Release 5

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

12.4 Pattern Request - Content

FHIR Infrastructure iconMaturity Level: 1Informative

A pattern to be followed by resources that represent a specific proposal, plan and/or order for some sort of action or service.

This is NOT a resource. It is not part of the FHIR schema and cannot appear directly in FHIR instances. It is a logical model that defines a pattern adhered to by other resources. This pattern serves two purposes:

  • It offers guidance to work groups designing resources and helps ensure consistency of content created by different work groups
  • It provides a standard "view" that might be useful for implementers in processing and manipulating all resources that adhere to the same pattern. (Tooling that supports this may become available in a future release.)

The notion of "request" encompasses all types of orders (original orders, filler representations of orders, reflex orders, etc.) as well as proposals/recommendations for action to occur, plans, scheduling, etc. Any sort of description of an activity that is "desired" where the description is specific as to the subject of the activity and the approximate timing of the activity would be considered a "Request".

This logical model is one of three common workflow patterns. The other two patterns are Event and Definition. This pattern is followed by (or is intended to be followed by a number of other FHIR resources/

Requests are distinct from events in that an event is primarily focused on what has occurred or is occurring while requests deal with what is "desired" to occur. While creating a request or definition can be seen as a type of event, the focus of those other resources is not the "creation" but the desire/intention. Both requests and definitions deal with activities that "can" occur, but requests represent a specific intention for something to occur and are bound to a specific context of subject (e.g. patient) and time, while definitions represent mere "possibility" rather than intention and are independent of a specific subject or timeframe.

Requests are related to Task in that tasks can both request and track the fulfillment of a request. In some cases, fulfillment may also result in the creation of sub-tasks. Requests do not track their own fulfillment - i.e. requested/accepted/in-progress. This is managed through Task. The status of a request only reflects the status of the "authorization/intention", not how the request is being executed or not. It is possible for multiple tasks to be associated with the fulfillment of a single Request.

This model represents a pattern. It provides a standard list of data elements with cardinalities, data types, definitions, rationale and usage notes that will ideally be adhered to by resources that fall into the "request" workflow category. However, adherence to this pattern is not mandatory. Not all healthcare domains are the same. Concepts that may be generally applicable (and thus are included in this standard pattern) might still not be relevant everywhere or may be sufficiently uncommon that they are more appropriate to include as extensions than as core properties of the resource. Work groups are encouraged to adjust descriptions, usage notes and rationale to be specific to their resource (e.g. use the term "diagnostic test" or "prescription" rather than "request"). As well, design notes in the comments column marked with [square brackets] identifies areas where domain variation is expected and encouraged. Other variation, including differences in names, cardinalities, data types and the decision to omit an element outright are also possible, but should be discussed with the FHIR Infrastructure work group's Workflow project to ensure the rationale for non-alignment is understood, to confirm that the deviation is necessary and to identify whether any adjustments to the pattern are appropriate.

This pattern provides a linkage to the W5 list of standard data elements. Resources that adhere to this pattern should ensure their w5 mappings are consistent, as is their data element ordering.

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Request ILogicalRequest Pattern
... identifier Σ0..*IdentifierBusiness Identifier for {{title}}

... basedOn Σ0..*Reference(Request)Fulfills plan, proposal or order

... replaces Σ0..*Reference(Request)Request(s) replaced by this {{title}}

... status ?!Σ1..1codedraft | active | on-hold | revoked | completed | entered-in-error | unknown
Binding: RequestStatus (Required)
... statusReason 0..1CodeableConceptReason for current status
... intent ?!Σ1..1codeproposal | plan | order (immutable)
Binding: RequestIntent (Required)
... priority Σ0..1coderoutine | urgent | asap | stat
Binding: RequestPriority (Required)
... doNotPerform ?!Σ0..1booleantrue if request is prohibiting action
... category Σ0..*CodeableConceptPartitions the {{title}} into one or more categories that can be used to filter searching, to govern access control and/or to guide system behavior.

... code Σ0..1CodeableConceptService requested/ordered
... product Σ0..1CodeableReference(BiologicallyDerivedProduct | Device | DeviceDefinition | Medication | NutritionProduct | Substance)Product requested/ordered
... subject Σ1..1Reference(Patient | Group)Individual the service is ordered/prohibited for
... encounter Σ0..1Reference(Encounter)Encounter the {{title}} is tied to
... occurrence[x] Σ0..1When service should (not) occur
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... authoredOn Σ0..1dateTimeWhen request was created/transitioned to active
... requester Σ0..1Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device)Who/what is requesting service
... reported[x] Σ0..1Reported rather than primary record
.... reportedBooleanboolean
.... reportedReferenceReference(Patient | RelatedPerson | Practitioner | PractitionerRole | Organization)
... performerType Σ0..1CodeableConceptDesired kind of service performer
... performer Σ0..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson)Specific desired (non)performer
... deliverTo Σ0..*Reference(Patient | RelatedPerson | Practitioner | PractitionerRole | Organization | Location | HealthcareService | CareTeam | Device | Endpoint)Who should receive result of {{title}}

