Introduction to Vocabulary

Introduction to Vocabulary Russell Hamm Informatics Consultant Apelon, Inc. Co-chair HL7 Vocabulary WG HL7 Tutorial May, 2009 St. Paul, MN (Yay!) Adapted from Ted Klein, CG Chute MD DrPH, Stan M. Huff MD, Beverly Knight,Cecil Lynch MD, Russ Hamm

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 © 2002-2009, Health Level Seven, Inc.

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) • … © 2002-2009, Health Level Seven, Inc.

Structured Terminology Elements Cardiac disorder Cardiopathy Myocardial finding (finding) 251052000 Heart disease (disorder) 56265001 Myocardial observation Disorder of heart Heart disease, NOS Disorder of heart muscle Myocardial disease (disorder) 57809008 Morbis cordis Disorder of Myocardium Myocardial infarction Myocardial disease, NOS MI Cardiac infarction Heart Attack infarctus du myocarde • Conceptsrepresent unique ideas • Codes uniquely identify concepts • Termsrefer to concepts • Typically • Humans communicate concepts using terms • Computers communicate concepts using codes • Concepts are language independent; terms are dependent Myocardial infarction (disorder) 22298006 © 2002-2009, Health Level Seven, Inc.

Interplay among Terminology Elements • Example scenario • English termentered by clinician to represent an idea • Term is encoded in SNOMED • Code is recorded in Electronic Health Record • Record is retrieved • Record is transmitted to another application or institution • Code is extracted • Term is requested e.g., • French term • Consumer term • French consumer term © 2002-2009, Health Level Seven, Inc.

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 a45893009month. She met his gaze with a285846001stare. Julia is in bed with a82272006. © 2002-2009, Health Level Seven, Inc.

Strategic Role of Vocabulary • Interface to Knowledge Resources • Guidelines, Critical Paths, Reminders • Decision Support, Reference • Support Practice Analysis • Quality Improvement • Clinical Epidemiology • Outcomes Analyses © 2002-2009, Health Level Seven, Inc.

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. © 2002-2009, Health Level Seven, Inc.

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, … © 2002-2009, Health Level Seven, Inc.

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. © 2002-2009, Health Level Seven, Inc.

Terminology Models May consist of the following attributes • Code system • Code system version • Concept • Code • Concept Designation • Concept Property • Concept Relationship © 2002-2009, Health Level Seven, Inc.

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 © 2002-2009, Health Level Seven, Inc.

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. © 2002-2009, Health Level Seven, Inc.

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 © 2002-2009, Health Level Seven, Inc.

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 © 2002-2009, Health Level Seven, Inc.

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) © 2002-2009, Health Level Seven, Inc.

Code System (continued) Code systems may vary in size and complexity from a simple code/value table… … to a complex reference terminology containing many 100,000’s of concepts, relationships and the like. © 2002-2009, Health Level Seven, Inc.

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 … © 2002-2009, Health Level Seven, Inc.

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 © 2002-2009, Health Level Seven, Inc.

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 © 2002-2009, Health Level Seven, Inc.

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 © 2002-2009, Health Level Seven, Inc.

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. © 2002-2009, Health Level Seven, Inc.

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 © 2002-2009, Health Level Seven, Inc.

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= © 2002-2009, Health Level Seven, Inc.

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). © 2002-2009, Health Level Seven, Inc.

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 functionalcharacteristics 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) © 2002-2009, Health Level Seven, Inc.

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, ...) © 2002-2009, Health Level Seven, Inc.

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 © 2002-2009, Health Level Seven, Inc.

CTS API HL7 Vocab Browser CTS Application Find codes having “*myelitis” Interface HL7 Terminology Server Service Select * from VOC_concept_designation WHERE text like ‘%myelitis’ MS Access Tables Data © 2002-2009, Health Level Seven, Inc.

CTS API – Different Client, Same Service IHC Picklist Tool CTS Application Find codes having “*icillin” Interface HL7 Terminology Server Service Select * from VOC_concept_designation WHERE text like ‘%icillin’ MS Access Tables Data © 2002-2009, Health Level Seven, Inc.

CTS API – Different Server, Same Client IHC Picklist Tool CTS Application Find codes having “*icillin” Interface APELON DTS Select * from conc_repr WHERE text like ‘%icillin’ AND ... Service SNOMED CT Oracle Tables Data © 2002-2009, Health Level Seven, Inc.

CTS API – Distributed Services IHC Picklist Tool CTS Application Find codes having “*icillin” Interface <msg><soap....><filter=“*icillin”...</msg> Service Web Portal Internet Service Data © 2002-2009, Health Level Seven, Inc.

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” © 2002-2009, Health Level Seven, Inc.

Common Terminology Services Message Processing Application Message Processing Application Message Processing Application Message API Vocabulary API Vocabulary Vocabulary Vocabulary © 2002-2009, Health Level Seven, Inc.

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 © 2002-2009, Health Level Seven, Inc.

Common Terminology Services • 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 © 2002-2009, Health Level Seven, Inc.

Introduction to Vocabulary