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

This page is part of the Clinical Order Workflows (v1.0.0-ballot: STU 1 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. No current official version has been published yet. For a full list of available versions, see the Directory of published versions

Workflow State Overview

Page standards status: Informative

This table outlines 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.

Note to balloters: Throughout this implementation guide there are references to a "performer of a Task". In FHIR R4, the Task resource only has an owner element, however FHIR R5 has also added a performer element. HL7 invites balloters to provide input on whether the owner element is sufficient to represent the performer concept, or if they may be different in some use cases.

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		 Awaiting Interpretation  
Partial fulfillment Request:
- Status: active
- Intent: order		 Task:
- Status: in-progress
- BusinessStatus: [images available, end exam, awaiting interpretation, etc.]
- Code: fulfill
- Intent: order
- 1..* Output		 Draft  
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)