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'”
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 …
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.
- 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, put 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 remain 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. 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.
- Pragmatic Interoperability: Healthcare Interoperability’s Missing Workflow Layer (Part 1)
- Task, Workflow, and Interoperability Definitions: Pragmatic Interoperability Part 2
- Human Linguistics & Healthcare Interoperability Languages: Pragmatic Interoperability Part 3
- The Linguistic Science Behind Task-Workflow Interoperability: Pragmatic Interoperability Part 4
- Task-Workflow Interoperability Benefits and Next Steps: Pragmatic Interoperability Part 5
Latest posts by Charles Webster, MD (see all)
- Makers in Healthcare - April 11, 2016
- Interoperability benefits of task workflow: Pragmatic interoperability series, part 5 - February 26, 2016
- Healthcare BPM: The science behind task workflow interoperability. Pragmatic Interoperability series, part 4 - February 25, 2016