“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review June 25, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.

Slides:



Advertisements
Similar presentations
September, 2005What IHE Delivers 1 Karen Witting IBM Cross-Community: Peer- to-Peer sharing of healthcare information.
Advertisements

Extending XDW in Cross-Community Editor: Charles Parisot Notes for the March 19 th, 2013 – ITI Tech Committee.
S&I Framework Testing HL7 V2 Lab Results Interface and RI Pilot Robert Snelick National Institute of Standards and Technology June 23 rd, 2011 Contact:
Electronic Submission of Medical Documentation (esMD) Face to Face Informational Session esMD Requirements, Priorities and Potential Workgroups – 2:00pm.
Electronic Submission of Medical Documentation (esMD) for Medicare FFS Presentation to HITSC Provenance Workgroup January 16, 2015.
Project Proposal to IHE: Implementation Guide for Data Segmentation For Privacy (DS4P) over REST Submitted by S&I Framework Data Segmentation for Privacy.
S&I Framework Provider Directories Initiative esMD Work Group October 19, 2011.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review September 17, 2013 Presented by: David Staggs and Michael Dufel Jericho Systems Corporation.
NHIN Direct Project Communications Work Group Message for State HIE/RECs August 30, 2010.
NHIN Specifications Richard Kernan, NHIN Specification Lead (Contractor), Office of the National Coordinator for Health IT Karen Witting, Contractor to.
Cross Domain Patient Identity Management Eric Heflin Dir of Standards and Interoperability/Medicity.
Electronic Submission of Medical Documentation (esMD) Face to Face Informational Session Charter Discussion – 9:30am – 10:00am October 18, 2011.
Cross Domain Patient Identity Management Eric Heflin Dir of Standards and Interoperability/Medicity.
What IHE Delivers Healthcare Provider Directories IHE IT Infrastructure Planning Committee Eric Heflin – Medicity/THSA.
S New Security Developments in DICOM Lawrence Tarbox, Ph.D Chair, DICOM WG 14 (Security) Siemens Corporate Research.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review June 18, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review July 9, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review July 16, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
Cross-Enterprise User Assertion IHE Educational Workshop 2007 Cross-Enterprise User Assertion IHE Educational Workshop 2007 John F. Moehrke GE Healthcare.
PDMP & HITI Solution Planning/IG Workgroup Session July 3, 2014.
CS 493 Project Definition The project assignment is a simplified version of the Integrating Healthcare Enterprise (IHE) Cross-Enterprise Document Sharing.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review April 9, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review April 23, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
Sharing Value Sets (SVS Profile) Ana Estelrich GIP-DMP.
Data Segmentation for Privacy Agenda All-hands Workgroup Meeting May 9, 2012.
Public Health Data Standards Consortium
“Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review April 16, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
Dynamic Document Sharing Detailed Profile Proposal for 2010 presented to the IT Infrastructure Technical Committee Karen Witting November 10, 2009.
0 Connectathon 2009 Registration Bob Yencha Webinar | August 28, 2008 enabling healthcare interoperability.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review August 27, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
Key Issues of Interoperability in eHealth Asuman Dogac, Marco Eichelberg, Tuncay Namli, Ozgur Kilic, Gokce B. Laleci IST RIDE Project.
Public Health Reporting Initiative Stage 3 Sprint: Implementation Guide Development Phone: x
EDOS Workgroup Update May 21, 2013 Laboratory Orders Interface Initiative.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review May 7, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review May 14, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
Health eDecisions Use Case 2: CDS Guidance Service Strawman of Core Concepts Use Case 2 1.
1 Healthcare Information Technology Standards Panel Care Delivery - IS01 Electronic Health Record (EHR) Laboratory Results Reporting July 6, 2007.
S&I PUBLIC HEALTH REPORTING INITIATIVE: DEVELOPING OF A TEAMING APPROACH S&I Public Health Reporting Initiative Nikolay Lipskiy, MD, DrPH, Co-Lead September,
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review May 21, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
Health Delivery Services May 29, Eastern Massachusetts Healthcare Initiative Policy Work Group Session 2 May 29, 2009.
Longitudinal Coordination of Care (LCC) Pilots Documentation GSIHealth: Health Home Data Exchange via Direct 01/06/2013.
Data Access Framework All Hands Community Meeting April 23, 2014.
Data Access Framework (DAF) Relationship to Other ONC Initiatives 1.
Data Access Framework All Hands Community Meeting April 2, 2014.
Ongoing/Planned Activities for Week of 4/22 Initial feedback on UCR Crosswalk due COB 4/23 Hold working session to continue filling out the UCR Crosswalk.
Electronic Submission of Medical Documentation (esMD)
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review June 4, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
Ongoing/Planned Activities for Week of 4/29 Final UCR Crosswalk due COB 4/30 Hold two working sessions to complete UCR Crosswalk on 4/30 Hold working session.
IHE IT Infrastructure Domain Update Karen Witting – IBM IT Infrastructure Technical Committee co-chair.
The Patient Choice Project Use Case Working Session January 8 th, 2016.
September, 2005What IHE Delivers 1 IT Infrastructure Planning Committee Karen Witting – Ready Computing XDS & XCA: On-Demand Documents.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review May 28, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
Dynamic/Deferred Document Sharing (D3S) Profile for 2010 presented to the IT Infrastructure Technical Committee Karen Witting February 1, 2010.
Data Access Framework All Hands Community Meeting April 9, 2014.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review August 13, 2013 Presented by: Michael Dufel and David Staggs Jericho Systems Corporation.
Public Health Data Standards Consortium
Data Access Framework All Hands Community Meeting April 16, 2014.
Longitudinal Coordination of Care LCP SWG Thursday, May 23, 2013.
What IHE Delivers Basic Patient Privacy Consents HIT-Standards – Privacy & Security Workgroup John Moehrke GE Healthcare.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review April 30, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
Cross Community Access Profile Karen Witting IBM Co-chair ITI technical committee.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review June 11, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation.
“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review November 5, 2013 Presented by: David Staggs JD, CISSP Jericho Systems Corporation.
Integrating the Healthcare Enterprise Retrieve Information for Display (RID) Integration Profile Ellie Avraham Kodak Health Imaging IHE IT Infrastructure.
What IHE Delivers Healthcare Provider Directories IHE IT Infrastructure Planning Committee Eric Heflin - Medicity.
Dynamic/Deferred Document Sharing (D3S) Profile for 2010 presented to the IT Infrastructure Technical Committee Karen Witting February 1, 2010.
Labs Early Adoption Program Template Insert the Name of Your Implementation / Organization Here MM/DD/YYYY.
Structured Data Capture (SDC) FHIR SDC Pilots Template
IT Infrastructure Plans
System Directory for Document Sharing (SDDS)
Presentation transcript:

