This is Part 2 in a five-part series on Task-Workflow Pragmatic Interoperability. Feel free to read Part 1 before Part 2. Thank you to Health Standards for hosting this five-post, 10,000-word series about healthcare interoperability the week before HIMSS16. Fittingly, the series was inspired by a Health Standards #HITsm tweetchat. Help me (@wareFLO, a HIMSS Social Media Ambassador) spread the Task-Workflow Pragmatic Interoperability word at #HIMSS16 by using the #HIMSSworkflow hashtag!
Workflow is a series of tasks, consuming resources, achieving goals.
Tasks are also called steps, actions, or activities, especially when understanding patient “workflow,” sometimes referred to as life-flow. I like this definition because it explicitly places workflow in an economic context. Consuming resources is a cost. Achieving a goal is a benefit. When the context in which a workflow is executed changes, often the workflow should change if it is to continue operations above some minimum threshold of benefit and cost.
Workflow technology used to be synonymous with workflow management systems, in which workflow engines executed workflow definitions. A workflow definition is like a program that a non-programmer can understand and edit. Today one hears of Business Process Management (BPM) systems. BPM and related systems rely on process or orchestration engines to execute, or at least automatically consult, representations of work and workflows. These are often represented visually, as graphical flowcharts or checklists. Academics call these “process-aware” information systems. Increasingly, many other modern IT systems, including so-called SMAC (Social, Mobile, Analytics, Cloud) technologies, rely on or embed various degrees of process awareness.
Workflow technology relies on executable, or automatically consultable, models of work and/or workflow to drive, perform, or facilitate work or workflow.
“Interoperability is the ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged. “(my emphasis)
“the ability of two or more systems or components to exchange information and to use the information that has been exchanged.” (my emphasis).
Notice the important word “use,” which means “take, hold, or deploy (something) as a means of accomplishing a purpose or achieving a result.” Sometimes people think pragmatic interoperability is synonymous with practical interoperability, which is not a bad connotation to have. Pragmatics and practical derive from a common root, meaning to do, act, or perform.
“Pragmatics is the study of how words are used“
“Pragmatics is concerned with the use of language in social contexts and the ways in which people produce and comprehend meanings through language.”
“Pragmatics is the study of how language is used in everyday interaction.”
Definitions of interoperability emphasize use of information. Pragmatics is about using language. Healthcare interoperability emphasizes syntactic and semantic interoperability, but not pragmatic interoperability. Syntax and semantics are two major subfields within linguistics. Pragmatics is the third major subfield. Healthcare interoperability is a stool with only two legs: syntax and semantics. It is time for healthcare interoperability to level up, and add the third leg of the healthcare interoperability stool: Pragmatic Interoperability.
Complete pragmatic interoperability is what artificial intelligence researchers call “AI-complete,” meaning that we’d need to create generally intelligent systems, as generally intelligent as we humans. This is why I focus on a subset of pragmatic interoperability that is achievable in the near term. I call this Task-Workflow Interoperability (admittedly somewhat inconsistently, regarding the hyphen).
In my previous, 7,000 word, five-part series, I distinguished between task and workflow interoperability. (I encourage those who are interested in gory details to go read those gory details.) A task is a “logical unit of work that is carried out as a single whole by one resource” (Aalst & Hee). Task interoperability is the ability to observe or change task state, such as inactive, pending, started, postponed, reassigned, escalated, errored-out, and so on, in another IT system or healthcare organization. For example, perhaps I’d like to see which clinical tasks have been accomplished for an admitted patient, which have not, and why. There are a variety of task life cycle models out there that can be applied to model clinical and related healthcare task life cycles.
Workflow interoperability is the ability to observe or change relationships among tasks in other IT systems or healthcare organizations. At design time (when workflow is modeled, but not yet executed or “enacted”) these relationships are the “arrows” between tasks. For example, “Start > A > B > C > End” is a workflow. Design-time workflow interoperability means I, in my IT system or healthcare organization, can see and influence not just current tasks (A, B, and C) but the actual models of work and workflow combining them. Just as tasks can have properties (their states), relations among task can have properties, such as who or what resource can execute a transition from A to B or B to C. Run-time workflow interoperability means I can query, and, potentially, trigger, an entire thread of executing workflows. For example, I may wish to cancel all tasks in a workflow by cancelling the workflow. In this case, I’m influencing only this instance of enacting workflow, but not the fundamental design of that workflow for future execution. Finally, there is workflow model interoperability (for example, the BPMN Model Interchange Working Group), so that workflow models can be shared with other workflow systems and related platforms (such as simulation).
Task and workflow interoperability require APIs, so one system can query task and workflow state in another, at either design- or run-time, as well to trigger changes in task and workflow state. More technical models of workflow interoperability exist, than in my above description. To a degree, health IT has been searching in the dark regarding comprehensive interoperability due to relative lack of familiar with these models. Consider the Workflow Management Coalition’s 1996 Workflow Standard on interoperability.
To put it more visually, from my 2009 Well Understood, Consistently Executed, Adaptively Resilient, and Systematically Improvable EHR Workflow:
… Workflow Engine A kicks off workflow A1 through A5, but between A3 and A4 outsources steps B1 through B3 via Web services.”
Health IT cannot achieve workflow interoperability without workflow engines. In fact, we cannot create great workflow between healthcare organizations without great workflow within healthcare organizations. This is because workflow between healthcare organizations is interaction between workflows in different healthcare organizations.
Fortunately workflow engines are indeed finally showing up in health IT. Last year, when I systematically searched, five percent of HIMSS15 exhibitor websites mentioned “workflow engine.” The WfMC defined (in 1995!) various kinds of workflow interoperability: direct interaction, message passing, protocol translation, common repositories, various kinds of APIs (common gateway, limited, complete, shared definition formats, protocol compatibility, and common look and feel). To move from mere data interoperability (syntactic and semantic) to task and workflow, and, finally on to true pragmatic (intelligent) interoperability, we need to encourage more intellectual and technological commerce within health IT and between the health IT and BPM industries.
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. Many enterprises use third-party BPM platforms to tie together internal data sources and workflows. Some have both outward-bound API for exposing data and workflows and 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.
Ability to consume a variety of web services has been standard functionality among BPM systems 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.
Ideally, one builds process-aware healthcare organizations out of process-aware technology. However, many health IT systems still hardcode workflows. They lack the necessary workflow engines to interpret and execute models of work and workflow. Their workflows are opaque instead of transparent, because workflow engines cannot automatically update the task and workflow status needed for real-time reporting. However, most health IT systems also emit time-stamped event data that can reconstruct evidenced-based models of workflow. The process-aware technology that can convert this data exhaust into visual representations of workflow is called process mining. Therefore process mining standards, such as XES (Extensible Event Stream), are relevant to healthcare task and workflow interoperability, if only because we need to discover current workflows to create even better intra- and inter-organizational workflows.
One has to walk before you can run, and crawl before both. Healthcare task and workflow interoperability is just emerging from the crawl stage. For example, numerous startups and initiatives focus on monitoring admission and discharge states and events. Some are facilitating task management within hospitals and across care venues. Design- and run-time workflow interoperability is considerably down the road. However, efforts in this area are happening quickly and, some degree, under the radar of popular awareness of health IT trends.
Now that we know about models of work and workflow, we are almost ready to tackle pragmatics. But first we must talk about human language in general, and its relevance to healthcare interoperability. Why? Because I believe we should begin to view healthcare interoperability as goal-oriented cooperative communication among rational intelligent systems.
Stay tuned for (or proceed to, as the case may be) Human Linguistics & Healthcare Interoperability Languages: Pragmatic Interoperability Part 3.
- 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