If you are new to the wonderful world of Medical Terminologies, it can be somewhat confusing.
This series of articles is designed to provide my perspective on what medical terminologies are, how they work, what’s good about them and what can make them hard to use. I am a practitioner of guerilla informatics. Therefore, my thoughts and opinions may not be representative of the “official” informatics community. For the record, I think that the ongoing work of the “official” informatics community is important and vital to the evolution of healthcare. My objective here is to take a complex topic and try to make it more accessible. (So don’t form a mob and come after me at the next AMIA conference…)
Why do we even care?
Why do medical terminologies exist? What useful purpose do they serve? Medical terminologies are about modeling some context that exists in the real world, and to do so in such a way that a software application can interpret and make some productive use of the information. If you look at the pre-cursors to modern medical terminology, they were used to make sure you charged the right amount for a given item. That’s right; the UPC barcode on your can of soda is a number that represents an entity that has certain attributes and a price. The NDC started out this way as well, inventory and pricing. In modern healthcare applications we have used terminologies, in some form or another, for many years. We have used lab test terms to order lab tests and receive results. We have used NDC codes to reimburse pharmacies for dispensed medications. We have assigned identifiers to individuals to aggregate charges.
The electronic medical record has upped the ante, as it establishes a use model where more of the patient’s clinical context needs to be codified and structured. This creates many opportunities for us in the healthcare industry, to do more interesting and productive things in the software we develop. These opportunities will provide new avenues for content and software development and, if we do our jobs right, enhanced information for providers and improved outcomes for patients.
So, why do we care? To paraphrase words of the late great John F. Kennedy, “We choose to go to the moon in this decade represent patient context with medical terminologies and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win” (Please wait while I turn off the inspirational music and climb down off my soap box…)
Terminologies, Vocabularies, and Ontologies. Oh, my!
There are a lot of terms (pun intended) that get thrown around when you start talking about representing context. Terminologies, vocabularies, nomenclatures, taxonomies and ontologies are only a few. I will focus on terminologies and ontologies.
For the purpose of our discussion, a terminology is a collection of stable terms that represent the concepts within a specific domain. Each term should have, at a minimum, a stable identifier and a human readable description. A simple example of a terminology we all use every day is phone numbers. The phone number is stable (alright – semi-stable) identifier that is associated with a concept (a person or business that I may need to contact) that has a human readable description. When you enter friend’s numbers into your cell phone you are actually sub setting a multi-region hierarchical semantic terminology (and you thought informatics was complicated…)
The thing to remember is that terminologies represent concepts or things that exist, either as tangible items or abstractions, in the real world. An example of a tangible item is a pill. A 5 milligram warfarin tablet is a real thing that you can put in your hand so you can understand the concept of a 5 milligram warfarin tablet and assign it an identifier.
An example of an abstraction is the ingredient warfarin. You can’t put a notion of a single ingredient, like warfarin, in your hand, but your mind can grasp the notion of warfarin as a concept.
Now a good terminology has certain characteristics beyond an identifier and a description. I will go into those in another article.
Ontology is the philosophical study of the nature of being, existence or reality in general. Sometimes called a controlled vocabulary, a medical ontology is a collection of terminologies that are organized into relationships that are meant to simulate the nature of those concepts in the real world.
Most content providers have ontologies. For example a drug product terminology typically has component parts that represent routes, dose forms, ingredients and units of measure. The relationship between the drug product and these component terminologies is an ontology. In SNOMED the relationships between conditions and their broader or narrower variants is a terminology.
An important thing to remember is that since an ontology represents the existence of a set of terms within a context, the ontology itself is subjective. This is why different content sources, even though they have ontologies that model the same domain, can do so in very different ways.
For example, some content vendors provide a drug terminology that ontology includes the notion of route. Other content vendors may represent the same terminology absent route. The difference between the two is whether or not the route is considered part of the drug concept. Opinions differ since route is not physical attribute of the drug. Ontologies will be discussed more in a future article in this series.
The Patient Domain
When using medical terminologies to model patient context the domains you see most often expressed are: medications, allergies, problems, lab results and demographics.
Some of these domains are more mature than others. Medication terminologies, for example, have been around for many years and have typically been controlled by a handful of content vendors. Lab terminologies have also been around for many years. However, lab terminologies have typically been represented by homegrown code sets. This situation results in very stable local codes, but virtually no ability to exchange data with other systems and meaningful ways.
When considering terminologies, there are certain characteristics that will provide the implementer with an idea of what potential issues are in store for them.