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 & Authorization Questions:

• 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?