... reason Σ0..*CodeableReference(Condition | Observation | DiagnosticReport | DocumentReference)Why is service (not) needed?

... insurance 0..*Reference(Coverage | ClaimResponse)Associated insurance coverage

... supportingInfo 0..*Reference(Any)Extra information to use in performing request

... note 0..*AnnotationComments made about {{title}}

... relevantHistory 0..*Reference(Provenance)Key events in history of {{title}}


doco Documentation for this format icon

UML Diagram (Legend)

Request (Base) «Pattern»Business identifiers assigned to this {{title}} by the author and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to serveridentifier : Identifier [0..*]A higher-level request resource (i.e. a plan, proposal or order) that is fulfilled in whole or in part by this {{title}}. Authorization from the 'basedOn' request flows through to the referencing {{title}}basedOn : Reference [0..*] « Request »Completed or terminated request(s) whose function is taken by this new {{title}}replaces : Reference [0..*] « Request »A shared identifier common to all requests that were authorized more or less simultaneously by a single author, representing the identifier of the requisition, prescription or similar formgroupIdentifier : Identifier [0..1]The current state of the {{title}} (this element modifies the meaning of other elements)status : code [1..1] « Codes identifying the lifecycle stage of a request. (Strength=Required)RequestStatus! »Captures the reason for the current state of the {{title}}statusReason : CodeableConcept [0..1]Indicates the level of authority/intentionality associated with the {{title}} and where the request fits into the workflow chain (this element modifies the meaning of other elements)intent : code [1..1] « Codes indicating the degree of authority/intentionality associated with a request. (Strength=Required)RequestIntent! »Indicates how quickly the {{title}} should be addressed with respect to other requestspriority : code [0..1] « Identifies the level of importance to be assigned to actioning the request. (Strength=Required)RequestPriority! »If true indicates that the {{title}} is asking for the specified action to *not* occur (this element modifies the meaning of other elements)doNotPerform : boolean [0..1]Partitions the {{title}} into one or more categories that can be used to filter searching, to govern access control and/or to guide system behaviorcategory : CodeableConcept [0..*]A code that identifies the specific service or action being asked to be done (or not done)code : CodeableConcept [0..1]Indicates the product whose supply or manipulation is authorized by this {{title}}product : CodeableReference [0..1] « BiologicallyDerivedProduct| Device|DeviceDefinition|Medication|NutritionProduct|Substance »The individual or set of individuals the action is to be performed/not performed on or forsubject : Reference [1..1] « Patient|Group »The Encounter during which this {{title}} was created or to which the creation of this record is tightly associatedencounter : Reference [0..1] « Encounter »The date or time(s) at which the activity or service is desired to occur or not occuroccurrence[x] : DataType [0..1] « dateTime|Period|Timing »For draft {{title}}s, indicates the date of initial creation. For requests with other statuses, indicates the date of activationauthoredOn : dateTime [0..1]Who initiated the {{request}} and has responsibility for its activationrequester : Reference [0..1] « Practitioner|PractitionerRole| Organization|Patient|RelatedPerson|Device »Indicates if this record was captured as a secondary 'reported' record rather than as an original primary source-of-truth record. It may also indicate the source of the reportreported[x] : DataType [0..1] « boolean|Reference(Patient| RelatedPerson|Practitioner|PractitionerRole|Organization) »The type of individual that is desired to act upon/ not act upon the {{request}}performerType : CodeableConcept [0..1]Indicates who or what is being asked to perform (or not perform) the {{request}}performer : Reference [0..1] « Practitioner|PractitionerRole| Organization|CareTeam|HealthcareService|Patient|Device| RelatedPerson »Identifies the entity(ies) who should receive the results of executing the {{title}} (or the location to which the results should be delivered)deliverTo : Reference [0..*] « Patient|RelatedPerson|Practitioner| PractitionerRole|Organization|Location|HealthcareService| CareTeam|Device|Endpoint »Describes why the request is being made in coded or textual form, or Indicates another resource whose existence justifies this requestreason : CodeableReference [0..*] « Condition|Observation| DiagnosticReport|DocumentReference »Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be relevant in delivering the requested serviceinsurance : Reference [0..*] « Coverage|ClaimResponse »Information that may be needed by/relevant to the performer in their execution of this {{title}}supportingInfo : Reference [0..*] « Any »Comments made about the {{title}} by the requester, performer, subject or other participantsnote : Annotation [0..*]Links to Provenance records for past versions of this resource or fulfilling request or event resources that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the resourcerelevantHistory : Reference [0..*] « Provenance »

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Request ILogicalRequest Pattern
... identifier Σ0..*IdentifierBusiness Identifier for {{title}}

