Pragmatic Interoperability

Just before HIMSS16 @HealthStandards published my 10,000 word, five-part series on Pragmatic Interoperability. In time for the AHIP Institute I’m reblogging that content here to my own Healthcare Business Process Management Blog. The concept of Pragmatic Interoperability is crucial to the kind of data and workflow virtualization health plans need to better serve their members. You may also wish to spare a wee keek toward my toward my ten-part series, 10 Reasons Health Plans Should Double-Down on Modern Business Process Management.


Thank you to HL7 Standards for hosting this five-post, 10,000-word series about healthcare interoperability the week before HIMSS16. Fittingly, the series was inspired by a HL7 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!

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, it hasn’t been published yet) Task, Workflow, and Interoperability Definitions: Pragmatic Interoperability Part 2.

Here is an outline of this five-part series on workflow, linguistics, and healthcare interoperability.

  1. Pragmatic Interoperability: Healthcare Interoperability’s Missing Workflow Layer (Part 1)
  2. Task, Workflow, and Interoperability Definitions: Pragmatic Interoperability Part 2
  3. Human Linguistics & Healthcare Interoperability Languages: Pragmatic Interoperability Part 3
  4. The Linguistic Science Behind Task-Workflow Interoperability: Pragmatic Interoperability Part 4
  5. Task-Workflow Interoperability Benefits and Next Steps: Pragmatic Interoperability Part 5


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 HL7 Standards for hosting this five-post, 10,000-word series about healthcare interoperability the week before HIMSS16. Fittingly, the series was inspired by a HL7 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!

I’ve seen hundreds of definitions of “workflow,” some stretching across two slides in small print. The following is my own distillation of the essence of all the definitions I’ve seen.

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.

My working definition workflow technology then is …

Workflow technology relies on executable, or automatically consultable, models of work and/or workflow to drive, perform, or facilitate work or workflow.

Now compare several definitions of interoperability to several definitions of pragmatics.

HIMSS adopts a definition of interoperability …

“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)

… based on the IEEE definition …

“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.

Now take a look at three definitions of pragmatics (my emphases in italics), a subfield within linguistics, where syntax and semantics are also subfields.

“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.

Workflow interoperability is “the ability of two or more workflow engines to communicate and interoperate in order to coordinate and execute workflow process instances across those engines.”

To put it more visually, from my 2009 Well Understood, Consistently Executed, Adaptively Resilient, and Systematically Improvable EHR Workflow:

“The following is another diagram of a process shared across organizations.

… 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.

Here is an outline of this five-part series on workflow, linguistics, and healthcare interoperability.

  1. Pragmatic Interoperability: Healthcare Interoperability’s Missing Workflow Layer (Part 1)
  2. Task, Workflow, and Interoperability Definitions: Pragmatic Interoperability Part 2
  3. Human Linguistics & Healthcare Interoperability Languages: Pragmatic Interoperability Part 3
  4. The Linguistic Science Behind Task-Workflow Interoperability: Pragmatic Interoperability Part 4
  5. Task-Workflow Interoperability Benefits and Next Steps: Pragmatic Interoperability Part 5


This is Part 3 in a five-part series on Task-Workflow Pragmatic Interoperability. Feel free to read parts 1 and 2 before Part 3. Thank you to HL7 Standards for hosting this five-post, 10,000-word series about healthcare interoperability the week before HIMSS16. Fittingly, the series was inspired by a HL7 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!

In Part 2 of this series, I suggested viewing healthcare interoperability as communication between intelligent systems. We should look to the ultimate intelligent system, us, for inspiration.

By way of bona fides I should mention I have four degrees — Accountancy (BS), Industrial Engineering (MSIE), Intelligent Systems (MSIS in Artificial Intelligence), and Medicine (MD) — but I have one more degree I usually don’t mention: an ABD. ABD stands for All But Dissertation. I took all the courses necessary for a Ph.D. in Computational Linguistics, but transferred into Intelligent Systems at the last moment. I took twenty courses in linguistics and natural language processing: phonetics, phonology, morphology, syntax (I & II), semantics and pragmatics, then NLP (I, II, & III) and NLG (Natural Language Generation). Phew! More on my experience in My Virtual Graduate Degree in Computational Linguistics and Natural Language Processing.

