STU3 Candidate

This page is part of the FHIR Specification (v1.8.0: STU 3 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3

FHIR Infrastructure Work GroupMaturity Level: N/ABallot Status: STU 3

Workflow is an essential part of healthcare - orders, care protocols, referrals are the drivers of most activity within in-patient settings and a great deal of activity in community care as well. FHIR is concerned with workflow when there's a need to share information about workflow state or relationships, when there's a need to coordinate or drive the execution of workflow across systems and when there's a need to define allowed actions, dependencies and conditions on behavior.

Workflow state & relationships

FHIR does not need to be used for the execution of workflow. Orders, care plans, lab results, hospital admissions, claim payments and other records can all be shared using FHIR without the process to actually solicit fulfillment of those orders or requesting payment of those claims being driven by a FHIR transaction. Interoperable support for workflow execution is actually a more advanced FHIR activity because it requires a higher degree of standardization. Rather than merely standardizing the data to exchange, interoperable workflow execution requires standardization of the processes, roles and activities of the different systems. However, even without using FHIR for workflow execution, there's still a need to standardize the data elements related to workflow: how does an event or a result point to the order that authorized it? How do parent steps and child steps get linked together? How does a care plan identify what protocol it's adhering to?

FHIR defines three categories of resources that are involved in activities - requests, events and definitions. Each of these different types has a "pattern" associated with it.  Resources that fall into that type are encouraged to adhere to their respective pattern. These patterns provide standard elements that are typical for most resources of each type. Strict adherence is not required as work groups are expected to align with typical domain behavior and requirements as more authoritative than "desired" architectural patterns. In some cases, capabilities might be supported with extensions rather than core elements where a pattern capability is deemed to be "not common, but still relevant" for a given resource.

A full description of the patterns and their interrelationships can be found in the Workflow Resource Patterns section of this page.

Workflow execution

In addition to defining patterns for resources used in workflow processes, FHIR supports the execution of those processes as well. However, FHIR does not define a "one size fits all" solution for workflow architecture. FHIR supports a variety of interoperability paradigms and most of them (REST, Messaging and Services) provide support for driving workflow execution. (The Document paradigm does not directly support driving behavior, though it can be combined with one of the other patterns to do so.) In addition, several of these paradigms allow multiple approaches to supporting workflow, depending on the context and needs of the workflow process.

The Workflow Communication Patterns section of this page describes a number of options for workflow execution, summarizes their respective pros and cons and makes recommendations for the circumstances in which they might best be used.

Workflow definition

The definition of protocols, order sets, guidelines and other structures that define what sorts of activities should occur, what order they should occur on, what dependencies they have, in what circumstances they should start or end, etc. is handled by a pair of resources:

  • PlanDefinition defines the interrelationships of steps and the rules around their execution
  • ActivityDefinition defines an activity to be performed as a single step

The use of these two artifacts is documented TODO.

Not all resources in FHIR are related to workflow - many are used to describe entities and roles (patients, medications, etc.) or infrastructure (structure definitions, value sets, etc.). However, a large proportion of the FHIR resources are devoted to the description of activities in one fashion or another and almost all of these fall into the realm of workflow - they describe things that can be done (definitions), are desired to be done (requests) or that have been done (events). The table below summarizes the list of workflow-relevant resources:

Requests Resources that ask for or express a desire/intention for something to be done
Events Resources that express that something has been done and which can potentially be done as a result of a request
Definitions Resources that define something that can potentially happen in a patient and time-independent manner
* The Appointment and AppointmentResponse resources do not follow the same sort of request/response pattern as the other resources. Their design is based on iCal conventions, so their model won't reflect the same alignment as most other resources. They are included here for completeness.
ProcessRequest and ProcessResponse are candidates for retirement with their function subsumed by Task
The Task resource takes on characteristics of both "requests" and "events" and thus shares characteristics from both patterns

Note that requests, events and definitions don't exist in a 1:1:1 relationship. Some requests and events have obvious pairings. For example, a SupplyRequest will generally always pair with a SupplyDelivery. The same goes for EnrollmentRequest/EnrollmentResponse, etc. On the other hand, for other resources there isn't a strict pairing. A ReferralRequest might be responded to by an Encounter, DiagnosticReport, Procedure, RiskAssessment, etc. Similarly, a Procedure might be triggered by a DiagnosticRequest, ProcedureRequest, or ReferralRequest. The set of common linkages should be asserted in their respective resources. The specific types of responses for a given request will be governed by the Request.code, any workflow definitions/protocols referenced and local convention.

These three patterns of resources have a standard set of relationships, both with themselves, as well as with each other.

Workflow relationships diagram showing Request, Event and Definition and their relationships to themselves and each other

Specifically:

  • both requests and events can point to their respective definitions
  • events and requests can point to the proposals, plans or orders they are based on
  • events and definitions can be organized into parent-child relationships of parents and components
  • definitions and requests can both replace prior versions of the same type of artifact

This list of relationships is not exhaustive, but covers those that are "standardized" as part of the patterns. Further description and guidance on these relationships can be found in the Request, Event and Definition logical models.

Requests are resources that represent the proposal, plan or order for an activity to occur. A Request pattern defines the common elements typically present on all request resources.

The amount of information needed for a Request to be actionable can vary by circumstance. Some request instances may not be "fully specified" - additional information from protocol, patient preference and/or professional decision-making may be necessary before the authorized action can occur. For example, a MedicationOrder might be specified without indicating a strength or route in situations where the pharmacy (or even nursing information) has the authority to determine those parameters. A VisionPrescription might not be actionable until frames have been chosen and the necessary measurements of the patient's face have been taken to allow the lenses to be positioned appropriately within the frames.

All requests with an intent of "order" authorize something. Whether what is authorized is sufficient to be immediately actionable depends on who is fulfilling the order and the context in which the fulfillment request is made. The determination of whether a given "request" is actionable may be made by the systems involved or the humans being asked to act.

As well, the existence of a "Request" instance doesn't necessarily imply that fufillment will be requested immediately - or even ever. The decision to request fulfillment may be delegated to the patient or to down-stream practitioners. Such fufilling practitioners may need to capture additional information prior to executing the fufillment.

Events are resources that represent the ongoing or completed execution of some activity or observation. For example, a clinical procedure, a financial transaction, the recording of a diagnosis, etc. An Event pattern defines the common elements typically present on all event resources.

Definitions are resources that represent activities that could be performed in a time and subject-independent manner such as a protocol, order set, clinical guideline, etc. A Definition pattern defines the common elements typically present on all event resources.

Workflow execution is supported in FHIR by a large number of mechanisms. In considering how best to interoperate around workflow, there are a number of considerations:

  • Which paradigm do you want to use (REST, messaging or services)?
  • Is there infrastructure in place to support polling, push notifications via subscriptions or both?
  • Is there a need for confirmation that the desired performer agrees to act, or can that be presumed?
  • Is there a need to negotiate whether/how the requested action will be performed?
  • Can the requesting and performing system communicate directly? Are they able to post to each other's servers (if using REST)?
  • Is there an ability/need to have a queue server to facilitate workflow execution?
  • How many potential actors are involved?
  • Will the workflow always be directed or is there a pool of potential performers who could choose to perform the requested action?

This section highlights some of the more common patterns and identifies their characteristics and limitations and provides recommendations on when each approach may be most useful or relevant. Please note that this list of patterns is not exhaustive. Patterns can be combined in various ways and there are likely some possibilities we haven't thought about yet (feel free to submit additional patterns using the 'submit a change' link at the bottom of the page). As well, the recommendations given here are just that - recommendations. Implementers are free to choose which patterns they wish to support. Because of this, tight interoperability around workflow execution (as with any other tight interoperability using FHIR) will depend on communicating participants doing some up-front negotiation around how they plan to support workflow execution or all communicating partners will need to adhere to an implementation guide that sets out clear interoperability expectations.

Prior to reviewing this list of options, readers are encouraged to be familiar with the following pages and resources: REST, messaging, operations, services and the Subscription resource.

The scenarios below make use of a few conventions:

  • The focus here is on a "request" and the actioning of that request. Almost all workflows can be broken down to a sequence of these steps, though the responsibilities of the different parties may shift for each interaction and there can be more than two parties involved in the overall workflow
  • The request could be as simple as "please look at this information" and the response could be as simple as an implicit "it's been looked at" or the request could be for some more involve action that may involve reporting back multiple interim and final steps
  • The requester is referred to as the "placer" and the performer is referred to as the "filler", which are often seen as order-specific terms. However, in this context, the terms hold whether the request is expressed as a proposal, plan or full-blown order
  • Each of the patterns defines the set of steps involved in processing the request, lists some of the benefits and limitations associated with the approach and then makes recommendations about when the pattern is most appropriate
  • The descriptions of these patterns focuses on the notion of requesting fulfillment of a request. However most of these patterns are also applicable to requests for status change, requests for information, etc. If a pattern is limited in the types of execution it can trigger, this will be noted in the "limitations" section.

The list of patterns discussed here is as follows:

Option A: Simple RESTful POST or PUT
Option B: Direct POST of request to fulfiller's system
Option C: POST of request to placer/queue server system, receiver uses polling
Option D: POST of request to placer/queue server system, receiver uses subscription
Option E: POST of Task to filler system
Option F: POST of "open" Task to queue server system
Option G: POST of "request" resource for filler system, response via Task
Option H: Workflow broker
Option I: Messaging request from placer to filler & acknowledgment
Option J: Services request from placer to filler & acknowledgment
Additional Scenarios

TODO: Insert Jose's decision tree here?

  1. The placer makes a RESTful call to create or update a record or a POST to invoke an operation over HTTP
  2. The receiver responds with a 2xx HTTP response indicating whether the request was successfully processed or not and, if appropriate, provides the response to the request in the payload of the HTTP response
  • Simplest of all the possible workflow architectures
  • Placer knows whether the request was accepted or not and knows when the task has been done
  • Only works for automated execution where the decision to perform the request and the execution of the request can be done synchronously within the HTTP timeout period (generally on the order of 10s of seconds).
  • Requires that the placer have authority to post directly to the placer's system
  • Requires that the "request" be expressible as a simple creation, update or operation invocation
  • Only works for "fulfillment" requests for Request resources - can't handle request for state changes or information

This is by far the most common pattern in FHIR for simple changes as it requires the least overhead. However, if human processing is involved in the request execution, then this approach won't suffice. This approach is listed here to make sure that implementers consider whether they can make this one work first before falling back to one of the more sophisticated patterns.

Diagram showing direct POST of request to fulfiller's system workflow
  1. Placer system invokes a create by POSTing a 'request' resource (e.g. MedicationRequest, DiagnosticRequest, ReferralRequest, etc.) to the appropriate RESTful resource endpoint (e.g. [base]/MedicationRequest) on the filler system and places an actionable tag on the resource that indicates the request is intended to be acted upon, not merely stored.
  2. The filler synchronously responds with a "201" indicating that that they have received and stored (created) the resource on their system
  3. At some later point, the filler POSTs an 'event' resource (e.g. MedicationDispense, DiagosticReport, Encounter, etc.) to the appropriate resource endpoint on the placer system, including a basedOn link to the 'request' resource that the action was performed in fulfillment of.
  4. The placer system synchronously responds with a "201" indicating they've received and store (created) the resource on their system
  • Lowest amount of overhead. No need for Task. No need for polling or subscriptions
  • Explicit acknowledgement that filler has received the request
  • Can only use when requesting fulfillment (can't use to request status change or other updates)
  • Placer and filler must be able to communicate directly (i.e. know each other's respective endpoints) and must each have a FHIR server and must have "write" permissions to each other's servers. This could become unmanageable if there are a large (or dynamic) number of placers and fillers that need to communicate
  • No indication of agreement to act on the request
  • There's no ability to negotiate fulfillment - no ability to say "no"

Use this approach when there's no ability to have queue servers and no support/need for complexity of Task, polling or pub/sub (and no need for negotiation or the ability for the filler to say "no"). This is a pseudo-messaging architecture that doesn't actually use messaging architecture.

Diagram showing POST of request to placer/queue server system, receiver uses polling workflow
  1. Placer system invokes a "create" action by POSTing a 'request' resource (e.g. MedicationRequest, DiagnosticOrder, ReferralRequest, etc.) to the appropriate RESTful resource endpoint (e.g. [base]/MedicationRequest) on either its own system or a third party queue server system and sets a "flag" on the resource that indicates the request is "actionable". The request explicitly identifies the intended fullfiller
  2. The filler system, at some agreed frequency, RESTfully queries the placer or queue server system to see if there are any "new" requests that: are tagged as "actionable", have the filler identified as the intended performer, and are a type of request "of interest" to the filler. (The queries could be initiated by the filler system automatically in the background or upon triggering by user of the filler system.)
  3. At some later point, the filler POSTs an 'event' resource (e.g. MedicationDispense, DiagosticReport, Encounter, etc.) to the appropriate resource endpoint on either its own system, the same queue server as the request was placed on or some alternate queue server, including a link to the 'request' resource that the action was performed in fulfillment of.
  4. The placer system, at some agreed frequency, RESTfully queries the filler or queue server system to see if there are any "new" events that are tied to any outstanding orders the placer has initiated. (The queries could be initiated by the placer system automatically in the background or upon triggering by user of the placer system.)
  • Placer & Server don't have to communicate directly (can act through queue server). This can reduce the number of point-to-point interfaces that need to be supported.
  • No need for Task.
  • Can only use when requesting fulfillment (can't use to request status change or other updates)
  • Placer and filler must regularly poll to see if there's anything new. (Can represent significant communication overhead)
  • Polling by the placer for "anything related to these 500 open orders" could be onerous, especially if some orders never get closed.
  • Placer and fulfiller must know where to poll for content - this could be a large number of systems
  • No indication of agreement to act on the request
  • There's no ability to negotiate fulfillment - no ability to say "no"
  • Placer may not know when (or if) filler system has retrieved the request

Use this when there's no ability to have queue servers and no support/need for complexity of Task and where no Subscription infrastructure exists. This is a more typically RESTful approach where data resides on the server "owned" by the data creator and is accessed by other systems.

Diagram showing POST of request to placer/queue server system, receiver uses subscription workflow
  1. Same as Option C - placer posts to itself or to queue server
  2. Filler has set up a subscription to requests of interest (same criteria as for B)
  3. When placer's request is posted, filler receives a notification that a new, relevant request exists and queries to receive it
  4. Same pattern follows for transmission of response from filler back to placer
  • Placer & Server don't have to communicate directly (can act through queue server). This can reduce the number of point-to-point interfaces that need to be supported.
  • No need for Task
  • Lower communication overhead than polling
  • Can only use when requesting fulfillment (can't use to request status change or other updates)
  • Additional complexity of setting up and maintaining a subscription infrastructure
  • Placer and fulfiller must know where to subscribe for content - this could be a large number of systems
  • No indication of agreement to act on the request
  • There's no ability to negotiate fulfillment - no ability to say "no"
  • Placer may not know when (or if) filler system has retrieved the request

Same a Option C, but in an environment where subscription capability does exist.

Diagram showing POST of Task to filler system workflow
  1. Placer POSTs the request to its own system or to a queue server system
  2. Placer POSTs a Task resource to the filler system, pointing to the request resource and seeking fulfillment
  3. Fulfiller system queries to retrieve the referenced request
  4. Fulfiller Updates the Task to indicate acceptance of the task (and possibly interim progress notes)
  5. Placer either polls the Task to note acceptance and changes or uses a subscription to determine the same
  6. Fulfiller POSTs an event resource to its own system or to a queue server system
  7. Fulfiller Updates the Task resource to change its status to completed and to point to the event resource
  8. Placer system becomes aware of the update via polling or subscription and retrieves the referenced event resource
  • Can use this approach for request other than just when requesting fulfillment (e.g. to request status change or other updates)
  • There's an ability to negotiate fulfillment - i.e. the ability to say "no"
  • Explicit acknowledgement that filler has received and agreed to act on the request
  • Additional complexity of setting up and maintaining a subscription or polling infrastructure
  • Additional complexity of using Task
  • Placer and filler may need to be able to communicate directly (i.e. know each other's respective endpoints) and have a FHIR server and must have "write" permissions to each other's servers

    • This could become unmanageable if there are a large (or dynamic) number of placers and fillers that need to communicate
    • May not apply if there's a queue server
  • Placer and fulfiller must know where to subscribe for content - this could be a large number of systems
  • Placer may not know when (or if) filler system has retrieved the request

Not clear why would anyone do this . . .

Diagram showing POST of "open" Task to queue server system workflow
  1. Placer POSTs the request to its own system or to a queue server system
  2. Placer POSTs a Task resource to its own system or a queue server system, pointing to the request resource and seeking fulfillment.
    Task does not have a specified "performer" (but may have performer type)
  3. Fulfiller system uses either polling or pub/sub to become aware of the existence of the task
  4. Fulfiller system queries to retrieve the referenced request
  5. Fulfiller system updates the Task to indicate "ownership" and agreement to fulfill
  6. Fulfiller may update the Task to indicate interim progress notes
  7. Placer either polls the Task to note acceptance and changes or uses a subscription to determine the same
  8. Fulfiller POSTs an event resource to its own system or to a queue server system
  9. Fulfiller Updates the Task resource to change its status to completed and to point to the event resource
  10. Placer system becomes aware of the update via polling or subscription and retrieves the referenced event resource
  • No need for placer and fulfiller system to talk to each other directly
  • Can use this approach for request other than just when requesting fulfillment (e.g. to request status change or other updates)
  • There's an ability to negotiate fulfillment - i.e. the ability to say "no"
  • Explicit acknowledgement that filler has received and agreed to act on the request
  • Additional complexity of setting up and maintaining a subscription or polling infrastructure
  • Additional complexity of using Task
  • Placer and filler may need to be able to communicate directly (i.e. know each other's respective endpoints) and have a FHIR server and must have "write" permissions to each other's servers

    • This could become unmanageable if there are a large (or dynamic) number of placers and fillers that need to communicate
    • May not apply if there's a queue server
  • Placer and fulfiller must know where to subscribe for content - this could be a large number of systems
  • Placer may not know when (or if) filler system has retrieved the request

Used when requests are not (always) directed to a specific filler and where fillers may respond to tasks from multiple placers. This creates a sort of "market" where fillers choose what to take on and negotiate what work they perform.

Diagram showing POST of "request" resource for filler system, response via Task workflow
  1. Placer system invokes a "create" action by POSTing a 'request' resource (e.g. MedicationRequest, DiagnosticOrder, ReferralRequest, etc.) to the appropriate RESTful resource endpoint (e.g. [base]/MedicationRequest) on the filler, placer or queue server system and sets a "tag" on the resource that indicates the request is "actionable"
  2. Filler POSTs a Task resource to its own system or a queue server system, pointing to the request resource and indicating intent to fulfill or refusal to fulfill
  3. Placer system uses either polling or pub/sub to become aware of the existence of the task and fulfillment intent
  4. Fulfiller may update the Task to indicate interim progress notes
  5. Placer either polls the Task to note acceptance and changes or uses a subscription to determine the same
  6. Fulfiller POSTs an event resource to its own system or to a queue server system
  7. Fulfiller Updates the Task resource to change its status to completed and to point to the event resource
  8. Placer system becomes aware of the update via polling or subscription
  9. Placer system retrieves the event
  10. Placer system marks the request as "complete"
  • There's an ability to negotiate fulfillment - i.e. the ability to say "no"
  • Explicit acknowledgement that filler has received and agreed to act on the request (though no need for the placer to check)
  • Can only use when requesting fulfillment (can't use to request status change or other updates)
  • Additional complexity of setting up and maintaining a subscription or polling infrastructure
  • Additional complexity of using Task
  • Placer and filler may need to be able to communicate directly (i.e. know each other's respective endpoints) and have a FHIR server and have "write" permissions to each other's servers (if no queue server is used)
  • Placer and fulfiller must know where to subscribe for content - this could be a large number of systems

Use this when the filler needs to have complete ownership over the task and there's no ability for both placer & filler to manipulate tasks on a common server

Diagram showing workflow broker workflow
  1. Placer POSTs the request to its own system or to a queue server system
  2. Broker detects that new un-assigned request (without a Task yet created and falling within the scope of the Broker to ensure fulfillment) via polling or subscription
  3. Broker POSTs a Task resource to its own system or a queue server system, pointing to the request resource and seeking fulfillment from a specific filler
    Task does not have a specified "performer" (but may have performer type)
  4. If the Task is rejected by one potential recipient, the broker may create a new task to seek fulfillment from others
  5. Continue as per Option G
  • Offloads responsibility for seeking fulfillment from the placer system, but more actively solicits fulfillment than a simple "post the task and see who takes it". Also allows prioritized assignment of tasks (i.e. some fillers may be preferred over others)
  • Requires a broker to exist
  • Broker must know all available fillers and their capabilities to allow appropriate assignment

Appropriate in environments that have a workflow engine that takes on responsibility for ensuring fulfillment

  1. Placer sends message to filler system including Request resource (and other relevant resources) along with a MessageHeader with an "event" code saying "please fulfill" and "data" element pointing to the Request resource as the item to fulfill. Message could potentially use Task instead of MessageHeader.event to convey desired action (ongoing discussion)
  2. Filler system sends a response indicating receipt of the message and, optionally an indication of their intention to fulfill the request
  3. Filler system may send incremental messages to the placer showing progress (e.g. specimen collected, preliminary results, final results)
  • Reduced number of communications
  • All relevant data sent in one package
  • Responses can be asynchronous and content may routed
  • There's an ability to negotiate fulfillment - i.e. the ability to say "no"
  • Can request things other than just fulfillment (e.g. please suspend)
  • Explicit acknowledgement that filler has received and agreed to act on the request (though no need for the placer to check)
  • Messaging is "heavy"
  • Need to negotiate what allowed responses are and what data can be present in request and response messages
  • Additional complexity of setting up and maintaining a subscription or polling infrastructure
  • Additional complexity of using Task
  • Need message delivery infrastructure in place

Existing messaging infrastructure (e.g. v2 LTP, MLTP, WSI Web Services, Direct, VISA, REST, etc.) and a need to stay consistent with that architecture

This scenario needs work - there's not a lot of experience using FHIR services to manage the fulfillment process

  1. Placer may create and store a Request resource on their own system or a queue server.
  2. Placer invokes a service on the filler system saying "please fulfill this order", including the content or a reference to the request resource and any other relevant data
  3. Filler system responds (synchronously if using HTTP, but may be asynchronous if using SOAP or other transport mechanisms) with conformation of receipt and, optionally indication of intention to fulfill and/or results
  • ???
  • ???

TBD

  1. Placer sends query for Task(s) that have a focus of the request of interest to a system (placer system, queue server or filler) that holds tasks related to their request.
  2. System returns a query response showing all related tasks (typically just one). Task shows current status.
  1. Placer invokes a "what's the status of this order" service, passing the request business identifier or URL of the request
  2. Services responds with a Task showing the current state of the fulfillment of the request
  1. Placer sends an update to the Task setting the status to "cancelled"
  2. Filler receives notification of the update (because the task is on their system or because they poll it or are subscribed to it) and ceases work if they are able
  1. Placer creates a new task requesting cancellation of the original fulfillment task
    Fulfillment of the "cancellation task" can be requested using any of the mechanisms above
  2. Filler decides whether they are able to cancel the task and update the "cancellation" task to indicate either cancellation is complete or has been refused

STU Notes:

  • It is possible to replace some portions of the MessageHeader with a reference to the Task resource. Doing so would mean consistency in how asynchronous requests are represented using REST and messaging. However, it introduces an additional layer of complexity and formality into the messaging paradigm that may be unwelcome, particularly for those systems that do not currently foresee a need to support both RESTful and messaging invocations of workflow
  • The OperationDefinition resource could be used to define types of tasks and the sets of parameters that are allowed to go with them. Is this an appropriate use of the OperationDefinition resource?
  • The SupplyRequest, DeviceUseRequest and VisionPrescription resources have a significant degree of overlap. Should they remain distinct resources?