... basedOn Σ0..*Reference(Request)Fulfills plan, proposal or order

... replaces Σ0..*Reference(Request)Request(s) replaced by this {{title}}

... status ?!Σ1..1codedraft | active | on-hold | revoked | completed | entered-in-error | unknown
Binding: RequestStatus (Required)
... statusReason 0..1CodeableConceptReason for current status
... intent ?!Σ1..1codeproposal | plan | order (immutable)
Binding: RequestIntent (Required)
... priority Σ0..1coderoutine | urgent | asap | stat
Binding: RequestPriority (Required)
... doNotPerform ?!Σ0..1booleantrue if request is prohibiting action
... category Σ0..*CodeableConceptPartitions the {{title}} into one or more categories that can be used to filter searching, to govern access control and/or to guide system behavior.

... code Σ0..1CodeableConceptService requested/ordered
... product Σ0..1CodeableReference(BiologicallyDerivedProduct | Device | DeviceDefinition | Medication | NutritionProduct | Substance)Product requested/ordered
... subject Σ1..1Reference(Patient | Group)Individual the service is ordered/prohibited for
... encounter Σ0..1Reference(Encounter)Encounter the {{title}} is tied to
... occurrence[x] Σ0..1When service should (not) occur
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... authoredOn Σ0..1dateTimeWhen request was created/transitioned to active
... requester Σ0..1Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device)Who/what is requesting service
... reported[x] Σ0..1Reported rather than primary record
.... reportedBooleanboolean
.... reportedReferenceReference(Patient | RelatedPerson | Practitioner | PractitionerRole | Organization)
... performerType Σ0..1CodeableConceptDesired kind of service performer
... performer Σ0..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson)Specific desired (non)performer
... deliverTo Σ0..*Reference(Patient | RelatedPerson | Practitioner | PractitionerRole | Organization | Location | HealthcareService | CareTeam | Device | Endpoint)Who should receive result of {{title}}

... reason Σ0..*CodeableReference(Condition | Observation | DiagnosticReport | DocumentReference)Why is service (not) needed?

... insurance 0..*Reference(Coverage | ClaimResponse)Associated insurance coverage

... supportingInfo 0..*Reference(Any)Extra information to use in performing request

... note 0..*AnnotationComments made about {{title}}

... relevantHistory 0..*Reference(Provenance)Key events in history of {{title}}


