What is workflow?

A 1921 reference to the term Workflow as we use it today, from The Railway Engineer Volume 42

I devoted most of Q3 and all of Q4 at the HL7 Working group meeting today in a session hosted by Orders and Observations, and including participants from Financial Management, Patient Care, Modelling and Methodology, Imaging Integration, Pharmacy, Healthcare Standards Integration, Security and FHIR Infrastructure work groups to discuss the addition of workflow to FHIR DSTU 2.1 in the coming months.

There's a ton of information packed into that single sentence, so let me parse that for you:

1. A lot of people in HL7 are interested in workflow.
2. It will be a focal point of the next FHIR DSTU release, presently known as 2.1.
3. The material will be developed fairly quickly (at least to support FHIR connectathon testing), and will likely be balloted in the next six months (although unlikely to be balloted in the next cycle due to the short time frame for it).

One of the things we didn't yet agree upon is what we mean by workflow, and it was fairly clear that what a lot of people were talking about addressed workflow at a variety of different levels.

Many workflow standards exist today without even defining what a workflow is.  BPMN is a perfect example, as is OASIS Human Task (the standard IHE used to support Cross-Enterprise Document Workflow).  Fortunately, the Workflow Management Coalition (WfMC) defines workflow in their glossary as:

The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.

This is a fairly straightforward definition, which I will build upon further based on my work with BPMN over the past year or so.  Some of the terms in this definition are a bit slanted towards business process automation and workflow management tools, but for the most part what it says can readily be applied to what we are trying to do with workflow in healthcare at HL7 and elsewhere.

From my perspective:

Workflow is the creation of a good or service through the collaboration of multiple parties performing a defined process.

Each component of this definition is essential.
An activity that does not provide some utility (the good or service) is at best boring, and at worst wasteful.

• If only a single party (person, organization or system) is involved, then we don't need to manage it in the same way as when is is performed by multiple parties, at at best our "workflow" becomes a process or algorithm by which a good or service is produced.  So without multiple parties, our need to manage "workflow" disappears.  
• The defined process is also essential, because that is how we can measure progress through a workflow.

It's fairly clear in many discussions that I have had with others about workflow that some of the essentials are missing when workflow is being discussed.  People often talk about "their workflow", but what they often mean is their process, which moves us a bit further along to the next definition:

A process is a defined sequence of activities and decisions to be performed by an entity that has a clear starting and ending point, and may have inputs and outputs.

Without clear endpoints, we cannot tell how far along a process is.  Without sequence, we cannot ensure that steps occur in the appropriate order when necessary. Decision points allow for alteration or repetition of a process based upon defined criteria [wash, rinse, repeat until done]. Inputs and outputs provide for interim measurable results that show progression through the workflow, and through which quality of the process can be evaluated and managed.

The parties, entities or whatever phrase you might want to apply are simply autonomous actors, things able to do something of their own volition having been appropriately prepared.  That can be a person, an organization, or a system, or some entity composed of two or more of those parts.

Finally,

An activity is a unit of work which can be treated atomically.  Activities are performed by people, organizations or systems (or by any composition of the same).  Activities may be further broken down, in which case it can be viewed as a "subprocess."

Some processes are comprised of a single activity.  When my daughter (either of them) creates a drawing, they may not have a defined process for how they do that activity (arguably, it is very ad hoc).  But there is a very clear beginning point (a blank page), and an end-point, which often includes a decision to be made (an artist decision, a filled page, or bed-time, whichever comes first ;-).  So even a not very well defined activity can have a moderately well defined process.

The definitions I've provided are clearly informed by BPMN, but are also consistent with other definitions of workflow found elsewhere, going back as far as 1921.

I don't know that it is all that important to get people to agree with MY definitions, so long as we agree to work from some definition.  I think making sure that we understand the distinctions between the concepts associated with (in my definitions) the terms workflow, process and activity, we'll be able to move forward successfully.

One of the important distinctions that Lloyd made in the meeting is that Resources aren't activities. There is a difference between "Resource" and "Service", in that a resource can describe what needs to be done, e.g., a request or order.  The service actually executes the activity, and as a result may alter, create, delete or access other resources.  What FHIR operates on today are resources, and it includes the basic functions Create, Read, Update and Delete on those resources.  Those familiar with security ontologies will realize is that the missing action from FHIR resources is execute, and that is what services enable, the execution of a process.  And enabling collaboration (through FHIR) among multiple processes will result in integrated workflow, for perhaps the first time in healthcare.

BPMN and Actor/Transaction Diagrams

In all of my playing around with BPMN it's become apparent that it has a number of different uses for IHE profiles.  One of them is to represent actors and transactions.  Here are two views of IHE Radiology's Scheduled Workflow B Profile:

The IHE Actor/Transaction diagram on the left from SWF shows you what the different actors do in the profile.  The collaboration diagram on the right does exactly the same thing. I chose SWF because it's one of the more complex IHE profiles, and I can still capture the detail in almost the same amount of space.  The nice part about the latter component is that the collaboration diagram is computable. I've even embedded the documentation for the actors in the BPMN diagram.

One of the things that's missing from BPMN is a way to indicate which messages (IHE calls them transactions) in the workflow must be supported by the sender and receiver.  This isn't reflected in the Actor / Transaction Diagram that IHE uses either, but does show up in the Actor/Transaction Table that follows it.

BPMN can actually handle this with extensions, as I show in the following example:

    <bpmn2:messageFlow id="MessageFlow_2" name="Patient Update [RAD-12]" sourceRef="#Participant_1" targetRef="#Participant_2">
      <bpmn2:extensionElements>
        <ext:style/>
        <ihe:supportRequired ihe:source="Required" ihe:target="Required"/>
      </bpmn2:extensionElements>
    </bpmn2:messageFlow>

And if I could actually figure out how to use the BPMN Model editor in Eclipse, I might even be able to create this extension without having to edit the XML directly.  At this stage, it looks like I could capture a good deal of IHE Volume I content in BPMN.  I could go a step further and represent some of the use cases in BPMN models.  At this point though, I could see how a model driven development tool could be created for several different types of IHE profile.  I'm unlikely to take this further (at least from the IHE perspective) unless there is some interest in further developing the material further.

    Keith

A Collection of Posts on BPMN and IHE XDW Workflow Definitions

I've been spending a lot of time figuring out how to use BPMN to document Workflow Definition profiles using the IHE XDW Profile.  It's become a new series which you can follow using either the BPMN or Workflow labels, and I'll update this post periodically as I add more.

• Workflow Automation
  In which I realize that after looking at a few workflow profiles there's got to be a way to automate this.
• Building IHE XDW Workflows
  In which I show some of what I've already done previously and start to explore use of BPMN for documenting the workflow.
• BPMN and XDW
  Some initial mappings: BPMN Collaboration = XDW Workflow, BPMN Workflow Participant (Pool) = XDW Workflow Participant
• Workflow = Flexibility
  Some general rambling on what it means to support workflow, not really BPMN related.
• Integrating Existing Messages into a Workflow
  How to support existing IHE messages, an exploration still in need of a solution.
• Signaling Workflow Events
  On using BPMN signals to indicate when a workflow task has changed state.
• IHE XBeR Workflow Profile in BPMN
  My first crack at actually implementing an IHE XDW Profile in BPMN.

IHE XBeR Workflow Profile in BPMN

The image below is what I generated as an example representation of the IHE Cross-Enterprise Basic eReferral Workflow profile in BPMN 2.0 notation that I generated Friday based on the work some of which has been discussed here so far.

If you want the BPMN file, you can get it here.

A discussion of each workflow participant's responsibilities follows:

Referral Requester

