Why should HealthIT Workflow integration be Different?

In a traditional (read "non-Healthcare" related) workflow scenario:

1. A workflow produces a good or service through the collaboration of different parties.
2. The good or service is developed in various stages with through various processes coordinated between parties, with various checkpoints to ensure quality.
3. Along the way, various information, services or goods are consumed as inputs, or produced as outputs, eventually generating the final good or service that is the goal of the workflow.

Under the above description, lab tests, imaging or other diagnostic studies, screenings, treatments, medication orders, or referrals are all activities involving workflow.  The good or service produced by a diagnostic study is information about a patient used in the diagnosis of disease.  Treatment provides a service that will either cure, or at least alleviate the symptoms of illness.  So really, there is no difference here.

The flow in workflow is of outputs to inputs between tasks being executed by different participants. The fundamental unit of work is a task.  This is reflected in many different models of workflow in the various standards that I discussed yesterday.  Tasks have a fundamental state diagram that is well described in OASIS Human Task.  Essentially, they are first created, then ready to be claimed, then reserved (claimed), and finally in progress and completed (or failed).  Some special states exist to account for non-recoverable errors (recoverable errors eventually complete or fail), premature exit (e.g., cancellation of an order), or on becoming obsolete (it is no longer necessary to treat a patient whose is no longer ill).  Tasks can also be in a special suspended (held) substate from which they return once they are unsuspended (e.g., putting a medication on hold while surgery is being performed).  It's conceivable that a task can go from any of the previously mentioned states to any other (Interface engine administrators often "requeue" messages that "unrecoverably" failed after patching the code).

Tasks have potential performers, those who could perform the task, an actual performer, a creator, and an administrator who can change it (often the creator and administrator are the same party).  Many of these roles can be delegated or reassigned (forwarded).

Tasks have inputs and outputs. These are essentially named slots to which you can attach things (much like Parameters used with FHIR operations).

There are a couple of other attributes of task that might be useful: Priority, type (of task), type of performer (used to qualify potential owners).

Here's my first crack at what Task looks like in FHIR.

<Task xmlns="http://hl7.org/fhir"> 
 <identifier><!-- 0..1 Identifier Task Instance Identifier --></identifier>
 <type><!-- 0..1 CodeableConcept Task Type --></type>
 <performerType><!-- 0..* Coding Task Performer Type --></performerType>
 <priority><!-- 0..1 Coding Task Priority --></priority>
 <status><!-- 1..1 Coding Task Status --></status>
 <subject><!-- 0..1 Reference(Any) Task Subject --></subject>
 <definition value="[uri]"/><!-- 0..1 Task Definition -->
 <created value="[dateTime]"/><!--  1..1 Task Creation Date -->
 <lastModified value="[dateTime]"/><!--  1..1 Task Last Modified Date -->
 <owner><!-- 0..1 Reference(Device|Organization|Patient|Practitioner|RelatedPerson) Task Owner -->
 </owner>
 <creator><!-- 1..1 Reference(Device|Organization|Patient|Practitioner|RelatedPerson) Task Creator -->
 </creator>
 <manager><!-- 0..* Reference(Device|Organization|Patient|Practitioner|RelatedPerson) Task Manager -->
 </manager>
 <input>  <!-- 0..* Task Input -->
  <name value="[string]"/><!-- 0..1 Input Name -->
  <value[x]><!--  0..1 * Input Value --></value[x]>
 </input>
 <output>  <!-- 0..* Task Output -->
  <name value="[string]"/><!-- 0..1 Output Name -->
  <value[x]><!--  0..1 * Output Value --></value[x]>
 </output>
</Task>

As a resource this is very well aligned with HumanTask and XDW, and would integrate fairly well in a workflow system defined using BPMN and/or orchestrated or choreographed using other. It doesn't have any specific requirements about "how" the task is managed, but enabled it to be managed and tracked.

Task Resources like this MAY be aggregated into a workflow instance resource, which allows a collection of related tasks associated with a given workflow to be managed together.  My first crack at that resource looks something like this:

<Workflow xmlns="http://hl7.org/fhir"> 
 <identifier><!-- 0..1 Identifier Workflow Instance Identifier --></identifier>
 <name value="[string]"/><!-- 1..1 Workflow Name -->
 <description value="[string]"/><!-- 0..1 Workflow Description -->
 <subject><!-- 0..1 Reference(Any) Workflow Subject --></subject>
 <definition value="[uri]"/><!-- 0..1 Workflow Definition -->
 <created value="[dateTime]"/><!-- 1..1 Creation Date -->
 <author><!-- 1..1 Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) Workflow Author --></author>
 <tasks><!-- 0..* Reference(Task) Workflow Tasks --></tasks>
 <status><!-- 1..1 Coding Workflow Status --></status>
 <failureReason><!--  0..* CodeableConcept Failure Reason --></failureReason>
</Workflow>

Now, if you want to put these two together, you can manage just about any workflow someone wants to throw at you.  Do medication orders for certain substances need to be reviewed before being filled?  That's a task that is part of the medication ordering workflow.  Does a positive result need to be confirmed by the lab supervisor?  That's a task that  is part of the laboratory testing workflow. These tasks can be associated with their subjects through the subject reference, without ever interfering with the interpretation of the subject resource.  If you want to dig into the workflow associated with an order, you could query for workflow.subject = resource, or task.subject = resource, and find the workflows still open, or the tasks as yet uncompleted.

This approach simplifies integration of clinical workflows with clinical data without making any assumptions about the workflows that go along with it.  And best of all, almost none of it is specific to healthcare.  Everything I've described above comes from existing IT standards and systems, but can be readily applied to healthcare.