“ Jericho / UT Austin Pilot”

“Jericho / UT Austin Pilot”

Privacy with Dynamic Patient Review

July 2, 2013

Presented by:David Staggs, JD, CISSP

Jericho Systems Corporation

207/2/2013

Agenda• Administrative issues • Pilot scope• Data flow diagram• ATNA• ITI Guidance• NHIN IHE XCA ITI Transactions• NHIN IHE XCPD ITI Transactions• Proposed approach• UT student involvement• Questions• POA&M

307/2/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

407/2/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.

507/2/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

Recording Release Decisions• Where should our audit record by generated?

– Concept of the Audit Trail • “audit records must capture event descriptions for the

entire process, not just for individual components” • How do we specify what is sent where?

– Identify the RFC-3881 expressible concepts – Identify the appropriate PCD repository

• Repository can be different between patients – Have ability to send to the repository – How much information should be sent?

07/2/2013 6

ATNA Basics• Audit Trail and Node Authentication (ATNA):

– patient information confidentiality – data integrity – user accountability

• Network communications only between secure nodes– local user authentication – bi-directional certificate-based node authentication – audit trail provides accountability

• Example transactions:– ITI-19: Node Authentication, – ITI-20: Record Audit Event

07/2/2013 7

ATNA Details• ITI Example Transactions:

– Node Authentication (ITI-19)– Record Audit Event (ITI-20)

• Secure Communications:– Transport Layer Security (RFC 2246)

• Audit Log Transport:– Syslog Protocol (RFC 5424)– Transmission of Syslog Messages over TLS (RFC 5425)

• Audit Log Messages:– Security Audit and Access Accountability Message XML

Data Definitions for Healthcare Applications (RFC 3881)

07/2/2013 8

ITI Guidance• IHE IT Infrastructure Technical Framework (ITI TF)• IT infrastructure domain (ITI) guidance:

– Volume 1 - Section 9• principles• integration profile• trigger events

– Volume 2 - Sections 3.19, 3.20, …• describes details of transactions• For example, 3.20 equals Record Audit Event (ITI-20)

07/2/2013 9

ITI Guidance, Volume 1• Volume 1 - Section 9:

– principal objective of the Audit Trail mechanism is to track data access to PHI

– recommends using RFC-3881 format, and reporting only events that it can describe

– IHE profile does not specify any audit reporting functions or formats

– specifies Syslog Protocols as the mechanism for logging audit record messages to the audit record repository

– new applications domains may have their own extended vocabularies

– Audit Trail and Node Authentication Integration Profile - actors and transactions (next slide)

07/2/2013 10

ATNA Actors and Transactions

07/2/2013 11

Audit Trail and Node Authentication Integration Profile - Actors and Transactions; IHE IT Infrastructure Technical Framework, Vol. 1, Table 9.4-1

ITI Guidance, Volume 2• Volume 2 (ITI-1 through ITI-28) - Sections 3.19, 3.20:

– Section 3.19 • trust relationship between two nodes in a network

– Section 3.20 • communicate with the audit record repository• uses the syslog protocol (RFC 5424) over TLS (RFC

5425) or UDP (RFC 5426)• record of actions performed on data by users• description of RFC-3881 format• defines terminology for use in IHE extensions

07/2/2013 12

13

NHIN IHE XCA

07/2/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

What’s Relevant to J-UT?• Transactions from the diagram:

– XCA Query for Documents (ITI-38)– XDS.b Document Query (ITI-18) – XCA Document Retrieve (ITI-39) – XDS.b Document Retrieve (ITI-43)

• and – XCPD (ITI-55)

07/2/2013 14

Document Query (ITI-38), part 1• XCA Query for Documents (ITI-38) Section 3.38.4.1.4• The Initiating Gateway:

– If receiving a Registry Stored Query transaction from a Document Consumer, see ITI TF-2a: 3.18.5.1.2.

– In addition, shall audit the Cross Gateway Query as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1.

– In addition, if interacting with a local Document Registry, shall audit as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1.

07/2/2013 15

Document Query (ITI-38), part 2• XCA Query for Documents: Responding Gateway:

– Shall audit the Cross Gateway Query as if it were a Document Registry, see ITI TF-2a: 3.18.5.1.2.

• Where in the CONNECT stack is this done?– In addition, if interacting with a local Document Registry,

shall audit as if it were a Document Consumer. See ITI TF-2a: 3.18.5.1.1.

07/2/2013 16

Document Query (ITI-39), part 1• Document Query (ITI-39) Section 3.39.4.1.4• The Initiating Gateway:

– If receiving a Retrieve Document Set transaction from a Document Consumer, shall audit as if it were a Document Repository, see ITI TF-2b: 3.43.6.

– In addition, shall audit the Cross Gateway Retrieve as if it were a Document Consumer, see ITI TF-2b: 3.43.6.

– In addition, if interacting with a local Document Repository, shall audit as if it were a Document Consumer, see ITI TF-2b: 3.43.6.

