October 3, 2017 Security Conference Call

Back to Security Main Page

Attendees

x	Member Name		x	Member Name		x	Member Name		x	Member Name
x	John MoehrkeSecurity Co-chair		x	Kathleen ConnorSecurity Co-chair		x	Alexander Mense Security Co-chair		.	Trish WilliamsSecurity Co-chair
x	Mike Davis		x	Suzanne Gonzales-Webb		x	David Staggs		x	Christopher Shawn
.	Mohammed Jafari		.	Beth Pumo		.	Ioana Singureanu		x	Rob Horn
x	Diana Proud-Madruga		.	Serafina Versaggi		x	Joe Lamy		.	Galen Mulrooney
.	Paul Knapp		.	Grahame Grieve		.	Johnathan Coleman		.	Aaron Seib
.	Ken Salyards		.	Christopher D Brown TX		.	Gary Dickinson		.	Dave Silver
.	Oliver Lawless		.	Ken Rubin		.	David Tao		.	Nathan Botts

Back to Security Main Page

Agenda

1. (3 min) Roll Call, Agenda Approval
2. (10 min) Review and Approval of September 26th Minutes. Review and approval of the HL7 Sept 2017 WGM San Diego Minutes
3. (10 min) Is Privacy Obsolete Study Group wiki page, TF4FA ballot delay, PSAF PSS and future deliverables - Mike
4. (15 min) #FHIR and Bulk Data Access Proposal Posted on September 20, 2017 by Grahame Grieve.

• See John's comment at bottom of page and his and Bulk De-Identification blog
• Draft Security WG comments - See ideas from last week's discussion below.

1. (20 min) Next version of the Interoperability Standards Advisory HL7 Policy Advisory Committee [PAC] would like to ask all workgroups to review the ISA for their areas of interest and let the HL7 Policy Advisory Committee know of any suggestions by October 15 at policyinput@lists.hl7.org. - Kathleen to point out any privacy/security hot topics. See list of ISA Links for discussion in Meeting Material section below.
2. (2 min) FHIR Security call - Call will happen at 5PM ET/2PM PT

Meeting Materials

Bulk Data Transfer Access Control & AuthorizationQuestions:

• What is the use-case for use of this? 
• There are use-cases that have legitimate authorization to all data of a given patient. For these use-cases a binary PERMIT vs DENY might be sufficient, but it is not clear what the use-case are.
• What is the intended PurposeOfUse? Is it Treatment? Payment? Coverage? Research? Public Health?  Each of these may or may-not provide binary PERMIT vs DENY ALL. Information used for Payment purpose of use, for example, does not include all information used for treatment.
• Based on the use-case the functionality of Minimum-Necessary may apply.  Is enforcement of minimum necessary requirements considered a source system responsibility?
• How is Consent going to affect this API?
• How might ConfidentialityCode affect this API?
• Audit Logging: Given the API, the Audit Logging needs to be defined clearly. Even if the AuditEvent resource is not mandated (which I think it should be), the functionality must be clearly defined. KC –Audit logs are required under HIPAA and MU.
  • Is this bulk access request recorded as ONE audit log entry, **ONE per patient, or is each Resource returned identified in the audit log.
  • ONE per patient would be needed if accounting of disclosure is a potential requirement.
• What happens when the Resources that are being requested in a Bulk Data Transfer have Security Labels that, for example (1) require a higher level of authorization for transfer; (2) obligate the recipient to limit purpose of use; or (3) prohibit the recipient from further disclosure?

• Will the POU for which the API was authorized to retrieve a Group be persisted as a security label on each Resource in the Group so that downstream compliance is assured?

Security WG ISA Review and Comment Page

ISA Item Links

• Document-Level Segmentation of Sensitive Information

◾Per 2015 Edition Health IT Certification Criterion for DS4P (§ 170.315(b)(7) and § 170.315(b)(8)), document-level tagging is the scope required for certification. ◾For C-CDA transmission, document level DS4P is required in the C-CDA General Header. Therefore, adoption levels may be higher than 1/5 for document level tagging (vs. section level).

• Data Provenance Establishing the Authenticity, Reliability, and Trustworthiness of Content Between Trading Partners
• Recording Patient Preferences for Electronic Consent to Access and/or Share their Health Information with Other Care Providers

◾IHE BPPC may not support management of patient privacy across governmental jurisdictions which may have different regulations regarding access to patient data by providers, patients, governmental entities, and other organizations. ◾Along with security tokens and consent documents, security labels that are the critical third part of the Attribute-Based-Access-Control and SLS should be mentioned as well. Security Labels are used in CDA, FHIR, as well as the IHE Document Sharing (e.g. XDS), as described on the FHIR security page at https://www.hl7.org/fhir/security-labels.html

• Sending a Notification of a Patient's Admission, Discharge, and/or Transfer Status to Other Provider
• Sending a Notification of a Long Term Care Patient’s Admission, Discharge and/or Transfer Status to the Servicing Pharmacy

