PATIENT ADMINISTRTAION (PA) Workgroup Development Draft

5.27 Resource Order - Content

This resource is marked as a draft.

This resource maintained by the Orders and Observations Work Group

A request to perform an action.

5.27.1 Scope and Usage

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, MedicationPrescription, NutritionOrder and ProcedureRequest.

This resource is referenced by Appointment, CarePlan, ClinicalImpression and OrderResponse

5.27.4 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Order DomainResourceA request to perform an action
... identifier 0..*IdentifierIdentifiers assigned to this order by the orderer or by the receiver
... date 0..1dateTimeWhen the order was made
... subject 0..1Patient | Group | Device | SubstancePatient this order is about
... source 0..1PractitionerWho initiated the order
... target 0..1Organization | Device | PractitionerWho is intended to fulfill the order
... reason[x] Text - why the order was made
.... reasonCodeableConcept0..1CodeableConcept
.... reasonReference0..1Any
... authority 0..1AnyIf required by policy
... when I0..1ElementWhen order should be fulfilled
Provide a code or a schedule, but not both
.... code I0..1CodeableConceptCode specifies when request should be done. The code may simply be a priority code
.... schedule I0..1TimingA formal schedule
... detail 1..*AnyWhat action is being ordered

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Order DomainResourceA request to perform an action
... identifier 0..*IdentifierIdentifiers assigned to this order by the orderer or by the receiver
... date 0..1dateTimeWhen the order was made
... subject 0..1Patient | Group | Device | SubstancePatient this order is about
... source 0..1PractitionerWho initiated the order
... target 0..1Organization | Device | PractitionerWho is intended to fulfill the order
... reason[x] Text - why the order was made
.... reasonCodeableConcept0..1CodeableConcept
.... reasonReference0..1Any
... authority 0..1AnyIf required by policy
... when I0..1ElementWhen order should be fulfilled
Provide a code or a schedule, but not both
.... code I0..1CodeableConceptCode specifies when request should be done. The code may simply be a priority code
.... schedule I0..1TimingA formal schedule
... detail 1..*AnyWhat action is being ordered

 

Alternate definitions: Schema/Schematron, Resource Profile (XML, JSON)

5.27.4.1 Terminology Bindings

PathDefinitionTypeReference
Order.when.code When a requested action should be performed (e.g. STAT, daily, evenings, etc.)UnknownNo details provided yet

5.27.4.2 Constraints

  • ord-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))

5.27.5 Processing Order Details

Each request includes one or more detail elements that specify what is being ordered. The following kinds of orders have been defined:

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 definition for the resource used in the detail 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 - it is always an instruction/request for something to be done, while other resources may have some kind of status element for this purpose. If the definition of the resource does not explicitly make it clear this, then it cannot be the target of an order (e.g. you cannot order a diagnostic report, for example - you have to order a diagnostic order instead).

DSTU note: This list is only a start - the full list of what can be ordered much longer, and yet to be described. Implementers should expect this list to grow in subsequent versions, and feedback is welcome from implementers who use the Order resource for other kinds of orders.

5.27.6 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

NameTypeDescriptionPaths
authorityreferenceIf required by policyOrder.authority
(Any)
datedateWhen the order was madeOrder.date
detailreferenceWhat action is being orderedOrder.detail
(Any)
patientreferencePatient this order is aboutOrder.subject
(Patient)
sourcereferenceWho initiated the orderOrder.source
(Practitioner)
subjectreferencePatient this order is aboutOrder.subject
(Group, Device, Patient, Substance)
targetreferenceWho is intended to fulfill the orderOrder.target
(Practitioner, Organization, Device)
whendateA formal scheduleOrder.when.schedule
when_codetokenCode specifies when request should be done. The code may simply be a priority codeOrder.when.code