¶ Terminology in healthcare
Standardized terminology is simply a common language, nomenclature, classification, or taxonomy designed to be shared among users. In healthcare settings, the usage of standardized terminologies is essential to clearly and accurately document patient assessments, care, and outcomes.
The main reason is the complexity of the development of terminology described in Cimino's desiderata for medical vocabularies and may be summarized on the following principles:
- Domain completeness - cover your scope with depth and breadth
- Unambiguous - define your term with a clear concept, and close the definition
- Non-redundant - don’t have more than one way to describe a concept
- Synonymy - clearly document terms that have the same meaning
- Multiple classifications - allow multiple axes in your hierarchy
- Explicit relationship - make sure you’re explicit about how your concept relates to each other.
Detailed guidelines for development of the healthcare vocabularies declare:
¶ Vocabulary Content
Content is paramount in terms of scope and quality. Any practical clinical terminology needs to be comprehensive in domain coverage (concepts) and have human-readable terms (descriptions and synonyms). Specific tools are required to allow the content to be expanded as and when required, including translation into other languages and dialects, while ensuring quality.
¶ Concept Orientation
Each concept term should have one and only one meaning. It should be neither vague nor ambiguous. However, each concept may be described by several terms (synonyms) in the same language as well as different terms in other languages and dialects. Note that the same term can have different meanings (homonyms) that relate to different concepts.
¶ Concept Permanence
Once a concept is created its meaning persists. It must not be changed or deleted by updates. However, a concept may be marked as retired where its meaning is found to be ambiguous, redundant or otherwise incorrect.
¶ Non-semantic Concept Identifiers
Each concept should have a unique identifier, which should be meaningless. Semantic information (relating to meaning) is an attribute of the concept, not part of its identifier. This is a problem with many traditional position-dependent coding schemes, such as ICD.
Note that this desideratum is controversial. It may not always be appropriate for aspects of meaning to be part of the code, but it is not always wrong either.
¶ Polyhierarchy
It is useful to organize medical concepts in a hierarchical way, but many clinical concepts are naturally multi-dimensional with more than one parent (super-type) concept. For example, a fractured tibia is both a type of fracture and a type of leg injury.
¶ Formal Definitions
The way of classifying a concept should be independent of the way of identifying it. Use of descriptive logic to define and classify clinical concepts is a development away from the traditional position-dependent coding schemes and dictionary forms of definition. For example, pneumococcal pneumonia may be defined using a hier- archical (is a) link to the concept pneumonia and a caused by link to the concept streptococcus pneumoniae.
¶ Reject “Not Elsewhere Classified”
Many existing classifications include catchall categories for concepts not covered explicitly. Not elsewhere classified (NEC) categories change their meaning, when any new category is added within the NEC scope. The meaning is not permanent (criterion 3 above).
¶ Multiple Granularities
Users require different levels of granularity for defining concepts, navigation, decision support and reporting. For example, a manager may only need to know that a patient has a broken leg; the finance department that it is a fractured tibia, but the clinician needs to know that it is a closed spiral fracture of the shaft of the right tibia. There should be no arbitrary limitation on the number of levels in the hierarchy.
¶ Multiple Consistent Views
When a concept has multiple parents in a hierarchy, the view of that concept should not depend on how it was reached. The full structure of terminology, including all hierarchies and relationships, can be complex but each end user only needs views into it that reflect his or her own needs and understanding. This must remain consistent with the underlying model.
¶ Context Representation
The information recorded within a particular context should not be interpreted without understanding it thoroughly. The context needs to be computer-processable. One approach is to provide means of recording context explicitly within the terminology.
¶ Graceful Evolution
Terminologies evolve and change over time. It creates problems for users if the meanings of aggregated time series data change in an uncontrolled manner. Carefulness must be implemented when designing the whole structure to support graceful evolution of concepts, terms and relationships.
¶ Recognize Redundancy
When terminologies change, some components will become redundant making it important to recognize explicitly that this has happened.
These principles have stood the test of time well. Any proposal that does not meet them will inevitably cause problems sooner or later, probably sooner.
¶ Data models
There are many database models to implement terminology services.
¶ Entity-attribute-value
The most universal model is the entity–attribute–value model (EAV).
EAV is a data model to encode, in a space-efficient manner, entities where the number of attributes (properties, parameters) that can be used to describe them is potentially vast, but the number that will actually apply to a given entity is relatively modest.
With EAV, you can describe any data model, but due to too much flexibility, the readability of the data model and the API are lost.
Most of the universal data models don’t solve the problem of versioning. The typical solutions of data model architects use expiration periods (validFrom and validTo) and activity attributes (isActive: true/false). And in most cases, it is reasonable to keep the client system simple. This kind of model allows the creation of snapshot from practically every other model and support snapshot easily.
But these simple models are not suitable for more complex tasks, such as the development of terminology and management of the terminology.
¶ CTS2
HL7 has been working on the terminology model for a long time and as a result, HL7 Common Terminology Services Service Functional Model Specification has been developed. The updated version of Release 2 (hereinafter CTS2) was issued in January 2022 and is available on the HL7 site. The CTS2 model also reuses the EAV model, but adds many specific entities to support the development of clinical terminology:
CTS2 structured terminologies provide a foundation for information interoperability by improving the effectiveness of information exchange. They provide a means for organizing information and serve to define the semantics of information using consistent and computable mechanisms.
CTS2 provides a domain model for defining the concepts, code systems, their relations, and versioning. It also allows the creation of value sets from different code systems, adding/changing designations, creating maps between concepts, and many many more.
CTS2 does not depend on the specific implementation, it can be used with HL7 V2, V3, FHIR, and potentially further standard versions.