This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

December 11, 2018 Security Conference Call

From HL7Wiki
Jump to navigation Jump to search

Back to Security Main Page


Back to Security Main Page

x Member Name x Member Name x Member Name x Member Name
. John Moehrke Security Co-chair x Kathleen Connor Security Co-chair . Alexander Mense Security Co-chair . Trish Williams Security Co-chair
x Christopher Shawn Security Co-chair x Suzanne Gonzales-Webb . Mike Davis x David Staggs
x Diana Proud-Madruga . Johnathan Coleman . Francisco Jauregui . Joe Lamy
x Theresa Ardal Connor . Greg Linden . Grahame Grieve x Dave Silver
. . Beth Pumo . Jim Kretz . Peter Bachman . Peter VanLiesdonk

Back to Security Main Page


  1. (2 min) Roll Call, Agenda Approval
  2. (5 min) Review and Approval of Minutes December 4, 2018
  3. (30 min) Developing a Privacy Framework WG comments on NIST RFI for HL7 Policy Advisory Committee - see Meeting Materials. Kathleen
  4. (2 min) GDPR Vocabulary Call - cancelled
  5. (10 min) FHIR Security call update on FHIRcast presentationHL7 FHIR Security 2018-12-11- John
  6. (5 min) 201901 Security WGM Agenda wiki style & 201901 Security WGM Agenda Confluence Style Continue editing - Kathleen

Meeting Materials

NIST Privacy Framework RFI published 11/4/2018. Comments due 12/31/2018. HL7 PAC is interested in Security and CBCP comments on HL7 standards and general position on key topics. Excerpts:

  • The NIST Privacy Framework: An Enterprise Risk Management Tool (“Privacy Framework”), is intended for voluntary use and is envisioned to consist of outcomes and approaches that align policy, business, technological, and legal approaches to improve organizations' management of processes for incorporating privacy protections into products and services.
  • This notice requests information to help identify, understand, refine, and guide development of the Privacy Framework. The Privacy Framework will be developed through a consensus-driven, open, and collaborative process that will include workshops and other opportunities to provide input.
  • NIST is developing a voluntary Privacy Framework to help organizations: better identify, assess, manage, and communicate privacy risks; foster the development of innovative approaches to protecting individuals' privacy; and increase trust in products and services.
  • The Privacy Framework is intended to be a tool that would assist with enterprise risk management.
  1. Consensus-driven and developed and updated through an open, transparent process. NIST will model the approach for the Privacy Framework on the successful, open, transparent, and collaborative approach used to develop the Framework for Improving Critical Infrastructure Cybersecurity (“Cybersecurity Framework”).
  2. Common and accessible language. The Privacy Framework should be understandable by a broad audience, including senior executives and those who are not privacy professionals.
  3. Adaptable to many different organizations, technologies, lifecycle phases, sectors, and uses. The Privacy Framework should be scalable to organizations of all sizes, public or private, in any sector, and operating within or across domestic borders. It should be platform- and technology- agnostic and customizable.
  4. Risk-based, outcome-based, voluntary, and non-prescriptive.
  5. Readily usable as part of any enterprise's broader risk management strategy and processes.
  6. Compatible with or may be paired with other privacy approaches. Privacy Framework should take advantage of existing privacy standards, methodologies, and guidance. It should be compatible with and support organizations' ability to operate under applicable domestic and international legal or regulatory regimes.
  7. A living document.

Privacy Framework Development and Attributes

  • While good cybersecurity practices help manage privacy risk through the protection of personally identifiable information (PII),[3] privacy risks also can arise from how organizations collect, store, use, and share PII to meet their mission or business objective, as well as how individuals interact with products and services. NIST seeks to understand whether organizations that design, operate, or use these products and services would be better able to address the full scope of privacy risk with more tools to support better implementation of privacy protections. 
  • NIST invites industry, civil society groups, academic institutions, Federal agencies, state, local, territorial, tribal, and foreign governments, standard-setting organizations, and other interested stakeholders to respond.
  • The goals of the Privacy Framework development process, generally, and this RFI, specifically, are:
  1. To better understand common privacy challenges in the design, operation, and use of products and services that might be addressed through a voluntary Privacy Framework,
  2. To gain a greater awareness about the extent to which organizations are identifying and communicating privacy risk or have incorporated privacy risk management standards, guidelines, and best practices, into their policies and practices; and
  3. To specify high-priority gaps for which privacy guidelines, best practices, and new or revised standards are needed and that could be addressed by the Privacy Framework or a related roadmap.

