Clinical Architecture Blog

The point of a software application in a healthcare setting is essentially to (1) improve patient care (2) assist providers in providing care (3) make the processes involved in patient care more efficient, (4) leverage all of this to help manage costs over time and (5) make sure I am getting paid the for services I provide.

 Now, behind closed doors it isn’t always prioritized in this way, but these are usually in the top-ten list of “whys”.

One of the main drivers of better software solutions is the notion of Clinical Decision Support or CDS.  This is the idea that a provider can’t keep everything in their head so we should augment them with extended clinical knowledge and the logic to apply it appropriately to their patient.  This is a good idea and we are slowly evolving in this direction.  We are still struggling today, primarily because the knowledge is too blunt and what the application knows about the patient is sketchy.  This is due to a number of issues, two of which are the lack of structured/coded information and also the absence of information from other care venues.   To address this we have “meaningful use” which promotes structured data and sharing across traditional information silos.

So to summarize, our goal is to capture and store clinically accurate structured terms so that our applications can leverage them for Clinical Decision Support.

If you are with me so far, then we need to ask a question.  Do the terminologies we are searching for, storing and exchanging provide a foundation for what logically comes next?  Are we strategically positioning ourselves for what is considered by many to be “the whole point” of an electronic medical record?

In order to provide good information in our patient records, we first have to find the term that most accurately describes our observations, diagnosis, treatments and procedure.  Finding the right term can be difficult because we humans are capricious.  We operate within our own contextual bias and want to describe something the way we think about it.  To accommodate this, for a given set of terms, we establish keywords, abbreviations, mnemonics and aliases.  In the informatics when you establish variants of a concept to enable searching or presentation this is commonly referred to as an ‘interface terminology’ and the concepts that they relate to are in a ‘reference terminology’. 

Most people prefer an interface terminology because they are, by their very nature, more familiar. The problem with interface terminologies is that they can also serve to hide the actual reference terminologies that are, due to their conceptual nature, designed to drive what happens behind the scenes.  

When you are working with an interface terminology you have to remember a few rules of thumb.

• Good interface terms are in conceptual alignment with the concepts they relate to. 

An interface term should not represent more or less information than their concept does.   For example a good interface term for ‘leg fracture’ would be ‘busted leg’ not ‘busted right leg’.

• Good interface terms are complete

• Good interface terms indicate both language and purpose

• Good interface terms are stable

A good rule of thumb is if you take a given interface term an put it in front of any member of the intended audience would they be able to (a) understand what the term means and (b) pick the concept behind the term out of a list?  If the answer is “yes” then the interface term is good. Remember that the concepts behind the “friendly” terms are the whole point and will be what truly matters in the next stage of our evolution as an industry. 

Clinical Architecture’s Symedical Server provides comprehensive support for interface terminologies and reference terminologies alike.  The search engine handles common mnemonics, partial words, acronyms and abbreviations for any terminology.  It also supports the creation of local keywords, aliases and even local terms without compromising terminology updates from the source.  Our mission is to help you prepare for the next logical evolutionary step while meeting your tactical objectives today.  Give us a call and let us show you a better way forward.

Let's start with the word coordinated.  Remember, we are talking about a term, which for our purposes is a stable identifier associated with one or many words meant to express a concept or idea. (term= code + description).
 
When you create a term, you are coordinating a set of words together into a concept to represent some piece of relevant information.  You do this all the time.  You did it the last time you ordered an “extra dry grande soy latte with two packets of Splenda” at Starbucks.  So, the act of assembling words to express an idea is the act of coordination. 
 
So what about the “Pre-” and “Post-”? 
 
The "pre” and “post” prefixes have to do with when the coordination was performed relative to when a code was assigned (or at least that is how I think about it).   
A “Pre-coordinated term” is a term that was coordinated and assigned a code before you needed it. 
 
A “Post-coordinated term” is a term that you assembled from other terms at the point when you needed it.  (So the coordination of the notion happened “post” stable code assignment to the TERMs used to represent it.)
 
A simple, non-healthcare, example is a value-meal at a fast food restaurant.  The value-meal is a Pre-coordinated meal.  When you walk in and order the value-meal the cashier presses a single button that represents your meal and it is ordered.  If, however, you don't want the value-meal and you order items a la cart, the cashier presses however many buttons they need so that they can accurately convey the details of you order.  They are “post-coordinating” items together at time of consumption (and thinking you are high maintenance).
 
When you consider this and think about healthcare terminologies, you quickly come to the realization that we live in a world that is predominantly pre-coordinated.  Here is a partial list of terminologies we use in Healthcare that are pre-coordinated:
- ICD9
- ICD10
- LOINC
- RxNorm
- CPT
- FDA NDC
- SNOMED-CT (parts of it)
- HDD (parts of it)
- Most commercial terminologies
- Most local terminologies

Here are some established terminologies that are designed for Post-coordination:
- SNOMED-CT (parts of it)
- HDD (parts of it)
- RadLex

Notice a difference?

Why so many pre-coordinated terminologies in Healthcare?
 
To answer the question “why?”, lets consider the pros and cons of each coordination approach.
 
Pre-coordination

Pros:

• It is easier to manage a “flat” Pre-coordinated terminology with legacy content management methodologies. 
• The fact that they are created ahead of time means that they should always represent a valid concept in the domain.
• It is easy to store in a database.  Since it has a single code pointer to a concept it fits into the way we have always thought about terms.

Cons:

• The entity maintaining the terminology has to Pre-coordinate an idea for it to be represented in the terminology.  (You have to order off of the value menu - no substitutions).
• To understand the parts of a term you need to create explicit relationships to other term.  In other words the work you did to Pre-coordinate the term is not represented in a structured way.
• In order to represent every possible combination terminologies can become very large.
• Adding a new axis of information can create significant ripples across a terminology and require a large amount of maintenance to instantiate.
• Since clinical decision support is often triggered on primitive concepts, complex Pre-coordinated terminologies must be pessimistically linked in order to work.  For example, in the CMS quality measures there is a measure that excludes patients if they have had an X-ray procedure.  In order to drive this rule that notion “x-ray procedure” is linked to hundreds of Pre-coordinated LOINC and CPT terms that have in them the notion of “X-ray procedure”.  In a well defined post coordinated terminology this would be a single link to the modality “x-ray”.  This issue can be solved ontologically but requires a fair amount of work behind the scenes.

Post-coordination

Pros:

• Smaller, primitive terminologies designed to be assembled into complex post-coordinated terms.
• Consumer can “build their own” notion based on the primitives.
• Decision support rules can be driven by post coordinated partial assemblies and use optimistic linking.

Cons:

• Without some rational grammar a consumer could post-coordinate an invalid notion from the available parts. This means that a well designed Post-Coordinated terminology would have a grammar where necessary to prevent this from happening.
• We would need to consider how we store and represent post-coordination in our applications.
• Post coordinated terminologies are ontological in nature.  This means maintaining them is not a simple as a flat list of terms. 

When you examine the pros and cons (which are almost reciprocals of one another) you can see that Pre-coordinated terms are the easy path for those of us that build software and content (at least initially) and Post-coordinated terms are better for the consumer trying to leverage the software in their care process.
 
Where does one approach make sense versus another?
 
Pre-coordination is a reasonable approach when you are dealing with a domain that has finite boundaries.  Medications are a good example of this.  There are a finite number of combinations of ingredients, dose forms and strengths.  This gives the person coordinating those notions a solid basis to say “these are the valid terms in this domain”. 

The inverse of this is a domain where there are an infinite number of potential combinations, like Problems.  In a Pre-coordinated terminology if you want to represent fractures you need to associate the notion “fracture” with any bone that can be fractured.  If you want to further denote the type of fracture you take those notions and associate them with each fracture type.  If you want to say the patient has a “history of” fracture, you do it again.  Anyone that has taken a close look at ICD10-CM knows what happens form there.  On top of all this, it doesn’t take much for you to realize that the concept you want to express has not been Pre-coordinated... So you pick the closest thing you can...and information is lost.  '

A terminology in a domain that has an infinite or even a very large combination of notions should ultimately be represented by a post-coordinated terminology.
 
If post-coordination is better in some circumstances, what is stopping us from adopting it in healthcare?
 
