Where does responsibility for the Provenance resource lie?
The FHIR documentation is clear on this: “Provenance resources are prepared by the application that initiates the create/update etc.”
Sounds straight forwards and unambiguous. There shouldn’t be any more to say on the subject.
But as with many things FHIR, not everything is as straight forwards as you might expect. The real-world often intrudes with its own set of “What ifs?”
Let’s say you have a FHIR server sitting at the heart of your solution. Many applications are accessing the server. Some are performing GET requests to read data. Others are sending POST and PUT requests to create or update resources.
In line with the FHIR standard, each application or source that is sending data to your server should be accompanying it with a Provenance resource documenting the role they played in creating or updating that data.
An example might be the creation of a new Observation captured during an Encounter between a Patient and a Practitioner.
The app sending the Observation would normally use a transaction Bundle containing the Observation along with a Provenance resource that referenced the Observation via the “target” element. The source of the data would be clearly identified in the agent.who element of the Provenance.
All clear and unambiguous — a textbook use of the Provenance resource.
But…
It’s your FHIR server, containing data that you manage and are responsible for. Are you really going to take the word of an external app that it has correctly identified itself and correctly populated all the necessary elements of the Provenance.
Here’s a common set of steps for a server (or server façade) to perform:
- Verify the source of the incoming data via the source’s authentication (client ID, token, API key, etc.)
- Verify that a Provenance exists in the incoming Bundle
- Verify that the Provenance.agent.who data matches the authenticated source
- If required, add an extra agent to the Provenance that documents that source in a way you expect
- Verify that the Provenance.target correctly references all resources in the Bundle being created or updated.
A more robust and forward thinking FHIR server might also update the Provenance after the Bundle was processed to add a version number to the Provenance.target element that references a specific version of the Observation.
Provenance resources are prepared by the application that initiates the create/update.
Yes — but it shouldn’t stop here. Sometimes you need to take at least partial ownership of that Provenance in order to verify and expand out the details it contains.
The FHIR documentation presents the ideal. The real-world sometimes requires you to expand on that ideal to ensure data quality and consistency.
Remember: it’s your FHIR server and you are responsible for the data it contains.
---