Medical Terminologies and Interoperability
Why are standards for various types of Healthcare IT message structures not enough for interoperability between providers? Unless one has spent a lot of time considering the intricate problems of Healthcare IT (HIT) interoperability, the problems of the exchange of clinical messages are not easily perceived. It is not just the message formats that need to be defined, it is the actual contents of the data fields which must be interpreted as well. Think about the way each provider, (be it a doctor's office or a hospital network), stores the data in their EHR system. IT systems traditionally have stored their data by storing codes which represent a set of values. Different HIT systems evolved to code their values different ways. One provider might store a Blood type of O+ as a numeric value of 1935. Another system might store the text "O+". If one look down at the bits and bytes in the actual data file, these are not the same. If one sends data alone, the meaning of the number 1935 is not easily understood by a person. One has to know the sending database's terminologies to know what 1935 meant to the sender. That requires mapping one set of codes to another so they can be translated. Once one knows that "O+" translates to 1935 and vice versa, progress is made. However, as mapping all possible clinical values takes years to finish and requires several teams of experts, it gets too expensive. Hence, in comes the need for standard international terminologies.
When exchanging data, one has to map your data elements to the data elements of the destination system. When you are sending data outside your organization or network. There is another problem inherent in mappings. That is one of the granularity of the concepts. If two systems have different granularities, that means they have established different levels of detail for similar concepts and as a consequence of that decision, the concepts will not map directly one to another. In a simple sense, one is more detailed that other.
To eliminate the need to map data, if systems use the same terminologies, they can exchange data that is understandable. Then when you send me a code 10928, I already know what that means. We both have the same standardized terminologies.
Medical Terminologies and Service Oriented Architecture (SOA)
When one uses a terminology, you can create a Service Oriented Architecture terminology service to access it. Then everyone can use a common service to query the terminology. Then you have to learn how to use the service like a method or function call. Medical Terminology differs from country to country. You can also use a terminology service to ask "How do you say Rhinitis in German?" Add to different concepts for the same word, different languages for the same word and one avoids the confusion level of a veritable tower of Babel. SNOMED CT handles these different foreign languages.
Medical Concepts: Making Sense out of Apples and Oranges
We all know the common saying about comparing apples to apples. To keep our concepts clear with medical terminology, we must also talk apples to apples and oranges to oranges. But in Healthcare IT, we have not just two fruits to keep straight, but a huge variety of data fields and EHR fruit salads concocted by an array of EHR systems. We want healthcare providers and government entities to talk each other and to private hospitals, clinics and Dr. Smith on a picture of an apple with the segments of an orange inside it. We as patients want to talk to our doctor's offices, testing labs, pharmacies, and insurance companies. The contents of the electronic healthcare records and test results have to be able to be sent, understood, and processed with the meanings intact. But the human body is complex and is subject to many diseases which are diagnosed & treated. Samples are tested and drugs are prescribed. Many hundreds of thousands of concepts are involved here.
What is a concept? If you were to tell a web browser you want to search for the keyword orange, what kind of object should it look for? Do you want the color orange or do you want the fruit called orange? There are multiple concepts of the word 'orange'. Getting to the intended concept of 'orange' is achieving semantic understanding of the data. So we have to qualify that this person wants orange as in paint and that person wants to eat an orange as in fruit. Now we know the underlying concept for the word. Ontologies are used to create hierarchies so we can pinpoint where in the hierarchy a particular concept falls.
"Medical concept representation is not an end in itself but is desirable for the capabilities it provides. There are at least three activities that would be made possible by a consistent representation of medical concepts:
1) the real-time exchange of medical data;
2) the exchange of decision-support programs including alerts, protocols, care pathways, and care plans; and
3) the pooling of data for outcomes research, quality assurance programs, and clinical research.
One proposed model of medical concept representation, which we adopt here,5 breaks the representation model into three components: a medical vocabulary or lexicon, a semantic data model (an information model), and a knowledge base. We discuss only the first two of these components in the following paragraphs.
The first component, a structured medical vocabulary, is an organized set of terms or words with associated codes. Coded medical vocabularies are one of the foremost issues in the field of medical informatics. Indeed, Dr. Smith noted that a unified controlled medical vocabulary was one of the grand challenges of medical informatics. There is a large and growing set of publications related to the development and use of structured medical vocabularies.
The second component of medical concept representation, a semantic data model (SDM), is a description (template or data structure) of how vocabulary items can be combined to make a valid representation of medical information. Semantic data models have also generated a large number of publications. Often unrecognized as SDMs are the health care data exchange standards, particularly CEN TC251/PT-00822 and CEN TC251/PT-02223 of Technical Committee 251 (Health Informatics) of the European Committee for Standardization; HL7 (Health Level 7); the DICOM standards; and specifications E123829 and E139430 of the American Society for Testing and Materials (ASTM). These standards describe the interchange format and syntax for messages that can be exchanged between medical computing systems."
Now let's take the need for semantic understanding to a document which has text about an encounter with a patient. It's a whole lot harder isn't it? A doctor has written the word "cold" in his notes about a patient. The word "cold" is called the surface form of the term. The surface form is what we humans use. But a surface form can be linked to multiple concepts. If one uses just the word cold with out the proper context, is the patient cold temperature-wise (97 degrees F) or do they have a "cold" meaning rhinitis? What is the intended meaning of cold? How do we transmit data so it has the proper has meaning? Standardized medical terminologies solve this problem. For instance a standard called SNOMED Clinical Terminology assigns concepts to these words to imbue them with meaning and context. So when we send the word cold, we will know if we mean cold as in "Rhinitis" or "I'm feel cold and I have a fever". In this extensive hierarchical framework of concepts and synonyms, one can find a resting place for unanchored parlance. An organization called IHTSDO owns and administers the terminology contained in SNOMED CT. SNOMED CT is one of the largest terminologies out there as of this date. Doctors can use these concepts, not just the surface form, to arrive at a specific meaning. Drop down lists will help them find and enter the best phrases.
The U.S. has a national license to use SNOMED. It is wonderful to have concepts attached to specific words; but if only we had that ability 30 years ago, everyone could have standardized on it back then. Before SNOMED was available, healthcare organizations developed their own reference tables of concepts and codes. That cost vendors a lot of money to develop these proprietary reference tables. Now we have many healthcare organizations with their own reference codes. So when we send data from one organization to another, we are dealing with too many different local reference terminology systems.
For example, one entity might send me the value for a piece of data called sex which contains the number 22. Say what? What does 22 mean? What happened to just "M" and "F" for male and female? Well, the FBI has 23 different codes for sex, as their values include "male posing as female", "transvestite", "female posing as male". What I expected to receive was the concept of medical gender. Really what the FBI needs is a "Sexual Appearance" concept apart from just one basic concept of medical gender. Their concepts rightly come from the job function they perform: it is their job to identify people. Healthcare providers need to treat people. Hospitals use a concept called administrative gender. They don't want to put a male and a female in the same room. Males don't need pap smears. So what is going to sort all these concepts out? The SNOMED CT is a frame work in which these concepts are sorted out in a vast carefully curated hierarchical database of 900,000 entries. In here a map is built which points individual words to their concepts properly. SNOMED CT is updated periodically by people who are professional medical Terminologists.
The International Classification of Diseases, ICD, terminology is another large terminology. When one uses a terminology, you create a Service Oriented Architecture terminology service to access it. Then everyone can use a common service to query the terminology. Then you have to find out about and learn how to use the service like a subroutine.
What is LOINC?
"The LOINC (Logical Observation Identifier Names and Codes) vocabulary is a set of more than 10,000 names and codes developed for use as observation identifiers in standardized messages exchanged between clinical computer systems. The goal of LOINC is to create standard universal names and codes for clinical observations that could be used by all clinical information systems. The LOINC names are structured to facilitate rapid matching, either automated or manual, between local vocabularies and the universal LOINC codes. If LOINC codes are used in clinical messages, each system participating in data exchange needs to match its local vocabulary to the standard vocabulary only once. This will reduce both the time and cost of implementing standardized interfaces."
J Am Med Inform Assoc. 1998 May-Jun; 5(3): 276–292.
What is SNOMED?
SNOMED is essentially a very complex hierarchical database of concepts and the medical terms which belong to each concept. The hierarchy is an ontology. The data in SNOMED is used to code, retrieve and analyze clinical data. SNOMED CT resulted from the merger of SNOMED Reference Terminology ( SNOMED RT) developed by the College of American Pathologists (CAP) and Clinical Terms Version 3 ( CTV3) developed by the National Health Service (NHS) of the United Kingdom.
By using numbers to represent medical concepts, SNOMED CT provides a standard by which medical conditions and symptoms can be referred, eliminating the confusion that may result from the use of regional or colloquial terms. The numerical reference system also facilitates the exchange of clinical information among disparate health care providers and electronic medical records (EMR) systems.
SNOMED International owns the SNOMED standard. About SNOMED
The terminology is comprised of concepts, terms and Relationships with the objective of precisely representing clinical information across the scope of health care. Content coverage is divided into hierarchies, which include:
The SNOMED concept hierarchies include: Clinical finding, Procedure, Body structure, Organism, Substance, Pharmaceutical/biologic product, Specimen, Special concept, Linkage concept, Physical force, Event, Environment or geographical location, Social context, Situation with explicit context, Staging and scales, Physical object, Qualifier value and Record artifact.
Caution! Concepts exist in multiple hierarchies. See this article on SNOMED Hierarchies by HDD Access.
Here is a SNIOMED concept and two of its synonyms, along with their respective description IDs:
Myocardial infarction (disorder): 22298006
- Cardiac infarction: 37442013
- Heart attack: 37443015
Support for multiple levels of granularity allows SNOMED CT to be used to represent clinical data at a level of detail that is appropriate to a range of different uses." (IHTSDO SNOMED User's Guide)
Concepts with different levels of granularity are linked to one another by "is a" relationships, like in UML modeling. A terrier is a type of dog. A rigatoni is a type of pasta. This enables appropriate aggregation of specific information within more detailed categories.
Relationships link concepts in SNOMED CT. There are four types of Relationships that can be assigned to concepts in SNOMED CT:
Myocardial infarction (disorder): 22298006