At the start of it's process the Referral Requester begins by executing the "Request Referral" subprocess.  When the subprocess starts, this participant may, but is not required to create the XDW document containing this XDW task in the CREATED state to indicate that work has started creating a referral for the patient.  The eReferral request is created and is an output of the user task [this user task is NOT recorded in the XDW Workflow document -- there should be a way to indicate that somehow, but I haven't figured that part out yet].  At that point the eReferral request document [and other relevant data, but again I haven't figured out how to represent that yet either] are used as inputs to the Schedule Referral CREATED message.  This message notation is the way that we show that the scheduling task must be created and recorded in the XDW document [the XBeR profile doesn't actually have this requirement -- there's some work to discuss here].  Finally the participant updates the XDW Document with the Request Referral Task in the COMPLETED state.

Referral Scheduler

The Referral Scheduler basically waits until a Schedule Referral Task is CREATED.  Arguably, according to the XBeR profile, this task is actually triggered by the completion of the Referral Request, and I think I could simply notate it that way, without having to deal with the Schedule Referral CREATED event.  However, from a best practice perspective, a Workflow Monitor will want to track task status change events, and time between CREATED, READY, IN_PROCESS and COMPLETED are all important and have well-understood semantics.  So even though CREATED on Schedule Referral task could be implied by a COMPLETED on the Request Referral, it seems best to me to make such dependencies explicit.  I think the way I did it last Friday may not be right though.

Now, this Perform Referral subprocess really cannot continue further without the patient participation, so I created a merge where a message [really the patient request to schedule the referral] needs to also occur before the workflow can continue.  At that stage, the Schedule Referral task is supposed to [according to the profile] go to the IN_PROGRESS state, which we show with the signal event.  Then the patient is scheduled.  Note that the data flow shows that the eReferral request coming from the incoming message being used in the Create Appointment user task.  The next task: Perform Referral is created, and then the Schedule Referral is marked as COMPLETED.

This diagram shows what happens if a patient does not schedule the referral after sufficient time has passed, which results in a failure of the Schedule Referral Task, resulting in a closure of this workflow with the referral workflow itself failing to complete in a normal state (as we use the Error State here in the final form).

Perform Referral  

Alright, I leave the description of this one as an exercise for the reader.  There's really very little in here that you haven't already seen.  Tell me if you cannot figure it out.

Signaling Workflow Events

If you are like most people, you worry much more about your kids not getting a balanced breakfast then you do them getting brain tumors.  At least that's the case for me.  And if I had to worry about the latter problem, I'd probably not be worrying quite so much about the former.  Because the magnitude (cost, effort, impact, however you want to measure it) of the latter problem is so much bigger than the magnitude of a single instance of that other challenge (failing to get a balanced breakfast).  But when you multiple that other problem by the thousands of times that it occurs, it could still have just as big an impact.  Even so, these aren't equations that balance out prettily like those examples in physics or math texts.

This is one of the reason's that I've catapulted myself right into the middle of the workflow muddle in Health IT.  IHE's XDW profile has a lot to offer here for both sides, the provider doing a simple task thousands of times, and in those crazy-expensive collaborations like tumor boards, where having multiply expensive specialists wasting even a minute of time is worth paying attention to.

What I'm trying to do right now is figure out how to make both of these different kinds of workflows be able to benefit from precise descriptions.  Yesterday I explained how to integrate messages into a workflow, today, I'm going to discuss some of what I've discovered about event handling and signaling.

In BPMN, a signal is "like a message", except that it is broadcast to anyone who is interested in it. Rather than having a single sender and receiver (as in a message), a signal has a single thrower, and many possible catchers.  One of the things I'm using signals for in the IHE representation of an XDW workflow in BPMN is a XDW workflow task state change.  The XDW task I represent as a BPMN activity (specifically a sub-process).  Within that subprocess, each state change that forces an update of the XDW document in the XDS repository "signals" the change.  The event itself is named after the task and the final state.  Start events are "caught" by the task which the event is named for.  End events (either COMPLETED or FAILED) are thrown by the task for which the event is named.  I use the error event to represent the FAILED case, and the normal end event in BPMN to represent the usual COMPLETED condition.  Intermediate events for READY or IN_PROGRESS can be caught or thrown by anyone.  The "thrower" is responsible for recording the new task state in the XDW document.  The catcher simply waits until the task state is reached before doing anything else.

There's more I have to figure out in these cases, because I also have to figure out data flow with these signals, and also tie the signals into the IHE DSUB profile.  That's for later posts.

   Keith

Integrating Existing Messages into a Workflow

Usually, a message recipient is ignorant of the workflow that resulted in the message being sent.  The same message may be sent as part of multiple workflows, in multiple places within a single workflow, even multiple times within a single task.  I think we need to fix that, because there are a variety of different ways services could be optimized or improved if we only knew what workflow was being done.

One of my present challenges in IHE is in defined how to describe an XDW Workflow Definition in BPMN.  Mostly this involves mapping what has already been done in text in various workflow definition profiles to the appropriate BPMN representation.  But there are some things that you can do in BPMN that we haven't addressing in IHE Workflow definitions yet, probably because we really didn't have a clue as to how useful that might be.

Two areas of present concern are Messages and Signals (I'll talk about signals in a later post).  Now, in BPMN, a message is simply that. It could be used to represent an HL7 Version 2 message, an HL7 Version 3 message, a FHIR request, a SOAP Message, a DICOM service request, whatever.  You name it.  What I want to be able to do is associate a specific message with a workflow.  Now, the metadata stored in the Workflow instance captures that association, but not in any way that is searchable.  In other words, you need to know the workflow instance before you can determine the association with the message, and what I'm trying to find, given I only know about the message is the workflow instance.

Ideally, we'd all have workflow oriented systems, and this wouldn't be a problem.  Each message would be linked back to a workflow and we'd know without much effort where and how that was done.  But the reality is different.  Some systems have and deal with defined workflows.  Others don't.  Some messages can occur as part of more than one workflow, or result from more than one task in a single workflow, or could occur multiple times in a single task.  As the message receiver, figuring out where you are in the workflow be very valuable.  At the very least it might provide you with some opportunities to optimize the work of the message based on the workflow (for example, you might cache patient data when that patient is involved in an active workflow).

So, what I'm proposing is that the sender of a message acting as a result of a workflow add the message identifier to the metadata for document describing workflow instance when that document is updated to describe the task that sent the message.  The other piece of this would be to add that message identifier to the <taskEvent> element in the history.  That way, once you've received a message, you could quickly and easily find the workflow and task instance which generated it.

Now, I don't advocate that services being performed should vary in what they do based on the workflow that they are part of. That would result in numerous private agreements inside services with different workflows.  But it would allow for careful optimizations which could improve overall performance within and across workflows, and at the very least, would allow for information capture about the relationship of various workflows to activities affecting system integration.  Imaging being able to say: 85% of XYZ messages received are result of ABC workflow.  What would that do to your ability to optimize?

   -- Keith

Workflow = Flexibility

Consider McDonald's, Wendy's, and Burger King, and your favorite sit-down restaurant, and your favorite diner, and you favorite sushi place.  Do they all do the same thing?  Basically.  But their processes are very different. Would a nice sit-down restaurant benefit from adopting processes from Burger King?  Probably not. And vise-verse.  And leave my favorite Sushi place's processes alone.

What in those processes can and should be standardized?  And where does the value-add come in?  In all the discussion of the importance of workflow, one thing that we must realize is that very little workflow in this world is ever standardized.  Even Amazon and Barnes and Noble have different workflows, and let's not even add eBay into the discussion.  At best we might standardize on certain names for products and methods of preparation, and how food is permitted to be treated (e.g., storage temperatures).  And even names are challenging.  Ever order your steak Chicago-blue and get a charred mess?

Let us consider even the simplest healthcare workflow: Identifying the patient.

Do you:

1. Obtain a patient identifier from some official document (e.g., a driver's licence) and then look them up in some global database to get their demographics?
2. Get their demographics from them directly, and then verify their identity?
3. Verify their identity with one document, and get their healthcare identifier from another?
4. Or are the two linked together somehow?
5. Do you need more than one identifier for them?

After that, do you:

1. Collect their co-pay, and if so, how do you determine how much it is?
2. Bill their insurer (or the government, or both, them and the others)?
3. Collect their co-payment after billing?
4. How do you determine who pays and in what order?

Many of these very simple workflows vary, not just at the international level, but even within the same practice depending on the patient, and for a single patient depending on their age, payers and other stuff, even the type of practice they are visiting.

Could we simplify this?  Possibly.  Even probably for the really small stuff.  But once we get into bigger stuff, it isn't clear.  Part of the reason for this has to do with inference based on process and workflow. Once a particular workflow step has been completed, there are a lot of assumptions and inferences that can be made about what has already been done.  For example, in many places, the admission/registration process includes updates to the allergy list.  And so, a person familiar with that organization's workflow can rest assured that allergies have been update.  But elsewhere, they cannot, and so even though the patient has been admitted, the allergy list cannot be assumed to be up to date.

That may be an oversimplified example, but it should make the point.

What most people really mean when they say that workflow is important is that flexibility is important, so that your product (or mine, or anyone else's) is integrated with something else, the two can work together, regardless of whatever workflow the other assumed.

BPMN and XDW

Continuing my researches into representing IHE XDW profiles in BPMN:

The <collaboration> element in BPMN would represent the Workflow Profile.  That contains <participant> elements which would represent the Workflow Participants.  So far that makes sense. What isn't clear here is <messageFlow>, because XDW's notion of communication is through input and output documents, rather than explicit messages, but maybe there's a mapping here.

Each <participant> has a name, a description (in documentation), and references some processes. Essentially, we are putting the workflow participants in the collaboration as swim-lanes.  Again, this part makes sense to me.  I've seen at least one workflow where partnerMultiplicity is useful (an order placer for a read of an imaging study in which several order fillers could respond).

There's a few places where some routing logic needs to be explained, and where triggers and timeouts need to be addressed.  I'm looking for task transitions to be triggers for other workflow tasks.

I'm not entirely clear on the distinction between the terms task (in Human Task) and process (in BPMN), because task seems like it could be smaller or larger depending on context.

One of the places where it seems like there would need to be some refinement in ITI is in the DSUB profile, because I'd like to support DSUB style notifications of workflow participants when their created/owned tasks have been transitioned from one state to another (each task has an owner and a creator -- when the task has its state changed, both the owner and the creator may want to know about it).

I think these might be some additional DSUB-like queries, which might be addressed by the Workflow Monitor participant.

Workflow Automation

I've now seen more than a dozen, and written almost a half-dozen workflow profiles over the past two years.  After the first two, the remainder get simpler.  After the first three, if I cannot automate some part of the process, I must be sleeping.  For my last five, I automated a huge chunk of the content development.  And as it turns out, with BPMN 2.0, there is an XML expression for the semantics of what gets depicted in an IHE Workflow profile, addressing things like task ownership, attachments, messaging, and sequencing.  As workflows get more complex, we'll need to incorporate branching and notifications as well.

So for the next IHE PCC cycle of profile development I will be building an Appendix to the PCC Technical framework profiling the use of BPMN to describe IHE Workflows.  The next IHE Workflow profile to come out of PCC (and Radiology): Remote Read, will take advantage of what I get done to facilitate implementation.

A couple of quick notes on the value of this:

1. I've shown that you can automate development of conformance rules, test plans, and implementation testing via an XML representation of the workflow.
2. I've also shown that a lot of documentation can also be generated from the XML representation.
3. You could actually plug the BPMN into your workflow automation tools to simplify your implementation.

It remains to be seen whether I can profile BPMN 2.0 and its XML representation of the workflow semantics (I care some about the pretty pictures, but not terribly much) to provide the same set of capabilities.  But so far, early investigations are promising.  Since I already have a set of five workflows that I've developed my own little DSL for, basically I'll be looking for how to represent that DSL in BMPN 2.0.

It's one of those things you'll get to look forward to here in 2015 as I develop that content in IHE.  And hopefully, as the IHE/HL7 Joint Workgroup continues on its slow but steady process to creation, we'll be able to look at capturing workflow details in FHIR.  But that will have to wait at least for DSTU 3 (the content train for DSTU left the station months ago).

    -- Keith