Data Segmentation for Privacy Initiative –
Technical Approach Executive Summary
Highlights
 Use existing and evolving
standards and profiles to
enable data segmentation
The Challenge of Data Segmentation
This executive summary is targeted at members of the HITSC
Privacy and Security Workgroup and healthcare executives
with a good understanding of how to implement standardsbased interoperability solutions
Summary of Technical Approach
 Use of controlled value sets for
computability of privacy
metadata
 Structure patient consent in a
machine-readable format that
is easy to understand and
exchange
The S&I Framework Data Segmentation for Privacy Initiative
Technical Approach, developed with an open-community and
consensus-approved, focused on the use of privacy metadata
to segment patient data. By reusing existing standards and
allowing for a gradual escalation in granularity at the patient’s behest, mechanisms are put into place
that allow for both the healthy exchange of patient information and a level of control on how that
information can be used and disclosed. Our approach looked to ensure that Direct and eHealth
Exchange, formerly NwHIN Exchange, would be immediately supported as transport approaches for
privacy metadata, with future focus on implementation support for REST.
Several existing and proposed Federal regulations are used as reference points for defining our
requirements and technical solution. These regulations are intended to provide tangible examples of the
types of policies that must be addressed, e.g., 42 CFR Part 2 for Federally assisted alcohol and drug
abuse treatment programs, Section 7332, Title 38, USC for sharing of healthcare data collected by the
Veterans Administration, and Proposed Rule 45 CFR Part 164.522(a)(1)(iv) allowing the patient to restrict
the sharing of data with payers for self-pay services. Our implementation guidance is intended to be
broad and flexible enough to address other legal and regulatory requirements should they become
applicable in the future. For further detail about supported uses cases and system requirements please
refer to the Use Case document.
The technical approach is also intended to be supportive of multiple standards and technologies, in
accomplishment of the following objectives:

Support for pushing of segmented patient data through support for secure email (Direct) and
the persistence of segmented data through the use of pull-based implementation models (as
defined by the eHealth Exchange)


Use of structured vocabularies to deliver unambiguous meaning to receiving systems about
privacy metadata, such as obligations, confidentiality, and refrain policies.
Extensibility to allow for application of controls to patient data, down to uniquely-defined
granular privacy controls for data, such as lab results and medications.
In the following visual, an example of the Data Segmentation for Privacy Technical Approach is shown:
Figure 1 – Data Segmentation Approach Overview
The Data Segmentation for Privacy Technical Approach is focused on the use of existing and evolving
standards to support the need for segmentation of patient data. The use of standards in this approach is
intended to leverage existing successful efforts within the health information technology community.
Specific to reuse, the Data Segmentation for Privacy Technical Approach is designed to support multiple
architectures, including use of SMTP and S/MIME through the Direct Project (with additional IHE XDR
support) and use of SOAP architectures that support IHE XD* metadata. REST is also supported, with
further discussion on the REST approach evolving as piloting results evolve.
Standards Used in this Technical Approach
The standards selected for implementation were reviewed by the S&I Framework to ensure they aligned
to the following factors, as expressed by the Office of the National Coordinator (ONC) and the Health IT
Standards Committee (HITSC):



Viability for implementation within existing and future environments, as Meaningful Use Stage 2
progresses and Meaningful Use Stage 3 begins
Availability of documentation to support implementers who wish to exchange segmented
patient data within their environments, and to support implementation of data segmentation
mechanisms within vendor products, such as electronic health records (EHRs)
Extensibility to support both expected and unplanned improvements to privacy metadata, as
the level of patient control over their data increases
Further information about the standards harmonization for Data Segmentation for Privacy can be found
reference the following link: Standards Harmonization
A summary of the usage of these standards and profiles within this technical approach is provided
below:
Capability
Standard/Profile
Specific Usage
IHE XD* Profiles
IHE XDR and XDM Metadata
IHE XDS Metadata used as the mechanism
to support both SubmissionSet and
Document metadata
Vocabularies
ASC X12 5010
Used to define type of insurance coverage
Capability
Healthcare Facility Type Value Set –
as defined in HITSP C80
Used to define facility types (and used by
systems to determine protected facilities)
HL7 RefrainPolicy
Used to convey specific prohibitions on the
use of sensitive health information
HL7 PurposeofUse
Used to convey a purpose of use
HL7 BasicConfidentialityCodeKind
Used to represent confidentiality codes
HL7 ObligationCode
Used to convey specific obligations
HL7 ActPolicyType
HL7 SensitivityPrivacyPolicy
Used to convey a type of policy
Used to convey the sensitivity level of a
specific policy
SOAP
Transport-level security
Transport
Transport
Transport
Transport
SMTP and S/MIME
S/MIME attributes are bound to SMTP to
provide for the use of secure email as the
transport mechanism for exchanging patient
data
Conveying Identity
- Cross-Enterprise User Assertion
(XUA)
IHE XUA Metadata
SAML Assertion
(SAML Request and Response)
- OASIS SAML Specification Version
2.0
Conveying Identity
X.509 Digital Certificates
PKI to support Direct implementations
Patient Consent
Structure
HL7 CDA R2 Consent Directive
(DSTU)
HL7 CDA Consent Directive DSTU
Table 1 - Applicable Standards for Data Segmentation
Use and Placement of Privacy Metadata
Metadata Definition: A set of data that describes and gives information about other data.
Metadata is applied and processed at various levels of information exchange. The intent of the Data
Segmentation for Privacy Technical Approach is to make the application and processing of privacy
metadata machine-readable and computable, while also ensuring ease of the implementation of
privacy-aware interoperability solutions. The model used for this implementation guidance is to focus on
separation of levels used to exchange protected information sent from one organization to another.
Each level would have specific metadata that would be applicable; with the levels being defined in the
table below describes the privacy at a different level in the transaction (e.g. payload, transport):
Levels of Metadata
Privacy-related metadata
How the Metadata is Used in the Implementation
The metadata associated with the information exchange is
intended to support applicable privacy policies. This
metadata ensures that protected information can be
exchanged in a way consistent with applicable privacy
policies:
 Purpose of Use code
 Obligation Code
 Refrain Code