“ 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: Access code: URL: d= d=

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 Repository 2 nd Requestor 1 st 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/20136

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

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

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

Repository Requests Vary Which 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/201310

Cross Gateway Patient Discovery 06/25/ Attribute IDSourceDescriptionOptionality PCD Query urn:oasis:names:tc:xspa:1.0:subject:purposeofuseXUA assertionHL7 valueRequired urn:oasis:names:tc:xpsa:1.0:subject:organization-idXUA Assertionunique organizational identifier of the requestor Required urn:oasis:names:tc:xpsa:1.0:subject:organizationXUA AssertionName of the organization of the requestor Required urn:nhin:names:saml:homeCommunityIdXUA AssertionHome community id of the requestor Required If Available Optional urn:oasis:names:tc:xpsa:1.0:subject:organizationXUA Assertionhome community ID of the requestor RequiredOptional urn:oasis:names:tc:xacml:1.0:resource:patient-id XDS.b metadatapatient idRequired urn:oasis:names:tc:xacml:1.0:action:action-idN/ADefined Value: DocumentQuery Required urn:oasis:names:tc:xacml:2.0:subject:roleXUA AssertionASTM role of the requesting user Optional urn:oasis:names:tc:xacml:1.0:subject:subject-idXUA AssertionRequestor name, address or NPI RequiredOptional urn:oasis:names:tc:xspa:1.0:environment:localityConfigurationhome community ID of servicing organization RequiredOptional

Query for Documents Transaction 06/25/ Attribute IDSourceDescriptionOptionality PCD Query urn:oasis:names:tc:xspa:1.0:subject:purposeofuseXUA assertionHL7 valueRequired urn:oasis:names:tc:xpsa:1.0:subject:organization-idXUA Assertionunique organizational identifier of the requestor Required urn:oasis:names:tc:xpsa:1.0:subject:organizationXUA AssertionName of the organization of the requestor Required urn:nhin:names:saml:homeCommunityIdXUA AssertionHome community id of the requestor Required If Available Optional urn:oasis:names:tc:xpsa:1.0:subject:organizationXUA Assertionhome community ID of the requestor RequiredOptional urn:oasis:names:tc:xacml:1.0:resource:patient-id XDS.b metadatapatient idRequired urn:oasis:names:tc:xacml:1.0:action:action-idN/ADefined Value: DocumentQuery Required urn:oasis:names:tc:xacml:2.0:subject:roleXUA AssertionASTM role of the requesting user Optional urn:oasis:names:tc:xacml:1.0:subject:subject-idXUA AssertionRequestor name, address or NPI RequiredOptional urn:oasis:names:tc:xspa:1.0:environment:localityConfigurationhome community ID of servicing organization RequiredOptional urn:oasis:names:tc:xspa:2.0:resource:typeXDS.b Query or Document LOINC code for document requested Required urn:oasis:names:tc:xspa:1.0:resource:hl7:confidenti ality- code XDS.b Query or Document Confidentiality code of CDA document RequiredOptional?

