This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version in it's permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3
FHIR Infrastructure Work Group | Maturity Level: 2 | Standards Status: Trial Use |
As described in previous sections, many FHIR resources can be used within workflows without using FHIR to manage the execution of the workflows. When we want to manage workflow execution with FHIR, there are several mechanisms available. In addition to managing workflow with FHIR, there are also cases where management of workflow execution is not necessary, and supporting workflow becomes simply the use of the resource patterns in an ad-hoc fashion. In deciding how best to interoperate around workflow with FHIR, there are several considerations:
The answers to these (and other) questions will guide the selection of communication patterns to be used for a specific interoperability use case. It is recommended that domain workgroups analyze the support for workflow execution within their domains and provide recommendations for an appropriate subset of patterns, with a discussion on where and how to use them. Implementation guides, by their nature, should prescribe which patterns to use for workflow execution management.
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 Subscriptions.
The scenarios used to illustrate the patterns below make use of a few conventions:
One of the key distinguishing characteristics in the patterns below is whether the pattern supports the tracking of the workflow's state by both the placer and the filler. The workflow state is represented by the Task resource. The Task state machine, which is also presented here, shows the use of Task.status to represent the general infrastructure state of the Task resource.
The combination of Task.status, Task.statusReason and Task.businessStatus provide the mechanism for tracking the workflow state. The following two examples illustrate how that could be accomplished with regards of specific workflows. Note that these examples avoid any specificity on where the described resources exist, or any reference to a specific communication pattern. The goal of the examples is to demonstrate the use of the Task attributes to represent the workflow state.
The following table shows the steps for a simple blood test order, and the corresponding values of the Task attributes. A lot of details on other attributes have been omitted in order to focus on the state changes.
Workflow step | Task.status | Task.statusReason | Task.businessStatus |
---|---|---|---|
Provider orders a blood test for a patient. A ServiceRequest resource is created to represent the order, and a Task resource is created to represent the request to the lab. Task.basedOn points to the ServiceRequest instance. | Requested | New order | Ordered |
The lab accepts the order. | Accepted | Able to perform the test. | Accepted |
The patient is at the lab, and blood is drawn. | In progress | Obtained the specimen | Specimen available |
Work on the blood sample is in progress, preliminary results are available, a DiagnosticReport resource is created, and Task.output.value[1] references the DiagnosticReport resource. | In progress | Preliminary results available | Preliminary results |
Final results are available | Complete | Final results are available | Final results |
The following table shows the steps for a referral workflow, and the corresponding values of the Task attributes. A lot of details on other attributes have been omitted in order to focus on the state changes.
Workflow step | Task.status | Task.statusReason | Task.businessStatus |
---|---|---|---|
Provider A is seeing a patient with a specific complaint. Based on the exam, Provider A refers the patient to a specialist at clinic B. It is an urgent referral, requesting to see the specialist within 4 days. A ServiceRequest resource is created to represent the referral order, and a Task resource is created with Task.priority set to Urgent, and Task.restriction.period.end set to 4 days in the future. | Requested | New referral | Referred |
Clinic B receives the referral and puts it on the urgent queue to be reviewed. | Received | Received by organization | Pending |
Upon reviewing the referral, the clinic determines they have no capacity to see the patient within the specified time period, and they decline the referral. | Rejected | Provider unavailable | Declined |
Provider A changes the referral request to clinic C. This creates a new Task resource, with the appropriate information | Requested | Changed the referred to provider | Referred |
Clinic C accepts the referral and it is placed on a scheduler's queue. | Accepted | Able to provide the service. | Accepted |
An appointment is scheduled for the patient at Clinic C. | In progress | Appointment scheduled | Scheduled |
Soon after the appointment is scheduled, the patient calls provider A to ask for a different location for the referral appointment, as he lost his transportation, and he cannot reach Clinic C. The provider requests a cancel for the referral. | Suspended | Patient unable to make appointment. | Cancel requested |
Clinic C confirms the cancellation of the existing task. |
In progress Failed |
Referral cancelled | Cancelled as requested |
Provider A changes the referral to Clinic D, which is located close to where the patient lives, and can be conveniently reached using public transportation. This creates a new Task resource, with the appropriate information. | Requested | Changed the referred to provider | Referred |
Clinic D accepts the referral and it is placed on a scheduler's queue. | Accepted | Able to provide the service. | Accepted |
An appointment is scheduled for the patient at Clinic D. | In progress | Appointment scheduled | Scheduled |
Patient is seen at Clinic D. A diagnosis is made by the specialist, a prescription is given, and a follow-up appointment is made at clinic D. Task.output.value[1] references a Compositions resource, which contains the encounter summary. | In progress | Intermediary consultation note available | Preliminary notes |
Patient comes for follow-up appointment at clinic D. The specialist is satisfied by the progress the patient has made and creates the final consultation note. Task.output.value[2] references a Compositions resource, which contains consultation note. | Completed | Final consultation note available | Final notes |
The patterns that facilitate the execution of workflow using the Task resource are grouped in the Workflow Management Patterns section. The patterns where no Task resource is used are grouped in the Ad-hoc Workflow Patterns section. The list of patterns is as follows: