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

Workflow State Overview

Page standards status: Informative

These table outline how a Request can be represented across its lifecycle independent of the chosen FHIR exchange mechanism. Specification authors building on this IG may convey equivalent states using other methods (e.g., MessageHeader.event), but must ensure that required information is captured in both the Task and the Request. This guidance builds on the Task state machine

Not all states will apply to every workflow or use case, and implementations may not need to expose resources for every stage. Authors extending this guide may further refine these states using elements like Task.businessStatus to suit specific needs.

TODO - should we combine this with the Fulfiller Selection page?

Request to a Single Fulfiller with Acceptance

In this example, the placer and the fulfiller's business agreement requires that the fulfiller confirm whether they can perform the desired service.

Workflow State to Represent	Request resource representation	Task resource representation	Event resources representation	Descriptions
Request placed and performer selected	Request: - Status: active - Intent: order	Coordination Task: - Status: requested - Owner: [specified] - Code: fulfill - Intent: order	Not set	This state can be a starting point for systems where the authorization of a request and the selection of a performer are done at the same time.
Fulfiller Awaiting Information	Request: - Status: active - Intent: order	Coordination Task: - Status: received - BusinessStatus: Awaiting Information - StatusReason/ReasonReference: [details on the information needed, such as a questionnaire or Task back to the placer] - Owner: [specified] - Code: fulfill - Intent: order	Not set
Fulfiller Accepted	Request: - Status: active - Intent: order	Coordination Task: - Status: accepted - Owner: [specified] - Code: request-fulfillment - Intent: order	Not set
In Progress	Request: - Status: active - Intent: order	Coordination Task: - Status: in-progress - Owner: [specified] - Code: fulfill - Intent: order	Not set
Partial fulfillment	Request: - Status: active - Intent: order	Coordination Task: - Status: in-progress - BusinessStatus: [images available, end exam, awaiting interpretation, etc.] - Code: fulfill - Intent: order	Awaiting Interpretation
Partial fulfillment	Request: - Status: active - Intent: order	Coordination Task: - Status: in-progress - BusinessStatus: [images available, end exam, awaiting interpretation, etc.] - Code: fulfill - Intent: order - 1..* Output	Draft	Unlike the previous state, an output has been started, but is still in a draft state. This may not be surfaceable
Preliminary fulfillment	Request: - Status: active - Intent: order	Coordination Task: - Status: in-progress - BusinessStatus: Preliminary - Code: fulfill - Intent: order - 1..* Output	Preliminary
Complete	Request: - Status: completed - Intent: order	Coordination Task: - Status: completed - Owner: [specified] - Code: fulfill - Intent: order - 0..* Output (DiagnosticReport, Observations, DocumentReference, CarePlan, etc.)	Complete (if service has an output)

Request to Bid to Multiple Fulfillers:

This flow differs from the previous flow in that multiple potential fulfillers are informed of the request. Potential fulfillers may respond with information about their ability to perform the service, before the patient and their provider ultimately choose a performer.

Workflow State to Represent	Request resource representation	Task resource representation	Event resources representation	Descriptions
Request Placed and Multiple Potential Performers Notified	Request: - Status: active - Intent: order	1..* Bidding Tasks: - Status: requested - Owner: [specified] - Code: request-fulfillment - Intent: bid	Not set	This state can be a starting point for systems where there are multiple potential fulfillers and they bid for the fulfillment.
Potential Fulfiller Awaiting Information	Request: - Status: active - Intent: order	1 Bidding Task: - Status: received - BusinessStatus: Awaiting Information< br>- StatusReason/ReasonReference: [details on the information needed] - Owner: [specified] - Code: request-fulfillment - Intent: bid 0..* Tasks for other potential fulfillers	Not set
Fulfiller Accepted	Request: - Status: active - Intent: order	1..* Bidding Task: - Status: accepted - Owner: [specified] - Code: request-fulfillment - Intent: bid	Not set	A fulfiller has indicated they are willing to perform the service, and perhaps provided a 'bid' with details, such as when they could start
Fulfiller Selected	Request: - Status: active - Intent: order	1 Coordination Task: - Status: accepted - basedOn: [Bidding Task] - Owner: [specified] - Code: request-fulfillment - Intent: order 0..* Bidding Tasks: - Status: cancelled - StatusReason: not selected - Owner: [specified] - Code: fulfill - Intent: bid	Not set	The Placer and Patient have reviewed one or more bids and found one acceptable.

Once the fulfiller has been selected, the workflow continues in a manner similar to the previous example.

Provider Authorization and Patient Selection:

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.

TODO: is this better without the Coordination Task at the Placer? This does make it clear no one else has started.

Workflow State to Represent	Request resource representation	Task resource representation	Event resources representation	Descriptions
Request placed (no designated performer)	Request: - Status: active - Intent: order	Not created or created with Owner not set	Not set	This state can be a starting point for systems where the authorization of a request and the selection of a performer are done at the same time.
Performer selected by patient	Request: - Status: active - Intent: order	Coordination Task: - Status: in-progress - Owner: [specified] - Code: fulfill - Intent: order	Not set