My August, 3-8, 2015, 7000-word, five-part series on Task and Workflow Interoperability in Healthcare IT News (1, 2, 3, 4, 5) caused a lot of folks to contact me, about how their projects and products help work toward this goal. Thank you all! I’ve seen an interesting mix of effects since, from tweaked healthcare workflow IT marketing campaigns to reconceptualization of product categories (“Hey! We’re a workflow interop product!”) to FHIR proposals to represent task status. I’ve assembled the original five segments into a single blog post below, because each section builds on previous sections (especially workflow interoperability on task interoperability). I’m also adding an outline of links to related material, which I’ll occasionally update. BTW, if you’re interested in the relevance of workflow tech to issues beyond “mere” interoperability, check out my other five-part opus: BPM-based Population Health Management & Care Coordination: Workflow, Usability, Safety & Interoperability Perspectives.
–Chuck
- Achieving Task and Workflow Interoperability in Healthcare
Part 1: Achieving Task and Workflow Interoperability in Healthcare
Part 2: A look at what healthcare task interoperability means
Part 3: Laying down a definition of workflow interoperability
Part 4: Bridging the gap between data and workflow
Part 5: Achieving workflow interoperability among healthcare organizations - Health IT Workflow Integration: Whither #FHIR? (Fast Healthcare Interoperability Resources)
- From Syntactic & Semantic To Pragmatic Interoperability In Healthcare
From the original August 3-8, 2015 Achieving Task and Workflow Interoperability five-part series, combined into a single post….
Interoperability just might be the thorniest problem in healthcare today. And while much of the conversation treats it as if interoperability is one issue, in reality there are different types. In a five-part series, here’s my take on getting where we need to go.
Part 1: Achieving Task and Workflow Interoperability in Healthcare
I’m reminded of the famous first line in Charles Dickens’ A Tale of Two Cities, “It was the best of times, it was the worst of times.” Over the past decade we have spent billions to digitize healthcare, especially at the point-of-care in hospitals and medical clinics. So now we have unprecedented stores of patient data.
Nonetheless, in health IT imagination, healthcare interoperability is deep in Gartner’s Trough of Disillusionment. We need interoperability to leverage these unprecedented resources. What will it take to climb from the Trough of Disillusionment onto the Slope of Enlightenment and then Plateau of Productivity? I will argue task interoperability and workflow interoperability – and both require workflow technology to be done right.
There’s a level of interoperability above data interoperability. This is the workflow interoperability layer. Right now, if all of the data interoperability software works, we get to send some data from one system to another. But the mere ability to send data is not the same as being about to look into the workflows of another organization, and use that knowledge to better coordinate our internal workflow with their internal workflow. Only when we can do this, will we see dramatic improvement in the speed and quality of coordination of everyone and everything needed, so a patient can move seamlessly from home to medical office to hospital to rehabilitation and home again. This missing link is exactly what workflow interoperability provides. We are finally beginning to see the knitting together of separate specialists and organizations, each responsible for different aspects of patient care at different times and places during a patient’s journey.
Ten years ago, at the HIMSS’05 conference in Dallas, I predicted the following:
“EHR workflow management systems will need to coordinate execution of workflow processes among separate but interacting EHR workflow management systems. For example, when a primary care EHR workflow management system (System A) forwards a document (such as a Continuity of Care Record) to a referral specialist, who is also using an EHR workflow management system (System B), System A should expect a referral report back from System B. When it arrives, it needs to be placed in the relevant section in the correct patient chart and the appropriate person needs to be notified (perhaps via an item in a To-Do list). If the expected document does not materialize within a designated interval, System A needs to notify System B that such a document is expected and that the document should be delivered or an explanation provided as to its non-delivery. System B may react automatically or eventually escalate to a human handler. If System B does not respond, System A needs to escalate to a human handler. Interactions among systems, a hierarchy of automated and human handlers, and escalation and expiration schedules will be necessary to achieve seamless coordination among EHR workflow management systems.” (p. 14, EHR Workflow Management Systems in Ambulatory Care, HIMSS’05, February 14, 2005, Dallas)
Ten years ago there was very little task management in EHRs. The situation today is somewhat improved. However, most task management is based on what I call “frozen workflow.” Ideally, users should not only get task management, they should get customizable task management, the workflows for which they can arbitrarily change, and not be hostage to some Java or C# programmer. Furthermore, healthcare IT users need distributed task management, in which workflows span boundaries between healthcare organizations. Healthcare workflows? Cross-organization workflows? Created and edited by non-programmer EHR users? In this, to date, today’s EHR industry has not made much of a dent, if any at all.
The following is my diagram of the “Invoke,” “Monitor,” “Control,” and “Get Result” workflow pattern between a primary care medical practice EHR and a referred to sub-specialist EHR. Note that while “A” and “B” in the above quote refer to EHR systems, “A” and “B” the diagram below refer to tasks within EHR systems.
Figure from Well Understood, Consistently Executed, Adaptively Resilient, and Systematically Improvable EHR Workflow, Healthcare Business Process Management Blog, November, 2009
The key concept I am promoting here is not just tasks being pushed back and forth between healthcare organizations. The key concept is tasks being pushed back and forth according to workflow definitions and business rules under control of non-programmer clinical and administrative users who best know their workflows and rules (plus a dollop of governance to avoid workflows “gone wild”).
More recently, I’ve written about the importance of “pragmatic interoperability” in addition to syntactic and semantic interoperability. Syntactic interoperability is the ability of one EHR to parse (in the high school English class sentence diagram sense) the structure of a clinical message received from another EHR or health IT system (if you are a programmer think: counting HL7’s “|”s and “^”s, AKA “pipes” and “hats”). Semantic interoperability is the ability for that message to mean the same thing to the target EHR as it does to the source EHR or health IT system (think controlled vocabularies such as RxNorm, LOINC, and SNOMED).
Plug-and-play syntactic and semantic interoperability is currently the holy grail of EHR interoperability. We hear less about the next level up: pragmatic interoperability (AKA workflow interoperability).
“Pragmatic interoperability (PI) is the compatibility between the intended versus the actual effect of message exchange.” (Towards Pragmatic Interoperability in the New Enterprise — A Survey of Approaches)
Issues of pragmatic interoperability manifest themselves as issues about coordination among EHR workflows. The most mature technology for implementing pragmatic interoperability is workflow technology.
Sophisticated workflow technology (see my five-part tutorial) is coming to healthcare and health IT. Every year, for the past five years, I search every HIMSS conference exhibitor website for workflow and workflow technology-related words and phrases. The percentage of HIMSS exhibitor websites mentioning, even emphasizing, workflow and workflow technology has doubled every year since 2011, from less than two percent to over a third of HIMSS exhibitor websites. Sophisticated workflow technology is diffusing into healthcare and health IT at a rapid rate. However, in absolute terms, healthcare is a large industry. Many workflow-oblivious legacy EHRs and health IT systems are in place. They won’t be ripped-and-replaced in the foreseeable future. How can we optimally workaround and compensate for these vestiges of health IT past?
The key is workflow interoperability. And a key milestone on the way to workflow interoperability is task interoperability. I’ll delve into that in Part 2 of this series.
Part 2: A look at what healthcare task interoperability means
To truly grasp what the industry is up against, we must understand where we’re trying to go. And task interoperability is a key piece of the puzzle. I describe task interoperability in the second part of my five-part series on task and workflow interoperability.
Workflows are made up of sequences of tasks, consuming resources, and achieving goals. So it makes sense that workflow interoperability requires task interoperability. It’s classic systems engineering. Solve the subproblems (tasks), and then solve the relations among the subproblems (workflow), to solve the problem. I’m reminded of the old saying; how do you eat an elephant? One mouthful at a time!
A task is a “logical unit of work that is carried out as a single whole by one resource” (). In a medical practice, tasks include escorting a patient to their exam room, asking about current medications, conducting a physical exam, collecting a specimen to be sent to a clinical laboratory, sending the specimen to the clinical laboratory, reviewing results from the clinical laboratory, contacting the clinical laboratory because you’ve not yet received the results, and so on … if you are a hospitalist, I’m sure you can easily list a hundred typical hospital tasks.
Task interoperability is visibility, to humans and machines, of tasks and their status, context, and properties from one healthcare organization into another. Status includes such task states as Ready, Assigned, Expired, Forwarded, Finished and so on. Properties are aspects of tasks that don’t change during task and workflow execution. Examples include who or what is qualified to perform a task or prior estimates of cost-per-minute of accomplishing a task. Context includes aspects of tasks that do change, according to, well, workflow context. Examples include who owns a task, who was a task forwarded from and to, in what workflow is a task being accomplished, or from what workflow definition was a task activated.
What does it mean for a task in one healthcare organization to be “visible” in another healthcare organization? That depends on who, or what, is looking. Just as how many data and file formats can be designed to be both machine and human readable, task formats (essentially data about tasks) can be both machine and human readable. A task is visible to a human if they can find, retrieve, read, and make sense of the task description. A task is visible to a machine if the machine can find, retrieve, read, and do something useful with that task description, from displaying it to humans to archiving some information to triggering other tasks.
Task interoperability is impossible unless tasks are represented in the first place. So we have to figure out how to represent tasks, and then find, view, and process these task representations.
Years ago, I took a course in knowledge representation (KR) as part of my MS in Intelligent Systems (Artificial Intelligence). There are many kinds of representations. In this case, a representation is a set of statements about a task. These statements can be added or deleted. KR folks (and computer programmers in general) often speak of properties and values. An apple has a Color property. For a specific apple, the value of the Color property might be Red (or Yellow, or whatever). We pick a specific apple out of a universe of possible apples by assigning a unique identifier, such as “2f39fnv9483h” (I just typed that a random. If I were to refer to a different Apple, I’d need to make sure I don’t accidently use the same identifier, but that is very easy in a computer).
The same goes for healthcare tasks. For a given patient of mine, from behind hospital walls, I’d like to retrieve a list of IDs. (I am of course speaking in the voice of a physician-programmer. Physician-non-programmers just want a list of human-readable descriptions, plus ability to do something useful with them, which is where machine-readable comes in.) Each ID is uniquely associated with a specific enacted task. In the workflow technology world, “enacted” workflow means “executed” workflow. It is analogous to the difference between an unexecuted computer program versus the thread of execution of that program while being executed. Workflow definitions are like the former. Enacted workflows and tasks are like the later.
Once I have a list of task IDs, for each ID, I’d like to access whatever context and property values are relevant to my current goals. For example, I’d like to see a list of sensible (to me) names of clinical tasks. These names could simply be strings stored in each clinical task’s Name or Description property. Another task aspect I’d be interested in, at least for some tasks, would be Status. Show me all the completed tasks for my patient. Then for some of those completed tasks, show me patient data relevant to the tasks, such as data generated during accomplishment of the task. An example might be a clinical lab result or radiological image interpretation. Remember, I am just using these workflows as illustrations. I am not called for particular workflows to become standard workflows. What I am calling for is your ability to create and modify whatever workflow you need to do your job most effectively, efficiently, flexibly and enjoyably.
The layer of task representation is essentially part of a navigational user interface. Instead of a clinician interacting directly with the underlying data, clinical task status, context, and properties are used to find, filter, and interpret data. Assume I work for a health insurance company. I might be interested in tasks that are ready, but not yet assigned, to make sure they are covered before they assigned. Assume I am a hospital management engineer. I’d be interested in time-stamps, for purposes of spotting bottlenecks and rework. Data associated with tasks is a goldmine, not just for users within a healthcare organization, but users in other healthcare organizations too.
Health IT is on the cusp of beginning to implement task interoperability. Startups are beginning to monitor and route care transition events. These are tasks at the boundaries of health organizations, such as hospital admission and discharge. However, there are many other tasks behind the walls of hospitals and other healthcare organizations. Folks say to me, what do I care about what goes inside someone else’s healthcare workflow black box? To which I reply, you should. Providers need to better understand health plan payer internal workflows. Health insurers need to better understand provider workflows. And both need to better understand patient workflows, AKA life-flows. In fact, across many industries a trend is to make enterprise tasks, workflows, and processes more transparent, to make them visible to external customers and partners, using social, mobile, and cloud technologies, and then to systematically improve customer experience with analytics.
The trend toward explicitly representing, manipulating, and sharing clinical tasks, and using these representations to automatically trigger valuable human and machine workflows is beginning to take off inside healthcare organizations. These lightweight, mobile and (secure) social-like apps get data from older systems, including EHRs, and get data from human users, because these users get value back from entering and sharing clinical task data. Given that changes in admission and discharge task statuses are beginning to be shared, we are just a step or two away from sharing other tasks deeper within healthcare organizations.
An obvious place to represent healthcare tasks is in some future version of FHIR (Fast Healthcare Interoperability Resources). However, for purpose of this happy path into a future of workflow interoperability, I’ll abstract away from specific transport and data standards. The technology is already here, (a variety of web service technologies and data formats) to create task interoperability. In other words, don’t wait for a standard. As a practical matter, I’d rather deal with a half a dozen well-designed and well-documented healthcare task APIs (Application Programming Interfaces) than wait for some future health IT task standard promising nirvana. If your APIs generate value, someone will come along and aggregate them anyway. That said, keep an eye on any nascent healthcare task interoperability standard. The discussions and communities of practice can be excellent educational and networking resources.
This five-part series could have been titled “Getting To Task Interoperability And Then From There To Workflow Interoperability: Healthcare Workflow Silos Unite!” but that would have simply too unwieldy. We just covered, “Getting To Task Interoperability.” Now we need to cover, “Getting To Workflow Interoperability.”
In the next installment, I’ll dive deep into workflow interoperability.
Part 3: Laying down a definition of workflow interoperability
Building on data and task interoperability, healthcare will finally be able to get to workflow interoperability. In the third part of my five-part series, here’s a look at what that means.
You can think of a workflow system (an informal phrase I use that includes Business Process Management, or BPM) as a collection of tasks and these tasks having states: pending, started, postponed, reassigned, escalated, cancelled, completed, etc. When a task is completed, other tasks may be automatically started, assigned to users, or roles (collections of user, anyone which can complete the task). Moment-by-moment all tasks and all task states can be displayed. If you’ve never used a workflow system, you have no idea how valuable such a display is to preventing even the possibility of someone dropping the ball, so to speak, with the result of a languishing task (and an increasingly pissed-off customer).
Workflow interoperability is visibility, to humans and machines, of task relationships, plus context and properties, across healthcare organization boundaries. Just as healthcare task interoperability is not possible without representing tasks, healthcare workflow interoperability is not possible without representing workflow (relationships among tasks).
Consider, for example, my earlier diagram of several tasks being delegated from a primary care clinic to a subspecialist. The relationships are the lines between the lettered tasks. I uncluttered the workflow diagram a bit. First of all, I’m using letters instead of clinical task descriptions. A and F could be “Refer to specialist” and “Receive results from specialist.” You’ll also sometimes see arrows instead of just lines. In this case all the arrows would have been downward, so I eliminated them. The workflow diagram illustrates the four most basic workflow primitive patterns: sequence (F to G), parallel split (A to B and D) or choice (A to B or D), and join or merge (C and E to F). Terminology varies. But you get the idea. These are the DNA bits out of which more complex workflows are constructed.
Recall, in Part 2, when I distinguished between task properties and task context? Similarly, some relationships among tasks don’t change, but some do change. The relationships among tasks that don’t change, except when users intentionally change them, are part of workflow definitions. The relationships among tasks that change? They occur when workflow definitions are executed, and come into contact with the real world. Users cancel tasks. They add tasks. These tasks have temporary relationships with other tasks in the currently “enacted” workflow.
Workflow diagrams are used informally throughout healthcare, though they are often called flowcharts. The difference, between these diagrams on napkins or in Visio and a workflow diagram in the workflow technology world, is that a workflow diagram is actually an executable program controlling automated workflow behavior. Of course, you need a more information, such as which users or roles can accomplish which tasks, and what workflow screen or form is to be pushed onto their worklist (often called a To-Do List). Also, there are business rules, to determine, for example, when to escalate and to who, and, when you come to a split, which path to take, for example, A, B, C, F, G versus A, D, E, F, G. Furthermore, some case management systems represent work in other ways besides workflow diagrams. But to keep it simple, in this necessarily tutorial series, I’ll stick with the simple workflow diagram I introduced in Part 1 of this series.
Workflow engines executing workflow definitions powerfully influence health information system usability. They not only intelligently forward tasks to the right person (and follow up to make sure tasks are completed), but also automatically navigate among screens for a single user. The effect is a bit like most software installation wizards: Next, Next, Next…, OK, OK, OK…. Of course, users are free to jump off automated workflow happy paths at any point. A “happy path” is what’s supposed to happen, barring the unexpected, when you use a software application. Uncompleted tasks hang around, visible to someone on a To-Do list, or eventually escalated according to previously user-designed business rules.
Suppose you are a precocious user. Let’s say you want to add a screen or screenless step (such as check for and download a lab result). Instead of calling your EHR vendor to request the change in workflow, you just pop open that visual workflow editor and drag-and-drop new step H into the workflow diagram. Then you double-click and edit a business rule. Pop back into the application; you just changed the workflow of your EHR to a workflow you prefer. In fact, one of my popular posts is my Litmus Test for Detecting Frozen EHR Workflow. Ask the sales gal or guy to show you the workflow you just observed in a workflow editor, delete a step, and then observe the demo of the edited workflow again. If that task step is now missing from the workflow, then there must be a workflow engine executing (“enacting”) the workflow you just ask to be edited.
Workflow interoperability? Some tasks in a single workflow diagram might be in one healthcare organization and some might be in another healthcare organization (D+ and E+ in the previous workflow diagram). This is exactly the picture I painted ten years ago. Instead of my getting an alert when my patient discharged, how about my getting an alert when the X-ray is read? Or when an important result from clinical pathology comes back. (If I chose to get the alert… I’m free to edit the workflow definition on my side of the organizational divide.) Just as in a medical practice, where it is more efficient to begin to assemble a vaccination tray when the vaccination is ordered, not when told to do so after the physician leaves the exam room, there are workflows external to an organization we’d like to kickoff when a task changes status within an organizational workflow. Someday non-programmer super users and clinical and business analysts will design these cross-organizational healthcare workflows by dragging, dropping, and configuring graphical icons in visual workflow editors. (Though, one should note, workflow editors don’t always look like flowcharts. Sometimes they look and work more like user-configurable templates or checklists.)
In fact, how about me being able to not just see into a workflow’s past, but also into its future. For me to see not just started or completed healthcare tasks, but future intended tasks as well, I need not just healthcare task interoperability but healthcare workflow interoperability as well. I need to pull over the entire workflow definition, so I can look along the workflow happy path to see which other tasks are likely to be started and accomplished. In other words, we need healthcare workflow interoperability not just to automatically kick off tasks in other organizations, we need the representations (that word again) of workflow to allow us to follow along and understand the intentions and goals of our partner healthcare organizations.
I often claim, as important as open source and open data are, open workflow is even more important. Open workflows are “figuroutable” and “buildonable” in ways that open source and open data are not. Non-programmers can read and modify workflow definitions, to design changes in workflow, in ways that they cannot accomplish pouring through traditional open source code. Being able to look into another healthcare organization’s workflows, and then use those workflows to drive workflows in your healthcare organization, releases all kinds of creative possibilities and problem solving.
Similarly, data is static and tactical. Workflow is dynamic and strategic. Let me see the data pipelines giving rise to data. Let me tap into those pipelines wherever I wish. Maybe you’re doing something with the data in the last step I don’t understand, or, if I did understand, might wish to do differently. Give me access to the workflow generating the data, and I’ll create my own hybrid pipeline, better serving my idiosyncratic needs and purposes. By the way, open workflow is relevant to the patient data ownership debate. Patients won’t truly “own” their data until they (or agents acting on their behalf) control the workflows generating their data.
That’s what workflow interoperability in healthcare means – my next two parts in this series will explain how to make it happen.
Part 4: Bridging the gap between data and workflow
The health IT industry has a second chance at building process-aware health information systems, if we proceed carefully and in the right manner. In this, the fourth part of my five-part series, are my suggestions on making workflow interoperability happen.
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 represent task and workflow state, workflow platforms will have to compensate and provide these missing pieces of the workflow interoperability puzzle.
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.
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.
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.
Part 5: Achieving workflow interoperability among healthcare organizations
Now that we have laid the groundwork in parts 1 through 4, let’s look ahead, about five years into the future. How will a new generation of workflow platforms pull all the pieces together, to get to true healthcare workflow interoperability?
We will see a plethora of clinically- and patient-oriented workflow platforms. Many have already obtained considerable investment and beginning to expand their market footprints. It’s early days yet. But, within five years we’ll see as much, or more, about facilitating workflow at the point-of-care and point-of-health as the emphasis on population health and patient engagement at the recent HIMSS conference in Chicago. In fact, population health and patient engagement are playing critical roles in driving adoption of process-aware workflow technologies in healthcare. If you drill down through the layers of technology necessary to do both, efficiently, effectively, and flexibly at scale, you’ll invariably find some form of workflow orchestration engine. In some cases these will be based on third-party business process management suites. In some cases the workflow engines will be proprietary. It’s often hard to tell which is which, since many vendors do not wish to reveal they are relying on an embedded third-party product.
Regardless of whether you use a full-fledged pure-play BPM platform or a homegrown health IT workflow platform, look for the workflow engine under the hood. It will buy you speed (throughput, patient volume), transparency (ability to track all tasks at all times, letting none fall between the cracks), and flexibility to systematically improve intra- and inter-organizational workflows.
When you strip away all the fancy words and acronyms, we are talking about To-Do lists. Putting To-Do items on To-Do lists and letting staff know about them is what workflow systems do very well. They were the reason workflow management systems were invented several decades ago. They’ve had several decades to improve. To-Do lists help human figure out what to do next, and tell automated systems what to do next, within organizations and, increasingly, across organizational boundaries.
Workflow management systems (now business process management and adaptive case management systems), have literally been around for over two decades. Workflow technology evolved quickly since I wrote that earlier passage (in Part 1 of this series) reflecting back to ten years ago. Within the BPM industry, there are healthy debates about automating structured and routine workflows versus unstructured and ad-hoc workflows (using ACM, for adaptive case management, also called dynamic case management). Workflow analytics, especially process mining, came from BPM research, but can be used to substantially improve workflows of even systems without classic workflow engines. BPM thought leaders talk about “empathic workflow” in which backend enterprise processes and customer journey maps are reimagined and then quickly implemented and systematically improved. I know both BPM and ACM pretty well, for a health IT guy. I’ve been a judge for both the BPM and ACM annual awards for years. I encourage EHR and health IT vendors to apply for one or both of those top awards in the workflow technology industry today.
A wide variety of entrepreneurs and intrapreneurial healthcare organizations are putting down a new layer of workflow technology on top of an existing layer of data technology. The difference between data technology and workflow technology is key. Most current healthcare data that health IT manages is about patients, not about processes and workflows. Makes sense, for individual patients, healthcare staff and patients need to keep track of symptoms, diagnoses, prescriptions, and so on. This data is about patients.
We need more than data about patients. Real value resides in information about workflows creating patient data. We need data about workflows involved in using patient data, in real-time, to trigger workflows influencing patient and provider behaviors. Then we need data about those workflows. To systematically improve effectiveness, efficiency, and user and patient experience, we need to, and will, collect data not just about patients, but also about workflows serving patients and providers. Much of this will be delivered via modern mobile, cloud, and analytics platforms. Under the hoods of many of these systems? Workflow engines.
A word is due here about security. I am sure that when I speak of “visibility” of tasks and workflows across organizational boundaries, red flags must go up in some minds. What with all the recent high-profile breaches of sensitive patient data, how can we possibly contemplate making internal healthcare information even more visible to outside organizations? Process-aware workflow technology, within and across healthcare organizations, can be substantially more secure than what we currently have in place. First, modern BPM application platforms have an extra layer of security (against which workflow app developers develop) implemented by professionals who understand security well. Second, knowing an event takes place, or typically takes place, is not the same as knowing the patient data resulting from the event. We get notifications all the time that something interesting just happened. We then have to authenticate ourselves to get the details. Third, need-to-know access control to patient data is can be more finely grained. It can be granted at the beginning of a specific step in a workflow, than then revoked when the step is completed. Fourth, workflow platforms log much more comprehensive and detailed data about who looked at what, when, and in what context. Finally, knowledge of the workflow of how another organization handles data you send to them is important to you in making critical judgments about whether you can trust that organization.
Terminology (not just technology) is in flux. These new systems could be called Care Management Systems. Other names include Care Coordination Platforms or Healthcare or Care Process Management systems. This is a layer on top of EHRs and other health IT systems explicitly intended to coordinate care across providers, track patient events, and manage task handoffs among providers. It is a classic scenario for workflow technology, already being used to coordinate lots of things we consumers take for granted these days, from Amazon to Google Now to systems we don’t even know the names for, but just invisibly work. In fact, I don’t see these workflow systems as separate from or leveraging healthcare interoperability. They will be workflow interoperability.
Workflow interoperability is coming to healthcare and health IT whether we like it or not (and there will be some legacy laggards who won’t). Other industries are a half-generation ahead of health IT in adopting workflow management systems, business process management and adaptive case management systems. It is a natural and desirable progression of software application architectures: taking data out of applications into databases, user interfaces out of applications into operating systems, and, now, taking workflow out of applications into process-aware workflow orchestration systems. Health IT will not be an exception to this general pattern. However, as a community, of workflowistas, health IT and BPM professionals, we can accelerate the change needed to get to task interoperability and workflow interoperability. The key will be entrepreneurs (and intrapreneurs) seeing and grasping the opportunity. There’s a lot of money to be made (or saved) in displacing (or compensating for) workflow-oblivious legacy health IT infrastructure.
By the way, there is no small role for health IT social media to palaver, kibitz, and egg on these healthcare workflow entrepreneurs and intrapreneurs.
