December 11, 2018 Security Conference Call

Back to Security Main Page

Attendees

Back to Security Main Page

x	Member Name		x	Member Name		x	Member Name		x	Member Name
x	John Moehrke Security Co-chair		x	Kathleen Connor Security Co-chair		.	Alexander Mense Security Co-chair		.	Trish Williams Security Co-chair
.	Christopher Shawn Security Co-chair		x	Suzanne Gonzales-Webb		x	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
. x	Beth Pumo		.	Jim Kretz		.	Peter Bachman		x	Peter VanLiesdonk

Back to Security Main Page

Agenda

1. (2 min) Roll Call, Agenda Approval
2. (5 min) Review and Approval of Minutes December 4, 2018 (not ready for review)
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 Call - cancelled
5. (10 min) FHIR Security call update on FHIRcast presentation HL7 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 Q&A Webinar Recording is now available at 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.

Relevant 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 disassociability or 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 specifications and healthcare privacy related projects, which are intended to support healthcare standards developers and implementers to achieve the objectives of an overarching Privacy Framework as envisioned by the NIST Privacy Framework.

HL7 Privacy and related Security Standards and informative documents:

• HL7 Standards Privacy Impact Assessment (SPIA) Cookbook - Guides HL7 standards developers through a 10-step of an HL7 standard, reducing the need to retrospectively incorporate privacy.
• Security Risk Assessment Cookbook - Instructions for HL7 standards authors and workgroup members.
• 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.
• HL7 CDA® R2 Implementation Guide: Patient-Friendly Language for Consumer User-Interfaces, Release 1 - relevant to request for Common and accessible language.

Emerging HL7 Privacy related specifications, all of which are slated to be published as ANSI recognized standards in 2019:

• HL7 Trust Framework for Federated Authorization Conceptual and Behavioral Models - A general architecture for creating a trusted relationship with a healthcare partner supporting policy negotiation for security and privacy.
• HL7 Provenance Conceptual Model - Conceptual-level viewpoints associated with business requirements that relate to the content and structure of provenance data, and the functional behavior of systems that manage that data, which are important to establishing the trustworthiness of specific resources within the healthcare environment.

HL7 Privacy Projects:

• HL7 Standards in support of computably implementing General Data Protection Regulations (GDPR) requirements for healthcare.
• Is Privacy Obsolete Study Group - A "crowd sourced" study of international issues related to privacy and technology.

Meeting Minutes

Back to Security Main Page

Temporary Recording: https://fccdl.in/cPb1smUF4d

Meeting Chair:

Agenda Approved, Role taken

NIST RFI (see read ahead above) Privacy Framework Development and Attributes

• Voluntary approval
• voluntary conformance testing to help inform customers, etc to help

FHIRCASE (fhircast.com)

• Issac presented the current state of FHIRCAST ((add lik)
• discussed a couple of dimensions through fhircase and there were two issues raised by community (via GitHub) brought to light potential security gap openining up...without understanding that they are opening
• good working session
• JohnM is added a few comments on their GitHub for security and privacy consideration
• they are leveraging the W3C spec called WebSub
  • would recomment our community to look at it a standard that we're leveragesing .. contains a sS&P section that is now commen in W3C
  • also have a S&P questionnaire that all specs much utilize when that spec is being written---similar to our S&P cookbook, but more actionable---tangential to FHIRcast.
    • maybe a process that we might want to review/consider
  • like our S&P cookbook but a different approach
• asking community what W3C community is doing and come prepared to dsicss.
  • not saying yes we should do, but review the approach in W3C

Upcoming meetings (FHIR-Secuity will meet on for the 18 NO MEETINGS December 18, 25 or January 1st NEXT MEETING, January 8th

Secufrity WGM Agenda

• JohnM to check with Isaac for FHIRCast (maybe Monday afternoon, as a report out)
• JohnM suggests - add a full Q of FHIR

Motion made to adjorn Meeting ended at 1347 Arizona time --Suzannegw (talk) 15:47, 11 December 2018 (EST)