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

2. 205/28/2013 Agenda Administrative issues Updated data flow diagram Review of user stories Review gap analysis Review of functional requirements HIE XCA and eHealth Exchange On-Demand Document IHE trial supplement Review of relevant standards Questions POA&M

3. 305/28/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/21/2013 Expected Data Flow (updated) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st Requestor   B ,  = Clinical data A,B = PCD data = audit record And Subsequent Custodian of Data being Provided at 

5. 505/28/2013 Review of User Stories 1.Requestor makes (two-step) request for patient information to a “Custodian of Data” across the eHealth Exchange 2.“Custodian of Data” receives request from eHealth Exchange for patient information, retrieves PCD from PCD repository, applies the PCD when deciding if requested data should be released, and returns status to PCD repository Do we have permission to respond to patient query? Do we have permission to respond to document query? 3.PCD repository receives request for PCD from “Custodian of Data” across the eHealth Exchange, returns PCD, and accepts status from AC decision Are we passing the minimum required information in PCD? 4.Stretch: transmitting location of PCD in the returned clinical data

6. Gap Analysis Initial gap analysis for discussion: 1.Single PCD can apply to multiple requests (filter PCD?) 2.Discovered XDS.b issues (XUA “participant” issue) 3.Interoperability of current PCD (HL7 PCD structure) 4.Interoperability of current PCD (XACML payload) 5.Gaps in PCD vocabulary (supporting granularity) 6.Returning repository location in the clinical data (extension) 7.Mapping ATNA protocol to use case (sufficient for user story?) Newly added issues: 8.More attributes are required in request to PCD repository 9.XCPD caching issue can result in wrong attributes ‡ 10.Some attributes are missing or conflated 05/28/20136

7. 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 (NwHIN) 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] * = non-normative 05/28/20137

8. 8 NHIN HIE XCA 05/28/2013 NHIN Query for Documents Web Service Interface Specification XCA Cross Gateway Query transaction [ITI-38] as the protocol for query for documents NHIN Retrieve Documents Web Service Interface Specification XCA Cross Gateway Retrieve transaction [ITI-39] as the protocol for retrieving documents

9. 9 On-Demand Documents (ODD) NHIN Documents: NHIN Query for Documents Web Service Interface Specification “NHIN has adopted the use of On-Demand Documents as specified in the On-Demand Documents Supplement.” On-Demand Documents Supplement (August 19, 2011) Supplement to IHE IT Infrastructure Technical Framework V7.0 Updates XCA to use dynamically created documents Allows registration of content dynamically assembled in a document Appropriate for documents containing dynamic data Can be generated from a single source 05/28/2013

10. 10 ODD Overview On-Demand Documents XDS profile: On-Demand Document Source Actor registers an On-Demand Document Entry with the XDS Document Registry Document Consumer queries (metadata) to the Document Registry requesting that On-Demand Document Entries On-Demand Document Source uses the metadata to formulate the document and return On-Demand Document Source may choose to register the document created 05/28/2013

11. 11 ODD and XCA On-Demand Documents XCA profile: Query and Retrieve are mediated through a Responding Gateway Responding Gateway requires no additional processing Workflow Initiating Gateway queries a Responding Gateway requesting On-Demand Document Entries The Responding Gateway returns On-Demand Document Entries for the patient identified in the query Initiating Gateway uses the metadata from the On-Demand Document Entry to request the most recent content Responding Gateway searches its clinical database for content of the type defined by the On-Demand Document Entry, formulates this into a document, and returns the document 05/28/2013

12. 12 ODD Message Semantics On-Demand Documents XDS metadata changes: creationTime – Not Applicable, shall not be specified in a Register On-Demand Document Entry request Hash – Not Applicable, shall not be specified in a Register On- Demand Document Entry Request legalAuthenticator – Recommend this not be specified - no clear meaning in the context of an On-Demand Document Entry. repositoryUniqueId – Globally unique identifier of the On-Demand Document Source which provides the on-demand document. Size – Not Applicable, shall not be specified in a Register On- Demand Document Entry Request uniqueId – The globally unique identifier assigned by the On- Demand Document Source to this On-Demand Document Entry 05/28/2013

13. 13 ODD Details Cross-Enterprise Document Sharing (XDS.b) diagram (p. 7) 05/28/2013

14. 14 Relevant Standards Standards from last week’s discussion: XCA and/or XDS.b (IHE) XUA (IHE) – IHE profile includes SAML (OASIS) XCPD (IHE) – not fully integrated into DS4P IG ATNA (IHE) – for returned audit record of the release decision CDA r2 (HL7) – for PCD location in released clinical document – for format of the directive (includes XACML) XACML (OASIS) – specifically to PCD NwHIN specification OOD (IHE) - On-Demand Documents (Trial) Supplement Note: PCD (HL7) – just updated last WGM, will re-ballot 05/28/2013

15. DS4P Standards Material Location of DS4P Standards Inventory: http://wiki.siframework.org/Data+Segmentation+-+Standards+Inventory Location of DS4P Standards Mapping Issues: http://wiki.siframework.org/file/view/Copy%20of%20DataMappingsIssues%20051 02012.xlsx/333681710/Copy%20of%20DataMappingsIssues%2005102012.xlsx General Standards Source List: http://wiki.siframework.org/file/view/General%20SI%20Framework%20Standards %20Analysis.xlsx/297940330/General%20SI%20Framework%20Standards%20A nalysis.xlsx Standards Crosswalk Analysis http://wiki.siframework.org/Data+Segmentation+for+Privacy+Standards+and+Har monizationhttp://wiki.siframework.org/Data+Segmentation+for+Privacy+Standards+and+Har monization (at bottom of page, exportable) Implementation Guidance http://wiki.siframework.org/file/view/Data%20Segmentation%20Implementation% 20Guidance_consensus_v1_0_4.pdf/416474106/Data%20Segmentation%20Impl ementation%20Guidance_consensus_v1_0_4.pdf 05/28/201315

