Toward Vocabulary Domain Specifications for Health Level 7--coded Data Elements

Journal of the American Medical Informatics Association Volume 7 Number 4 Jul / Aug 2000 333

JAMIAThe Practice of Informatics

White Paper n

Toward VocabularyDomain Specifications forHealth Level 7–codedData Elements

SUZANNE BAKKEN, RN, DNSC, KEITH E. CAMPBELL, MD, PHD, JAMES J. CIMINO, MD,STANLEY M. HUFF, MD, W. ED HAMMOND, PHD

A b s t r a c t The ‘‘vocabulary problem’’ has long plagued the developers, implementers,and users of computer-based systems. The authors review selected activities of the Health Level7 (HL7) Vocabulary Technical Committee that are related to vocabulary domain specification forHL7 coded data elements. These activities include: 1) the development of two sets of principlesto provide guidance to terminology stakeholders, including organizations seeking to deploy HL7-compliant systems, terminology developers, and terminology integrators; 2) the completion of asurvey of terminology developers; 3) the development of a process for HL7 registration ofterminologies; and 4) the maintenance of vocabulary domain specification tables. As background,vocabulary domain specification is defined and the relationship between the HL7 ReferenceInformation Model and vocabulary domain specification is described. The activities of theVocabulary Technical Committee complement the efforts of terminology developers and otherstakeholders. These activities are aimed at realizing semantic interoperability in the context of theHL7 Message Development Framework, so that information exchange and use among disparatesystems can occur for the delivery and management of direct clinical care as well as for purposessuch as clinical research, outcome research, and population health management.

n J Am Med Inform Assoc. 2000;7:333–342.

Affiliations of the authors: Columbia University, New York,New York (SB, JJC); The Permanente Medical Group, Oakland,California (KEC); Intermountain Health Care, Salt Lake City,Utah (SMH); Duke University, Durham, North Carolina (WEH).

The preparation of this manuscript was supported in part bygrant NIH-NR04423 from the National Institutes of Health.

Correspondence and reprints: Suzanne Bakken, RN, DNSc,School of Nursing, Columbia University, New York, NY 10032;e-mail: ^[email protected]&.

Received for publication: 9/24/99; accepted for publication:12/28/99.

Tremendous efforts by terminology developers andmedical informatics researchers during the last decadehave focused on the representation of health care datain a manner that facilitates the use and re-use of in-formation. Despite these efforts, ‘‘the vocabularyproblem’’ remains unsolved; that is, there are nowidely available agreed-on standards for representinghealth care information.1–8 Moreover, evaluation stud-ies indicate that there are gaps in the content coveredby existing terminologies and that the majority of ter-minologies are not represented in a manner that fa-cilitates implementation into computer-based systemsor terminology management using knowledge-based

group.bmj.com on July 14, 2011 - Published by jamia.bmj.comDownloaded from

http://jamia.bmj.com/

http://group.bmj.com/

334 BAKKEN ET AL., Specifications for Health Level 7 Elements

F i g u r e 1 A domain specification for gender.

approaches.9–12 In this article, we highlight selected ac-tivities of one organization, Health Level 7 (HL7), thatis addressing the ‘‘vocabulary problem.’’

Health Level 7 is a standards development organiza-tion, accredited by the American National StandardsInstitute, that is focused on interoperability for the in-terchange of health care data.13 The Institute of Elec-trical and Electronic Engineers (IEEE) defines inter-operability as ‘‘the ability of two or more systems orcomponents to exchange information and to use theinformation that has been exchanged.’’14 Much ofHL7’s earlier work dealt with the functional part ofthe definition, ‘‘. . . to exchange information.’’ In 1996,HL7 created the Vocabulary Special Interest Group,which was promoted to a Technical Committee (TC)in 1998. The Vocabulary TC is focused on the semanticaspect of the definition, ‘‘. . . to use information.’’

The overall objectives of the Vocabulary TC are toidentify, organize, and maintain terms used in codedfields for HL7 messages. As a part of the efforts tomeet these objectives, the Vocabulary TC assumes theresponsibility to define a vocabulary domain for eachcoded entry message field. Health Level 7 proposesthat the values in the vocabulary domains come frompre-existing terminologies in which they are availableand adequate. When appropriate standard terminol-ogies are not available, HL7 will develop a satisfac-tory solution. Thus, the work of the TC builds on andcomplements that of terminology developers, termi-nology integration organizations, and medical infor-matics researchers.1,4,6–8,15

In this article, we review selected activities of the Vo-cabulary TC that relate to vocabulary domain speci-

fication for HL7 coded elements, in order to informterminology stakeholders (e.g., organizations seekingto deploy HL7-compliant systems, terminology de-velopers, and terminology integrators) about the ap-proaches being undertaken. As background, we de-fine vocabulary domain specification and brieflydescribe the relationship between the HL7 ReferenceInformation Model (RIM) and vocabulary domainspecification.16 Our review focuses on the followingactivities: 1) the development of two sets of principles(principles for HL7-compliant terminologies and prin-ciples for HL7-sanctioned terminology integration ef-forts) to provide guidance to terminology stakehold-ers, 2) the completion of a survey of terminologydevelopers, 3) the development of a process for HL7registration of terminologies, and 4) the maintenanceof vocabulary domain specification tables.

