Clinical Architecture Blog

Don’t miss this chance to make your dreams come true. 

Stop by the Clinical Architecture fortress of solitude (Booth 4863) at HIMSS and see how you can transform into the ultimate human-computer hybrid.  Map five thousand terms in 30 seconds.  Create ontologies in a fraction of the time it would take a mortal terminologist.  Perform searches faster than a speeding bullet.

We will be demoing Symedical Server version 1.1.1 and, for some lucky conference-goers, the newest thing to escape Clinical Architecture Labs…the Sift Engine.  It represents the latest advancement in “unnatural language processing”.
While supplies last we will be giving out interoperability goggles and pre-coordinated milk and chocolate.  Come by early, supplies are limited.

We look forward to seeing you there!


.

On the first day of Christmas, my informaticist gave to me
A hyper-precoordinated key

On the second day of Christmas, my informaticist gave to me
Two LOINC codes
And a hyper-precoordinated key

On the third day of Christmas, my informaticist gave to me
Three RXCUIs
Two LOINC codes
And a hyper-precoordinated key

On the fourth day of Christmas, my informaticist gave to me
Four SNOMED Concepts
Three RXCUIs
Two LOINC codes
And a hyper-precoordinated key

On the fifth day of Christmas, my informaticist gave to me
Five ON-TOL-O-GIES
Four SNOMED Concepts
Three RXCUIs
Two LOINC codes
And a hyper-precoordinated key
 
On the sixth day of Christmas, my informaticist gave to me
Six ICD maps
Five ON-TOL-O-GIES
Four SNOMED Concepts
Three RXCUIs
Two LOINC codes
And a hyper-precoordinated key
 
On the seventh day of Christmas, my informaticist gave to me
Seven representations
Six ICD maps
Five ON-TOL-O-GIES
Four SNOMED Concepts
Three RXCUIs
Two LOINC codes
And a hyper-precoordinated key
 
On the eighth day of Christmas, my informaticist gave to me
Eight mental predicates
Seven representations
Six ICD maps
Five ON-TOL-O-GIES
Four SNOMED Concepts
Three RXCUIs
Two LOINC codes
And a hyper-precoordinated key
 
On the ninth day of Christmas, my informaticist gave to me
Nine semantic primes
Eight mental predicates
Seven representations
Six ICD maps
Five ON-TOL-O-GIES
Four SNOMED Concepts
Three RXCUIs
Two LOINC codes
And a hyper-precoordinated key
 
On the tenth day of Christmas, my informaticist gave to me
Ten content models
Nine semantic primes
Eight mental predicates
Seven representations
Six ICD maps
Five ON-TOL-O-GIES
Four SNOMED Concepts
Three RXCUIs
Two LOINC codes
And a hyper-precoordinated key
 
On the eleventh day of Christmas, my informaticist gave to me
Eleven luminaries lecturing
Ten content models
Nine semantic primes
Eight mental predicates
Seven representations
Six ICD maps
Five ON-TOL-O-GIES
Four SNOMED Concepts
Three RXCUIs
Two LOINC codes
And a hyper-precoordinated key
 
On the twelfth day of Christmas, my informaticist gave to me
Twelve government guidelines
Eleven luminaries lecturing
Ten content models
Nine semantic primes
Eight mental predicates
Seven representations
Six ICD maps
Five ON-TOL-O-GIES
Four SNOMED Concepts
Three RXCUIs
Two LOINC codes
And a hyper-precoordinated key-ey-ey-ey

--

May all your holidays be happy, healthy and semantically interoperable!
The Clinical Architecture Team

The Terminology Uncertainty Principle

I am a Star Trek fan (not a Trekkie... I don't wear a tunic around the office...if I did it would be gold to signify command... but I DON'T). On Star Trek they had a piece of equipment called a 'transporter'.  It was the job of the transporter to teleport a person from point A to point B.  It does this by converting a person to a pattern of information and energy (dematerializing them), sending them through a beam and rematerializing them on the other side, hopefully without turning them inside out.

The idea of interoperability is that you are taking structured information, that is native to one system, and converting it to structured information that is native to the receiving system. This is typically done through mapping, where a source code is mapped to the single, most appropriate target code.  The objective of mapping this information is to create a picture of the patient in the target system that is as complete and accurate as the picture was on the source system. The challenge in doing this is making sure you get it right.  The Star Trek writers often had to create fictional mechanisms to make the show believable.  One of these fictional mechanisms, relating to the transporter, was something called the 'Heisenberg compensator'.  In 1927 a physicist, Werner Heisenberg, postulated that an experimenter cannot accurately observe a particle without affecting it and therefore it is not possible to truly know the state of a particle.  This assertion went on to be called the “Heisenberg uncertainty principle”.  By establishing the Heisenberg compensator the star trek writers were able to conveniently set this aside, allowing the fictional transporter to isolate the state of each particle in the source’s body and rematerialize them in their target location.  How convenient.

