This page is part of the FHIR Specification v6.0.0-ballot3: Release 6 Ballot (3rd Draft) (see Ballot Notes ). The current version is 5.0.0 . For a full list Continuous Integration Build of available versions, see FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions

• Content
• Examples Detailed Descriptions
• Detailed Descriptions Search Params
• Mappings
• Operations Examples
• Search Params Operations
• Profiles
• Extensions

6.3 Resource Provenance - Content

Responsible Owner: Security Work Group

Maturity Level : 4   Trial Use Normative

Security Category : Not Classified

Compartments : Device , Group , 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 MAY impact security, privacy, and trust policies.

6.3.4 References to this Resource

• Implements: Event
• Resource References: Contract , DeviceDispense , DeviceRequest , MedicationAdministration , MedicationDispense , MedicationRequest ... Show 4 2 more , MedicationRequest , ServiceRequest , Task and Transport Task
• Extension References: Event history and Relevant history

6.3.5 Resource Content

 

Additional definitions: Master Definition XML + JSON , XML Schema / Schematron + JSON Schema , ShEx (for Turtle ) + see the extensions , the spreadsheet version & the dependency analysis

6.3.5.1 Terminology Bindings

Path	ValueSet	Type	Documentation
Provenance.authorization	PurposeOfUse	Example	Supports communication of purpose of use at a general level.
Provenance.activity	ProvenanceActivityType	Example	Some potential code systems are: v3-DocumentCompletion v3-DataOperation v3-ActCode ISO Lifecycle FHIR RESTful interactions W3C PROV Activity Types
Provenance.agent.type	ParticipationRoleType	Example	This FHIR value set is comprised of Actor participation Type codes, which can be used to value FHIR agents, actors, and other role elements. The codes are intended to express how the agent participated in some activity. Sometimes refered to the agent functional-role relative to the activity.
Provenance.agent.role	SecurityRoleType SecurityRoleTypeExamples (a valid code from Sample Example Codes for Security Structural Role )	Example	This value set contains example structural roles. In general, two types of roles can be distinguished: structural roles and functional roles. Structural Roles reflect human or organizational categories (hierarchies), and describe prerequisites, feasibilities, or competences for actions. Functional roles are bound to the realization or performance of actions.
Provenance.entity.role	ProvenanceEntityRole	Required	How an entity was used in an activity.

6.3.5.2 Constraints

6.3.5.3 Using the Provenance Resource

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

• As part of a Bundle where it identifies the provenance of part or all of the resources in the Bundle (e.g. Documents )
• On a RESTful system where it keeps track of provenance information relating to resources

The resources found in a Bundle are often the latest version and don't have a version identified , yet Provenance resources in the Bundle may MAY have references (e.g. .target) to version specific resources. When de-referencing resource references that may MAY have a version identified one should SHOULD look for the non-version resource found in the Bundle.

On a RESTful system, the target resource reference should 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 SHOULD be submitted as a pair using a transaction (see the Transaction Example ). Alternatively, the Provenance http header may MAY be used if supported.

6.3.5.3.1 Element Level Provenance

The Provenance.target may MAY point at a specific element within the targeted resource using the target element extension or target path extension . For example when updating a Patient resource with a new official name, such as shown in example 1 , where the Provenance is indicating that the official name was provided by the Patient themselves.

6.3.5.3.2 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.)
• When recording an AuditEvent, one AuditEvent may MAY be used to record the create of the resource and provenance

6.3.5.4 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 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.5 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.6 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 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 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.5.7 Multiple Patients Affected

Where a provenance activity impacts more than one Patient/Subject; multiple Provenance resources should SHOULD be recorded, one for each Patient/Subject. This best enables segmentation of the Provenance details so as to limit the Privacy impact. The use of multiple Provenance is a best-practice and should SHOULD be driven by a Policy. There will be cases where the use of multiple Provenance resources is not necessary, such as public health reporting.

6.3.5.8 Relevant History Provenance

Some Event pattern or Request pattern resources will have a relevantHistory element. These elements would point to a subset of all Provenance about that resource that are considered relevant. For further guidance on relevantHistory see Event history pattern or Request history pattern.

6.3.6 Search Parameters

Search parameters for this resource. See also the full list of search parameters for this resource , and check the Extensions registry for search parameters on extensions related to 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 , Group , Organization , CareTeam , Device , Patient , HealthcareService , PractitionerRole , RelatedPerson )
agent-role	token	What the agents role was	Provenance.agent.role
agent-type	token	How the agent participated	Provenance.agent.type
based-on	reference	Reference to the service request.	Provenance.basedOn (Any)
encounter	reference	Encounter related to the Provenance	Provenance.encounter ( Encounter )	28 27 Resources
entity	reference	Identity of entity	Provenance.entity.what (Any)
location	reference	Where the activity occurred, if relevant	Provenance.location ( Location )
patient	reference	Where the activity involved patient data	Provenance.patient ( Patient )	64 61 Resources
recorded	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.ofType(dateTime))