Provenance - FHIR v5.0.0 (original) (raw)

This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version. 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
• Operations
• Search Params
• Profiles
• Extensions
• R4 Conversions

6.3 Resource Provenance - Content

Security Work Group	Maturity Level: 4	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.1 Scope and Usage

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. This information can be used to form assessments about its quality, reliability, trustworthiness, or to provide pointers for where to go to further investigate the origins of the resource and the information in it.

Provenance resources are a record-keeping assertion that gathers information about the context in which the information in a resource was obtained. Provenance resources are prepared by the application that initiates the create/update etc. of the resource. An AuditEvent resource contains overlapping information, but is created as events occur, to track and audit the events. AuditEvent resources are often (though not exclusively) created by the application responding to the read/query/create/update/etc. event.

6.3.2 Boundaries and Relationships

Many other FHIR resources contain some elements that represent information about how the resource was obtained, and therefore they overlap with the functionality of the Provenance resource. These properties in other resources should always be used in preference to the Provenance resource, and the Provenance resource should be used where additional information is required, or explicit record or provenance is desired. Details on this overlap can be found on the FiveWs, including a mapping from the at the Resource Element level.

The relationship between a resource and its provenance is established by a reference from the provenance resource to its target. In this way, provenance may be provided about any resource or version, including past versions. There may be multiple provenance records for a given resource or version of a resource.

6.3.3 Background and Context

The Provenance resource is based on the W3C Provenance specification , and mappings are provided. The Provenance resource is tailored to fit the FHIR use-cases for provenance more directly. In terms of W3C Provenance the FHIR Provenance resource covers "Generation" of "Entity" with respect to FHIR defined resources for creation or updating; whereas AuditEvent covers "Usage" of "Entity" and all other "Activity" as defined in W3C Provenance.

The W3C Provenance Specification has the following fundamental model:

Where:

• Entity - An entity is a physical, digital, conceptual or other kind of thing with some fixed aspects; entities may be real or imaginary. One or more entities can be the input (.entity) of an activity, and one or more entities can be the output (.target).
• Agent - An agent is something that bears the responsibility identified by the type of participation in the activity taking place, for the existence of an entity, or for another agent's activity. An Agent may be a person, device, system, organization, group, care-team, or identifiable thing.
• Activity - An activity is something that occurs over a time period and acts upon or with entities. It may include consuming, processing, transforming, modifying, relocating, using, or generating entities.

The Provenance resource corresponds to a single activity that identifies a set of resources (target) generated by the activity. The activity also references other entities (entity) that were used and the agents (agent) that were associated with the activity. To record multiple activities that resulted in one (target), record each (activity) in independent Provenance records all pointing at that (target).

The Provenance resource depends upon having References to all the resources, entities, and agents involved in the activity. These References need not be resolvable. The references must provide a unique and unambiguous identification. If a resource, entity, or agent can have different versions that must be identified, then the Reference must have versioning information included.

Versioning and unique identification are not mandated for all systems that provide Resources, entities, and agents. But, inclusion of Provenance requirements may introduce requirements for versioning and unique identification on those systems

The Provenance resource is based on leveraging the W3C Provenance specification to represent HL7 support of provenance throughout its standards and explicitly modeled as functional capabilities in ISO/HL7 10781 EHR System Functional Model Release 2 and ISO 21089 Trusted End-to-End Information Flows. Mappings are provided. The Provenance resource is tailored to fit the FHIR use-cases for provenance more directly. In terms of W3C Provenance the FHIR Provenance resources covers "Generation" of "Entity" with respect to FHIR defined resources for creation or updating; whereas AuditEvent covers "Usage" of "Entity" and all other "Activity" as defined in W3C Provenance.

6.3.4 References to this Resource

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

6.3.5Resource Content

• Structure
• UML
• XML
• JSON
• Turtle
• R4 Diff
• All

Structure