doco Documentation for this format icon

UML Diagram (Legend)

Request (Base) «Pattern»Business identifiers assigned to this {{title}} by the author and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to serveridentifier : Identifier [0..*]A higher-level request resource (i.e. a plan, proposal or order) that is fulfilled in whole or in part by this {{title}}. Authorization from the 'basedOn' request flows through to the referencing {{title}}basedOn : Reference [0..*] « Request »Completed or terminated request(s) whose function is taken by this new {{title}}replaces : Reference [0..*] « Request »A shared identifier common to all requests that were authorized more or less simultaneously by a single author, representing the identifier of the requisition, prescription or similar formgroupIdentifier : Identifier [0..1]The current state of the {{title}} (this element modifies the meaning of other elements)status : code [1..1] « Codes identifying the lifecycle stage of a request. (Strength=Required)RequestStatus! »Captures the reason for the current state of the {{title}}statusReason : CodeableConcept [0..1]Indicates the level of authority/intentionality associated with the {{title}} and where the request fits into the workflow chain (this element modifies the meaning of other elements)intent : code [1..1] « Codes indicating the degree of authority/intentionality associated with a request. (Strength=Required)RequestIntent! »Indicates how quickly the {{title}} should be addressed with respect to other requestspriority : code [0..1] « Identifies the level of importance to be assigned to actioning the request. (Strength=Required)RequestPriority! »If true indicates that the {{title}} is asking for the specified action to *not* occur (this element modifies the meaning of other elements)doNotPerform : boolean [0..1]Partitions the {{title}} into one or more categories that can be used to filter searching, to govern access control and/or to guide system behaviorcategory : CodeableConcept [0..*]A code that identifies the specific service or action being asked to be done (or not done)code : CodeableConcept [0..1]Indicates the product whose supply or manipulation is authorized by this {{title}}product : CodeableReference [0..1] « BiologicallyDerivedProduct| Device|DeviceDefinition|Medication|NutritionProduct|Substance »The individual or set of individuals the action is to be performed/not performed on or forsubject : Reference [1..1] « Patient|Group »The Encounter during which this {{title}} was created or to which the creation of this record is tightly associatedencounter : Reference [0..1] « Encounter »The date or time(s) at which the activity or service is desired to occur or not occuroccurrence[x] : DataType [0..1] « dateTime|Period|Timing »For draft {{title}}s, indicates the date of initial creation. For requests with other statuses, indicates the date of activationauthoredOn : dateTime [0..1]Who initiated the {{request}} and has responsibility for its activationrequester : Reference [0..1] « Practitioner|PractitionerRole| Organization|Patient|RelatedPerson|Device »Indicates if this record was captured as a secondary 'reported' record rather than as an original primary source-of-truth record. It may also indicate the source of the reportreported[x] : DataType [0..1] « boolean|Reference(Patient| RelatedPerson|Practitioner|PractitionerRole|Organization) »The type of individual that is desired to act upon/ not act upon the {{request}}performerType : CodeableConcept [0..1]Indicates who or what is being asked to perform (or not perform) the {{request}}performer : Reference [0..1] « Practitioner|PractitionerRole| Organization|CareTeam|HealthcareService|Patient|Device| RelatedPerson »Identifies the entity(ies) who should receive the results of executing the {{title}} (or the location to which the results should be delivered)deliverTo : Reference [0..*] « Patient|RelatedPerson|Practitioner| PractitionerRole|Organization|Location|HealthcareService| CareTeam|Device|Endpoint »Describes why the request is being made in coded or textual form, or Indicates another resource whose existence justifies this requestreason : CodeableReference [0..*] « Condition|Observation| DiagnosticReport|DocumentReference »Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be relevant in delivering the requested serviceinsurance : Reference [0..*] « Coverage|ClaimResponse »Information that may be needed by/relevant to the performer in their execution of this {{title}}supportingInfo : Reference [0..*] « Any »Comments made about the {{title}} by the requester, performer, subject or other participantsnote : Annotation [0..*]Links to Provenance records for past versions of this resource or fulfilling request or event resources that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the resourcerelevantHistory : Reference [0..*] « Provenance »

 

