This page is part of the FHIR Specification (v4.5.0: R5 Preview #3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles & Extensions
• R3 Conversions

6.3 Resource Provenance - Content

Security Work Group

Maturity Level: 3

Trial Use

Security Category: Not Classified

Compartments: Device, Patient, Practitioner, RelatedPerson

Provenance of a resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that resource. Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance. Provenance statement indicates clinical significance in terms of confidence in authenticity, reliability, and trustworthiness, integrity, and stage in lifecycle (e.g. Document Completion - has the artifact been legally authenticated), all of which may impact security, privacy, and trust policies.

6.3.4 References

This resource is referenced by Contract, DeviceRequest, MedicationAdministration, MedicationDispense, MedicationRequest, ServiceRequest and Task.

This resource implements the Event pattern.

6.3.5 Resource Content

 

See the Profiles & Extensions and the alternate definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis a

6.3.5.1 Terminology Bindings

Path	Definition	Type	Reference
Provenance.reason	The reason the activity took place.	Extensible	PurposeOfUse
Provenance.activity	The activity that took place.	Extensible	ProvenanceActivityType
Provenance.agent.type	The type of participation that a provenance agent played with respect to the activity.	Extensible	ParticipationRoleType
Provenance.agent.role	The role that a provenance agent played with respect to the activity.	Example	SecurityRoleType
Provenance.entity.role	How an entity was used in an activity.	Required	ProvenanceEntityRole

6.3.5.2 Using the Provenance Resource

The Provenance resource identifies information about another resource (the reference element). The Provenance resource may be used in several different ways:

• As part of a document bundle where it identifies the provenance of part or all of the document
• On a RESTful system where it keeps track of provenance information relating to resources

When used in a document bundle, the references are often not explicitly versioned, but they always implicitly pertain to the version of the resource found in the document. On a RESTful system, the target resource reference should be version specific, but this requires special care: For new resources that need to have a corresponding Provenance resource, the version-specific reference is often not knowable until after the target resource has been updated. This can create an integrity problem for the system - what if the Provenance resource cannot be created after the target resource has been updated? To avoid any such integrity problems, the target resource and the Provenance resources should be submitted as a pair using a transaction.

6.3.5.2.1 HTTP Header

The custom header X-Provenance to provide a provenance resource when performing PUT or POST operations using the RESTful interface:

POST [base]/Observation
Content-Type: application/fhir+?
X-Provenance: { "resourceType": "Provenance", "location": { "reference": "Location/1" }," agent" ... }

[body]

The intent is that the server picks up the provenance, fills out the target, and then stores the provenance information as it normally would. Notes:

• Irrespective of the Content-Type or Accept headers, the Provenance resource is in the JSON format
• The provenance SHALL not have a specified Provenance.target. The server will fill the target in as it processes the contents of the POST/PUT and determines the ids of the resource(s) to which the interaction applies
• Servers MAY ignore the header, but SHOULD process it if they support provenance
• Some server frameworks impose a length limit on individual HTTP headers, or on the the headers as a whole. Servers MAY reject a request if the X-Provenance header is too long
• The use of the header is not documented for other HTTP methods (GET etc)

6.3.5.3 Signatures

The Provenance resource includes a signature element (digital signature) which can be used for standards based integrity verification and non-repudiation purposes. The Signature datatype provides details on use of the signature element. The Signature.type coded value of "Source" should be used when the signature is for simply proving that the resource content is the same as it was when the resource was updated or created.

6.3.5.4 Provenance of Removal

A Provenance record can be recorded to indicate who deleted a Resource. If versioning is supported, the version that was deleted is referenced in Provenance.target; if versioning is not supported then Provenance.target contains the non-version reference. Provenance.entity is not used unless there is a business requirement to do so.

6.3.5.5 Use of Provenance to record Import and Transform

Provenance can be used to record activities of an automaton that transforms input. Such as middleware that extracts information from a HL7 v2 message and creates FHIR resources, or middleware that extracts information from an HL7 CDA document and creates FHIR resources, etc. The Provenance in these cases is recording the activity of the middleware.

The middleware in this case would, in addition to creating the target resources, create a Provenance resource that indicates all the target resources (using Provenance.target). The middleware is identified as one of the Provenance.agent elements, with the Provenance.agent.type of assembler.

The middleware may record the source as another Provenance.agent element.

The original content is optionally saved. This might be as a DocumentReference, or Binary. The Provenance.entity would then point at this original content.

The original source might include some form of 'provenance' to cover the history of the original content prior to the import transformation. This original source 'provenance' should be converted into FHIR Provenance records as appropriate.

Examples of this activity with Provenance profile can be found in the IHE Implementation Guides for

• Query for Existing Data for Mobile - QEDm
• Reconciliation of Clinical Content and Care Providers - RECON

6.3.6 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name	Type	Description	Expression	In Common
activity	token	Activity that occurred	Provenance.activity
agent	reference	Who participated	Provenance.agent.who (Practitioner, Organization, Device, Patient, PractitionerRole, RelatedPerson)
agent-role	token	What the agents role was	Provenance.agent.role
agent-type	token	How the agent participated	Provenance.agent.type
entity	reference	Identity of entity	Provenance.entity.what (Any)
location	reference	Where the activity occurred, if relevant	Provenance.location (Location)
patient	reference	Target Reference(s) (usually version specific)	Provenance.target.where(resolve() is Patient) (Patient)
recorded N	date	When the activity was recorded / updated	Provenance.recorded
signature-type	token	Indication of the reason the entity signed the object(s)	Provenance.signature.type
target	reference	Target Reference(s) (usually version specific)	Provenance.target (Any)
when	date	When the activity occurred	(Provenance.occurred as dateTime)