R4 Ballot #2 (Mixed Normative/Trial use)

This page is part of the FHIR Specification (v3.5.0: R4 Ballot #2). 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

12.3 Pattern request - Content

FHIR Infrastructure Maturity 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.

12.3.1 Scope and Usage

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".

12.3.2 Boundaries and Relationships

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.

12.3.3 Background and Context

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.

12.3.4 Pattern Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Request ILogicalRequest Pattern
... identifier Σ0..*IdentifierBusiness Identifier for {{title}}
... instantiatesCanonical Σ0..*canonical(Definition)Instantiates FHIR protocol or definition
... instantiatesUri Σ0..*uriInstantiates external protocol or definition
... basedOn Σ0..*Reference(Request)Fulfills plan, proposal or order
... replaces Σ0..*Reference(Request)Request(s) replaced by this {{title}}
... groupIdentifier Σ0..1IdentifierComposite request this is part of
... status ?!Σ1..1codedraft | active | suspended | cancelled | completed | entered-in-error | unknown
RequestStatus (Required)
... statusReason 0..1CodeableConceptReason for current status
... intent ?!Σ1..1codeproposal | plan | order (immutable)
RequestIntent (Required)
... priority Σ0..1coderoutine | urgent | asap | stat
RequestPriority (Required)
... doNotPerform ?!Σ0..1booleantrue if request is prohibiting action
... code Σ0..1CodeableConceptWhat's being requested/ordered
... subject Σ1..1Reference(Patient | Group)Individual the service is ordered for
... context Σ0..1Reference(Encounter | EpisodeOfCare)Encounter / Episode associated with request
... occurrence[x] Σ0..1When service should occur
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... authoredOn Σ0..1dateTimeWhen request transitioned to being actionable
... requester Σ0..1Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device)Who/what is requesting service
... performerType Σ0..1CodeableConceptDesired kind of service performer
... performer Σ0..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson)Specific desired (non)performer
... reasonCode Σ0..*CodeableConceptWhy is service (not) needed?
... reasonReference Σ0..*Reference(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

UML Diagram (Legend)

Request (Logical)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..*]The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this {{title}}instantiatesCanonical : canonical [0..*] « Definition »The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this {{title}}instantiatesUri : uri [0..*]A plan, proposal or order that is fulfilled in whole or in part by this {{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]A code that identifies the specific service or action being asked to be done (or not done)code : CodeableConcept [0..1]The individual or set of individuals the action is to be performed/not performed on or forsubject : Reference [1..1] « Patient|Group »The encounter or episode of care that establishes the context for making this requestcontext : Reference [0..1] « Encounter|EpisodeOfCare »The date or time(s) at which the activity or service is desired to occur or not occuroccurrence[x] : Type [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 »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 »Describes why the request is being made in coded or textual formreasonCode : CodeableConcept [0..*]Indicates another resource whose existence justifies this requestreasonReference : Reference [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}}
... instantiatesCanonical Σ0..*canonical(Definition)Instantiates FHIR protocol or definition
... instantiatesUri Σ0..*uriInstantiates external protocol or definition
... basedOn Σ0..*Reference(Request)Fulfills plan, proposal or order
... replaces Σ0..*Reference(Request)Request(s) replaced by this {{title}}
... groupIdentifier Σ0..1IdentifierComposite request this is part of
... status ?!Σ1..1codedraft | active | suspended | cancelled | completed | entered-in-error | unknown
RequestStatus (Required)
... statusReason 0..1CodeableConceptReason for current status
... intent ?!Σ1..1codeproposal | plan | order (immutable)
RequestIntent (Required)
... priority Σ0..1coderoutine | urgent | asap | stat
RequestPriority (Required)
... doNotPerform ?!Σ0..1booleantrue if request is prohibiting action
... code Σ0..1CodeableConceptWhat's being requested/ordered
... subject Σ1..1Reference(Patient | Group)Individual the service is ordered for
... context Σ0..1Reference(Encounter | EpisodeOfCare)Encounter / Episode associated with request
... occurrence[x] Σ0..1When service should occur
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... authoredOn Σ0..1dateTimeWhen request transitioned to being actionable
... requester Σ0..1Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device)Who/what is requesting service
... performerType Σ0..1CodeableConceptDesired kind of service performer
... performer Σ0..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson)Specific desired (non)performer
... reasonCode Σ0..*CodeableConceptWhy is service (not) needed?
... reasonReference Σ0..*Reference(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

UML Diagram (Legend)

Request (Logical)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..*]The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this {{title}}instantiatesCanonical : canonical [0..*] « Definition »The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this {{title}}instantiatesUri : uri [0..*]A plan, proposal or order that is fulfilled in whole or in part by this {{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]A code that identifies the specific service or action being asked to be done (or not done)code : CodeableConcept [0..1]The individual or set of individuals the action is to be performed/not performed on or forsubject : Reference [1..1] « Patient|Group »The encounter or episode of care that establishes the context for making this requestcontext : Reference [0..1] « Encounter|EpisodeOfCare »The date or time(s) at which the activity or service is desired to occur or not occuroccurrence[x] : Type [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 »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 »Describes why the request is being made in coded or textual formreasonCode : CodeableConcept [0..*]Indicates another resource whose existence justifies this requestreasonReference : Reference [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 »

 

12.3.4.1 Terminology Bindings

PathDefinitionTypeReference
Request.status Codes identifying the lifecycle stage of a request.RequiredRequestStatus
Request.statusReason Codes identifying the reason for the current state of a request.UnknownNo details provided yet
Request.intent Codes indicating the degree of authority/intentionality associated with a request.RequiredRequestIntent
Request.priority Identifies the level of importance to be assigned to actioning the request.RequiredRequestPriority
Request.code Codes 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.UnknownNo details provided yet
Request.performerType Identifies 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.UnknownNo details provided yet
Request.reasonCode Codes 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.UnknownNo details provided yet

12.3.5 State Machine

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.

12.3.6 Fulfillment/Execution information

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.

12.3.7 Updating requests

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.

12.3.8 Compound Requests

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

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

12.3.8.1 Shared requisition id

The Request.requisitionId 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. In general the requisitionId, practitioner, authoredOn and subject for each will be immutable, but there may be situations where some workflows allow them to change. 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.

12.3.8.2 "Based on" chain

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. In a "replaces" relationship, the target resource is no longer in force and should have a status of "completed" or "cancelled" or some other terminal state.

12.3.8.3 RequestGroup

This approach makes use of the RequestGroup 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 RequestGroup must have an intent of "option", meaning that they cannot be interpretted 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". If there is a need for divergent statuses, these must be handled by creating "child" 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.

12.3.8.4 Mappings

identifier instantiatesCanonical instantiatesUri basedOn replaces groupIdentifier status statusReason intent priority doNotPerform code subject context occurrence[x] authoredOn requester performerType performer reasonCode reasonReference insurance supportingInfo note relevantHistory
Appointment 1 1 1 1 T 1 NC 4 NTC 1 N 1 NTC 1 N 1 N 1 N 1 NT
AppointmentResponse 1 1 N 1 N 2 NT 1 NC 1 N 1 NT
CarePlan 1 2 2 1 1 1 1 1 1 1 1 1 2 NT 1 N 1 N 1 C 1 2 N 1 1
Claim 2 1 N 1 C 1 T 1 NC 1 NC 1 N 1 N 1 N 1 NT 1 NT
CommunicationRequest 1 1 1 1 1 1 1 1 1 C 1 1 1 1 2 NC 1 1 1 N 2 NT
Contract 2 1 C 2 N 1 C 2 N 2 N 1 N 1 NT 1 N
CoverageEligibilityRequest 1 1 C 1 T 1 NC 1 N 2 N 1 N
DeviceRequest 1 1 1 1 1 N 1 1 C 1 1 1 NT 1 1 1 1 1 1 1 1 1 1 1 1 1
EnrollmentRequest 1 1 C 1 NC 1 N 1 N 1 N 1 N
ImmunizationRecommendation 1 1 NC 1 N 1 NTC 1 N 1 N
MedicationRequest 1 1 1 N 1 1 1 1 1 1 NT 1 1 1 NTC 1 1 1 1 1 1 1 1 N 1 1 N
NutritionOrder 1 1 1 1 1 8 NC 1 N 1 3 NC 1 N 1 N 3 NT 1
ProcessRequest 1 1 N 1 C 1 N 1 N
RequestGroup 1 1 1 1 1 1 1 1 2 2 C 1 C 1 1 NT 1 1 N 1 NC 1 1 1 NT 1
ServiceRequest 1 1 1 1 1 1 N 1 1 1 1 1 1 1 1 1 1 1 1 C 1 1 1 1 1 1
SupplyRequest 1 1 C 1 1 NT 1 1 1 1 NC 1 1
Task 1 1 1 E 1 1 1 1 1 1 NC 1 1 1 1 NT 1 1 1 1
VisionPrescription 1 1 C 1 NC 1 N 1 N 1 N