IHE ITI Technical Framework
  • IHE IT Infrastructure (ITI) Technical Framework, Volume
    Revision 20.0, August 4, 2023 – Final Text
The Final Text ITI Technical Framework is published here in HTML format and is no longer published as PDF. Trial Implementation supplements are available from the Volume 1 Table of Contents.

3 National Extensions for IHE USA

The national extensions documented in this section shall be used in conjunction with the definitions of integration profiles, actors and transactions provided in Volumes 1 through 3 of the IHE ITI Technical Framework. This section includes extensions and restrictions to effectively support the regional practice of healthcare in the United States.

This ITI national extension document was authored under the sponsorship and supervision of IHE USA and the IT Infrastructure Technical Committee. Comments should be directed to: 

http://www.ihe.net/ITI_Public_Comments

3.1 Data Segmentation for Privacy (DS4P)

This National Extension shows how to use and interpret the Document Sharing Metadata Profiles (XDS.b, XCA, XDR, XDM, and MHD) in compliance with the requirements identified for Data Segmentation for Privacy (DS4P). Data Segmentation is the privacy and security concept for differentiating between data that are to be handled differently for privacy or security reasons. Data Segmentation for Privacy support in this context is the interoperability constraints to enable documents of various and different privacy and sensitivity to be communicated within a trust framework in a way that the sender can communicate necessary and specific privacy and security attributes and obligations in a way that the recipient can clearly understand them and act properly.

This national extension is intended to be used within a trust framework between communicating parties. This trust framework includes policy agreements to use this national extension to communicate segmented sensitive information. For each document that is communicated within this trust framework (PUSH or PULL) the following metadata constraints shall be used to communicate the highest sensitivity of the content as evaluated by the sender. The identified sensitivity level is then enforced by the recipient. Trust enforcement is expected to be defined and managed within that trust framework.

This USA National Extension addresses methods for sharing of segmented documents containing personally identifiable information (PII) as may be permitted by privacy policies or regulations. The privacy policies on which this National Extension is based do not explicitly address the clinical implications of giving patients control over the disclosure of their sensitive records. Standards development organizations are focused on the development of technical infrastructure specifications and remain agnostic on the appropriateness of a privacy policy.

Privacy policies are defined as limits on disclosure and use. Disclosure and use restrictions may originate from a patient, a service provider, or from jurisdictions where healthcare is delivered. Implementations should be prepared to extend functionality based on state, region, and local policies.

This USA National Extension is the result of a proposal from the US Department of Health and Human Services, Office of the National Coordinator for Health IT (ONC) to develop guidance for implementation of Data Segmentation Techniques, including RESTful patterns as defined in the MHD Profile, using the standards, building blocks and principles documented in the Use Cases developed by the S&I DS4P stakeholder community, and the NwHIN SOAP/Exchange version of the S&I DS4P Implementation Guide.   Furthermore, this specification draws upon and cites specific instances of U.S. law such as 42 CFR Part 2, 38 CFR Part 1, etc. These specific references are intended to profile a specific set of users operating under realm specific law and goals. Nothing in this supplement is intended to prevent adoption or customization to meet the needs of other realms.

This USA National Extension is based on artifacts and the findings of pilot implementations of the Data Segmentation for Privacy (DS4P) S&I Framework Initiative , specifically on the Use Cases developed by the stakeholder community, and the NwHIN SOAP/Exchange version of the S&I DS4P Implementation Guide.   Additionally, content from the HL7 DS4P Profiles (HL7_IG_DS4P_R1_CH1_CONTENT_N2_2014JAN, HL7_IG_DS4P_R1_CH2_DIRECT_N2_2014JAN, and HL7_IG_DS4P_R1_CH3_EXCHANGE_N2_2014JAN) which in turn reference IHE XDS are noted as important companion documents. For a detailed description of the project, refer to the S&I Initiative DS4P Project Executive Summary found at http://wiki.siframework.org/Data+Segmentation+for+Privacy+Homepage .

This USA National Extension defines constraints according to the requirements captured in the Use Cases developed by the Data Segmentation for Privacy (DS4P) S&I Framework Initiative stakeholder community and additional requirements that were identified by pilot projects engaged in validating the implementation guidance developed by the DS4P S&I Framework Initiative.

Conformance to the Document Sharing Profiles (e.g., XDS.b, XDR, XDM, XCA, and MHD) is expected with the following additional constraints based on privacy policies related to the type of document and the context of the exchange (requesting user, patient, consent, document, facility, purpose, communications mechanism, etc.).

  • DocumentEntry constraints are given in Section 3.1.2 below. The constraints include:
  • Security tags (confidentialityCode ) constraints
  • indicate the Confidentiality Level specified by using the designated HL7 Confidentiality vocabulary
  • indicate the Handling Caveats for Obligation Policy using a designated Obligation Policy vocabulary
  • indicate the Handling Caveats for Purpose of Use using a designated Purpose of Use vocabulary
  • indicate Handling Caveats for Refrain Policy using a designated Refrain Policy vocabulary
  • indicate the Authoring healthcare facility type using a designated restricted healthcare facility type vocabulary
  • indicate the Document  practice setting type using a designated restricted practice setting vocabulary
  • indicate the Low-level classification of the document (typeCode) using a designated restricted type code vocabulary
  • SubmissionSet constraints are given in the Section 3.1.3 below. The constraints include:
  • Indicated as necessary the Targeted intended recipient (intendedRecipient)
  • Indicate the SubmissionSet creator