Name	Flags	Card.	Type	Description & Constraints
Provenance	TU	DomainResource	Who, What, When for a set of resourcesElements defined in Ancestors: id, meta, implicitRules, language, [text](domainresource.html#DomainResource "A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety."), contained, extension, modifierExtension
target	Σ	1..*	Reference(Any)	Target Reference(s) (usually version specific)
occurred[x]	0..1	When the activity occurred
occurredPeriod	Period
occurredDateTime	dateTime
recorded	Σ	0..1	instant	When the activity was recorded / updated
policy	0..*	uri	Policy or plan the activity was defined by
location	0..1	Reference(Location)	Where the activity occurred, if relevant
authorization	0..*	CodeableReference()	Authorization (purposeOfUse) related to the eventBinding: PurposeOfUse (Example)
activity	0..1	CodeableConcept	Activity that occurredBinding: ValueSet of sample of representative activity type codes. (Example)
basedOn	TU	0..*	Reference(CarePlan | DeviceRequest	ImmunizationRecommendation	MedicationRequest	NutritionOrder	ServiceRequest	Task)	Workflow authorization within which this event occurred
patient	TU	0..1	Reference(Patient)	The patient is the subject of the data created/updated (.target) by the activity
encounter	TU	0..1	Reference(Encounter)	Encounter within which this event occurred or which the event is tightly associated
agent	ΣC	1..*	BackboneElement	Actor involved+ Rule: Who and onBehalfOf cannot be the same+ Rule: If who is a PractitionerRole, onBehalfOf can't reference the same Practitioner+ Rule: If who is an organization, onBehalfOf can't be a PractitionerRole within that organization
type	Σ	0..1	CodeableConcept	How the agent participatedBinding: Participation Role Type (Example)
role	0..*	CodeableConcept	What the agents role wasBinding: Security Role Type (Example)
who	ΣC	1..1	Reference(Practitioner | PractitionerRole	Organization	CareTeam	Patient	Device	RelatedPerson)	The agent that participated in the event
onBehalfOf	C	0..1	Reference(Practitioner | PractitionerRole	Organization	CareTeam	Patient)	The agent that delegated
entity	ΣTU	0..*	BackboneElement	An entity used in this activity
role	Σ	1..1	code	revision | quotation	source	instantiates	removalBinding: Provenance Entity Role (Required)
what	Σ	1..1	Reference(Any)	Identity of entity
agent	0..*	see agent	Entity is attributed to this agent
signature	TU	0..*	Signature	Signature on target
Documentation for this format

See the Extensions for this resource

UML Diagram (Legend)

Provenance (DomainResource)The Reference(s) that were generated or updated by the activity described in this resource. A provenance can point to more than one target if multiple resources were created/updated by the same activitytarget : Reference [1..*] « Any »The period during which the activity occurredoccurred[x] : DataType [0..1] « Period|dateTime »The instant of time at which the activity was recordedrecorded : instant [0..1]Policy or plan the activity was defined by. Typically, a single activity may have multiple applicable policy documents, such as patient consent, guarantor funding, etcpolicy : uri [0..*]Where the activity occurred, if relevantlocation : Reference [0..1] « Location »The authorization (e.g., PurposeOfUse) that was used during the event being recordedauthorization : CodeableReference [0..*] « ; null (Strength=Example)PurposeOfUse?? »An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entitiesactivity : CodeableConcept [0..1] « null (Strength=Example)ProvenanceActivityType?? »Allows tracing of authorizatino for the events and tracking whether proposals/recommendations were acted uponbasedOn : Reference [0..*] « CarePlan|DeviceRequest| ImmunizationRecommendation|MedicationRequest|NutritionOrder| ServiceRequest|Task »The patient element is available to enable deterministic tracking of activities that involve the patient as the subject of the data used in an activitypatient : Reference [0..1] « Patient »This will typically be the encounter the event occurred, but some events may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission lab tests)encounter : Reference [0..1] « Encounter »A digital signature on the target Reference(s). The signer should match a Provenance.agent. The purpose of the signature is indicatedsignature : Signature [0..*]AgentThe Functional Role of the agent with respect to the activitytype : CodeableConcept [0..1] « null (Strength=Example)ParticipationRoleType?? »The structural roles of the agent indicating the agent's competency. The security role enabling the agent with respect to the activityrole : CodeableConcept [0..*] « null (Strength=Example)SecurityRoleType?? »Indicates who or what performed in the eventwho : Reference [1..1] « Practitioner|PractitionerRole|Organization| CareTeam|Patient|Device|RelatedPerson » « This element has or is affected by some invariantsC »The agent that delegated authority to perform the activity performed by the agent.who elementonBehalfOf : Reference [0..1] « Practitioner|PractitionerRole| Organization|CareTeam|Patient » « This element has or is affected by some invariantsC »EntityHow the entity was used during the activityrole : code [1..1] « null (Strength=Required)ProvenanceEntityRole! »Identity of the Entity used. May be a logical or physical uri and maybe absolute or relativewhat : Reference [1..1] « Any »An actor taking a role in an activity for which it can be assigned some degree of responsibility for the activity taking placeagent[1..*]The entity is attributed to an agent to express the agent's responsibility for that entity, possibly along with other agents. This description can be understood as shorthand for saying that the agent was responsible for the activity which used the entityagent[0..*]An entity used in this activityentity[0..*]

