Data Segmentation for PrivacyAgenda

All-hands Workgroup Meeting

May 9, 2012

Meeting Etiquette

Remember: If you are not speaking keep your phone on mute

Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call – Hold = Elevator Music = very frustrated speakers and participants

This meeting, like all of our meeting is being recorded– Another reason to keep your phone on mute when not speaking

Feel free to use the “Chat” feature for questions, comments or any items you would like the moderator or participants to know.

NOTE: This meeting is being recorded and will be posted on the Meeting Minutes Wiki page after

the meeting

From S&I Framework to Participants:Hi everyone: remember to keep your phone on mute

Agenda

Topic Time Allotted

General Announcements 5 Minutes

Tiger Team Review 15 Minutes

Privacy Metadata Analysis 60 Minutes

Next Steps/Questions 10 Minutes

HL7 EHR-S Metadata Ballot

• Third item on ballot desktop

• “Comment Only” ballot, due date for comments on May 25th, 2012

• Documents for public comment are in draft form

• Scope of the ballot touches on the 3 P’s: Patient Identification, Provenance, & Privacy

• Seeking input on:

1. Have the correct categories of metadata been captured in the Profile?

2. Have the correct metadata items been identified in the Profile?

3. Does audit data need to be differentiated from metadata?  If so, how?

4. Are these the correct functions and conformance criteria to represent metadata needs and processes?

• Current ballot only contains two documents:

1. Chapter 1 of the Profile - Overview and Conformance Clause

2. Chapter 2 of the Profile - Functions List (in excel format).

Relevant Content:

"The EHR-S Metadata Functional Companion Profile sets a foundation for other profiles to establish realm or domain-specific

language related to metadata, audit data, and its management in EHR-S.  This Profile identifies the system functionality and

conformance criteria for an EHR system to support metadata required for patient demographics, provenance (source and

type of data), and security and privacy in support of health information exchange."

Name Lvl. Ballot Document Signup Close Date Ballot Open Ballot Close HL7 EHR-System Functional Profile for Health Information Exchange Metadata, Release 1 - US Realm

O1 ( 621.3 kb ) May 18, 2012 Apr 25, 2012 May 25, 2012

General Announcements

Pilot Implementation• Forming a RI/Pilot sub-workgroup starting on May 21st

Data Segmentation for PrivacyAll-hands Slides

Consent Management Transactions Tiger Team

Information Interchange Tiger TeamSystem Requirements Tiger Team

May 9, 2012

DS4P Initiative Timeline

Work Accomplished and Next Steps

Work Accomplished• Conducted Implementation Guide walkthrough

Next Steps• Review and finalize tiger team recommendations of data set/data element

analysis• Provide Implementation Guidance in accordance with tiger team

recommendations• Continue review and comment of IG document

Announcements, Recommendations, and Risks

Announcements• CMT and II TT meetings will be Monday, 5/14• SR TT meeting will be Tuesday, 5/15• IG comment and feedback wiki page

Risk/Issues/Dependencies• We need your input, please review the IG document prior to next weeks TT

meetings

Action ItemsDescription Owner Status Due Date Notes

Review and finalize tiger team recommendations of data set/data element analysis

WG

Open 5/14

Still pending

Finalize IG document

WG

Open 5/30

Data Segmentation for PrivacyAll-hands Slides

Privacy Metadata Analysis

May 9, 2012

Privacy Policy Overview

Composite Privacy Policies

– Composite policies are complex, they comprise of several, computable policies

– Privacy metadata used to summarize the relevant base policies:

• Confidentiality level• Information source is a

covered substance abuse treatment

• Consent required for disclosure/re-disclosure

42 CFR Part 2

Consent required for disclosure

Facility = Substance Abuse Treatment

Confidentiality = Restricted

Privacy Metadata Inside CDA

Clinical Document Architecture (CDA) based Documents

– Atomic data objects– Support confidentiality

level in a hierarchical way

• Global – in the header, it applies overall to the document

• Per section – the highest level must apply to the document

CDA Document

Section Section Section

Confidentiality = Restricted

Confidentiality = Restricted

Confidentiality = Restricted

Confidentiality = Normal

Assumptions: - Receiving EHR system can enforce access control to control access to restricted information - Only information receiving organization is authorized to receive is sentRecommendation: - Apply “highest watermark approach” to applying confidentiality code to document - Use HL7 confidentiality code system, CDA subset (N, R, VR)

IHE XUA ++ Metadata

Submission Set Metadata

DocumentEnvelope Metadata

DocumentEnvelope Metadata

DocumentEnvelope Metadata

Select documents to

be sent

Submit documents to

recipient

Confidentiality Code

Specify user, role, purpose,

consent reference

Segment protected

information

Sending 42 CFR protected information

Document Envelope Metadata is the XDSDocumentEntry

Parse XUA Metadata

Parse Document Metadata

XUA ++ Metadata Persist documents and

metadata

Interpret Submission Metadata

Receiving 42 CFR protected information

Submission Set Metadata

DocumentEnvelope Metadata

DocumentEnvelope Metadata

DocumentEnvelope Metadata

Confidentiality Code

Purpose of Use

XUA ++ Metadata

Select documents to

be sent

Submit documents to

recipient

Specify user, role, purpose,

consent reference

Re-disclosure: Sending 42 CFR protected information

Third-party documents

and metadata

Locally created

Submission Set Metadata

Document EnvelopeMetadata

DocumentEnvelope Metadata

DocumentEnvelope Metadata

Third-party author

Segment protected

information

Open Issues

1. Re-disclosure Notification:

- Machine readable and/or human readable?

2. Can the approach presented here satisfy use case requirements if the payload is not a CDA?