Develop an Informative Implementation Guide in the US Realm to specify functional and technical guidance on what constitutes minimal “provenance”. This guidance should inform future implementations of the data class identified in the US Core Data for Interoperability published by the Office of the National Coordinator.
Specifically, the IG will include technical guidance for C-CDA 2.1, and US FHIR Core (based on R4). Guidance will be limited to the set of data classes identified in the US Core Data for Interoperability, and any additional information needed to convey those data classes within C-CDA and FHIR.
The Draft U.S. Core Data for Interoperability and Expansion Process, published by ONC on Jan 5, 2018 indicated 22 “data classes” in the list of Draft USCDI Version 1 Data Classes. While many of those data classes have already been well defined within the C-CDA and FHIR standards, “provenance” has not been. For interoperability to be achieved with this data class, functional and technical guidance are needed regarding what details constitute “provenance”, which data classes should be conveyed including provenance information, and technically how provenance information should be represented in the C-CDA and FHIR standards.
- Security WG (sponsor)
- Historical references and guidance on provenance attributes
- Patient Care WG (co-sponsor)
- Selection of data classes for which provenance is important
- Selection of provenance attributes that should be required
- Structured Documents WG (co-sponsor)
- C-CDA 2.1 technical guidance
- EHR FM (co-sponsor)
- FHIR EHR-LR IG technical guidance
- Legal Medical Record expertiese
- CBCP (co-sponsor)
- Prior CDA Data Provenance IG owner
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
2020 Jan WGM
Project End Date
Every 2 weeks starting March 25, 2019
3:00 PM - 4:00 PM ET (GMT -5)
Phone: +1 515-604-9567, Participant Code: 880898
Call Details | Edit | Cancel | Delete |
Online Meeting Link: https://www.freeconferencecall.com/join/security36
Visit http://www.hl7.org/concalls/CallDetails.aspx?concall=43654 for the full details of this call
HL7 Project Scope Statement v2018.2_Provenance 20190114_v02.docx
Basic Provenance Project Materials
20190719_HL7_Basic_Provenance_Security_Posting.docx - draft of Ballot Content for approval to proceed to ballot
BasicProvenance_20190422_v2 - 201905 WGM ppt
Draft Basic Provenance Informative Implementation Guide for Security WG Review
Final Basic Provenance Reconciliation Spreadsheet 20200218_HL7_PROVENANCE_CCDA_FHIR_R1_I1_2019SEP_Amalgamated.xls
This list of references to Provenance is likely to be leveraged by this Implementation Guide.
•HL7 Implementation Guide: Data Segmentation for Privacy (DS4P)
•FHIR Provenance Resource
•FHIR EHR Record Lifecycle Event IG with Provenance Profile directly in FHIR Core R4
•HL7 Version 3 Standard: Privacy and Security Architecture Framework - Volume 3 Provenance, Release 1 (recent ballot)
•IHE set of profiles - mXDE – MHD profiles, QEDM, RECON profile – Provide clear Provenance to support use-case where FHIR Resources have been extracted from Documents.
•ONC Challenge for tracking provenance
•ONC S&I Initiative on Data Provenance (led to CDA IG)
•HL7 CDA R2 Data Provenance (sponsored by CBCP, co-sponsoerd by Security)
•ISO specifications on EHR Lifecycle events – how an EHR manages a record over lifecycle events – focused on CRUD (27 lifecycle events)
ISO 21089:2018 - Trusted End-to-End Information Flows (27 Record Lifecycle Events, including provenance specification where applicable)
Trusted End2End Interoperability-20190319.pdf
ONC-SI-DPROV-System Event Matrix-20161111.pdf
• FHIR Record Lifecycle Event Implementation Guide (RLE IG), part of FHIR Core R4 (27 Lifecycle Events, including Provenance Resource Profile as applicable)
• ISO/HL7 10781:2014 - Electronic Health Record System Functional Model, Release 2, Information Infrastructure Section (24 Record Lifecycle Events, including provenance specification as applicable)
• HL7 Electronic Health Record System Functional Model, Release 2.1, passed ballot January 2019, being prepared for publication (27 Record Lifecycle Events, including provenance specification as applicable), will be advanced to ISO as ISO/HL7 10781:2019
• HL7 Personal Health Record System Functional Model, Release 2, passed ballot January 2019, in reconciliation (27 Record Lifecycle Events, including provenance specification as applicable), will be advanced to ISO as ISO/HL7 16527:2019
Provenance Definitions from Standards
Basic stepping stone, not comprehensive set of use-cases.
Concurred with prior discussion:
- Who ‘authored’
- Who ‘handed to you’
- Data, and metadata for the purposes for trust, traceability and identification of ‘Who’ and ‘When’
- Capture at least the last system that provided, if not the full chain of provenance. The full chain can be recreated by asking each system that is ‘one-hop’ prior. The system that provided you the data
- It’s not inherently bad to contain the full chain, but that may not be possible
- Likely the CDA Prov already provides sufficient details for CDA. There is a definition of various levels of effort that could be pointed out as minimally acceptable - Basic Provenance - support
- Likely the FHIR EHR-LR Implementation Guide provides sufficient details for FHIR. There are likely a subset of events that could be chosen for minimally acceptable - Basic Provenance - support
- IHE mXDE profile could be promoted as a best case when an externally sourced Document is decomposed into FHIR Resources that are served up. Such as an HIE that provides a FHIR api. The Provenance specified in mXDE binds the FHIR Query results to the source Document from which that data was extracted.
- Are the use-cases explicitly only those involving external (Import/Export) functionality? That is to say, are we considering internally generated data (fully within the EHR control)? This seems to be the focus of the US Core Data for Interoperability.
CDA Prov has expired.
Discussion in CBCP indicates that the are willing to re-invigorate this if it is needed.
DS4P may contain the same level of Provenance detail as might be needed by this Basic Provenance IG work. DS4P is more widely understood and is being actively maintained.
I just published three blog articles on the topic of Provenance. They are my statements, not intended to be a statement of anyone else:
Reed D. Gelzer
I see that EHR is a co-sponsor and "Legal Medical Record" expertise is noted as a contribution.
Unfortunately, those of us mainly working in U.S. domain law in EHR WG are otherwise committed to our test of concept for the Montreal Connectathon and do not have sufficient bandwidth to cover this project as well. We welcome episodic opportunities to compare notes, review.
First please note that we are designing. as noted above, a very preliminary "test of concept" for the Montreal Connectathon for leveraging the Record Lifecycle Events as in EHR FM R2, extended in ISO, captured in FHIR 4.0. The limited "lift" is to represent a set of key authenticity attributes as specified against the US domain legal definition of "Authenticity". This definition, and its relationship to solving critical gaps in current US EHRs, is one of the topics detailed in the 2017 peer-reviewed publication The Sedona Conference Journal. Note that this article also offers additional detail on the criticality of data source capture in To Originate as precursor to Retain in the first Record Lifecycle Event where Originate+Retain = Create in CRUD.
The Sedona Conference is an international convening organization for developing consensus on key challenges in law and legal process.
Here is a link to the article: https://s3.amazonaws.com/IGG/publications/EHR.TSC.Vol18.rev.pdf
Here is a link to the organization: https://thesedonaconference.org/ "Moving the law forward in a reasoned and just way"
A number of earlier law review articles on key US legal concepts for EHRs are in the bibliography. I will separately send one that was published by three EHR WG supporters with a forward by the renowned digital evidence SME, George Paul.
The Connectathon work is intended to be the first of a long series of "builds" for testing how source system attributes that differentiate accuracy and authenticity requirements for different end-uses and end-users. In that series our works will undoubtedly converge.
I would also recommend that, in support of "authenticity competence" in US domain EHRs, you include the ASTM Standards for audit functions that remain U.S. law insofar as they are included by reference in HITECH. Legal practice experts repeatedly point to the substantial improvements in affirming authenticity if that law was actually enforced. (While those standards have since been updated with more stringent requirements, the prior Standards remain U.S. law unless replaced by the HHS Secretary). One of the more vocal patient advocates on this topic, lawyer Jon Lomorro recently appearing in the Kaiser Family Foundation/Fortune article on why EHRs have so far fallen short. This editorial summarizes that article and links to it. It also has a video with Mr. Lomorro and also our HL7 colleague Galen Mulrooney. It also links to an upcoming conference. http://fortune.com/2019/03/18/healthcare-ehr-brainstorm-health/
Lastly, it will be useful to note that "Legal Medical Record" is a term of art, a legacy term that persists in many organizations' policies and procedures manuals despite its progressive replacement, as indicate in HIPAA, with "Designated Record Set for purposes of _____________". In the law and legal process alone there are multiple output types to fill in that blank with a named end-use. While it will take time to wind down the old "Legal Medical Record" concept, it would be useful to keep the digital-records relevant term in mind. At some point you may want to transition to Designated Record Sets, general subcategory, "for law or legal process"
Best wishes for your work. I regret we cannot cover your work concurrently and recommend a regular touch base. Since we have a vested and engaged set of end-use stakeholders, our primary focus is on instantiating the end-use requirements of the interest group assembled by Dr. Michael Brody for the EHR Workgroup's Podiatry Profile project. We've recently converged with CIMI's extensive work on a related data set as a project expansion and added EHR vendors and a Registry as well.
Inquiries and cross-coordination are always welcome. Best wishes with your works. Undoubtedly our related initiative will be of interest to your group as yours is to ours.
Reed D. Gelzer, MD, MPH
Trustworthy EHR, LLC
Facilitator, RMES and Co-Facilitator, Podiatry Profile
Here's the System Event Matrix we developed in conjunction with the S&I DPROV Initiative. It shows data provenance events as health data/records flow from source to use across a single point of exchange. Note that it includes points of assemble/disassemble where data/records are transformed algorithmically (to/from exchange artifacts) before and after exchange vs. compose/decompose where the same thing is happening with human (clinician) intervention before/after exchange.
Here's another perspective on end-to-end health data/record interoperability, developed using the Collect/Share/Use paradigm of the ONC Interoperability Roadmap and noting where FHIR Provenance resource instances might be applied.
usecase for consideration (likely not in scope) from Mohammad Jafari --
There is a bulk-data export for the purpose of population-level research. The provider has to redact personal information and de-identify the outgoing data. The provider needs to communicate to recipient some metadata about the applied transformations (e.g. de-identification methods, algorithms used, etc.). A single provenance resource can be created for the entire exported resource set (or maybe associated with the result resource like a
I'd be very interested to see the use-case set document; it might be beneficial if it can be made public like in github repo so that people can post pull-requests with new use-cases. I'm also happy to volunteer to do some of this work since provenance is of interest for Mike right now and I have the tasking to do that.
Why is BDT not in scope given that the test procedures §170.315(g)(10) Standardized API for patient and population services references § 170.215(a)(2) API Resource Collection in Health (ARCH) Version 1, which includes Provenance, including mandatory support for “Provenance.agent.actor” (for the author and author’s organization) and “Provenance.recorded” elements.
Note that IHE QEDm profile now has updated FHIR R4 conformance resources including a profile on Provenance. See https://github.com/IHE/fhir/blob/master/StructureDefinition/structuredefinition-IHE_QEDm_Provenance.xml
Did you compare to the published Draft Argonaut Provenance Profile?
I did not, as QEDm has specific requirements. It is not trying to be generic.
Brett, can you provide access to current draft of ballot reconcilled text?
Thanks for checking in John – I haven't started implementing comments. I posted the latest ballot excel file to our last call minutes.
There is a question on ZULIP asking for an example of CDA implementing DPROV. Are there examples?