JSON Template

{ "resourceType" : "Provenance", // from Resource: id, meta, implicitRules, and language // from DomainResource: text, contained, extension, and modifierExtension "target" : [{ Reference(Any) }], // R! Target Reference(s) (usually version specific) // occurred[x]: When the activity occurred. One of these 2: "occurredPeriod" : { Period }, "occurredDateTime" : "<dateTime>", "recorded" : "<instant>", // When the activity was recorded / updated "policy" : ["<uri>"], // Policy or plan the activity was defined by "location" : { Reference(Location) }, // Where the activity occurred, if relevant "authorization" : [{ CodeableReference }], // Authorization (purposeOfUse) related to the event "activity" : { CodeableConcept }, // Activity that occurred "basedOn" : [{ Reference(CarePlan|DeviceRequest|ImmunizationRecommendation| MedicationRequest|NutritionOrder|ServiceRequest|Task) }], // Workflow authorization within which this event occurred "patient" : { Reference(Patient) }, // The patient is the subject of the data created/updated (.target) by the activity "encounter" : { Reference(Encounter) }, // Encounter within which this event occurred or which the event is tightly associated "agent" : [{ // **R!** Actor involved "type" : { CodeableConcept }, // How the agent participated "role" : [{ CodeableConcept }], // What the agents role was "who" : { Reference(CareTeam|Device|Organization|Patient|Practitioner| PractitionerRole|RelatedPerson) }, // I R! The agent that participated in the event "onBehalfOf" : { Reference(CareTeam|Organization|Patient|Practitioner| PractitionerRole) } // I The agent that delegated }], "entity" : [{ // An entity used in this activity "role" : "<code>", // R! revision | quotation | source | instantiates | removal "what" : { Reference(Any) }, // R! Identity of entity "agent" : [{ Content as for Provenance.agent }] // Entity is attributed to this agent }], "signature" : [{ Signature }] // Signature on target }

Changes from both R4 and R4B

See the Full Difference for further information

This analysis is available for R4 as XML or JSON and for R4B as XML or JSON.

See R4 <--> R5 Conversion Maps (status = See Conversions Summary.)

Structure

Name	Flags	Card.	Type	Description & Constraints
Provenance	TU	DomainResource	Who, What, When for a set of resourcesElements defined in Ancestors: id, meta, implicitRules, language, [text](domainresource.html#DomainResource "A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety."), contained, extension, modifierExtension
target	Σ	1..*	Reference(Any)	Target Reference(s) (usually version specific)
occurred[x]	0..1	When the activity occurred
occurredPeriod	Period
occurredDateTime	dateTime
recorded	Σ	0..1	instant	When the activity was recorded / updated
policy	0..*	uri	Policy or plan the activity was defined by
location	0..1	Reference(Location)	Where the activity occurred, if relevant
authorization	0..*	CodeableReference()	Authorization (purposeOfUse) related to the eventBinding: PurposeOfUse (Example)
activity	0..1	CodeableConcept	Activity that occurredBinding: ValueSet of sample of representative activity type codes. (Example)
basedOn	TU	0..*	Reference(CarePlan | DeviceRequest	ImmunizationRecommendation	MedicationRequest	NutritionOrder	ServiceRequest	Task)	Workflow authorization within which this event occurred
patient	TU	0..1	Reference(Patient)	The patient is the subject of the data created/updated (.target) by the activity
encounter	TU	0..1	Reference(Encounter)	Encounter within which this event occurred or which the event is tightly associated
agent	ΣC	1..*	BackboneElement	Actor involved+ Rule: Who and onBehalfOf cannot be the same+ Rule: If who is a PractitionerRole, onBehalfOf can't reference the same Practitioner+ Rule: If who is an organization, onBehalfOf can't be a PractitionerRole within that organization
type	Σ	0..1	CodeableConcept	How the agent participatedBinding: Participation Role Type (Example)
role	0..*	CodeableConcept	What the agents role wasBinding: Security Role Type (Example)
who	ΣC	1..1	Reference(Practitioner | PractitionerRole	Organization	CareTeam	Patient	Device	RelatedPerson)	The agent that participated in the event
onBehalfOf	C	0..1	Reference(Practitioner | PractitionerRole	Organization	CareTeam	Patient)	The agent that delegated
entity	ΣTU	0..*	BackboneElement	An entity used in this activity
role	Σ	1..1	code	revision | quotation	source	instantiates	removalBinding: Provenance Entity Role (Required)
what	Σ	1..1	Reference(Any)	Identity of entity
agent	0..*	see agent	Entity is attributed to this agent
signature	TU	0..*	Signature	Signature on target
Documentation for this format

See the Extensions for this resource

UML Diagram (Legend)

Provenance (DomainResource)The Reference(s) that were generated or updated by the activity described in this resource. A provenance can point to more than one target if multiple resources were created/updated by the same activitytarget : Reference [1..*] « Any »The period during which the activity occurredoccurred[x] : DataType [0..1] « Period|dateTime »The instant of time at which the activity was recordedrecorded : instant [0..1]Policy or plan the activity was defined by. Typically, a single activity may have multiple applicable policy documents, such as patient consent, guarantor funding, etcpolicy : uri [0..*]Where the activity occurred, if relevantlocation : Reference [0..1] « Location »The authorization (e.g., PurposeOfUse) that was used during the event being recordedauthorization : CodeableReference [0..*] « ; null (Strength=Example)PurposeOfUse?? »An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entitiesactivity : CodeableConcept [0..1] « null (Strength=Example)ProvenanceActivityType?? »Allows tracing of authorizatino for the events and tracking whether proposals/recommendations were acted uponbasedOn : Reference [0..*] « CarePlan|DeviceRequest| ImmunizationRecommendation|MedicationRequest|NutritionOrder| ServiceRequest|Task »The patient element is available to enable deterministic tracking of activities that involve the patient as the subject of the data used in an activitypatient : Reference [0..1] « Patient »This will typically be the encounter the event occurred, but some events may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission lab tests)encounter : Reference [0..1] « Encounter »A digital signature on the target Reference(s). The signer should match a Provenance.agent. The purpose of the signature is indicatedsignature : Signature [0..*]AgentThe Functional Role of the agent with respect to the activitytype : CodeableConcept [0..1] « null (Strength=Example)ParticipationRoleType?? »The structural roles of the agent indicating the agent's competency. The security role enabling the agent with respect to the activityrole : CodeableConcept [0..*] « null (Strength=Example)SecurityRoleType?? »Indicates who or what performed in the eventwho : Reference [1..1] « Practitioner|PractitionerRole|Organization| CareTeam|Patient|Device|RelatedPerson » « This element has or is affected by some invariantsC »The agent that delegated authority to perform the activity performed by the agent.who elementonBehalfOf : Reference [0..1] « Practitioner|PractitionerRole| Organization|CareTeam|Patient » « This element has or is affected by some invariantsC »EntityHow the entity was used during the activityrole : code [1..1] « null (Strength=Required)ProvenanceEntityRole! »Identity of the Entity used. May be a logical or physical uri and maybe absolute or relativewhat : Reference [1..1] « Any »An actor taking a role in an activity for which it can be assigned some degree of responsibility for the activity taking placeagent[1..*]The entity is attributed to an agent to express the agent's responsibility for that entity, possibly along with other agents. This description can be understood as shorthand for saying that the agent was responsible for the activity which used the entityagent[0..*]An entity used in this activityentity[0..*]

JSON Template

{ "resourceType" : "Provenance", // from Resource: id, meta, implicitRules, and language // from DomainResource: text, contained, extension, and modifierExtension "target" : [{ Reference(Any) }], // R! Target Reference(s) (usually version specific) // occurred[x]: When the activity occurred. One of these 2: "occurredPeriod" : { Period }, "occurredDateTime" : "<dateTime>", "recorded" : "<instant>", // When the activity was recorded / updated "policy" : ["<uri>"], // Policy or plan the activity was defined by "location" : { Reference(Location) }, // Where the activity occurred, if relevant "authorization" : [{ CodeableReference }], // Authorization (purposeOfUse) related to the event "activity" : { CodeableConcept }, // Activity that occurred "basedOn" : [{ Reference(CarePlan|DeviceRequest|ImmunizationRecommendation| MedicationRequest|NutritionOrder|ServiceRequest|Task) }], // Workflow authorization within which this event occurred "patient" : { Reference(Patient) }, // The patient is the subject of the data created/updated (.target) by the activity "encounter" : { Reference(Encounter) }, // Encounter within which this event occurred or which the event is tightly associated "agent" : [{ // **R!** Actor involved "type" : { CodeableConcept }, // How the agent participated "role" : [{ CodeableConcept }], // What the agents role was "who" : { Reference(CareTeam|Device|Organization|Patient|Practitioner| PractitionerRole|RelatedPerson) }, // I R! The agent that participated in the event "onBehalfOf" : { Reference(CareTeam|Organization|Patient|Practitioner| PractitionerRole) } // I The agent that delegated }], "entity" : [{ // An entity used in this activity "role" : "<code>", // R! revision | quotation | source | instantiates | removal "what" : { Reference(Any) }, // R! Identity of entity "agent" : [{ Content as for Provenance.agent }] // Entity is attributed to this agent }], "signature" : [{ Signature }] // Signature on target }

Changes from both R4 and R4B

See the Full Difference for further information

This analysis is available for R4 as XML or JSON and for R4B as XML or JSON.

See R4 <--> R5 Conversion Maps (status = See Conversions Summary.)

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.1Terminology 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
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 (a valid code from Sample 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 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 have references (e.g. .target) to version specific resources. When de-referencing resource references that may have a version identified one should look for the non-version resource found in the Bundle.

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. The Provenance http header may be used if supported.

The Provenance.target may point at a specific element within the targetted 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.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.)
• When recording an AuditEvent, one AuditEvent 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 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 Provenanceresource 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.5.7 Muiltiple Patients Affected

Where a provenance activity impacts more than one Patient/Subject; multiple Provenance resources 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 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.