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.
[Part 1: Achieving task and workflow interoperability in healthcare.]
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.