Background

Vocabulary Domain Specification

The basic idea of vocabulary domains is, intuitively,quite simple. A vocabulary domain is the set of al-lowed values for a coded field. If a message instancecontains a marital status field, then the vocabulary do-main for that field would consist of the allowed val-ues for that field, which are, single, married, widowed,divorced, and separated. The reason for defining a vo-cabulary domain for coded fields is to strengthen thesemantic understanding and computability of thecoded information that is passed in HL7 messages.The assumption is that if there is a public definitionof what values a coded field can take, systems on thereceiving end of an interface will have a better un-derstanding of how to use the data in their systems.The intent is that the coded data can be used in ap-plications supporting direct patient care, outcomeanalysis and research, generation of alerts and re-minders, and other kinds of decision support pro-cesses.

The Relationships Between Vocabulary DomainSpecification and the HL7 RIM

The HL7 RIM is a coherent, shared information modelthat is the source of the data content of all HL7 mes-asges. The evolving version 3 of the HL7 RIM hasbeen developed through a consensus process that in-cludes harmonization activities in order to incorporateefforts of HL7 message development groups. Messagedevelopment groups focused on a particular subjectdomain (e.g., patient care, blood bank) develop mes-sages for that domain and work with a subset of rel-evant concepts. A comprehensive description of themessage development process is beyond the scope of





this paper. We refer the reader to the Message Devel-opment Framework (MDF) document for details.16

Each coded attribute in the RIM requires a vocabularydomain specification. As shown in Figure 1, genderocdis an attribute of Patient. The genderocd attribute hasbeen assigned the vocabulary domain Gender. Its ex-tensibility is ‘‘coded with exceptions,’’ meaning thatthe gender attribute should be valued from items inthe gender domain, but free text exceptions are al-lowed. The vocabulary domain specification for theattribute, in this instance, comes from an HL7 tablethat lists all the allowed values for Gender. However,vocabulary domain specifications for coded attributesassociated with the majority of concepts required forHL7 messages (e.g., diagnoses, signs, symptoms, bodyparts) will come from standard terminologies.

HL7 Terminology Principles

Given HL7’s commitment to using pre-existing ter-minologies when possible, two sets of principles weredeveloped by the Vocabulary Technical Committee.The principles seek to assist stakeholders in determin-ing which terminologies should be used in HL7 mes-sages and facilitate terminology integration efforts ina manner consistent with the needs for HL7 messag-ing.

Principles for HL7-compliant Terminologies

The Vocabulary Technical Committee developed a setof principles regarding the manner in which end usersshould determine what terminologies should be in-cluded in HL7 messages for a specific organization.13

The development of these principles was viewed fromdifferent perspectives, which were challenging to re-solve, but the current principles reflect a consensusamong the participating committee members.

Implicit in these principles is the recognition that var-ious organizations place different values on particularcharacteristics of terminology systems (e.g., cost, qual-ity, timeliness of maintenance, interoperability, scien-tific validity). In addition, at least for the near future,‘‘one size does not fit all’’ with regard to terminologysystem selection, and the specific decisions regardingthe terminology systems need to be made by the or-ganizations that deploy HL7-compliant systems. Asorganizations gain more experience in deploying ter-minology systems, the principles may expand andspecific terminology systems may create de facto mar-ketplace standards.

The specific agreed-on principles are:

n The terminology must be compliant with the se-mantics of the HL7 message structure.

n The terminology provider must be willing to par-ticipate in HL7-sanctioned interoperability efforts.

n There must be an organization committed to thetimely maintenance and update of the terminology.

n Terminology license fees should be proportional tothe value they provide to the enterprise and the enduser but should not be out of proportion to the de-velopment and support costs of the terminology it-self.

n The terminology should be comprehensive for theintended domain of use.

n Regulatory circumstances may require the adoptionof specific terminologies. The use of such terminol-ogies, provided that they are consistent with Prin-ciple 1 above, shall not be considered a deviationfrom the HL7 standard.

