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:

1. State of Healthcare Provenance today
2. Blockchain Provenance Service
3. Basic Provenance Use-cases

Good morning,

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.

Regards,

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 Task resource).
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? 

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?

  https://chat.fhir.org/#narrow/stream/179166-implementers/topic/C-CDA.20Provenance.20Sample