1. The Patient Choice Technical Project Dataset Considerations Candidate Standards Mapping Companion Document April 12 th, 2016

2. Table of Contents 2 TitleSlide Introduction to detailed mapping and approach3 High-Level Findings11 Candidate Standards Examples

3. Introduction to detailed mapping and approach 3

4. Consent Directive Type Scale From “No to All” Patient Choice No consent: Health information of patients is automatically included—patients cannot opt out; Opt-out: Default is for health information of patients to be included automatically, but the patient can opt out completely; Opt-out with exceptions: Default is for health information of patients to be included, but the patient can opt out completely or allow only select data to be included; Opt-in: Default is that no patient health information is included; patients must actively express consent to be included, but if they do so then their information must be all in or all out; and Opt-in with restrictions: Default is that no patient health information is made available, but the patient may allow a subset of select data to be included. Patient Choice: There is no default policy imposed by institution

5. Patient Choice Data Requirements Candidate Standards Spreadsheet Along the Rows - 4 Use Case Data Requirement Tables: Consent Location Query – Find Metadata Consent Location Response – Return Metadata Consent Directive Query – Request Consent Directive Consent Directive – Content of Returned Consent Directive

6. Patient Choice Data Requirements Candidate Standards Spreadsheet Across the Columns: 5 Candidate or Affiliated Standards: BPPC [IHE Basic Patient Privacy Consent] APPC [IHE Advanced Patient Privacy Consent HL7 version 2 Consent Segment [Chapter 9 Medical Records] HL7 Consent Directive CDA Implementation Guide HL7 FHIR Consent Directive profile on Contract Resource

7. Consent Location Query Map 7

8. Consent Location Response Map 8

9. Consent Directive Query Map 9

11. High-Level Findings 11

12. General Points about Findings All more/less support core elements of Consent Directives[CD]: »Patient, PHI Custodian, CD Requester, PHI Requester, PHI, Purpose of Use, Status [active/revoked], restrictions, exceptions, and handling instructions All can be more/less well transformed into the others with some semantic loss All but FHIR [still under development] are used today within the HIT ecosystems for which they were designed However, the boundaries of those ecosystems are rapidly dissolving, which makes inter-standards interoperability increasingly important

13. IHE Basic Patient Privacy Consent [BPPC] High adoption rate by XDS HIEs – but likely little adoption elsewhere because architecturally specific Policies are unstructured legal agreements specific to an Affinity Domain, but may be agreed to for Cross Affinity Domain exchanges BPPC Enforcement includes configuring HIE Actors to comply with Domain Patient Privacy Policy obligations, refrains, purposes of use, authorization restrictions, and display of Privacy Marks However, these Domain Privacy Policies are very terse, unstructured legal rules represented as OIDs »A BPPC Consent Directive may contain 1..* policy OIDs »OIDs are not directly computable or adjudicatable »Implementers assign Access Control Rules by hard-coding policy rules to ACS authorization decision and enforcement mechanisms »Number of discrete policies are limited to reduce permutations on the ACS decision and enforcement requirements

14. IHE Basic Patient Privacy Consent [BPPC]-cont. XD* ebXML Metadata “slots” [aka “fields, elements] are populated with CDA R1 Header data through transform as well as information from local provider and patient directories CDA limits proper modeling – i.e., treated like a clinical episode instead of an agreement Most Document retrievers and disclosers typically do not retrieve a patient’s BPPC »Requesters only check XDS metadata with Patient’s list of Domain patient privacy policy OIDs to make decisions about whether to publish; retrieve; permit access, use, disclosure

15. IHE Basic Patient Privacy Consent [BPPC]-cont. Downside: Metadata is privacy leaking – especially with DIRECT XDR or XDM – »May indicate that patient sees substance abuse provider, admitted to substance abuse facility, or agreed to disclosure of substance abuse information to authorized requester »Requester may not be authorized to see certain metadata »BPPC recommended mitigation is to either segregate metadata or not include in HIE due to limited ability to control access to the metadata »Privacy leaks mitigated by HL7 Data Segmentation for Privacy by constraining XDS and XDR metadata, but that solution has not been adopted for BPPC, APPC, or HL7 Consent Directive CDA

16. IHE Advanced Patient Privacy Consent [APPC] Adoption Status: Under IHE/AHIMA development since late 2015 On IHE BPPC roadmap for sometime Goal is to move to structured/computable patient privacy policies »See IHE/AHIMA APPC Project Overview Jan. 2016IHE/AHIMA APPC Project Overview Jan. 2016 Progress – APPC cochairs are actively involved in FHIR Consent Directive development Upside – With uptake, would improve agility, interoperability of IHE Consent Documents Potential Issues: Entrenched BPPC deployment and difference in exchange patterns and enforcement mechanisms, IHE may not get adoption rate – e.g., lack of uptake for FHIR XD* Document Reference for metadata

17. HL7 Version 2 Consent Segment Adoption rate within and outside of Enterprise is not clear, but v2 isn’t going away as the source of consent information that may be used to populate interoperable Consent Directive standards Currently use is to push Consent Directive related to a Medical Record within an Enterprise as well as the Enterprise “source of truth” for multiple consent flags used in Orders, Admission, and Financial transactions Some HIEs may use as input to generation of CCDAs with appropriate confidentiality codes With transforms, could be used to populate IHE, CDA, and FHIR Consent Directives

18. HL7 V2 ADT Access Restriction Value [AVR]Segment Patient privacy preferences may also collected on admission in the ARV segment along with Confidentiality Code from other segments for Access Control throughout the enterprise, and includes: Action Restriction Action Code: Add/Insert, Delete, Update, No Change Access Restriction Values: Specifies the information to which access is restricted. Access Restriction Reason Code: Used to convey the reason for the restricted access. Special Access Restriction Instructions: Used to specify instructions about the release of information to family and friends.

19. HL7 Consent Directive CDA IG Upside CD policy is encoded so can be computably processed and adjudicated using Rules Engine May include Rules Engine Language representation of policy using XACML, XRML, ODRL, or other Includes Security Labels assigned to Protected Information by Type for: »Confidentiality »Governing Policy »Obligations »Refrains Downside Same XD* metadata privacy leak risks Same BPPC/APPC modeling issues – based on a Clinical Document not an agreement »Clinical ServiceEvent used to record Consent Directive Event with clinician performer Due to commitment to BPPC backward compatibility design principle

20. HL7 Consent Directive CDA IG CDA limitations on representing CD Types CD CDA represents all types as LOINC Codes: »64292-6 Release of information consent »57016-8 Privacy policy acknowledgment Document »57017-6 Privacy policy Organization Document LOINC codes are less specific than ActConsentDirectiveType codes [e.g., Opt-out, Opt-in with restrictions], which should be used instead or in addition to the LOINC codes CD CDA represents CD effective time as the effective time of a Clinical ServiceEvent rather than the effective time of an agreement

21. HL7 FHIR Consent Directive Status – under development for September FHIR Ballot Potential Adopters include DAF and SDC in US, and possible as the structured content for IHE APPC Designed to support BPPC/APPC/v2/CDA Consent Directive data elements in line and/or as Attachments – i.e., backward compatible to other major Consent Directive specifications Attachment can be scanned paper Consent Directive Form and the Legal basis for the ConsentDirective – e.g., a statutory citation [42 CFR Part 2 Confidentiality provisions], a Notice of Privacy Practices, or a BPPC set of Patient Privacy Policies Supports Digital and Wet Signature as well as delegation/countersigning FHIR ConsentDirective.terms enable specification of restriction and exception rules

22. HL7 FHIR Consent Directive FHIR Consent Directive is only one component in the FHIR Privacy Consent Directive Implementation Guide, which is slated to include a FHIR Privacy Consent Questionnaire/Questionnaire Response.FHIR Privacy Consent Directive Implementation Guide A Patient’s FHIR Privacy Consent Questionnaire Response is a Patient Friendly rendering of the choices allowed under a Consent Directive scheme Used to populate the interoperable/computable FHIR Consent Directive, which is what the Access Control Systems use to decide and enforce patient choice May be the right place to capture v2 Consent elements such as use of interpreter and additional information to inform patient consent.

23. HL7 FHIR Consent Directive Unlike other Consent Directive [CD] standards, designed as a Contract rather than a Clinical Statement, which makes affinities to real world concepts about CDs easier to represent, e.g., effective time is directly related to the CD and any CD terms. Makes Provider Organization the Grantee, which is asking the Patient [Grantor] to either consent or acknowledge the Organization’s privacy policy. Easier to specify whether PHI as a whole is the governed by the entire CD, or whether some subset of PHI is governed as a whole or in a CD restriction or exception term.

24. Candidate Standards & Pilots Pilots may be interested in scenarios that involve 1..* Candidate Standards. A HIE may want to use FHIR Consent Directive to carry BPPC elements “in line” and/or as an URI/Attachment. A HIE might demonstrate how v2 Consents are used to populate a CDA Consent Directive, and then how the CDA Consent Directive can be mapped into a FHIR Consent Directive “in line” and/or as an URI/Attachment. FHIR Connectathon participants might simply demonstrate the use of FHIR Consent Directive in a Track [Use Case] that reflects possible implementations.

25. Candidate Standards Examples 25

26. IHE Basic Patient Privacy Consent [BPPC] 26 Graphical representation of consent with wet signature

27. IHE Advanced Patient Privacy Consent [APPC] 27

28. IHE BPPC/APPC/CDA/FHIR + DocumentReference Consent Directive Exchange Interactions 28

29. HL7 CDA Consent Directive 29

30. 30

31. Manage Electronic Privacy Policy (ePolicy)

32. FHIR Consent Directive FHIR ConsentDirective is a profile on FHIR Contract Resource Based on foundational HL7 Privacy and Security ISO 2260 Privilege Management and Access Control Underlying model is more attune to the policy structure of Consent Directives vs. trying to use a Clinical Document structure

33. HL7 FHIR Consent Directive 33

34. HL7 FHIR Consent Directive 34

35. HL7 FHIR Consent Directive 35

36. FHIR BPPC Example FHIR BPCC Example

37. FHIR BPPC Example FHIR BPCC Example

38. Project Contact Information OCPO-ONC LeadJeremy MaxwellJeremy.Maxwell@hhs.gov Project CoordinatorJohnathan Colemanjc@securityrs.com Project ManagerAli KhanAli.Khan@esacinc.com Project SupportTaima GomezTaima.Gomez@esacinc.com Staff SMEKathleen Connorklc@securityrs.com Staff SMEDavid Staggsdrs@securityrs.com 38

39. @ONC_HealthIT@HHSONC Thank you for joining!