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

Identifiers assigned to this request by the requester, performer and other systems.

Allows identification of the request as it is known by various participating systems and in a way that remains consistent across servers.

The identifier.type element is used to distinguish between the identifiers assigned by the requester/placer and the performer/filler.

A protocol, guideline, orderset or other definition that is adhered to in whole or in part by this request.

[The allowed reference resources may be adjusted as appropriate for the request resource].

A plan, proposal or order that is fulfilled in whole or in part by this request.

Allows tracing of authorization for the request and tracking whether proposals/recommendations were acted upon.

[The allowed reference resources may be adjusted as appropriate for the request resource].

Completed or terminated request(s) whose function is taken by this new request.

Allows tracing the continuation of a therapy or administrative process instantiated through multiple requests.

The replacement could be because the initial request was immediately rejected (due to an issue) or because the previous request was completed, but the need for the action described by the request remains ongoing.

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

Some business processes need to know if multiple items were ordered as part of the same "prescription" or "requisition" for billing or other purposes.

Requests are linked either by a "basedOn" relationship (i.e. one request is fulfilling another) or by having a common requisition. Requests that are part of the same requisition are generally treated independently from the perspective of changing their state or maintaining them after initial creation.

The current state of the request.

The status is generally fully in the control of the requester - they determine whether the order is draft or active and, after it has been activated, completed, cancelled or suspended. States relating to the activities of the performer are reflected on either the corresponding Event(s) or using the Task resource.

A nominal state-transition diagram can be found in the [[request.html#statemachine | Request pattern]] documentation

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is.

Indicates the level of authority/intentionality associated with the request and where the request fits into the workflow chain.

Proposals/recommendations, plans and orders all use the same structure and can exist in the same fulfillment chain.

When resources map to this element, they are free to define as many codes as necessary to cover their space and will map to "proposal, plan or order". Can have multiple codes that map to one of these. E.g. "original order", "encoded order", "reflex order" would all map to "order". Expectation is that the set of codes is mutually exclusive or a strict all-encompassing hierarchy.

Indicates how quickly the {{title}} should be addressed with respect to other requests.

A code that identifies the specific service or action being requested.

The individual or set of individuals the action is to be performed on or for.

Links the request to the Patient context.

[For resources that aren't patient-specific, the set of allowed resources may be extended to include other things. Group should generally be retained unless there's certainty this resource won't be used for veterinary, research or public health settings where Group may be necessary (e.g. this cage of rats/crate of chickens, group of people in a 5 mile radious of the incident, etc.)].

The encounter or episode of care that establishes the context for making this request.

Links the request to the Encounter context.

This will typically be the encounter the request was created during, but some requests may be initiated prior to or after the official completion of an encounter or episode but still be tied to the context of the encounter or episode (e.g. pre-admission lab tests).

The date or time(s) at which the activity or service is desired to occur.

[The list of types may be constrained as appropriate for the type of event].

For draft requests, indicates the date of initial creation. For requests with other statuses, indicates the date of activation.

The individual who initiated the request and has responsibility for its activation.

[Resources may choose to replace this with just a single requester where there's no need to responsible organization].

The device, practitioner, etc. who initiated the request.

The organization the device or practitioner was acting on behalf of.

Practitioners and Devices can be associated with multiple organizations. This element indicates which organization they were acting on behalf of when authoring the request.

The type of individual that is desired to act upon the request.

If performer is also specified, this indicates what type of performer is desired in the event the requested performer is not available.

If specified without indicating a performer, this indicates that the performer must be of the specified type. If specified with a performer then it indicates the requirements of the performer if the designated performer is not available.

Indicates who or what is being asked to perform the request.

Describes why the request is being made in coded or textual form.

Textual reasons can be caprued using reasonCode.text.

Indicates another resource whose existence justifies this request.

[Additional resources may be added as appropriate].

Information that may be needed by/relevant to the performer in their execution of this request.

Comments made about the request by the requester, performer, subject or other participants.

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

This element does not point to the Provenance associated with the current version of the resource - as it would be created after this version existed. The Provenance for the current version can be retrieved with a _revinclude.