Anything that represents a fundamental change is hard. It is even harder if the change is something that is not felt directly by the consumer or when it is designed to improve something later.  As long as we chase short term, buzzword oriented, goals and ignore the strategic evolutionary adaptation required for a well positioned clinical architecture, we will continue to fall short of becoming the awesome sidekick we can become.
 
There is movement in this direction.  SNOMED-CT has been heralded as a terminology that supports post coordination.  It needs some work, but it is a good starting point.  I have also been told that ICD11 is based on post coordination...

RadLex is based on post-coordination but has struggled to gain adoption.  I think the existing post-coordinated terminologies have struggled because:

1. Post-coordinated terminologies are deceptively complex to manage, especially using legacy oriented tools.
2. They try to straddle the worlds of Pre/Post-coordination.
3. They try to leverage overly generalized, academically oriented structures.
4. We, as an industry, have not been ready for them.

At ClinicalArchitecture we are building technologies that will help our partners evolve the way they use terminology, regardless of how it is coordinated.  The truth is, if you are building an EHR system you just want the terminology to work and do so in a way that allows you to delight your customers.  This is one of the reasons we started the company back in 2007.  This fundamental shift is not going to be easy and as long as the entire industry is running, heads down, it will not happen. 
 
Someone needs to be focused on solving this problem of plumbing...Someone is.
 
Come by and see us at HIMSS - we will show you what the future looks like (and give you some cool stuff).
 
If any of my learned collegues in the industry would liek to add their thoughts please feel free to add your comments.

If Healthcare were an epic blockbuster, it would be a story that would revolve around four main characters: The Patient, The Problem , The Provider and HealthcareIT. 

The Patient is a sympathetic character - they are in trouble and the odds are stacked against them. 

The Provider is the hero,brave and bold and prepared to do whatever it takes to help the Patient against the odds. 

The Problem is the villain in this story, malevolent and inscrutable, it stalks the Patient and conspires to thwart the Provider's best efforts to keep the Patient safe.
 
What is the role of HealthcareIT in this story?
     
I am sure we can all think of stories we experienced where HealthcareIT fit in each of these roles.  The important thing to remember is that these are all supporting roles. HealthcareIT is never the hero.  This can be hard to take as a solution provider, as everyone wants to be the hero.
 
Don’t get me wrong, the sidekick will have their moments to shine.  Whether they are telling the hero that the villain has a glass eye, they shout “duck!” at the right moment or they discover that “to serve patients” is a cook book, their support can mean the difference between a happy or unhappy ending. Regardless of the circumstances, for the sidekick to make a difference, they need to do their job supporting the hero.  If the sidekick forgets this, they run the risk of getting in the way of the hero, or worse. 
 
So, if we are to embrace our role as sidekick, what would make us a good one? 

The characteristics of an good sidekick:

Knowledge - the best sidekicks are those that have access to information.  Especially information that the hero needs to do their job.
 
Understanding - they need to understand what the hero is dealing with so that they can apply their knowledge in a way that provides meaningful advice (as opposed to trivia).
 
Experience - a good sidekick remembers previous capers.  This experience augments their knowledge and understanding and keeps the hero from repeating mistakes made in the past.
 
Timeliness - they need to be there when the hero needs them.
 
Respect - they need to remember that the hero is in charge...unless.     
Where are we today?
 
I think that if you were to ask providers, a number of them would say “Stay in the car”.  This is a reflection of where we are in our evolution as an industry.  We are feeling the growing pains of orchestrating the art and science of medicine, the ambiguity of human communication and the complexity of knowledge representation into something that will help providers do their job.
 
We are making progress and will continue to do so.  The intervals between our shining moments are getting shorter.  If we remember our role, and focus on expanding on those abilities that will make us awesome sidekicks, we can play a significant role in the healthcare story. 
 
Clinical Architecture’s mission is to provide the tools to enable Healthcare IT to be a better sidekick, to turn providers into Super Providers.  We believe that technology specifically designed to focus on the characteristics that make an excellent sidekick, through our relationships with innovative partners, will act as a catalyst in Healthcare IT.
 