Because multiple terminology systems will be in usefor the near future, the Vocabulary Technical Com-mittee recognized the importance of supporting ter-minology interoperability efforts (such as the UnifiedMedical Language System [UMLS]17 and Open-GALEN,18 and created a set of guiding principles forfacilitating these efforts for HL7 purposes.

Principles for HL7-sanctioned TerminologyIntegration Efforts

The following principles describe general groundrules for how terminology providers and terminologyintegrators should work together but intentionally de-scribe nothing about the specifics of how terminolo-gies should be integrated.13 There are many differentoptions for how terminologies may be integrated intoa functional integrated system, and these details arein the purview of the implementers, not that of theVocabulary Technical Committee.

The specific principles are, first, that a source termi-nology provider must be willing to publish a limitedconceptual model sufficient for HL7 implementationand allow HL7 to implement those or derivative in-formation models in their applications without roy-alty. The HL7 organization is free to incorporate thoseor derivative information models in the HL7 stan-dard.

Second, within the limitations stated by an appropri-ate written agreement, a terminology will be providedby the terminology provider to any HL7-sanctionedterminology integration organization (TIO) effort thatwishes to integrate the terminology content with thatof others. One possible candidate TIO is the NationalLibrary of Medicine’s UMLS. For the purposes of anintegration effort, the terminology integration orga-





Table 1 n

Terminologies Represented by SurveyRespondents (N = 25)

Alternative Billing Concepts (ABC)22

American Dental Association, Code on Dental Procedures andNomenclature (Dental Procedure)19

American Dental Association, Systemized Nomenclature ofDentistry (SNODENT)20

Centers for Disease Control, Common Data Element Implemen-tation Guide (CDC)23

First DataBank (FDB), nine terminologies—National Drug DataFile, Master Drug Data Base, International Drug Data File,PIF, DDID (drug descriptor identification code), MultilexDrug Knowledge Base, FDBDX (disease code), Medical Con-ditions24

Health Care Financing Administration, Procedure Coding Sys-tem (HCPCS)25

Home Health Care Classification (HHCC)26

International Classification of Diseases, 9th revision, ClinicalModification (ICD-9-CM)27

International Classification of Diseases and Related HealthProblems Procedure Coding Systems (ICD-10-PCS)28

International Classification of Primary Care (ICPC)29/Interna-tional Classification of Primary Care Drug Codes (ICPCDrugs)30

Logical Observation Identifiers, Names, and Codes (LOINC)6

Medicomp Systems (MEDCIN)31

Multum MediSource Lexicon (Multum)32

National Health Service [U.K.], Clinical Terms [formerly ReadCodes] (NHS)33

North American Nursing Diagnosis Association Taxonomy 1(NANDA)34

Nursing Intervention Lexicon and Taxonomy (NILT)35

Nursing Interventions Classification (NIC)36

Nursing Outcomes Classification (NOC)37

Omaha System (Omaha)38

Patient Care Data Set (PCDS)39

Perioperative Nursing Data Set (AORN)40

Physicians’ Current Procedural Terminology (CPT)21

Russian translation of MeSH (R MeSH)41

Systematized Nomenclature of Medicine (SNOMED)8

Universal Medical Device Nomenclature System (UMDNS)25

NOTE: Abbreviations used in the text are shown in parentheses.

nization is required to implement the terminologyprovider’s system in a way that is approved by theterminology provider, and the terminology integra-tion organization must distribute and license its inte-grated products in accordance with its agreementwith the terminology provider. Participation in HL7-sanctioned terminology integration efforts does notimply that the terminology provider must relinquishany rights to its intellectual property.

Third, the terminology integration organizationshould enter into a written agreement with the ter-minology provider that details the assumption of li-ability pertaining to the accuracy of any resulting in-teroperability products.

Survey of Terminology Developers

The principles generated by the Vocabulary TechnicalCommittee delineate a starting point in the develop-ment of mechanisms for using standard terminologiesto specify vocabulary domains for coded data ele-ments in HL7 messages. As another step in the pathtoward vocabulary domain specification for HL7 mes-sages and semantic interoperability, we conducted asurvey of terminology developers, to gain an under-standing of current patterns of terminology mainte-nance and update, the vocabulary domains includedin existing terminologies, and licensing and fee struc-tures for use in HL7 vocabulary domain specificationand messages.

Methods

The two-part survey was accompanied by a cover let-ter from the Vocabulary Technical Committee co-chairs describing the purpose of the survey. The firstset of questions focused on a description of the ter-minology and its potential vocabulary domain cov-erage for HL7 messages. Each respondent was askedto indicate, on a checklist of vocabulary domains cor-responding to HL7 data elements, the domains forwhich the terminology could provide coded terms.They were also asked to list any additional domainsfor which the terminology might serve the needs ofHL7 coded data elements.

The second set of questions related to licensing andfee structures for the use of the terminology for HL7messaging purposes. They included four different sce-narios: 1) use of the terminology by HL7 for vocabu-lary domain specification for HL7 messages, 2) use ofthe terminology within an organization and to sendmessages, 3) mapping to the terminology from an-other terminology to send a message, and 4) mappingto the terminology from another terminology to re-

ceive a message. The survey was distributed by mailto the developers of the source vocabularies of theUMLS, to developers of terminologies recognized bythe American Nurses Association, and to pharmacysystem knowledge-base vendors. The survey was alsoavailable on the HL7 Web site. Surveys were returnedby mail or electronically. Survey responses were tab-ulated and descriptive statistics calculated.

Results

Of the 75 surveys distributed, 25 responses regarding34 terminologies were recieved. The survey respon-dents (Table 1) included the providers of the majorclinical and administrative terminologies as well asproviders of specialized terminologies for alternativetherapies, demographics, dentistry, medical devices,





Table 2 n

Frequency of Updates and UMLS Status for EachTerminology

Frequency ofTerminology Updates* UMLS Status†

AORN L PABC Q ICDC M PCPT A IDental Procedures A P

FDB W IHCPCS A IHHCC L IICD-9-CM A I

ICD-10-PCS A IICPC/ICPC Drugs L ILOINC Q IMEDCIN L S

Multum W INHS B, M (drugs) INANDA L INIC L I

NILT L NNOC L IOmaha L IPCDS L I

R MeSH A ISNODENT A ISNOMED B IUMDNS A I

NOTE: The full title of each terminology appears in Table 1.*L indicates less than annually; A, annually; B, biannually; Q,quarterly; M, monthly; W, daily/weekly.†I indicates included; S, submitted; P, plan to submit; N, no planto submit.

nursing, and pharmacy knowledge bases.8,19–41 In ad-dition, the respondents represented those terminolo-gies that evaluations have found to possess the bestdomain coverage.9,42,43 Nonrespondents included theproviders of terminologies that were developed forspecialized applications (e.g., symptom terms for di-agnostic decision support systems) and for transla-tions of the MeSH codes. Thus, the respondents re-flected a representative sample of terminologies thatwould be used for vocabulary domain specificationfor HL7 purposes.

The frequency of updates ranged from daily to irreg-ularly and was related to the rate at which newknowledge is generated in the domain and to the de-mand for the new knowledge. For example, the ter-minologies of the drug knowledge-base vendors areupdated daily, whereas the nursing terminologies areupdated less often than yearly (Table 2). Almost allthe terminologies were already included in or hadbeen submitted or planned for submission to theUMLS as source vocabularies (Table 2).

As shown in Table 3, all vocabulary domains had atleast two terminologies for which respondents re-ported contents for the domain, although seven ter-minologies had only one domain each. The broadestcoverage across vocabulary domains was reported forMEDCIN, NHS, and SNOMED.* With the exception ofSNOMED and NHS, only nursing terminologies (i.e.,AORN, HHCC, and NOC) reported that outcome in-dicators were included. Additional domains reportedby the respondents beyond those listed in the surveyincluded dental diagnoses, dental procedures, exter-nal causes of injury, social history, medical history,family history, physical therapy, social work, occupa-tional therapy, speech and language therapy, disabil-ity, functional performance, occupations, and healthknowledge and behaviors.

