“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review June 11, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation

206/11/2013 Agenda Administrative issues Updated data flow diagram Functional requirements summary Timeline J-UT Pilot Infrastructure CONNECT 4.1 Demonstration Related Topics Review of relevant standards Questions POA&M

306/11/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: Access code: URL: d= d=

406/11/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 

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 06/11/20135

6 Timeline General Timeline, conditioned on agreement of stakeholders MilestoneTarget DateResponsible Party Kick off and LogisticsApril 2013Jericho Systems Basic InfrastructureJune 2013Members AuthN via RepositoryAugust 2013Members Reporting CapabilityOctober 2013Members CompleteNovember 2013Members

7 CONNECT Infrastructure 06/11/2013 Code “as is” from: Training Tutorials/Webinars:

8 J-UT Notional Architecture 06/11/2013 Initial goal: request/provide patient clinical document.

906/11/2013 Pre-Configured Endpoint J-UT participants may use a pre-configured endpoint (optional) CONNECT 4.1 base functionality CONNECT 4.1 Master Patient Index (MPI) CONNECT 4.1 XDS.b document repository CONNECT 4.1 test scripts Available “as is” as a VM image 8 GB RAM 60GB Available HDD space 1.1 Ghz of available CPU Recommended Requires only configuration file changes and PKI set up Available to any formal member of the pilot

10 Demonstration 06/11/2013

Implementation Current implementation status –Created virtual machines for Custodian and Primary Requestor –Installed CONNECT 4.1 on each –Setup PKI infrastructure –Tested functionality with: CONNECT MPI CONNECT XDS.b 4.1 document repository XCPD / XCA Possible future enhancements: Open connect /11/201311

1206/11/2013 Completing Basic Infrastructure Additional steps required to complete Basic Infrastructure milestone Crosscheck each participant’s gateway Establish network connectivity between pilot participants –Custodian –Primary Requestor Re-Test Establish process for deploying code updates as development commences. Initiate development spirals for reference implementation

1306/11/2013 Additional Steps Provide UI’s to simplify use and demonstration From: CONNECT Universal Client (UC) GUI User Guide

Standard soapUI Test Interfaces 06/11/201314

15 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 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 ODD (IHE) - On-Demand Documents (Trial) Supplement Note: PCD (HL7) – just updated last WGM, will re-ballot 06/11/2013

DS4P Standards Material Location of DS4P Standards Inventory: Location of DS4P Standards Mapping Issues: xlsx/ /Copy%20of%20DataMappingsIssues% xlsx General Standards Source List: %20Analysis.xlsx/ /General%20SI%20Framework%20Standards%20A nalysis.xlsx Standards Crosswalk Analysis monizationhttp://wiki.siframework.org/Data+Segmentation+for+Privacy+Standards+and+Har monization (at bottom of page, exportable) Implementation Guidance 20Guidance_consensus_v1_0_4.pdf/ /Data%20Segmentation%20Impl ementation%20Guidance_consensus_v1_0_4.pdf 06/11/201316

1706/11/2013 Questions? For example: Can I use my own eHealth Exchange endpoint? Can use actual patient information? (No.)

18 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 Stand up information holders and requestors Create XDS.b repository holding PCD Identify remaining pieces Document and update IG with results of our experience 06/11/2013

1906/11/2013 DS4P References Use Case: ases ases Implementation Guide: nsensus nsensus Pilots Wiki Page: +Pilots+Sub-Workgroup +Pilots+Sub-Workgroup

2006/11/2013 Backup Slides

Query and Response for Location 06/11/201321

Query and Response PCD 2206/11/2013

2306/11/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 

2406/11/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

2505/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

2605/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

2705/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 

2805/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 

2905/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 

3006/11/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 

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

3205/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.

3305/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

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

3506/11/2013 Issues from Previous Call 1.Issues inherent in embedding PCD repository information Embedding PCD Repository information in clinical documents Providing a pointer to location is static (even if PCD dynamic) Can we meet goal by embedding query information? 2.Subsequent Custodian of Data should multicast query for PCD Provide broad information, specific to organization Provide unique PCD identifier in clinical document 3.Cover new use cases If PCD not found, multiple PCD found, or new repository 4.Build on previous pilots Most recent PCD, no de-confliction step considered

36 NHIN IHE XCA 06/11/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

3706/11/2013 Issues from Previous Call 1.Issues inherent in embedding PCD repository information Embedding PCD Repository information in clinical documents Providing a pointer to location is static (even if PCD dynamic) Can we meet goal by embedding query information? 2.Subsequent Custodian of Data should multicast query for PCD Provide broad information, specific to organization Provide unique PCD identifier in clinical document 3.Cover new use cases If PCD not found, multiple PCD found, or new repository 4.Build on previous pilots Most recent PCD, no de-confliction step considered

3806/11/2013 Running Observations 1.XCA simplifies back-end implementation Although XDS.b is described in IHE documents, not required Many current examples of eHealth Exchange use XCA 2.On-Demand Documents Supplement NHIN has adopted the use of On-Demand Documents Updates XCA to use dynamically created documents Allows registration of content dynamically assembled 3.Audit record from custodian of release decision Previous pilots used unique message ID, not externalized 4.Creation of PCD on demand If PCD has sensitive data, should not give all information

3906/11/2013 PCD Reference Information 1.How a PCD is referenced depends on your environmental assumptions XCA takes care of patient id mappings and lookups of remote service endpoint URLs Using XCA, reference of PCD is by home community ID Using plain XDS.b, reference of PCD is by patient ID and service endpoint URL 2.What is the impact of clinical document exchange architectures?

4006/11/2013 Architecture Differences 1.eHealth Exchange using CONNECT Uses XCA for document queries Communities are connected with a service registry –If you are not in the service registry, you don’t exist Works well when you don’t know who has the information Typically requires MPI, XCA implementation, and a service registry. –Complex and expensive to manage the supporting systems

4106/11/2013 Architecture Differences (cont) 2.DIRECT Uses XDR and XDM instead of XCA. –i.e. either a direct SOAP web service call over HTTPS (XDR) or over S/MIME (XDM) Works great when you are pushing a record to someone you know Requires minimal supporting software and systems 3.Summary What is the appropriate standard for exchanges with the PCD repository: XCA – or – XDR & XDM?

4206/11/2013 PCD Reference Table

Using ATNA 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/201343

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 06/11/201344