Truth is harder than fiction

When dealing with the exchange of patient information, in the nonfiction world, we also engage in a similar process and we also worry about turning our subject inside out as a result on uncertainty.

When dealing with interoperability is important to be aware of those circumstances that introduce uncertainty into the process and conspire against us.

The interoperability uncertainty principle that I propose is as follows:

When exchanging information between systems, the more you try to read into a surface term the more likely you are to introduce an unintended shift in the meaning of the original information.

Contributing Factors

Each time we take a patient's clinical information and convert it to another collection of terminologies a couple of factors conspire against us.  A few of these factors are transcription error, contextual ignorance and granularity. 

Transcription Error

Transcription error is the fact that due to terminology differences, software and human error, each time you transform a item you run the risk of degrading the meaning of that item.  The more items and the more transformations the more likely a degradation will occur.
Contextual Ignorance

Contextual ignorance is the recognition that all terminologies are built based on the domain view (prejudices, knowledge and policies) of the terminology publishers and that viewpoint is not inherently bound to a given term.  This being the case, when a provider selects the term, it is based on the term itself, not the context behind it.  Therefore it is important that when we convert/map the term to another terminology, we should deal with it in a prima facie manner.  To do otherwise presumes contextual knowledge that likely did not exist and could result in transcription error. 



By way of example, let's say that you come across the SNOMED disorder term 'fracture' in a patient's problem list.  Before mapping it to the target you consult SNOMED and find that the 'fracture' term that was selected was a child of 'Injuries to the skull'.  You have the choice of mapping to a local code of 'fracture' or a local code of 'skull fracture'.  Which do you choose?

In another patient's file you find that they have a severe allergy to 'sulfa drugs'.  When you go to map that to the target terminology do you look up the ingredients in that class and try to find a class with overlap in the target or do you just try to find the best match on the term 'sulfa drugs'.  When the admission clerk chose 'Sulfa drugs' do you think they researched the ingredients and chose that class based on how their terminology provider applied the class to ingredients?  Do you think they chose what they thought they heard the patient say?  Or did the patient say a single ingredient and the clerk chose the class based on their clinical knowledge.

The problem in both of these examples is that you have no way of knowing whether or not the person that selected the code was aware of the context.  If this is the case, your best bet is to choose the best prima facie match.  This preserves the integrity of the surface information, which is what the provider chose, the patient saw and the clinical decision support uses as an entry point.

Granularity

Granularity is essentially the degree to which a term specifies the concept it s representing.  For example; a drug terminology that describes my prescription as “Loratidine” is less granular than one that describes it as “Claratin (loratidine) 10 mg Oral Tablet”. This concept is also referred to as “broader or narrower than” . When conversing between two like terminologies often you run into a situation where one terminology is more or less granular than the other.  When this happens someone has to make a choice.  It is easier to go from a more granular term to less granular term if the less granular term is the primary defining attribute of the more granular term.  Using my previous example; it is not difficult to go from “Claritin (loratadine) 10 mg Oral Tablet” to “loratadine”.  It is a perfectly valid target.  I am losing information in the transaction, but that information is outside the conceptual awareness of the target terminology, which only understands generic drugs.  However, if I reverse the flow and go from “loratadine” and select “Claritin (loratadine) 10 mg Oral Tablet”, because it is the only option I have to represent the primary defining characteristic (loratadine), I have added information that is not based on facts.  One could argue that in this case, with loratadine in particular, the guess is harmless.  That agreement might change if the drug in question was warfarin and I arbitrarily selected a 10 mg strength.  Another example is the problem in going from ICD9 to ICD10.  Both terminologies can represent disorders, both are for the same source but they express like terms at different granularities which makes life difficult when you are trying to transition or correlate for one to another.



This problem with granularity will persist as long as we have more than one system using more than one terminology.  The crux of this obstacle is that sometime you have the make a leap of granularity.  Some leaps are safer than others.  What is important is that if you have information that is based on a granular leap you (a) indicate that there was a shift in granularity, (b) let the consumer know the nature of the leap and (c) preserve the original data for reference.  This way, even if you have made a bad leap, you allow the consumer to recover from it.

Design for uncertainty

In a nutshell, the answer to uncertainty is to plan and design for it.

1. Indicate which terms came from elsewhere
2. Preserve the original term for reference
3. Indicate granularity shifts
4. Resist the urge to infer beyond the surface term.

For terminology creators, remember a good term adheres to a doctrine of ‘res ipsa loquitur’ – or ‘the thing speaks for itself’. 

I hope this has been useful.  I am always open to alternate points of view.  If you have anything to add or want to argue any of these, please put up your dukes and reply with a comment or an email to me.

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.

Did you ever wonder what happens to a code when there is a lack of good semantic interoperability?  If so, please watch the following cautionary tale about a well meaning medication allergy term 'Si Metadeen'.