This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 5.0.0 . For a full list Continuous Integration Build of available versions, see FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions . Page versions: R5 R4B R4 R3

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

12.3 Logical Model request Pattern Request - Content

Responsible Owner: FHIR Infrastructure

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.3.4 References to this Pattern

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

12.3.4 12.3.5 Logical Model Pattern Content

 

Alternate definitions: Master Definition XML + JSON .

12.3.4.1 12.3.5.1 Terminology Bindings

Unknown No details provided yet

Path	Definition ValueSet	Type	Reference Documentation
Request.status	RequestStatus	Required	Codes identifying the stage lifecycle stage of a request request.
Request.statusReason	Unknown	No details provided yet	Required Example	RequestStatus 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.
Request.priority	RequestPriority	Required	RequestIntent Request.priority Identifies the level of importance to be assigned to actioning the request request.
Request.code	Required Unknown	No details provided yet	RequestPriority Example 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.
Request.performerType	Unknown	No details provided yet	Request.performerType Example	Identifies types of practitioners, devices or others other agents that should fulfill a request. While the detailed constraints of relevant providers agents will vary by resource, some degree of consistency around recommended codes across request and definition resources would be desirable desirable.
Request.reason	Unknown	No details provided yet	Request.reasonCode 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.3.4.2 12.3.6 Constraints Extensions inv-1 : On request.requester: onBehalfOf can only

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 specified if agent "applicable" but is practitioner or device ( expression not commonly supported. A list of these can be found on request.requester: (agent.resolve().empty()) or (agent.resolve() is Device) or (agent.resolve() is Practitioner) or onBehalfOf.exists().not() ) the Request Extensions (request-specific) and Workflow Extensions (shared by events and requests).

12.3.5 12.3.7 State Machine

The following diagram shows the "typical" "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" "completed" back to "active"). "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.3.6 12.3.8 Fulfillment/Execution information

Request resources describe what activity is desired/authorized. They don't describe what activity has actually occurred against Requests do not track the request. execution/fulfillment of the plan, proposal or order. I.e. The 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 in of execution) may be found in Task resources that have a focus of this request.

In some systems, the notion of fulfillment status may be projected into a single overall status, which is then referred to as Request status (e.g. Prescription status ) - e.g. having Request statuses such as requested , accepted , in progress alongside statuses such as draft , on-hold , and completed . FHIR has specifically split these two types of statuses apart and tracks them in two separate resources. The rationale for doing so is as follows:

• It is not a given that fulfillment is necessarily sought for all active authorizations. It's not uncommon in some areas for an authorization to exist but the individual responsible for seeking fulfillment to never actually do so
• It is possible for fulfillment of the same authorization to be sought multiple times - for example, asking one lab to fulfill an order, receiving a rejection, then asking a second lab. The rejected status for the first lab needs to be tracked alongside the accepted status for the second lab.
• In some cases, fulfillment might be sought for less than the entire authorization. E.g. seeking performance of a single service repetition, a single set of tests, a single dispense, even though the authorization might cover multiple repetitions/sets of tests/dispenses
• The Request resource is often signed - whether digitally or in some other manner and, as such it is problematic to have a filler revising the Request instance to change its status reflecting fulfillment progress
• The fulfillment process often has complexities around tracking the details of progress. E.g. specimen collection, specimen transport, initial assessment, drug packaged, insurance processed, etc. Conveying this information in Task which has the ability to convey 'business' status, as well as the ability to break complex processes down into sub-Tasks, each with their own status provides a robust way of handling these complexities.

In situations where a source system does not track fulfillment independent of the Request resource, they may opt to surface the statuses dealing with fulfillment via one or more [contained] Task instances, though this still creates challenges around filling systems updating the Request instance and any signature mechanisms would need to accommodate this process.

Irrespective of the Request.intent , changes to the status of the Request should always be under the control of the requester and be a reflection of changes to the recommendation/authorization. For example, a Request should only change to complete when the requester determines that the action they requested has been completed as ordered (or sufficiently close to what was ordered). For further clarity, the status of a Request with a given intent (e.g. a proposal) is NOT generally changed automatically when a fulfilling Request (e.g. an order) or Event is created or has its own status changed.

If there is no closed loop process that allows the requester to evaluate what was done, then the status of a request might never change from active or might only be changed to ended when the system automatically updates the status when the recommendation/authorization has expired.

