Health Terminology Service

Chapter 8 of 11

 

Over the past few decades, healthcare policymakers and stakeholders worldwide have stressed the importance of substantiating Electronic Health Records (EHRs) for every healthcare institution. It is seen as a critical to minimizing medical errors, boosting patient safety, enhancing efficiency, and reducing costs. Medical knowledge, which is crucial to meeting these goals, is the core of the EHRs.

From the perspective of the healthcare provider, data entry remains an obstacle to the successful adoption and effective use of EHRs. Providers, therefore, prefer to document healthcare processes, findings, and outcomes via the use of free text in natural language. This narrative format allows to the sharing of concepts effortlessly and efficiently.

8.1. DEFINITION

Terminology services enable consistent programmatic access to terminology content. Centralizing terminologies facilitates consistent meaning and shared understanding between users. Terminology services also ensure proper integration of other terminology-enabled software applications and optimal delivery of terminology artifact in harmony with a single consensus standard content model and data format (Vocabulary Task Force Public Hearing, 2010). Without standards, gathering health information becomes difficult, health data comparison becomes next to impossible, interchange of data between health systems cannot occur, and secondary uses, such as research, are not possible.

Today’s terminology services have varied scope and capability. This variance reflects the differences in local requirements of users availing the services. By determining the exact point of commonality for terminology services, consistent and uniform behaviors of common terminology services become possible.

8.2. PURPOSE

  • Health terminology services serve as a means by which clinical applications can interoperate among standards and local terminologies and define common business functions for terminology applications.
  • By using terminology server software, content and format can be federated or centralized, and communication with other network applications becomes possible.
  • Using terminology services opens access to a common platform for terminology updates, which ultimately leads to optimal development and maintenance of terminology content such as use-specific subsets, a local extension to existing standards and mappings that help connect concepts to different terminologies.

8.3. HISTORY

The history of health terminologies dates back to the 17th century when English demographer John Graunt decided to study the statistical information about mortality. The most common causes of death in his “Bills of Mortality” include bloody flux, rising of the light, mortification, griping of the guts and teeth.

In 1839, an English epidemiologist, William Farr, expressed the medical community’s need for standard terminologies. He stated that disease has, been described using three or four terms and that each were inconvenient and quite vague names of diseases have been registered instead of primary diseases.

In 1893, Paris released the Bertillon Classification of Causes of Death. A few years later, the International Lists of Causes of Death was published to classify the most common causes of mortality. ICD-1 was released in 1900 and eventually fell under the control of the World Health Organization (WHO).

Currently, ICD-9 and Current Procedural Terminology (CPT) are the most widely used administrative terminologies. However, these terminology standards are not designed to adopt Healthcare Information Technology (HIT) applications because they lack adequate structure and granularity, and they are not truly concept based.

The history of the modern terminology services in the United States started in 1996 when Kaiser, Mayo and Lexicon technology released the YATN, also known as the “Yet Another Terminology Service.” In 1998, three terminology services were released: the MetaPhrase by Lexicon Technology, the UC Davis JTerm Terminology service and Lexicon Query Services (LQS). In 2003, Common Terminology Services (CTS) was implemented. A year later, CTS was updated to CTS1 through HL 7 balloted procedure. In 2009, CTS was updated to its latest version, the CTS2, by going into another ballot.

8.4. COMPONENTS

Terminology services use three critical elements to transmit healthcare information across different computer systems within the organization and across healthcare organizations:

8.4.1. CONCEPTS

In the healthcare sector, a concept is a general idea or an abstract that is generalized from an occurrence. Different widespread approaches are needed to determine the exact meaning of these co-occurring concepts expressed on various medical free texts.

8.4.2. CODES

Computers use these codes to communicate concepts across different systems.

8.4.3. TERMS

Computers communicate concepts using codes. Terms refer to concepts. Concepts know no boundary, ethnicity or nationality because they are language- independent. Conversely, terms are language-dependent. Terms depend on the knowledge limitations of users and the language of the person using them.

8.5. TOOLS AND TECHNIQUES
8.5.1. TERMINOLOGY DEVELOPMENT/EDITING/MAINTENANCE TOOLS

Terminology development/editing/maintenance tools support the clinical representation of concepts. They include provision of a reference model using a type of frame-based approach of description logic, data to support version control and automated classification of new terms using a formal method of decomposing terminology into a set of task-achieving competencies or behaviors. These tools should support other formal structures of clinical document architectures and the resolution of inconsistencies across modelers.

The examples of terminology development/editing/maintenance tools include:

  • LexGrid: A framework for querying, representing, and storing biomedical information coordinated by the Mayo Clinic Division of Biomedical Statistics and Informatics
  • Medical Entities Dictionary Editor: A large repository of medical concepts derived from a variety of sources including LOINC, UMLS and ICD9-CM
  • Protégé (ontology development in frames or OWL): Model of underlying ontologies that aim to connect data integration of different healthcare applications

