1. “ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review May 7, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation

2. 205/07/2013 Agenda Administrative issues Review and discussion of user stories Review and discuss functional requirements –Precondition functional requirements –Functional requirements –Post-condition functional requirements –System requirements (for demonstration capability) Initial Gap Analysis (7 issues for discussion) Questions POA&M first draft of functional requirements Call for new members

3. 305/07/2013 Pilot Administrivia This pilot is a community led pilot –Limited support provided by the ONC Apurva Dharia (ESAC) Jeanne Burton (Security Risk Solutions) Melissa Springer (HHS) In conjunction with DS4P bi-weekly return of an All Hands meeting Access to DS4P Wiki, teleconference, and calendar Meeting times: Tuesdays 11AM (ET) –Dial In: +1-650-479-3208 Access code: 662 197 169 URL: https://siframework1.webex.com/siframework1/onstage/g.php?t=a& d=662197169 https://siframework1.webex.com/siframework1/onstage/g.php?t=a& d=662197169

4. 405/07/2013 Review of User Stories 1.Requestor makes request to a provider for patient data on eHealth Exchange 2.Provider receives request from eHealth Exchange for patient information, retrieves PCD from PCD repository and applies, returns status to PCD repository 3.PCD repository receives request for PCD from eHealth Exchange partner, returns PCD, accepts status from AC decision 4.PCD repository receives request for new account from healthcare consumer, possibly involving providers 5.PCD repository allows management of PCD from healthcare consumer 6.Healthcare consumer manages PCD from PCD repository account, views AC status reports

5. Functional Requirements Summary Precondition Functional Requirements –Document format for establishing authentication exchange –Document format for exchange of repository account holder and HIO identifiers? (in proxy) –Document format for clinical data request Functional Requirements –Document format for requesting consent directive –Document format for returning consent directive –Document format for sending result of decision to consent directive repository Post-Condition Functional Requirements –Document format for exchange of repository location and account holder identifier to 2nd requestors associated with data [based on DS4P IG UC 3 as discussed 30APR2013] 05/07/20135

6. Precondition Functional Reqs. Document format for establishing authentication exchange? –No related requirements Document format for exchange of Consent Repository Account Holder and HIO identifiers? (in proxy) –The PCD Repository must create a unique identifier for the patient that may be used by providers to request the consent directive. –The PCD Repository must maintain a mapping of patient identifiers when a patient strongly authenticates with a provider. Document format for clinical data request –Use NwHIN Exchange format 05/07/20136

7. Functional Requirements Document format for request to consent directive, including specifying patient /account number and consent directive repository –Request must include POU, Repository ID, Requestor Document format for returning consent directive, including specifying patient HIO identifier –PCD encoded in HL7 Consent Directive format –If no match to parameter (e.g. requestor, POU) no PCD returned –If no PCD returned may use default based on local policy –If PCD returned must be used in deciding release decision –PCD computable in a portable and standards-compliant manner –PCD returned must have only information intended for requestor –PCD returned must support of organization and/or provider ids –PCD returned must support purpose of use and sensitivity codes 05/07/20137

8. Functional Requirements (cont.) Document format for sending result of release decision to consent directive repository, including detail appropriate for patient –Patient identifier for the provider –Patient identifier for the requestor –Patient identifier for the repository –Purpose of use for the request –Resource requested –Provider community id –Requestor community id –Requestor identifier (email, NPI, name) –Release decision (permit / deny) –Basis for the decision (jurisdictional policy, patient consent, etc.) Review ATNA for usability 05/07/20138

9. Post Condition Functional Reqs. Document format for exchange PCD information to 2nd requestors associated with data exchanged with 1st requester (provenance) –Use HL7 format consistent with clinical data returned –PCD repository location and account holder identifier 05/07/20139

