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

Background - Goals and General Principles

Page standards status: Informative

Highlight text changes?

Goals

This guide helps specification authors working on Orders, Referrals, and Transfers achieve interoperability more quickly and cost-effectively by:

• Highlighting abstractions that support reuse of functionality across care domains and jurisdictions
• Reducing ambiguity through proven workflow patterns
• Identifying key decision points
• Establishing shared terminology to streamline collaboration

This guide was motivated by the various activities globally and seeks to align these efforts. Materials used in the drafting of this guide include, as a non-exhaustive list, the work by BSeR, the NL TA Notified Pull, AU Sparked, the US DME Orders IG, the Gravity project, and others.

How Orders, Referrals, and Transfers Relate

Clinical order workflow (COW) aims to address orders placed in or directed to clinical settings. The term "order' is taken in this context to include what many groups may term "referrals" and "transfers", as the considerations for exchange and managing the request are largely identical.

Historically, these terms have been delineated by the extent to which responsibility for a patient's care was transitioned or delegated between providers. As care has become more collaborative, it is often challenging to draw bright line distinctions between these terms.

To help with discussions, brief descriptions and examples of each term are provided below.

Transfer	Referral	Order
Usually not service-specific Requestor usually does not expect an outcome after the coordination Usually changing primary responsibility for a patient's care, often with patient movement Long-Term Care (LTC)- with functional status Burn Unit - with specific tests Often includes a patient summary. May include a more specific `reason for transfer`	Usually more high level: Imaging referral for knee pain Surgical Consult Referral for physical therapy Referral to psychiatry Authorization to see Obstetrics (OB)/Maternal-Fetal Medicine (MFM) SDOH (Social Determinants Of Health) May be evaluative: Consider for transport assistance May not be authorized at the moment of creation (insurance, etc.) Fulfillers sometimes refuse	Usually more specific: X-Ray 3 view knee General expectation is that the service will occur and the overall performer is known Some lab in the network will perform this test Usually the fulfiller can't refuse to perform a service, although depending on the business agreements, they may be allowed to modify the request, such as by selecting a more specific service to perform. Additionally, Fulfillers may indicate they are not able to fulfill the request for some reason, such as a specimen's condition or quantity.

These all involve a healthcare provider deciding that action should be taken by another provider or healthcare organization. The receiving party may or may not be allowed, based on the business agreements, to reject or to modify the request for service, and the initiating party may or may not expect to receive some information back during or after the service.

This guide is designed to support both groups using FHIR messaging and those using RESTful mechanisms, including those leveraging the Subscriptions framework. This reduces lock-in, silos, and implementation burden for vendors, by providing a data model which may be represented using either paradigm.

Pre-Coordination Needed for Push-Based Exchanges

A core aim of this guide is to help specification authors to enable workflow related exchanges for orders, referrals, and transfers in a consistent way.

FHIR provides several mechanisms by which push-based payloads may be sent between two actors. Regardless of the specific FHIR mechanism chosen, all push-based exchanges require pre-coordination to define:

• Endpoints - where the information should be sent
• Events of interest - which workflow steps trigger the need for information exchange
• Payload expectations - both for structure and content. For example - a message may be sent between two parties that serves as both notification ("a result has been generated for this patient") and it's content ("no abnormal findings found"). This is analogous to HL7 v2 exchanges. Alternatively, a notification might indicate simply that data is available for retrieval if needed.
• Operational agreements - including policies on request whether a Fulfiller must confirm their ability to fulfill a Request, when and how a Placer may cancel or modify a Request after it has been accepted, etc.
• Error handling and remediation - responsibilities for correcting errors, coordinating chart updates, and involving support desks.

Implementers may approach these coordination points differently, but each must be addressed for reliable push-based exchange.

Integration architects often need to balance two competing interests. On one hand, there is value to minimizing the set of data shared until that information is necessary from a privacy perspective. On the other hand, placers may need to supply downstream systems with all information that they need to process a request. A sender may not know what information is most relevant to a downstream specialist, and there is value in reducing the frequency with which a downstream system must call-back for additional information. Depending on the broader exchange environment, it may also be difficult for the ultimate fulfillers of a request to communicate with the original placers. Environments like these encourage including more information with the initial notification. The Core Concepts section provides additional information for how Placers can manage Fulfiller access.

Brief Survey of Mechanisms for Pushing FHIR Content

This section provides context on the main FHIR-based mechanisms for pushing content between actors.

RESTful POST of Resources (Creates or Updates)

• This mechanism may be used alongside others. It requires the availability of FHIR servers.
• Actors must pre-coordinate where the definitive instances of shared FHIR resources will be hosted, when they should be exchanged, who can update them, and under what circumstances.
• Note that more complex transactions may be needed. For example, if a Placer attempts to POST a Task (in the case where the Task is at the Fulfiller), the parties must agree on how to reference the patient; e.g. whether the Placer must use $match to obtain the Fulfiller's Patient resource, or if the Fulfiller will resolve a Patient resource reference to the Placer's server.

Batch or Transaction bundles:

• These may operate similar to the RESTful Create and Update described above, but provide a mechanism for a client to submit several transactions as a set, which can reduce network traffic. This guide does not explore this option in detail.

FHIR Messaging:

• Event-driven exchange using a Bundle with a MessageHeader and related resources.
• Resources in the message are not required to persist or be queryable.
• Messaging is conceptually similar to HL7 v2, requiring tight coordination on events, message content, and identifiers.
• Message senders should include all potentially relevant information, as message recipients may not be able to retrieve more later.

FHIR Subscriptions:

• These can also function in a manner similar to HL7 v2. A Subscription records that a party would like to receive content from a server on a specified channel when certain events occur. A subscription-notification bundle is sent when these triggers occur.
• Subscriptions provide two optional features that support order, referral, and transfer workflows:
  • SubscriptionTopics: a data-holder MAY make a SubscriptionTopic available to which authorized data requestors may subscribe for updates. Such "dynamic subscriptions" let an actor specify their own endpoint, events of interest, and desired format from a menu of options chosen by the data holder. This is purely optional within Subscriptions: administrators may instead discuss updates out of band and manually configure Subscriptions, just as administrators do for HL7v2 interfaces today.
  • Query guidance: subscription-notifications can include instructions for how a notification recipient (e.g. a Fulfiller getting a subscription-notification about a Task and a ServiceRequest being available at the Placer's FHIR server) may query for additional information later. For instance, if insurance coverage might change between when a referral is created and when service should be provided, the subscription-notification sent for the referral can guide a Fulfiller on how to retrieve updated Coverage data if or when it is needed later.