ONC Interoperability Standards Advisory 2018 Review and Comment Page

Back to Security Main Page

Next version of the Interoperability Standards Advisory 2018 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.

PAC Comment Format Guidance

As you provide feedback, please use the following format as much as possible:

• Section and Interoperability Need
• Including the link to the ISA Interoperability Need page would be ideal.
• Commenting Suggestions:
• o Can include corrections, changes to adoption level, maturity, etc.
• o Provide Rationale
• o Be realistic, practical, don’t oversell
• o Be as positive as possible though
• If you have any suggestions to make the ISA more navigable, user friendly, easier to search, please consider those as well.
• PAC Detailed Commenting Guidance

Please review and send positive, negative, and suggestion comments to Kathleen Connor by October 15th. Thanks!

Potential Comment Areas

• Upgrade maturity of data segmentation on CDA
• Include FHIR Security labels as means to protect FHIR Bundles and Resources
• Add FHIR Consent and Contract to emerging Consent Directive standards
• Include use of both for individual Right of Access
• Add FHIR Provenance to DPROV
• Under Pre-population of Research Forms from Electronic Health Records Add FHIR Audit Event and FHIR Research Study and Research Subject as emerging approaches to conveying Research information. Add SDC Questionnaire/QuestionnaireResponse for pre-populating Research Forms.
• Include the ability to use FHIR Audit Events to generate FHIR Accounting of Disclosure Resources
• Add TF4FA and FHIR Contract for App Terms of Service and for Trust Contract to determine trading partner capabilities for e.g., consuming and enforcing computable consent directives
• Add FHIR AuditEvent and Provenance Resources; NIST SP 800-63, NIST SP 800-53, and NISTR 8062 to Appendix I – Sources of Security Standards and Security Patterns.

Below are links to ISA Sections that discuss privacy & security.

ISA 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?
• Comments from Oct.3 Security WG call:
  • NISTR 8062
  • NIST 800-53 Rev 5 Review Security and Privacy Controls for Information Systems and Organizations Initial Public Draft
  • NIST SP 800-63 Digital Identity Guidelines