“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review June 25, 2013 Presented by:...
-
Upload
angel-long -
Category
Documents
-
view
219 -
download
1
description
Transcript of “ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review June 25, 2013 Presented by:...
“Jericho / UT Austin Pilot”
Privacy with Dynamic Patient Review
June 25, 2013
Presented by:David Staggs, JD, CISSP
Jericho Systems Corporation
206/25/2013
Agenda• Administrative issues • Pilot scope• Data flow diagram• Information leakage• Relevant filtering• Data segmentation• Available attributes for various eHealth exchange calls • How to pass the attributes in the PCD request• UT student involvement• Questions• POA&M
306/25/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/25/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/25/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
Information Leakage• PCD repository reference implementation options:
– Give the data custodian the entire PCD once and allow use for multiple requests
– Give the data custodian a subset of the PCD relevant to the data custodian and allow use for multiple requests
– Give the data custodian a subset of the PCD relevant to each request for a clinical document
• Information leakage is reduced by providing only what is required to decide patient’s intent for the clinical document being requested
06/25/2013 6
What’s Relevant?• Filtering the PCD to reduce data leakage:
– What information is available and necessary to filter the PCD (SAML attributes)
• organization and organization-id (remote node)• subject-id and subject:npi (remote requester)• role (role of remote requester)• purposeofuse (stated reason for the request)• resource-id (unique patient identifier)
• Provide recommendation meeting clinical workflow
06/25/2013 7
What’s Relevant?• Filtering the PCD to reduce data leakage:
– What information is available and necessary to filter the PCD (SAML attributes)
• organization and organization-id (remote node)• subject-id and subject:npi (remote requester)• role (role of remote requester)• purposeofuse (stated reason for the request)• resource-id (unique patient identifier) use patient-id
• Provide recommendation meeting clinical workflow• Clerks submit requests for clinicians
06/25/2013 8
X
XX
Data Segmentation• Patient’s consent over release of certain clinical data:
– What information is available and necessary to filter the PCD (attributes from the clinical document)
– Requires segmentation (data tagging) of the clinical document being requested
• HL7 CDA r2 Confidentiality codes (e.g., ETH) in header• HL7 HCS Sensitivity codes (in data segments)
• If data tags are passed in the request for a PCD, only the patient’s restrictions on those data tags need be sent– Custodian already knows the existence of the data
segment because it sees it in the clinical document
06/25/2013 9
Repository Requests VaryWhich responses should require a PCD?
• In response to Cross Gateway Patient Discovery (XCPD)– NHIN Patient Discovery IHE ITI-55– NHIN Patient Location Query IHE ITI-56
• In response to NHIN Query for Documents Transaction– IHE Cross Community Access (XCA) ITI-38
• In response to NHIN Retrieve Document Transaction– IHE ITI XCA Supplement Section 3.39
XCPD maps identifiers, other request have different attributes
06/25/2013 10
Cross Gateway Patient Discovery
06/25/2013 11
Attribute ID Source Description Optionality PCD Query
urn:oasis:names:tc:xspa:1.0:subject:purposeofuse XUA assertion HL7 value Required Requiredurn:oasis:names:tc:xpsa:1.0:subject:organization-id XUA Assertion unique organizational
identifier of the requestor
Required Required
urn:oasis:names:tc:xpsa:1.0:subject:organization XUA Assertion Name of the organization of the requestor
Required Required
urn:nhin:names:saml:homeCommunityId XUA Assertion Home community id of the requestor
Required If Available
Optional
urn:oasis:names:tc:xpsa:1.0:subject:organization XUA Assertion home community ID of the requestor
Required Optional
urn:oasis:names:tc:xacml:1.0:resource:patient-id
XDS.b metadata patient id Required Required
urn:oasis:names:tc:xacml:1.0:action:action-id N/A Defined Value: DocumentQuery
Required
urn:oasis:names:tc:xacml:2.0:subject:role XUA Assertion ASTM role of the requesting user
Optional Optional
urn:oasis:names:tc:xacml:1.0:subject:subject-id XUA Assertion Requestor name, email address or NPI
Required Optional
urn:oasis:names:tc:xspa:1.0:environment:locality Configuration home community ID of servicing organization
Required Optional
Query for Documents Transaction
06/25/2013 12
Attribute ID Source Description Optionality PCD Query
urn:oasis:names:tc:xspa:1.0:subject:purposeofuse XUA assertion HL7 value Required Requiredurn:oasis:names:tc:xpsa:1.0:subject:organization-id XUA Assertion unique organizational
identifier of the requestor
Required Required
urn:oasis:names:tc:xpsa:1.0:subject:organization XUA Assertion Name of the organization of the requestor
Required Required
urn:nhin:names:saml:homeCommunityId XUA Assertion Home community id of the requestor
Required If Available
Optional
urn:oasis:names:tc:xpsa:1.0:subject:organization XUA Assertion home community ID of the requestor
Required Optional
urn:oasis:names:tc:xacml:1.0:resource:patient-id
XDS.b metadata patient id Required Required
urn:oasis:names:tc:xacml:1.0:action:action-id N/A Defined Value: DocumentQuery
Required
urn:oasis:names:tc:xacml:2.0:subject:role XUA Assertion ASTM role of the requesting user
Optional Optional
urn:oasis:names:tc:xacml:1.0:subject:subject-id XUA Assertion Requestor name, email address or NPI
Required Optional
urn:oasis:names:tc:xspa:1.0:environment:locality Configuration home community ID of servicing organization
Required Optional
urn:oasis:names:tc:xspa:2.0:resource:type XDS.b Query or Document
LOINC code for document requested
Required Required
urn:oasis:names:tc:xspa:1.0:resource:hl7:confidentiality- code
XDS.b Query or Document
Confidentiality code of CDA document
Required Optional?
Retrieve Document Transaction
06/25/2013 13
Attribute ID Source Description Optionality PCD Query
urn:oasis:names:tc:xspa:1.0:subject:purposeofuse XUA assertion HL7 value Required Requiredurn:oasis:names:tc:xpsa:1.0:subject:organization-id XUA Assertion unique organizational
identifier of the requestor
Required Required
urn:oasis:names:tc:xpsa:1.0:subject:organization XUA Assertion Name of the organization of the requestor
Required Required
urn:nhin:names:saml:homeCommunityId XUA Assertion Home community id of the requestor
Required If Available
Optional
urn:oasis:names:tc:xpsa:1.0:subject:organization XUA Assertion home community ID of the requestor
Required Optional
urn:oasis:names:tc:xacml:1.0:resource:patient-id
XDS.b metadata patient id Required Required
urn:oasis:names:tc:xacml:1.0:action:action-id N/A Defined Value: DocumentQuery
Required
urn:oasis:names:tc:xacml:2.0:subject:role XUA Assertion ASTM role of the requesting user
Optional Optional
urn:oasis:names:tc:xacml:1.0:subject:subject-id XUA Assertion Requestor name, email address or NPI
Required Optional
urn:oasis:names:tc:xspa:1.0:environment:locality Configuration home community ID of servicing organization
Required Optional
urn:oasis:names:tc:xspa:2.0:resource:type XDS.b Query or Document
LOINC code for document requested
Required Required
urn:oasis:names:tc:xspa:1.0:resource:hl7:confidentiality- code
XDS.b Query or Document
Confidentiality code of CDA document
Required Optional?
urn:oasis:names:tc:xspa:1.0:resource:hl7:sensitivity-code
XDS.b Document
Sensitivity code of data Required Required if available
Notes on Data SegmentationHow do we pass attributes in the PCD request?
• Include attributes in SAML/XUA Assertion and keep XDS.b Find Documents query unchanged
• Create new XDS.b query and define attributes as slot query parameters
• Extend existing XDS.b Find Documents query, including attributes as additional optional slot query parameters
06/25/2013 14
IG Query and Response PCD
1506/25/2013
UT Student Contribution• UT Austin HIT Students: John Bender and Adrian Tan
– Project: "Definition of Data Sets Exchanged During Request for Patient Consent Directive (PCD) on e-Health Exchange"
• Goals:– Review common or emerging privacy and security standards for
the transfer of information within eHealth Exchange– Determine optimal standard(s) for data exchange
• Potential usability of HL7 HCS for Jericho Pilot Stage 2– Health Care Privacy & Security Classification System– Define required security labels within the HCS for PCD
transfer– Define specific PCD data to be exchanged, including metadata
• Deadline: July 22nd06/25/2013 16
1706/25/2013
Reminder: Test Methodology
1806/25/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
1906/25/2013
Questions?
• For example:• Should we demonstrate data segmentation information being
passed in the PCD request?
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/25/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/25/2013 21
2206/25/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/25/2013
Backup Slides
2406/25/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/25/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/25/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/25/2013 33
Query and Response PCD
3406/25/2013
35
NHIN IHE XCA
06/25/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
3606/25/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
3706/25/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