This page is part of the FHIR Specification (v0.11: DSTU 1 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

Resource Order - Content 5.12

A request to perform an action.

The resource name as it appears in a RESTful URL is [root]/order/

An order resource describes an order that an action be performed. An order is expected to lead to one or more responses that describe the outcome of processing/handling the order. The order resource is focused on the process of actually requesting an action be performed; the actual action to be performed is detailed in a separate resource that contains the details. Note that orders are often called "requests", but this name is not used here since the word "request" is used differently elsewhere in this specification.

Note that there is a variety of processes associated with making and processing orders. Some orders may be handled immediately by automated systems but most require real world actions by one or more humans. Some orders can only be processed when other real world actions happen, such as a patient actually presenting themselves so that the action to be performed. Often these real world dependencies are only implicit in the order details.

Separation of Order and Order details 5.12.1

In healthcare, information that a particular action has been requested is often widely disseminated throughout the context of a patient's healthcare. For example, the patient's healthcare record will often include a list of prescriptions that have been made for the patient. For this reason, the presence of a prescription record itself is not enough to create an obligation for a dispense to occur. Most other things that can be ordered follow this same pattern.

For this reason, the information about what is requested is separated from the actual request for an action to be taken. The various workflows around the actual order/fulfillment process are associated with this resource and the Order Response resource, while the details of what is actually ordered are delegated to other resources.

Using Orders in a RESTful context 5.12.2

In a RESTful context, a server functions as a repository of requests. When the server accepts the order, it has only stored the order; there is no direct response to the order. Some other process detects the existence of the order, processes it, and creates one or more responses as the order is processed. Usually, these responses are made available on the same server as the order, so that the client can monitor the result of the original order.

A client can determine that an order has not been performed by searching for order resources with no matching responses (see below)

Using Orders with messaging 5.12.3

Two message types are defined for sending orders: synchronous and asynchronous.

In a synchronous message, an order message (i.e. a bundle with a message resource, an order resource and a details resource) is sent to a system, and it responds with a message that includes the response (a message resource, and Order Response resource, along with additional details as appropriate). This synchronous message exchange is simple, but only useful where there only needs to be one response, and where the response can be made in a timely fashion.

For more general use, an asynchronous message type is also defined. With this type, the requesting system sends the order message, and receives a simple acknowledgement message (only a message resource) that acknowledges that the order was received. Then the receiving system sends one or more response messages as the order is processed. Each of these response messages is sent back to the originating system, which also acknowledges receipt of these messages with an acknowledgement message.

Using orders in a other contexts 5.12.4

There are a wide variety of ways to implement Order/Order Response. The Order and Order Response resources are special resources created to manage behaviour in a RESTful or messaging context. In other contexts, such as a Service based environment, there may be alternate methods for managing this behavior that are more appropriate, and there is no need to use Order/Order Response in these contexts.

Resource Content 5.12.5

<Order xmlns="http://hl7.org/fhir">
 <!-- from Resource: extension, narrative, and contained -->
 <date value="[dateTime]"/><!-- 0..1 When the order was made -->
 <subject><!-- 0..1 Resource(Patient) Patient this order is about --></subject>
 <source><!-- 0..1 Resource(Practitioner) Who initiated the order --></source>
 <target><!-- 0..1 Resource(Organization|Device) Who is intended to fulfill the order --></target>
 <reason value="[string]"/><!-- 0..1 Text - why the order was made -->
 <authority><!-- 0..1 Resource(Any) If required by policy --></authority>
 <when>  <!-- 0..1 When order should be fulfilled -->
  <code><!-- 0..1 CodeableConcept Code specifies when request should be done. The code may simply be a priority code --></code>
  <schedule><!-- 0..1 Schedule A formal schedule --></schedule>
 </when>
 <detail><!-- 1..* Resource(Any) What action is being ordered --></detail>
</Order>

Alternate definitions: Schema/Schematron, Resource Profile

Terminology Bindings 5.12.5.1

Path	Definition	Type	Reference
Order.when.code	When a requested action should be performed	Unknown	No details provided yet

Constraints 5.12.5.2

• Inv-1: On Order.when: Provide a code or a schedule, but not both (xpath on f:Order/f:when: exists(f:code) != exists(f:schedule))

Processing Order Details 5.12.6

Each request includes one or more detail elements that specify what is being ordered. The following kind of orders can be made:

Description	Order Resource	Response Resources	Notes
Request for Diagnostic Investigation	DiagnosticOrder	0..* DiagnosticReport	Local work flow arrangements will determine whether the laboratory handles a request by waiting for a specimen, or for the patient, or by visiting the patient directly to obtain the specimen (i.e. phlebotomy ward round)
Order to supply a prescription	MedicationPrescription	0..* MedicationAdministration or MedicationDispense
Transfer of care from one practitioner to another	Referral (Resource not yet developed)	n/a

Note that a resource may only be used for the order details if the resource type explicitly defines how it is known to be something requested, as opposed to (for instance) something that has happened. For some resources, such as a prescription, this is defined to be always true, while other resources may have some kind of status element for this purpose. If the resource type does not explicitly define this, then it cannot be the target of an order.

Auction Protocol 5.12.7

The order and response resources can be used in an auction context, where the order will actually be offered to multiple service providers and then fulfilled by a single provider based on some criteria determined from their responses. The auction protocol may be implemented explicitly by the end user and provider of the order/response, or, in some cases, it may be implemented (partially) transparently by a broker system that sits between them.

In the auction protocol, the order is created without a specified target provider that is intended to fulfill the order. This order is passed to multiple target systems that provide a response based on the service and cost they are prepared to provide. The source or broker selects a preferred provider based on the information provided, updates the target provider on the order and then updates the order in the repository or resends it to the original target systems, which know whether or not they are the winner of the auction by the target system value.

Search Parameters 5.12.8

Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.

Name / Type	Description	Paths
_id : token	The logical resource id associated with the resource (must be supported by all servers)
authority : reference	If required by policy	Order.authority
date : date	When the order was made	Order.date
detail : reference	What action is being ordered	Order.detail
source : reference	Who initiated the order	Order.source
subject : reference	Patient this order is about	Order.subject
target : reference	Who is intended to fulfill the order	Order.target
when : date	A formal schedule	Order.when.schedule
when_code : token	Code specifies when request should be done. The code may simply be a priority code	Order.when.code