We can't change the role that we will play, but we can change the story.

 

Clinical Architecture will be exhibiting at HIMSS this year in New Orleans
 
Just wanted to share that we will be exhibiting at HIMSS this year and I am very excited about it.
 
Here's why:
 

1. Apparently I will be a contestant on QUIPSTAR in the Medicomp booth.  I will be pitted against Dr. Jayne from Histalk (who will be disguised, I imagine).  So if you want to see a mighty, masked clinical warrior mop the floor with me using only an iPad, you should stop by. 
2. Histalkapalooza should be a blast this year at the bowling alley. CA will have a team competing.  I hate to brag but when I was nine I was in a league...I even had my own ball.  I had special shoes, but that had nothing to do with bowling.
3. I have been going to HIMSS for a long time and New Orleans is always an interesting venue.  Good food, nightlife, the longest exhibit hall in the known universe.  I have some recommendations below for the first time Nawlins HIMSS pilgrims.
4. We have the same booth as last year, nestled behind the GE Healthcare villa.  Our booth number is 1463.
5. We have a ton of awesome features in version 1.4 of our Symedical product to show off this year:

• Symedical Knowledge Portal
• Content distribution server
• Reference Ontology Manager and subset designer
• Term Enrichment module
• The Sift Engine - targeted language processing
• Symedical Smart Search and Nymble Search
• Mapping on steroids
  • new mapping algorithms
  • rule based, qualified maps
  • consult windows - harness collective reasoning
  • quick map agent - mapping has never been easier
• Many other enhancements designed to change the way you acquire, manage, interoperate and distribute knowledge in your HIT architecture 

I hope to see you there and if you say "Charlie sent me" at the booth there is a special give away just for you.  (Supplies are limited so get there early).

---

Recommendations for your New Orleans HIMSS visit:
 
Breakfast
 
If you like a down home breakfast, and don't mind standing in line for a few minutes, I strongly recommend “Mothers” at 401 Poydras street.  They are known for their baked ham but their breakfast is awesome.  It is walkable from the convention center.
 
Lunch
 
If you have the time and stamina to extract yourself from the convention center for lunch I recommend "Mulate’s". It is right across the street from the convention center and it is good and not expensive (compared to the outrageous prices for typical convention hall fare)

Fine Dining

Arnauds is described as the ultimate cajun dining experience.  It is a bit pricey, but I have never had a bad meal there. 

24/7 Eats

It is New Orleans and you should be getting your rest so that you can pay attention to those fascinating sessions... but I kow you better than that.  Daisy Dukes is open 24/7 and there are free refills on coffee and Bloody Mary's!! (do you know where your CTO is?)

Night Life
 
Pat Obriens is an atypical piano bar off of Bourbon street that is a lot of fun. I am not much of a drinker but I know a few... And they highly recommend it.  It is loud and packed and irreverent.  Much like Clinical Architecture HQ with more pianos.
 
Coffee and “Donuts”
 
If you have never been to New Orleans you should definitely go to Cafe Du Monde. Its menu consists of dark roasted Coffee and Chicory, Beignets, White and Chocolate Milk, and fresh squeezed Orange Juice. The coffee is served Black or Au Lait. Au Lait means that it is mixed half and half with hot milk. Beignets are square French-style doughnuts, lavishly covered with powdered sugar.
 

Recently the VA and DOD announced that they have licensed 3Ms Healthcare Data Dictionary, or HDD, for open use as 'HDD Access'.
 
As someone that has spent a fair amount of time with the HDD, I think that this announcement represents something very exciting for those of us trying to leverage structured information in healthcare. I have to assume that there are a number of people out there that do not have an understanding of what the HDD is and how it can be used.
 
First of all, I should share that most of my knowledge and experience with the HDD is based on a core HDD.  I am not sure how that translates to the ‘HDD Access’ version that will be released over the next 12-24 months.  This being the case, I will focus more on structure and the features of the structure rather than the content itself.
 
HDD Access is described on its website as an “Enterprise Reference Terminology (ERT) that serves as the foundation for data management”.   The HDD is primarily comprised of four core tables as described on the HDD Access website.  These tables are CONCEPT, RSFORM, RSFORM_CONTEXT and CONCEPT_RELATION.



