Clinical Architecture Blog

Clinical Terminologies in Healthcare Applications - Part One

But Charlie, you look so young!

Over the past two decades, I have been on the battlefield of Healthcare IT.  Throughout this time, I have been in many roles, ranging from programmer and systems designer, to chief technology officer.  During this time, I have had the opportunity to observe a number of applications in the healthcare space.  Some of these applications have been simple and some complex; some dealt with administrative aspects of care and some that meant the difference between a safe patient and a patient that ends up in a statistic that gets quoted in an ISMP report.  I have learned from my successes, my mistakes and the successes and mistakes of others (yes, I have been watching you).

What follows is a collection of my observations with regard to the role of clinical terminologies in healthcare applications and how I believe it will change and be changed by the evolution that is happening even as I write this post.

A Wise Man Once said… or was it me?

A “healthcare provider” is ultimately the sum of a skilled human being, their physical tools (facilities, equipment, devices, medicines and instruments) and their information technology (Paper files, forms, software applications and data).  In this symbiotic triplet, each group (Humans, Tools and Information Technology) evolves and grows as our knowledge and capabilities grow.

The objective of the evolution of the physical tools is to enhance the physical capabilities of the human.  Improve their ability to observe things, remove things, kill bacteria, stop a cancer or trick some biological mechanism to behave in a particular manner.  In essence, improving their ability to detect and affect things within the scope of their objective.

The objective of the evolution of the information assets (beyond paper and file cabinets) is to enhance the mental capabilities of the human.  Improve their ability to recall information, expand their knowledge, increase the speed at which they can process information and bring awareness to them of things outside of the range of their human senses.

Last but not least, the humans themselves are prone to natural evolution, expanding their understanding with dedication, intuition and insight.  They are also tasked with driving the evolution of the other two members that have already been mentioned.

The most recent addition to this grouping is that of information technology as a successor to paper, books and filing cabinets.  These information technology tools are what I will be focusing on.

I will assume that, if you are reading this post, you understand the primary functions of a healthcare provider.   That being said, let’s start by summarizing the primary functions of healthcare information technology systems. 

Here are five of its most critical capabilities (over simplified for the sake of brevity):

  • Record and store information about providers, physical assets and services
  • Record and store information about patients
  • Record and store what we currently know about the practice of medicine
  • Record and store the relationships between these elements as we become aware of them
  • Provide this information (or any combination thereof) to a provider and administrators as needed in order to assist them with their objectives

In order for the HIT application to perform its functions well, two things must happen, (1) the information must be entered into the application by a provider and (2) when the time comes, the information must be presented in a manner that the provider can understand.

Sounds simple right?  It would be, if not for a couple of issues…

Human-to-Computer Interface

The Human-to-Computer interface is fraught with inefficiency.  We are constantly looking for ways to improve and expedite this most inelegant of relationships.  But whether we use mice, keyboards, voice recognition or touch screens, the problem remains.  When you think about it, the human mind works fairly quickly (well… after some coffee) as does a computer processor.  When we try to move information from one to the other, it is like a freeway onramp that requires to you get out of the car, disassemble it, push each part through a doorway and reassemble the car to continue.   Seriously, think about it.  In fact, in the time it took me to type this, I thought up seven other metaphors for how inefficient the human to computer interface is, but it would take me too long to go back and type a better one.

Human to Human Interface

Have you ever engaged in the dangerous habit of sending an email to another human?  Has it always panned out the way you intended?  No?  Well, there is a reason for that.  The human mind is not a processor of information; it is an interpreter of information.  When presented with data it goes through a process of cognitive filtering and interpretation that is fraught with intellectual, personal and contextual biases.  In other words, the human mind is local.  So when you tell your spouse they look “fine” you have no control over whether “fine” will be interpreted as “Sure, I guess you look fine (meh)” or “Damn! You look FINE!”.  

The other night, I gave my fifteen year old son the following instructions: “Max, I left the sprinklers on in the yard.  Please go outside and shut them off.”  These were simple, straight-forward instructions (even for a teenager).  He dutifully left the room and came back about ten minutes later.  I thanked him and he said “You’re welcome, Dad.”  It was a well-formed transaction with a flawless acknowledgement mechanism.  When I got up the next morning to catch a flight, I walked out the front door and both sprinklers were going full blast and had obviously been doing so all night.  What bothered me the most was the following question, “What exactly did Max do during those ten minutes?”  Just in case, I checked the gas on the grill in the back yard.  To this day, I have no idea what he did.

This ability to misinterpret language is exacerbated when the communication is devoid of vocal tone and body language, which is the case when text is exchanged.

Clinical Terminologies as a Lingua Franca

Clinical terminology is how we record information about a patient.  We do this in an attempt to create a record that both the computer and other humans can utilize in the performance of their duties.   In the best circumstances, these terms are stable, well formed, unambiguous and of appropriate granularity for their purpose (and NOT concatenated…grrr).  The problem, of course, is the human (they are cute, when they are small).  The terms are selected by a human being (with all of their biases), jammed inefficiently through the human to computer interface, so that they can interpreted by a software program (with its unforgiving logic) and other humans (with all of their biases).   Oh… did I mention that the terminologies are created by humans?  Also, it is important to note that these terminologies are constructed within specific ontologies.  According to Wikipedia: “Ontology deals with questions concerning what entities exist or can be said to exist, and how such entities can be grouped, related within a hierarchy, and subdivided according to similarities and differences.”  In other words, ontology is a collection of intellectual, personal and contextual biases.

Now is when I calm everyone down. 

I am not bashing clinical terminologies or those brave souls that craft them in the forges of their intellect.  We do not have a better alternative.  All I am suggesting is that we respect the fuzzy nature of the delicate process that is in play here.  We accept the uncertainty and resist the urge to give ourselves over to the notion that if we build a model finite enough, and a computer fast enough that fuzziness will disappear and the human can sit back and relax.  It may happen someday, but not likely someday soon.    This understanding and acceptance of the uncertainty of information is what I call the Clinical Terminology Uncertainty Principle and it is the subject of my next post.
Posted: 9/3/2011 3:26:28 PM by Global Administrator | with 0 comments
Comments
Blog post currently doesn't have any comments.
Leave comment Subscribe



 Security code