And then Magic Happens

Engineers do this all the time.  We make some simplifying assumptions about how a design will work, so that we can then focus on other more important stuff.  Sometimes these simplifying assumptions are well understood, and sometimes they presuppose some things that have yet to be proven.  This is what I'm referring to in the title.  It's those simplifying assumptions where "magic [science as yet insuffuciently explained] happens".

In discussing FHIR workflows in Q3 and Q4 today at the HL7WGM, I described some of the simplifying assumptions about how communication would be syncronized between a sender and a receiver, asserting without showing the proof, that there were several ways these systems could be synchronized without having to worry about the exact details.

Grahame balked (rightly so, as we do have to explain this to our readers at some point), and he wasn't convinced that I was right.  He could figure it out quite well on his own, but I'm the one making the assertions, so it is fitting that I prove it.

So, here are the assumptions and assertions:

1. There are three actors: A sender (which could be an Order Filler or Order Placer) as system tracking tasks which I'll call workflow, and a receiver (which could be an Order Placer or an Order Filler).
2. The sender can create or update  a resource (the general pattern is the same, the only difference is between PUT and POST), and as a result of that create or update, the receiver can be seen to eventually act upon it within a reasonable time period ensuring synchronization at some granularity of time units.

So basically, this is what we want to ensure is present in all cases:

There are three ways to do this that I covered:

1. Polling
2. Subscriptions
3. Grouping (Receiver and Workflow system are part of the same system)

Polling

Polling looks like this, with the polling system periodically making a query for tasks of interest (in this case, tasks assigned to the polling system), and acting on received results:

Not shown here but which may need to be accounted for:

Time should be synchronized for all systems (so _lastUpdated query works).

The receiver should recognize when a bundle contains a [specific version of a] Task resource it has already acted upon, and not act upon it again.

Subscription

Polling is slow and inefficient in some cases.  Some systems would rather be notified using subscriptions.  That would look like this (note: I didn't go into details about the four different kinds of subscription channels which could be supported):

In some cases, subscriptions are really just a tap on the shoulder that you need to ask for data, and in other cases the data is already presented to you in the subscription communication channel.  So that middle GET on the bottom right might not be necessary.  Again:

Time should be synchronized for all systems (so _lastUpdated query works).

The receiver should recognize when a bundle contains a [specific version of a] Task resource it has already acted upon, and not act upon it again.

Grouped

Finally there is grouping the workflow system with the intended receiver.  In this case, you can simply treat it as if there was a magical subscription present.  You don't need to seen information back and forth because it is already there:

This is the simplest of the three cases, and might be the preferred implementation for simple workflows where you "post something" and it just magically happens.  In this case, it is additional, unspecified by FHIR logic in the server, which simply ensures that tasks are processed.

In this example, you can ignore time synchronization and logic to avoid reprocessing a task, since it won't get messed up that way (although I'm sure someone will figure out how to do that anyway).

As you can see in all of the above, the preconditions and postconditions are reasonably met in a couple of different ways.  Hopefully this addresses some of the concerns raised about how the "magic happens."

    -- Keith