FHIR, Process-Aware Orchestration & Choreography, and Task & Workflow Interoperability

This week’s #HITsm tweetchat (with ) is about FHIR (Fast Healthcare Interoperability Resources) & APIs (Application Programming Interfaces), prompting this blog post. (I often write pre-tweetchat blog posts about subjects in which I am especially interested.) Obviously, FHIR can facilitate health IT workflow by making patient data more accessible. But this blog post is about more than that. It is about representing, creating, transmitting, and leveraging patient task and workflow data through use of workflow technologies such as workflow management systems, business process management, workflow engines, and task management systems. All of these are coming together to create a new layer of task- and workflow-centric care management software leveraging a wide variety of EHR and health IT data sources and sinks.

August 3-7, 2015, in a five-part, 7000-word series (1, 2, 3, 4, 5) that appeared in Healthcare IT News, I outlined what I believe is the first comprehensive framework for Task and Workflow Interoperability in Healthcare (consolidated here). In that series I made a number of suggestions and predictions, some relating to FHIR and task and workflow interoperability. At least one suggestion, representing clinical task status, has indeed been taken up in FHIR online discussions. I’m also interested in seeing what role FHIR will play regarding workflow interoperability. (BTW, if you are interested in the science behind Task and Workflow Interoperability, check out my 2014 post on Pragmatic Interoperability. It had great reviews, which I appended to the beginning of the post.)

Before and after my Task and Workflow Interoperability series, I’ve badgered FHIR folks with questions about workflow. In May I asked the following questions.

I’ll break out these questions here, since they are still on target.

  • Q. Do you see an opportunity to access workflow state (started, which tasks complete, which pending, all that classic workflow engine stuff) via FHIR?
  • Q. Ex: Patient encounter is a series of steps. Which are pending, started, complete, cancelled, postponed, reassigned, escalated, restarted & associated resource info.
  • Q. Of course, to know to query a task’s status, one needs to be able to query what tasks are in the first place < possible future evolution of workflow representations?
  • Q. (In response to suggestion to look at the Encounter resource and Encounter State element…) I see 6 codes, is this extensible? Second, are there task resource, & can those have status (extensible?)
  • Q. In other words, Encounter is bring treated as one big task, w/task status, are there more granular representations of collections of tasks making up an encounter?
  • Q. Do you [think there is an potentially] useful synergy btwn FHIR & the Cross-Enterprise Document Workflow XDW effort?

In May I suggested FHIR-W (for FHIR-Workflow).

In June I suggested adding clinical task status to FHIR.

So of course I’m not going to miss an opportunity to continue stirring this pot. There are many reasons for, and avenues to, use of more workflow technology in healthcare — usability, productivity, safety — to which we can add interoperability. For example, see my ten questions about FHIR, workflow, and workflow technology (BPM and related). For each of this week’s FHIR/API questions, I’ve adapted my answer to the context I described above. In many cases, I answer a question with a question, though I’m sure you’ll be able detect some of my opinion shining through. 🙂

Topic 1: Are you currently using #FHIR &/or #SMARTonFHIR in production? If so, how? If not, when? #HITsm

My concerns about #FHIR in practical use regard whether plug-in apps retard or facilitate EHR and health IT workflow. Workflows are essentially hardcoded (“hardwired”) into EHRs. Technically, being able access a SMART/FHIR app within EHR workflow, for example, is less arduous than having to switch to a separate standalone app. But it’s still a far cry from the flexible, automatic, transparent, and systematically workflows EHR users need.

So, how will FHIR participate in, and perhaps support, the kinds of orchestrated and choreographed workflows that modern workflow technology brings to the health IT interoperability table? For more on workflow orchestration and choreography, see my Dec 3, 2015, webinar, Wellness Through Workflow.

orch2

That said, if we begin to encode task and workflow status into FHIR perhaps we can begin to see a path for diffusion of “process-aware” technology into our current, mostly workflow-obvious systems. I suspect this is an extremely open question. On one hand, if FHIR encodes this information, some systems under development (especially workflow-centric care management systems implemented on top of current data-centric EHR systems) will likely leverage these task and workflow interoperability resources. On the other hand, I’d not like to see FHIR participate in essentially another layer of hardcoded workflow. (See Topic 3, below, regarding this possibility.)

Here are some of my tweets on this subject.

Topic 2: When do you expect #FHIR-based #API ecosystem to be relevant for app developers? Why? #HITsm

When it comes to FHIR I’m on the outside looking in (though I’ve used web services for a variety of purposes). This is why I tend to answer questions about FHIR with related questions about workflow and workflow technology. However, I will point out that task and workflow interoperability need not wait for FHIR. At a strategic level, task and workflow interoperability is *not* about data standards for representing task and workflow status. It is about what academics call “process-aware” information system architectures. Common nomenclature for PAISs includes workflow systems, workflow management system, and business process management. (Though, it must be pointed out, process-awareness is not limited only to these classic application types. Any information system relying on some sort of model of work or workflow, to reason about what needs to happen next to help users do their jobs, are examples of process-aware workflow technology.)

In fact, when I’ve brought up the issue of workflow interoperability with experts and thought leaders in the BPM and workflow tech industry, their reaction has been quite interesting. Yes, they admit they could use more useful task, workflow, and process model-related data standards. However, in almost the same breath they say that BPM and related tech is already intrinsically and architecturally about knitting together workflows among disparate systems and technology. Most modern BPM systems already expose task and workflow design and status through APIs. This is why I argue not to wait for FHIR to “solve” task and workflow interoperability. BPM has already been characterized by a top BPM expert as the “spider in the web” in that it already is used to knit together workflows from disparate systems based on disparate technologies. While FHIR, in healthcare, may come to play an important supporting role here, it’s a mistake to wait for FHIR-capable (heaven forbid Meaningful Use FHIR certified) systems before tackling task and workflow interoperability.

This is, in fact, already happening anyway. Since I published that the Task and Workflow Interoperability series, I’ve been contacted by many individuals and representatives who are doing just this, creating task and workflow interoperable care management systems, without FHIR. (That said, they are tracking FHIR, and will/would/might likely adopt. The point I’m making is that the secret sauce is more in their process-aware architectures, than in a future task and workflow interoperability data standard.)

Topic 3: #MU3 #Ed2015Cert allows proprietary #API to meet cert requirements. How can we ensure interoperable #API for #MU3? #HITsm

How do we prevent Meaningful Use API interoperability mandates from doing to API developer interface usability what Meaningful Use already did to EHR user interface (and workflow) usability?

Topic 4: What novel things can you do with #FHIR & #API in #healthcare that you couldn’t do before? Why? #HITsm

I am optimistic about implications of FHIR for task and workflow interoperability. However I urge a nuanced reading of the task and workflow lack of interoperability situation in which healthcare still finds itself. Simply creating data standards representing task and workflow status will be insufficient to achieving widespread task and workflow interoperability. When it comes to task and workflow interoperability, the fundamental issues are architectural, not representational. Nonetheless, if we increasingly represent more sophisticated concepts of task and workflow in data standards (and not just within FHIR) this is part of a progressive, advancing front of process-aware workflow technology into our healthcare IT industry landscape.

We will, I hope, see two converging trends. On one hand, FHIR-capable health IT systems, including EHRs, will evolve into more process-aware workflow platforms. On the other hand, already sophisticated workflow platforms, especially from the business process management space, will add FHIR to their considerable portfolio of data adaptors (already including a wide variety of web service technologies).

Both are good things!


On Periscope!

warefloblab3

Leave a Reply