Seven respondents did not provide answers to thesurvey questions related to license and fee structures.However, several of these indicated that the surveyhad stimulated discussion of the license and fee struc-tures for HL7 domain specification and messagingand that these issues were subsequently under reviewin their respective organizations. The majority of re-sponses did not differentiate license and fees relatedto the four different scenarios of terminology use de-scribed in the questionnaire. The responses fell intothree main categories. The first category comprisedthe public domain (terminologies (e.g., HHCC, ICD-10-PCS) that reported no license or fee for any use ofthe terminology. The second category included those

*Terminology abbreviations are shown in Table 1.

terminologies (e.g., Multum, UMDNS) that require alicense but no fee for the uses described in the survey.The terminologies in the third category reported thata license and fee would be required. MEDCIN andNANDA indicated that a nominal fee would becharged. Others (e.g., FDB, SNOMED, CPT) reportedthat the fee was negotiable dependent upon use.

Support for Terminology Users

HL7 Registration of Terminology Systems

The Vocabulary Technical Committee recognizes thatorganizations need information to help them deter-mine which terminology systems they should deploy.While the resources of the Vocabulary TechnicalCommittee do not enable it to collect, organize, andprovide access to many pieces of information (e.g.,evaluative studies of all terminologies), the Tech-nical Committee determined that providing standard-




338B

AK

KE

NE

TA

L.,Sp

ecification

sfor

Health

Level

7E

lemen

tsTable 3 n

Vocabulary Domains Included in the Terminology, as Reported by RespondentsVocabulary Domain A B C D E F G H I J K L M N O P Q R S T U V W X

Adverse drug reactions 2 1 1 2 1 1 1 1

Allergies (e.g., drug, food) 2 2 1 1 1 1 1 1

Analytes 1 1

Anatomy 1 1

Billing codes 1 1 2 1 2 2 1 1

Chemicals 1 2 1 1

Chief complaint 2 2 1 1 1 1 1

Demographics 1 1 1 1

Dietary 2 2 2 2 1 2 2 1

Diseases 1 1 1 1 1 1 1

Drug names 1 1 1 1 1

Home health care 2 2 1 1 1 2 2

Imaging orders 2 1 1 1 1

Imaging findings 1 1 1

Laboratory orders 2 2 1 1 1 1 1

Laboratory results 2 1 1 1

Medical diagnoses 1 2 1 1 1 1 1 1

Medical devices 2 2 2 2 1 1 1 1 1

Medical procedures 2 2 1 2 2 1 1 1 1 1

Microorganisms 2 2 1 1 2 1

Nursing diagnoses 1 1 2 1 1 1 1 1 1

Nursing interventions 1 2 1 1 1 1 1 1 1

Nursing outcomes 1 1 1 1 1 1 1

Outcome indicators 1 1 2 1 1

Reasons for health care visit 2 1 1 1 1 1 1

Respiratory care 2 2 1 1 1 1 1

Signs 2 2 1 1 1 1 1 1 1

Symptoms 2 2 1 1 1 1 1 1 1

Topography 1 1 1 1

Trauma 1 1 1 1 1

Vaccines 2 1 2 1 1 1 1

NOTES: R MeSH did not complete this portion of the survey; ICPC and ICPC Drugs were combined in a single response; and the nine FDB terminologies were combinedin a single response. The terminologies are identified as follows: A indicates AORN; B, ABC; C, CDC; D, CPT; E, Dental Procedures; F, FDB, G, HCPC; I, ICD-9-CM; J,ICD-10-PCS; K, ICPC/ICPC Drugs; L, LOINC; M, MEDCIN; N, Multum; O, NHS; P, NANDA; Q, NIC; R, NILT; S, NOC; T, Omaha; U, PCDS; V, SNODENT; W, SNOMED;X, UMDNS. The domains are described as follows: 1 indicates a primary vocabulary domain for the terminology; 2, a secondary vocabulary domain for the terminology.

group.bm

j.com on July 14, 2011 - P

ublished by jam

ia.bmj.com

Dow

nloaded from




Table 4 n

Steps for Health Level 7 (HL7) Registration of aTerminology System13

1. A terminology system sponsor (acceptable to the terminol-ogy development organization being sponsored) will identifythemselves to the HL7 Vocabulary Technical Committee andwill commit to the creation and timely update of the HL7terminology registration documentation.

2. The terminology system sponsor will complete the registra-tion documentation and make the documentation availableto HL7 for posting on the HL7 Web site. This registrationdocumentation will describe how a terminology system is tobe used in HL7 and will include an itemized description ofhow the terminology system meets the principles for HL7-compliant terminologies and an initial list of domain con-straints for HL7 versions 2.x and 3.x in tabular form suitablefor upload into a commericial database, as described inChapter 7 of the Message Development Framework.

3. The terminology system sponsor will respond to questions.Any HL7 member may ask clarifying questions regardingthe principles and the domain constraints. These questionsalone or the questions and their subsequent answers will be-come a permanent part of the registration documents. Ques-tions deemed irrelevant by a majority of the VocabularyTechnical Committee co-chairs may be excluded from, or ed-ited before inclusion into, the registration documentation.

4. Completed registration documents will be submitted duringa regular HL7 meeting. At the time of the next HL7 meeting,allowing for clarifying questions and incorporation of the an-swers for these questions into the registration documenta-tion, the terminology system shall be considered registered.

ized documentation about how terminology systemsadhere to the principles for HL7-compliant terminol-ogies would be significant value to end users.Subsequently, the Technical Committee developed anondiscriminatory process by which any terminologysystem may be registered by a sponsor.

The development of the HL7 registration system isintended to facilitate access to information regardingterminology systems for organizations implementingHL7 and to foster a spirit of cooperation between ter-minology providers and the HL7 organization by pro-viding each stakeholder with a specific role in the de-velopment of semantically rich health care messages.The registration process includes the development ofdocumentation for implementing organizations. Thespecific registration steps are listed in Table 4. Oncethe terminology is registered, the terminology systemsponsor has several obligations. First, advertisementsthat a system is registered with HL7 must include aprominent disclaimer stating that ‘‘HL7 registrationdoes not imply that a system is necessarily appropri-ate for use in HL7 messages.’’ The obvious reason forthis disclaimer is that HL7 does not have the resourcesor the inclination to do an exhaustive evaluation ofthese standard terminologies. Second, the registrationdocumentation must be updated quarterly and dem-onstrate a move toward a more comprehensive spec-ification of vocabulary domain values.

Domain Specification Database

The maintenance of a domain specification databaseis essential because vocabulary domain specificationsare only useful if they can be resolved to a list of al-lowed values for the coded attribute to which theyare attached. All vocabulary domain names are re-solved against a set of HL7 tables that contain thedefinitions of the various vocabulary domains or, al-ternatively, point to external terminologies where thevocabulary domain specifications are defined. The as-sumption is that any process that needs to resolve avocabulary domain name to the list of concepts thatthe vocabulary domain contains can do so by refer-ence to the domain specification database or by ref-erence to external terminology tables or services.

There are four primary data tables in the vocabularydomain specification database.16 Definitions related totable columns and examples of row entries are shownin Figure 2.

n The Vocabulary Domain Definition Table describes thehigh-level definition of a given vocabulary domain.It holds the name of the vocabulary domain and

shows the relationship of the vocabulary domain todifferent realms of use (usually countries, but anyorganizational or political boundary is permissible),and to the various terminologies that are used todefine the vocabulary domain. There is a new rowfor each realm of use and terminology providingvalues for the vocabulary domain. The structureof this table allows a vocabulary domain to be de-fined by recursive reference to other vocabulary do-mains.

n The Vocabulary Domain Relationship Table records therelationship between HL7-maintained vocabularydomains and the concepts that are values in the do-main. An HL7-maintained domain may be com-posed of individual concepts, other domains, orboth.

n The Source Vocabulary Domain Representation Tableshows the relationship between HL7 concepts andcodes and descriptions from specific terminologies.It allows a user of HL7 to see how the conceptsin a given domain can be represented in a spe-cific terminology. The structure of this table cor-responds roughly to the logical structure of theversion 2.x HL7 vocabulary tables. However, the




340B

AK

KE

NE

TA

L.,Sp

ecification

sfor

Health

Level

7E

lemen

ts

F i g u r e 2 Definitions and examples from the four primary data tables in the vocabulary domain specification database. In the Vocabulary DomainRelationship Table, the columns headed HL7 Domain Name* and HL7 Domain Concept Name* are shown for illustrative purposes only; the actual columnsexist in the Vocabulary Domain Definition Table. COLUMN HEADINGS: Code indicates text string used in the code system to identify the concept; CodeSystem, identifier of the code system from which the observation identifier was obtained; Code System Vin, version number of the code system at the timethat the observation identifier was created; Code System Vout, version number of the code system at the time that the observation identifier was retiredor deleted (blank value means that the row exists in the current version of the data); Description, textual representation of the meaning of the entry as itis represented in the code system from which it originated; Expression, an expression that defines how the vocabulary domain is derived from other pre-existing vocabulary domains (e.g., union, difference, intersection); Generality, whether the concept in the HL7 Concept ID column should be interpretedas itself or whether it should be expanded to include its child concepts; HL7 Concept ID, the concept identifier of the item that is being included in thedomain; HL7 Domain ID, unique numeric vocabulary domain identifier; HL7 Domain Concept Name, unique textual name assigned by HL7 for thevocabulary domain concept; HL7 Domain Name, unique textual name assigned by HL7 for the vocabulary domain; HL7 Status, status of the entry in thethe domain specification database (e.g., Proposed, Rejected, Active, Obsolete, Inactive); HL7 Vin, version number of the domain specification database atthe time this entry was added or updated; HL7 Vout, version number of the domain specification database at the time this entry was modified or deleted;Language, the language used in the description; Observation ID, observation identifier to which a vocabulary domain is being linked; Source Domain ID,the name of the domain in the original source that contains this concept; Realm, realm of use of the vocabulary domain (e.g., country or organization);Relationship, name of the relationship that exists between the domain and the concept listed in the HL7 Concept ID column.

group.bm

j.com on July 14, 2011 - P

ublished by jam

ia.bmj.com

Dow

nloaded from




Table 5 n

General Process of MaintainingDomain Specifications13

1. The specification of vocabulary domains and vocabulary do-main harmonization will be patterned after the RIM har-monization process and will happen in conjunction with RIMharmonization meetings.

2. At least two Vocabulary Technical Committee members willbe appointed as vocabulary facilitators to the message de-velopment Technical Committees by the co-chairs of the vo-cabulary Technical Committee and approved by the co-chairsof the relevant message development Technical Committee.People with a special interest may also be appointed to bethe stewards of specific tables.

3. For vocabulary domains that are shared by more than onemessage development Technical Committee, a single Tech-nical Committee will be chosen as steward, with all inter-ested parties having an opportunity to provide input, follow-ing the harmonization rules adopted for shared RIM projects.

4. The message development Technical Committees have theultimate responsibility to define the vocabulary domains re-ferenced by the RIM objects for which they are the stewards.

5. The vocabulary facilitators have the responsibility to see thatgood vocabulary practices are followed and to physicallymaintain the vocabulary domain specification database ac-cording to the definitions provided by the Technical Com-mittees.

6. Any new concepts created by Health Level 7 (HL7) TechnicalCommittees will be submitted to HL7-registered terminologydevelopers for potential inclusion in the standard terminol-ogies.

7. All HL7-registered terminology providers are welcome toprovide mappings to HL7 domains using their terms andcodes. The terminology providers are responsible for map-ping their concepts to the concepts in the domain. Any pro-prietary terminologies used in HL7 specifications or inter-faces must be properly licensed according to the licensingpolicies of the terminology provider.

content of the Source Vocabulary Domain Rep-resentation Table can be provided by HL7 or byany terminology provider that wants to use theHL7 domain specification database as a mechanismfor making their terminology available for use inHL7 messages.

n The Observation Identifier to Vocabulary Domain Link-ing Table is used to link an observation identifier,e.g., a LOINC code,6 with a vocabulary domain.This table is used when it is desirable to specify theexact vocabulary domain that should be associatedwith a coded observation identifier as used in a ser-vice event, assessment, or observation instance.

The general process of maintaining domain specifi-cations is summarized in Table 5.

Discussion

The ‘‘vocabulary problem’’ has long plagued the de-velopers, implementers, and users of computer-basedsystems.5,44 Tremendous strides have been made in re-cent years in the development and maintenance ofstandard terminologies that are atomic in nature andrepresented in a manner that renders them more suit-able for implementation into and manipulation bycomputers.2,4,8,15,45 The activities of the VocabularyTechnical Committee complement the efforts of ter-minology developers and other stakeholders. The twosets of principles that were developed are aimed atproviding guidance and support to various stakehold-ers in relationship to terminology requirements forHL7 messages. Our survey results indicate that stan-dard terminologies are available and appropriate forproviding vocabulary domain specifications (i.e.,value sets) for many categories of coded elements forHL7 messages. Issues related to licenses and fees foruse in vocabulary domain specifications require fur-ther discussion among stakeholders. The HL7 Vocab-ulary Technical Committee provides a forum for suchdiscussions. The activities described in this article areaimed at realizing semantic interoperability in thecontext of the HL7 Message Development Frameworkso that information exchange and use among dispa-rate systems can occur for the delivery and manage-ment of direct clinical care as well as for purposessuch as clinical research, outcome research, and pop-ulation health management.

Portions of this manuscript were adapted from Chapter 7 of theHL7 Messsage Development Framework.16 The authors thankthe other members of the Vocabulary Technical Committee fortheir contributions to the thoughts and principles reflected inthis article. They also thank Robert McClure, MD, for his assis-tance in the development of the terminology survey.

References n

1. Campbell KE, Cohn SP, Chute CG, Shortliffe EH, RennelsG. Scalable methodologies for distributed development oflogic-based convergent medical terminology. Methods InfMed. 1998;37(4–5):426–39.

2. Chute CG, Cohn SP, Campbell JR. A framework for com-prehensive terminology systems in the United States: de-velopment guidelines, criteria for selection, and public pol-icy implications. ANSI Health Care Informatics StandardsBoard Vocabulary Working Group and the Computer-basedPatient Records Institute Working Group on Codes andStructures. J Am Med Inform Assoc. 1998;5(6):503–10.

3. Cimino JJ. The concepts of language and the language ofconcepts. Methods Inf Med. 1998;37(4–5):311.

4. Cimino JJ. Desiderata for controlled medical vocabularies inthe twenty-first century. Methods Inf Med. 1998;37(4–5):394–403.

5. Hammond WE. Call for a standard clinical vocabulary. J





Am Med Inform Assoc. 1997;4(3):254–5.6. Huff SM, Rocha RA, McDonald CJ, et al. Development of

the LOINC (Logical Observations Identifiers, Names, andCodes) Vocabulary. J Am Med Inform Assoc. 1998;5(3):276–92.

7. Rector AL, Bechhofer S, Goble CA, Horrocks I, Nowlan WA,Solomon WD. The GRAIL concept modelling language formedical terminology. Artif Intell Med. 1997;9:139–71.

8. Spackman KA, Campbell KE, Cote RA. SNOMED RT: a ref-erence terminology for health care. In: Masys D (ed). AMIAAnnu Fall Symp. 1997:640–4.

9. Campbell J, Carpenter P, Sneiderman C, Cohn S, Chute C,Warren J. Phase II evaluation of clinical coding schemes:completeness, taxonomy, mapping, definitions, and clarity.J Am Med Inform Assoc. 1997;4(3):238–51.

10. Chute CG, Cohn SP, Campbell KE, Oliver DE, Campbell JR.The content coverage of clinical classifications. J Am MedInform Assoc. 1996;3(3):224–33.

11. Henry SB, Warren J, Lange L, Button P. A review of themajor nursing vocabularies and the extent to which theymeet the characteristics required for implementation incomputer-based systems. J Am Med Inform Assoc. 1998;5(4):321–8.

12. Henry SB, Mead CN. Nursing classification systems: nec-essary but not sufficient for representing ‘‘what nurses do’’for inclusion in computer-based patient record systems. JAm Med Inform Assoc. 1997;4(3):222–32.

13. About HL7. Health Level 7 Web site. Available at: http://www.hl7.org. Accessed May 17, 2000.

14. Institute of Electrical and Electronics Engineers. IEEE Stan-dard Computer Dictionary: A Compilation of IEEE Stan-dard Computer Glossaries. New York: IEEE, 1990.

15. Rossi-Mori A, Consorti F, Galeazzi E. Standards to supportdevelopment of terminological systems for health caretelematics. Methods Inf Med. 1998;37(4–5):551–63.

16. Health Level 7. Message Development Framework. Ann Ar-bor, Mich: Health Level 7, 1999.

17. Lindberg DAB, Humphreys BL, McCray AT. The UnifiedMedical Language System. Methods Inf Med. 1993;32:282–91.

18. Rector AL, Glowinski AJ, Nowlan WA, Rossi-Mori A. Med-ical concept models and medical records: an approachbased on GALEN and PEN & PAD. J Am Med Inform As-soc. 1995;2(1):19–35.

19. American Dental Association. Code on Dental Proceduresand Nomenclature. Chicago, Ill: ADA, 1998.

20. American Dental Association. Systemized Nomenclature ofDentistry (SNODENT). Chicago, Ill: ADA, 1998.

21. American Medical Association. Physician’s Current Proce-dural Terminology. Chicago, Ill: AMA, 1993.

22. Alternate Billing Concepts. Version 983. Las Cruces, NM:Alternate Link LLC, 1998.

23. Centers for Disease Control. Centers for Disease ControlCommon Data Element Implementation Guide. Atlanta, Ga:CDC, 1998.

24. First DataBank National Drug Data File, Master Drug DataBase, International Drug Data File, PIF, DDID, Multilex,Drug Knowledge Base, FDBDX, Medical Conditions. SanBruno, Calif: First DataBank, 1998.

25. Health Care Financing Administration. Health Care Financ-

ing Administration Common Procedure Coding System(HCPCS): Level II Alpha-Numeric Codes. Baltimore, Md:HCFA, 1998.

26. Saba VK. The Classification of Home Health Nursing Di-agnoses and Interventions. Washington, DC: GeorgetownUniversity, 1990.

27. United States National Center for Health Statistics. Inter-national Classification of Diseases: 9th revision, ClinicalModification (ICD-9-CM) Washington, DC: NCHS, 1980.

28. Health Care Financing Administration. International Statis-tical Classification of Diseases and Related Health Problems(ICD-10) Procedure Coding Systems (PCS). Baltimore, Md:HCFA, 1998.

29. World Organization of Family Doctors (WONCA). Inter-national Classification of Primary Care. Amsterdam, TheNetherlands: WONCA, 1998.

30. World Organization of Family Doctors (WONCA). Inter-national Classification of Primary Care Drug Codes. Am-sterdam, The Netherlands: WONCA, 1998.

31. Medicomp Systems I: MEDCIN. Chantilly, Va: MedicompSystems, 1998.

32. Multum MediSource Lexicon. Denver, Colo: Multum Infor-mation Services, 1998.

33. O’Neil MJ, Payne C, Read JD. Read Codes, Version 3: a userled terminology. Methods Inf Med. 1995;34:187–92.

34. North American Nursing Diagnosis Association. Nursingdiagnoses: definitions and classification 1999–2000. Phila-delphia, Pa: NANDA, 1999.

35. Grobe SJ. The Nursing Intervention Lexicon and Taxonomy:Implications for representing nursing care data in auto-mated records. Holistic Nurs Pract. 1996;11(1):48–63.

36. McCloskey JC, Bulechek GM. Nursing Interventions Clas-sification (NIC). 2nd ed. St Louis, Mo: Mosby, 1996.

37. Johnson M, Maas M (eds). Nursing Outcomes Classification(NOC). St. Louis, Mo: Mosby, 1997.

38. Martin KS, Scheet NJ. The Omaha System: Applications forCommunity Health Nursing. Philadelphia, Pa: Saunders,1992.

39. Ozbolt J, Fruchtnicht JN, Hayden JR. Toward data standardsfor clinical nursing information. J Am Med Inform Assoc.1994;1:175–85.

40. Kleinbeck SVM. In search of perioperative nursing data el-ements. AORN J. 1996;63(5):926–31.

41. Russian Translation of MeSH. Moscow, Russia: State CentralScientific Medical Library, 1998.

42. Henry SB, Holzemer WL, Reilly CA, Campbell KE. Termsused by nurses to describe patient problems: can SNOMED

III represent nursing concepts in the patient record? J AmMed Inform Assoc. 1994;1:61–74.

43. Humphreys BL, McCray AT, Cheh ML. Evaluating the cov-erage of controlled health data terminologies: report on theresults of the NLM/AHCPR Large Scale Vocabulary Test. J AmMed Inform Assoc. 1997;4(6):484–500.

44. Board of Directors of the American Medical Informatics As-sociation. Standards for medical identifiers, codes, and mes-sages needed to create an efficient computer-stored medicalrecord. J Am Med Inform Assoc. 1994;1:1–7.

45. Rector AL. Thesauri and formal classifications: terminolo-gies for people and machines. Methods Inf Med. 1998;37(4–5):501–9.




doi: 10.1136/jamia.2000.0070333 2000 7: 333-342JAMIA

Suzanne Bakken, Keith E Campbell, James J Cimino, et al.

coded Data Elements−−Health Level 7Toward Vocabulary Domain Specifications for

http://jamia.bmj.com/content/7/4/333.full.htmlUpdated information and services can be found at:

These include:

References

http://jamia.bmj.com/content/7/4/333.full.html#related-urlsArticle cited in:

http://jamia.bmj.com/content/7/4/333.full.html#ref-list-1This article cites 22 articles, 12 of which can be accessed free at:

serviceEmail alerting

box at the top right corner of the online article.Receive free email alerts when new articles cite this article. Sign up in the

Notes

http://group.bmj.com/group/rights-licensing/permissionsTo request permissions go to:

http://journals.bmj.com/cgi/reprintformTo order reprints go to:

http://group.bmj.com/subscribe/To subscribe to BMJ go to:


http://jamia.bmj.com/content/7/4/333.full.html

http://jamia.bmj.com/content/7/4/333.full.html#ref-list-1

http://jamia.bmj.com/content/7/4/333.full.html#related-urls

http://group.bmj.com/group/rights-licensing/permissions

http://journals.bmj.com/cgi/reprintform

http://group.bmj.com/subscribe/



Toward Vocabulary Domain Specifications for Health Level 7--coded Data Elements

Documents