HL7 Common Terminology Services

By Syed Ali Raza, Software Engineer, SEECS, NUST

Terminology Services in Support of Healthcare Interoperability

Outline

Why Terminology Importance of Terminologies

Terminologies in Healthcare Semantics of Healthcare Terminologies

Terminology Services Intent HL7 CTS / CTS 2

Health Care Is An Information Intensive Industry

Control of Health Care Costs ... Improved Quality of Care ... Improved Health Outcomes ... Appropriate Use of Health Technology... Compassionate Resource

Management...

> ... depend upon information> … ultimately Patient Data

Understanding the Clinical Process

Background - Terminology Terminologies (and ontologies, sort of…)

have been around for a long time in the healthcare domain. Coding / classification / query is an integral

part of the practice of medicine Shared electronic records is an emerging

need▪ PMR

Defines the meaning of data i.e. changes data to information through

instantiation of semantic rules

What is a Structured Terminology? A structured terminology

is composed of concepts along with synonymous terms, properties and various relationships, especially a taxonomy

Relationships Taxonomy (is-a) Partonomy (part-of) Etiology (caused-by) Therapy (treated-by) Position (located-in)

Terminology Elements

Concepts represent unique ideas Codes uniquely identify concepts Terms refer to concepts Typically

Humans communicate concepts using terms Computers communicate concepts using codes

Concepts are language independent; terms are dependent

Interplay among Terminology Elements Humans and computers

select, apply and transform concepts, codes and terms Across human languages Across contexts (geographic, medical specialty, etc.) Across applications

Example scenario English term entered by clinician Term is encoded in SNOMED Code is recorded in Electronic Health Record Record is retrieved Record is transmitted to another application in another institution Code is extracted Term is requested e.g.,▪ Spanish term▪ Consumer term

Why Standard Terminologies? Provide consistent meaning Promote shared understanding Facilitate communication with humans Enable comparison and integration of data Essential for interoperation among

systems, applications and institutions Crucial for Electronic Health Record (EHR)

sharing and portability

Significant Applications

Structured terminologies are needed in healthcare for Data integration Decision support Clinical guidelines Medical error reduction

Standard Terminologies

Clinical (SNOMED CT) Reimbursement (ICD, CPT, HCPCS) Pharmaceuticals (FDB, RxNorm, NDF-

RT, …) Labs (LOINC) Nursing (ICNP, NIC, NOC, NANDA) Adverse events (MedDRA, COSTART,

WHOART) Genetics (GO) …

Terminology is a Crucial Requirement

Without Terminology Standards... Health Data is non-comparable Aggregation is difficult if not impossible Health Systems cannot Interchange Data Linkage to Decision Support Resources not

Possible

Terminology Services

One of the fundamental goals of computerized medical information is that of precise, accurate and unambiguous communication.

Structured terminologies provide the semantics of the concepts being conveyed in an electronic message or record (syntax is another discussion altogether).

Meaningful Communication…now what?

Being able to predictably access terminological content is still necessary.

Example Need to receive a SNOMED-CT disorder code, and▪ Validate the code against the SNOMED-CT vocabulary▪ Query against properties of the code (determine the

grouping or aggregation of the code, e.g. What type of disorder is this?)

▪ What drugs can be used to treat this disorder▪ Translate this code for our insurance systems.

Problem How do we ensure that our operations with

vocabulary are consistent across domains?

Meaningful Communication…now what?

External terminological resources vary considerably in both content and structure.

User requirements of terminology differ (real time decision support, billing applications…)

Storage formats may differ (relational database, XML, RDF, MIF…)

This is where Terminology Services comes in.

What is a Terminology Server?

A terminology server is

a (networked) software component

centralizes terminology content access and reasoning

provides (complete, consistent and effective) terminology services for other network applications

How is a Terminology Server Used?

By informaticists to create, maintain, localize and map

terminologies

By clinical applications and their users to select and record standardized data

By integration engines to facilitate mapping terminology elements

between applications

What are Terminology Services? The means by which applications (clinical) can

Define the common business functions for terminology applications

Utilize and interoperate among standard and local terminologies

Benefit from terminology model “knowledge”

Are provided by terminology server software, which Centralize or federate terminology content and

represents it in a consistent format Communicates with other network applications (e.g.,

to translate and normalize data elements)

What are Terminology Services? Provides a common platform for

terminology updates Provides tools to develop and maintain

terminology content, including mappings that connect concepts in different terminologies, use-specific subsets, and local extensions to existing standards.

Implement terminology as an asset of the organization

Examples of Terminology Services

Term/name normalization: What is the SNOMED CT name for heart attack?

Myocardial Infarction

Code translation: What is the ICD-9 code for Myocardial Infarction?