In addition to the current Confidentiality Code the DS4P
implementation guide defines only interoperability-related
metadata needed to support existing privacy policy; it does
not propose a new privacy policy.
Privacy-related metadata such as confidentiality code,
purpose of use, obligations, and refrain policies may appear
in the “Access Control and Authorization Related Metadata,”
added to a technology-specific “Transport-related
metadata.” The privacy-related metadata may be added to
the payload-metadata to describe not only the information
itself by its privacy-related characteristics to the receiver of
protected clinical information.
While privacy-related metadata accompanies the clinical
payload subject to disclosure, a privacy policy reference is
viewed as a document separate from the clinical payload
that informs the sending or receiving party who it may
disclose privacy-protected information to.
Payload-related metadata
The metadata describes the patient information exchanged
in the payload. It specifies the type of data exchanged its
origin, its current custodian, the intended recipient, the
target patient, etc. This is referred to as the “payload
mechanism” and is placed within the actual content (for
example, in a CDA document or section.
This initiative has proposed additional payload-related
metadata to support the “privacy-related metadata”
described above. This metadata, for instance, allows
implementers to specify the privacy characteristics of an
individual clinical statement in a CDA document.
Access Control and Authorization
The metadata to determine level of access and authorization
of users of EHRS (Electronic Health Record Systems). An
example of this type of metadata would be a SAML
assertion.
Transport
The metadata associated with a specific transport
mechanism or protocol used to exchange protected clinical
information. This is referred to as the “transport
mechanism.” An example of this metadata is IHE XDM
metadata associated with a Direct message or IHE XDR
metadata included in a NwHIN transaction.
Table 2 – Privacy Metadata
The goal is to apply the appropriate amount of metadata that is necessary for a given level, and no
more.
Figure 2 – Privacy metadata may be applied at different levels in the transaction
As seen in Figure 3, the privacy-related metadata identified by the DS4P is used to specify the
responsibilities associated with this data. Similar to other responsibilities related to acknowledging a
transaction, for instance, the receiver must recognize and persist the metadata associated with the
exchange of protected information.
NEW PRIVACY METADATA introduced by this initiative: Obligation and Refrain Codes – to support
specific obligations for disclosure (including refraining from disclosing to other parties) using controlled
vocabularies both as policy references. More detailed obligations, such as the naming of specific parties
that information can only be disclosed to may be accomplished through external references to a
patient’s privacy consent.
Type of Content and Transaction – supports the use of metadata in various levels of content and
transactions, such as the use of privacy metadata “for the metadata” as well as privacy metadata
embedded into patient data that is captured in a format such as CDA.
The following figure summarizes where privacy metadata is intended to be placed:
Figure 3 - Placement of Privacy Metadata in Data Segmentation Approach
The purpose of placement is to ensure that the least revealing metadata is placed in the outer envelope
(the Document Entry XD* Metadata) with the most revealing privacy metadata being placed at the CDA
Entry level. This approach ensures that two implementations are possible:
o
o
Implementation of obligations for restricting disclosures that are implemented through external
references within CDA entry templates
Implementation of obligations for restricting disclosures that are implemented through the use
of XD* metadata (as a policy reference or refrain codes) to reference specific policies.
The following figure summarizes the distinction between “payload” privacy metadata and “transport”
privacy metadata:
Figure 2 - Payload and Transport Privacy Metadata
Segmentation “High Watermark”
The essential premise of the Data Segmentation metadata approach is that metadata is applied at
different levels within patient data. Segmentation works through a “high watermark” approach. In this
approach, the highest level of confidentiality and obligations that is established for the transaction
carries through to the content, and vice versa.



IHE XD* metadata is placed at the Document Entry and Submission Set level , such as a purpose
of use and obligation codes
XUA++ metadata is included in those scenarios where a “pull” approach is employed
Where a CDA approach is used, the Header and Section may include confidentiality codes
o CDA entries may also include an external reference to additional obligations and
restrictions on disclosure
The following is an example of the high watermark approach:
Figure 3 - Defining Segmentation "High Watermark"
A problem observation of “shingles” contains an external reference to a consent document that
establishes restrictions on the disclosure of this observation to only a dermatologist, and only for
purposes of treatment. This restriction includes codes obligating disclosure only in the case of a visit by
the patient to a dermatologist, and also contains refrain codes limiting disclosure beyond that purpose.
The Problem Section holding this observation would include a confidentialityCode of R.
The Dermatologist who receives information from a primary care physician is then able to process the
problem observation and its confidentiality code, by first evaluating the metadata surrounding the
problem observation, and then ensuring that refrain codes contained in the metadata are enforced by
the receiving system and the dermatologist’s organization. For a problem observation of “shingles”, the
external reference is also accessed by the dermatologist’s receiving system to ensure that all aspects of
the patient’s consent are reviewed and enforced.
If this is established within the CDA entry, a “high watermark” is established for the entire transaction.
This means that the IHE XD* metadata must also reflect this confidentialityCode of R. In this example,
the shingles diagnosis is protected, and since the document contains the shingles diagnosis, it is
protected by an “R”. However, if the receiving dermatologist (with the right to access this document)
wanted to incorporate sections into his/her EHR, he/she could incorporate the “N” sections without any
special management necessary.
The Workflow of Data Segmentation
Segmentation is designed to be an internal system activity that a sending system conducts prior to
sending patient data deemed “sensitive” to a receiving system. How to apply privacy metadata to
specific data that have been deemed sensitive is in scope. Determining what is considered “sensitive” is
subject to policy and therefore outside the scope of this initiative (e.g. DS4P is not tasked with
determining what is considered substance abuse data) - this is defined by law and policy at the federal
and state levels. However, DS4P did identify various strategies for systems to use in determining which
data needs to be segmented. The end-goal of the initiative was to produce documented guidance for
implementers around the strategies further detailed in this document, based around three transport
mechanisms – The Direct Project, eHealth Exchange and REST. The Data Segmentation pilots are testing
the approaches outlined in the Reference Implementation Guides to generate clear implementation
guidance for data segmentation workflow.
The following visual summarizes the different workflow activities used to segment patient data:
Figure 6 - Data Segmentation - Conceptual Workflow
This approach to segmentation relies on several responsibilities for the sending system:

Understanding of the information that is restricted/protected


Knowledge of the patient’s consent directive, where required by policy
Ability for an EHR system to apply privacy metadata
The receiving system is also asked to assume several responsibilities:

Ensure that any obligations that are specified by the sending system are followed and persist (
such as purpose of use, prohibition on re-disclosure etc)
How the Exchange of Segmented Patient Data Works
Segmentation is a critical aspect of the technical approach, but is not the only focus. The transport of
segmented patient data in a manner that retains the applied privacy metadata is also crucial. The
technical approach adopted by the S&I Framework Data Segmentation for Privacy initiative is designed
to support different implementation environments where segmented patient data is expected to be
shared. This includes environments called “push”, where a point-to-point exchange occurs, and
environments where a “pull” of the segmented patient data will occur, such as from an HIE.
Push implementations (e.g. using secure email) are based on establishing trust through the use of X.509
digital certificates and then sending a secure email with segmented patient data. In the following
example, a push-based implementation is used to send segmented patient data from a primary care
physician to a specialist. This example shows how XDM metadata is set for non-disclosure of the
information (as an obligation to the receiving system and with a confidentiality code) and the data is
classified as Restricted to allow the receiving system to enforce appropriate obligations defined by law
and by privacy policies defined by reference in the privacy metadata:
Figure 7 - Data Segmentation - Push Approach Example
The Data Segmentation for Privacy Technical Approach also supports the use of XDR metadata. This
allows for segmented patient data to be shared across multiple environments (e.g. a regional HIE, where
a provider may support Direct, but may need to share segmented patient data with an Exchange
partner, such as the Department of Veterans Affairs (VA)). The following visual provides an example of
how this approach would work – privacy metadata is defined using XD* profiles, so that a provider using
the Direct protocol can share privacy obligations and confidentiality codes with a participant on the
NwHIN Exchange:
Figure 8 - Data Segmentation - Combo Example
Finally, there is support for pull implementations, where segmented patient data is made available
through an HIE or other party to a receiving system that has established trust with a sending system. The
pull implementation operates slightly differently than other approaches in that additional metadata,
such as a purpose of use and requested users of the patient data, can be sent by the receiving system
prior to the exchange occurring. This implementation also supports querying for consent directives and
their locations. In this example, similar metadata applies as in the push approach, but additional
metadata is needed to ensure that components such as the HIE Repository and Registry also enforce
obligations and requested purposes.
Figure 9 - Data Segmentation - Pull Based Example