Introduction to Vocabulary Russell Hamm Informatics Consultant Apelon, Inc. Co-chair HL7 Vocabulary WG Adapted from Ted Klein, CG Chute MD DrPH, Stan M

Introduction to Vocabulary

Russell Hamm Informatics Consultant

Apelon, Inc.

Co-chair HL7 Vocabulary WG

Adapted from

Ted Klein, CG Chute MD DrPH,

Stan M. Huff MD,

Beverly Knight, Cecil Lynch MD, Russ Hamm

HL7 Tutorial

May, 2009

St. Paul, MN (Yay!)

March, 2009 2© 2002-2009, Health Level Seven, Inc.

Outline

• Why Terminology• Terminology Basics• Terminology Services


What is the Role of Vocabulary?

• Defines the meaning of data – i.e. changes data to information through instantiation of semantic rules

• Is the Human readable value a user sees• Allows for intersystem interoperability by disambiguation of

the message payload• Required for

– data translation– data aggregation

• Is the single most important component for interoperability


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)– …


Structured 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

Myocardial infarction (disorder)

22298006

Myocardial disease (disorder)

57809008

Heart disease (disorder)

56265001

Myocardial finding (finding)

251052000

Disorder of Myocardium

Disorder of heart muscle

Myocardial disease, NOS

Cardiac disorder

Cardiopathy

Disorder of heart

Heart disease, NOS

Morbis cordis

Myocardial observation

Myocardial infarction

MI

Cardiac infarction

Heart Attack

infarctus du myocarde


• Example scenario1. English term entered by clinician to represent an idea2. Term is encoded in SNOMED3. Code is recorded in Electronic Health Record4. Record is retrieved5. Record is transmitted to another application or institution6. Code is extracted7. Term is requested e.g.,

• French term• Consumer term• French consumer term

Interplay among Terminology Elements


Why Code Data? (translation and understanding)

• Cold– February is a cold month.– She met his gaze with a cold stare.– Julia is in bed with a cold.

February is a 45893009 month.She met his gaze with a 285846001 stare.

Julia is in bed with a 82272006.


Data Aggregation

Term Description ID Concept ID

myocardial infarction 37436014 22298006

cardiac infarction 37442013 22298006

heart attack 37443015 22298006

myocardial infarct 1784873012 22298006

MI - Myocardial infarction

1784872019 22298006

infarction of heart 37441018 22298006


Strategic Role of Vocabulary

• Interface to Knowledge Resources– Guidelines, Critical Paths, Reminders– Decision Support, Reference

• Support Practice Analysis– Quality Improvement– Clinical Epidemiology– Outcomes Analyses


Outline



Terminology Definitions

• A set of concepts, designations, and relationships for a specialized subject area

• The terms that are characterized by special reference within a discipline are called the terms of the discipline and collectively form the Terminology. Terms that function in general reference over a variety of languages are simply words, their totality is a Vocabulary.


How do we represent patient data?

• Reference Terminologies– SNOMED CT®, LOINC®

• High Level Classifications – ICD-10

• Terminologies with a specific purpose– DPG – Day Procedure Group– CMG – Case Mix Groups

• Within the context of information models– ISO, HL7, openEHR, …


Types of Clinical Terminologies


Reference Terminologies VS Interface Terminologies

Reference Terminologies• Represent a large number and range of possible concepts in a consistent manner• Specify relationships between concepts• Meet requirements for a semantic foundation for reliable retrieval

– Based on inherent meaning– Independent of initial purpose of collection

• May not meet the requirements for ease of data entry

Interface Terminologies• Assist entry and display of information

– Synonyms, etc (alternate or common terms)– Provides a national refinement option

• Provides consistent data entry• Does not meet the requirement for data retrieval based on implicit meaning

A combination of Interface & Reference Terminology features is required to meet data entry AND retrieval requirements.


Terminology Models

May consist of the following attributes• Code system• Code system version• Concept• Code• Concept Designation • Concept Property• Concept Relationship


An example of a Terminology Information Model

http://biomedgt.org/apelcore/index.php/Image:Upper_Level_Class_Model_-_v5.jpg


