“ jericho / ut austin pilot”
DESCRIPTION
“ Jericho / UT Austin Pilot”. Privacy with Dynamic Patient Review. Presented by: David Staggs, JD, CISSP Jericho Systems Corporation. Agenda. Administrative issues Pilot scope Data flow diagram ATNA ITI Guidance NHIN IHE XCA ITI Transactions NHIN IHE XCPD ITI Transactions - PowerPoint PPT PresentationTRANSCRIPT
“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