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

207/9/2013 Agenda Administrative issues Pilot scope Data flow diagram Masking / Redaction Data Labeling HL7 Security Observation Vocabulary HCS in the J-UT Pilot Identifiers in Clinical Documents Questions POA&M

307/9/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=

407/9/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. 4. Stretch goal: mask and/or redact the clinical document based on PCD choices retrieved from the PCD repository.

507/9/2013 Pilot Data Flow 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 

Data Segmentation (6/25/2013) 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 07/9/20136

Document Masking/Redaction Document masking and redaction –Redaction: Remove information –Masking: Limit access to information (encrypt) Prerequisites –Clinical document must be segmented and labeled Previous masking and redaction DS4P pilot demonstrations –September 9-14, 2012 at HL7 WGM –March 3-7, 2013 at HIMSS Interoperability Showcase Data labeling used in VA/SAMHSA DS4P pilot –HCS Security Labels conform to NIST FIPS PUB 188 Standard Security Label structure 07/9/20137

VA/SAMHSA Pilot Overview 07/9/20138 from: HIMSS 2013 Interoperability Showcase Demonstration Playbook

Data Labeling Scope 07/9/20139 from: Guide to the HL7 Health Care Privacy and Security Classification System

HCS Security Labels Detail 07/9/ from: Guide to the HL7 Health Care Privacy and Security Classification System

HCS Security Labels Document masking and redaction using HCS Tags –Can be at CDA header, sections, and/or entries –Requires data segment information Binding elements to consent directive –Includes Clinical Facts, Clinical Attributes, Provenance Attributes, and Security Label Attributes –Examples: Medications: RxNorm Clinical Terms: SNOMED CT C32 sections: Logical Observation Identifiers Names and Codes (LOINC) codes C32 document: CDA header 07/9/201311

Security Observations Vocabulary 07/9/ from: Informative Example of HL7 Healthcare Privacy and Security Classification System Release 1 Using HL7 Security Observation Vocabulary

HCS Security Observations Detail 07/9/ from: Guide to the HL7 Health Care Privacy and Security Classification System

Using HCS in the J-UT Pilot Document masking and redaction scope –Can be at CDA header, sections, and/or entries –Requires data segment information –Requires shared concept of clinical document content Options –Use simple clinical document (C32, Patient Summary) –Apply to segmented and labeled clinical document –Interface with Security Labeling Service as “black box” Challenge –Incorporate HCS-required vocabulary and semantics in our data exchange (both to and from PCD repository) 07/9/201314

DS4P Integration Expectation of being a DS4P pilots: –Provide integration with other DS4P pilots –Participate in “end-to-end” demonstrations Benefits of being a DS4P pilot: –VA/SAMHSA pilot members have agreed to support the use of the HCS infrastructure in the J-UT pilot –We have access to several Subject Matter Experts (SMEs) DS4P pilots explore new approaches –We do not have to boil the ocean 07/9/201315

Functional Requirements Summary Precondition Functional Requirements –Document format for establishing authentication exchange * –Document format for exchange of repository account holder and HIO identifiers? (in proxy) * –Document format for clinical data request (NwHIN) Functional Requirements –Document format for requesting consent directive –Document format for returning consent directive –Document format for sending result of decision to consent directive repository Post-Condition Functional Requirements –Document format for exchange of repository location and account holder identifier to 2nd requestors associated with data 06/18/201316

Identifiers Problem: use of identifiers that can uniquely identify the healthcare consumer and PCD repository Correlation of the PCD? –Correlation error results in another’s PCD applied –Identifying (correct) subject of clinical document at multiple PCD results in conflicts No correlation of the PCD? –Subject of clinical document may have moved –Repositories may have moved –Can use correlation as a fall back 07/9/201317

Assumptions Identifier embedded in a clinical document: –Identify the subject –Identify the Repository Registry Repository Note: two repository SOAP endpoints Note: no issues with distributed XDS.b repositories –Be compatible with CDAr2 document –Provide access to the audit endpoint 07/9/201318

Proposed Construct 07/9/201319

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 Current summary: –Ability to mask PCD based on: –Data types, restrictions: Normal, Restricted –Specific restrictions –Classifications of data Health system planning Communicable test results 07/9/201320

2107/9/2013 Pilot Timeline General Timeline, conditioned on agreement of stakeholders

22 Relevant Standards Standards from previous discussions: XCA and/or XDS.b (IHE) XUA (IHE) – IHE profile includes SAML (OASIS) XCPD (IHE) – not fully integrated into DS4P IG ATNA (IHE) in ISO format – returned access decision log CDA r2 (HL7) – for PCD location in released clinical document – for format of the directive (includes XACML) XACML (OASIS) – specifically to PCD NwHIN specification ODD (IHE) - On-Demand Documents (Trial) Supplement Note: PCD (HL7) – just updated last WGM, will re-ballot 06/18/2013

2307/9/2013 Questions? For example: What level of control should the subject have over their records? When does too much control cause confusion? Would subjects or algorithms be setting the HCS options?

24 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/9/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 07/9/201325

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

2707/9/2013 Backup Slides

2807/9/2013 Pilot Data Flow 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 

2907/9/2013 Pilot Data Flow 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

3007/9/2013 Pilot 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

3107/9/2013 Pilot 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

3207/9/2013 Pilot 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 

3307/9/2013 Pilot 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 

3407/9/2013 Pilot 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 

3507/9/2013 Pilot 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 