Thank you to HealthStandards for hosting this five-post, 10,000-word series about healthcare interoperability the week before HIMSS16. Fittingly, the series was inspired by a HealthStandards #HITsm tweetchat. Help me (@wareFLO, a HIMSS Social Media Ambassador) spread the Task-Workflow Pragmatic Interoperability word at #HIMSS16 by using the #HIMSSworkflow hashtag!
Healthcare is awash in data. We build messages. We send them. We parse them. We look up their meaning using nomenclatures, classifications, and terminologies. But health IT often fails to systematically do useful things with this encoded, sent, parsed, and looked-up data. We lack a sound theoretical foundation to our thinking about how to use healthcare data to communicate and coordinate human and machine action. I argue that this missing theory of interoperability is Pragmatic Interoperability.
Issues of pragmatic interoperability manifest themselves as issues about coordination among EHR workflows (with and among other health IT systems). Pragmatic Interoperability is the science behind the practical engineering nuts and bolts in my previous 7000-word, five-part series, Achieving Task and Workflow Interoperability in Healthcare.
I will further argue that the most mature technology for implementing pragmatic interoperability today is workflow technology. Workflow technology encompasses a number of related technologies, from workflow engines, task and workflow management systems, business process management (BPM), and other process-aware information systems such as case management, interface engines, and customer relationship management systems. “Process-aware” means there is an explicit representation of work or workflow and engine executing or automatically consulting this representation of work during automated accomplishment or facilitation of work or workflow.
In many ways, the healthcare workflow, workflow technology, and workflow interoperability stars are aligning. There’s a great fit between BPM (Business Process Management) and FHIR (Fast Healthcare Interoperability Resources) when it comes Achieving Task and Workflow Interoperability in Healthcare. FHIR provides access to EHR data. BPM orchestrates tasks and workflows across EHRs and other health IT systems, potentially in different healthcare organizations. FHIR (and non-FHIR) EHR API (Application Programming Interfaces) initiatives will play an important role in ushering into healthcare the kind of process-aware BPM-style interoperable workflow it so desperate needs.
The key to achieving task-workflow pragmatic interoperability is representing clinical and administrative task and workflow states and events, and making them accessible via APIs. This is the necessary layer between data interoperability (syntactic and semantic, to be discussed below) and task- and workflow-oriented pragmatic interoperability. The next interoperability layer up from data interoperability consists of workflow engines orchestrating choreographies of workflow conversation among EHRs, and between EHRs and other health IT systems. Intelligent, transparent, flexible, workflow-managing process orchestration engines in the cloud will supply healthcare interoperability’s missing workflow layer.
Current healthcare interoperability rests on a two-legged stool. One leg is Syntactic Interoperability. One leg is Semantic Interoperability. (More on those below.) Plug-and-play syntactic and semantic interoperability is the holy grail of EHR interoperability. We hear less about the next level up: pragmatic interoperability (the linguistic science behind task and workflow interoperability).
Pragmatic Interoperability is the third leg missing from the healthcare interoperability stool. This five-part series describes pragmatics (a subfield within linguistics), its relevance to healthcare interoperability, and how to leverage process-aware workflow technologies, such as Business Process Management, to achieve task-workflow pragmatic interoperability. We need to add the crucial third leg of the healthcare interoperability stool.
Linguistics is made up of a number of subfields. You may think of them as a pipeline or series of layers from compression and rarefaction of sound waves to purposeful communication and coordinated action. The output from syntax is the input to semantics. The output from semantics is the input to pragmatics. In the pragmatics layer we do things with words to change the world to achieve goals. It’s actually way more complicated that how I make it seem. There are feedback loops. Linguists argue about where to draw the lines between syntax, semantics, and pragmatics. But this simplified model will serve the purpose of this series about pragmatic interoperability in healthcare.
Syntax and semantics are terms borrowed from linguistics, specifically, the study of signs. A sign is something, such as an ICD-10 code, that can be interpreted to have meaning, such as a medical diagnosis. Syntax is about relations among signs, for example relations among fields in an HL7 message or characters in an ICD-10 code. Syntactic interoperability deals with the structure of healthcare data (reminiscent of sentence diagrams in high school English class). It is necessary for transmitting healthcare data in a message from one system to another. Syntactic interoperability is the ability of one EHR (for example) 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”).
Semantics is about the relation of signs to what they mean or denote in the world, such as a diagnosis, etiology, anatomic site, and so on. Semantic interoperability deals with the meaning of data. It is necessary for sharing meaning between transmitting and receiving systems. 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).
Syntactic and semantic interoperability are not enough. They are just tactical tools. Pragmatics is about how we use syntax and semantics as a tool to accomplish goals. Semantics is about literal meaning. Pragmatics is about non-literal meaning. I will discuss pragmatics, in depth, in Part 4 of this series, but will introduce the idea of pragmatic interoperability below.
To review: Syntactic interoperability parses sent data structures; semantic interoperability preserves meaning across sending and receiving systems; pragmatic interoperability does something useful with the outputs of the former. It would not be grandiose to say a theory of healthcare pragmatic interoperability is a theory of healthcare interoperability, since syntax interoperability serves semantic interoperability, and semantic interoperability serves pragmatic interoperability.
Let’s start with a straightforward definition of pragmatic 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)
Compatibility between intended effect versus actual effect of message exchange…
When you speak to me, you are trying to do something, to change the world in some way. Even if you do not explicitly tell me to do something, I grasp your intended meaning and likely help you do whatever you are trying to do. I consider the context of your utterance, your likely workflow (your goal, remaining tasks and their order, and which uncompleted tasks I might help you complete), and help if I can.
If you ask me if I know the time for the next scheduled surgery, I ignore your literal question (to which my overly literal answer would have been “Yes”), and respond to your intended meaning (“2:30”). I act in a pragmatic interoperable manner. The intended effect of you question is to find out the scheduled time (so that you can show up on time, so that you can complete your residency, so you can … and so on). The actual effect is you find out the time. Since intended and actual effects match, we achieve pragmatic interoperability.
Key to modern conceptions of pragmatics is that human communication is not just encoding a message in my brain, sending it to you over a potentially noisy channel, and then you decoding that message. This is a naive model human communication. Among linguists an inferential model of communication replaced the simplistic encode/send/decode model of communication.
What do I mean by inferential? Speakers imply (suggest indirectly) and addressees infer (deduce from evidence and reasoning rather than from explicit statement). Consider an extreme example. Suppose everyday at 6PM an on-call physician sends a text message to a partner that everything is under control. Whenever no text message is sent, they both understand the partner needs to come in to help out. Since no overt message was sent, there is nothing to decode. Nonetheless, the address successfully infers the “speaker’s” intended meaning. This was an extreme example. For the rest of this series I will assume some overt token, a message, is exchanged. But the literal content of the message is insufficient to achieve pragmatic interoperability. Non-literal meaning must be inferred from shared background knowledge. The most important shared background knowledge to achieve healthcare interoperability is knowledge about tasks, workflows, plans, and goals, all of which are explicitly represented and automated by workflow technology.
Healthcare interoperability must incorporate more inference-based communication. The key technology to allow this to happen will be workflow technology. Workflow technology relies on explicit models of work and workflow. When these models (such as shared care plans) are shared, this is the context that make task and workflow interoperability possible. Shared context between sender and receiver make possible inferences necessary to achieve pragmatic interoperability. Current shared care plan-based health IT applications rely on humans to be the workflow engines, to react to changes in state and to trigger workflows. Increasingly this will be accomplished, or facilitated by software-based workflow engines.
A reasonable objection is that, designed right, all communication among health IT systems can be based on literal meaning (semantics) and not have to rely on non-literal meaning (pragmatics). I disagree. There is always some implicit message context that is not captured in the message itself. In some instances, perhaps it can be ignored. But in general, health IT needs to perform a better job taking into account the clinical context of sent and received messages. In this series, I will specifically focus on task, workflow, plan, and goal context, because we have an available tool to manage this context: workflow technology.
The earlier offered definition of pragmatic interoperability is deceptively simple, but nonetheless powerful. First of all, it makes intuitive sense. Clinicians can understand it, as in, do what I mean, not what I say, sort of way. Second, it can apply to relatively simple scenarios and to relatively complicated scenarios. “Effect” can refer to something as simple as sending someone (perhaps in another healthcare organization) a task to complete. Compatibility between intended and actual can be as simple as checking to make sure the task moves through its task life cycle (pending, started, resigned, started, escalated, complete and so on) to “complete” by a certain time or date. On the other hand, “effect” can refer to complex constellations of tasks, workflows, and mental states, as in, “I accept responsibility for completing all tasks in this assigned workflow, promise to complete them within one week, and inform you when they are complete.”
This series is about the science behind task and workflow interoperability, recently outlined in my recent 7000-word, five-part series Achieving Task and Workflow Interoperability In Healthcare. That series was about practical engineering. So if you are looking for a practical guidebook, go there. Here I am talking about theories supporting why I believe process-aware technology is key to achieving task and workflow interoperability.
Science is about understanding the world. Engineering is about solving problems. Scientific theories are abstract, tentative, and eschew practical consequences. Engineering is concrete, decisive, and about practical consequences. However, as Kurt Lewin, the famous organizational psychologist famously said: “There is nothing as practical as a good theory.” Have no fear, though; mine will be a gentle introduction to linguistics and pragmatics.
Stay tuned for (or proceed to… if there’s nothing there yet, it hasn’t been published) Task, Workflow, and Interoperability Definitions: Pragmatic Interoperability Part 2.
Here is an outline of this five-part series on workflow, linguistics, and healthcare interoperability.
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