8.5.2. FHIR INFRASTRUCTURE

This is a service that allows healthcare apps to use codes as well as value sets without the need for users to become specialists when it comes to underlying code systems. A server that adequately supports every functionality that is highlighted here is referred to as “FHIR Terminology Service,” and is expected to be in line with the Terminology Service Capability Statement.

Security

Ordinarily, SSL should be employed for every production healthcare data exchange. Although terminology servers do not usually manage patient information directly, observers might still be capable of inferring patients’ information by observing the codes used in terminology service servers. Encryption is highly recommended.

At times, a terminology server chooses not to authenticate users/clients. Authentication is vital in order to implement the agreement to licensing firms or account for usage. Since a value set maintenance server allows the editing of specific terminologies, it would only be proper to have some form of authentication in place. This specification, however, does not call for a particular approach to security.

FHIR Terminology

A FHIR terminology service is a set of software systems built on the definitions that are provided by a collection from ConceptMan, CodeSystem, and ValueSet resources. Other terminologies are also provided for additional support. This is founded on basic principles that make use of terminologies in FHIR. Implementers are expected to get familiar with:

  • The CodeSystem Resource
  • The Use of Codes In FHIR
  • The ConceptMan Resource
  • The ValueSet Resource

External Code Systems

It is often necessary to define code systems along with their content if they must be used with a value set. They can be defined explicitly by utilizing the code system resource. The FHIR system determines the essential qualities of a set of namespaces for code systems that are commonly encountered while defining how some of them, such as LOINC, SNOMED CT and RxNorm, work with FHIR. These code systems are usually large and come with several internally defined properties. The CodeSystem resource is not a suitable way of distributing the contents of these code systems. The standard FHIR code system resource merely represents the attributes of the code system. Instead, these terminologies render their distribution formats and it is presumed that the terminology server externally acknowledges the content of the code systems.

The majority of practicable terminology servers will often make one or more of the external code systems available for use right within the value sets that they manage. The list of additional terminologies supports beyond those that are defined within its value sets is usually published to users via the referencing code system resources in the server’s Capability Statement.

Implementation Note

A terminology server usually exposes an external code system, when it does, a set of services are made available internally. These services are created to serve the operational interfaces that will be outlined below. The internal server depends primarily on this logical information for a terminology:

  • Codes that are considered valid
  • The URL, i.e. namespace as well as how versioning works
  • Properties that can be used in the selection of codes
  • Implicit value sets that exist

The FHIR specification defines this information for standard terminologies (RXNorm, SNOMED CT, LOINC, etc.) and puts up the CodeSystem infrastructure for supporting distinctive relatively simple small code systems.

Terminology service may prefer to disclose additional external code system-specific related functionality, such as structured search or summation, but these are services that are beyond the scope of the FHRI terminology service.

Terminology Maintenance

The terminology service makes use of the value set and code systems resources that are defined on the system to serve the functional interface, this includes the implicit ones that are linked with the external code systems as well as those that are explicitly available at the /ValueSet and /CodeSystem endpoints. A terminology server ought to substantiate incoming resources while ensuring the wholeness of the terminology services. Servers provide test-and-production environments but there is no explicit impression of this in the interface itself.

Value Set Expansion

A value set depicts a set of rules for what concepts or codes are considered to be available in the value set. An FHIR-enabled app can call for a terminology server to work out every detail and return a list of the present-day codes in the value set. This action is referred to as “expanding the value set.”

The following are the instructions that the clients pass to the server:

  • The value set, usually via its logical identifier or URL on the restful interface, i.e. ValueSet.url or instantaneously as a parameter to the call.
  • A text filter used to limit the codes that are returned, i.e. user input text. (Optional)
  • The date at which the expansion is expected to be evaluated. This is usually the current date and time. (Optional)
  • The exact page to be retrieved, in which the server is required to break down the expansion into a set of chunks. (Optional)
  • Other parameters provide additional information for expansion. (Optional)

The server generates a value set that comes with the current list of codes which meet the criteria of the filter. If the expansion fails, an Operation Outcome with an error occurs. It is not uncommon for some value sets to expand to an infinite number, and when this happens, the server is expected to return a message: “error code too-costly.” In such cases, the client should give it a try again by entering a more specific text filter in order to minimize the number of codes returned, thereby resulting in a logical expansion.

