Category: Clinical Software Design Principles

Clinical Concepts vs. Chart Concepts – How Do They Differ?

I was goaded into mulling over this question by the same concerns that led to my writing, Is the Electronic Health Record Defunct? I am worried about being trapped in a paper-oriented thinking mode when designing clinical apps.   That trap is easy to fall into because patient information is essential to patient care.   All clinical work requires access to patient information, so it is easy to jump straight to thinking about what information to store and how to store it. Once snared, taking the next step of borrowing design ideas from paper charts is hard to resist. How does one separate clinical care concepts from chart concepts when creating software???

Let’s start with medication and problem lists. What concepts do these lists embody or convey?   Understanding why I ask this question requires a bit of a philosophical diversion.   A word, sentence, or phrase has a meaning (semantics). For example, the word aspirin has a meaning—it is a non-steroidal pain medicine and anti-inflammatory agent. It also may denote something specific (i.e., an enteric coated tablet in my hand). However, it is possible for a word or phrase to have semantic import (meaning) and yet denote nothing.   Bertrand Russell illustrated this point with his storied example: “The present king of France…” Semantically speaking, anyone who understands English knows what this phrase means. The problem, of course, is that there is no king of France. Semantically, the sentence is fine; however, it denotes nothing. Now, back to clinical vs. charts concepts.

When a clinician uses a nomenclature such as RxNorm to add a drug to a patient’s current medication list, we can be sure that the semantic properties of the term are intact. However, if the patient never receives, refuses, or stops taking the drug, that RxNorm term now listed in the medication list no longer denotes a real fact about the patient.     Here, we have a clinical care concept – the clinician deciding/intending to give the drug – rendered in the patient’s medication list; however, the term does not correspond to the patient’s actual situation.  A drug being in a patient’s medication list has a meaning, but not necessarily any denotation.   Now, here is my question to all of my philosophically-inclined readers: When building clinical care systems, should we design systems to avoid semantic/denotational mismatches?   Stated another way, should we record the intention to give a medication in a different way than the way we record that a patient is definitely taking the medication?

Semantic/denotational mismatches are patient safety issues because when they occur, they convey false information about the patient.   Medication reconciliation helps to address this with medication issues, but what about problems/diagnoses?

A problem/diagnosis listed in the patient record implies that the patient has that problem. By extension, the absence of a problem implies it isn’t present in the patient.  Every incorrect entry in a patient’s problem list is a semantic/denotational mismatch.  What havoc might result for decision support users? How can a system’s design reconcile the clinician’s belief/intent with the actual state of the patient?

It seems that for any item listed in a chart, there needs to be some way of ensuring that it denotes something about the patient.   What is the problem list equivalent of medication reconciliation?

Aside from semantic/denotational mismatches, there are other clinical concepts that have no natural home in the chart. Is therapeutic efficacy the same thing as the patient has been taking a drug for x number of years???   When does a drug being removed from a medication list denote therapeutic failure???

At some point in system design, classes are created and behaviors are assigned to them. So eventually, semantic/denotational mismatches become a design challenge—as they have for me.   All the possible solutions I imagine require system designs unlike anything that currently exists. Patient-facing health record apps would have to become integrated in some way with clinicians’ systems, allowing for feedback on medications and diagnoses. Having had my first personal experience with the patient portal of a major vendor, I can say that seems to be far off.

Levels of “belief” would have to be built into every captured data element.   For example, it would be necessary to have diagnoses marked as provisional unless other data in the system corroborated the entry.   Algorithms that surveyed patients looking for undiagnosed conditions would be required as well.

Perhaps we need EHR designs that allow clinicians to enter diagnostic and treatment plans that are then converted into decision trees where intentions/decisions are made explicit to anyone caring for the patient.

I may have wandered off the deep-end with my speculations, but I am sure that we can all agree that semantic/denotational mismatches are dangerous. Now, as to how one might address this problem through specific design innovations…well, that requires a lot more thought. Meanwhile, time to get back to prn: OnCall.