Shared Care Planning (SCP) Implementation Guide - Local Development build (v0.3.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Workflow
Summary of workflow in FHIR core specification
The FHIR R4 Workflow Module provides a standardized approach to managing processes and workflows within healthcare systems using FHIR standards. It defines a set of resources and operations to model, manage, and track workflow activities across various healthcare applications. This can be used for several use cases, to basically, 'ask for stuff' like:
- Here's a drug prescription/lab order
- Referrals
- Please fill out this form
- Please suspend this order
- Please discharge this patient
- Please call me
It defines resources across three categories:
- Definitions: Resources such as ActivityDefinition and PlanDefinition, which describe possible activities and how they should be performed.
- Requests: Resources like ServiceRequest, MedicationRequest or DeviceRequest that represent the medical authorization for an activity to occur. The existence of a "Request" instance doesn't necessarily imply that fulfillment will be requested immediately - or even ever. The decision to request fulfillment may be delegated to the patient or to down-stream practitioners. Such fulfilling practitioners may need to capture additional information prior to executing the fulfillment.
- Events: Resources such as Procedure, Observation and MedicationAdministration that capture what has been done in response to a request.
The FHIR Task resource is a special case. The Task resource in the Workflow module is designed to represent specific actions or work items that need to be completed within a healthcare workflow. It provides a way to track the status, progress, and outcomes of tasks and specify who is accountable for the task and what is expected. Given a request (e.g. ServiceRequest), multiple Tasks may be used for this request to seek a care provider that is able to fullfill the request. Given a request (e.g. MedicationRequest), multiple Tasks may be used for this request to actually administer a dosage of the medication at a given time or interval. A Task resource can handle dependencies between tasks. For instance, one task may need to be completed before another can begin. This ensures tasks are executed in the correct sequence.
FHIR Workflow Module descibes various communication patterns to implement a workflow. Depending on the requirements, this can range from simple to more advanced workflows.
An example of a simple workflow would be to create a request (e.g. ServiceRequest or MedicationRequest) for a performer and tag it to be 'actionable'. It does not use a Task resource to manage the status of a request. This workflow pattern has the lowest amount of overhead, but also has limitations:
- Can only use when requesting fulfillment (can't use to request status change or other updates)
- No indication of agreement to act on the request
- There's no ability to negotiate fulfillment - no ability to say "no"
- The only way to stop fulfillment is to update the Request to have a 'cancelled' status Another option would be to just use a Task resource without the 'request' resource. This is applicable for simple requests that do not require medical authorization. E.g. 'change this bed' or 'fill out this form'.
More advanced FHIR workflow patterns make use of a Task resource to enable negotiation and state-management for a specific request (e.g. ServiceRequest or MedicationRequest). It 'solves' the limitations of the simpler workflows, but it adds extra overhead and may add requirements for the healthcare systems of requester and performer.
Workflow in Shared Care Planning
In Shared Care Planning, an advanced FHIR workflow pattern is used to cover all requirements for a generic workflow process between organizations. The process is based on FHIR workflow pattern G, but SCP nodes can also use pattern F or H depending on the capabilities of their healthcare systems. The main difference between these 3 patterns (F, G and H) is the location of the Task; it can be stored at the requester, performer or at a third party (broker). For example; if you'd want to create a Task at the performer, but their EHR does not support it, you may choose to create a Task at your own EHR and notify the performer (and thus following pattern F in stead of G). SCP uses notifications in between nodes to provide quick feedback/updates in initial phase of a Task (creation to acceptance/rejectance).
Task workflow Option G: Creation of Task on performer's system
Notification of stakeholders
If a SCP-Task is created/updated, participating organizations MUST be notified of this change.
Stakeholders may have a role in the Task. For example, an external care provider department may be set as the Task.owner. The Organization or HealthcareService instance of this care provider department may exist locally (or at a Care Service Directory service), so to find the notification-endpoint of the care provider may involve searching/fetching the HealthcareService.endpoint, HealthcareService.managingOrganizations, Organization.partOf and/or Organization.endpoint
Stakeholders may also host instances that are referenced in the Task (e.g. an external CarePlan in Task.basedOn, an external ServiceRequest in Task.focus or an external Task in Task.partOf). The base-url in the literal reference may be used to find the notification-endpoint.
Task state and lifecycle
The Task status and state transitions are important part in the lifecycle of a Task. The Task state machine for SCP is a subset of the base FHIR Task state machine. In comparison to base FHIR Task state machine, the SCP-Task does not use status 'draft' or state 'ready', but does allows states-transition and from 'requested to completed:
| State from | State to | Allow state transition for |
|---|---|---|
| - | requested | Task.requestor who is also CarePlan-participant |
| requested | received, accepted, rejected, cancelled, in-progress, completed, failed | Task.owner |
| received | accepted, rejected, cancelled, in-progress, completed, failed | Task.owner |
| accepted | cancelled, in-progress, completed, failed | Task.owner |
| in-progress | completed, failed, on-hold | Task.owner |
| on-hold | in-progress, completed, failed | Task.owner |
An SCP-Task can only be created by the requester. Tasks can only be updated by the owner/performer. However, some elements SHALL not be updated by the performer, depending on the Task.intent. This table indicates the elements a performer can update (immutability is the default):
| Mutable elements | notes |
|---|---|
| status | changing status to requested is prohibited |
| statusReason | - |
| businessstatus | - |
| executionPeriod | if intent = order and the status is updated to received or accepted, the executionPeriod should not be updated |
| lastModified | - |
| owner | the owner may be changed to an entity within current organization |
| location | - |
| note | - |
| relevantHistory | - |
| output | - |
To avoid losing data during updates, actors MUST support the directives in FHIR transactional integrity and FHIR concurrency
Using planned Tasks
When a requester sets Task.intent to plan, it may use this to find the care organization that is able to perform the Task closest to the Patient or at the earliest date (by changing the executionPeriod).
Multiple Tasks may be created in parallel for different care providers. For privacy reasons, the Patient instance (or non-relevant parts of the Patient instance) should not be shared with care providers in this phase.
Performers MUST respond real-time to allow the requester to select the best performer (based on location, executionPeriod or other data like cost and patient satisfaction ratings). A new Task SHALL be created with intent = order, status = requested and the selected performer to proceed with the usual acceptance/execution of the Task.