Concepts

• Concept defines a unitary mental representation of a real or abstract thing; an atomic unit of thought

• Should be unique in a given terminology• May have synonyms in terms of representation• May be a primitive or compositional term


Coded Concept

• A Coded Concept is unique within the Code System that defines it.

• Coded Concepts may be characterized by zero or more Concept Properties.

• A Coded Concept has the following minimal attributes: – code - an identifier that uniquely names the class or "concept"

within the context of the defining Code System. – status - represents the current status of the Coded Concept

within the Code System.


Metadata

• Data about a datum• Allows for a full description of a data element such that the data

element can be classified and potentially reproduced• Provides the necessary information to allow vocabulary

interoperability

• Example includes the following LOINC code 22705-8:

– GLUCOSE:– SCNC:– PT:– UR:– QN:– TEST STRIP

metadata


Concept Domain

• Definition:– An HL7 Concept Domain is a named category of like concepts that will be bound to one or

more coded elements.– Concept Domains exist to constrain the intent of the coded element– Concept Domains are independent of any specific vocabulary or code system or Realm– They exist at the Universal level only and ALL must be registered at HL7 international.

• May further constrain the intent of a Concept Domain by creating a Sub Domain (& therefore create a hierarchy)

• Provides a high level grouping for all things possible in a given domain from which value sets will be constructed

• Naming rules have been created to provide consistency

• Examples: – OrderableLabType


Code System

• At various times referred to as an ontology, classification, terminology, or code set/table.

• Within the HL7 context, a collection of codes with associated designations and meanings– Concept codes within a code set must not change ‘meaning’.– Codes may be added or retired– Definitions may be clarified– New relationships may be established– Codes must not be reused– Names should be unique– Code systems have versions– Contain codes & synonyms– Print names at the concept & code level

• Can have more than one print name– Have semantic relationships between them & hierarchies– Some allow post co-ordination (eg UCUM & SNOMED CT)


Code System (continued)

Code systems may vary in size and complexity from a simple code/value table…

Code Value

M MaleF FemaleU Undifferentiated

… to a complex reference terminology containing many 100,000’s of concepts, relationships and the like.


Code System Examples

• LOINC• CPT-4• NIC• NOC• ICD-9-CM• ICD-10• SNOMED International• SNOMED-CT• ISO 4217 Currency codes

• ISO 3166-1 Country Codes• IETF Mime Types• HL7 Version 2 Table 1• ISO 639 Language Codes• International Airport Codes• IANA Character Sets• HL7 Version 3

Administrative Gender• HL7 Version 3 ActClass …


Value Sets• A Value Set represents a uniquely identifiable set of valid concept representations,

where any concept representation can be tested to determine whether or not it is a member of the value set.

• Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content, and must contain at least one concept representation.

• All have an OID & may have it’s own name• Can refer to a specific version of a code system• They can exist in UV as X_Domains (although do not need this format for the name any

longer)• Can create a sub-Value Set• Value set complexity 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.

• Can be expressed as– Enumerated (or extensional)

• specifies a complete set of codes– Intentional (or definitional, expression)

• “filter” or rules are defined to specify the allowable codes• Can consist of codes from one or more code systems BUT cannot have representations of a

single concept from more than one code system


Structural Vocabulary

• Vocabulary intended to define the structural classes in a data model from which objects can be created– Examples; the HL7 Version 3 structural codes that define Class

Codes, Mood codes etc. or a high level namespace in an ontology model describing a grouping for more primitive concepts such as “Living Organism” with sub-classes of “Virus, Bacterium, Fungi, Parasite”

• These codes identify information structures in HL7 that are used to inform the message objects that will carry the clinical data; they are not generally the clinical objects!

• The value of this kind of code carried in a data element may not change after the class in which it appears is instantiated


Descriptive Vocabulary

• Defines the terms and codes for concepts• The data used to populate a data element• Provides the core component for system and data

interoperability• Examples:

– Anthrax– Gram negative rod– centrifugal rash– MRI of brain

• These are the information payload that are carried in the fields in a message or an information model instance


Binding Realms