Applicable Value Set(s) and Starter Set(s): ◾Secure Communication – create a secure channel for client-to-server and server-to-server communication. ◾Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery. ◾Authentication Enforcer – centralized authentication processes. ◾Authorization Enforcer – specifies access control policies. ◾Credential Tokenizer – encapsulate credentials as a security token for reuse (e.g., – SAML, Kerberos). ◾Assertion Builder – define processing logic for identity, authorization and attribute statements. ◾User Role – identifies the role asserted by the individual initiating the transaction. ◾Purpose of Use - Identifies the purpose for the transaction.

• View, Download, and Transmit Data from EHR
• Applicable Value Set(s) and Starter Set(s):

◾System Authentication – The information and process necessary to authenticate the systems involved ◾User Details – identifies the end user who is accessing the data ◾User Role – identifies the role asserted by the individual initiating the transaction ◾Purpose of Use – Identifies the purpose for the transaction ◾Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed

• • May be required to authorize any exchange of patient information
  • May be required to authorize access and use of patient information
  • May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply

◾Security Labeling – the health information is labeled with security metadata necessary for access control by the end user ◾Query Request ID – Query requesting application assigns a unique identifier for each query request in order to match the response to the original query ◾Secure Communication – create a secure channel for client-to-server and server-to-server communication. ◾Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery

• Remote Patient Authorization and Submission of EHR Data for Research
• Limitations, Dependencies, and Preconditions for Consideration:

◾See Sync for Science and Sync for Genes for more details about the research project use case that pertains to this interoperability need. ◾The Kantara Initiative's UMA (User Managed Access) Work Group project's use case is designed to develop specifications that allow individual control of authorized data sharing and service access to promote interoperability in support of this interoperability need.

• Push Patient-Generated Health Data into Integrated EHR
• ◾The SMART on FHIR Project is working in this area, and may have additional implementation guidance, as well as a list of applications supporting this interoperability need.
• ◾For Direct, interoperability may be dependent on the establishment of “trust” between two parties and may vary based on the trust community(ies) to which parties belong. The leading trust communities to enable communication amongst the most users include DirectTrust Web Site Disclaimers (for provider messaging and consumer-mediated exchange) and NATE Web Site Disclaimers (for consumer-mediated exchange).
• Information Model for the Interoperability of Behavioral Health
• Appendix I – Sources of Security Standards and Security Patterns See Question 16, Section VI 16. Are there other authoritative sources for Security Standards that should be included in Appendix I?

Minutes

Agenda: no additions/changes ‘’’Minutes: October 3, and 10th , 2017’’’

• 10th – Kathleen/Suzanne Motion to approve
  • Objections: none; Abstentions: none; approve 8
• 3rd – not yet complete

‘’’Privacy Study Group’’’ Is Privacy Obsolete?

• Comments are being received on the list—comments are being cataloged
• WG4 (ISO) is planning for a project would be P&S for the internet of things.
  • Mike is part of the US TAG
  • Ann Kevorkian – Privacy by Design created in OASIS
• Conversation on ‘privacy is dead’ – which Ann did not agree
• Cited GDPR; and suggested that privacy is not dead, but seriously challenged
  • Within NIST privacy

Privacy is about your choice—no concept where we see security services as enforcing privacy; there is no concept of privacy enforcement relying on security services… or that privacy is managed by security—where security fails, privacy also suffers.

• Mike is surprised by ISO on this now being a security issue.
• We need to look at the situations in US, CAN, EU and non-EU as well and take the opinions, viewpoints from each of these areas—belief is country specific is defined by law and will change from country to country—wherein we cannot develop sweeping …
  • David—they were saying there was no such thing as privacy; suggested to changing verbiage to ‘’data protection by design’’ (instead of privacy by design)
• Mike; there’re kind of like in HITSP days wondering why they were in the same room as privacy; HL7 is remarkably mature—expecting the rest of the world to also gone with though us; there is a view point (rest of world) where they have been uninformed in our work; joint information model, etc. it’s not part of their thinking and an obstacle in dialogue. (16:00)
  • conversation will be added to the HL7 listserv thread

Kathleen In a FHIR audit event, there is a place to add text inhuman readable terms to read what the resource is about: FHIR Security CR 14028

• Accounting of disclosure; it wouldn’t be structured in the text but other parts of Accounting of Disclosure on audit event would e

Per Mike: regarding fields:

• WHO ‘organization or person—in US, we may ask for both
• Determine if mandatory or optional fields (recommend making everything optional and make law require…
• Patient readable format—cite patient friendly format document in hl7
• Kathleen; will take into consideration and update as this is the first draft.

For the 2017 we had extensive comments

• There was good acceptance of the points that were made (table)
• <<Add table link>>

2. Addition of ADT; security labels should be included
   • Security labeling has been added to several other sections (33:12)
   • Section called vocabulary—move the HCS to that section and not keep in the reference section—point out that this is the vocabulary to be used in security labeling

• Also to terminology add SAMHSA vocabulary in ‘VSAC’ (confirm)
  • No other comments, additions
  • Move to add comments as described to submit as a draft tomorrow to ___
  • Comments as is (Kathleen/Suzanne)
    • Objections: 0, abstentions: none; approve: 9

• October 31, Kathleen and Suzanne will be out-of-office
• No other discussion items

Motion to adjourn: Kathleen/Suzanne at 12:49 Pacific time