Alternate definitions: Master Definition XML + JSON.

PathValueSetTypeDocumentation
Request.status RequestStatus Required

Codes identifying the lifecycle stage of a request.

Request.statusReason UnknownNo details provided yetExampleCodes identifying the reason for the current state of a request.
Request.intent RequestIntent Required

Codes indicating the degree of authority/intentionality associated with a request.

Request.priority RequestPriority Required

Identifies the level of importance to be assigned to actioning the request.

Request.code UnknownNo details provided yetExampleCodes indicating the details of what is being requested. These will vary significantly based on the type of request resource and will often be example/preferred rather than extensible/required.
Request.performerType UnknownNo details provided yetExampleIdentifies types of practitioners, devices or other agents that should fulfill a request. While the detailed constraints of relevant agents will vary by resource, some degree of consistency around recommended codes across request and definition resources would be desirable.
Request.reason UnknownNo details provided yetExampleCodes identifying why this request was necessary. These may be clinical reasons (e.g. diagnoses, symptoms) and/or administrative reasons. While the detailed constraints of relevant reasons will vary by resource, some degree of consistency across resources around recommended codes would be desirable.

Not all resources that follow the 'Request' pattern will necessarily include all of the above elements. A set of standard extensions have been defined for use with resources where an element might be "applicable" but is not commonly supported. A list of these can be found on the Request Extensions(request-specific) and Workflow Extensions(shared by events and requests).

The following diagram shows the "typical" state machine diagram for resources following the Request pattern. Note that not all resources will support all states, some resources may choose different names for certain states and some resources may introduce sub-states to the listed states. As well, additional transitions may be supported, including from terminal nodes (e.g. from "completed" back to "active"). That said, most resources should align with this state machine fairly well.

Typical state machine diagram for resources following
  the Request pattern

Note that this state machine does not reflect the execution of the request. That state is managed either through the Event resources that are based on the request or via the Task resource.

Request resources describe what activity is desired/authorized. Requests do not track the execution/fulfillment of the plan, proposal or order. I.e. the request resource will not indicate actual performer, actual performance time, actual action performed, etc. Information about what action (if any) has occurred against the request is tracked using the corresponding Event resource(s). Events that are associated with the request should have a basedOn link referencing the request. In addition, a linkage can be established (and information about progress of execution) may be found in Task resources that have a focus of this request.

FHIR does not impose any business rules on what sorts of changes may be made to a request. A generic FHIR server could support updating a completed request to change the subject, requester, authorized action, quantity, timing and any other such information. However, most business processes will impose significant constraints on what changes, if any, are allowed to request resources, particularly after they have transitioned to "active" or "completed". Servers are free to enforce whatever rules they deem appropriate - and to provide appropriate OperationOutcome responses detailing constraints if those rules are violated.

There are three different ways to define "compound" requests in FHIR:

  • Shared requisition id
  • "Based on" chain
  • RequestOrchestration

The Request.groupIdentifier element allows multiple requests to be linked as having been created as part of the same "event" - generally by the same practitioner at the same time for the same subject. The "requisitionId" represents the identifier of the prescription, lab requisition or other form that was shared by all items. The common information (patient/practitioner/authoredOn) can be seen by examining any of the Request instances that share that requisitionId If there are common comments or notes that span the entire requisition, they should be captured as Observation or Communication instances linked to relevant Request instances using Request.supportingInfo.

Each "component" behaves as an independent request and has its own status that changes independently. Cancelling or suspending request with a shared groupIdentifier has no impact on other requests with the same groupIdentifier. The shared requisitionId allows business processes dependent on "simultaneous/requisition-based ordering" such as payment rules to know that the requests were ordered at the same time.

In general, the requisitionId, requester, authoredOn, and subject for each Request will not change over the lifetime of the instance, particularly once the status becomes 'active', though there may be situations where some workflows allow these elements to change. Because of this, there could be situations where the subject, requester, authoredOn could differ between Requests that share the same requisitionId. Systems can enforce business rules to prevent such inconsistency from happening if it would be problematic.

