“ Jericho / UT Austin Pilot”

“Jericho / UT Austin Pilot”

Privacy with Dynamic Patient Review

November 5, 2013

Presented by:David Staggs JD, CISSP

Jericho Systems Corporation

211/5/2013

Agenda• Administrative issues • Pilot scope• Pilot data flow • Implementation guidance document

– Previously discussed sections– Additional sections

• General discussion• Pilot timeline• Plan of action

311/5/2013

Pilot Administrivia• This pilot is a community led pilot

– Limited support provided by the ONC• Johnathan Coleman (Security Risk Solutions)• Zachary May (ESAC)• Penelope Hughes (ONC)• Libbie Buchele (ONC Sponsor)

• 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

411/5/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 to the healthcare consumer (subject). 

2. Additional goal: use identifiers to identify the subject/ PCD repository for use in reporting the outcome of the “secondary user” request use case to subject by subsequent EHR custodians.

3. Stretch goal: mask and/or redact the clinical document based on data segmentation and PCD choices retrieved from the PCD repository.

511/5/2013

Pilot Data Flow

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

611/5/2013

J-UT Implementation Guidance• PCD returned to the document custodian should be

specific to the document custodian and the requestor • PCD should be requested for each type of network

exchange that could reveal PHI: ITI-55, ITI-38, and ITI-39• Data labels should be passed in the PCD request if they

exist in the document being requested • Document Custodian should return release decision as

an ATNA audit message to the PCD repository • PCD repository should allow edit of PCD and review of

release decisions through standard interfaces

http://wiki.siframework.org/file/view/SIFramework_DS4P_UC_Jericho_4NOV2013.docx/466080974/SIFramework_DS4P_UC_Jericho_4NOV2013.docx

711/5/2013

Previously Discussed IG Sections

• PCD should be dynamically filtered specifically for the document custodian and requestor (§2.2)

• PCD should be requested for each type of data exchange that could reveal PHI (§3.0)

• PCD request should include any data labels identified in the requested information (§2.3)

• Release decision should be returned to the PCD repository using an ATNA audit message (§2.4)

• PCD repository should be securely accessible to patients using standard interfaces

• PCD alternative representation should be XACML and should be lightweight (§2.6)

• PCD repository location and account information can be embedded in a CDA clinical document (§2.5)

811/5/2013

Additional Topics Added to the IG

• Introduction: creation of the pilot (§1.0)• Use Case Scenario: implementation of user story 3 (§2.0)• Architecture: The J-UT data flow (§2.1)• IHE ITI-55 Transactions: diagram and data sets for patient

discover request received at the gateway (§3.1)• IHE ITI-38 Transactions: diagram and data sets for

document list request received at the gateway (§3.2)• IHE ITI-39 Transactions: diagram and data sets for

document request received at the gateway (§3.3)• Test Participants: List of members who played roles in the

test scenario (§4)• Summary of J-UT Implementation Guidance: Summary of

the major guidance from the pilot (§5)

911/5/2013

General Discussion• Implementation guidance document

– Do we need more time to review?– Does the content need additions / deletions?

• Are there issues with the remaining artifacts?– Mapping / gap analysis of functionality to standards?– Test cases, test artifacts, and/or test video?

• Additional activities– More demonstrations and/or J-UT meetings?– Approval of the implementation guidance document?– Bringing the IG to standards organizations (profiles)?

1011/5/2013

Pilot Timeline• General Timeline, conditioned on agreement of stakeholders

11

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, create test procedures • Document and update IG with results of our experience

11/5/2013

1211/5/2013

Backup Slides

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

11/5/2013 13

1411/5/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

Test Cases

11/5/2013 15

1. Consent To Patient Discovery : No Consent2. Consent To Document Query : No Consent3. Consent To Document Retrieve : No Consent4. Consent To Patient Discovery : 1st Requestor (1st)5. Consent To Document Query : 1st To PC - Allow6. Consent To Document Query with POU 1st to PC – Deny7. Consent To Document Retrieve : 1st to PC - Allow8. Consent To Patient Discovery : 2nd Requestor (2nd)9. Consent To Document Query : 2nd To PC - Deny10. Consent To Document Retrieve : 2nd To PC – Deny11. Consent To Document Query : 2nd to SC - Deny12. Consent To Document Retrieve : 2nd to SC - Deny13. Consent To Document Retrieve : With Segmentation

Test Cases (Visual Representation)

11/5/2013 16

Scenario PCD ITI-55 ITI-38 ITI-391st Requestor → PC Y 4 5/6 72nd Requestor → PC Y 8 9 102nd Requestor → SC Y 11 121st Requestor → PC N 1 2 3Clinical Data Segmentation Y 13

PC = Primary CustodianSC = Secondary Custodian

Test Document available for review (since 9/16/2013) at: http://wiki.siframework.org/DS4P+Jericho-UT+Austin+Draft+Test+Document

Video of the test will be available shortly.

Test Participants

Participants in the September 20, 2013 DS4P Pilot Execution Script:

11/5/2013 17

Participant Acting As Story Role Home Community IdUT-Austin Secondary

CustodianResearch University 2.2

UT-Austin First Requestor Research University 2.2Conemaugh Second Requestor Marketing Network 5.5

Jericho Systems Primary Custodian First Network 1.1

Jericho Systems Patient Consent Repository

Patient Consent Repository

1.1

Edmond Scientific

Secure Labeling Service

First Network infrastructure piece

1811/5/2013

Pilot Data Flow

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

1911/5/2013

Pilot Data Flow

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

2011/5/2013

Pilot Data Flow (1)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

, = Clinical data

A,B =PCD data

= audit record

2111/5/2013

Pilot Data Flow (2)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

, = Clinical data

A,B =PCD data

= audit record

2211/5/2013

Pilot 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

2311/5/2013

Pilot 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

2411/5/2013

Pilot 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

2511/5/2013

Pilot 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