5.12 Order リソース

Home ＞ Administrative ＞ Order [order]

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.

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.

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)

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.

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.

Alternate definitions: Schema/Schematron, Resource Profile

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

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

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.

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 for RESTful searches. The standard parameters also apply. See Searching for more information.