Basic Data Provenance April 22, 2019 HL7 Security Work Group working session

Montreal WGM Preferred quarter to discuss Basic Provenance Tuesday Q4 + Wednesday Q1 (joint with EHR) Items to cover Review selected use cases Recap key basic provenance fields to display (discussion starts on this call!) Handling of more detailed provenance when provided Summer plans Latest developments from USCDI Continue alignment with broader provenance efforts

Timelines Task Date Develop priority use cases 2019 May WGM Submit for Informative Ballot(First Ballot Cycle) 2019 Sep Ballot Complete Informative Reconciliation 2019 November WGM Request Informative Publication 2019 Dec Project End Date 2020 Feb

What is purpose of the Provenance Information? Help a clinician

Thoughts from the DoD and VA DoD and VA have a special viewer (JLV) that shows HIE data provenance Primary clinical use of this provenance info is to quickly find the right data Secondary clinical use is as provide context for the data Provenance data is extracted from various XPaths in CDAs (document, section, entry), but always from an author.assignedAuthor.representedOrganization

A Key Purpose of Basic Provenance Project Provide organizational context for external patient data, when displayed to the Clinician. -Source organization

Scenario 1: “Fax” What should be displayed to the user? Point to point exchange between two sites. (e.g. DIRECT, patient provided upload). Not ‘imported’ yet. Assumption throughout, only Author at header for discussion today. Will adjust in future. Who - Author of the information (could What - Action taking – lab report? When - Date/time stamp – possibly many but intended to match the particular exchange. Where - could be physical location, or network location, etc. Why - rationale for the test

Scenario 2: HIE Redistribution Is additional information beyond Scenario 1 required for the end-user? Information is received by a provider from a HIE. The HIE received the information, stored it, and then passed with no content change. HIE Information could be stored – Not changed! Query/retrieve Push

Scenario 3: HIE Transformation What does the receiving end-user expect to see? Information is received (e.g. v2 lab, other CCDs) and transformed by an HIE, stored, and then passed in a new format (CCD). Source data is not manipulated beyond transforming into a new format. HIE Consider *3a – Change translations, code systems, automated deduplication. *3b – ‘Data enrichment’ – Care gaps, potential manual deduplication. What additional information is captured when HIE transforms the information into a new format? Includes: - Automated deduplication - Adding translations

Scenario 4: “Clinical Information Reconciliation and Incorporation (CIRI)” Provider stores information in their system – may have made changes. Provider sends information to another provider (e.g. DIRECT).

Backup

Out of Scope Items Content Scope: “Data Classes” NOT listed in draft USCDI Full chain of custody Provenance of how information is created, and managed within an EHR Organizational policies on which individual authors to include Blockchain Assigning a level of trust to the person/system assigning the provenance Additional metadata elements to support data reconciliation

Prior Provenance Efforts Data Segmentation for Privacy (DS4P) FHIR Provenance Resource FHIR Provenance Profile directly in FHIR core HL7 Version 3 Standard: Privacy and Security Architecture Framework - Volume 3 Provenance, Release 1 (recent ballot) EHR Functional Model (profile on the FHIR Provenance resource) IHE set of profiles - MHD profiles, QEDM, RECON profile ONC Challenge for tracking provenance ONC S&I Initiative on Data Provenance (led to CDA IG) HL7 CDA R2 Data Provenance (written by CBCP) EHR Lifecycle events – how an EHR manages a record over lifecycle events – focused on CRUD (27 lifecycle events)