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 Patterns

Page standards status: Informative

This page provides an overview of how Requests may be coordinated across actors using a variety of exchange patterns. This is illustrative and meant to convey one end-to-end flow; details are provided elsewhere.

Note to balloters: Throughout this page 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.

The other pages in this section outline considerations for specific parts of a Request's lifecycle in FHIR. These include:

  • Order initiation:
    This section addresses aspects of how orders are created that relate to FHIR workflows. Many details are left to implementers or more specific implementation guides.

  • Order grouping
    How multiple requests for service (or multi-item requests) may be communicated and how dependencies between requests may be communicated and coordinated.

  • Fulfiller determination
    After a request has been created, how a fulfiller for that service is selected. This could be direct assignment by a placer, assignment by a central triage or coordination office, or patient-selection.

  • Requests by a Fulfiller for additional information
    How potential Fulfillers may ask for additional information about a Request, either while determining if they can fulfill the Request or later.

  • Cancelling and modifying orders
    This section describes how Placers and Fulfillers may modify a request once it has been created. This includes:
    • A placer cancelling a request before service has begun
    • A placer requesting that an in-progress request for service be cancelled
    • A fulfiller proposing an alternative service back to the placer
    • A fulfiller electing to perform a more specific service under their own authority
    • A fulfiller informing a placer that they can no longer perform a service
  • Sharing outputs from an order
    How the outputs from a Request, such as a diagnostic result report or a consult note, may be linked back to the original Request and shared between actors. This includes how actors may make the Outputs discoverable for others involved in a patient's care later, even if the later actors can only contact the Placer.

Overview Example - Coordination Task at Fulfiller with Optional Subscriptions

The below is an overview of how a Request may be coordinated with the Coordination Task hosted at the Fulfiller. In this example, the Placer and the Fulfiller have pre-coordinated that the Placer is Subscribed to updates on Tasks that they originate. Note, however, that this is optional for the example: a Placer could query for updates on the Coordination Task at some expected date or ahead of their next visit with the patient.

Many details are deferred for more detailed discussions elsewhere in this guide or for later implementation guides.

Task at Fulfiller OverviewPlacerPlacerFulfillerFulfillerPre-Coordination1Register Fulfiller as a client2Register Placer as a Client3Inform Fulfiller of their channel on which to receive SubscpriptionStauts-notification bundles4Create an administrative subscription for the Placer on Tasks which the Placer creates5Inform Placer on their own channel6Create an administrative subscription for the Fulfiller on ServiceRequests for whichthere is a Task designating the Fulfiller as the intended performer in Task.performerFulfiller can be notified if supporting info is addedOther subscriptions, like for Patient Demographics info, are also possible.Note that the subscription is just an identifier and need not be a surfacable resource.Create Request7Create Order, ServiceRequest8Task.CreateTask.basedOn is the ServiceRequest at the Placer. The Placer may include supporting information inServiceRequest.info or in the Task if Fulfiller-specific9Query ServiceRequest.supportingInfo, ServiceRequest.reason, etc.10Update Task.businessStatus 'requested' => 'accepted'11SubscriptionStatus notification - Task updatedCould also have that the Fulfiller makes a Plan, RequestOrchestration, etc. with Task.outputA Placer could then update the Task to Accepted if they accept the Fulfiller's Proposal.12Update status of tracking if needed, such as ServiceRequest.status.If Fulfiller will perform a more specific service14Create ServiceRequest with ServiceRequest.basedOnreferring to the Placer's ServiceRequestPerform ServiceIf fulfiller creating an output document16Performs Service, creates Output17Updates Task.output == Output18Update Task.businessStatus19SubscriptionStatus Notification for Task updateOptionally, if placer needs to be able to review the output21Reads output via Task.output22Update ServiceRequest.status == CompletedOptionally - if Placer needs to surface that outcome in future24Read Output Document if not received within SubscriptionStatus Notification25Save a copy. If needed, indicate Fulfiller's documentis source of truth via Provenance.location, etc. Note the output may alsodirectly reference the performer.