There are many interesting connections between linguistics and workflow. They use similar ways to represent sequences of activity; in the case of workflow, tasks; in the case of linguistics, words in sentences and utterances in conversations. Workflow and task context influence speech recognition performance. “Conversational” user interfaces need to recognize user goals, plans, and activities, all of which can be informed by models of work and workflow. Speech recognition and clinical natural language processing rely on workflow technology-based pipelines to convert sound into text and structured data, conduct post-editing quality assurance, and to route results to users.

Interoperability, in its most general sense, is about communication. The ultimate example of interoperability is human conversation. Conversation is the most common, developmentally first, historically oldest and default means of communication. Conversation is powerful. You and I use conversation to change the world, each other, and ourselves.

Conversation is remarkably resilient. We constantly monitor, adapt, accommodate and repair what we say and mean. Some medical informaticists suggest we view health IT workflows as conversations instead of transactions. Conversations can be modeled as workflows. Business process collaboration can be modeled as conversation.

Instead of mere data transactions, EHRs and other health IT systems need conversational workflows, if they are to become more resistant to errorful interpretation. “Which patient are you referring to?” (reference resolution) “I promise to get back to you” (speech act) “Why did you ask about the status of that report?” (abductive reasoning) These interactions include issues of pragmatic interoperability (workflow interaction protocols over and above semantic and syntactic interoperability).

Human conversation would not be possible without special properties of human language. Let see how they compare to healthcare interoperability standard “languages,” such HL7 2.X, C-CDA, and FHIR, used in conjunction with coding systems such as ICD, LOINC, and SNOWMED. These are not human languages, in the traditional sense studied by linguists, but they are languages nonetheless. Computer programming languages aren’t natural languages, but they can be understood by humans, borrow ideas from linguistics (especially syntax and semantics), and sometimes even influence linguistics research (especially computational linguistics). Linguists list six important design principles of human language: arbitrariness, displacement, cultural transmission, duality, productivity, and reflexivity.

Arbitrariness is simply the fact that any form (for example, any string of characters) may potentially have any meaning. For example, any string of characters can, in principle, refer to any diagnosis. Obviously, previous convention guides adding new codes and their meanings to interoperability vocabularies, but, again in principle, we can choose to assign any meaning to any string when we are designing a vocabulary for communication between information systems.

Displacement is the ability to speak of things not immediately present. Human can speak of things that happened someplace else at some other time than the moment of speech. Animals don’t do this. They communicate but only refer to things and events in the moment (“Watch out! Predator!) Similarly, healthcare interoperability messages may refer to patient events in the past.

Cultural transmission makes possible historical continuity across successive generations. Language is not genetically encoded and instinctual. Similarly, interoperability syntax and semantic pass from one generation of health IT professional to another via cultural practice: training, documentation, programming, and so on.

Duality allows a small set of symbols to be combined and recombined to refer to a large set meanings. Patterns occur at both the syntactic and semantic levels. Every day we utter sentences that have never been uttered before, and yet we understand them. Interoperability languages sometimes rely on a smaller set of primitives, but which can be combined to support a wide variety of meaning.

The last two design principles of human language — productivity and reflexivity — are special. It is more difficult to find examples of the phenomena in current healthcare interoperability languages. However, productivity and reflexivity are important to the future of healthcare interoperability languages.

Productivity is the ability to create new words and meanings. Humans coin words and ideas at a rapid clip, seemingly almost effortless (Jabberwocky!). One might argue that productivity in healthcare interoperability languages would be a bad idea. One of the goals of standard vocabularies is to allow comparison for a wide variety of purposes, but especially research. To constantly allow new vocabulary terms seems disruptive. And yet, look at the many problems of moving from just one version of ICD to another. In this light, it’s tempting to argue we need to build some, perhaps limited, form of productivity into healthcare interoperability languages.

Reflexivity is what I am doing now, using language to talk about language. In fact, in this sentence I’m using language to talk about using language to talk about using language! No animals can do this. Not many human systems of communication can do this: Pantomime, traffic signs, fashion, etc. do not. And yet, it is our ability to talk about talking and write about writing that allows us to introspect and debug the very system we are using to introspect and debug. It is a primary means for recursive self-improvement.

To the degree current healthcare interoperability languages resemble human language, it suggests we consider other ways in which they resemble human language. Specifically, current healthcare interoperability concerns emphasize data interoperability, via syntactic and semantic interoperability. Syntax and semantics are both concepts drawn from linguistics. I suggest healthcare interoperability also begin to incorporate ideas from pragmatics, an important subfield of linguistics, with important strategic interactions with syntax and semantics. In addition to syntactic and semantic interoperability, we should begin to emphasize pragmatic interoperability as well.

