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

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.

request-simplest.png

Task at Fulfiller
Task at Fulfiller
PlacerPlacerFulfillerFulfillerCreate RequestAssume endpoints, client registration, business rules, etc.are communicated beforehand and that subscriptions already initiated1Create local representation, ServiceRequest2POST Task to Fulfiller with ServiceRequest in Task.basedOn3Create Local RepresentationBased on business agreements, no confirmation needed of the HTTP status code.The Placer may assume the Fulfiller accepts the request.If Generating Output4Create Output Document (of someform, if needed) and host on FHIR server5Update Task.Outputif using Subscriptions:6send SubscriptionStatusNotification for Task updateNote - implementers should be mindful of performance considerations to pollingif not using Subscriptions:7Poll Fulfiller periodically to see if Service complete8Respond with Info9Create local-representation as needed

Example using Task at Placer with Subscriptions

Task at Placer with Subscriptions
PlacerPlacerFulfillerFulfillerCreate RequestAssume endpoints, client registration, business rules, etc.are communicated beforehand1Create local representation, ServiceRequest, Taskon Placer's FHIR server2SubscriptionStatus Notification bundle with Task in notificationEvent.focus3Create Local RepresentationBased on business agreements, no confirmation needed outside of the message ack.The Placer may assume the Fulfiller accepts the request.If Generating Output4Create Output Document (of someform, if needed) and host on FHIR server5Update Task.Output with a pointer to the output document on the Fulfiller's server6Create local-representation as needed

Example using Messaging (Relying on Identifiers)

Messaging
PlacerPlacerFulfillerFulfillerCreate RequestAssume endpoints, client registration, business rules, etc. are already communicated1Create local representation2POST Message bundle to Fulfiller $process-message endpointwith MessageHeader.focus as a Task and Task.focus as a ServiceRequest3Create Local RepresentationBased on business agreements, no confirmation needed beyond the HTTP status code.The Placer may assume the Fulfiller accepts the request.If Generating Output4Create Output (if needed) and internal representation5send Message with Task in focus and Task.output as output6Create local-representation as needed

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.

request-accept.png

Task at Fulfiller
PlacerPlacerFulfillerFulfillerCreate RequestAssume endpoints, client registration, business rules, etc.are communicated beforehand and that subscriptions already initiated1Create local representation, ServiceRequest2POST Task to Fulfiller with ServiceRequest in Task.basedOn3Create Local Representation4Request additional information necessary for determinationif business agreement allows Fulfiller to accept:6Update Task status7SubscriptionStatus notification to Placer with updated Taskif placer needs to review proposal:9prepare proposal10SubscriptionStatus notification with updated Task11review proposal12POST Update to Task indicating acceptance13proceed to perform service

Task at Placer with Subscriptions
PlacerPlacerFulfillerFulfillerCreate RequestAssume endpoints, client registration, business rules, etc.are communicated beforehand1Create local representation, ServiceRequest, Taskon Placer's FHIR server2SubscriptionStatus Notification bundle with Task in notificationEvent.focus3Create Local Representation4Query for any additional information needed to make determinationif business agreement allows Fulfiller to accept:5Update Task.status to indicate acceptanceif placer needs to review proposal:6Update Task with business status for proposal and Task.input7Review proposal8Update Task.status9Send SubscriptionStatus notification bundle with Task in focus and status updated10proceed to perform service

Example using Messaging (Relying on Identifiers)

Messaging
PlacerPlacerFulfillerFulfillerCreate RequestAssume endpoints, client registration, business rules, etc. are already communicated1Create local representation2POST Message bundle to Fulfiller $process-message endpointwith MessageHeader.focus as Task and Task.focus as ServiceRequest3Create Local Representation4send message acknowledging message5review requestif more information needed:6request information out-of band7send Message with Task in focus, same identifier, andnew info in ServiceRequest.supportingInfo8send Message with Task in focus, same identifier, and updated status9proceed with service

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.
request-patient.png

