Stream: implementers
Topic: provenance
Jayashree Surnar (Apr 21 2017 at 08:12):
hello all, can any one explain the purpose of provenance resource?
Lloyd McKenzie (Apr 21 2017 at 08:20):
Provenance captures details about where data came from - specifically what were the actions and/or data sources that led to the creation of one or more resource version instances. It lets you capture things like author, data enterer, data entry system, informant, witness, supervisor, entry location, attestation time, source record id, etc. In theory, there'll be a Provenance instance associated with every single resource version on a server, though in practice not all servers will support it and of those that do, not all will necessarily capture Provenance for every single resource
Jayashree Surnar (Apr 21 2017 at 08:43):
thank you @Lloyd McKenzie ,sorry for not asking exact doubt, actually i have not understand this, in concent resource.and how to implement that ?
in consent resource given.
Consent Directives are executed by verbal acknowledge or by being signed - either on paper, or digitally. Consent Signatures will be found in the Provenance resource (example consent and signature). Implementation Guides will generally make rules about what signatures are required, and how they are to be shared and used.
so please help.
John Moehrke (Apr 21 2017 at 12:53):
@Jayashree Surnar can you explain what kind of a signature you need? Most of the time today (FHIR 80% rule) there are no digital signatures, only a scanned into PDF of a persons ink signature on their paper consent. If you could explain your current system, I can help you understand how to represent it. I also am very interested in your current system as I lead the Privacy/Security efforts in FHIR and we are open to engagement.
Jayashree Surnar (Apr 24 2017 at 04:13):
hello @John Moehrke,we are building an ipad app, for one of the screen we are creating the Patient consent form. in that form we are creating the questions like
1.CARDIOPULMONARY RESUSCITATION: for a patient in cardiac or respiratory arrest
A) Do Not Resuscitate B) Attempt Resuscitation
2.VENTILATION: for a patient in respiratory distress
A) Do Not Intubate and Ventilate B) Intubate and Ventilate
etc.
user is going to sign on concent form and we are going to create a leagal doc.
for example patient has HIV and he doesn't want to tell that info to a doctor etc.
so how to manage the user access like
1.not showing atall
2.no access
3. access & edit.
Jayashree Surnar (Apr 24 2017 at 06:30):
actually we want to create these questions as part of concent and capture the signiture. while doing the R&D i gone through the provenance resource. there i found the signiture and what our doubt is can we use rovenance resource to capture that? or any otherway? and how to manage the user access?
John Moehrke (Apr 24 2017 at 13:35):
I know that the committee working on the Consent resource would be interested in your usecase. It seems you have two things you are controlling with that consent. The first part seems to be what is called an 'Advanced Directive', the second part would be a Privacy Directive. The Consent model would have you create two Consent resources to represent these things, and link them together. You should create a stream topic specific to that so that you get good input.
John Moehrke (Apr 24 2017 at 13:38):
On the Signature... what kind of a signature do you get from the patient? Do the patients have digital identities with which the make digital signatures? There are few regions I am aware of that have this, and even where it exists it is not used much. Thus most patient signatures are the old style ink-on-paper. These could be represented in the Provenance.signature.blob as a scanned image of that ink-on-paper. This however doesn't really require Provenance, as Consent.source[x] would work just as well.
Brian Postlethwaite (Apr 26 2017 at 05:44):
And I'd also question is the login context also relevant here, was it a patient portal that they do self service via, or is it a provider app that they hand over to the client for "signing". As the identify of the user may also be just as important.
Jayashree Surnar (Apr 26 2017 at 05:51):
@Brian Postlethwaite . it's a provider app.
Brian Postlethwaite (Apr 26 2017 at 05:55):
We have a similar mobile app (not currently in fhir) that we grab the image of the signature, along with the geo-code co-ords of the location of the device to provide assurance that the patient was there. Wasn't considering that we'd be using Provenance when we port it to FHIR, as its just data on the consent (in our case its a confirmation that the service was delivered - and hence we can pay the provider).
Jayashree Surnar (Apr 26 2017 at 05:58):
okay. thank you. @Brian Postlethwaite .
Mounika (Apr 26 2017 at 06:08):
Hi @Brian Postlethwaite I am using ClinFHIR in that scenarioBuilder,we are creating questions,but confusing little bit to create questions of type group.
John Moehrke (Apr 26 2017 at 12:19):
Consent has the Consent.source[x] to put your scanned image of the patient ink signature on the paperwork that is exactly what they signed. No need to go to provenenace.signatue for this. HOwever, it could also be recorded in a Provenance.signature as simply a scanned image of an ink on paper signature. It is possible, but for Consent there is already a more upfront solution.
Jayashree Surnar (May 02 2017 at 04:34):
thank you @John Moehrke .
rekha (Jan 02 2020 at 12:37):
Hi All,
While creating Patient resource ,Provenance will get created.In the same manner while updating the Patient,How can we retrieve the Provenance resource? Can anyone suggest me??
Thanks in advance.
John Moehrke (Jan 02 2020 at 13:21):
use _revinclude search parameter. The example given for this parameter is the use-case for getting all provenance for search results. http://build.fhir.org/search.html#revinclude
Tom Lipcsey (Apr 15 2020 at 20:53):
Are we as an EHR vendor, expected to keep a provenance history? Reading the examples, Hospital A prescribes a med. Hospital B accepts that med into their chart. By the documentation, Hospital B now becomes the owner. When i export that record to hospital C, i can only send one provenance record. Its seems logical to send my current provenance (Hospital B) So question is, should i store previous provenance that i receive from incoming records? TL:DR, should i keep only the most recent provenance record for each item?
Grahame Grieve (Apr 15 2020 at 21:00):
it's not clear what you are asking. As a matter of internal design, the answer is that you will need to keep audit records for everything, and sometimes those will include provenance infomration. Typically when you need to store the provenance, you need to keep it.
If you're asking about what to expose on a FHIR interface... then the requirements are less all-encompassing, though they trend in the same direction
Tom Lipcsey (Apr 15 2020 at 21:12):
Let me try to clarify and do this in small chunks. First, an ER doctor prescribes a new medication for a patient. He sends that medication w/ its provenance to me in my EHR via FHIR or C-CDA. I reconcile and save this new med in my EHR. What do i store as provenance, the original ER doctors information, or my own info because i accepted it into my system?
Grahame Grieve (Apr 15 2020 at 21:12):
who's you? the doctor?
Tom Lipcsey (Apr 15 2020 at 21:16):
Correct, i'm a provider in my EHR reconciling what i received from the ER doc.
René Spronk (Apr 16 2020 at 06:29):
IMHO: Two Provenance instances: one for the creator, one for the person that accepted/reconciled.
John Moehrke (Apr 16 2020 at 12:36):
Tom, are you asking about the Provenance IG, or about the basics of EHR requirements, or about the capability built into the Provenance resource?
Tom Lipcsey (Apr 16 2020 at 13:07):
I am looking for guidance as an EHR vendor as we are frequently exchanging data (send and receive) with external sources. My core question is do i as an EHR vendor need to store ALL the provenance i have received to share with the next source i share this information with, or to i just store the most recent only because that's all the FHIR resource has is room for one provenance per record? So if i received a med from an ER with a provenance from Dr. ER that is in the FHIR transaction. Per the Basic Provenance guide example, if i incorporate that with no changes into my EHR, i am now the author, (Dr. EHR).
Questions: Must i as an EHR vendor store both provenance records for that med? Dr. ER's creation and Dr EHR's acceptance?
When i export this med and share it down the line with the next provider, do i just send the most recent provenance (Dr. EHR) since i only have room for one in the FHIR message?
Thanks, hoping i'm making more sense now.
John Moehrke (Apr 16 2020 at 13:22):
Some of your question is about Legal EHR requirements, a topic that is neither FHIR specific nor HL7 specific. There is a HL7 specification on EHR Legal Medical Records requirements that might be informative to you.
- https://www.hl7.org/implement/standards/product_brief.cfm?product_id=86
- https://www.hl7.org/implement/standards/product_brief.cfm?product_id=18
John Moehrke (Apr 16 2020 at 13:23):
Some of your question is about the FHIR IG on "Basic Provenance"
- http://hl7.org/fhir/us/core/basic-provenance.html
@Brett Marquard will likely have some clarifications too
John Moehrke (Apr 16 2020 at 13:24):
You are not required to take on the Author role when you have received the data from outside. The expectation here is that the one that sent you the data would send you the author Provenance, and you would store this author Provenance; so that if you send the data somewhere else then you would have the author Provenance to forward along.
John Moehrke (Apr 16 2020 at 13:26):
You would also be expected to store who sent you the data, so that you could inform someone downstream from you, the provenance of the data.
John Moehrke (Apr 16 2020 at 13:27):
There is no limit to the number of Provenance you can have on any data object. I am wondering where you got that impression.
John Moehrke (Apr 16 2020 at 13:30):
I think your last question is around a data object that was created in the ER, forwarded to EHR1, forwarded to your system EHR2. I think you would be expected to save the author Provenance from ER, and the transmitter Provenance from EHR1, and you would create a transmitter Provenance if you send the data to someone else.
John Moehrke (Apr 16 2020 at 13:31):
in this way there is a provenance chain that can be followed. If the EHR1 transmitter Provenance was not saved, then there would be a break in this provenance chain, thus there would be broken provenance.
Tom Lipcsey (Apr 16 2020 at 14:08):
At this link, Figure 2 suggests that Dr. Accepted is the new author, i think this is where our confusion is coming from.
http://hl7.org/fhir/us/core/basic-provenance.html
From Figure 2:
Dr. Accepted is the latest author after verifying the problem on 5/2018 and accepting the problem data into their local data store, since it went through an interactive reconciliation process. This type of authorship change is only relevant for data fit for reconciliation, such as medications, allergies, problems. If Dr. Accepted had saved other clinical content into his EHR that aren’t reconciled but simply stored, such as clinical notes, that content must retain its original author.
Tom Lipcsey (Apr 16 2020 at 14:12):
Your point:
There is no limit to the number of Provenance you can have on any data object. I am wondering where you got that impression.
However, isn't there a limit to what you can send in the FHIR message?
John Moehrke (Apr 16 2020 at 14:24):
Tom Lipcsey said:
At this link, Figure 2 suggests that Dr. Accepted is the new author, i think this is where our confusion is coming from.
http://hl7.org/fhir/us/core/basic-provenance.htmlFrom Figure 2:
Dr. Accepted is the latest author after verifying the problem on 5/2018 and accepting the problem data into their local data store, since it went through an interactive reconciliation process. This type of authorship change is only relevant for data fit for reconciliation, such as medications, allergies, problems. If Dr. Accepted had saved other clinical content into his EHR that aren’t reconciled but simply stored, such as clinical notes, that content must retain its original author.
The "since it went..." clause in this paragraph is recognizing that Dr Accepted has added value to the data by reviewing it in the context of reconciliation. If it is just imported , this would not be the case, it would be more like I described above.
I would agree that the title of this section seems to use a generic term "Accepting..." which might be read the way you read it.
You could enter a CR that would be handled in the next revision.
John Moehrke (Apr 16 2020 at 14:25):
Tom Lipcsey said:
Your point:
There is no limit to the number of Provenance you can have on any data object. I am wondering where you got that impression.However, isn't there a limit to what you can send in the FHIR message?
Not practically. yes there are often technical constraints, but those constraints are not likely to be met by a few Provenance instances.
James Dinsmore (Jul 13 2020 at 16:16):
For the R4 US Core Provenance profile are we required to support versioning? Are we required to support versioning for any of the R4 US Core profiles?
John Moehrke (Jul 13 2020 at 18:09):
I don't think so. It is clearly easier to track changes with versioning support. But my understanding of Basic Provenance is that it is just looking for recording Provenance of the import activitity, not that it is recording all the specific changes made during that import.
Seikh Bahar (Dec 07 2020 at 18:18):
Hi all. Need a help understand on understanding Provenance profile and how it should be used : https://www.hl7.org/fhir/provenance.html .
Are we suppose to provide audit trail for every other single resource ( CarePlan, Goal etc..) via Provenance or it should be used as a audit trail for all the resources combined ?
Please let me know if my question makes sense. Thanks in advance!
Daniel Venton (Dec 07 2020 at 19:18):
The guide does say that 1 provenance resource can be a provenance for a set of records. I, personally, think of provenance resource as applying to a single other resource. But I can see the use case of 1 provenance to represent a panel + the observations. Or perhaps there is a set of procedures that typically occur in lock step but are recorded individually for whatever reason. Perhaps there would be 1 provenance for all items modified during an encounter. (one person modifies multiple items simultaneously (bound by event)).
To me it would be reasonable that you'd have a set of provenance for a single resource or a set of provenance for a set of tightly bound other resources, but to have 1 set of provenance for the 1 set of all other resources, seems like a stretch.
If you do, you'll have to make sure the agent is clear. Dr. Bob and Dr. Bill and Dr. Dan were the agents of change of all resources. Really, all 3 of them changed all the resources at the same time?
Bob Milius (Dec 07 2020 at 19:56):
We use a single provenance to describe all the resources created in a transaction bundle that was created by data exchange tooling. It also points to a device resource (agent.whoReference) representing the software and version of the tool used to create the bundle.
Lloyd McKenzie (Dec 07 2020 at 23:13):
Generally, there's one Provenance per 'action'. Some actions manipulate a bunch of resources at once.
Seikh Bahar (Dec 09 2020 at 22:16):
Thank you everyone for your thoughtful response. In simpler words, we are trying to communicate metadata of an event to a patients health not the metadata of the table record itself. Did I get it right?
Lloyd McKenzie (Dec 10 2020 at 03:15):
Provenance is typically more about the 'record' side of things than the 'health' side of things. If you take a CDA document and run an extraction routine to produce a bunch of resources, that's not a "health" action at all. It is, however, a 'system' action, and as a single action, it would typically produce a single Provenance instance.
Anusha (Feb 23 2021 at 19:26):
Hi everyone. I'm trying to parse the PDEX SHALL requirements related to Provenance (as a payer implementing the IG).
- In addition to the
searchRevIncludeinteraction, is the expectation that a client application should be able to query a bundle/resource and then return to the FHIR server _n_ days later and get the provenance for that bundle/resource using the bundle/resource reference? - The timestamp that's captured in the
recordedfield should always be the Date/Time that the payer received the information or created the bundle -- is that correct?
Lloyd McKenzie (Feb 23 2021 at 20:18):
You might want to ask on #Da Vinci PDex
Lital Inghel (Sep 22 2021 at 15:29):
hi
I wonder about the difference between Provenance author and the recorder of a clinical act (such as procedure). what is the difference?
thanks!
Michele Mottini (Sep 22 2021 at 15:35):
For a lab result the author could be the lab itself and the recorder the EHR system (and/or person) that received that lab report
Michele Mottini (Sep 22 2021 at 15:36):
(as an example)
John Moehrke (Sep 22 2021 at 15:39):
that would be a good one to make into an example of Provenance in the core spec. Can you write that up with example as a CR?
Michele Mottini (Sep 22 2021 at 15:54):
{
"resourceType": "Provenance",
"id": "8-bfe992b8d8644f48b459fffebd2df7d6",
"meta": {
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-provenance"
]
},
"target": [
{
"reference": "DiagnosticReport/4.bfe992b8d8644f48b459fffebd2df7d6"
}
],
"occurredDateTime": "2015-08-11T07:13:28.14+00:00",
"recorded": "2015-08-11T07:13:28.14+00:00",
"activity": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-DataOperation",
"code": "CREATE"
}
]
},
"agent": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
"code": "AUT",
"display": "Author (originator)"
},
{
"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
"code": "author"
}
],
"text": "Originating organization"
},
"who": {
"reference": "Organization/86ebdb60-e00a-e511-943a-8cdcd4a8b5cd",
"display": "EDW Patient Record Authority"
}
},
{
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/us/core/CodeSystem/us-core-provenance-participant-type",
"code": "transmitter"
}
],
"text": "Transmitter"
},
"who": {
"display": "EdwLabsLoad",
"identifier": {
"use": "official",
"system": "http://anthem.com/typeid/Application",
"value": "292"
}
},
"onBehalfOf": {
"display": "SystemUser",
"identifier": {
"system": "urn:ietf:rfc:3986",
"value": "urn:uuid:3539c314-6e5b-4864-87c1-1195e7e2adcd"
}
}
}
]
}
Michele Mottini (Sep 22 2021 at 15:55):
^ example from our system - author is EDW (an external system we get data from), transmitter is EdwLabsLoad - the sub-system we use to import that data
Last updated: Apr 12 2022 at 19:14 UTC