410.9

Grouping and aggregation: Is Myocardial Infarction a Cardiac Disease?

Yes

Clinical knowledge: What drug treats Myocardial Infarction?

Streptokinase

Local information: Add L227 as the local code for Serum Calcium.

OK

History of Terminology Services in the US

YATN: yet another terminology service 1996 Mayo, Kaiser, Lexical Technology

MetaPhrase – Lexical Technology 1998 UC Davis JTerm Terminolgy service 1998 LQS: Lexicon Query Services; 3M 1998 Apelon DTS Mayo Autocoder: UI to YATN suite 2000 CTS: Common Terminology Services 2003 LexGrid: superset CTS, ref. implementation –

04\ CTS 2 – DSTU Ballot March 2009

What is Common Terminology Services (CTS)

An HL7 ANSI Standard interface specification for querying and accessing terminological content.

The CTS identifies the minimum set of functional characteristics a terminology resource must possess for use in HL7.

The functional characteristics are described as a set of Application Programming Interfaces (APIs) that can be implemented to suit.

Each terminology developer is free to implement this API call in whatever way is most appropriate for them

Advantages to this functional approach

Advantages to this functional approach No need to force a common terminological

structure on terminology developers. Decouples terminology from the terminology

service. Terminology users can use whatever technology

appropriate for their needs.▪ Legacy database▪ Institutional infrastructure

Provides a common interface and reference model for understanding▪ I know what you mean by Code System

▪ I know what to expect when I execute the validateCode() method

Advantages to this functional approach

Client software doesn’t have to know about specific terminology data structures and/or how to access them.

Server software can plug and play with many clients.

CTS Modules: The Message and Vocabulary API

The Message API allow a wide variety of

message processing applications to create, validate and translate CD-derived data types

The Vocabulary API allows applications to

query different terminologies

CTS Modules: The Message and Vocabulary API (contd..)

The Message API utilizes the Vocabulary API

General HL7 CTS User (Actor) Classes

Message Creation Software – Software that is involved in the creation of HL7 messages.

Message Processing Software – Software that receives, decodes and acts on the content of standard HL7 Version 3 messages. This process may include validation, translation and inferencing steps.

RIM Modelers – The combination of people and tools that create and define HL7 Message content.

Software Developers – The people who build the software that creates, validates and processes HL7 Version 3 messages.

Vocabulary Translators – A combination of tools and people that translate the abstract HL7 Version 3 specification into the structure and terms of actual data processing applications.

CTS Runtime Message API Examples

CTS Runtime Vocabulary API

Common Terminology Services API

Allows Client Software to be Developed Independently from Service Server Software

Allows Terminology Plug-and-Play

Allows Client Plug-and-Play

Defines a “Functional Contract” between terminology users and providers

Limitation of CTS

Purposely limited functional scope: read only terminology access APIs for HL7 (much

carryover to other terminologies) basic terminology mapping no versioning support

CTS 2

CTS 2

Project of the HL7 Vocabulary Workgroup Developed under the Service Oriented

Architectures (SOA) and Healthcare Service Specification Project (HSSP) framework

Expand the scope of functionality to include▪ Administrative functions▪ Expanded search capability▪ Mapping functionality▪ Authoring / Maintenance▪ Conceptual model for terminology

Context of SFM within HSSP Roadmap

the purpose of an HL7 SFM is to identify and document the functional requirements of services considered important to healthcare.

Accordingly, the CTS 2 service provides a critical component within the larger context of service specifications in that it defines The expected behaviors of a terminology service A standardized method of accessing terminology

content.

Service Overview

The major goal of the CTS 2 specification stack is to provide a standardized interface for the usage and management of terminologies.

CTS 2 defines the functional requirements of a set of service interfaces to allow the representation, access, and maintenance of terminology content either locally, or across a federation of terminology service nodes.

CTS 2 Aims

Establish the minimal common structural model for terminology behavior independent from any specific terminology implementation

Integrate into CTS 2 the functional coverage outlined in the existing CTS specification.

Specify both an information and functional model that addresses the relationships and use of terminology.

Specify the interactions between terminology providers and consumers

CTS 2 Aims

Specify how mapping between compatible terminologies and data models is defined, exchanged and revised.

Specify how logic-based terminologies can be queried about sub-sumption and inferred relationships.

Engage broad community participation to describe the dimensions of use and purpose for vocabularies and value sets.

Scope

Administration Search Query Authoring Maintenance Associations

Administration

Set of functionality that provides the ability to manage content ability to load terminologies export terminologies management of notifications

Accessible by service administrators

Search / Query

Set of functionality that provides the ability to find concepts based on some search criteria.

Includes: capabilities for searching. querying terminology content . representing terminology content in the

