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

• Content
• Detailed Descriptions
• Mappings
• Implementations
• Detailed Analysis

12.4 Pattern Request - Content

FHIR Infrastructure

Maturity Level: 1

Informative

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

12.4.4 References to this Pattern

• Implemented by: Appointment, AppointmentResponse, CarePlan, Claim, CommunicationRequest... Show 10 more, CoverageEligibilityRequest, DeviceRequest, EnrollmentRequest, ImmunizationRecommendation, MedicationRequest, NutritionOrder, RequestOrchestration, ServiceRequest, SupplyRequest and VisionPrescription

12.4.5 Pattern Content

 

Alternate definitions: Master Definition XML + JSON.

12.4.5.1 Terminology Bindings

Path	ValueSet	Type	Documentation
Request.status	RequestStatus	Required	Codes identifying the lifecycle stage of a request.
Request.statusReason	Unknown	No details provided yet	Example	Codes 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	Unknown	No details provided yet	Example	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.
Request.performerType	Unknown	No details provided yet	Example	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.
Request.reason	Unknown	No details provided yet	Example	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.

12.4.6 Extensions

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

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

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.4.8 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.4.9 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.4.10 Compound Requests

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

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

12.4.10.1 Shared requisition id

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.

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

12.4.10.3 RequestOrchestration

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.

12.4.11 Notes and Related Information

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.

12.4.12 Relevant history

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.

12.4.12.1 Mappings

	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