ONC Interoperability Standards Advisory 2018 Review and Comment 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.
Below are links to ISA Sections that discuss privacy & security.
Please review and send positive, negative, and suggestion comments to Kathleen Connor by October 15th.
Thanks!
ISA Links
◾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:
