Healthcare Terminology Systems Explained (part 4)
This is the fourth and final article in our series on Healthcare Terminology Systems Explained. In our previous articles, we explored why clinical terminologies matter, how they are released, and their common components. Now, as we conclude, we examine the significant challenges of working with healthcare data—such as data silos, quality issues, and a lack of standards—and discuss how thoughtful use of data models can help overcome them.
👉 To see how these concepts apply in practice, visit TermHub, our platform for exploring, managing, and integrating healthcare terminologies.
As the final installment in this series, we build on Part 1 (Clinical Terminologies and Why They Matter), Part 2 (How Clinical Terminologies are Released), and Part 3 (Common Clinical Terminology Components).
What Makes Healthcare Data so Difficult?
There are many factors that make it difficult to interact with healthcare data and ensure that it is interoperable and reusable. The US Healthcare system is a complex network of systems that can be difficult to connect, have varying level of recorded detail, and can use differing standards. All of this makes true interoperability within healthcare difficult and costly.
1. Data Silos
Healthcare organizations are typically made up of many different IT systems, all of which need interfaces between them to facilitate the exchange of data. Even in large organizations that have more integrated systems, like the Veterans Health Administration’s VISTA system (they are in the process of moving towards Cerner), there may be different implementations at the various sites within the organization. For example, VA has 130 different implementations of VISTA, each of which has been modified from the original VISTA.
2. Data quality
There is a balancing act we face with healthcare data. When recording data we want to describe what is being observed and performed easily and fully. We also want to be able to retrieve that data easily and accurately after it has been recorded. How clinicians describe patient encounters and the need to make data entry efficient, does not always correlate with easy retrieval or secondary uses of the same clinical data.
For example, if a clinician wants to enter “Back pain due to spondylosis” into a patients record, there is no single concept that represents that phrase. They could search and add two separate codes, one for backache and one for spondylosis, but that requires a number of extra steps to add both concepts and link them together. These extra steps make it not as efficient as searching and finding the single term.
3. Not using standards (or using overlapping standards)
Healthcare organizations have developed and often use legacy systems that have non-standard data models and use locally developed, non-standard terminologies. Even modern healthcare systems typically use a proprietary data model. Though they have begun the move towards standard terminologies, though they have begun moving toward standard terminologies, often by mapping local codes to them. Therefore, the legacy data in older systems may not be compatible with newer systems that do use standards more rigorously.
Even among standards there can be significant overlap and if not implemented correctly can cause interoperability of systems to be difficult. We talked about this in our Healthcare Terminology Systems Explained (part 2) article. We will discuss this overlap of standards further below.
4. Cost
The combination of a lack of standards, overlapping standards, poor data quality, and siloed data makes it very costly to achieve true semantic interoperability. With overlapping standards, one needs to understand all the different ways standards can be used to record data and be able to detect ambiguous or equivalent representations. In a situation with poor data quality, critical information could be missing and extra time processing data to ensure an accurate understanding will be required. In a situation where data is siloed or built on proprietary systems, interoperability interfaces will need to be built between all systems involved.
What Does “Separation of Concerns” Mean in Healthcare Data Standards?
As discussed above, the various healthcare standards required to record data have overlapping features that can prohibit semantic interoperability. In a perfect world, the different standard models we see below would be cleanly separated, and no overlap would exist between them. However, scope creep within standards becomes a real problem and it is difficult to define the fine line between one model and another as it sometimes affects usability. Each of the higher-level models can be used within the layers below.
1. Terminology (Concept) Model
The base layer of healthcare architecture is the terminology model. A terminology or concept model is the collection of concepts and relationships and the specification of how they are used to provide a definition for concepts within the terminology. For example, within SNOMED CT one of the relationships (finding site) is used to provide definitions of subtypes of “Clinical finding” and uses concepts from the “Body structure” hierarchy to do that. Not all clinical terminologies have a concept model or even use relationships (IS A and/or other defining relationships).
With terminology it is easy to get overlap with other models due to the need to support usability requirements. Most commonly there is the need to support the natural language of clinicians (or patients) versus what should be represented in the data model. It is much easier to have the user enter “Nausea and Vomiting” than enter two separate entries for “Nausea” and “Vomiting”.
2. Data or Statement Model
A data or statement model is used to organize elements of data and standardize how they relate to one another. Problems arise when similar structures exist within the terminology model and the statement model. For example, SNOMED CT contains concepts that allow you to represent family history of concepts with a single code, but FHIR also contains resource that allows you to capture that same information using multiple fields and include greater detail. SNOMED International has a good webinar on the topic of using SNOMED CT within FHIR Questionnaires that highlights some of the issues with different ways of representing the same thing depending on the data model.
As there are different terminologies for different use cases, there are also different statement models for different use cases. Another example of a potentially useful statement model is the Analysis Normal Form which represents a potential solution for normalizing the various models to allow for an easy, consistent way for analyzing data.
3. Assertional Model
Assertional models, sometimes called assertional knowledge, contain the knowledge about a concept that is situation dependent and is only known at run time. Assertional models build upon and connect terminology(s) with additional relationships that can be used to help with endeavors such as Clinical Decision Support by representing additional facts that are not always true about a concept but may be helpful to make certain decisions. For example, RxNorm contains attributes like May Treat, May Prevent or Contraindicated With. In RxNorm, Aspirin:
i. May Treat — Rheumatic fever, Pain, Fever, Inflammation, etc.
ii. May Prevent — Myocardial infarction, Pain, Pre-Eclampsia, etc.
iii. Contraindicated With — Blood platelet Disorders, Blood coagulation disorders, etc.
The assertional model tends to have overlap with the terminology model in a lot of standards. Many standard terminologies tend to embed assertional knowledge within their terminology model and don’t make a distinction between definitional and assertional knowledge.
4. Procedural Model
This last model can best be described as how we represent how we do something. Some good examples would be templates for documenting encounters, order sets, and even clinical decision support (CDS) rules. https://cds.ahrq.gov/cdsconnect
a. Documentation Templates (https://lhcforms.nlm.nih.gov/sdc)
For certain conditions or procedures, it is important to completely capture certain required or optional information. Documentation templates guide the user and ensure that the appropriate information is captured in an efficient and complete manner.
b. Event-Condition-Action Rules
Event-Condition-Action Rules (ECA rule) can be incorporated into a system and help drive further actions in the treatment or documentation of a patient. ECA rules follow this logic: “On an event, if the condition is true, then an action is performed”.
c. Order Sets
Order sets are pre-defined groups of orders used as a checklist for clinicians when dealing with a patient in a specific clinical context or stage of care.
Summary
This final article brings the Healthcare Terminology Systems Explained series full circle. Across the four parts, we have shown:
Why terminologies matter (part 1)
How they are released (part 2)
What their core components are (part 3)
Why working with healthcare data remains so complex (part 4)
The lessons are clear: overcoming silos, improving data quality, addressing overlapping standards, and applying the right models are essential to achieving true semantic interoperability. These challenges extend far beyond hospitals and clinics—they affect life sciences, insurance, population health, research, technology, government, and every sector that depends on healthcare data. By recognizing both the promise and the complexity of healthcare terminology, we can build systems that make data usable, shareable, and valuable across the entire ecosystem.
👉 TermHub is your key to turning knowledge into practice—helping you apply the lessons from this series to real-world healthcare data challenges.