5.27 Resource Order - Content

5.27.1 Scope and Usage

NOTE: This resource is slated to be eliminated in favor of the Task resource as part of the FHIR Workflow refactoring. Readers of this resource are encouraged to review the Task resource and consider using it instead and/or to provide feedback if they feel it will be inadequate to satisfy the use-cases associated with this resource.

An order resource describes a request 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 are 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 can actually be performed. Often these real world dependencies are only implicit in the order details.

5.27.2 Background and Context

5.27.2.1 Separation of Order and Order details

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.

5.27.2.2 Using Orders in a RESTful context

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)

5.27.2.3 Using Orders with messaging

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

In a synchronous message, an order message (i.e. a bundle with a Message Header resource, an order resource and a detail resource for the order - see below) is sent to a system, and it responds with a message that includes the response (a Message Header 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 event code is also defined. With this code, 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.

5.27.2.4 Using orders in other contexts

There are a wide variety of ways to implement Order/Order Response. The Order and Order Response resources are special resources created to manage behavior 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.

5.27.3 Boundaries and Relationships

As described above, the split between the Order resource and the domain order resources is that Order is a workflow resource, not a clinical resource. It is used to manage fulfillment requests and other state transitions for the 'real' clinical orders - DeviceUseRequest, DiagnosticOrder, MedicationOrder, NutritionOrder and ProcedureRequest.

• Structure
• UML
• XML
• JSON
• All

Structure

Name	Flags	Card.	Type	Description & Constraints
Order	Σ		DomainResource	A request to perform an action
identifier	Σ	0..*	Identifier	Identifiers assigned to this order by the orderer or by the receiver
date	Σ	0..1	dateTime	When the order was made
subject	Σ	0..1	Reference(Patient | Group | Device | Substance)	Patient this order is about
source	Σ	0..1	Reference(Practitioner | Organization)	Who initiated the order
target	Σ	0..1	Reference(Organization | Device | Practitioner)	Who is intended to fulfill the order
reason[x]	Σ	0..1		Text - why the order was made
reasonCodeableConcept			CodeableConcept
reasonReference			Reference(Any)
when	Σ I	0..1	BackboneElement	When order should be fulfilled Provide a code or a schedule, but not both
code	Σ I	0..1	CodeableConcept	Code specifies when request should be done. The code may simply be a priority code
schedule	Σ I	0..1	Timing	A formal schedule
detail	Σ	1..*	Reference(Any)	What action is being ordered
Documentation for this format

<Order xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Identifiers assigned to this order by the orderer or by the receiver --></identifier>
 <date value="[dateTime]"/><!-- 0..1 When the order was made -->
 <subject><!-- 0..1 Reference(Patient|Group|Device|Substance) Patient this order is about --></subject>
 <source><!-- 0..1 Reference(Practitioner|Organization) Who initiated the order --></source>
 <target><!-- 0..1 Reference(Organization|Device|Practitioner) Who is intended to fulfill the order --></target>
 <reason[x]><!-- 0..1 CodeableConcept|Reference(Any) Text - why the order was made --></reason[x]>
 <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 Timing A formal schedule --></schedule>
 </when>
 <detail><!-- 1..* Reference(Any) What action is being ordered --></detail>
</Order>

{
  "resourceType" : "Order",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Identifiers assigned to this order by the orderer or by the receiver
  "date" : "<dateTime>", // When the order was made
  "subject" : { Reference(Patient|Group|Device|Substance) }, // Patient this order is about
  "source" : { Reference(Practitioner|Organization) }, // Who initiated the order
  "target" : { Reference(Organization|Device|Practitioner) }, // Who is intended to fulfill the order
  // reason[x]: Text - why the order was made. One of these 2:
  "reasonCodeableConcept" : { CodeableConcept },
  "reasonReference" : { Reference(Any) },
  "when" : { // When order should be fulfilled
    "code" : { CodeableConcept }, // C? Code specifies when request should be done. The code may simply be a priority code
    "schedule" : { Timing } // C? A formal schedule
  },
  "detail" : [{ Reference(Any) }] // R!  What action is being ordered
}

Structure

Name	Flags	Card.	Type	Description & Constraints
Order	Σ		DomainResource	A request to perform an action
identifier	Σ	0..*	Identifier	Identifiers assigned to this order by the orderer or by the receiver
date	Σ	0..1	dateTime	When the order was made
subject	Σ	0..1	Reference(Patient | Group | Device | Substance)	Patient this order is about
source	Σ	0..1	Reference(Practitioner | Organization)	Who initiated the order
target	Σ	0..1	Reference(Organization | Device | Practitioner)	Who is intended to fulfill the order
reason[x]	Σ	0..1		Text - why the order was made
reasonCodeableConcept			CodeableConcept
reasonReference			Reference(Any)
when	Σ I	0..1	BackboneElement	When order should be fulfilled Provide a code or a schedule, but not both
code	Σ I	0..1	CodeableConcept	Code specifies when request should be done. The code may simply be a priority code
schedule	Σ I	0..1	Timing	A formal schedule
detail	Σ	1..*	Reference(Any)	What action is being ordered
Documentation for this format

UML Diagram

XML Template

<Order xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Identifiers assigned to this order by the orderer or by the receiver --></identifier>
 <date value="[dateTime]"/><!-- 0..1 When the order was made -->
 <subject><!-- 0..1 Reference(Patient|Group|Device|Substance) Patient this order is about --></subject>
 <source><!-- 0..1 Reference(Practitioner|Organization) Who initiated the order --></source>
 <target><!-- 0..1 Reference(Organization|Device|Practitioner) Who is intended to fulfill the order --></target>
 <reason[x]><!-- 0..1 CodeableConcept|Reference(Any) Text - why the order was made --></reason[x]>
 <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 Timing A formal schedule --></schedule>
 </when>
 <detail><!-- 1..* Reference(Any) What action is being ordered --></detail>
</Order>

JSON Template

{
  "resourceType" : "Order",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Identifiers assigned to this order by the orderer or by the receiver
  "date" : "<dateTime>", // When the order was made
  "subject" : { Reference(Patient|Group|Device|Substance) }, // Patient this order is about
  "source" : { Reference(Practitioner|Organization) }, // Who initiated the order
  "target" : { Reference(Organization|Device|Practitioner) }, // Who is intended to fulfill the order
  // reason[x]: Text - why the order was made. One of these 2:
  "reasonCodeableConcept" : { CodeableConcept },
  "reasonReference" : { Reference(Any) },
  "when" : { // When order should be fulfilled
    "code" : { CodeableConcept }, // C? Code specifies when request should be done. The code may simply be a priority code
    "schedule" : { Timing } // C? A formal schedule
  },
  "detail" : [{ Reference(Any) }] // R!  What action is being ordered
}