NIST solicits information about how organizations assess risk; how privacy considerations factor into that risk assessment; the current usage of existing privacy standards, frameworks, models, methodologies, tools, guidelines, and principles; and other risk management practices related to privacy. In addition, NIST is interested in understanding whether particular frameworks, standards, guidelines, and/or best practices are mandated by legal or regulatory requirements and the challenges organizations perceive in meeting such requirements.

  1. The greatest challenges in improving organizations' privacy protections for individuals;
  2. The greatest challenges in developing a cross-sector standards-based framework for privacy;
  3. How organizations define and assess risk generally, and privacy risk specifically;
  4. The extent to which privacy risk is incorporated into different organizations' overarching enterprise risk management;
  5. Current policies and procedures for managing privacy risk;
  6. How senior management communicates and oversees policies and procedures for managing privacy risk;
  7. Formal processes within organizations to address privacy risks that suddenly increase in severity;
  8. The minimum set of attributes desired for the Privacy Framework, as described in the Privacy Framework Development and Attributes section of this RFI, and whether any attributes should be added, removed or clarified;
  9. What an outcome-based approach to privacy would look like;
  10. What standards, frameworks, models, methodologies, tools, guidelines and best practices, and principles organizations are aware of or using to identify, assess, manage, and communicate privacy risk at the management, operational, and technical levels, and whether any of them currently meet the minimum attributes described above;
  11. How current regulatory or regulatory reporting requirements (e.g., local, state, national, international) relate to the use of standards, frameworks, models, methodologies, tools, guidelines and best practices, and principles;
  12. Any mandates to use specific standards, frameworks, models, methodologies, tools, guidelines and best practices, and principles or conflicts between requirements and desired practices;
  13. The role(s) national/international standards and organizations that develop national/international standards play or should play in providing confidence mechanisms for privacy standards, frameworks, models, methodologies, tools, guidelines, and principles;
  14. The international implications of a Privacy Framework on global business or in policymaking in other countries; and
  15. How the Privacy Framework could be developed to advance the recruitment, hiring, development, and retention of a knowledgeable and skilled workforce necessary to perform privacy functions within organizations.
  16. How your organization currently manages privacy risk. For example, do you structure your program around the information life cycle (i.e., the different stages—from collection to disposal—through which PII is processed), around principles such as the fair information practice principles (FIPPs), or by some other construct?
  17. Whether any aspects of the Cybersecurity Framework could be a model for this Privacy Framework, and what is the relationship between the two frameworks.
  18. Please describe your preferred organizational construct for the Privacy Framework. For example, would you like to see a Privacy Framework that is structured around:
  • The information life cycle;
  • Principles such as FIPPs;
    • The NIST privacy engineering objectives of predictability, manageability, and disassociabilityor other objectives;
    • Use cases or design patterns;
    • A construct similar to the Cybersecurity Framework functions, categories, and subcategories;
  • Specific Privacy Practices: In addition to the approaches above, NIST is interested in identifying core privacy practices that are broadly applicable across sectors and organizations. NIST is interested in information on the degree of adoption of the following practices regarding products and services:
    • De-identification;
    • Enabling users to have a reliable understanding about how information is being collected, stored, used, and shared;
    • Enabling user preferences;
    • Setting default privacy configurations;
    • Use of cryptographic technology to achieve privacy outcomes—for example, the disassociability privacy engineering objective;
  • Data management, including:
    • Tracking permissions or other types of data tracking tools,
    • Metadata,
    • Machine readability,
    • Data correction and deletion; and
    • Usable design or requirements.
  • Whether the practices listed above are widely used by organizations;
  • How the practices listed above or other proposed practices relate to existing international standards and best practices;
  • How standards or guidelines are utilized by organizations in implementing these practices

HL7 Privacy and Security Standards & Projects relevant to NIST Privacy Framework Response

The following are HL7 specification, which support healthcare standards developers and implementers to achieve the objectives of an overarching Privacy Framework as envisioned by the NIST Privacy Framework.

  • [1] - Guides HL7 standards developers through a 10-step process that helps ensure that privacy impacts are considered during the implementation of an HL7 standard, reducing the need to retrospectively incorporate privacy.
  • HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 - Foundational HL7 Privacy and Security Vocabulary used as metadata for encoding data subject, organizational, and jurisdictional privacy policies, which can be computably enforced, interoperably exchanged, and supports cross-domain privacy policy bridging.
  • HL7 Version 3 Standard: Privacy, Access and Security Services; Security Labeling Service, Release 1 (SLS - Conceptual Behavioral Model describing how to apply and enforce security labels valued with HCS codes.
  • HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 - Meaningful Use optional certification standard for applying machine readable security labels, which encode data subject, organizational, and jurisdictional privacy policies, to HL7 CDA artifacts.
  • HL7 Version 3 Standard: Security and Privacy Ontology, (SPO) Release 1 - Formally names and describes key interrelated security and privacy concepts within the scope of Healthcare Information Technology, including security policies, and data subject, organizational, and jurisdictional privacy policies, for intra- and inter-enterprise enforcement and accountability via trust frameworks, access control, audit, and provenance.
  • HL7 Version 3 Standard: Healthcare (Security and Privacy) Access Control Catalog , Release 3 - Conceptual model viewpoints associated with the business requirements that relate to the content, structure, and functional behavior of information important to the Access Control area of the Privacy, Access, and Security domains within the healthcare environment.
  • HL7 CDA® R2 Implementation Guide: Privacy Consent Directives, Release 1 - A structured document specification to exchange signed Consent Directives, and provides a computable representation of a consent directive but the resulting structured documents could be used to generate enforceable assertions or rules (e.g. SAML, XACML).
  • FHIR Consent Resource - A record of a healthcare consumer’s choices, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time.
  • FHIR Contract Resource - Legally enforceable, formally recorded unilateral or bilateral directive i.e., a policy or agreement.
  • FHIR Provenance Resource - Provenance statement indicating clinical significance in terms of confidence in authenticity, reliability, and trustworthiness, integrity, and stage in lifecycle , all of which may impact security, privacy, and trust policies.
  • Audit Event Resource - The content of an AuditEvent is intended for use by security system administrators, security and privacy information managers, and records management personnel. Useful for deriving provenance and accounting of disclosure records.

Meeting Minutes

Back to Security Main Page