There are a number specialized vocabularies used in healthcare, many of which are designed and standardized with the intent of facilitating computer processing. One of the most familiar is the International Classification of Diseases and Related Healthcare Problems (ICD-10). It is typically used to record diagnoses (e.g., on encounter forms) and is often secondary in the sense that (in many cases) it does not record information directly entered by the clinician.

Doctor having phone call and using her computer in medical offic

Doctor having phone call and using her computer in medical office

On the other hand, an ontology known as SNOMED CT (which stands for Systematic Nomenclature for Medicine) is often used in Computerized Physician Order Entry (CPOE) systems, though ideally, its use should be transparent to the healthcare provider. Indeed, in Introduction to SNOMED CT, S. B. Bhattacharyaa says:

It needs to be understood by all and sundry that no end user on a system, irrespective of the level (0, 1 or 2) of SNOMED CT support that it has, should ever need to worry about the syntax and the associated rules governing the formation and running of any type of expressions. This should be done in the background, far away from their eyes [My italics].

This can be accomplished in any of a number of ways, ranging from menu systems to Natural Language Processing (NLP). In fact, how to make the underlying technology as unobtrusive as possible, and allow providers to work without feeling encumbered by technology is one of the biggest challenges of health IT.

This does not mean that vocabularies like SNOMED CT can or should be dispensed with in electronic health record (EHR) systems. To see why, let us consider a few differences between ICD-10 and SNOMED-CT.

  1. ICD-10 is based on a single hierarchy, whereas SNOMED CT makes use of multiple taxonomic and metronomic relations, not to mention attribute systems.
  2. ICD-10 is designed to be used by non-clinicians (such as medical coders) as well as healthcare professionals. By contrast, SNOMED CT is not normally used in this way, and if Bhattacharyya is right, it really shouldn’t be used by anyone!
  3. It is the intent of SNOMED CT to encode knowledge about diseases, procedures, etc., not merely to name them.
  4. It is common to create mappings between SNOMED CT and other vocabularies, allowing information encoded using SNOMED CT to be used to be processed programmatically, generating output using ICD-10, CPT-4, etc. (I am not suggesting that such processing should immune from review by professionals, of course.)

Software and database professionals will be familiar with the multiple hierarchies used in SNOMED CT in a different context. In Object Oriented Design (OOD) and Object Oriented Programming (OOP), we are accustomed to decomposing systems into classes and objects. Classes are typically organized into inheritance hierarchies (“IS A” relationships), which may be single or multiple. (For example, a cruise ship may be modeled as both a hotel and a ship, meaning it participates in multiple inheritance, or multiple “IS A” relationships at once.)  Classes may also be structured through composition relationships (metronomes). For example, a hotel (or, indeed, any building) may have multiple rooms. We might express this formally

HOTEL is-a BUILDING

BUILDING has-a ROOM

In SNOMED CT we have relationships that are typically modeled using attributes, and are also referred to as “HAS A” relationships. For example a disease can be infectious, be communicable, and have a causative organism. This is similar to attributes and references in OOD.

I do not mean to imply that modeling technologies such as Unified Modeling Language (UML) are exactly analogous to SNOMED CT, or to ontologies in general, but it can be useful to compare them, and really, the similarity is quite strong. It is also interesting that application users are generally not aware of the underlying model, except as it is manifest in user interface objects manipulated directly by the user. So the problem of how to avoid requiring the user to be familiar with the details of the underlying model is not an unfamiliar one, either.