If there is a need to track status of fulfillment on a Request , this could be done with a fulfillment Task, possibly as a contained resource.

12.3.7 12.3.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" "active" or "completed". "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 12.3.10 Compound Requests

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

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

12.3.8.1 12.3.10.1 Shared requisition id

The Request.requisitionId Request.groupIdentifier element allows multiple requests to be linked as having been created as part of the same "event" "event" - generally by the same practitioner at the same time for the same subject. The "requisitionId" "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" "component" behaves as an independent request and has its own status that changes independently. In general Cancelling or suspending request with a shared groupIdentifier has no impact on other requests with the requisitionId, practitioner, authoredOn and subject for each will be immutable, but there may be situations where some workflows allow them to change. same groupIdentifier. The shared requisitionId allows business processes dependent on "simultaneous/requisition-based ordering" "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.3.8.2 12.3.10.2 "Based on" "Based on" chain

In this case "components" "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" "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 may might not transition in the same manner. For example, if the original lab order were updated to "suspended", "suspended", the initial blood draw request might be complete. The other requests might change to either "suspended" "suspended" or even "aborted" "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" "based on" relationship both resources are "active" "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 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 status of "completed" or "cancelled" or some other terminal state. proposal - though an order can be "basedOn" a proposal.

12.3.8.3 12.3.10.3 RequestGroup RequestOrchestration

This approach makes use of the RequestGroup 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 RequestGroup RequestOrchestration must have an intent of "option", "option", meaning that they cannot be interpretted 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". "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" "child" requests using the "basedOn" "basedOn" approach above. They should have a basedOn relationship with both the "parent" "parent" Request as well as the specific "option" "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.3.11 Use of 'identifier' and similar elements

The 'identifier' element is intended to be able to uniquely point to a single instance, however there are exceptions:

• In order to be unique, both Identifier.system and Identifier.value must be present.
• If the Identifier has an associated period, the identity only applies within that time-period.
• There may be circumstances where the identifier might not always be unique. For example, social security numbers could appear on multiple patients due to fraud, entry error, or the presence of multiple patient records for the same individual for legacy purposes or the needs of differing departments.

Identifiers are not intended to act as 'classifiers' or 'categories', nor are they intended to convey identifiers for other business objects. For example, if there is a need to convey a 'request' identifier on a result where the same request might produce multiple results, the 'request' identifier should never appear in [result].identifier. Instead, convey the request identifier on [result].basedOn.identifier.

Some systems may contain legacy information that puts inappropriate content in identifier elements (e.g. placing an insurance subscriber id in Patient.identifier when that should instead go in Coverage.subscriber). In these situations, it is possible that values that are not actually 'proper' identifiers may still show up in identifier elements. While this is not 'correct', systems should still be tolerant of identifiers that prove to be non-unique.

Systems may choose to enforce that some identifiers systems must be unique within their system and only in the presence of such system enforcement can identifiers be safely used with a presumption that they will always resolve to only a single distinct record. If there is a need to convey 'categories' for resources, those can be conveyed in elements other than Resource.identifier. Examples include .code, .category, special elements like .groupIdentifier, extensions, or meta.tags.

12.3.12 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.3.13 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.3.14 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
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			1 NC	1 NT			1 NT				1 T
ClaimResponse																								1 T
CommunicationRequest	1	1 T	1 T	1	1	1 C	1	1	1				1 C	1	1 T	1	1 T			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			1 NTC	1 T	1	1	1	1 T			1 T		1	1	1 T	1	1 T
EnrollmentRequest	1				1 C								1 NC			1 N	1 NT			1 NT			1 NTC
EnrollmentResponse													1 NC
MedicationRequest	1	1 T	1 NTC	1	1	1 C	1	1			1 NTC		1	1		1	1		1	1 TC		1	1	1 NT	1	1 NT
NutritionOrder	1	1 T		1	1		1	1			4 N	3 N	1	1	3 NTC	1 NC	1 T			1 TC				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	1	1 T	1 NT	1 T	1	1	1	1 T		1	1 TC		1	1	1 T	1	1 T
Task	1	1 T	0|1 ET	1	1	1 T	1	1	1		1	1 NTC	1 NTC	1	1 NT	1	1 T		1 NTC	1 NT		1	1	1 NTC	1	1 T
VisionPrescription	1	1 T		1	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