1. By Syed Ali Raza, Software Engineer, SEECS, NUST
Terminology Services in Support of Healthcare Interoperability

2.  WhyTerminology
 Importance ofTerminologies
 Terminologies in Healthcare
 Semantics of HealthcareTerminologies
 Terminology Services
 Intent
 HL7 CTS / CTS 2

3.  Control of Health Care Costs ...
 Improved Quality of Care ...
 Improved Health Outcomes ...
 Appropriate Use of HealthTechnology...
 Compassionate Resource Management...
> ... depend upon information
> … ultimately Patient Data

5.  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

6.  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)

7.  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

8.  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

9.  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

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

11.  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)
 …

12. WithoutTerminology Standards...
 Health Data is non-comparable
 Aggregation is difficult if not impossible
 Health Systems cannot Interchange Data
 Linkage to Decision Support Resources not Possible

13.  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).

14.  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?

15.  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 whereTerminology Services comes in.

16. 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

17.  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

18.  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)

19.  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

20. 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

21.  YATN: yet another terminology service 1996
 Mayo, Kaiser, LexicalTechnology
 MetaPhrase – LexicalTechnology 1998
 UC Davis JTermTerminolgy service 1998
 LQS: Lexicon Query Services; 3M 1998
 Apelon DTS
 Mayo Autocoder: UI toYATN suite 2000
 CTS: CommonTerminology Services 2003
 LexGrid: superset CTS, ref. implementation – 04
 CTS 2 – DSTU Ballot March 2009

22.  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

23.  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

24.  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.

25.  The MessageAPI
 allow a wide variety of
message processing
applications to create,
validate and translate CD-
derived data types
 TheVocabularyAPI
 allows applications to query
different terminologies

26.  The MessageAPI utilizes theVocabularyAPI

27.  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 HL7Version 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 HL7Version 3 messages.
 VocabularyTranslators – A combination of tools and people that
translate the abstract HL7Version 3 specification into the structure
and terms of actual data processing applications.

30.  Allows Client Software to be Developed
Independently from Service Server Software
 AllowsTerminology Plug-and-Play
 Allows Client Plug-and-Play
 Defines a “Functional Contract” between
terminology users and providers

31.  Purposely limited functional scope:
 read only
 terminology access APIs for HL7 (much carryover
to other terminologies)
 basic terminology mapping
 no versioning support

33.  Project of the HL7VocabularyWorkgroup
 Developed under the Service OrientedArchitectures
(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

34.  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.

35.  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.

36.  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

37.  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.

38.  Administration
 Search
 Query
 Authoring
 Maintenance
 Associations

39.  Set of functionality that provides the ability to manage
content
 ability to load terminologies
 export terminologies
 management of notifications
 Accessible by service administrators

40.  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.

41.  Set of functionality that provides the ability to create
and maintain content.
 This would include the appropriateAPIs to add, change,
or delete concepts and associations.

42.  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.

43.  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.

44.  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.

45.  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
withTerminology Provider systems in order to:
 obtain the terminology content, then load that
terminology content on localTerminology Servers.

46.  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.

47.  Interface Interoperability Considerations
 Terminology Structure Considerations

48.  CTS 2 Service Accessed by a Single Organization

49.  Multi Organizational access to a CTS 2 Service

50. Problems:
 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.

51.  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

53.  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.

54.  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

55.  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.

57.  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

58.  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.

59.  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.

60.  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