1

Data Segmentation for Privacy Summary

Process of segmentation and exchange of privacy policy protected information across

provider organizations

2

Summary

Based on federal (and state) privacy policy• Substance abuse treatment facility (42CFR Part2)• Substance Abuse related problems (Title 38)• Self-pay

– Identified encounters where the services were “out-of—pocket”, explicit opt-in require

Translates the patient privacy preference into computable rules

Identifies the sensitive information using explicit

3

Project Need References

Data Segmentation for Privacy Project documents referenced in this IG are available on the DS4P Project Wiki• Data Segmentation for Privacy Project specified

the requirements for this Implementation Guide in the Use Case Document

Detailed description of the project: S&I Initiative DS4P Project Executive Summary

4

Data Segmentation for Privacy (DS4P) Project

Privacy Annotation Building Blocks• Interoperability standard neutral representation of metadata

required to support privacy policies for Interoperability standard specific building blocks (CDA templates)

• Privacy Annotations• Provenance specified as mandatory information

– Entry-level provenance mandatory if different than the header-specified provenance

Transport-specific building blocks for IHE XD* and Direct protocols• Metadata in addition to the “confidentialityCode” specifying

the purpose of the data and receiver responsibilities

5

1) CDA Content Profile

CDA R2 and Privacy Metadata Reusable Content Profile (HL7_IG_DS4P_R1_CH1_CONTENT)• document template, clinical statements templates,

and reusable building blocks for the transport specifications.

• This document introduces the requirements and the technical approach to addressing unmet needs

6

Templates: Clarify the use of Provenance

7

Templates: Clarify the use of Provenance

Section

Entry

Privacy Annotation

Section

Document

DocumentProvenance

EntryProvenance

8

Templates: Privacy Annotation

9

Templates: Reuse in Privacy Marking Section

Section

Privacy Marking

Privacy Annotation

10

2) Transport Specifications

Two Transport Profiles containing transport specific constraints based on the reusable building blocks.• constraints represented in the reusable building

blocks are applied to the transport-specific metadata (e.g. Document Sharing Metadata/XDS Metadata, XDM Metadata used by Direct) intended for implementation (e.g.SOAP. NwHIN Direct, REST).

• two transport specification profiles are available to implementers for use in the US

11

NwHIN Transport Specifications

NwHIN Direct Transport Profile, Release 1, January 2014 Normative Ballot• Unique Ballot ID:

HL7_IG_DS4P_R1_CH2_DIRECT_N2_2014JAN NwHIN Exchange Transport Profile, Release 1,

January 2014 Normative Ballot• Unique Ballot ID:

HL7_IG_DS4P_R1_CH3_EXCHANGE_N2_2014JAN

12

Implementation-neutral Privacy Annotation Building Blocks

Confidentiality Code – the only existing privacy annotation in CDA and IHE protocols, constrained to avoid disclosure of sensitive information

Obligation Policy Code – encoded using standard HL7 value set, specifies receiver responsibilities (e.g. encrypt, comply with disclosure consent)

Purpose of Use Code – added to the disclosed data set, specifies the purpose of the disclosed data (e.g. treatment)

Refrain Policy Code – encoded using standard HL7 value set, specifies receiver responsibilities (e.g. no redisclosure)

Value Set Binding

Value Set Binding Value Set Binding

Value Set Binding

13

Building Blocks implementation

Document Exchange Metadta (aka XDS)• Reuses the DocumentEntry.confidentialityCode

classification object– Mandatory according ot IHE ITI TF Vol.3, first occurrence

ConfidentialityCode, constrained value set bindings– Additional, one ore more occurrences of Purpose of Use,

constrained value set bindings– Additional, zero or more occurrences of Refrain Policy ,

constrained value set bindings – Additional, zero or more occurrences of Obligation Policy, ,

constrained value set bindings

14

Additional Constraints Applied to Document Exchange Metadata

Constrain the coded values allowed for DocumentEntry metadata to avoid disclosure of protected information (e.g. substance abuse treatment facility)• DocumentEntry.practiceSettingCode (SNOMED-CT)• DocumentEntry.healthcareFacilityTypeCode (SNOMED-CT)• DocumentEntry.typeCode (LOINC)

Constrain the use of sender intended recipient to allow for digital certificates based on email address• For those projects like NwHIN and Direct where the • SubmissionSet.intendedRecipient

15

HL7 DS4P Project Requirements

DS4P S&I Framework Initiative developed user scenarios for organizations exchanging medical records • Share All• Share Partial• Query/response vs. Push• Emergency/Break the glass

Additional requirements developed by the pilot implementers of the DSP Implementation Guide developed by ONC S&I Framework Initiative

16

HL7 DS4P Ballot Structure

DS4P Content• Building blocks• CDA Templates• Generic transport-related constraints

– Provenance and Receiver details– Privacy Metadata

» Constraints to existing metadata (value set constraints) Transport specific XDS Metadata constraints

• IHE XDR, XDS, etc.• IHE XDM (email)

CDAR2_IG_DS4P_CONTENT_R1_N2_2014JAN

CDAR2_IG_DS4P_EXCHANGE_R1_N2_2014JAN

CDAR2_IG_DS4P_DIRECT_R1_N2_2014JAN

17

Privacy Annotation Building Blocks

Encoded metadata• Terminology based on the HL7 Healthcare

Classification Scheme (HCS) specification– Obligation– Refrain– Purpose of Use– Confidentiality Level (confidentialityCode)