Concepts

The CONCEPT Table is where the concepts are stored.  The primary key is called the ‘Numeric Concept Identifier’ or ‘NCID’.  As the name implies the NCID is a meaningless numeric identifier (or Dumb Number as some people like to call it) which is a good thing.  It is also supposed to be stable, which means that once a concept is introduced it is never deleted, which is also a good thing.  A concept has a status that indicates if it is still active and the status itself is also an NCID.  Every NCID is associated with and Enterprise identifier (Enterprise_NCID) that identifies the source of the NCID.

An organization can be issued an Enterprise_NCID and can then create their own NCIDs within an assigned NCID integer range.  This is the mechanism currently in place to extend the concepts in the HDD to support local or unique concepts.  This must be done with caution as adding local terms to a ‘standard’ terminology will create semantic drift that will require cleanup later if you want to take advantage of the standard.

Representations

The RSFORM and RSFORM_CONTEXT tables work together to allow concepts to have multiple contextual representations.  Representations have a unique numeric identifier as well called the RSFORM_ID for each unique representation associated with an NCID.  A representation will also have one or more Context_NCID that provides context relative to the nature of the representation. A context allows a representation to be more than just a synonym.  This difference, though it may seem small, has a significant impact in terms of utility.


For example, you can have display contexts like ‘patient oriented display context’ or ‘provider oriented display context’ to show synonyms for use under certain circumstances.  You could also have interface contexts like ‘SNOMED-CT interface context’ or ‘ICD10CM interface context’ that allow you to associate code values to a given concept as representations.  Since contexts are concepts themselves they can also have relationship and conceptual hierarchy, this allows you to group contexts into subsets like ‘Display Contexts’ has child ‘patient oriented display context’.

Like concepts, representations have an associated Enterprise_NCID and can be extended using an assigned range of numeric RSFORM_IDs.

Relationships

The CONCEPT_RELATION table has the relationship between a source concept and its related concepts.  Each relationship has a relationship type (RELATIONSHIP_NCID), which is also a concept.  A relationship will also have an Enterpirse_NCID associated with it.  While this type of structure is not uncommon when compare to other ontologies, like SNOMED-CT, the HDD tends to have more explicit relationships and avoids the overuse of the ubiquitous ‘IS A’ relationship preferring instead the more specific ‘has Child’ and ‘has Member’ type relationships that I tend to prefer.


Relationships in the HDD can be used to describe conceptual hierarchy and taxonomy but are also used to denote defining attributes and properties of a concept.

The Structure in General

The HDD has simliar structural characteristics to SNOMED-CT and in some ways the UMLS metathesuarus so it can support some fairly sophisticated patterns.  It can get complex when you are trying to isolate a specific valueset but the granularity of the relationships and the ability to filter representations by context are worth the additional work.  When 3M releases the information models I will dive deeper into the structure and with their permission I may even put together a screencast.   

The Timeline

On the HDD Access website they have a timeline that you can hover over and magnify.  Here is the timeline in tabular form (dates approximated from timeline graphic):



 
Summary

I think that, much like SNOMED-CT, LOINC, RxNorm and the UMLS Metathesaurus, the HDD Access offering will be an excellent resource that has the potential to make a difference in healthcare IT. 

Our objective at Clinical Architecture will be to ensure that Symedical® Server, our state of the art terminology management and interoperability platform, will enable our clients to take full advantage of the HDD Access content.  This will include capabilities like managing local subsets, enhanced mapping, sophisticated customizable search and ontology traversing.  We will also support advanced terminology and ontology management with the ability to publish local enhancements directly to the HDD schema.  These capabilities will be released in Symedical® Server in advance of the first release of the HDD Access content.

We are happy share our thoughts and experience with anyone who would like some assistance with the implementation of the HDD Access content and structures in addition to any other terminology source in the public domain.  Please feel free to contact us here at Clinical Architecture, if we can be of service.

If there is interest, I would be happy to create follow up posts that compare the HDDAccess model with SNOMED-CT and UMLS Metathesaurus. 

If anyone has any corrections or other feedbck, please feel free to leave them in the comments.