Towards a FHIR-based workflow model

Earlier this week I talked about differing views of workflow.  We discussed this today on our call to further the BPMN white paper. There are a couple of good posts in that discussion, so I'll start with the first part, and follow up on Monday with what we produced.

Bascially, with the Workflow Document in XDW, we have a very good view of what is happening to a patient.  It shows all the different kinds of participants in the workflow, the tasks that they are engaged in, and how the workflow is proceeding for that patient.  Now, if we stack all these instances in a pile, and look at a side view, we get a different perspective.

In this view, all the participants in the workflow line up vertically by type of participant.  And different instances of a participant type might be involved in different workflows, as you can see to the left here.

You could sort the participant work by task (as each participant might be involved in different tasks), and by participant instance, producing yet another view.  This view becomes a task queue, where you could have multiple tasks of the same type being able to be viewed all at once, or filtered by the participant assigned to them.

The two standards we were discussing in the IHE Radiology meetings on Remote Read, XDW and Unified Procedure Step - RESTful Services (UPS-RS), excel at two different views.  XDW excels at the patient-centric view, and UPS-RS excels at a worklist-centric view.

What I think is needed over the longer term is a standard that supports both viewpoints.  XDW is a great start for this.  I did a technical evaluation comparing UPS-RS to XDW a while back, and we did a similar evaluation in IHE Radiology, with the end result that from a data perspective, both UPS-RS and XDW contain all of the necessary data to manage the workflow.  There are some things that UPS-RS does better especially for Radiology, and some that XDW does better, but for the most part, the two are equal.

Developing new standards is not something that IHE does.  For that, I'd look to HL7, and specifically FHIR.  What I would like to do is propose a couple of new resources for the next round of FHIR work (DSTU 3), which would support workflow management.  The Workflow Resource would support collecting a bunch of tasks, and referencing a workflow definition, a patient, and an owner or manager of the workflow instance.

This would overcome some of the challenges we have in XDW today.  Most workflow document updates are simply to add a task, and leave the workflow metadata itself otherwise unchanged. Replacing an entire document to accomplish this is cumbersome.  The benefit that FHIR provides here is that the Workflow resource and all of its task resources can be separately managed with separate states and histories.  This provides a patient-centric view of a single workflow instance, a population view over a variety of instances (which I haven't mentioned thus far), and a task-centric view of tasks.

Problem solved... Not really, now I need to propose the work, and get it accepted through HL7, and then we need to profile this to make it work across the health care continuum.  Monday I'll be talking about how these different pieces could fit together.  What I'm proposing here is a better way to do what XDW does, and it will take some time to get it done.  Hopefully, I can get HL7 to start on the standards side of this in time for IHE to begin work on the other half.

I'm certain some people will be unhappy about a proposal to change or update XDW, but in my own opinion, I think this would be a great way to move workflow forward.  It's just going to take some time.  I'm happy to move this forward at Internet speeds, but what I will very much try to avoid is to move it forward at ONC's preferred speed (yesterday).

   Keith