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

What I'll be doing in 2015

What will I be doing in 2015?

1. Defining how to represent IHE XDW Workflow Definitions in BPMN.
2. Getting involved in the HL7/IHE Joint Workgroup.
3. Participating in IHE PCC profile development.
4. Paying attention to HL7 FHIR Projects
5. Responding to pending Meaningful Use and related Health IT regulation

For school, I've got two things going on:

1. I'm enrolled in Design and Evaluation in Health Informatics
2. I have some things to do to prepare to teach an online edition of the Standards and Interoperability class, more on that as it evolves.

As the year starts off, this seems like a light load, and from an external perspective, it is compared to my usual activities.  However, I expect the HL7/IHE Joint workgroup efforts will be consuming a great deal of my time once it gets going.  There's a ton of outstanding things that it could take on.

I'm no longer on the HL7 Board, and did not get elected to be the HL7 Chair, so I have at least a year of not being involved on the board.  I'm not sure what I'm going to do there.  I'm still involved in several board appointed committees and planning on continuing in those roles.  The real question is whether I'm going to run for the Board again, and if so, in what role, and when.

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.

Outeroperability

One of the differences between IHE and HL7 is in how the two organizations approach the dynamic interaction model.  IHE has actors which exchange information in transactions.   HL7 (version 2 and 3) have application roles and interactions which exchange information using messages.  But the traditional focus is a bit different in the two organizations.  In V3, very little attention is given to story board and application roles.  Most of the attention goes to the information models, the various *IM diagrams that are generated.  In IHE, about 50% of the technical detail in a profile is related to the information model -- constraints on data.  The other 50% (sometimes even more), is on required behaviours.  It isn't enough to just recieve the message, the reciever has to do something (operate with) the information it recieved from elsewhere.

This material is covered in the HL7 specifications, it just doesn't have as much an impact on how the specification is written.  And within different domains, these generalizations don't always apply.  For example, most of PCC's early work was about data constraints (templates).  And some HL7 domains focus very much on dynamic behaviours.

This is the real key to interoperability is to be able to operate with information recieved from outside your system.  I think it should really be called outeroperability.

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.

Nobody Knows

In looking back over 2014, and looking forward to 2015, two things stands out: uncertainty and change.  As I look into my crystal ball at the beginning of this year, I see more fog than I have seen in many years.

1. The US national program is at a time of transition, from the carrot to the stick. Incentives are no more.  Penalties kick in this year.  Will that work? 
2. At the same time, many hope that the incoming congress will pass new laws changing the way the Meaningful Use program works.  Will that happen?
3. Meaningful Use Stage 3 proposed rule, which many and projected to drop December 23rd as usually is still waiting in the wings,  Clearly it is no longer business as usual at ONC.  What's in the proposed rule?
4. ONC now hosts at most three of the original people staffing it under ARRA.  Few really have a clue what is going to happen here either.  What will ONC look like when it grows up?
5. FHIR will soon be launching its second DSTU.  The first pilots of FHIR using DSTU 1 will soon be appearing.  Will it work, or won't it?  
6. IHE and HL7 will soon have a joint workgroup. There is a lot of opportunity here to bring together these two organizations which have had an on-again off-again love-like-hate-envy-love relationship.  , will it be successful?  

On a personal note, I am now half-way through my degree program according to hours needed to graduate, and so far carrying a very credible GPA.  I'm looking forward to teaching my first semester long class later this year on Interoperability and Standards. Will I become one of those ivory tower academics that I so despised earlier in my career?  (I certainly hope not, but ...)

For next year, I have to plan out what I will be doing, and how my new role(s) will be evolving.  As to what that will look like?

So, wishing you a joyful new year, and as for all the rest ... I dunno.

    Keith