Healthcare Terminology Systems Explained (part 4)
This article explores the various reasons why working with healthcare data is so challenging. It is the fourth article in our continued education effort to help people learn about Healthcare Terminology.
(For a deeper dive, read part one Clinical Terminologies and Why They Matter, part two How Clinical Terminologies are Released, and part three 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 Administrations 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, at the very least by mapping 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.
Separation of Concerns
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 imbed assertional knowledge within their terminology model and don’t make a distinction between definitional and assertional knowledge.
4. Procedural 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
Using standards to represent the terminology, statement, assertional, and procedural models can help to prevent data silos by easing the ability to exchange data. By separating the various models and avoiding overlaps we can ensure that the data is used consistently across the various disparate systems. This leads to better data quality and makes the data understandable and reusable once it is consumed by another system.