16. Query and Response for Location 05/28/201316

17. Query and Response PCD 1705/28/2013

18. 1805/28/2013 Questions? For example: Must we broadcast to everyone on eHealth Exchange for a PCD? Can we retrieve PCD from a patient’s PCD repository if we have that information?

19. 19 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 any 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/28/2013

20. 2005/28/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

21. 2105/28/2013 Backup Slides

22. 2205/21/2013 Expected Data Flow (updated) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st Requestor   B ,  = Clinical data A,B = PCD data = audit record And Subsequent Custodian of Data being Provided at 

23. 2305/28/2013 Expected Data Flow (updated) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st Requestor Clinical exchange #  Clinical exchange #  B ,  = Clinical data A,B = PCD data = audit record And Subsequent Custodian of Data being Provided at  Fetch PCD Send audit

24. 2405/25/2013 Expected Data Flow (1) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st Requestor  ,  = Clinical data A,B = PCD data = audit record

25. 2505/25/2013 Expected Data Flow (2) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st Requestor  ,  = Clinical data A,B = PCD data = audit record

26. 2605/25/2013 Expected Data Flow (3) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st Requestor  B ,  = Clinical data A,B = PCD data = audit record And Subsequent Custodian of Data being Provided at 

27. 2705/25/2013 Expected Data Flow (4) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st Requestor  ,  = Clinical data A,B = PCD data = audit record And Subsequent Custodian of Data being Provided at 

28. 2805/25/2013 Expected Data Flow (5) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st Requestor ,  = Clinical data A,B = PCD data = audit record And Subsequent Custodian of Data being Provided at 

29. 2905/21/2013 Expected Data Flow (updated) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st Requestor   B ,  = Clinical data A,B = PCD data = audit record And Subsequent Custodian of Data being Provided at 

30. 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/14/201330

31. 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/14/201331

32. 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/14/201332

33. 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/14/201333

34. 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/14/201334

35. 35 SAML Attributes Attribute set presented in an eHealth Exchange document query: Contained in SAML envelope included in the XUA profile are: 1. Subject ID 2. Subject Organization 3. Subject Role 4. Purpose Of Use 5. Home Community ID 6. Organization ID 7. Resource ID (Optional) 8. National Provider Identifier (Optional) NHIN Authorization Framework Specification v 3.0 p. 19 05/28/2013

36. Formal SAML Attributes 05/28/201336 Attribute ElementDescription xacml:1.0:subject:subject-idperson making the request xspa:1.0:subject:organizationname of organization xacml:2.0:subject:rolerole of the requester xspa:1.0:subject:purposeofusereason for the request nhin:names:saml:homeCommunityIdassigned unique NHIO value xspa:1.0:subject:organization-idunique ID of the organization xacml:1.0:resource:resource-idunique patient identifier xspa:2.0:subject:npi (optional)CMS 10-digit identification number Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of Security Assertion Markup Language (SAML) for Healthcare V. 1.0 p. 13

37. 37 Map and Gap Policy Attributes 05/28/2013 AttributeSourceDescription subject-idXUA (SAML)person making the request organizationXUA (SAML)name of organization roleXUA (SAML)role of the requester purposeofuseXUA (SAML)reason for the request patient-idXCPDde-conflicts use of resource-id (new) action-idN/Apolicy targeting feature localityConfiguredhomeCommunityId NHIO value typeXCA (XDS.b)LOINC code for requested document confidentiality-codeXCA (XDS.b)confidentiality-code of document

38. 38 Clinical Data Exchange Requestor makes (two-step) request for patient information to a “Custodian of Data” across the eHealth Exchange Patient Discovery NHIN Patient Discovery Web Service Interface Specification Document Query NHIN Query for Documents Web Service Interface Specification Review standards to identify attributes required to meet goals: Do we have permission to respond to patient query? Do we have permission to respond to document query? 05/28/2013

39. 39 Clinical Data Exchange Goal Attributes required to meet goals: Do we have permission to respond to patient query? Do we have permission to respond to document query? What are the attributes required to retrieve patient consent directive: patient-id: If multiple resource profile is required need to replace use of resource-id action-id: if policy targeting required need new attribute locality: specify locality in PCD type: specify type of document in PCD confidentiality-code: specify confidentiality tag in PCD 05/28/2013

40. 40 PCD Exchange Impacts due to use of XCPD query Specification allows cached XCPD queries for documents Multiple requesters can use the same XCPD query How does that effect the requester role and identifiers? Variety of XCPD Attributes Do we have enough to allow properly formed PCD Do we meet our goal with attributes: Are we passing the minimum required information in PCD? Attributes are required to return the properly scoped PCD –purposeofuse, organization, patient-id, action-id –Does this goal conflict with XCPD? (next slide) 05/28/2013

41. 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/14/201341

42. Potential Gap 2 Discovered XDS.b issues: Participant 05/14/201342 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

43. Potential Gap 2 (cont.) 3.42.2 Use Case Roles 05/14/201343 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.

44. Informative Note: PCDs 05/14/201344 PCD Format PCD Header PCD Body Structure of the PCD

45. 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/14/201345

46. 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 semantic interoperability and correct decisions made on passed attributes No known XACML profile for PCD repository exchange of a PCD with XACML in payload 05/14/201346

47. 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/14/201347

48. 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/14/201348

49. 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/14/201349

50. 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/14/201350

51. 5105/14/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.

52. 5205/14/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

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