Clinical Order Workflows, published by HL7 International / Orders and Observations. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-cow-ig/ and changes regularly. See the Directory of published versions

Order Initiation

Page standards status: Informative

Order initiation refers to the different activities that may exist or be required up until an order or authorization is ready to be actioned. There are some considerations and mechanisms to consider in this ordering process:

Order progression

Status and intent:

• request.status is a coded element with required binding - the status of the request is limited to those statuses identified in the resource, and MAY NOT be extended. The request .status is the status of the authorization, not the status of execution.

  • Orders can be created in active status, or may evolve from draft to active - an order instance may be created as "draft" and then be updated to become "active" …
• the extension statusReason contains reasons for a given status of authorization. It SHALL NOT be used to contain detailed statuses.
  • example: "expired" is a possible reason for an order to be "revoked", but is not an additional status.

• request.intent is an immutable element, meaning that systems SHALL NOT update the intent of an order. For creating a plan from a proposal, or an order from a plan or proposal, a new request resource instance MUST be created, basedOn the proposal/plan instance.

  • Note: some possible values for intent have a hierarchical relationship. This is means that while intent is immutable, it is possible to change from an intent to a 'sub-intent' because this doesn't change the intent, it just refines it.
• Order intent may be, among others:
  • proposal: a suggestion made by someone/something that does not have an intention to ensure it occurs.
  • plan: an intention to ensure something occurs without providing an authorization for others to act.
  • order: a request/demand and authorization for action by the requestor.

Co-authoring

In some cases, additional confirmation / sign-off is needed - this is common for special procedures, controlled substances.
In other cases, order creation follows different steps - resulting in co-authoring of the order. This Implementation Guide currently addresses fulfillment of orders, so this co-authoring is therefore not in the primary scope.

Prior Authorization

In several cases, before the order can be operationalized, a series of steps may be required. Prior Authorization as a cost control mechanism is one of those common use cases which may happen as part of order initiation.

Co-authoring, prior authorization can include different participants and can be predefined or ad-hoc processes. While this is not the focus of the present edition of this guidance, implementers are invited to provide input on their needs, for consistent guidance where possible.

Actionable orders

In FHIR, requests express authorizations, and are not intended to be actionable per se. An order becomes actionable if one of the following is fulfilled:

• it's tagged as actionable (using the "actionable" tag in meta.tag)
• there's a Task pointing to the request telling to fulfill it
• there's a message or operation that implies it is to be actioned

The FHIR Specification recommends against considering orders actionable outside these scenarios, as it may prevent system expansion and/or break interoperability with systems that follow FHIR workflow recommendations.

The Goal of the COW Implementation Guide is to describe how to express workflows for actionable Orders using the Task Resource as mentioned in the second bullet point."

Ordering from Service/Product Catalogs

In many systems, the "orderable" items are established in a catalog - sometimes referred to as a "formulary" for Medications. The service catalogs may present different types of functionalities on the services, like searching, clustering, or providing details on the orderable items.

The availability of catalogs and interactions with catalog services are a common dependency but are out of scope of this guidance. They are mentioned here to acknowledge that:

The interaction with catalogs may exist before or during the creation and update of orders. Catalog information can be downloaded and synchronized in advance, or may be queried for example before ordering, changing or validating orders, or for checking or fulfilling orders. This interaction is orthogonal to the scope of this Implementation Guide. For more details about order catalogs, users are invited to consult the Order Catalog Implementation Guide.

• HL7 is producing guidance on order catalogs, namely the Order Catalog Implementation Guide.

---

Order set protocols

Protocols are sets of defined orders, possibly interdependent. Order sets may be ordered:

• As group of orders, as defined in grouping;
• In a single request, if one single designation or code exists for the order set. In this case, the order set may be broken down:
  • at the order Placer when seeking fulfillment - thus becoming a group order.
  • at the Fulfiller side, upon initiating fulfillment. In this case, the orchestration is done by one Task for the entire order set; additional orchestration may be done by grouping Fulfiller orders, with one task coordinating the orders, or several tasks - see order grouping.

Decision Support in ordering

One of the most common uses for Decision Support is to assist in ordering. While this implementation guide focuses on the order execution and tracking, this guidance is designed to be compatible with Decision Support Guidance, namely the Clinical Practice Guidelines and its workflows.