Release 4 R6 Ballot (1st Full Ballot)

This page is part of the FHIR Specification (v4.0.1: R4 - Mixed Normative and STU v6.0.0-ballot4: Release 6 Ballot (1st Full Ballot) (see Ballot Notes ) in it's permanent home (it will always be available at this URL). ). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions for published versions icon . Page versions: R5 R4B R4 R3

Responsible Owner: Work Group FHIR Infrastructure icon Standards Status : Informative

12.0 15.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. i.e., process/orchestration definition

For information about the relationship of specific domain resources, consult the modules that are specific to those resources. For example, the Administration module contains an explanation of the relationship of Appointment , Slot , Encounter , etc. The Diagnostics module contains the relationship between ObservationDefinition , ServiceRequest , Observation , DiagnosticReport , etc.

12.0 15.0 Index

Infrastructure
Scheduling
Clinical Process

12.0.1 15.0.1 Introduction

Workflows can be performed through direct posting of resources to a target server (combined with a specific tag), by using the Task resource, through the use of messaging or via FHIR services . This specification includes a workflow page that describes the concepts underlying the discussion of workflows, and points to a number of different communication and architectural workflow patterns .

In addition to the Task resource, 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 common attributes of each type of resource as well as relationships between them. 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 by describing the types of activities that can occur and setting rules about their composition, sequencing, interdependencies and flow.

12.0.2 15.0.2 Common use Cases

Workflow manifests in many places in the healthcare environment:

  • Creating a lab order , drug prescription , or other clinical order or an insurance claim , enrollment request , Appointment 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. (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. (e.g., suspension, update, cancellation, etc.) to a fulfilling system so that they can take appropriate action
  • Asking for a state change, requesting the merge of a couple of patients or the invoking of some operation or decision support in 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 these scenarios (and many others). Common mechanisms, along with their pros and cons can be found in the workflow sections on patterns .

12.0.3 15.0.3 Security and Privacy

Resources related to workflow need to adhere to the same security and privacy guidelines that apply to all FHIR resources, 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. 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 15.0.4 Developmental Roadmap

Initial work has taken place on aligning most (though not yet all) resources with the Definition , Request and , Event and other patterns. We now have tooling that allows easier checking of alignment and documenting reasons for divergence. In the lead-up to R5, R6, we'll be moving the alignment checks into the build process and more formally documenting (and potentially reporting) on variations along with their justifications. setting expectations for work groups to capture these reasons for divergence. Further alignment is also possible (where beneficial to implementers). We'll also implementers), though breaking changes will generally not be examining the potential for exposing alignment with the patterns in a computably useful manner (e.g. as interfaces). made solely to further alignment.

Work will continue is underway within the Diagnostics space on enhancing guidance around order fulfillment and the workflow patterns, including vetting the patterns against pages will be updated to reflect this documentation. Additional IGs that take on various clinical scenarios aspects of workflow are anticipated and enhancing pattern documentation. We further changes based on feedback from those IGs is also possible.

We hope to examine both messaging and services in more detail with further guidance about when and how such mechanisms should be used for workflow and how they relate develop tooling to the Task render ExampleScenario resource. As well, we'll examine instances as part of the possibility for developing "standardized" workflows for certain domains core specification and start to leverage that to create more documentation about how such patterns might be documented, particularly through the use of the ExampleScenario resource. We will look for implementer feedback to guide handle complex workflows, both within this work. core specification as well as within implementation guides.

The PlanDefinition and ActivityDefinition resources will continue to evolve based on feedback from the implementer community. We'll explore using them in a variety of ways, including clinical order sets, medication protocols, workflow protocols, clinical pathways, administrative protocols, etc. We hope to develop several example workflow protocols. guidance and examples of using these resources to document expected interoperablity interactions at the system level.

Additional topics for future work include:

  • The initial effort to align with workflow patterns has been a bit over-zealous for some resources, resulting in the loss of domain-specific context or occasionally the introduction of elements that might be more properly represented as extensions. In R5, we'll We will continue to work on improving the balance, ensuring that consistency working with patterns does not overshadow the essential requirements for implementer intuitiveness and simplicity Resolving the overlap between the SupplyRequest , DeviceRequest and VisionPrescription resources Improving mapping and alignment of the work groups to evaluate when elements and status codes of the Task resource with the WS-HumanTask specification should be handled in core vs. using extensions, though we will take into account implementation levels before introducing breaking changes.
  • Creating "best practice" guides for how to implement workflow for different business patterns
  • Examining how workflow is used for compensating actions icon E.g. e.g., account transactions and reversals