Stay tuned for (or proceed to… if there’s nothing there, it hasn’t been published yet) The Science Behind Task-Workflow Interoperability: Pragmatic Interoperability Part 4.

Here is an outline of this five-part series on workflow, linguistics, and healthcare interoperability.

  1. Pragmatic Interoperability: Healthcare Interoperability’s Missing Workflow Layer (Part 1)
  2. Task, Workflow, and Interoperability Definitions: Pragmatic Interoperability Part 2
  3. Human Linguistics & Healthcare Interoperability Languages: Pragmatic Interoperability Part 3
  4. The Linguistic Science Behind Task-Workflow Interoperability: Pragmatic Interoperability Part 4
  5. Task-Workflow Interoperability Benefits and Next Steps: Pragmatic Interoperability Part 5


This Part 4 in a five-part series on Task-Workflow Pragmatic Interoperability. Feel free to read parts 1, 2, and 3 before Part 4. Thank you to HL7 Standards for hosting this five-post, 10,000-word series about healthcare interoperability the week before HIMSS16. Fittingly, the series was inspired by a HL7 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!

If you’ve stuck with me this far, through all of the first three parts of this series on Task-Workflow Pragmatic Interoperability in Healthcare, thank you! We covered workflow, workflow technology, and definitions of interoperability. I’ve argued that current healthcare interoperability languages, used to facilitate healthcare interoperability, share important design principles with human language. An important area of language, studied by linguistics, in addition to syntax and semantics (already emphasized by healthcare interoperability), is pragmatics. Pragmatics is, essentially, How To Do Things With Words (lecture notes, 1955, book 1962: one of the most important books in linguistics about pragmatics, which kicked off modern pragmatics research programs).

The subfield of linguistics called pragmatic has five sub-subfields: speech acts, implicature, presupposition, reference, and deixis. They sound complicated, but much is common sense. So let’s start with an example torn from the headlines, so to speak. The following is a quote from a recent article in an online health IT trade publication.

“‘It’s all about the workflow …. If you want to have a bad day with physicians, mess up their workflow or make them learn a new one that they think is less efficient.’ From a physician’s point of view, looking at a [Consolidated Care Document] is like rummaging through a ‘junk drawer’ in search of that one elusive item. ‘They don’t want to hunt for what they want'”

I will return to the above example each time I discuss one of the five areas of pragmatics.

Research into pragmatics is relevant to creating computers that understand humans and can be understood in return. From a popular textbook about pragmatics:

“Who could doubt that the world of artificial intelligence will soon bring us electronic devices with which we can hold a colloquial natural-language conversation? The problem, of course, is pragmatics … it needs rules of inference that will allow it to take what has occurred in the discourse thus far, a certain amount of world knowledge, and its beliefs about how much of that world knowledge we share, and calculate the most likely interpretation for what I have uttered, as well as to construct its own utterances with some reasonable assumptions about how my own inferencing processes are likely to operate and what I will most likely have understood it to have intended. These processes are the subject of pragmatics research.”

Wait a minute, you may think, aren’t we talking about communication among computer systems, not among humans or humans with computer systems? Yes, data-centric approaches to healthcare interoperability do strive to cut humans out of the loop. They may create and use the data, but the actual movement and synchronization and interpretation is mechanically accomplished as much as possible. Workflow-centric approaches to healthcare interoperability are different. For the foreseeable future, they require communication among joint human/computer cognitive systems. As we will see, pragmatics is not only relevant to interoperability, it is relevant to usability as well. In fact, it is at the level of task-workflow pragmatic interoperability that interoperability and usability merge in to a single concern. After all, what do definitions of interoperability, pragmatics, and usability have in common? “Use.”

Inspect the following diagram. You can think of this is as a general-purpose conversational workflow that repeats over-and-over, though each cycle may take a different path. On the left we have a healthcare workflow customer, or initiator, on the right, a healthcare supplier, or partner. The dashed line is the boundary between two organizations. I adapted this diagram from figures 2-12 and 2-16 in Workflow Management Systems for Process Organizations (1996). Those diagrams, in turn, reflect ideas from pragmatics, specifically speech act theory.


In speech act theory, words are deeds. These deeds have prerequisites and effects on the world. These deeds chain together into workflows. At each step of conversational workflow, prerequisites (felicity conditions) must be met. You can think of a conversation as a series of back and forth moves (like in a game). Speech acts include (in addition to above listed, plus there are many others not listed here):

  • Assertives: (I affirm, believe, conclude…)
  • Directives: (I ask, challenge, command, request…)
  • Commissives: (I guarantee, promise, swear…)
  • Expressives: (I apologize, thank, welcome…)
  • Declaratives: (I pronounce, sentence, declare…)