The expand operation comes with support for paging so that clients can retrieve large expansions in a set of partial views in order to achieve the most optimal user experience. The client is expected to specify a count, and an offset such as the number of codes per page as well as where in the sequence to commence. All expansions should also include the total code count, though the offset element will only exist when the paging is utilized. Expansions, which are nothing but stratified trees of concepts, are not affected by paging. The server merely returns the full expansion.

Concept Lookup/Decomposition

A system may request that a terminology server return some information about a code/system combination using the lookup operation. The server delivers information for display as well as processing. The client sends the following information to the server:

  • The code value which could be a coding data type or a code
  • The URL or ID of the code system in which the code is to be checked (Optional)
  • The date at which the code information should be returned (Optional)
  • A set of properties or status to return about the code
  • The server returns some or all of the following information:
  • The recommended display for the code
  • The (human) description of the system
  • Status of the code
  • Other designations that have to do with the code
  • The relationships between the code and other codes
  • Essential properties of the selected code

The recommended display for the code appears as a text representation of the code which the terminology server recommends as the default option to render to the user. A client can decide to go for any other designations if there is a reason to.

Value Set Validation

The quickest way to determine if a code is in a value set is by expanding it. And then taking a look at the returned codes to check if the code is in expansion. This method cannot work for some values especially those with an infinite number of members. An FHIR terminology server provides what is known as a “validate-code” operation. The following is the information that the client passes to the server:

  • The value set via its logical identifier, i.e. ValueSet.url or as a direct parameter
  • The date at which the expansion is to be evaluated which is the current time/date by default, though this does not apply in some circumstances
  • The code value, i.e. a Coding data type, a code + system or a CodeableConcept

The server gives a true/false indication on whether the concept/code is valid as well as a list of warnings and errors linked with it. The server should also put out a suitable display for the concept for utilization in a UI context. Take note that if the server is passed a CodeableConcept, the server will be able to check whether or not any of these codes are valid against the value set.

Terminology browsers allow the viewing of one or more terminologies. Aside from viewing, some browsers may also allow editing of terminologies. The examples of single terminology browsers include:

  • RELMA (Regenstrief LOINC Mapping Assistant)– a terminology browser that uses the power of Windows to search through the healthcare database and assists in mapping local healthcare codes to LOINC codes
  • MED (Medical Entities Dictionary) browser
  • CLUE – the freeware browser of SNOMED CT
  • Examples of browsers for multiple terminologies include:
  • Knowledge Source Server of the Unified Medical Language System
  • LexGrid of Mayo
  • HL 7 Common Terminology Services – the API used by HL7 Software to access terminological content
  • Open GALEN – an open-source terminology tool for building and delivering terminologies and medical concepts
  • Mycroft of Apelon – a free, multi-terminology, standalone terminology browser

8.5.3. TERMINOLOGY MAPPING TOOLS

Terminology mapping tools facilitate the mapping of terms from a local or source terminology to a target terminology (Appendix B: Terminology Services and Tools). Examples include:

  • SNOMED CT development tools
  • Regenstrief LOINC Mapping Assistant (RELMA)
  • Comparatively, mapping tools that use multiple terminologies are:
  • Health Level 7 Common Terminology Services
  • LexGrid of Mayo

8.5.4. CONCEPT-BASED RETRIEVAL AND INDEXING TOOLS

Concept-based retrieval and indexing tools use tagging and indexing for the proper retrieval of document sets. The most popular include:

  • Apelon’s Concept-Based Indexing and Retrieval Solution
  • Open GALEN
  • Unified Medical Language System – tools that aim to integrate and distribute key terminology, coding standards, and classifications to promote the creation of more effective interoperable healthcare information systems and services
  • Cimino’s Infobutton Manager – context-based links that anticipate user needs from one information system to another

8.5.5. TERMINOLOGY IMPORT TOOLS

Terminology import tools facilitate the transfer of terminologies in various formats. Mayo’s LexGrid is an example of terminology import tools.

8.5.6. NATURAL LANGUAGE PROCESSING TOOLS

Natural language processing tools convert natural language into semantic structures and map these parsed terms to a standardized terminology. Friedman’s MedLEE is the most popular natural language processing tool.

8.5.7. CLINICAL TERMINOLOGY SERVER

A clinical terminology server is a networked software component that aims to centralize access of terminology content by providing effective, complete, and consistent terminology service for other healthcare networks.

8.8.6. BEST PRACTICES

8.6.1. ADMINISTRATION

It is one of the best practices expected from a health terminology service. It is best to note that the administrative functionality of a health terminology service should be exclusive and accessible only to health service administrators.

8.6.2. SEARCH AND QUERY

Terminology services help users experience more effective research inquiries. Using uncontrolled terms when searching causes significant issues from trivial variations. As a result, non-specialists may find access to applications frustrating.