Overview Example - Subscriptions with Task at Placer

The below is a similar overview in which the Coordination Task is hosted at the Placer. In this example, the Placer and the Fulfiller have pre-coordinated that the Fulfiller is Subscribed to Tasks that the Placer creates for them in which the Fulfiller is the expected Task.performer.

PlacerPlacerFulfillerFulfillerPre-Coordination1Register Fulfiller as a client2Register Placer as a client3inform Placer of the FHIR endpoint on which SubscriptionStatus-notifications should be sent4Create administrative subscription for fulfiller on Tasks where they are Task.performerCreate Request5Create Order, ServiceRequest, Taskper (potential) fulfiller6POST SubscriptionStatus notification bundleSubscriptionStatus.notificationEvent.focus is the Task. The placer may include the ServiceRequest and references from .supportingInfo in.additionalContextTask.basedOn is the ServiceRequest at the Placer.7Query ServiceRequest.supportingInfo, ServiceRequest.reason, etc.8Update Task. businessStatus from 'requested' to 'accepted' (or supply a Plan for Bid flows via Task.input for Placer review)If Placer will review bids10Review. Cancel tasks to other potential fulfillers as needed11Update Task.status, Task.businessStatus, etc.12SubscriptionStatus notificationindicating status isupdated and they 'won' the bidIf Fulfiller will perform a morespecific service14Create ServiceRequest with .basedOnpointing to the Placer's ServiceRequestPerform ServiceIf Fulfiller creating an output document16Performs service, creates Output17Updates Task.Output -> Outcome document on Fulfiller's server18Update Task and ServiceRequest.status -> CompletedInterim statuses may be used if the Placer must decide if the service is completeOptionally, if Placer needs to be able to surfacethat Outcome in future20Read Output Document21Save a copy. If needed, indicate that the Fulfiller's copy is the source of truth via Provenance.location, etc.Note that in many cases, the Event resource itself indicates origin.

Overview Example - Messaging

Equivalent flows can be constructed via FHIR Messaging. The Placer and the Fulfiller pre-coordinate their endpoints and events of interest, just as with Messaging. The key distinction is that (in this example, where we assume no FHIR servers may be queried RESTfully) the notifications must contain the information the Placer anticipates the Fulfiller will need. Just as in HL7 v2 messaging today, actors rely on shared identifiers and reliable messaging to coordinate State.

Referrals Outline - Messaging w/ Placer IdentifiersPlacerPlacerFulfillerFulfillerPre-CoordinationCoordinate business agreementRegister clientRegister clientInitial NotificationPlacer generates Request. Creates internal representation.Authenticates to FulfillerThis may be a flow like OAuth 2.0 client credentialsProvides Access Token scoped to allow messagingSends message with MessageHeader.focus as a Task, and supporting info such as the ServiceRequestCreates their own internal representation.Acknowledges the request.Note - the fulfiller may or may not accept at this stage, and may or maynot send back their own identifier. Can be a comm ack or a decision.If potential fulfiller has further processing to do, like checking availability before acceptingProcesses the RequestRequests additional info necessary for processing. Sends a message with Task.identifierthat identifies this relates to the earlier request, and a businessStatus indicating info needed.May review what else can be sharedSends additional info in a message with Task in focus, Task.identifier indicatingthe relation to the earlier request, and Status of RequestedAccepts the requestIf placer has to accept a 'bid' from the potential fulfillerSend confirmation they should provide the serviceShare UpdatesIf placer has additional info come inSend status updates, additional info, etc.If placer wants status updates and fulfiller can sendSend status updates (scheduled, etc.)Share OutcomeGenerate outcome/result with internal identifierNotify of outcome via a Message with Task in focus, Task.Status updated, and Task.output referencing any outputProcess outcome and create internal representation