This is Part 5 in a five-part series on Task-Workflow Pragmatic Interoperability. Feel free to read parts 1, 2, 3, and 4 before Part 5. Thank you to Health Standards for hosting this five-post, 10,000-word series about healthcare interoperability the week before HIMSS16. Fittingly, they were inspired by blog post about a Health Standards #HITsm tweet chat. Help me (@wareFLO, a HIMSS Social Media Ambassador) spread the Task-Workflow Pragmatic Interoperability word at #HIMSS16 by using the #HIMSSworkflow hashtag!
The benefits of workflow interoperability between organizations are the same as the benefits of workflow technology within organizations. Without interoperability these only accrue within the borders of a single healthcare organization. With workflow interoperability these benefits span between healthcare organizations, creating virtual healthcare organizations from multiple separate healthcare organizations. These benefits of task-workflow pragmatic interoperability are essential for creating learning healthcare organizations. The four main benefits are:
- workflow automaticity,
- workflow transparency,
- workflow flexibility, and
- workflow improvability.
The number one advantage of task and workflow interoperability is automaticity. Can events in one healthcare organization automatically, without, or at least with minimal human intervention during workflow execution, automatically cause events in another healthcare organization? Automatically triggering workflow, inside or between healthcare organizations requires some form of workflow engine, also sometimes called a process or orchestration engine. If you look around most well run healthcare organizations, you will see a lot of human workflow engines. Sometimes they are care coordinator, sometimes a nurse interacting with multiple systems, or sometimes even a medical scribe.
These personnel are essentially performing as intelligent workflow engines. When one human workflow engine in one healthcare organization coordinates care with another human workflow engine in another healthcare organization, we are talking task-workflow interoperability. We need to understand what they are doing and help them do it even better. The key will be mapping their workflows, encoding them as explicit representations of the workflow they facilitate. Depending on how complex and sophisticated the representation of the events triggering workflow, we are may be speaking of complex event processing (where the real-time data is available we need fast workflow triggers). You’ll also see event-driven BPM used to refer to automatically triggering workflows to be executed by a BPM workflow engine.
Then you have transparency. Can a user or health IT system in one healthcare organization view and act on task and workflow states in other healthcare organizations? Because task goes through a workflow engine, each clinical task state transition is logged. “Is it pending? Is it in process? Has it been completed? Is it languishing? Has it been forwarded to someone else? Has it errored out? Has it been cancelled?” All this information is available, and it can be viewed by the members of the care team, who can see, “Okay, I see this task in our group, and Joe, who usually does it, didn’t do it, so I guess I’ll have to do it.” The workflow status can be viewed in reports by the supervisor, so they can say, “Show me all the outstanding tasks that have languished more than five minutes,” and they can be seen by the administrators, who are keeping the system running well.
It is this task transparency that compensates for interruptions. Instead of a human saying, “Oh, I need to do this later,” and they forget; the workflow engine knows that you haven’t done it and reminds you.
Flexibility: Workflow behavior comes from workflow engines consulting workflow rules. Sometimes these are called work definitions, workplans, orchestration or process maps or models. These are representations of workflow behavior that are accessible and “programmable” by non-programmers. These workflow rules or models live outside compiled code. They can be changed by the administrators and the supervisors. EHR usability advocates (who isn’t?) often urge users to be included before EHR implementation, when the EHR is designed in the first place. EHRs and health IT systems based on workflow engines can, in effect, be designed after implementation. This is possible because the compiled code (the “hardcoded” stuff) is consulting soft-coded representations, outside the compiled code, even after implementation. Thus, users, who know their workflows best, and who are most directly affected if workflow is not good after implementation, can still influence ultimate long-term EHR and health IT system usability. You can imagine how useful it is to able change workflow rules within a healthcare organization. Now consider how useful it is to be able to change the workflow rules controlling workflows interacting with other healthcare organizations.
When you put together transparency and flexibility, you arrive at improvability, time-stamped event data can be used to find and eliminate bottlenecks, rework or redundancies, doing things over-and-over again. This “process-improvement process” can be used to improve cycle time, for example reduce workflow cycle time (time from start to end) from four hours to two hours and double capacity, because two workflows can be executed within the same time, using the same resources, as the previous unimproved workflow. Workflow execution consistency increases, improving the likelihood all workflow tasks are accomplished within customizable time limits. If not, intelligent escalation rules make sure no task languishes indefinitely.
Inter-organizational workflow automaticity, transparency, flexibility, and improvability will be necessary for creating healthcare learning systems that span healthcare organizational boundaries. If you consider all of the potential healthcare organizations necessary to support every patient at every step of their person-centered workflow, the only way to create virtual healthcare learning enterprises will be to achieve workflow interoperability among the constitute non-virtual healthcare organizations.
If workflow management technology is necessary to implement rudimentary pragmatic interoperability, not just among health IT system users, but among healthcare organizations then diffusion of task and workflow management technology into healthcare and health IT is a limiting rate factor for realizing system-wide task-workflow pragmatic interoperability. Even a small change in a limiting factor can result in a large global system change. This is exactly what is happening right now in health IT. It is the “workflow-ization of health IT” I referred to in the title of the blog post inspiring this series. Therefore, it is useful to take a look at one model of IT application architecture evolution that applies to evolution of health IT application architectures from data-centric to workflow-centric architectures.
The following is abstracted from the 2002 Aalst and Hee MIT Press book titled Workflow Management: Models, Methods, and Systems.
“1965-1975: decompose applications … information systems comprised decomposed applications, each with its own databases and definitions”
1975-1985: database management … rise of the database management system (DBMS). A database is a permanently available, integrated collection of data files, which can be used by many applications”
1985-1995: user-interface management … Originally user interfaces were designed by the developers screen by screen, field by field. Not only did this take up a lot of time, but also each designer had her own style, which meant that every system had to operate in a different way”
“1995-2005: workflow management … take the business processes out of the applications … A workflow management system (WfMS) manages the workflows and organizes the routing of case data amongst the human resources and through application programs.”
Health IT today, despite increased adoption of such technologies as social, mobile, analytics, cloud, and language processing, is around year 2000 when it comes to adopting workflow management technology. Today the best example of what academics call process-aware technology is business process management, though process-aware tech increasingly appears under the hood of SMAC (Social, Mobile, Analytics, Cloud) and clinical natural language technologies. As SMAC technologies diffuse into healthcare, they are vectors carrying into healthcare sophisticated workflow technologies.
Starting in 2011 I searched for workflow-related content on every website of every HIMSS conference exhibitor (1200-1500!). Starting at a level of about two percent, workflow mentions doubled every year up to and including 2015, in which time at least a third of HIMSS exhibitor website contained relevant workflow content. About five percent of last years HIMSS exhibitors actually mention “workflow engine.”
Workflow technology is indeed diffusing into healthcare and health IT. We are indeed making progress toward task-workflow pragmatic interoperability in healthcare. It is beginning days yet. But startups and initiatives to create and coordinate tasks and workflows across healthcare organizations is one of the single most active areas of health IT. Whether we call it task interoperability, workflow interoperability, process interoperability, or Task-Workflow Pragmatic Interoperability, it is finally happening. (Hurrah!)
You may not have thought about what you are doing as an example of task or workflow interoperability, or the relevance of a distant and exotic fields such as linguistics and pragmatics. However, to be able to place what you are doing into a larger context of prior work and future trends can be powerfully useful for product design and marketing. I am seeing more-and-more task, workflow, and pragmatic interoperability, in a new wave of workflow-centric products. I see it in messaging, location tracking, care coordination, imaging, speech recognition, interface engines, and many other categories of health IT. What they have in common are models of work and workflow used to create sophisticated, transparent, flexible, and systematically improveable intra- and inter-organizational automatic workflows.
A top BPM researcher puts it this way:
“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, my emphasis)
A spider in the web, connecting different technologies … isn’t this exactly what healthcare and health IT so desperately needs?
This series about pragmatic interoperability has been high-level introduction to language, linguistics, and pragmatics relevant to task and workflow interoperability. Theories of pragmatics will be essential to creating truly intelligent EHRs and health IT systems, by which I mean intelligent enough to communicate with both humans (usability) and each other (interoperability). This initiative, trend, campaign (whatever you wish to call it) is potentially a decades-long program. But it may be a little as ten years. Artificial intelligence is more rapidly transforming society that perhaps we realize. Hundreds of millions are being invested in AI startups every year.
A shorter campaign, around ideas and technologies practical to implement in a rudimentary fashion using current workflow technology is completely different. Task and workflow interoperability is happening right now. I wrote my previous five-parter, Achieving Task and Workflow Interoperability, six months ago, in August of 2014. I predicted that the single greatest activity in health IT over the next five years would be the shift from data-centric plumbing to a workflow-centric layer implemented on top. We are ten percent of the way to that time horizon. I have already seen a variety of rudimentary process-aware systems enter the health IT market, and discussion of task and workflow interoperability among health IT thought leaders.
A word about the relationship between healthcare data and workflow standards versus workflow interoperability is due here. First, workflow interoperability is conceptually different from data interoperability. Data interoperability isn’t even technically required for workflow interoperability to exist. When I worked for an EHR vendor to implement e-prescribing, the number of clicks necessary refill a prescription when from three clicks to three clicks. This is because originally tasks just showed up in worklists and human user took care of them. From the point of view of the physician, the most costly resource in this workflow, nothing changed. (Of course, ideally, data and workflow interoperability are aligned, to achieve maximum effectiveness and efficiency.)
Second, there’s a difference between workflow-driven interoperability standards-based solutions and standards-based workflow-driven solutions. In the former case, knowledge of typical clinical and administrative workflows is used to design standards. If, ultimately, after implementation, real-world workflows are different than those envisioned during standard design, users often still have to adapt their workflows to software workflows. In contrast, process-aware information systems, based on existing standards for retrieving, adding, and updating healthcare data, have much more plastic workflows, so that workflow can adapt to users instead of the other way around. Therefore we need to be careful, when designing workflows into healthcare data interoperability standards that we are not perpetuating the kind of frozen workflows that have for so long afflicted hardcoded intra-organizational healthcare workflows.
Terminology (not just technology) is in flux. These new systems may be called Care Management Systems, Care Coordination Platforms, Healthcare or Care Process Management systems, or something completely new. This post-EHR workflow layer, on top of EHRs and other data-centric health IT systems will explicitly represent workflows and 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/dynamic 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, workflow interoperability, and then all the way to comprehensive pragmatic 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.
Finally, there is no small role for health IT social media to palaver, kibitz, and egg on these healthcare workflow entrepreneurs and intrapreneurs. For example — there’s me — @wareFLO on Twitter.
P.S. If I have piqued your interest in healthcare workflow and workflow technology, please read my previous Health Standards guest posts Why is Health IT Behind in Workflow-Friendly Technology and Process Awareness? How do we fix? and Marketing Workflow Is An Incredible Opportunity To Differentiate Health IT Products, And You!
- Pragmatic Interoperability: Healthcare Interoperability’s Missing Workflow Layer Part 1
- Task, Workflow, and Interoperability Definitions: Pragmatic Interoperability Part 2
- Human Linguistics & Healthcare Interoperability Languages: Pragmatic Interoperability Part 3
- The Linguistic Science Behind Task-Workflow Interoperability: Pragmatic Interoperability Part 4
- Task-Workflow Interoperability Benefits and Next Steps: Pragmatic Interoperability Part 5
Latest posts by Charles Webster, MD (see all)
- Makers in Healthcare - April 11, 2016
- Interoperability benefits of task workflow: Pragmatic interoperability series, part 5 - February 26, 2016
- Healthcare BPM: The science behind task workflow interoperability. Pragmatic Interoperability series, part 4 - February 25, 2016