Overview

The Provenance resource tracks information about the activity that created, revised, deleted, or signed a version of a resource, describing the entities and agents involved. Whenever patient records or patient record items are created or amended an associated provenance record can also be recorded which details the entities and processes responsible for the update.

For example:

• When a Patient resource is updated as a result of a HL7 v2 demographics update message, a Provenance resource can be created that references the new version of the Patient resource, together with details of the system responsible for sending the message and the component responsible for processing the update. The Provenance resource may also provide a link to HL7 v2 message that triggered the update.
• A clinical system record a new Observation resource to a datastore via a FHIR API. An additional Provenance resource can also be recorded by the originating system to indicate that it was responsible for inserting the new Observation record.

Provenance resources can be used in this way to provide information about the context in which the information in a resource was obtained, and to provide traceability in order to fix bugs and maintain data quiality.

The data recorded within a Provenance resource is in addition to other items of reference data recorded as part of a FHIR resource, such as the clinician (Practitioner) responsible for adding new data, or the Encounter during which the data was recorded. This data is generally included within the definition of the FHIR resource e.g. the clinician responsible for an observation is recorded in the Observation.performer field.

Data Model - Provenance

The diagram below shows the relationship a Provenance resource, and the systems (or agents) an entities responsible for the data update.

Note that in the model above, the Device resource is used to indicate the systems involved in the data update. If these resources do not exist within the datastore, then a logical reference may be used instead (see example 2)

The DocumentReference resource can be used to provide a link to the message that can be included as an attachment or via a URL link.

Examples

The following examples are based on the model above:

• Provanance
  • Device (Welsh PAS)
  • Device (component of CDR)
  • DocumentReference (provenance)

This alternative Provenance example demonstrates how logical references can be used where Device resources are not available in within the data store.

Provenance and the Care Data Repository

Provenance data MUST be recorded for all FHIR resources that are stored within the Care Data Repository within the National Data Resource. As a minimum, details of the contributing system must be recorded as part of the Provenance data. All systems writing data via FHIR API calls are responsible for recording this data correctly.

This is required in order to maintain traceability of data, and to facilitate the management of data that may have originated from many different sources.

Activity Codes

The Data Standards Wales Provenance FHIR profile binds the Provenance.activity field to the Data Standards Wales Provenance Activity value set. The table below provides additional guidance when seeking to determine the most appropriate value for this field when adding data to the Care Data Repository.

Extension-DataStandardsWales-DemographicsAsRecorded

Some data has additional requirements to record the original patient demographics against the data to be recorded. Patient demographic data may change over time as the patient changes address or name, or whenever data is corrected if entered incorrectly. In order to maintain the original demographics as recorded, a Provenance resource containing the original demographics held within the Demographics as recorded extension.