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
12.1 Workflow Description 
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.
12.1.1 Workflow Resource Patterns
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:
12.1.1.1 Workflow 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.
12.1.1.2 Workflow Resource Relationships
These three patterns of resources have a standard set of relationships, both with themselves, as well as with 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.
12.1.1.3 Request Resource Pattern
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.
12.1.1.4 Event Resource Pattern
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.
12.1.1.5 Definition Resource Pattern
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.
12.1.2 Workflow Communication Patterns
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.
12.1.2.1 Communication Pattern Overview
The list of patterns discussed here is as follows:
TODO: Insert Jose's decision tree here?
12.1.2.2 Option A: Simple RESTful POST or PUT
12.1.2.2.1 Steps
- The placer makes a RESTful call to create or update a record or a POST to invoke an
operation over HTTP
- 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
12.1.2.2.2 Benefits
- Simplest of all the possible workflow architectures
- Placer knows whether the request was accepted or not and knows when the task has been done
12.1.2.2.3 Limitations
- 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
12.1.2.2.4 Usage Recommendations
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.
12.1.2.3 Option B: Direct POST of request to fulfiller's system
12.1.2.3.1 Steps
- 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.
- The filler synchronously responds with a "201" indicating that that they have received and stored (created) the resource on their system
- 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.
- The placer system synchronously responds with a "201" indicating they've received and store (created) the resource on their system
12.1.2.3.2 Benefits
- Lowest amount of overhead. No need for Task. No need for polling or subscriptions
- Explicit acknowledgement that filler has received the request
12.1.2.3.3 Limitations
- 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"
12.1.2.3.4 Usage Recommendations
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.
12.1.2.4 Option C: POST of request to placer/queue server system, receiver uses polling
12.1.2.4.1 Steps
- 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
- 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.)
- 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.
- 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.)
12.1.2.4.2 Benefits
- 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.
12.1.2.4.3 Limitations
- 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
12.1.2.4.4 Usage Recommendations
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.
12.1.2.5 Option D: POST of request to placer/queue server system, receiver uses subscription
12.1.2.5.1 Steps
- Same as Option C - placer posts to itself or to queue server
- Filler has set up a subscription to requests of interest (same criteria as for B)
- When placer's request is posted, filler receives a notification that a new, relevant request exists and queries to receive it
- Same pattern follows for transmission of response from filler back to placer
12.1.2.5.2 Benefits
- 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
12.1.2.5.3 Limitations
- 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
12.1.2.5.4 Usage Recommendations
Same a Option C, but in an environment where subscription capability does exist.
12.1.2.6 Option E: POST of Task to filler system
12.1.2.6.1 Steps
- Placer POSTs the request to its own system or to a queue server system
- Placer POSTs a Task resource to the filler system, pointing to the request resource and seeking fulfillment
- Fulfiller system queries to retrieve the referenced request
- Fulfiller Updates the Task to indicate acceptance of the task (and possibly interim progress notes)
- Placer either polls the Task to note acceptance and changes or uses a subscription to determine the same
- Fulfiller POSTs an event resource to its own system or to a queue server system
- Fulfiller Updates the Task resource to change its status to completed and to point to the event resource
- Placer system becomes aware of the update via polling or subscription and retrieves the referenced event resource
12.1.2.6.2 Benefits
- 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
12.1.2.6.3 Limitations
12.1.2.6.4 Usage Recommendations
Not clear why would anyone do this . . .
12.1.2.7 Option F: POST of "open" Task to queue server system
12.1.2.7.1 Steps
- Placer POSTs the request to its own system or to a queue server system
- 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)
- Fulfiller system uses either polling or pub/sub to become aware of the existence of the task
- Fulfiller system queries to retrieve the referenced request
- Fulfiller system updates the Task to indicate "ownership" and agreement to fulfill
- Fulfiller may update the Task to indicate interim progress notes
- Placer either polls the Task to note acceptance and changes or uses a subscription to determine the same
- Fulfiller POSTs an event resource to its own system or to a queue server system
- Fulfiller Updates the Task resource to change its status to completed and to point to the event resource
- Placer system becomes aware of the update via polling or subscription and retrieves the referenced event resource
12.1.2.7.2 Benefits
- 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
12.1.2.7.3 Limitations
12.1.2.7.4 Usage Recommendations
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.
12.1.2.8 Option G: POST of "request" resource for filler system, response via Task
12.1.2.8.1 Steps
- 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"
- 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
- Placer system uses either polling or pub/sub to become aware of the existence of the task and fulfillment intent
- Fulfiller may update the Task to indicate interim progress notes
- Placer either polls the Task to note acceptance and changes or uses a subscription to determine the same
- Fulfiller POSTs an event resource to its own system or to a queue server system
- Fulfiller Updates the Task resource to change its status to completed and to point to the event resource
- Placer system becomes aware of the update via polling or subscription
- Placer system retrieves the event
- Placer system marks the request as "complete"
12.1.2.8.2 Benefits
- 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)
12.1.2.8.3 Limitations
- 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
12.1.2.8.4 Usage Recommendations
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
12.1.2.9 Option H: Workflow broker
12.1.2.9.1 Steps
- Placer POSTs the request to its own system or to a queue server system
- 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
- 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)
- If the Task is rejected by one potential recipient, the broker may create a new task to seek fulfillment from others
- Continue as per Option G
12.1.2.9.2 Benefits
- 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)
12.1.2.9.3 Limitations
- Requires a broker to exist
- Broker must know all available fillers and their capabilities to allow appropriate assignment
12.1.2.9.4 Usage Recommendations
Appropriate in environments that have a workflow engine that takes on responsibility for ensuring fulfillment
12.1.2.10 Option I: Messaging request from placer to filler & acknowledgment
12.1.2.10.1 Steps
- 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)
- Filler system sends a response indicating receipt of the message and, optionally an indication of their intention to fulfill the request
- Filler system may send incremental messages to the placer showing progress (e.g. specimen collected, preliminary results, final results)
12.1.2.10.2 Benefits
- 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)
12.1.2.10.3 Limitations
- 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
12.1.2.10.4 Usage Recommendations
Existing messaging infrastructure (e.g. v2 LTP, MLTP, WSI Web Services, Direct, VISA, REST, etc.) and a need to stay consistent with that architecture
12.1.2.11 Option J: Services request from placer to filler & acknowledgment
This scenario needs work - there's not a lot of experience using FHIR services to manage the fulfillment process
12.1.2.11.1 Steps
- Placer may create and store a Request resource on their own system or a queue server.
- 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
- 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
12.1.2.11.2 Benefits
12.1.2.11.3 Limitations
12.1.2.11.4 Usage Recommendations
TBD
12.1.2.12 Additional Scenarios
12.1.2.12.1 Querying the status of a workflow using REST
- 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.
- System returns a query response showing all related tasks (typically just one). Task shows current status.
12.1.2.12.2 Querying the status of a workflow using services
- Placer invokes a "what's the status of this order" service, passing the request business identifier or URL of the request
- Services responds with a Task showing the current state of the fulfillment of the request
12.1.2.12.3 Cancellation of a Task using REST - placer owns
- Placer sends an update to the Task setting the status to "cancelled"
- 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
12.1.2.12.4 Cancellation of a Task using REST - filler owns
- 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
- 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
12.1.3 Open Issues
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?
Workflow
|
Propose a change