“Jericho / UT Austin Pilot”

Privacy with Dynamic Patient Review

June 18, 2013

Presented by:David Staggs, JD, CISSP

Jericho Systems Corporation

206/18/2013

Agenda

• Administrative issues • Pilot scope• Updated data flow diagram• Functional requirements summary• Identified standards• Gap analysis• Update on J-UT Pilot Infrastructure• Influencing standards based on our pilot• Questions• POA&M

306/18/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-3208Access code: 662 197 169URL:https://siframework1.webex.com/siframework1/onstage/g.php?t=a&d=662197169

406/18/2013

Scope of the Pilot

• 1.      Define the exchange of HL7 CDA-compliant PCD between a data custodian and a PCD repository 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.

506/18/2013

Expected Data Flow (updated)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st 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-normative06/18/2013 6

7

Relevant Standards

• Standards from previous discussions:• 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-ballot06/18/2013

Gap Analysis• Initial gap analysis for discussion:

1. Single PCD can apply to multiple requests (must 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?)

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

11. Attributes used in PCD exchange may have different meaning

06/18/2013 8

906/18/2013

Pilot Timeline

• General Timeline, conditioned on agreement of stakeholders

Milestone Target Date Responsible Party

Kick off and Logistics April 2013 Jericho Systems

Basic Infrastructure June 2013 Members

AuthN via Repository August 2013 Members

Reporting Capability October 2013 Members

Complete November 2013 Members

1006/18/2013

Pilot Endpoint Functionality• J-UT participants should initially support:

• CONNECT 4.1 base functionality• CONNECT 4.1 Master Patient Index (MPI)• CONNECT 4.1 XDS.b document repository• CONNECT 4.1 test scripts

• Optional capability: • CONNECT Universal Client (UC) GUI

• Future capability: • Support ATNA logging

• Must be configurable to allow PKI set up

11

J-UT Notional Architecture

06/18/2013

Initial goal: request/provide patient clinical document.

Implementation Update

• Current implementation status– CONNECT 4.1 suite installed– PKI infrastructure set up– Tested functionality:

• CONNECT MPI• CONNECT XDS.b 4.1 document repository• XCPD / XCA

– CONNECT Universal Client (UC) GUI • Required switch to Glassfish application server

• Jericho will make Document Custodian endpoint available

06/18/2013 12

1306/18/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

1406/18/2013

Conformance Effort

• Create and track conformance against IG (with our additions)– Conformance statements tested– Conformance statements used– Increasing “utilized” number and tested/verified conformance

statements• Issues for discussion/resolution• Items marked for discussion

– Input from implementers• Items marked “not applicable”

– “hide” rows to resolve clutter• Change, removal requested for some items

– Discussion of pilot recommendations may be needed

1506/18/2013

Crosscheck Approach

1606/18/2013

Test Methodology

1706/18/2013

Influencing Standards

Long-term impact of the J-UT pilot will be in changes to relevant healthcare standards• Community Based Collaborative Care WG (HL7)

– Definition of the PCD header attributes– Definition of the PCD payload attributes

• Cross-Enterprise Security and Privacy Authorization TC (OASIS)– Identification of missing or conflated attributes– Proposal of Patient Consent Directive profile

• Security WG (HL7)– Data Segmentation for Privacy Implementation Guide

1806/18/2013

HL7 Security WG Project

Data Segmentation for Privacy Implementation Guide • Project Scope Statement released

– Adopts ONC DS4P Implementation Guide as a baseline– U.S. profile of the DS4P transport (conformance & constraints)– Includes implementation guidance to developers– Identifies all relevant standards

• Timeline– 1/2014 Submit for Normative Ballot– 1/2015 Project End Date

• Affects Clinical Documents (CDA) and Consent Directives• http://wiki.hl7.org/index.php?title=Security

1906/18/2013

Questions?

• For example:• Can I attend HL7 working group meetings?

20

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/18/2013

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%2005102012.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%20Analysis.xlsx

• Standards Crosswalk Analysis http://wiki.siframework.org/Data+Segmentation+for+Privacy+Standards+and+Harmonization (at bottom of page, exportable)

• Implementation Guidancehttp://wiki.siframework.org/file/view/Data%20Segmentation%20Implementation%20Guidance_consensus_v1_0_4.pdf/416474106/Data%20Segmentation%20Implementation%20Guidance_consensus_v1_0_4.pdf

06/18/2013 21

2206/18/2013

DS4P References

• Use Case: http://wiki.siframework.org/Data+Segmentation+for+Privacy+Use+Cases

• Implementation Guide: http://wiki.siframework.org/Data+Segmentation+for+Privacy+IG+Consensus

• Pilots Wiki Page: http://wiki.siframework.org/Data+Segmentation+for+Privacy+RI+and+Pilots+Sub-Workgroup

2306/18/2013

Backup Slides

2406/18/2013

Expected Data Flow (updated)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

B

, = Clinical data

A,B =PCD data

= audit record

And Subsequent Custodian of Data being Provided at

2506/18/2013

Expected Data Flow (updated)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

Clinical exchange #

Clinical exchange #

B

, = Clinical data

A,B =PCD data

= audit record

And Subsequent Custodian of Data being Provided at Fetch PCD Fetch

PCD

Send auditSend audit

2605/25/2013

Expected Data Flow (1)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

, = Clinical data

A,B =PCD data

= audit record

2705/25/2013

Expected Data Flow (2)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

, = Clinical data

A,B =PCD data

= audit record

2805/25/2013

Expected Data Flow (3)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

B

, = Clinical data

A,B =PCD data

= audit record

And Subsequent Custodian of Data being Provided at

2905/25/2013

Expected Data Flow (4)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

, = Clinical data

A,B =PCD data

= audit record

And Subsequent Custodian of Data being Provided at

3005/25/2013

Expected Data Flow (5)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

, = Clinical data

A,B =PCD data

= audit record

And Subsequent Custodian of Data being Provided at

3106/18/2013

Expected Data Flow (updated)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

B

, = Clinical data

A,B =PCD data

= audit record

And Subsequent Custodian of Data being Provided at

Informative Note: PCDs

05/14/2013 32

PCD Format PCD Header

PCD Body

• Structure of the PCD

Query and Response for Location

06/18/2013 33

Query and Response PCD

3406/18/2013

35

NHIN IHE XCA

06/18/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

36

Call for Pilot Team Members

05/14/2013

Name Role Organization

David Staggs Participant Jericho Systems Corporation

Michael Field Participant UT Austin HIT Lab

3706/18/2013

Issues from Previous Call1. 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/18/2013

Running Observations1. 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/18/2013

PCD Reference Information1. 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/18/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/18/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/18/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/2013 43