Clinical Order Workflows
1.0.0-ballot - STU 1 Ballot

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

## Fulfiller Determination

Page standards status: Informative

This section provides guidance for several mechanisms by which a Fulfiller may become aware of a request. Examples are provided that leverage pure REST, Subscriptions and Messaging. However, although this guidance is supplied, other exchange mechanisms may be used provided that they adhere to the guidance on representing a request's state and for resource ownership.

The ultimate Fulfiller of an order may not be known at the time an order is first created. A Placer may initiate and authorize:

- A simple order, in which a Placer creates a request and directs it to a specific performer who the Placer is confident will make a best-effort attempt to fulfill the request.
- A simple referral, in which a Placer creates a request for a specific intended performer, but the selected performer may decline to perform the requested service.
- A request which a patient then uses to seek service at a place of their choosing.
- A request which a Placer directs to an expected performer, with the option that a patient may elect to receive the service elsewhere.
- A request that may be broadcasted to several potential performers, in which any of them may claim the request.
- A request sent to several potential performers, where the requestor and patient will then review proposals or bids sent back by the performers before selecting a definite performer.
- A request to a central coordinator who will assign the request to a performer and notify the requestor of who will fulfill the request.
- A request to a central coordinator who will assign the request to a performer and additionally mediate further communication between the requestor and performer.

### Placer assigned

In the most simple flow, the Placer creates a request and indicates the specific Fulfiller that should perform it. In this scenario, the Placer is confident - based on pre-coordinated business and IT agreements, availability, etc. - that the performer won't decline the request.

Based on the workflow of interest, the performer may or may not notify the requestor of an 'outcome' at a later time.

##### Task at Fulfiller

Task at Fulfiller

#### Example using Task at Placer with Subscriptions

Task at Placer with Subscriptions

#### Example using Messaging (Relying on Identifiers)

Messaging

### Request with acceptance

When a requestor can't be certain of whether the Fulfiller will be willing to perform a service (based on availability, insurance, etc.), they may ask the Fulfiller to confirm that they accept the proposed service. If the performer declines to perform the service (or fails to respond within a pre-coordinated period), the requestor may choose to follow up with other potential performers.

Task at Fulfiller
Task at Placer with Subscriptions

#### Example using Messaging (Relying on Identifiers)

Messaging

### Patient-mediated requests

Many orders and referrals take the form that a provider 'authorizes' that care with another provider may occur, but the patient (or their agent) then manages the coordination of that care. Once the patient has selected a performer, that performer may wish to query additional information (including the authorization) and to share information with the original requestor.

Examples:

- In community prescriptions, the Patient usually chooses a Pharmacy.
- A requestor may indicate that a blood draw should occur for a patient. The patient may choose for themselves to which lab they will present (perhaps one lab is on their commute between their home and work).
- A provider may determine that a patient would benefit from receiving care in a long term care facility, and authorize that level of service. The patient and their family may consider several care facilities before deciding which they like.
- A patient may discuss with their primary care provider that they would like to see a specialist, such as OB/MFM, an orthopedist, a psychologist, etc. The GP may authorize this service without having a specific performer in mind, and may rely on the patient to then find a specialist.

##### Example with Subscriptions with Task at Fulfiller

Subscriptions - Task at Fulfiller

### Request with multiple performers

Sometimes, a requestor may choose to immediately notify several potential performers that a service has been requested. If the requestor and the patient do not have a preference around who will perform the service, it may be that the first potential Fulfiller to indicate availability may functionally 'claim' that service.

This can be accomplished by leveraging the Request-with-Acceptance flow, and keeping a separate task per potential Fulfiller. For brevity, only one flow is described here.

Subscriptions - Task at Placer

### Request with multiple performers with bidding

Alternatively (and more often), a requestor may notify one or more potential Fulfillers that they have a which must be performed. Those potential Fulfillers may respond back with a 'bid' describing the service they could perform. The details of that 'bid' will vary by care-domain, but may indicate the performer's availability, the details of a more specific service they would perform, cost, information about the specific performer who may provide the service, etc.

The requestor and the patient may then review the information received from potential performers and then decide which specific performer will be used.

Subscriptions - Task at Placer

### Requests to a central coordinator

Many locales and care domains rely on a central coordinator to manage some aspects of an order, referral, or transfer workflow. In these flows, a requestor notifies a central management group that they have a service which must be performed, and that central management group may then triage, notify performers, assign providers, or perhaps even schedule the service.

Details may vary considerably by business agreements (such as whether the coordinator may assign a request to a performer, or merely notify them) and architecture.

Some common reasons for a central coordinator include:

- Facilitating triage of scarce resources
- Managing waitlists
- Facilitating some parts of the exchange like endpoint discovery and client registration

Given the variability, this section is provided only for illustrative value. This section outlines two potential configurations (of several) based on the capabilities of the broker. The intent of the first example is that (with regards to exchange functionality) the Placer need be only minimally aware of whether they are interacting with a coordinator or with a Fulfiller directly.

In the second flow, the coordinator may identify relevant service providers, triage the request, and even assign the request. In this example, once the assignment has occurred, the Placer then interacts directly with the designated Fulfiller. This saves on the need for the Coordinator to facilitate rewrites or for Placers to track the source of outputs, but may require greater pre-coordination to facilitate client registration, endpoint discovery, etc. between Placers and Fulfillers.

Other IGs may build on top of this to include details of the endpoint discovery, handling holds the coordinator may place on an assigned Fulfiller, tracking authorization from a coordinator, etc.

Similar flows may be constructed using FHIR messaging or using FHIR Subscriptions with the shared coordination Task hosted at the Placer.

Coordinator Mediated Exchange
Initial Request to Triage With Later Direct Communication