In this case "components" of a parent request are not treated as components, but rather as separate orders that are executed as part of the fulfillment process for the parent order. For example, a lab order might spawn child orders to draw the specimen, treat the specimen, run several tests and to create the report. Each "child" Request would use Request.basedOn to reference the original Request. In this case, there's a relationship between the statuses of the base Request and the fulfilling Requests, but they transition separately and might not transition in the same manner. For example, if the original lab order were updated to "suspended", the initial blood draw request might be complete. The other requests might change to either "suspended" or even "aborted" and a subsequent update of the lab order back to active might require spawning additional fulfilling orders, perhaps to draw a new specimen.

basedOn is distinct from the notion of replaces. In a "based on" relationship both resources are "active" and in force and the authority cascades from the initial request to the request that is based on that original request. The source and target of a "replaces" relationship should have the same "intent". I.e. An order can replace another order, but can't generally replace a proposal - though an order can be "basedOn" a proposal.

This approach makes use of the RequestOrchestration resource which allows the assertion of complex timing and other dependencies between a collection of requests. These effectively become one overall Request instance with a single status. All resources referenced by the RequestOrchestration must have an intent of "option", meaning that they cannot be interpreted independently - and that changes to them must take into account the impact on referencing resources. Typically these will either be contained resources or tightly controlled or immutable instances based on ActivityDefinitions that can safely be referenced without concern of them changing independent of referencing Requests.

The status of the parent request automatically cascades to the component "options". It is not possible to cancel, suspend or complete one part of the RequestOrchestration without making the same status change to all options. If there is a need for divergent statuses, these must be handled by creating "child" requests using the "basedOn" approach above. They should have a basedOn relationship with both the "parent" Request as well as the specific "option" Request they are tied to.

A RequestOrchestration might have a .groupIdentifier if it was created as part of a larger collection of independent orders. The different 'option' requests referenced by the RequestOrchestration SHOULD NOT have a .groupIdentifier specified as they are all considered part of the RequestOrchestration order.