Based on the “Security Label” consisting of multiple privacy-related metadata elements

18

Privacy Policies and Interoperability

Privacy Policies are typically composites of simple, basic

policies Composite privacy policies (e.g. 42CFR

Part)comprise of several basic, computable data sharing policies

Privacy metadata used to represent simple data sharing policies:

– Confidentiality level– Purpose of use/disclosure– Information source is a covered substance abuse

treatment– Consent required for disclosure/re-disclosure

• Privacy metadata allows loosely-coupled systems and organization to exchange the most meaningful metadata related to the data shared among systems/organizations

Information exchanged may reference basic data sharing policies as privacy metadata

• Confidentiality Code = restricted• Purpose of Use Code[1] = treatment• Purpose of Use Code[1] = treatment• Refrain Policy Code[1] = no redisclosure without consent

42 CFR Part 2

Purpose = Treatmen

t

Refrain= No re-

disclosure without consent

Confidentiality =

Restricted

Basic Data

Sharing Policy

Basic Data Sharing Policy

Composite Privacy Policy

19

Privacy Metadata used in Information Exchange to specify simple data exchange policies across

organizations

For treatment purpose

No re-disclosure

Restricted

Summary Document/

Message

Transport Metadata

Patient Data

Section

Section

Section

20

Provenance Metadata - XML structure for items authored by a person

Author• Date/time• Organization• Provider name/title

Date/time

Provider Address

Provider Name

Provider Organization

21

Provenance Metadata - XML structure for items authored by a device

Authoring device• Date/time• Organization• Device type/id

Date/time

Device Id

Provider Organization

Device Details

22

Provenance Metadata – Rendered to users as HTML

Document Author• Date/time• Organization• Provider name/title

23

Author specified at the clinical statement level – e.g. problem

Authoring Date

Author Name

Provider Organization

• The author information may be displayed along with each problem• The author may be specified for the section

Section author

24

Auth

or sp

ecifi

ed a

t the

clin

ical

st

atem

ent l

evel

– e

.g. p

robl

em

25

Next steps for implementers..

To ensure that the data provenance requirements for exchange and persistence are met:• EHR system that send/disclose patient information

using standard C-CDA document should or must include the author for each data element

• EHR systems that receive this information must persist the provenance information (along with the privacy metadata)

– The EHR system may not display the author unless the user needs it

26

Privacy-Segmented C-CDA Document Structure – Provenance

Document Provenance- Specifies the author for all the content of the document in the header (e.g. an organization, clinician,or device). Already mandatory.

Entry ProvenanceMandatory if the entry is authored by a differentmore specific (e.g. a specific clinician in theorganization identified in the header)

27

Privacy-Segmented C-CDA Document-2

Privacy Segmented Section

- Specifies global metadata - Text describing prohibitions on redisclosure to the reader-Any C-CDA section may be privacy-segmented

Privacy Marking Entry

- Include PrivacyAnnotations to specify receiver responsibilities

28

Data Provenance in C-CDA

Typically only the CDA document header specifies the provenance of the entire document

If a summary document contains data authored by more than one person, organization, or device the “MandatoryProvenanceTemplate” could be used

29

Part of the “XDSDocumentEntry” are additional privacy metadata based on the DS4P building blocks

Cross-Enterprise Document Sharing Metadata includes metadata for DS4P

contains

30

Indicating receiver responsibilities – including HIE responsibilities

Cross-Enterprise Document Sharing Metadata: Obligation and Refrain Policy

contains

31

Specifies purpose of use of the data in the XD* metadata used for IHE document exchange protocols

Consistent with the SecurityObservation and ebXML

Purpose of Use Metadata in the XDS Metadata

32

Specifies receiver responsibilities in the XD* metadata used for IHE document exchange protocols

Consistent with the SecurityObservation and ebXML

Refrain Policy Metadata in the XDS Metadata

33

Specifies receiver responsibilities in the XD* metadata used for IHE document exchange protocols

Consistent with the SecurityObservation and ebXML

Obligation Policy Metadata in the XD* metadata

34

PrivacyAnnotation Template

Based on HCS and new terminology/value set specifications

Specifies a choice of privacy annotations consistent with the PCAST Health IT report (Dec. 2010)

Constrained specifically to meet the use cases identified by the S&I Framework Initiative• Building blocks

Confidentiality Obligation Policy Code Refrain Policy Code Purpose of Use

35

Privacy annotations may be associated with an entry in the (e.g. Privacy Markings entry) that reuses the PrivacyAnnotation template to specify confidentiality, receiver responsibilities (e.g. “redisclosure prohibited without consent”)

Applying Privacy Annotations to an Entry

36

Example: Applying Privacy Annotations to a Protected Problem

A protected problem may have specify privacy annotations (e.g. confidentiality level, added obligations, added refrains, and a specific purpose of use)

If the author differs from that specified in the header, the mandatory author information provides provenance details

37

Privacy across the NwHIN

C-CDA

C-CDA NwHIN Gateway

C-CDA

- Added privacy annotation

C-CDA

38

Project Change Management and Maintenance

Change Management using HL7 GForge• SVN source control

– CBCC Project to check in the MDHT Project containing the project constraints. It is also the home of the Consent Directive IG.

– Security Project to maintain domain analysis, use cases, etc. It is the home of the harmonized Security and Privacy DAM

» Any IHE, OASIS, etc. change requests also to be maintained here.

39

Security Modeling Projects