appropriate formats.

Authoring / Maintenance

Set of functionality that provides the ability to create and maintain content.

This would include the appropriate APIs to add, change, or delete concepts and associations.

Associations

Set of functionality that provides the ability to map concepts and the concept's associated attributes from a source terminology to a concept in a target terminology.

OR Create relationships between concepts

within a single code system.

Profile

Enables a service to be used at different levels, and allow implementers to provide different levels of capabilities in differing contexts.

Service-to-service interoperability will be judged at the profile level and not the service level.

A set of profiles may be defined that cover specific functions, semantic information and overall conformance.

CTS 2 Query Profile

Specifies the minimal functional coverage necessary for a service to declare itself as being a conformant CTS 2 service.

Includes capabilities for

searching and query terminology content representing terminology content in

interoperable data types and structuring terminology content.

Terminology Administration Profile

Provides the functional operations necessary for terminology administrators to be able to access and make available terminology content obtained from a Terminology Provider.

Terminology Administrators are required to interface with Terminology Provider systems in order to: obtain the terminology content, then load

that terminology content on local Terminology Servers.

Terminology Authoring Profile

Terminology authors require the capability to robustly query and access terminology content, as well as directly modify the terminology content.

Intended to provide the functional operations necessary for terminology authors to analyze and directly edit the existing terminology content.

Implementation Considerations Interface Interoperability Considerations Terminology Structure Considerations

Interface Interoperability Considerations CTS 2 Service Accessed by a Single Organization

Interface Interoperability Considerations (contd..) Multi Organizational access to a CTS 2 Service

Terminology Structure ConsiderationsProblems:

Controlled terminologies are developed with specific purposes and use cases in mind, and as such are structured very differently.

The format of any given terminology may range from a simple flat list of concepts, to more complex poly-hierarchies. The variety of attributes of the entities of code systems vary as well.

Even the formats of the identifiers are different Some concept identifiers being meaningless identifiers, Others which have explicit or implied meaning.

Terminology Structure Considerations (contd..)

CTS 2 specifies a concept based terminology model that is capable of representing most varieties of structured terminologies.

Basic requirements of the CTS 2 terminology model are illustrated in the CTS 2 Conceptual Model

Conceptual Model

Class Description

CodeSystem a resource that makes assertions about a collection of

terminological entities. described by a collection of uniquely identifiable

concepts with associated, representations, designations, associations, and meanings

ICD-9 CM, SNOMED CT, LOINC, and CPT CodeSystemVersion

Generally not static entities and change over time Enables identification of the versions of the code

system CodeSystemConcept

A Code System Concept defines a unitary representation of a real or abstract thing within the context of a specific Code System; an atomic unit of thought.

Class Description cont..

CodeSystemNode: Represents an individual "node" within a Code System, which is

either a Code System Concept or a Code System Concept Code

CodeSystemConceptCode: defines a single "code value" that is used to represent

(symbolize) a Code system Concept There may be more than one Code for a single concept in a

single code system

AssociationType: In the terminology model, allowable relationship types are

represented by the AssociationType class. Enables identification of the versions of the code system

Class Description cont..

Designation : Concept designations are representations of concepts For example, in SNOMED CT the concept of “fever” has:▪ the fully specified name of “fever (finding),”▪ A preferred name of “fever,”▪ synonyms of “febrile” and “pyrexia.”

These are all designations for the concept of “fever.”

Value Set : Represents a uniquely identifiable set of concept codes grouped

for a specific purpose. May range from a simple flat list of concept codes drawn from a

single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.

Formalize Actors

Business Scenarios (Use Cases) Based on the discussed terminology

service criteria, define high level business scenarios that: Cover the existing CTS functional capabilities

Extend the CTS functionality into other domains▪ Administrative functions▪ Expanded search capability▪ Mapping functionality▪ Authoring / Maintenance

Why Service is Necessary? CTS-1 deliberately avoided issues related to

terminology distribution, versioning and authoring.

CTS-1 focused on static value sets and didn’t fully address the definition or resolution of value sets that define post-coordinated expressions.

CTS-1 fails to address many of the maintenance, versioning and representation requirements necessary for a truly interoperable terminology service.

Why Service is Necessary? CTS-1 was deliberately silent on how the

vocabulary content should be structured.

CTS-2 will enhance the capabilities of the original CTS specification for sub-setting, mapping and extending the specification into domains such as terminology distribution, authoring, and versioning.

Summary

Terminologies play a crucial role in enabling semantic interoperability by defining the meaning of data being communicates

Healthcare has been a leader in the development of terminologies for use in classifying and aggregating clinical data.

Terminology Services can be deployed to provide consistent access to terminology resources across organizations