10. System Functional Reqs. Functional requirements recorded for use in demonstration (non-normative) –PCD repository must index the audit logs received so that patients may view, filter, and search on the access attempts –PCD repository receives request for new account from healthcare consumer, possibly involving providers –PCD repository must maintain account credentials for the patient –PCD repository must maintain a mapping of patient identifiers when a patient strongly authenticates with a provider –PCD repository allows management of PCD from healthcare consumer –Healthcare consumer manages PCD from PCD repository account, views response decision status reports –PCD repository must support creating, updating, and deleting consents –PCD repository must support Opt In/Opt Out/Opt In With Restrictions/Opt-Out with Exceptions 05/07/201310

11. Initial Gap Analysis Initial gap analysis for discussion: 1.Single PCD can apply to multiple requests 2.Discovered XDS.b issues 3.Interoperability of current PCD (PCD structure) 4.Interoperability of current PCD (XACML) 5.Gaps in PCD vocabulary 6.Returning repository location in the clinical data 7.Mapping ATNA protocol to use case Guidance available in§17 Dataset Considerations discussion of “Data Segmentation for Privacy Initiative: Use Case Development and Functional Requirements for Interoperability Data Segmentation for Privacy Use Case” (3/12/2012) and “Data Segmentation Implementation Guidance” v. 1.0.4 (3/20/2012). 05/07/201311

12. Potential Gap 1 Single PCD can apply to multiple requests –Consider opt-in, opt-opt, opt-in with restrictions, opt-opt with exceptions What should happen if requester can not support level of granularity –Consider opt-opt with exceptions If consumer lists, e.g., mental health clinic and general practitioner, passing the exception list conveys too much information –Multiple PCDs infeasible; create on the fly based on request? 05/07/201312

13. Potential Gap 2 Discovered XDS.b issues: Participant 05/07/201313 CDA Component within Consent Directive CDA Consent Directive Implementation Guidelines and Conformance Criteria CardinalityOptionality structuredBodyEvery CDA Consent Directive MUST define a structured body that represents the patient consent in a machine- readable format. 1Required Consent Directive Details InformantRefer to section 3.2.1.1 – Consent Directive Entry in the HL7 CDA Consent Directive DSTU. This implementation guide adopts CONF-CD-19 as conformance criteria for this section of the consent directive. 1Required ParticipantRefer to section 3.2.1.1 – Consent Directive Entry in the HL7 CDA Consent Directive DSTU. This implementation guide adopts CONF-CD-20, CONF-CD- 21, CONF-CD-22, and CONF-CD-23 as conformance criteria for this section of the consent directive. The role code that is used in this section MUST be the same as the role code used in the IHE XUA++. 1..NRequired From: “Data Segmentation Implementation Guidance” v. 1.0.4 (3/20/2012), p. 48

14. Potential Gap 2 (cont.) 3.42.2 Use Case Roles 05/07/201314 Actor: Document Repository or Integrated Document Source/Repository Role: A document storage system that submits document metadata to a Document Registry. Actor: Document Registry Role: A document indexing system that receives and stores document metadata. From: Rev. 9.0 Final Text – 2012-08-31 146 Copyright © 2012 IHE International, Inc.

15. Informative Note: PCDs 05/07/201315 PCD Format PCD Header PCD Body Structure of the PCD

16. Potential Gap 3 Interoperability of current PCD (PCD structure) –Large amount of metadata included in the HL7 PCD Specification includes many optional elements that might affect the ability to accept different PCD implementations No known Schematron available –Possibly too ambiguous to be interoperable –Currently in ballot at HL7 Working Group Meeting (WGM) We have provided comments 05/07/201316

17. Potential Gap 4 Interoperability of current PCD (XACML) –XACML can be included in the HL7 PCD eXtensible Access Control Markup Language is well-defined and interoperable Vocabulary must be agreed upon for synaptic interoperability and correct decisions made on passed attributes No known XACML profile for PCD repository exchange of a PCD with XACML in payload 05/07/201317

18. Potential Gap 5 Gaps in PCD vocabulary –PCD must support the four possible consent models DS4P profile must define semantics of: –opt-in, –opt-opt, –opt-in with restrictions, –opt-opt with exceptions 05/07/201318

