Clinical Order Workflows
1.0.0-ballot - STU 1 Ballot International flag

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

This table outlines how a Request and its associated resources might 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.

Common workflow states

Workflow State to Represent Request resource representation Task resource representation Event resources representation Descriptions
Request Placed (no designated performer) Request:
- Status: active
- Intent: order
- 0..* SupportingInfo		 Task:
- Status: requested
- Focus: [the Request]
- Performer: [null]
- Code: fulfill
- Intent: order
- 0..* Input		 Not set This state can be a starting point for cases where the patient chooses the performer, cases when someone can claim the task, etc.
Request placed and performer selected Request:
- Status: active
- Intent: order		 Task:
- Status: requested
- Performer: [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.
Request Placed and Multiple Potential Performers Notified Request:
- Status: active
- Intent: order		 1..* Tasks:
- Status: requested
- Performer: [specified]
- Code: request-fulfillment
- Intent: order		 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 for Information Request:
- Status: active
- Intent: order		 1 Task:
- Status: received
- BusinessStatus: Awaiting Information
- StatusReason/ReasonReference: [details on the information needed]
- Performer: [specified]
- Code: fulfill
- Intent: order

0..* Tasks for other potential Fulfillers still seeking fulfillment		 Not set  
Fulfiller Accepted Request:
- Status: active
- Intent: order		 1..* Task:
- Status: accepted
- Performer: [specified]
- Code: request-fulfillment
- Intent: order		 Not set This state may be used where several potential Fulfillers may indicate they can provide service, and the Placer and Patient then choose.
Fulfiller Selected Request:
- Status: active
- Intent: order		 1 Task:
- Status: accepted
- BusinessStatus: selected
- Performer: [specified]
- Code: fulfill
- Intent: order

0..* Task:
- Status: cancelled
- StatusReason: not selected
- Performer: [specified]
- Code: fulfill
- Intent: order		 Not set This state represents the selection of one out of possibly multiple Fulfillers who had bid on the Task.
In Progress Request:
- Status: active
- Intent: order		 Task:
- Status: in-progress
- Performer: [specified]
- Code: fulfill
- Intent: order		 Not set  
Partial fulfillment Request:
- Status: active
- Intent: order		 Task:
- Status: in-progress
- BusinessStatus: [images available, end exam, awaiting interpretation, etc.]
- Code: fulfill
- Intent: order
- 0..* Output (depending on whether there is shareable output)		 Awaiting Interpretation / Draft "Partial fulfillment" means some but not all outcomes are available; in some cases, there are no outcomes; in other cases, there may be outcomes that are still ''draft''; in third cases, there may be some outcomes but not all, and some more outcomes are expected before advancing the workflow.
Even then, these available outcomes may not be expected to be shared until a later point in the workflow execution. One example is a diagnostic study that is awaiting interpretation.
Preliminary fulfillment Request:
- Status: active
- Intent: order		 Task:
- Status: in-progress
- BusinessStatus: Preliminary
- Code: fulfill
- Intent: order
- 1..* Output		 Preliminary  
Complete Request:
- Status: completed
- Intent: order		 Task:
- Status: completed
- Performer: [specified]
- Code: fulfill
- Intent: order
- 0..* Output (DiagnosticReport, Observations, DocumentReference, CarePlan, etc.)		 Complete (if service has an output)