OK Everybody, Synchronize your Resources

You know how in secret agent TV shows in the 70's and 80's, where at the start of a major intervention the agents all synchronize their watches to ensure that they knew what was to happen and when?  And if you failed to do that, you could really mess things up, because you wouldn't be doing the appropriate things at the right time.  Inevitably something messes up in those shows [the target gets back on the elevator to collect a forgotten item], and somehow a message needs to be sent from one party to another to ensure that everyone keeps on track and out of trouble [after seeing a morse code flash from a car mirror at the street level, someone posing as a secretary on the 11th floor distracts the target long enough for the agent to finish his data download].  And of course the communicated signal might have requested "Abort!", but that's not what actually happens, but everything works out in the end.

We have similar problems in healthcare when dealing with workflows.  The problem is really in how we communicate and ensure that the processes of two different organizations involved in a workflow remain synchronized.  Let's look at a sample set of communications in a workflow to produce a laboratory report:

Physician/Order Placer	Lab/Order Filler
I need lipids, an A1C, and a cardiac panel for this patient and sample.
	OK, got it.
	Hey, can you send me a new sample, this one is spoiled.
OK, got it.
Here's a new sample.
	Thanks, got it.
	Tests are in progress.
...	...
How are those tests doing?
	Lipids are in progress.  A1C in progress.  Cardiac Panel completed, awaiting final review.
	Here are the lipids results.
	Here's the A1C results.
I need those results STAT!
	Tests are all done.
	Here's the cardiac panel.
	Tests are all done.
	Here's the cardiac panel again, the results were amended.

As you can see, there are several points where control passes from one system to another in order to complete the workflow, and, in order to remain synched up, the two systems may need to signal each other in some way.  One way is to query for information [e.g., how are those tests doing] to be sure that the current state is recorded (you might have missed a message somewhere).  Another way is to respond to a "request" with an acknowledgement that you have accepted work [OK, got it], or moved it to a new state [Tests are in progress].  Out of band, even though one system might be "in control", another system could assert privileges to regain control (e.g., an out of band message to change priority [I need those results STAT!], or not shown: [Cancel that order]).  And you may tap someone on the shoulder to say, whoops, something changed [Here's the cardiac panel again ...].

The challenge here is that the Test Order as a resource is actually two (or more) information objects. The physicians "Order" resource is managed at the Order Placer system.  The Lab's "Order" resource is managed at the Order Filler system.  These two systems could communicate using their own resources, but then you have to worry about how gets to edit which resource when, and that gets complicated.  Some have suggested that there are two resources: The Request and the Response, and that the request is owned and managed by the placer, and the response by the filler.  All that does is hide the fact that there are two information objects that need to be synchronized, it's simply the whack-a-mole problem.  We hide the complexity over here, and it pops up over there.  Others, like myself are saying: There's one or two resources, and how you use them to manage your workflow depends on how your systems are integrated, and that your "internal" workflow management infrastructure and your "external" workflow management infrastructure could be looking like the same things, but be managed differently.

FHIR needs to support order management workflows in environments where the norm is Choreography [collaborating systems], and in environments where the norm is Orchestration [centrally controlled systems].  

I'm still trying to figure how to address this.  I think the first step is to acknowledge that the step of "Synchronizing our workflows" has to occur, and that some communications may need to be exchanged which may NOT be a full resource.

The real trick in all of this is making sure that whatever the workflow is, it all works out in the end.

   Keith