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

12.3 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.3.4 References

This pattern is implemented by Appointment , AppointmentResponse , CarePlan , Claim , CommunicationRequest , Contract , CoverageEligibilityRequest , DeviceRequest , EnrollmentRequest , ImmunizationRecommendation , MedicationRequest , NutritionOrder , RequestGroup , ServiceRequest , SupplyRequest and VisionPrescription .

12.3.4 12.3.5 Pattern Content

 

alternate definitions: Master Definition XML + JSON .

12.3.4.1 12.3.5.1 Terminology Bindings

Path	Definition	Type	Reference
Request.status	Codes identifying the lifecycle stage of a request.	Required	RequestStatus
Request.statusReason	Codes identifying the reason for the current state of a request.	Unknown	No details provided yet
Request.intent	Codes indicating the degree of authority/intentionality associated with a request.	Required	RequestIntent
Request.priority	Identifies the level of importance to be assigned to actioning the request.	Required	RequestPriority
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.	Unknown	No 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.	Unknown	No details provided yet
Request.reasonCode Request.reason	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.	Unknown	No details provided yet

12.3.5 12.3.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.3.6 12.3.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.3.7 12.3.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.3.8 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" 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.9 12.3.10 Compound Requests

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

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

12.3.9.1 12.3.10.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.9.2 12.3.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. 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.9.3 12.3.10.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.9.4 12.3.10.4 Mappings

1 1 1 1 NT 1 1 1 NT 1 1 1 NTC 1 1 1 1 1 1 NT 1

	identifier	instantiatesCanonical	instantiatesUri	basedOn	replaces	groupIdentifier	status	statusReason	intent	priority	doNotPerform	code	subject	encounter	occurrence[x]	authoredOn	requester	reported[x]	performerType	performer	reasonCode reasonReference reason	insurance	supportingInfo	note	relevantHistory
Appointment	1			1	1		1			1 T		1 NC			4 NTC NC	1 N				1 NTC 1 NC			1 N	1 NT
AppointmentResponse	1			1 N			1 N								2 NT N				1 NC	1 N				1 NT N
CarePlan	1	2	2	1	1		2	1	1		1	1	1		2 NT N	1 N	1 N	1 C		2 N NC			1	1
Claim	2				1 N		1			1 T			1 N			1 N	1 N			1 N			1 T
CommunicationRequest	1			1	1	1	1	1	1	1	1		1 C		1	1	1			2 NC			1 N	2 NT N
Contract	2						1 C					2 N	1 C		2 N	2 N	1 N			1 N
CoverageEligibilityRequest	1						1			1 T			1 N			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
EnrollmentRequest	1						1 C						1 NC			1 N	1 N			1 N		1 N
ImmunizationRecommendation	1	1	1									1 NC	1 N		1 NTC NC	1 N							1 N
MedicationRequest	1			1	1 N	1	1	1	1	1		1 NT N	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 N	1
RequestGroup	1	1	1	1	1	1	1		1	2		2 C	1 C	1	1 NT N	1	1 N			1 NC	1		1 NT N	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
SupplyRequest	1			1			1 C			1		1 NT N			1	1	1			1 NC	1
Task	1	1		1	E	1	1		1	1		1	1 NC			1	1					1		1	1
VisionPrescription	1						1						1 N			1 N	1 N