|Work Group FHIR Infrastructure||Standards Status : Informative|
The workflow module focuses on the coordination of activities within and across systems. This includes three primary aspects:
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.
Workflow manifests in many places in the healthcare environment:
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 .
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. 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:
For more general considerations, see the Security and Privacy module .
Initial work has taken place on aligning most (though not yet all) resources with the Definition , Request and Event patterns. In the lead-up to R5, we'll be moving the alignment checks into the build process and more formally documenting (and potentially reporting) on variations along with their justifications. Further alignment is also possible (where beneficial to implementers). We'll also be examining the potential for exposing alignment with the patterns in a computably useful manner (e.g. as interfaces).
Work will continue on the workflow patterns, including vetting the patterns against various clinical scenarios and enhancing pattern documentation. We also 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 to the Task resource. As well, we'll examine the possibility for developing "standardized" workflows for certain domains and how such patterns might be documented, particularly through the use of the ExampleScenario resource. We will look for implementer feedback to guide this work.
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.
Additional topics for future work include: