This wiki has undergone a migration to Confluence found Here

ONC Interoperability Standards Advisory 2018 Review and Comment Page

From HL7Wiki
Revision as of 18:57, 20 November 2017 by Kathleenconnor (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

HL7 Response Letter ONC ISA 2018 Comments Submitted to ONC

Final PAC Approved 2018 ISA Comments submitted to HL7 Executive Committee

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

◾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).

◾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

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.

◾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

◾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.