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

Work Group FHIR Infrastructure

Ballot Status: n/a

12.0 Workflow Module

The workflow module focuses on the coordination of activities within and across systems. This includes three primary aspects:

• How do we ask for another person, device or system to do something?
• How do we track the linkages and dependencies between activities - actions to their authorizations, complex activities to individual steps, protocols to plans to orders, etc.?
• How do we define what activities are possible and the expected order and dependencies of the steps within those activities? I.e. process/orchestration definition

In addition, this module supports resources to support two specific workflows - the requesting and delivery of supplies and the requesting and delivery of information.

12.0.1 Introduction

Workflows can be performed using the Task resource, messaging or services. This specification includes a workflow page that describes a number of different communication and architectural workflow patterns.

This specification defines three logical models - Definition, Request and Event that define the patterns for resources that are typically involved in workflow. These patterns include elements defining relationships between requests, between events across requests and events. These relationships are summarized on the workflow page, along with a complete list of resources that follow (or are hoped to soon follow) the request and event patterns.

Finally the PlanDefinition and ActivityDefinition resources combine to support the creation of protocols, orders sets, guidelines and other workflow definitions.

12.0.2 Common use Cases

Workflow manifests in many places in the healthcare environment:

• Creating a lab order, drug prescription, referral or other order clinical order or a insurance claim, EnrollmentRequest or similar administrative request and asking for it to be actioned by a specific organization or practitioner
• Negotiating a fulfillment process, such as requesting further information before accepting a claim or referral or proposing an alternative therapy when processing an order
• Letting an ordering physician know what the current progress is in fulfilling an order (e.g. Blood has been drawn, sample is being processed, preliminary results are in, etc.)
• Defining a plan or recommendation for a set of clinical and/or administrative activities to manage a patient's care and then tracking how those plans and recommendations are (or are not) acted upon over time.
• Communicating a state change to a request or order (e.g. suspension, update, cancellation, etc.) to a filling system so that they can take appropriate action
• Asking for a state change, merge of a couple of patients or the invoking of some operation or decision supporting an asynchronous manner - for example, one where human intervention is required
• Designing or adhering to a study protocol, chemotherapy protocol, instantiating an order set or other plan definition

FHIR provides multiple ways to enable all of these scenarios (and many others). Common mechanisms, along with their pros and cons can be found in the workflow section on patterns.

12.0.3 Security and Privacy

Resources related to workflow need to adhere to the same security and privacy guidelines that apply to all FHIR resource, including specific considerations for those that may contain personally-identifying information. There are a couple of additional security and privacy considerations specific to workflow:

1. Some workflows are ad-hoc without pre-defined participants or flows. These can be challenging for security and privacy processes to manage appropriately

2. Workflow can drive automated behavior. I.e. The mere existence of an electronic record can cause information to flow, procedures to be performed, records to be changed and money to be transferred, potentially without any intervention, oversight or sanity checking by a human being. As such, even greater care must be taken to ensure that:

• constraints are placed on what systems (and users) can initiate workflow processes
• requests for action are appropriately authenticated before action is taken
• patient consents and other relevant policies are enforced either by the system storing the request or the system acting upon it (and that if enforcement is not performed by the actor, that they are confident that relevant policies have been enforced on the request prior to action)

For more general considerations, see the Security and Privacy module.

12.0.4 Developmental Roadmap

The principles of requesting action and reporting results have been present in FHIR since its initial version. However, significant work has happened (or is planned) as part of this STU 3 release to increase the consistency of resources involved in workflow and to improve the documentation expressing the different ways workflow can be managed depending on architectural and other constraints. This has included the introduction of the Task resource (which replaced the old Order and OrderResponse resources), the definition of the Request and Event patterns and the creation of the PlanDefinition and ActivityDefinition resources. Some of this work has had preliminary testing at connectathon but has had little production experience as yet. Most of the discussion has been on how workflow is best managed from a RESTful paradigm perspective.

Looking forward to the next release, we'll be seeking and incorporating feedback from the implementer community about both the workflow resources as well as the patterns and architectural approaches documented in this specification. We'll also be increasing focus on the messaging and services paradigms and seeing how much consistency in approach is possible/desirable across REST, messaging and services. Finally we'll be working with the workgroups responsible for the Administration and Financial modules to increase the consistency of approach to the design of workflow-related resources, regardless of domain. Whether any of the resources defined beneath this module will be candidates for normative status in the next release of FHIR will depend on the degree and type of implementer feedback between now and that release.

Additional topics for future work include:

• Resolving the overlap between the SupplyRequest, DeviceUseRequest and VisionPrescription resources
• Improving mapping and alignment of the elements and status codes of the Task resource with the WS-HumanTask specification
• Creating "best practice" guides for how to implement workflow for different business patterns
• Examining how workflow is used for "compensating actions", for example account transactions and reversals