From Syntactic & Semantic To Pragmatic Interoperability In Healthcare

Reviews of this article and my idea of pragmatic interoperability for healthcare are rolling in!

So, what the heck is Pragmatic Interoperability?

“Pragmatic interoperability (PI) is the compatibility between the intended versus the actual effect of message exchange.” (ref) The best current practical candidate for achieving pragmatic interoperability is workflow technology (AKA BPM or Business Process Management and related tech). A candidate for measuring progress toward pragmatic interoperability in healthcare is diffusion of workflow technology into healthcare.

Last year I searched every HIMSS13 exhibitor website (1200+) for evidence of workflow tech or ideas (AKA Business Process Management & Dynamic/Adaptive Case Management). About eight percent of websites had such evidence. I links to this material on the #HIMSS13 hashtag during the conference. This year, before HIMSS14, I searched again. More than sixteen percent of websites had qualifying material. This material I also during on the HIMSS14 conference on the #HIMSS14 hashtag.

  • What is pragmatic interoperability? (Beyond that initial quote).
  • How is workflow technology relevant to pragmatic interoperability?
  • What do I hope to see next year at HIMSS15?

What is pragmatic interoperability?

To understand pragmatic interoperability, you must also understand syntactic and semantic interoperability. Syntax, semantics, and pragmatics are ideas from linguistics. You can think of language as being built from successive layers of information processing: phonetics, phonology, morphology, syntax, semantics, pragmatics, and discourse (conversation). (All of which I’ve taken as undergraduate and graduate courses.) Turns out linguistics is relevant to communication among health IT systems too — who da thunk!

Between healthcare IT systems, as between people, interoperability is ultimately more about conversation than mere message-passing transactions. Think about it. Think about how self-correcting conversation is. How much conversation depends on shared understanding of shared context. In fact, twenty years ago Frisse, Schnase, and Metcalfe wrote the following:


Models for Patient Records

“When performance is defined as the result of collective efforts rather than as the result of the actions of an individual, software systems supporting these activities may be labeled under the popular rubric groupware….Although it is tempting to think of these activities as “transactions” it is equally valid to consider them “conversations” related to the solution of specific tasks….Using conversations as a central metaphor for handling patients’ records reflects workflow in a clinical setting”

Healthcare desperately needs usable interoperability. We need interoperability at the level of user interface, user experience, provider and patient experience and engagement, not just syntactic and semantic interoperability. The best metaphor at this level of interoperability is conversation, not transaction. But we need pragmatic interoperability to get to conversational interoperability. And workflow tech is the best way to engineer self-repairing conversations among pragmatically interoperable health IT systems. (More on this in my next section.)

Communication among EHRs and other health IT systems must become more “conversational,” 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).

pragmatics

By the way, context plays a very important role in pragmatics. If you are interested in context, contextual design, context-aware computing, etc. you ought to take a look at how linguistics views context. A good place to start is Birner’s Introduction to Pragmatics.

I am in no way diminishing the importance of syntactic and semantic interoperability. In fact, we need both to get to pragmatic interoperability. Much is made of the need for EHRs to interoperate with each other and other information systems (as well it should). Current efforts focus on syntactic and semantic interoperability. Syntactic interoperability is the ability of one EHR to parse (in the high school English sentence diagram sense) the structure of a clinical message received from another EHR (if you are a programmer think: counting HL7’s “|”s and “^”s, AKA “pipes” and “hats”).

Semantic interoperability is the ability for that message to mean the same thing to the target EHR as it does to the source EHR (think controlled vocabularies such as RxNorm, LOINC, and SNOMED).

Meaning is shared between two systems (human or computer) when the following occurs:

  • An external real world entity (drug, diagnosis) is referred to by an internal concept
  • The internal concept is encoded as symbol (word, number, ICD-9 code)
  • The symbol is transmitted across a channel (air, paper, TCP/IP, string)
  • The symbol is decoded to an internal concept
  • The internal concept refers to the same external real world entity (drug, diagnosis)

Two systems that can do this are “semantically interoperable.”

Plug-and-play syntactic and semantic interoperability is currently the holy grail of EHR interoperability. We hear less about the next level up: pragmatic interoperability. As soon as, and to the degree that, we achieve syntactic and semantic interoperability, issues of pragmatic interoperability will begin to dominate. And they will manifest themselves as issues about coordination among EHR workflows. In fact, issues of pragmatic interoperability are already beginning to arise, although they are not always recognized as such.

Here are succinct descriptions of semantic versus pragmatic interoperability:

“Semantic interoperability is concerned with ensuring that a symbol has the same meaning for all systems that use this symbol in their languages. Symbols are real world entities indirectly (i.e., through the concept they represent). Therefore, the semantic interoperability problems are caused either by different abstraction of the same real-world entities or by different representations of the same concepts….”

“Pragmatic interoperability is concerned with ensuring that the exchanged messages cause their intended effect. Often, the intended effect is achieved by sending and receiving multiple messages in specific order, defined in an interaction protocol.” (ref)

