A Workflow Framework

What follows is specification gobbelty-gook that flowed from my brain after the result of our FHIR Workflow discussions in HL7 earlier today.  It doesn't really explain much (specs often don't), but it's essential content somewhere, so I'm saving it here for further conjuration.

  Keith

---

The essential components of a workflow infrastructure for FHIR include the following:

1. A task resource which tracks the state of a service request, and which may be referenced by other task resources (known as subtasks).
2. A workflow system of record that keeps track of task resources.
3. At least one requester of services (e.g., order placer) that creates task resources indicating that a task needs to be performed.
4. At least one performer of services (e.g., order filler) that modifies task resources upon performance of a task.
5. An optional service monitor that tracks the state of task resources.
6. An optional service manager that can change the state of task resources.

The service requester must create task resources, and monitor the status of task resources that it creates as needed to ensure work is done.

The service performer must read task resources and monitor the status of those resources as they are updated to ensure the appropriate performance of work being requested.

The service monitor may read task resources to enable other functions (e.g., escalation, service level monitoring, dashboarding, et cetera).  Within a functioning workflow environment, it need not be present.

A service manager may write task resources to force a change in state of a task to support other functions (delegation, escalation, tie breaking, et cetera). Within a functioning workflow environment, it need not be present.

The system of record must maintain task resources in their current state.  It should support access to the history of the task resource. It should also support query and subscription to updates of a task resource. It MAY support additional capabilities, such as enforcement of certain constraints when a task is modified.  For example, it might insist that a task in the "Completed" state first be brought back to an "In Progress" state before certain properties are allowed to be modified.  It may also support storage of other resources.

The system of record may be a composition (e.g., federation) of systems, so long as all systems provide a consistent view of the current state of a task within certain limits (e.g., federation may incur some delays between synchronization of views, but these should be small).  The mechanism by which such federation is accomplished is unspecified.

The system of record for a task may migrate from one system component to another as the state of the task changes.  In this case, it must be apparent to all systems participating in the workflow environment which system is the system of record. The mechanism and model for this is not specified, and we only note that REST allows for Representational State Transfer, thus, that a task resource could be transferred from one system to another.

The mechanism by which the service requester and service performer monitor activities on tasks is unspecified.  This may occur through periodic polling, use of subscription, or even out of band communications to ensure that the information stored in the system of record is tracked by the service performer and service requester.

The results of task execution should be independent from the mechanism used for task monitoring. In other words, two systems which are cooperating in a workflow through the exchange of information in a task resource should not be able to distinguish whether the task is being processed by a system that monitors task status through polling or through a subscription mechanism.  This is not to say that there may not be advantages to the use of one mechanism or another, but that the effect should not be sufficiently distinguishable so far as the execution of the workflow is concerned.

To request that a task be performed the service requester shall create task resource on the system of record in any state less than "In Progress" (e.g., Created, Ready, Assigned).  In response to creation of such a task, a service performer may assign the task to itself, or if already assigned, may delegate or reassign the task to another system.  Once the task is in progress the service performer should mark it so.  A task can be suspended or resumed by the service performer or other system actor, or it may be cancelled.  Upon completion of the task the service performer will mark the task as complete.  If the task cannot be normally completed the service performer should mark it as failed, and provide a reason for failure.  If a task is not accepted by a service performer, this should be handled as for failure, with the reason for failure indicating the reason that the task was rejected.

Tasks can have sub-tasks.  The service performer can decide when it accepts a task how to break the work into subtasks and subsequently manage these.  The subtasks need not be stored in the same system of record as the original task, nor need they be assigned to the same task performer.  These subtasks should reference the parent task so that the entire workflow status associated with the initial task can be determined.  In BPMN parlance, a collaboration diagram represents a workflow, and within that collaboration an activity can be represented as a subprocess with seperate activities being performed by other workflow participants.  Within FHIR, the task represents a business process, either at the level of workflow collaboration, or at the subprocess level, and so comprises the functions of both the workflow and task information items.