19. Potential Gap 6 Returning repository location in the clinical data –Patient discovery queries are in addition to registration with specific providers through, e.g. a repository serving as a proxy –Special considerations for use of ATNA 05/07/201319

20. Potential Gap 6 (cont.) Should the provider query the PCD repository to decide if they can respond to the patient discovery queries Subsequently the provider must query the PCD repository to decide if the request for release of patient’s EHR will be allowed –When data is exchanged with the requester, either the ATNA endpoint or the PCD repository location and account identifier be included in the clinical document –CDA header example (ATNA endpoint): Explore encoding ATNA audit endpoint information in the CDA information 05/07/201320

21. Potential Gap 7 Mapping ATNA protocol to use case –ATNA protocol is based on syslog and consists of an XML payload Does the ATNA schema has the required data for our use case for directly interfacing with requesters: 05/07/201321

22. 2205/07/2013 Questions? For example: Do we have to use ATNA? Can we use the repository to field requests for PCD instead of using ATNA directly?

23. 23 Plan of Action Upon agreement of the participants the POA is Identify the elements available from previous DS4P pilots Scope level of effort, decide on extended scenario Determine first draft of functional requirements Review standards available for returning information on requests Determine gaps or extensions required in standards Create XDS.b repository holding PCD Stand up information holders and requestors Identify remaining pieces Document and update IG with results of our experience 05/07/2013

24. 24 Call for Pilot Team Members 05/07/2013 NameRoleOrganization David StaggsParticipantJericho Systems Corporation Michael FieldParticipantUT Austin HIT Lab

25. 2505/07/2013 DS4P References Use Case: http://wiki.siframework.org/Data+Segmentation+for+Privacy+Use+C ases http://wiki.siframework.org/Data+Segmentation+for+Privacy+Use+C ases Implementation Guide: http://wiki.siframework.org/Data+Segmentation+for+Privacy+IG+Co nsensus http://wiki.siframework.org/Data+Segmentation+for+Privacy+IG+Co nsensus Pilots Wiki Page: http://wiki.siframework.org/Data+Segmentation+for+Privacy+RI+and +Pilots+Sub-Workgroup http://wiki.siframework.org/Data+Segmentation+for+Privacy+RI+and +Pilots+Sub-Workgroup

26. 2605/07/2013 Backup Slides

27. 2705/07/2013 Expected Data Flow Patient’s Provider Patient PCD Repository 2 nd Requestor Requestor   B ,  = Clinical data A,B = PCD data = reporting

28. 2805/07/2013 Scope of the Pilot 1. Define the exchange of HL7 CDA-compliant PCD between a PCD repository and a provider evaluating that includes a report on the outcome of the request back to the healthcare consumer. 2. Additional goal: use of identifiers that can uniquely identify the healthcare consumer and PCD repository used to report the outcome of the request back to the healthcare consumer by healthcare consumer’s provider and subsequent EHR custodians. 3. Stretch goal: use of the PCD repository as a proxy allowing direct authentication by the healthcare consumer to the provider, subsequently reducing correlation errors.

29. 2905/07/2013 Secondary Goals of the Pilot Exchange and enforce privacy metadata to ensure proper policy- based disclosure and redisclosure of PHI Accept and display reports from information owners on access control decisions for requests for the patient’s PHI Create a token passing scheme that facilitates secondary use reporting Demonstrate dynamic reporting of access to a patient’s PHI and their ability to change their PCD using their PCD central repository

30. 3005/07/2013 Available Roles Holder of PHI that is participating on the eHealth Exchange –Accepts eHealth Exchange compliant request –Retrieves PCD and reports result of request –Synthetic Patient Data is Available Requester of PHI that is participating on the eHealth Exchange –Makes eHealth Exchange compliant request Repository holding subject’s Patient Consent Directive (PCD) –Transmits PCD to trusted eHealth Exchange requesters –Accepts policy created by subject of shared PHI –Passes HL7-compliant PCD –Displays result of the request transmitted from holder of PHI