Building IHE XDW Workflows

I've been working on a few XDW workflows lately, mostly dealing with variations on eReferral and Transfer. In developing these, it became pretty important to understand how the workflow itself works.  We've documented it in general using BPMN.  Ideally, what I would like to do is be able to represent the workflow description entirely in BPMN with a few annotations describing some key pieces of metadata about the workflow.  I haven't quite gotten there yet, but am pretty close.

What I have figured out is that the key to defining the workflow is a single spreadsheet table with the following columns:

• Trigger Event
• Responsible Actor
• Conditions
• Action
• Workflow Task
• Task Status
• Task Owner
• Input Documents
• Output Documents
• Notify
• Notes

The trigger event takes the form of "Workflow Task - Task Status", as in Request - COMPLETED, or a narrative description of an event, such as "Referral Response timed out" (e.g., indicating a maximum duration for a response was exceeded).  This tells you what initiates the activity.  The next two columns tell you who and when.  The responsible actor column is the workflow participant that has to do something, and the conditions tell you if there are additional preconditions that must be met.  For example, if the maximum time for a response timed out, AND there are no other acceptable responses, then the responsible actor must do something with another task.

And the next two columns start a "sub table", listing the things that the responsible actor must do.  It may for example, transition one task to another state, AND create two new tasks.  Each one of these gets a row. The action is usually create or transition, or create/transition, and the workflow task is one to be acted upon. Create is used to create a task that hasn't already existed.  Transition is used to transition a task that already exists to a new state.  Create/Transition is used when you don't know what the current status is for the task (it may not have been created yet, but it could exist).  Task Status indicates what the final state is for the task that was acted upon.  The task owner indicates who the task owner is.  Tasks can be created by the task owner, but may also be created by other workflow participants.  For example, in the workflow I'm looking at, one participant creates a Respond to Request task for each possible edge system that could respond, encouraging them to complete some activity.  During these actions, input or output documents can be added to the workflow.  Usually input documents are added during CREATE and IN_PROCESS states, and Output documents are added during IN_PROCESS, COMPLETE or FAILURE transitions.  It isn't usually the case that an input is added at the end of the task.  In some cases (although I haven't had to do this yet), the only action an actor may have is to add an input or output document to another task, and do nothing else.

An important step is that a notification should be given to the task owner and any expected actor who will be triggered by the state transition on the task.  Thus, is the Referral Requester workflow participant has a trigger on Response COMPLETED, then when the Referral Responder workflow participant the Response task to COMPLETED, it should notify the Referral Requester.  For this, I'm assuming that the DSUB transaction is used for notifications, and that the workflow participants are duly notified by some other actor (perhaps the Workflow Manager) of these cases.  There's no real subscription to set up, its just assumed that the notification transaction will occur under the appropriate cases.  When you use a Workflow Manager actor (as I did in my definition), one thing that you could do is make sure that 

1. It is listed as the intended recipient of the workflow document (meaning that it will be managing the workflow),
2. Some system, such as the registry or repository, interprets the intendedRecipient metadata in the provide and register transaction as a signal that a DSUB style notification should be given to the actor identified (in some way) in the Intended Recipient metadata. 
3. That workflow manager notifies any task owner of transitions that have occured on a task that were NOT performed by the task owner itself.  For example, task creations, FAILURE or COMPLETION transitions that may be caused by other external events, et cetera.
4. That workflow manager also notifies any actor responsible for activity on a trigger event that it can detect, e.g., a transition of a task.

In defining workflow in this manner, the table defines what MUST be done in the XDW workflow document, BUT, it does not prohibit additional transactions.  For example, in the Referral Request task, we only note that when a referral is needed (a narrative trigger event), the Referral Requester must create a Referral Request with final status being COMPLETED, and an input document of a Referral Request Document.  I don't say anything at all about the existence of intermediate states, such as CREATED, or IN_PROCESS.  It is quite possible that these states are recorded and the various transitions shown in the XDW document over time.  However, my definition doesn't depend on their existence, and doesn't prohibit it.  This enables other useful behaviors to be added later.  These states are essentially implicit in the workflow, and simply aren't documented with any requirements.

An important point in building these tables is that you have to consider that the state of the workflow should be transparent to an outside reviewer that does NOT have any understanding of the internal business rules associated with the workflow.  So, while you might assume that since a request has been completed, it is expected that the Referral Responder actors might be tasked with generating a respond, you wouldn't be able to tell if a task didn't exist for those actors.  Thus, some tasks that don't exactly need to be recorded in the workflow document to manage the state among the workflow participants still need to be made explicit so that others (such as dashboarding applications), can still provide a good indication to an outside viewer what the status of the workflow is.

I've transposed an short example of the table below (because I usually make it horizontal rather than vertically oriented).  I'll explain the key points after the table.  This is an example meant to illustrate different features of the table, it's not the actual workflow that I wound up defining.

Metadata\Trigger Event	Referral needed	Referral Request IN_PROGRESS		Referral Response READY		Referral Response COMPLETED -or- FAILURE
Responsible Actor	Referral Requester	Workflow Manager		Referral Responder		Workflow Manager
Conditions	N/A	N/A		Referral can be accepted	Referral cannot be accepted	Acceptable Response available	No acceptable response available and more responses expected	No acceptable responses available and no more responses expected
Action	create	create	create	transition		transition	N/A	transition
Workflow Task	Referral Request	Dispatch Referral	Referral Response	Referral Response		Referral Request	N/A	Referral Request
Task Status	IN_PROGRESS	COMPLETED	READY	COMPLETED	FAILURE	COMPLETED	N/A	FAILURE
Task Owner	Referral Requester	Workflow Manager	Referral Responder	Referral Responder		Referral Requester
Input Documents	Request for Referral	N/A	Request for Referral	Request for Referral		Request for Referral	Request for Referral	Request for Referral
Output Documents	N/A	N/A	N/A	Referral Response (Required)	Referral Response (Optional)	Referral Response (Required)	N/A	Referral Responses (Optional)
Notify	Workflow Manager	Referral Requester	Referral Responder	Workflow Manager		Referral Requester	N/A	Referral Requester
Notes			This task is created for each possible referral responder.			Normal Completion	Wait, hopefully someone will respond positively	Nobody responded positively, include all negative responses as output to allow manual review/escalation.

The idea of this workflow is to handle a managed referral request process, where there is a single requestor, and multiple possible referral responders.  There's a workflow manager participant that handles the business processing of the responses to choose among acceptable responses.  When an acceptable response is received, the referral request task is considered to be completed.  There are a lot of different ways to extend this workflow by adding new columns to it.  For example, you could be nice, and transition each outstanding referral response task to the FAILURE state once a referral response has been accepted, so that the Referral Responders can now ignore these tasks if it hasn't gotten to them.  You could also add a time out event to allow the Workflow Manager to renotify Responders of tasks that they haven't paid attention to, or escalate the request, et cetera.

Getting to Other Views

Having developed this table, there are now a couple of different things that you can do with it.  Often you need to explain multiple viewpoints of the workflow definition to satisfy to all and sundry stakeholders what is happening.  The table allows me to generate three different views:

BPMN

You can start to diagram the workflow in BPMN.  The general rules I've been following is that each workflow task becomes a task or activity in the BPMN diagram, and that each workflow participant (aka actor or task owner) gets a swim lane or pool. Conditions are used as conditional entry points into a task. Input and output documents are often included as components of the messages passed between tasks in different lanes/pools.

In an ideal world, I'd have the time to do some automation with a modeling tool so that I could graphically create the content in BPMN and subsequently generate the table, or import the table from a spreadsheet, and dynamically generate the diagram.  For now, I can live with managing the diagram separately from the table and going back and forth between the two.  It's just simply a matter of time and priorities.

Actor Requirements

When you sort this table by responsible actors and task sequence (effectively time), you get a description of the responsible actors view of the task to be performed, and what their required behaviors are.

Task oriented View

When you sort it through by workflow task and task sequence, you get a view of the steps of the workflow.

Generalizing and Specializing

The beauty of this table format is that it also allowed me to build more complex workflows by specializing from simpler ones, again by adding columns (rows really in my spreadsheet).  In my case though, what we wound up doing was defining the most complicated workflow, and then removing columns (generalizing) to get to simpler ones.  It doesn't really matter the direction that you do it in, what matters is that you can simplify or generalize these behaviors.

Notification (ala DSUB) is an important component of this workflow description, and the mechanism I've used is pretty straightforward.  I'm not sure if that's something to submit as a modification to the XDW profile (e.g., the Notification option), or in a specific workflow profile, but I think it is probably worthwhile to consider.