Pronouncing someone dead is a classic speech act. One of the preconditions is that the speaker must actually have the authority to pronounce someone dead. If these felicity conditions are met, then the status someone in the world changes from officially alive to officially dead. Healthcare and health IT are full of speech acts, especially during interactions with EHRs. A reliable test of whether an utterance is a speech act is to prepend “I hereby …” as in “I hereby pronounce John Smith dead at 8:00, January 25th, 2016.” While mundane data and order entry sounds a bit odd, translated into this linguistics test, it still works:

  • I hereby diagnose …
  • I hereby prescribe …
  • I hereby refer John Smith to you …

EHR data and order entry lend itself to the “hereby” test because so much interaction EHRs is for legal documentation purposes.

Several early workflow management systems modeled workflows as conversations chaining speech acts. Above was an example where speech act theory, from pragmatics, guided design of workflow systems at the boundary between two organizations, the customer and the supplier. Speech act theory continues to influence language-oriented workflow automation.

Relative to the “‘It’s all about the workflow” example, instead to thinking of healthcare interoperability as a data transaction, think of it as a workflow conversation. The following is just one of multitude of possible such workflow conversations:

The physician’s EHR requests information from an external health IT systems needed to complete the next step of a workflow. The external health IT system may ask for clarification (who? which date? what format?), then either deliver the result, or, commit to do so. In attempting to perform, tasks are delegated, escalated, until delivery of requested information is performed. The physician’s EHR evaluates and confirms this is the information the physician needs for the next workflow step. If the information is not what is needed, the cycle executes again, but this time the external health IT system may change its representation of the physician’s workflow, so that in the future presuppositions about completed and pending tasks are more accurate. Pragmatic interoperability requires compatibility between intended and actual effect of a message. The compatibility between what was intended (requested and committed to) versus what actually happened (what was perform and evaluated) is assessed over-and-over, across healthcare organizational boundaries.

Speech acts have three aspects. There is the locution. This is the actual utterance. In an healthcare interoperability language this is the message. There is the illocution. This is the intended meaning of the utterance or message. In a healthcare interoperability scenario, this is some action the sender of the message intends to have accomplished. Finally, there is the perlocution. This is the actual action precipitated by the utterance or message. Pragmatic interoperability is achieved when perlocution matches illocution.

On we go to the second area within pragmatics: implicature.

The best way to understand implicature is to leverage another subject familiar to health IT: usability. We’ll start with implicature’s core principle and its four maxims.

The principle is:

“Be cooperative.”

The maxims are:

  • Be truthful/don’t say what you lack evidence for
  • Don’t say more or less than what is required
  • Be relevant
  • Avoid obscurity & ambiguity, be brief and orderly

Anyone who has studied data display in EHRs recognizes the common sense nature of the principle and maxims. “Be truthful” seems obvious, but what does it mean when designing a user interface? What is a the computational definition of “evidence”? These maxims require nontrivial-to-implement programming rules, such as double-checking data, making sure whoever entered the data has the right authority to do so, and so on. Not displaying too much or too little, making sure what is displayed is relevant to user goals, displaying data in a format that easily consulted and consumed … all make sense. But users still complain these maxims are violated in many EHR and health IT systems.

Then there is the principle: “Be cooperative.” It sound so simple, also so common sense. But here’s the thing. In order to an EHR or health IT system, to be truly cooperative, to display exactly what is needed, no more, no less, requires that that system be able to understand user goal, plans, workflows, and tasks. If these goals, plans, workflows, and actions are not represented, then how can they be recognized? Guess what kind of information system represents goals, plans, workflows, and actions? Process-aware business process management style workflow systems.

Now, you say, OK, I’ve convinced you workflow tech is relevant to usability, but how is it relevant to interoperability? When another healthcare organizations sends me a Request to Commit to Perform a task or workflow on its behalf, I need to be cooperative, and be truthful (based on appropriate evidence), provide no more or less data then needed, make sure the data is relevant to why I believe they initiated the Request, and provide the data in a format they can easily consume. The very best way for me to do these things is to understand and leverage understanding of the other healthcare organization’s goals, workflow, plans, and tasks.

Relative to the “‘It’s all about the workflow” example, focus on the phrase “looking at a [Consolidated Care Document] is like rumma