The health IT market is in a transition period, from extremely data-centric systems toward more customizable workflow-centric systems. By "data-centric" I mean essentially structured databases plus graphical user interfaces. Users still have to figure out what to do next, hunt around to find the relevant data, and then further navigate around in order to enter data and orders. By "workflow-centric" I mean systems proactively pulling and pushing data and tasks to users, according to customizable templates and workflow models. This is a nascent trend. But it is growing quickly.
Investors view this trend as a way to unlock the value of the tremendous amount of data contained within tens of billions of dollars of recently installed hospital and ambulatory clinical information systems. This trend favors modular solutions, since the workflow technology can be used to "glue" modular functionality together. It's been referred to as a "spider in the web" for its ability to connect disparate systems and technologies together (more below). However, large enterprise hospital vendors have considerable leverage; they have more money and more data. They are opening "app stores" to provide access to their data, but on their own terms, as they seek to control health IT market evolution. There's even a workflow interoperability angle here. Workflow technology will be ideal for gluing together the apps in this app stores, into useful and customizable sequences of task-accomplishing apps.
A technology currently touted as a means to integrate systems together is FHIR, for Fast Healthcare Interoperability Resources. In a couple years we'll see standalone apps accessing data in from these data-centric systems. Some of these apps will be embedded into EHR user interfaces (such as for calculating pediatric doses or specialize drug interactions). FHIR will also be used by more workflow-centric care management systems, which you can think of as a layer on top of individual data-centric systems. These workflow-centric systems will increasingly coordinate care across providers, track patient events, and management handoffs. However, until FHIR can also push data to IT systems, and represent task and workflow state, workflow platforms will have to compensate and provide these missing pieces of the workflow interoperability puzzle.
[Part 3: Laying down a definition of workflow interoperability.]
To the degree we surround healthcare organizations with process-aware health information systems, process-aware technologies will inevitably seep across and into these healthcare organizations. If we use workflow technology to effect workflow interoperability among healthcare organizations, they will begin to leverage task and workflow representations within their borders with workflow technology. I'm reminded of a recent conversation with a hospital IT executive. He needed a Business Process Management engine to maximally leverage interoperability with his local Health Information Exchange, because it had a BPM engine.
I started this five-part series by quoting myself, from ten years ago. I described a conversation between two EHR workflow management systems, one for primary care, and the other for a subspecialty. Much has changed in ten years, but EHRs still won't be conversing with each other any time soon. They're essentially databases with user interfaces. They can't converse because they don't represent and execute the workflows necessary to converse. Some layer of process-aware technology must speak for them.
Let's take a look at one of my favorite descriptions of interoperability.
"An organization with a high level of interoperability is characterized as being able to work with other organizations in a unified or enterprise way to maximize the benefits of collaboration across organizations and across multiple ... investments or projects ... networks" (Existing Interoperability Maturity Models, Center for Technology in Government)
This definition of mature interoperability is about workflow, process, orchestration, and collaboration. It's about workflow interoperability in the sense as I describe in Part 3 of this series. These are exactly the concepts missing from today's data-centric discussions of healthcare interoperability.
What are the technologies that will get us to unified maximum enterprise collaboration across healthcare organizations?
Bridging the gap between data and workflow has been health IT's greatest challenge to date, though I don't think this is widely appreciated yet. Over the next five years we will see an evolution of internal healthcare organization IT systems toward support of essentially two parallel, complementary, interacting platforms, one for data and the other for workflows. Data integration platforms will face legacy and new data sinks and sources. Workflow integration platforms will face users, including patients, to provide seamless workflow user experience.
Healthcare interface engines were early adopters of process-aware technology, which they use to implement data flows. Visual editors of data workflows make programmer's lives easier. Increasingly, we'll see these vendors also begin to add user-facing applications and intelligent task management.
[Part 2: A look at what healthcare task interoperability means.]
The more unusual advice I will give is to adopt workflow application development platforms. Traditionally this space has been called Business Process Management (BPM) and, earlier, workflow management systems. This technology is just starting to diffuse into the health IT industry, but at an increasingly accelerating rate. This is the technology to allow your limited development staff to not only more quickly spin up desktop and mobile apps, connected to your data systems and platform, but also provide an integrated task management experience for your users.
A welcomed byproduct of adopting BPM technology, besides laying a foundation for workflow interoperability, is that it is a "low-code" approach to application development. Healthcare has long been stuck between a rock and a hard place, when it comes to products and services based on information technology. Either you buy prepackaged software from someone who promises to solve your problems, or you hire programmers to create new applications from scratch. In the former instance, you're stuck with whatever rate of innovation and compatibility your vendor allows you. In the later case, you create exactly what you need, but only at great expense. And then, when requirements change, it costs an arm and a leg, to modify, if it can even be substantially modified at all.
"Low-code" application development is a very different story. It's not buying someone else's preexisting software and it's not writing software yourself using a third generation language such as Java, C#, etc. (both of which I love, don't get me wrong). It's creating exactly the custom workflow-smart/work-smart workflow application you need, without having to literally "write" computer code, so you can create and change quickly. As I already pointed out, healthcare interface engines were early adopter of process-aware technology. Interface engines and workflow engines have a lot in common, except one faces data sources and sinks, while the other faces users and applications.
Converse to healthcare interface engines, BPM suites are adding adaptors and plugins and means to manage data flows. Abilities to consume a variety of web services (such as FHIR-based APIs) have been standard functionality for years. A particularly relevant manifestation is data virtualization. Instead of defining workflows directly against a heterogeneous mixture of data systems, the data in harmonized and made visible to the workflows being designed and executed. In turn, some of these systems are exposing not just their internal task, task list, and workflow state, but also this harmonized data. So you can see that healthcare interface engines and business process management suites are, in a sense, heading toward some of the same territory.
[Part 1: Achieving task and workflow interoperability in healthcare.]
Particularly important to task and workflow interoperability is ability of workflow platforms to expose task, task list, workflow state, and related to information, to other applications via APIs (Application Programming Interfaces). If you use a third-party BPM platform (to tie together internal data sources and workflows, as many enterprises are doing), be sure to investigate whether it has both an outward-bound API for exposing data and workflows, as well as an inward-bound API for pushing data and triggering workflows. Workflow management and business process management systems will be key technologies for achieving task and workflow interoperability.
"WFM/BPM systems are often the 'spider in the web' connecting different technologies. For example, the BPM system invokes applications to execute particular tasks, stores process-related information in a database, and integrates different legacy and web-based systems." (Business Process Management: A Comprehensive Survey)
The key to success will be integrating data and workflow, through use of both more-or-less traditional healthcare data integration technologies, but also newer workflow management and integration technologies. You need to think about how best to create and evolve a fast, flexible, and transparent backbone of data and workflow services, on which to hang and manage current and future systems.
In my next and last part of my five-part series on task and workflow interoperability, I'll tie up some loose ends and make some predictions.
