Pragmatic Interoperability

Just before HIMSS16 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 (, a HIMSS Social Media Ambassador) spread the Task-Workflow Pragmatic Interoperability word at by using the 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 (, a HIMSS Social Media Ambassador) spread the Task-Workflow Pragmatic Interoperability word at by using the 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 ), 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 (, a HIMSS Social Media Ambassador) spread the Task-Workflow Pragmatic Interoperability word at by using the 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 (, a HIMSS Social Media Ambassador) spread the Task-Workflow Pragmatic Interoperability word at by using the 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 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 .

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 rummaging through a ‘junk drawer’ in search of that one elusive item.” First of all, sending someone a “junk drawer” is not cooperative. It’s not cooperative because it violates the second maxim, not to say more than what is required. It violates the third maxim, since the document likely contains a lot of, to the physician, irrelevant information. It violates portions of maxim four, to be brief. Note, I’m presupposing that the evidence-based information (maxim one) is even in the document.

One is tempted to say that FHIR will solve this problem, since it is an standards-based API that will allow plucking out that single bit of not-to-much, not-to-little nugget of relevant information for presentation to the physician. However, the interacting EHR and health IT systems still need knowledge of each others workflows to perform the reasoning necessary to accomplish this cooperative act.

Presupposition is the information we presuppose when interpreting a message. Presupposition comes from shared and assumed common knowledge. If I ask someone if they finished their work, and they say the finished the last step in a workflow, then I presuppose they also executed all prerequisite steps in their workflow. I could be wrong. If the next thing they say contradicts my presupposition, I change it. (“cancellability” in pragmatics.) What is good source for the knowledge for what to presuppose, or not? My general or specific knowledge of goals, plans, workflows, and tasks. Workflow systems also use representations of goals, plans, workflows, and tasks. So they are natural platform for creating more usable, more pragmatic interoperable, health IT systems.

In the case of the “It’s all about the workflow” example, presupposition operates at several levels. First of all, the external health IT system presupposes the EHR and physician already know a lot of information, so it is not necessary to include it in any response. Second, from the information requested, one can presuppose previous steps in the workflow have been accomplished, but subsequence steps may not have been accomplished. If any information relevant to these subsequent steps is available, it might be helpful to offer this information as well. Third, if presuppositions are wrong, then they are changed for this conversation and perhaps changed for future conversations.

Finally we come to the two remaining areas of pragmatics that we have not yet covered, reference and deixis. Of the five areas, implicature, speech acts, and presupposition are most relevant to task-workflow interoperability. However, since we’re already this deep into the pragmatics weeds, I may as well cover them here as well.

Reference and deixis lay at the boundary between semantics and pragmatics. Reference is how words can refer to things in the world. “Hearts” refers to things that are hearts. Deixis is how context influences reference. “Me” refers to me when I utter it, but you when you utter it. “The patient” refer to one person in one context, but another person in another context. Both are potentially relevant concepts when thinking about healthcare interoperability. Medical coding systems attempt to standardize reference across sending and receiving systems. Natural language processing increasingly interprets exchanged clinical reports full of deictic terms: “this patient” (who?), “the operation will take place here…” (where?), “…tomorrow” (when?).

Regarding the “It’s all about the workflow” example, I could come up with ways in which it might illustrate reference and deixis. But I think we can leverage the 80/20 rule here. At least from a task and workflow interoperability perspective, speech acts, implicature, and presupposition probably account for a majority of the value due to a minimum cognitive effort to understand pragmatic interoperability. Therefore I will move on.

If you are an expert on pragmatics, you will surely realize I’ve provided an extremely simplified description of your fascinating discipline. Sorry about that! I am more motivated to stimulate health IT interest and appetite for learning more about pragmatics than a potentially off-putting detailed and comprehensive overview. To make up, let me end with a quotes from a leading textbook on pragmatics.

“Pragmatics is one of the most vibrant and rapidly growing fields in contemporary linguistics and the philosophy of language. In recent years, it has also become increasingly important in cognitive science, artificial intelligence, informatics, neuroscience, language pathology, anthropology, and sociology.”

In this series (and, since my 2014 From Syntactic & Semantic To Pragmatic Interoperability In Healthcare), I’ve argued that pragmatics is also increasingly important to healthcare interoperability.

Stay tuned for (or proceed to… if there’s nothing there, it hasn’t been published yet) Task-Workflow Interoperability Benefits and Next Steps: Pragmatic Interoperability Part 5.

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 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 HL7 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 HL7 Standards #HITsm tweet chat. Help me (, a HIMSS Social Media Ambassador) spread the Task-Workflow Pragmatic Interoperability word at by using the hashtag!

What are the benefits of Task-Workflow Pragmatic Interoperability? How do we get to these benefits?

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 — on Twitter.

P.S. If I have piqued your interest in healthcare workflow and workflow technology, please read my previous HL7 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!

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

On Periscope!