– One audit record per Document Repository contacted.

07/2/2013 17

Document Query (ITI-39), part 2• The Responding Gateway:

– Shall audit the Cross Gateway Retrieve as if it were a Document Repository, see ITI TF-2b: 3.43.6.

• Where in the CONNECT stack is this done?– In addition, if interacting with a local Document Registry,

shall audit as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1.

07/2/2013 18

Document Query (ITI-18), part 1• Document Query (ITI-18)• The Initiating Gateway:

– If receiving a Registry Stored Query transaction from a Document Consumer, see ITI TF-2a: 3.18.5.1.2.

– In addition, shall audit the Cross Gateway Query as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1.

– In addition, if interacting with a local Document Registry, shall audit as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1.

07/2/2013 19

Document Query (ITI-18), part 2• The Responding Gateway:

– Shall audit the Cross Gateway Query as if it were a Document Registry, see ITI TF-2a: 3.18.5.1.2.

– In addition, if interacting with a local Document Registry, shall audit as if it were a Document Consumer. See ITI TF-2a: 3.18.5.1.1.

07/2/2013 20

Document Query (ITI-43), part 1• Document Query (ITI-43)• The Initiating Gateway:

– If receiving a Retrieve Document Set transaction from a Document Consumer, shall audit as if it were a Document Repository, see ITI TF-2b: 3.43.6.

– In addition, shall audit the Cross Gateway Retrieve as if it were a Document Consumer, see ITI TF-2b: 3.43.6.

– In addition, if interacting with a local Document Repository, shall audit as if it were a Document Consumer, see ITI TF-2b: 3.43.6.

– One audit record per Document Repository contacted.

07/2/2013 21

Document Query (ITI-39), part 2• The Responding Gateway:

– Shall audit the Cross Gateway Retrieve as if it were a Document Repository, see ITI TF-2b: 3.43.6.

– In addition, if interacting with a local Document Registry, shall audit as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1.

07/2/2013 22

NHIN IHE XCPD

from “IHE ITI Technical Framework Supplement – Cross-Community Patient Discovery (XCPD)”

07/2/2013 23

XCPD Integration Profile

07/2/2013 24

from “IHE ITI Technical Framework Supplement – Cross-Community Patient Discovery (XCPD)”

eHealth Exchange uses Cross Gateway Patient Discovery [ITI-55]

XCPD (ITI-55, 56)• Cross Gateway Patient Discovery [ITI-55]

– 3.55.5.1 Security Audit Considerations• 3.55.5.1.1 Initiating Gateway audit message• 3.55.5.1.2 Responding Gateway audit message

• Patient Location Query [ITI-56] (not supported by eHealth Exchange)– 3.56.5.1 Security Audit Considerations

• 3.56.5.1.1 Initiating Gateway audit message• 3.56.5.1.2 Responding Gateway audit message

07/2/2013 25

2605/14/2013

ATNA: XCPD

2705/14/2013

ATNA: Document Query

2805/14/2013

ATNA: Document Retrieve

Implementation Approach

• EXTEND existing ATNA messages to include consent metadata– XCPD Supplement 3.55.5.1.2 Responding Gateway audit

message– TF_VOL2a 3.18.5.1.2: Document Registry audit Message – TF_VOL2b 3.43.6.1.2 Document Repository audit

message

10/11/2011 29

Privacy Extension

10/11/2011 30

Define additional ParticipantObjectDetail for consent metadata

Document Retrieve Extension

10/11/2011 31

Document Retrieve Extension (2)

10/11/2011 32

UT Student Contribution• "Definition of Data Sets Exchanged During Request for

Patient Consent Directive (PCD) on e-Health Exchange" – UT Students: Johnny Bender and Adrian Tan

• Initial enquiry:– HCS rules for assigning and rendering security labels

within the CDA document entry. • Findings:

– HCS rules for assigning/rendering security labels in CDA document entry/header/sections:

• Encode and store clinical elements/metadata– Rule for a tagged entry:

• A tagged entry must have a content element identifier (otherwise optional in CDA). 07/2/2013 33

UT Student Contribution (2)– Non-sensitive coded attributes:

• Not required to reference associated content element identifiers.

• Narrative consent not required to have content element identifiers.

– Tagged entry reference to narrative content: • CDA derived (coded) content element identifier: Must

reference narrative content source. • Original (non-coded) narrative content element

identifier: Must be encoded to assign security labels. – Tagged entry attribute reference to narrative content:

• The attribute of the originalText must reference narrative content element.

07/2/2013 34

3507/2/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

3607/2/2013

Questions?

• For example:• How many audit records should be sent per document request?• What information should be in the audit record sent from the

custodian?• Should we audit events within the PCD repository, too?

37

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

07/2/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

07/2/2013 38

3907/2/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

4007/2/2013

Backup Slides

4107/2/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

4207/2/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

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

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

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

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

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

4807/2/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