One of the best ways to achieve optimal search and query functionality of a terminology service is to increase consistency and access to web navigation systems and digital collections through vocabulary control. The administration can reduce the ambiguity of natural language used when describing and retrieving items for information searching.

Terms make up controlled vocabularies, and they are derived from selected natural language used by vocabulary designers to retrieve information and represent concepts. The ambiguity of natural language, as well as the synonyms related to different terms, poses potential problems in creating concepts for different terms. On the other hand, the same term may mean different concepts depending on how the natural language uses such a term in forming sentences.

Using controlled vocabulary can significantly reduce ambiguity between terms by defining the scope of terms, providing a set of synonyms for each concept and restricting the scope of terms so that they will only be related to only one concept. Having a controlled vocabulary ensures consistency in indexing and searching while helping reduce the possible problems that may arise from homograph and synonym mismatches. At a more sophisticated level, concept presentation in semantic structures and hierarchies may help the searcher, and the indexer chooses the most proper concept for their own purposes.

8.6.3. AUTHORING AND MAINTENANCE

It allows for the proper creation and preservation of content. To achieve this terminology services requirement, the use of appropriate Application Programming Interface (APIs) is necessary.

APIs allow terminology services to achieve terminology and client “plug-and-play,” define the functional contract between users and terminology providers and facilitate the independent development of client software from service server software.

8.6.4. ASSOCIATIONS

It is the ability to associate a terminal service, enables the mapping of concepts and other associated attributes from a source terminology to a target terminology. Within a single code system, associations help creates relationships between existing concepts.

The Unified Medical Language System (UMLS) is a set of software and files that combines several biomedical and health standards and vocabularies to enable operability between computer systems. This includes EHRs. The Unified Medical Language System can be used:

  • To develop terminology services
  • Formulate mapping between terminologies
  • Generate an informal retrieval system
  • Create specific terminologies from the Metathesaurus
  • Manage patient care among various departments in a hospital
  • Research ontologies or terminologies
  • Compute texts to extract knowledge, concepts, or relationships

The UMLS Knowledge Sources

  • Semantic Network: This involves broad categories, i.e. semantic types as well as their semantic relations or relationships.
  • Metathesaurus: This involves the use of terms and codes obtained from several vocabularies including SNOMED CT, LOINC, CPT, MeSH, ICD-10-CM, and RxNorm
  • Specialist Lexicon and Lexical Tools: This is an extensive syntactic lexicon of general and biomedical English as well as tools for creating indexes, normalizing strings as well as generating lexical variants.

8.7. OUTCOMES

Computer machines can now have better structure and granularity to promote the processing of healthcare information. Traditional patients record written as free texts have limited value as currently stored healthcare information. However, with newer terminologies, a more efficient capture of data at point-of-care can be achieved. Sharing valuable information between enterprises and processing of information become more efficient with these new improvements in health terminology services.

With better terminology, health terminology services can have a clean and unique representation of concepts. Newer standards in health terminology services will lead to the abolishment of loosely grouped similar terms in computer systems that will ultimately lead to better accuracy in health data retrieval. With the improvement of health terminology services, interrelationships between concepts will be better supported, resulting in the formation of rich ontologies and improved definition of concepts through their relationships with other concepts.

The use of modifiers as concepts to support other concepts, such as in the phrase of mild difficulty of breathing, will become more evident with newer terminologies. Concepts gathered to phrases will be readily stored and retrieved without any additional effort at point-of-care; furthermore, minimal effort will be needed to generate any report.

8.8. CITATIONS

  1. Hamm, R. (2009a, March 26). Terminology Services in Support of Healthcare Interoperability.
  2. ONC (2010, September 2). Vocabulary Task Force Public Hearing Retrieved September 11th, 2015 from www.healthIT.gov
  3. Op. Cit. Hamm (2009a).
  4. Ibid.
  5. Ibid.
  6. Stearns, M. (n.d.). Standards in HealthCare. Retrieved from www.redwoodmednet.org.
  7. Ibid.
  8. Ibid.
  9. Ibid.
  10. Hamm, R. (2009b, May 4). Terminology Services: A Key Technology for Interoperability.
  11. Ibid.
  12. Ibid.
  13. Ibid.
  14. HIMSS (2013). Evolution of Healthcare Informatics Standards. Retrieved from https://www.himss.org/library/interoperability-standards/Evolution-of-Healthcare-Informatics-Standards.
  15. Ibid.
  16. Ibid.
  17. Ibid.
  18. Ibid.
  19. Shortliffe, E.H., & Cimino, J.J. (n.d.). Standards in Medical Informatics. In ResearchGate.
  20. Ibid.
  21. Public Health Data Standards Consortium (2015). Health Information Technology Standards.
  22. Ibid.
  23. Ibid.