3.1.1 DS4P Document Content

Any CDA® document SHOULD comply with the CDA constraints defined in the HL7 CDA Privacy Segmented Document template (templateId: 2.16.840.1.113883.3.3251.1.1)

Other content types MAY be carried.

3.1.2 DS4P DocumentEntry

The following constraints apply to all documents in the SubmissionSet.

All the designated vocabulary and value sets are defined by HL7.

3.1.2.1 DS4P DocumentEntry.confidentialityCode

The confidentialityCode metadata SHALL use the “HL7 Healthcare Privacy and Security Classification System (HCS)” as defined in ITI TF-3: 4.2.3.2.5

3.1.2.1.1 DS4P Confidentiality Security Classification Label

The confidentialityCode element SHALL contain exactly one value from the codesystem 2.16.840.1.113883.5.25 (i.e., U, L, M, N, R, or V) (aka, http://hl7.org/implement/standards/fhir/v3/Confidentiality/index.html ), to indicate the Confidentiality coding of the content.

The confidentialityCode may also contain other values from other codesystems for which Sections 3.1.2.1.2 and 3.1.2.1.3 below are two examples.

The value represents the most restrictive content in the identified document (aka, High water mark).

3.1.2.1.2 DS4P Sensitivity Security Classification Label

The confidentialityCode SHOULD NOT contain a sensitivity indicator unless the trust framework policies indicate otherwise.

3.1.2.1.3 DS4P Handling Caveats Security Category

The confidentialityCode element SHALL contain any Obligation Handling Caveats deemed necessary.

If present, the Obligation values SHALL be selected from the ValueSet

  HL7 ObligationPolicyCode 2.16.840.1.113883.1.11.20445

  Also found at http://hl7.org/implement/standards/fhir/v3/vs/ObligationPolicy/index.html

If present, the Purpose Of Use values SHALL be selected from the ValueSet

HL7 PurposeOfUse 2.16.840.1.113883.1.11.20448

Also found at http://hl7.org/implement/standards/fhir/v3/vs/PurposeOfUse/index.html

If present, the Refrain Policy values SHALL be selected from the ValueSet

  HL7 RefrainPolicy 2.16.840.1.113883.1.11.20446

  Also found at http://hl7.org/implement/standards/fhir/v3/vs/RefrainPolicy/index.html

3.1.2.2 DS4P DocumentEntry.healthcareFacilityTypeCode

The healthcareFacilityTypeCode element contains an indicator of the type of facility that authored the document. The ValueSet designated is restricted to the subset of practice setting codes that will not disclose details about the healthcare facility that may be protected in a specific affinity domain, directed exchange, Health Information Exchange, etc. The HL7 RestrictedHealthcareFacilityTypeCode ValueSet meets this definition and is designated for this purpose.

The healthcareFacilityTypeCode element’s value SHALL be selected from the ValueSet

HL7 RestrictedHealthcareFacilityTypeCode 2.16.840.1.113883.3.3251.3.2.1

This HL7 ValueSet is a dynamic ValueSet. An HL7 ‘dynamic’ ValueSet is one that can change over time to adjust to changing policy landscapes, but is a managed ValueSet.

3.1.2.3 DS4P DocumentEntry.practiceSettingCode

The practiceSettingCode element contains an indicator of the type of practice setting. The ValueSet designated is restricted to the subset of practice setting codes that will not disclose details about the practice that may be protected in a specific affinity domain, directed exchange, Health Information Exchange, etc. The HL7 RestrictedPracticeSettingCode ValueSet meets this definition and is designated for this purpose. The ValueSet is derived from SNOMED-CT codes in a way consistent with prevailing privacy policies.

The practiceSettingCode element’s value SHALL be selected from the ValueSet

RestrictedPracticeSettingCode 2.16.840.1.113883.3.3251.3.2.2

This HL7 ValueSet is a dynamic ValueSet. An HL7 ‘dynamic’ ValueSet is one that can change over time to adjust to changing policy landscapes, but is a managed ValueSet.

3.1.2.4 DS4P DocumentEntry.typeCode

The typeCode element identifies the type of document. The ValueSet designated avoids disclosing protected information. The HL7 RestrictedTypeCode ValueSet meets this definition and is designated for this purpose.

The typeCode element’s value SHALL be selected from the ValueSet

RestrictedTypeCode 2.16.840.1.113883.3.3251.3.2.3

This HL7 ValueSet is a dynamic ValueSet. An HL7 ‘dynamic’ ValueSet is one that can change over time to adjust to changing policy landscapes, but is a managed ValueSet.

3.1.3 DS4P SubmissionSet

The following constraints apply to the submissionSet containing the document entries

3.1.3.1 DS4P SubmissionSet.intendedRecipient

The intended recipient element’s value MAY contain the intended recipient. When the exchange requires an intended recipient constraint, this element SHALL be populated. This element SHALL contain the e-mail address of that intended recipient unless the trust framework identifies an alternative encoding that is acceptable.

3.1.3.2 DS4P SubmissionSet.author

The SubmissionSet Author element’s value SHALL contain at least the author of the submission set.

This element SHALL contain the e-mail address of the author of the submission set unless the trust framework identifies an alternative encoding that is acceptable.

The recipient utilizes the SubmissionSet author as the indicator of the sender for PUSH transactions, and as the provenance identifier of the submission. This information may be used by the recipient in policy decisions and enforcement.