• Defines the interoperability space• Restricts what may be carried in a coded model element

– May restrict (instantiate) a Concept Domain, being bound to it within a Realm (Representative Realm Binding

– May be bound directly to the model element (universally where the model is used)

• There are 4 types of Realms (Universal, Representative, Example & Unclassified)– Universal

• constitutes the core HL7 realm which by definition is invariable. Structural elements and most datatypes are examples of contents in this realm.

– Representative• content that provide a plausible basis for adoption across specialized (including geographic) realms (ie Allows

jurisdictions to author value sets, templates, and content)• Content must be sufficiently comprehensive and internally consistent to be adoptable and implementable by

specialized realms. • Affiliates may choose to use an existing representative value set when determining what bindings to use within

their binding realm – Example

• In the absence of Representative Realm HL7 provides a Realm to designate content with no expectation to be complete or implementable.

– Unclassified• a realm that can accommodate content that is new and being created or legacy content that has not yet been

promoted to one of the three main realms.


Terminology Binding

• Terminology Binding is the link between the terminology component and the message model and determined by the Binding Realm.• Concept Domain in the message model is tied to a value set with the

terminology (with a start & end date)

• The binding may be to a specific set of codes or a changing set of codes• Static Binding - the allowed values of the value set do not change

automatically as new values are added to a value set.

• Dynamic Binding - the intent is to have the allowed values for a coded item automatically change (expand or contract) as the value set is maintained over time


Global Uniqueness (OIDs)

• All identifiers must be globally unique and OIDs (Object Identifiers) are used to achieve uniqueness

• Sequence of integers representing a Registration Authority tree– “…a convenient mechanism for assigning world-unique

identifiers to standard-related objects”1

• Each OID uniquely identifies something– Could be a Registration Authority (such as HL7)– Could be a Registered Object (such as LOINC)

• New entries can be registered in a de-centralized fashion

• http://hl7.org/oid/index.cfm• http://www.oid-info.com/cgi-bin/display?tree=

http://hl7.org/oid/index.cfm

http://www.oid-info.com/cgi-bin/display?tree=

http://www.oid-info.com/cgi-bin/display?tree=


Global Uniqueness (OIDs)

• Used in health informatics for uniquely identifying entities, concepts & events

• Five types of OIDs– Common Public Identifiers

• Real-world identifiers which are known by humans & frequently used outside of the direct business relationship with the issuer of the identifier (e.g. SIN, driver’s license)

– Local Public Identifiers• Typically generated by generated by clinical systems & communicated in their

message (e.g. lab order or prescription #s)– Private Identifiers

• Include identifiers necessary for smooth operation of automated systems & not used by practitioners or patients (e.g. event, query, application identifiers)

– Common Code Systems• Include all code systems intended for use where the organization responsible is not the

sender/receiver (e.g. LOINC®, SNOMED CT®)– Local Code Systems

• Those that are only used in communication by or with the organization responsible for creating that code system (e.g. internal lab test codes).


Outline


Common Terminology Services (CTS)


What CTS is

• An HL7 ANSI standard– Defines the minimum set of requirements for interoperability across

disparate healthcare applications

• A specification for accessing terminology content– The CTS identifies the minimum set of functional characteristics a

terminology resource must possess for use in HL7.

• A functional model– Defining the functional characteristics of vocabulary as a set of

Application Programming Interfaces (APIs)


The Problem

• Terminology systems vary considerably in both content and structure.– NDF-RT– RxNorm– SNOMED-CT– ICD-9 and ICD-10– CPT

• Requirements of terminology vary widely• Implementation decisions of terminology vary widely• Storage formats may differ (relational database, XML, ...)


Common Terminology Services (CTS)

• Purpose is to specify a common Application Programming Interface (API) to access terminological content

• 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 API

Application

Service

Interface

Data

CTS

. . .


CTS API

CTS

MS AccessTables

Application

Service

Interface

Data

HL7Vocab

Browser

HL7 Terminology

Server

Find codes having “*myelitis”

Select * from VOC_concept_designationWHERE text like ‘%myelitis’


CTS API – Different Client, Same Service

IHC

Picklist

Tool

MS AccessTables

Application

Service

Interface

Data

HL7 Terminology

Server

Find codes having “*icillin”

Select * from VOC_concept_designationWHERE text like ‘%icillin’

CTS


CTS API – Different Server, Same Client

IHC

Picklist

Tool

SNOMED

CT

OracleTables

Application

Service

Interface

Data

APELONDTS


Select * from conc_reprWHERE text like ‘%icillin’

AND ...

CTS


CTS API – Distributed Services

IHC

Picklist

Tool

Internet Service

Application

Service

Interface

Data


<msg><soap....><filter=“*icillin”...</msg>

CTS

WebPortal


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”


Common Terminology Services

Message Processing ApplicationMessage Processing Application

VocabularyVocabulary

Vocabulary

Message Processing Application

Message API

Vocabulary API



Runtime Browser

Message API Message Runtime Message Browser

Vocabulary API Vocabulary Runtime

Vocabulary Browser

Mapping / Translation Vocabulary Mapping

• Services Are Also Partitioned by Function


Code System – CTS Model


CTS Runtime Message API Examples

Function Description

validateCode Determine whether the supplied coded attribute (CD) is valid in this vocabulary domain and context.

validateTranslation Determines whether the translation portion of the coded attribute is valid in this domain and context.

translateCode Translate the input code into a form that is valid in the target contexts.


CTS Runtime Message API Examples


fillInDetails Fill in the details for the coded attribute, including all code system names, versions and display names.

subsumes Determine whether the parent attribute subsumes the child.

areEquivalent Determine whether attribute value 1 and 2 are logically equivalent

lookupValueSetExpansion Return a hierarchical list of selectable concepts for the vocabulary domain and context


CTS Runtime Vocabulary API


lookupCodeSystemInfo Return detailed information about the named code system

isConceptIdValid Determine whether the concept code is valid in the code system.

lookupDesignation Determine whether the relationship exists between the source and target code


Additional CTS API’s

• CTS Message Browsing API– Used by HL7 Modelers

• CTS Vocabulary Browsing API– Used by HL7 Terminology Authors and Value Set Building

• CTS Mapping API– Used to translate concept codes from one system to another

Details can be found on HL7 Ballot spec



• Interface specification– Different message processing applications, same functions– Different terminology structures, philosophy – same behavior

• Language Bindings– (Currently) specified in OMG IDL– Java interface binding– Java bean binding– WSDL/SOAP binding

• Version 1.0 Finalized Spring 2004– CTS1 balloted and adopted as an ISO standard Fall 2008

• Version 2.0 Balloted Spring 2008



Resources:• Specification:

– http://hl7.org• Implementations:

http://informatics.mayo.edu/

http://hl7.org/

http://informatics.mayo.edu/


CTS 2

• CTS I Limitations– Varying Vocabulary Formats– Varying repository formats– Vocabulary content overlap

• CTS 2– Functional Specification– Functionality Enhancements

• Terminology Authoring• Management of Terminology Versions• Enhanced Terminology Mapping Functions

– SOA SIG / HSSP– Based on a common model for vocabulary

• Terminology Use and Development Lifecycle Model


CTS 2 Status

• Being worked on by a long list of contributors– IHTSDO– Mayo Clinic– GE, Apelon– UC Davis, Emory– Others…

• Was balloted as a DSTU in March 2009• Comments are going through the disposition process• Is being updated with the ‘new’ HL7 vocabulary model

– Currently only implemented in the MIF• Current plan is to ballot CTS 2 as a DSTU in the March 2009 ballot

cycle


Conclusions

• Vocabulary covers a lot of territory• Critical component for interoperability• There is a lot more involved than a table of

mnemonics• There are significant resources available• Come and contribute in the Vocabulary Technical

Committee! Questions? Thank you very much!


Thank you

Russell HammInformatics ConsultantApelon, [email protected]

mailto:[email protected]

Documents

Introduction to Vocabulary Russell Hamm Informatics Consultant Apelon, Inc. Co-chair HL7 Vocabulary WG Adapted from Ted Klein, CG Chute MD DrPH, Stan M