Example with Subscriptions with Task at Fulfiller
Subscriptions - Task at Fulfiller
PlacerPlacerPatientPatientFulfillerFulfillerAssume client registration has taken place already, endpoints are known, etc.Create Request1Create local representation, ServiceRequest2Make ServiceRequest available to patient(paper req, QR code, patient portal, etc.)3Patient may shop around. Finds fulfiller4Create Local Representation5Queries Placer for details of request for serviceNote - this may be a scenario where an authorization_base is used. See Core Concepts6update representation7Create Task8send SubscriptionStatus notification to Placer to inform of Taskwith .basedOn as ServiceRequest9proceed to perform service

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.

request-claim.png

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
PlacerPlacerFulfiller_AFulfiller_AFulfiller_BFulfiller_BCreate RequestAssume endpoints, client registration, business rules, etc.are communicated beforehand1Create local representation, ServiceRequest, Taskper Fulfiller2SubscriptionStatus notification with TaskAin notificationEvent.focus3Create Local Representation4SubscriptionStatus notification with TaskBin notificationEvent.focus5Create Local Representation6Query for any additional information needed to make determination7Update Task.status to indicate acceptance8Update status of TaskB9SubscriptionStatus notification on Task status change10proceed to perform service

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.

request-bid.png

Subscriptions - Task at Placer
PlacerPlacerFulfiller_AFulfiller_AFulfiller_BFulfiller_BCreate RequestAssume endpoints, client registration, business rules, etc.are communicated beforehand1Create local representation, ServiceRequest, Taskper Fulfiller2SubscriptionStatus notification with TaskAin notificationEvent.focus3Create Local Representation4SubscriptionStatus notification with TaskBin notificationEvent.focus5Create Local Representation6Query for any additional information needed to make determination7Update Task with business status for proposal and Task.input8Review proposalPlacer -> Placer: Update TaskA.status9Send SubscriptionStatus notification bundle with Task in focus and status updated10Update status of TaskB11SubscriptionStatus notification on Task status change12proceed to perform service

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
request-central.png

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
PlacerPlacerCoordinatorCoordinatorFulfiller_AFulfiller_AFulfiller_BFulfiller_BAssume client registration has taken place already, endpoints are known, subscriptions created (subscribing Placer to the Coordinator), etc.Create Request1Create local representation, ServiceRequest2POST Task (A)3Create Internal Representation,checklist of potential fulfillers for service4POST Task (B) with rewritten URIs from Task (A)Note: it is not required that the communication between the Coordinatorand the Fullfillers be the same mechanism as that between the Placer and Coordinator5POST Task (C) with rewritten URIs from Task (A)6Process requst, create internal representation.if additional information needed:7Finds that additional information is needed8Query for supporting information9Rewrite query10Query for additional information:11Supply info12rewrite responses13Supply info (before timeout)14evaluate request. Update Task (B) with status15SubscriptionStatus notification on Task (B)16Update Task(A)17SubscriptionStatus notification indicating anupdate to their original Task (bid received or confirmed performer)if placer must accept proposal:18review proposal19POST update to shared tracking Task A with updated status20POST update to shared tracking Task B with updated status21POST update request is closed22Proceed to perform service

Initial Request to Triage With Later Direct Communication
PlacerPlacerCoordinatorCoordinatorFulfiller_AFulfiller_AFulfiller_BFulfiller_BAssume client registration has taken place already, endpoints are known, subscriptions created (subscribing Placer to the Coordinator), etc.Create Request1Create local representation, ServiceRequest2POST Task (A)3Create Internal Representation,checklist of potential fulfillers for service4Determine by some criteria anintended performer (availability, etc.)5Inform Placer of potential performersDetails are left for later guides. This may be Task.output referencing PractitionerRole resources, Organizations, ActivityDefinitions, etc.6Lookup endpoint for Fulfiller fromearlier coordination or Coordinator response7Authenticate8POST Task (B)9Lookup endpoint for Fulfiller from earlier coordination10Authenticate based on earlier Client Registration11POST Task (C)From here, equivalent to the multiple potential performers flowif additional information needed:12Request additional information13supply requested information14Evaluate request15Update Task(B) with intent to perform16SubscriptionStatus notification on Task(B)if Placer must approve:17Review18POST Task Update19Update Task (C) that request closed20Proceed to perform service