Both the 'note' and 'supportingInfo' element provide additional supporting or contextual information about the overall Request. However, they have slightling different purposes.

  • supportingInfo can be a reference to a DocumentReference containing ad-hoc clinical notes, however in most cases, supportingInfo will be other types of resources containing discrete information. In the situation where a DocumentReference is used to contain notes, those notes have an independent existence and maintenance cycle from the referencing Request resource and might be linked to multiple Request or other resources. On the other hand, notes are associated with exactly one Request instance.
  • Notes are typically added to a request after it has been activated, though they can come before. A key thing is that you want to track who made the note and when.
  • Notes can be clinical or administrative in nature. E.g. "Holding off sending the referral until patient is back from vacation", "Expect to resume med roughly 2 weeks post-discharge", "Possible compliance issues, follow up next appointment".
  • supportingInfo is information typically provided at the time the request is activated, though it can be added later.
  • supportingInfo is information needed by the filler in order to be able to perform the order (e.g. recent lab tests supporting a referral, patient height/weight/age supporting a dosage instruction - or allowing calculation of dosage, previous procedures done, etc. to support a Claim.
  • notes should never be used to reflect information conveyed in supportingInfo.

This pattern contains an element called "relevantHistory" that points to Provenance. This allows the resource to summarize key events that have happened over the lifespan of the resource. For example, when the request was created, when it was suspended, when it was released, etc. The list of referenced Provenence entries don't necessarily include all events that have occurred over the lifespan of the resource. Instead, they list those the author considers 'significant' and relevant to downstream users. Modifications to drafts or small corrections that do not impact fulfillment might not be needed. In some cases, Provenance for changes to other resources (e.g. fulfilling events) might also be included if the source system tracks those as 'events' tied to the Request.

IMPORTANT: the relevantHistory generally excludes the most recent change on 'pure' FHIR repositories. That is because in pure FHIR environments, the Provenance instance must be created after the update has been made - because it needs to point to the new 'version' of the resource that has been created. This means that if there is a desire to include the 'current' change in relevant history, it is necessary to first make the change, then update the resource to add the event to recentHistory. More typically, recentHistory simply won't include the most recent event. If the full history is needed, the system will need to retrieve both the history as well as the Provenance that points to the current release.

For systems that don't store history separately from the base resource, the relevantHistory Provenance instances can be conveyed as contained resources. In this circumstance, there might also not be an issue with relevantHistory also including the 'most recent' change as the history is updated at the same time the change is applied.

The full set of potential Provenance information may be overkill for those systems that are only interested in it from a relevantHistory perspective. The Provenance Relevant History profile is included to give guidance on what data elements are most likely to be relevant for systems looking at Provenance from the perspective of relevantHistory.

identifier basedOn replaces groupIdentifier status statusReason intent priority doNotPerform category code product subject encounter occurrence[x] authoredOn requester reported[x] performerType performer deliverTo reason insurance supportingInfo note relevantHistory
Appointment 1 1 T 1 T 1 1 T 1 NTC 1 NTC 4 NTC 1 N 1 NTC 1 1 NT 1
AppointmentResponse 1 1 NTC 1 N 2 NT 1 NC 1 NT 1 NTC
CarePlan 1 1 T 1 T 1 1 1 1 1 NT 1 N 1 NT 1 NTC 1 N 1 T 1
Claim 2 C 1 NTC 1 1 T 1 NT 1 NC 1 NT 1 NT 1 T
CommunicationRequest 1 1 T 1 T 1 1 1 1 1 1 1 C 1 1 T 1 1 2 NTC 1 1 NT 2 NT
CoverageEligibilityRequest 1 1 1 T 1 NT 1 NC 2 NT 1 NTC
DeviceRequest 1 1 T 1 T 1 1 C 1 1 1 TC 1 T 1 1 1 1 T 1 T 1 1 1 T 1 1
EnrollmentRequest 1 1 C 1 NTC 1 N 1 NT 1 NT 1 NTC
ImmunizationRecommendation 1 1 NC 1 NT 1 NTC 1 NC 1 NT
MedicationRequest 1 1 T 1 NTC 1 1 1 1 1 1 NTC 1 1 1 1 1 1 TC 1 1 1 NT 1 1 N
NutritionOrder 1 1 T 1 1 1 1 8 NT 1 1 3 NTC 1 NC 1 NT 3 NTC 1
RequestOrchestration 1 1 T 1 T 1 1 1 2 2 C 1 TC 1 1 NT 1 1 NT 1 NTC 1 1 NT 1
ServiceRequest 1 1 T 1 T 1 N 1 1 1 1 1 T 1 T 1 1 1 1 1 1 C 1 1 1 T 1 1
SupplyRequest 1 1 T 1 C 1 1 NTC 1 1 1 T 1 NTC 1
Task 1 1 T 0|1 ET 1 1 1 1 2 NT 1 NTC 1 1 NT 1 1 1 NTC 1 NT 1 1 1 1
Transport 1 T 1 1 1 1 1 NTC 1 1 1 1 C 1 N 1 C 1 1 1
VisionPrescription 1 1 1 NT 1 1 NC 1 NTC

Each non-grey cell contains a number, the number of elements and extensions (if > 0) mapped in the resource that are mapped to the pattern element in the column. If there are 0 elements and extensions, the number is not shown. In addition, the cell has a color and some character flags.

Colors:

  • Grey: the resource has no element or extension for the pattern element
  • White: the resource has an element that implements the pattern element with the same name
  • Yellow: the resource has a documented extension that implements the pattern element with the same name
  • Blue: the resource has an element that implements the pattern element with a different name
  • Red: the resource has an element that implements that pattern element, but the type or cardinality does not match

Flags:

  • E: pattern element implemented by an extension
  • N: pattern element implemented by an element with a different name
  • T: pattern element implemented by an element with a different type
  • C: pattern element implemented by an element with a different cardinality