Retrieve Document Transaction 06/25/ Attribute IDSourceDescriptionOptionality PCD Query urn:oasis:names:tc:xspa:1.0:subject:purposeofuseXUA assertionHL7 valueRequired urn:oasis:names:tc:xpsa:1.0:subject:organization-idXUA Assertionunique organizational identifier of the requestor Required urn:oasis:names:tc:xpsa:1.0:subject:organizationXUA AssertionName of the organization of the requestor Required urn:nhin:names:saml:homeCommunityIdXUA AssertionHome community id of the requestor Required If Available Optional urn:oasis:names:tc:xpsa:1.0:subject:organizationXUA Assertionhome community ID of the requestor RequiredOptional urn:oasis:names:tc:xacml:1.0:resource:patient-id XDS.b metadatapatient idRequired urn:oasis:names:tc:xacml:1.0:action:action-idN/ADefined Value: DocumentQuery Required urn:oasis:names:tc:xacml:2.0:subject:roleXUA AssertionASTM role of the requesting user Optional urn:oasis:names:tc:xacml:1.0:subject:subject-idXUA AssertionRequestor name, address or NPI RequiredOptional urn:oasis:names:tc:xspa:1.0:environment:localityConfigurationhome community ID of servicing organization RequiredOptional urn:oasis:names:tc:xspa:2.0:resource:typeXDS.b Query or Document LOINC code for document requested Required urn:oasis:names:tc:xspa:1.0:resource:hl7:confidenti ality- code XDS.b Query or Document Confidentiality code of CDA document RequiredOptional? urn:oasis:names:tc:xspa:1.0:resource:hl7:sensitivity- code XDS.b Document Sensitivity code of dataRequiredRequired if available

Notes on Data Segmentation How 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/201314

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 22nd 06/25/201316

1706/25/2013 Reminder: Test Methodology

1806/25/2013 Pilot Timeline General Timeline, conditioned on agreement of stakeholders MilestoneTarget DateResponsible Party Kick off and LogisticsApril 2013Jericho Systems Basic InfrastructureJune 2013Members AuthN via RepositoryAugust 2013Members Reporting CapabilityOctober 2013Members CompleteNovember 2013Members

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: Location of DS4P Standards Mapping Issues: xlsx/ /Copy%20of%20DataMappingsIssues% xlsx General Standards Source List: %20Analysis.xlsx/ /General%20SI%20Framework%20Standards%20A nalysis.xlsx Standards Crosswalk Analysis monizationhttp://wiki.siframework.org/Data+Segmentation+for+Privacy+Standards+and+Har monization (at bottom of page, exportable) Implementation Guidance 20Guidance_consensus_v1_0_4.pdf/ /Data%20Segmentation%20Impl ementation%20Guidance_consensus_v1_0_4.pdf 06/25/201321

2206/25/2013 DS4P References Use Case: ases ases Implementation Guide: nsensus nsensus Pilots Wiki Page: +Pilots+Sub-Workgroup +Pilots+Sub-Workgroup

2306/25/2013 Backup Slides

2406/25/2013 Expected Data Flow (updated) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st 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 Repository 2 nd Requestor 1 st Requestor Clinical exchange #  Clinical exchange #  B ,  = Clinical data A,B = PCD data = audit record And Subsequent Custodian of Data being Provided at  Fetch PCD Send audit

2605/25/2013 Expected Data Flow (1) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st Requestor  ,  = Clinical data A,B = PCD data = audit record

2705/25/2013 Expected Data Flow (2) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st Requestor  ,  = Clinical data A,B = PCD data = audit record

2805/25/2013 Expected Data Flow (3) Custodian of Data being Provided at  Patient PCD Repository 2 nd Requestor 1 st 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 Repository 2 nd Requestor 1 st 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 Repository 2 nd Requestor 1 st 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 Repository 2 nd Requestor 1 st Requestor   B ,  = Clinical data A,B = PCD data = audit record And Subsequent Custodian of Data being Provided at 

Informative Note: PCDs 05/14/ PCD Format PCD Header PCD Body Structure of the PCD

Query and Response for Location 06/25/201333

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 Call 1.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 Observations 1.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