1. Data Segmentation for Privacy Agenda All-hands Workgroup Meeting May 9, 2012

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

3. Agenda TopicTime Allotted General Announcements5 Minutes Tiger Team Review15 Minutes Privacy Metadata Analysis60 Minutes Next Steps/Questions10 Minutes

4. HL7 EHR-S Metadata Ballot Third item on ballot desktopballot desktop “Comment Only” ballot, due date for comments on May 25 th, 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." NameLvl.Ballot DocumentSignup Close Date Ballot OpenBallot Close HL7 EHR-System Functional Profile for Health Information Exchange Metadata, Release 1 - US Realm O1 ( 621.3 kb ) May 18, 2012Apr 25, 2012May 25, 2012

5. General Announcements Pilot Implementation Forming a RI/Pilot sub-workgroup starting on May 21st

6. Data Segmentation for Privacy All-hands Slides Consent Management Transactions Tiger Team Information Interchange Tiger Team System Requirements Tiger Team May 9, 2012

7. DS4P Initiative Timeline

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

9. 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 pagewiki Risk/Issues/Dependencies We need your input, please review the IG document prior to next weeks TT meetings

10. Action Items DescriptionOwnerStatusDue DateNotes Review and finalize tiger team recommendations of data set/data element analysis WG Open5/14 Still pending Finalize IG document WG Open5/30

11. Data Segmentation for Privacy All-hands Slides Privacy Metadata Analysis May 9, 2012

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

13. 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 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 sent Recommendation: - Apply “highest watermark approach” to applying confidentiality code to document - Use HL7 confidentiality code system, CDA subset (N, R, VR)

14. IHE XUA ++ Metadata Submission Set Metadata Document Envelope 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

15. Parse XUA Metadata Parse Document Metadata XUA ++ Metadata Persist documents and metadata Interpret Submission Metadata Receiving 42 CFR protected information Submission Set Metadata Document Envelope Metadata Confidentiality Code Purpose of Use

16. 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 Envelope Metadata Document Envelope Metadata Document Envelope Metadata Document Envelope Metadata Document Envelope Metadata Third-party author Segment protected information

17. Author /Submitter Content Type Code Entry UUID Intended Recipient Patient Id Source Id Submission Time Title/Subject Set Unique Id Author Class Code (document type) Confidentiality Code Obligation[s] Creation Time Entry UUID Format Code Healthcare Facility Type Code Language Code Mime Type Patient Id Practice Setting Code Source Patient Id Source Patient Info Type Code Document Unique Id Document Envelope Metadata Author Class Code (document type) Confidentiality Code Obligation[s] Creation Time Entry UUID Format Code Healthcare Facility Type Code Language Code Mime Type Patient Id Practice Setting Code Source Patient Id Source Patient Info Type Code Document Unique Id Document Envelope Metadata Submission Set Metadata Confidentiality = Restricted Disclosure requires consent Substance abuse treatment Discharge summary Encrypted Envelope Metadata Hashed Submission Set Metadata

19. Subject-role Authz-Consent Purpose Of Use Subject Id Subject Org NPI Home Community Id Subject-role Authz-Consent Purpose Of Use Subject Id Subject Org NPI Home Community Id Author /Submitter Content Type Code Entry UUID Intended Recipient Patient Id Source Id Submission Time Title/Subject Set Unique Id Author Class Code (document type) Confidentiality Code Obligation[s] Creation Time Entry UUID Format Code Healthcare Facility Type Code Language Code Mime Type Patient Id Practice Setting Code Source Patient Id Source Patient Info Type Code Document Unique Id Document Envelope Metadata Author Class Code (document type) Confidentiality Code Obligation[s] Creation Time Entry UUID Format Code Healthcare Facility Type Code Language Code Mime Type Patient Id Practice Setting Code Source Patient Id Source Patient Info Type Code Document Unique Id Document Envelope Metadata Submission Set Metadata XUA++ Metadata Reference to Privacy Consent

21. 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?