This last quote elaborates my first quote about pragmatic interoperability. At this point we must consider what specific technology is available to begin to create pragmatically interoperable health IT systems.

How is workflow technology relevant to pragmatic interoperability?

So, how does workflow technology tie into pragmatic interoperability? The key phrases linking workflow and pragmatics are intended effect and specific order.

Imagine a conversation between a primary care EHR workflow system and a specialty care EHR workflow that goes like this:



  • EHR workflow systems (WfSs) will need to coordinate execution of workflow processes among separate but interacting EHR WfSs. For example, when a general practice EHR workflow system (GP EHR WfS) forwards (“Invoke”) a clinical document to a subspecialist who is also using an EHR workflow system (SS EHR WfS), the GP EHR WfS eventually expects a referral report back from the SS EHR WfS.
  • When the result arrives (“Result”), it needs to be placed in the relevant section in the correct patient chart and the appropriate person needs to be notified (perhaps via an item in a To-Do list).
  • If the expected document does not materialize within a designated interval (“Monitor”), the GP EHR WfS needs to notify the SS EHR WfS that such a document is expected and that the document should be delivered or an explanation provided as to its non-delivery. The SS EHR WfS may react automatically or escalate to a human handler.
  • If the SS EHR WfS does not respond, the GP EHR WfS may cancel its referral (“Control”) and also escalate to a human handler for follow up (find and fix a workflow problem, renegotiate or terminate an “e-Contract”).

The sequence of actions and messages — Invoke, Monitor, Control, Result — that’s the “specific order” of conversation required to ensure the “intended effect” (the Result). Interactions among EHR workflow systems, explicitly defined internal and cross-EHR workflows, hierarchies of automated and human handlers, and rules and schedules for escalation and expiration will be necessary to achieve seamless coordination among EHR workflow systems. In other words, we need workflow management system technology to enable self-repairing conversations among EHR and other health IT systems. This is pragmatic interoperability. By the way, some early workflow systems were explicitly based on speech act theory, an area of pragmatics.

What do I hope to see next year at HIMSS15?

I answered the question, what I’d like to see next year at HIMSS15 regarding workflow and workflow technology, in an interview at HIMSS14.

Here is the transcript the relevant portion of that interview:

Question:

What do [I] want to see coming out of HIMSS14 so [I] am even more excited next year (at HIMSS15)?

Answer:

I am pretty monomaniacally interested in workflow. Because workflow is a series of steps, each of which consumers a resource (a cost), and achieves some goal, that the value. Health IT need more success in this area.

I want to see that sixteen or twenty percent this year [of exhibitors emphasizing workflow], that was eight percent last year; I’d like to see that go to a third of the vendors. And I would also like to see big signs saying “Here’s our top ten workflow aware vendors,” that kind of marketing to reward the folks investing in this technology.”

All-in-all, I was delighted to see a doubling of HIMSS14 exhibitors emphasizing workflow ideas and technology. And guess what? You aint seen nothing yet.

Whatever else Meaningful Use has done, many proponents and opponents would agree, it’s created a multi-billion dollar industry of EHR “work-arounds.” From EHR-extenders to speech recognition interfaces to full-blown workflow platforms riding on top of EHRs and related systems, workflow infrastructure, which ideally should have been implemented in the first place, is being added piecemeal. It’s flowing around legacy systems, talking to them through APIs when available, through reverse-engineered interfaces when not. Pragmatic interoperability provides users the “What’s next?” that many current systems can’t.

Social, mobile, analytics, and cloud (SMAC) get glory and credit. But often, under the hood, is workflow technology: workflow engines, process definitions, graphical editors and workflow analytics. Some EHRs will fare better than other. EHRs with open APIs will become plumbing. EHRs relying on workflow tech themselves will more naturally meet pragmatic interoperability half-way. Or one-quarter or three-quarter way, depending on their own degree of process-aware architecture and infrastructure.

As I wrote in another blog post about HIMSS14, software application architecture evolves through generations. In other industries, software designers are taking workflow out of applications, just as they moved data from apps to databases. Many of the usability and interoperability problems be-deviling health IT will become more manageable if we stop hardcoding workflow.

If you’ll recall, earlier I alluded to relevance of pragmatic interoperability and workflow technology to usability and user experience. So, just to hammer home the idea that workflow technology is the most natural and practical way to deliver true “deep usability”, let me point out that back in 1999, the Workflow Management Coalition defined an eight level model of workflow interoperability. It started with “Level 1: No interoperability” and went all the way up to “Level 8 – Common Look and Feel Utilities: Co-operating WFMS present a standard user interface.” (ref) Interoperable workflows and workflow usability are two sides of the same coin.

Let’s represent healthcare workflow so users can understand it and workflow engines can execute it. In doing so, we’ll finally make progress toward pragmatic interoperability and usable health IT systems.


Leave a Reply