More on Designing IHE XDW Workflows

So, more on building XDW workflows: As I began working through how to get data out of the spreadsheet I discovered several things.

Counting

I need to count three different things:

1. Steps in the workflow, 
2. alternatives within a step, 
3. and actions within an alternative. 

Once I have that numbering, building a BPMN diagram describing the workflow from the spreadsheet is basically automatic. This gives me a very good structure to use to generate the description of tasks, and the specific requirements of actors.

The steps are the point, not the triggers

In several cases I had different triggers doing the same pieces of work in the same workflow I was developing. So, I combined the triggers and merged the steps. For example, one actor in a referral would basically be doing the same work on evaluating a new referral as they would evaluating a referral that had additional data provided because it was requested. So, when the Request Information task completes, or a Respond to Referral request goes to IN_PROGRESS, those two triggers can start the same step (as far as the workflow is concerned).

Actions that Transition Tasks Generate new Triggers which should be Assigned to Steps

The nice thing about the spreadsheet is that whenever I transition a task to a status in the action row, I know there needs to be a trigger added so that some other task can act on that transition.  I discovered I had missed a bunch in the workflow I created, so I'm having to clean all of that up.

Proper use of Status

On the workflow statuses, I did a bit of digging into XDW and Human Task, and established some principles that I document only the required transitions and stay silent on the rest. That requires that I rework a number of transitions because having a common description for what these states means is very useful for dash-boarding (a key component of existing referral solutions they have):

CREATED	Task is Unassigned (has no owner) and is not ready to be acted upon.
READY	Task is Assigned (has an owner) and is ready to be acted upon (but may not yet have been acted on by the task owner)
IN_PROGRESS	Task is Assigned, is ready to be acted upon, and some work has been done by the task owner
COMPLETED	Task is done, usually by the task owner.
FAILURE	Task could not be completed, usually by the task owner, but perhaps by others.

So, Actor 1 executing Task A could certainly create Task B owned by Actor 2, but SHOULD NOT indicate that it is IN_PROGRESS, only that it is READY. It would be up to Task B to indicate that it is IN_PROGRESS. That requires a number of different changes in the spreadsheet and I have to go somewhat carefully.  However, in my original spreadsheet, I didn't start with those definitions. So now I have to go back through and change a bunch of things in the spreadsheet, and am about halfway through it.

Notification can be Automated

One thing that I discovered through all of this is that notifications should pretty much be automatic, with very view workflow dependent exceptions.

1. Any "Workflow Manager" or "Workflow Monitor" participant dealing with the workflow should always be notified. 
2. The task owner should always be notified whenever a task assigned to it has had its status changed by any workflow participant other than itself. 
3. The task creator should always be notified whenever a task created by it has had its status changed by any workflow participant other than itself.

That leaves me only a few special cases to handle for notification in my complex workflow.  All other cases are handed by the above three rules.

Finishing the Workflow

I still have to figure out how to document that a workflow is completed.  There are at least three ways I can do that.  For now, I'm just going to use the notes for that.

Here are the column heads for my spreadsheet.

Workflow
Step #
Step Name
Trigger Events
Responsible Actor
Alternative
Conditions
Action #
Action
Workflow Task
Task Status
Task Owner
Input Documents
Output Documents
Notify
Notes