Interface Terminologies: Facilitating Direct Entry of Clinical Data into Electronic Health Record Systems

Abstract

Previous investigators have defined clinical interface terminology as a systematic collection of health care–related phrases (terms) that supports clinicians' entry of patient-related information into computer programs, such as clinical “note capture” and decision support tools. Interface terminologies also can facilitate display of computer-stored patient information to clinician-users. Interface terminologies “interface” between clinicians' own unfettered, colloquial conceptualizations of patient descriptors and the more structured, coded internal data elements used by specific health care application programs. The intended uses of a terminology determine its conceptual underpinnings, structure, and content. As a result, the desiderata for interface terminologies differ from desiderata for health care–related terminologies used for storage (e.g., SNOMED-CT^®), information retrieval (e.g., MeSH), and classification (e.g., ICD9-CM^®). Necessary but not sufficient attributes for an interface terminology include adequate synonym coverage, presence of relevant assertional knowledge, and a balance between pre- and post-coordination. To place interface terminologies in context, this article reviews historical goals and challenges of clinical terminology development in general and then focuses on the unique features of interface terminologies.

Recently, major stakeholders in U.S. health care, including the federal government, have emphasized the importance of establishing electronic health record systems for all health care sites.^1,2,3,4,5 Their stated goals for doing so include increasing patient safety, reducing medical errors, improving efficiency, and reducing costs. To accomplish these goals, electronic health record systems should capture structured clinical information (i.e., conforming to a standardized format, designed for a specific purpose) to support health services research and to enable decision support programs used at the point of clinical care.⁶ An obstacle to widespread adoption of electronic health record systems, however, is the difficulty associated with capturing structured clinical information from health care providers who prefer to document health care findings, processes, and outcomes using unfettered “free text” natural language.^7,8

The authors have reviewed existing definitions for clinical interface terminology variously posited by Chute et al.,⁹ McDonald et al.,¹⁰ Rose et al.,¹¹ and Campbell et al.¹² and developed a combined definition: a systematic collection of health care–related phrases (terms) that supports clinicians' entry of patient-related information into computer programs, such as clinical “note capture” and decision support tools. Interface terminologies also facilitate display of computer-stored patient information to clinician-users as simple human-readable text.^13,14 The “interface” of interface terminologies (which have also been called colloquial terminologies,^10,15 application terminologies,¹¹ and entry terminologies⁹) links health care providers' own free text patient descriptors to structured, coded internal data elements used by specific clinical computer programs. These terminologies generally embody a rich set of flexible, user-friendly phrases displayed in the graphical or text interfaces of specific computer programs. Clinical interface terminologies have been used for problem list entry,^{16,17,18,19,20} clinical documentation in electronic health record systems,^{9,21,22,23,24,25,26,27,28} text generation,¹⁴ care provider order entry with decision support,^{29,30,31,32,33,34,35} and diagnostic expert programs.^{36,37,38,39,40}

Electronic health record systems depend on interface terminologies for successful implementation in clinical settings²¹ because such terminologies provide the translation from clinicians' own natural language expressions into the more structured representations required by application programs. While interface terminologies play an important role in promoting direct entry of categorical data by health care providers, both terminology developers and the standards community historically have focused on other types of terminologies, including reference and administrative (rather than on interface) terminologies. Such terminologies are generally designed to provide exact and complete representations of a given domain's knowledge, including its entities and ideas and their interrelationships. For example, reference terminologies can support the storage, retrieval, and classification of clinical data; their contents correspond to the internal system representation storage formats to which interface terminologies are typically mapped. Other types of terminologies may complement or form the formal underpinnings of interface terminologies; however, they do not replace them.⁷

This review describes the unique features and goals of interface terminologies. First, the authors review historical objectives of the developers and evaluators of clinical terminologies in general (rather than for a type of terminology designed for a particular usage). The historical review focuses on approaches to standardizing terminology development, and the challenges involved creating terminologies that meet such standards. Within this context, the authors next outline the specific role of interface terminologies, including desiderata for interface terminology usability. Finally, the authors discuss potential future directions for interface terminology developers.

The authors recognize that the usability of a clinical documentation system depends on factors intrinsic to the underlying interface terminology and on extrinsic factors such as the display characteristics of related systems' software user interface. While studies are beginning to elucidate the user interface characteristics and terminological attributes that contribute to successful structured documentation,^24,41,42 more research is needed. The authors restrict the focus of this review to exploring advantageous terminological attributes.

Overview of Clinical Terminologies in General

Definition and Usage of Terminologies

Terminologies consist of collections of words or phrases, called terms, aggregated in a systematic fashion to represent the conceptual information that makes up a given knowledge domain, such as clinical cardiology or pediatric orthopedics.^43,44,45 Terms in a terminology generally correspond to actual events or entities and to their cognitive representations in people's minds (called concepts).⁴⁴ For example, the entries “myocardial infarction” or “heart attack” in a given terminology might represent the event “ischemic injury and necrosis of heart muscle cells resulting from absent or diminished blood flow in a coronary artery.” A health care provider evaluating a patient with prolonged chest pain may consider the diagnosis of ischemic heart muscle injury and could use the terms “myocardial infarction” or “heart attack” to think about and to communicate such a possibility. Terminologies also typically contain hierarchical organizations and other representations of linkages among concepts, such as the “is-a-type-of” relationship between “myocardial infarction” and “heart disease.”^15,46,47

While many terminologies have been developed, no single terminology has been accepted as a universal standard for the representation of clinical concepts. By contrast, individual terminologies or components have been identified by standards organizations as candidates for specific uses. For example, in 2003, the U.S. National Committee on Vital and Health Statistics and the U.S. government's multiagency consolidated health informatics council recommended a core set of terminologies as standards for representing aspects of patient medical record information, because the terminologies “(1) are required to adequately cover the domain of patient medical record information and (2) meet essential technical criteria to serve as reference terminologies.”⁴⁸ The recommended terminologies include the Systematized Nomenclature of Medicine Clinical Terms ([SNOMED CT^®] for the exchange, aggregation, and analysis of patient medical information), Logical Observation Identifiers Names and Codes ([LOINC] for the representation of individual laboratory tests) and several federal drug terminologies such as RxNorm and the National Drug File Reference Terminologies (for representing medications, their biological mechanisms of actions, and their physiologic effects). In addition, the U.S. National Library of Medicine has assembled the Unified Medical Language System (UMLS)⁴⁹ to bring together multiple terminologies through a thesaurus encompassing component vocabularies.⁵⁰ (Currently, the UMLS contains over one million biomedical concepts and five million synonyms from over 100 terminologies.⁵¹)

History of Clinical Terminologies

Work on clinical terminology systems began in the middle of the 17th century with John Gaunt's refinement of the late 16th-century classification scheme for the London Bills of Mortality.^52,53,54 Over the next two and one half centuries, many clinical terminologies were developed, with many subsequently lost to history.^52,53,54 Even though the International Classification of Diseases (ICD) was first adopted in Paris in 1900,⁵⁵ Chute⁵² states that the “modern era for clinical descriptions” began with the publication of the multiaxial Standardized Nomenclature of Diseases (SND) in 1928 and its subsequent revision to the Standardized Nomenclature of Diseases and Operations (SNDO) in 1933. With SND and SNDO, users could model complex concepts by constructing them from more primitive building blocks (such as composing “chest pain” from an anatomy axis concept for “chest” and a pathophysiology axis concept for “pain”). These terminologies, which were created and maintained on paper, were designed primarily for purposes of classifying diseases on the basis of etiology, clinical manifestations, and relationships between them.^52,55

The number and size of available clinical terminologies have expanded over time as the result of three phenomena. First, the information-intensive domains of clinical practice have expanded rapidly since 1960. In 1976, Pauker et al.,⁵⁶ based on an analysis of the Internist-I^® knowledge base³⁷ and other sources, estimated that the domain of general internal medicine alone contained over two million “facts.” Likewise, Durack⁵⁷ and Madlon-Kay⁵⁸ showed that the physical weight of Index Medicus, one indicator of the volume of medical knowledge, grew almost exponentially in the second half of the 20th century. Existing clinical terminologies grow to encompass progressive depth of knowledge in fields such as pathophysiology,⁵² pharmacogenomics,^59,60 and genetics.^61,62 Second, the availability of computer systems that are able to handle the complexities of knowledge representation,⁶³ storage,⁶⁴ retrieval,⁷ and maintenance have facilitated growth and evolution of clinical terminologies beyond what was possible with manual paper-based storage systems. Third, intended uses for clinical terminologies have expanded beyond diagnostic classification to include comprehensive representation of clinical domains, data storage, data mining, algorithmic discovery of relationships among concepts, systems messaging, decision support, and clinical documentation.⁶⁵ Representative terminologies such as ICD, 9th revision, Clinical Modifications (ICD-9-CM), SNOMED CT, LOINC, Medical Subheadings (MeSH), and MEDCIN have been operational in various revisions for decades.

Standardizing the Approach to Clinical Terminology Development and Evaluation

Given ongoing growth and expanded use of various clinical terminologies, calls for improved approaches to terminology development occurred in the late 1980s.^{43,66,67,68,69,70} Miller and Giuse, working with the Internist-1^® and QMR^® vocabularies, emphasized the need for real-world clinical applications employing a terminology to provide relevant feedback that drives terminology evolution; terminologies created in a vacuum by committees that infrequently reconvene may have limited longevity without feedback from actual use.^66,67,68 Rector et al.^69,70 indicated that terminologies should distinguish between terms and concepts when modeling a medical domain. Evans et al.,⁴³ reporting for the CANON group (an organization of “medical informatics researchers…developing a ‘deeper’ representation formalism for use in exchanging data”) stated that the medical community required a “common, uniform, and comprehensive approach to the representation of medical information.”

In response, researchers and the standards community proposed rigorous, focused development objectives for terminology construction in the early 1990s.^43,71,72 The International Standards Organization (ISO), for example, published the Technical Specification 1087,^73,74 which outlined attributes recognized as supporting high-quality practices regarding terminology development, including that terminologies be formal aggregations of language-independent concepts, that concepts should be represented by one favored term and appropriate synonymous terms, and that relationships among concepts should be explicitly represented. Other investigators, such as Campbell et al.,⁷⁵ formally evaluated several existing terminologies based on whether they supported various terminological attributes, including whether they could be mapped to other terminologies, permitted compositionality (complex concepts can be composed from simple concepts, also called post-coordination), and supported synonymy (multiple terms can represent single concepts), among other attributes. Based on this early research, terminology investigators subsequently outlined formal desiderata,⁷⁶ frameworks,⁷⁷ and additional ISO standards.¹⁵ They indicated that a single conceptual approach for development and evaluation of all terminology types and uses could provide a foundation for terminology construction using structured clinical data representations.

In his “Desiderata for Controlled Terminologies,”⁷⁶ Cimino summarized “years of work and conversations” with members of the UMLS project, the CANON group, and the InterMed Collaboratory (a consortium of five geographically distributed academic centers organized with the goal of sharing informatics-related applications, data, and resources⁷⁹) toward defining the necessary attributes of a successful “sharable, multipurpose” terminology. He emphasized the importance of concept orientation during terminology construction. Concept orientation involves using concepts as “basic building blocks” rather than words, terms, or phrases. Concept orientation allows a terminology to be useful in multiple situations, represented in different languages and easily reviewed for quality. Cimino's desiderata emphasized the importance of having a universal single clinical terminology that would cover a specialty domain's concepts completely at multiple levels of detail, while avoiding nonspecific phrases such as “not elsewhere classified” and “not otherwise specified.”

Chute et al.,⁷⁷ working with both the Vocabulary Working Group of the American National Standards Institute Healthcare Informatics Standard Board and the Codes and Structures Working Group of the Computer-based Patient Records Institute (CPRI), published “A Framework for Comprehensive Health Terminology Systems in the United States.” Like Cimino's desiderata, this framework described standard characteristics for health care terminologies representing clinical “history, findings, management, and outcomes…in a way that can preserve clinical detail and identify characteristics that make possible improved risk adjustment, common guideline development, aggregate outcomes analyses, and shared decision support rules.”⁷⁷ Chute et al. stressed the need for complete and comprehensive domain coverage using nonambiguous, nonoverlapping concepts. Chute et al. added that, in the absence of complete domain coverage, terminologies should integrate with other terminologies. They also pointed out that terminologies need to support synonymy and compositionality.

The ISO published terminology-related technical specifications in the mid-1990s^73,74 and in 2001¹⁵ with the goal of serving “as a guide…toward improved terminological development.” The ISO specifications emphasized that terminologies should have “complete coverage of a specified domain by formally defined concepts.” The ISO specification also stated that terminologies must define their purpose and scope, quantify the extent of their domain coverage, and provide mappings to external terminologies designed for classification and to support administrative functions. A statement of purpose, scope, and coverage allows terminology builders to work toward specific development targets and provides evaluators with benchmarks with which to judge the terminology. The ISO also stressed the importance of mapping among separate terminologies designed to meet different needs. Such mapping would allow, for example, a health care provider to select a concept from a clinically oriented terminology while constructing a patient's problem list and a mapped concept in an administrative classification (such as ICD-9-CM) could be selected in an automated fashion for billing purposes (e.g., upon entering into a problem list the clinical problem “coronary artery disease,” a computer program may select the mapped ICD-9-CM code “414.0 Coronary atherosclerosis”).

Clinical Terminology Domain Coverage

Taken together, Cimino's desiderata, the Chute et al. framework, and the ISO specifications complement each other to define a unified scope and set of objectives for terminology development. The overlap and differences among these three sets of desiderata are summarized in ▶. These reports advocate as a central goal that terminologies include terms for all concepts that occur within the clinical domain that they model, an attribute called domain coverage.

Table 1.

Some Desired Attributes for a Controlled Medical Terminology, as Represented in Cimino,⁷⁶ Chute et al.,⁷⁷ and the ISO's Technical Specifications for Terminologies^15,73,74

Terminology Attribute	Cimino76,78	Chute et al.77	ISO15,73,74
Statement of purpose, scope, and comprehensiveness			√
Complete coverage of domain-specific content	√	√	√
Use of concepts rather than terms, phrases, and words (concept orientation)	√		√
Concepts do not change with time, view, or use (concept consistency*)	√		√
Concepts must evolve with change in knowledge	√	√	√
Concepts identified through nonsense identifiers (context-free identifier)	√	√	√
Representation if concept context consistently from multiple hierarchies	√	√	√
Concepts have single explicit formal definitions	√	√	√
Support for multiple levels of concept detail	√	√	√
Methods, or absence of, to identify duplication, ambiguity, and synonymy	√	√	√
Synonyms uniquely identified and appropriately mapped to relevant concepts	√	√	√
Support for compositionality to create concepts at multiple levels of detail	√	√	√
Language independence		√
Integration with other terminologies		√	√
Mapping to administrative terminologies		√	√

^*Includes the concepts “multiple consistent views” and “concept permanence.”

Achieving Complete Domain Coverage

To achieve domain coverage, terminology developers historically have created new concepts using two methods: pre-coordination (also called enumeration) and post-coordination. With pre-coordination, developers model relevant levels of detail in the terminology with distinct concepts, typically derived from real-world, unconstrained usage by clinicians; “chest pain,” “substernal chest pain,” and “crushing substernal chest pain” each exist as individual concepts, with unique terms and synonyms, often tied by hierarchical linkages. Generally, only clinically meaningful concepts are pre-coordinated.⁸⁰ By contrast with (as defined above), post-coordination, complex concepts of differing levels of detail are composed from quasi-independent axes that contain more fundamental concepts (called “atomic” or “kernel” concepts). For example, with a post-coordinated terminology, a user can dynamically create the concept “chest pain” by combining the anatomic concept “chest” and the pathophysiologic concept “pain.” The user can introduce further detail by selecting new concepts from additional axes, such as “substernal” and “crushing nature.” Rassinoux et al.⁸¹ asserted that pre-coordination and post-coordination can complement each other, with pre-coordination providing logic and intricacy and post-coordination allowing expressivity and more complete domain coverage.

Evaluating Domain Coverage

Three comparative studies by Chute et al.,⁸² Campbell et al.,⁷⁵ and Humphreys et al.⁵⁰ of multiple clinical terminologies examined whether pre- or post-coordination was associated with better domain coverage. The 1996 study of Chute et al.⁸² evaluated the coverage by four terminologies and the aggregate UMLS of a random selection of 3,061 concepts extracted from clinical documents. They found that the only terminology that allowed post-coordination included in the study, SNOMED, most completely covered diagnoses, findings, and modifiers. The 1997 follow-up study by Campbell et al.⁷⁵ also found that SNOMED was the most complete, coding 69.7% of study concepts, followed by the Read codes, which allowed some post-coordination, at 57%. Campbell et al. attributed SNOMED's superior coverage to the fact that it allows post-coordination. The Humphreys et al.⁵⁰ study evaluated both the 1997 version of the aggregate UMLS and its component terminologies for their coverage of 32,679 unique normalized concepts. Their study found that, while the UMLS covered 58% of test concepts, the component terminologies that permitted post-coordination, SNOMED, and the Read codes had the greatest overall coverage (while the actual coverage statistics were not reported, both covered more than 60% of test concepts). Humphreys et al. also noted that had the investigators used “related concepts,” its coverage would have increased to 99%. They classified related concepts as less specific (e.g., “chest pain” instead of “substernal chest pain”) or more specific (e.g., “crushing substernal chest pain” instead of “substernal chest pain”). Despite its excellent overall coverage, however, Humphreys,⁸³ Chute et al.,⁸² and Campbell et al.⁴⁴ have all independently pointed out that the UMLS serves not as a distinct terminology, but as an aggregation of terminologies into a thesaurus.

The studies by Chute et al., Campbell et al., and Humphreys et al. all demonstrated that existing terminologies allowing post-coordination were better able to represent phrases and concepts extracted from clinical documents than existing pre-coordinated terminologies. Because users of such terminologies can both access existing concepts and dynamically compose new concepts as needed, such terminologies would be expected to have greater domain coverage than those that only allow users to access existing concepts. However, while post-coordination may enhance terminology domain coverage, terminologies allowing post-coordination have not yet successfully modeled the full scope of medical knowledge or been shown to be usable for all clinical terminology needs. In addition, the post-coordination has intrinsic limitations, described below.

Consequences of Post-coordination in a Clinical Terminology

As described below, investigators have demonstrated three limitations of post-coordination in clinical terminologies: (1) difficulty in restricting composition to medically meaningful concepts; (2) ability to create unrecognized duplicate concept representations; and (3) inefficiency with respect to composing complex concepts from simpler concepts.^42,43,80,84 Such limitations are not associated with a given usage or type of terminology, but rather with the process of composing complex concepts from multiple simpler concepts and modifiers. Some of these limitations are surmountable; numerous investigators developed methods that at least partially address them (including description logics and standard formalisms).

Clinically Nonsensical Concepts

Rector et al.⁸⁴ and Rassinoux et al.⁸⁰ have separately pointed out that post-coordination may be used to generate meaningless concepts by combining two or more meaningful concepts. For example, a user could combine the concepts “chest” and “pain” and then add the concepts “radiating to” and “ankle” to create the composite “chest pain radiating to the ankle,” which makes little sense clinically. Working together, Horrocks⁸⁵ and Rector et al.⁸⁴ proposed a solution in 1995 called sanctioning. Sanctioning allows developers to create rules for potential concept combinations requiring the composition to be medically sensible. Horrocks⁸⁵ added that sanctioning can be permissive (i.e., no compositions allowed unless permitted) or restrictive (i.e., all compositions allowed unless restricted). The Masarie et al.⁸⁶ 1991 frames-based interlingua illustrated an earlier approach⁸⁰ analogous to Horrocks' permissive sanctioning. In that 1991 model, concepts were generally pre-coordinated at the lowest level of detail that could provide diagnostic meaning to a health care provider (e.g., the concept “chest” per se does not provide diagnostic information to a health care provider, while the concept “chest pain” evokes to a health care provider a set of diagnoses, including pneumonia, myocardial infarction, pulmonary embolus, etc.). These concepts, called generic findings, could have related formal linkages to lists of permitted modifiers and associated concepts, called item lists and qualifiers. Users could post-coordinate generic findings into more specific concepts, called instantiated findings, only by using the constrained item lists and qualifiers. In all cases, rules for sanctioning must be added on a concept-by-concept basis, increasing the effort required for terminology development.

Concept Duplication

Concept duplication occurs when a single concept is represented more than one time in a terminology or when there are multiple independent ways to use the terminology to represent a concept. Concept duplication can reduce the accuracy of information retrieval if it goes unrecognized (for example, when duplicate concepts cannot be merged algorithmically to the same meaning). While duplication may occur in terminologies regardless of whether they permit post-coordination, post-coordination enables a greater opportunity for duplication to occur.⁸⁷ Duplication can be induced when single concepts can be composed using unanticipated combinations of relatively atomic concepts (e.g., the concept “acute appendicitis” can be composed both from “acute,” “inflammation,” “in,” and “appendix” and from “acute” and “appendicitis”). The CANON group pointed out that users of SNOMED International, a terminology that permits post-coordination, can model the concept for appendicitis through at least four paths (▶).⁴³ A researcher or computer program trying to identify cases of appendicitis from a SNOMED International–encoded data set would need to search for all possible ways that the concept could have been expressed. Although subsequent versions of SNOMED (e.g., SNOMED RT) have carefully addressed this problem with description logic and equivalency tables,^12,88 the potential for duplication has not been completely eliminated.

Table 2.

Duplication Due to Compositionality: Four Ways to Compose “Appendicitis” in SNOMED RT

D5-46210 01 Acute appendicitis, NOS	G-A231 0l Acute D5-46100 01 Appendicitis, NOS
M-41000 01 Acute inflammation, NOS G-CO06 01 In T-59200 01 Appendix, NOS	G-A231 01 Acute M-40000 01 Inflammation, NOS G-CO06 01 In T-59200 01 Appendix, NOS

From the CANON Group.⁴³

NOS =Not otherwise specified.

Inefficiency of Concept Composition

In a usability study, McKnight et al.⁴² explored the competing tensions between greater content coverage achieved by terminologies that allow post-coordination and the enhanced ease of use resulting from pre-coordination. In the McKnight et al. study, five physicians attempted to model four clinical case vignettes, each containing four to six concepts, by combining atomic concepts in a simple user interface. Even though the underlying terminology covered 85% of concepts relevant to the domain being tested, three of the five users commented that the process of post-coordination was “too cumbersome for complex problem entry”; most users commented that they would prefer selections to be restricted to the most relevant concepts.⁴² While potentially limited by not distinguishing between the effects of the computer program's user interface and those of the underlying terminology, by small sample size, and by using a terminology that was not designed for usage by physicians for structured documentation, the McKnight et al. study suggests that composing complex concepts from simpler concepts as part of standard documentation processes may be inefficient for the general practice of most health care providers. While it is possible that this finding would have been mitigated had the investigators used a terminology or a user interface specifically designed to support physician problem entry, the authors know of no studies that have evaluated the usability of post-coordination across multiple terminologies or across a representative variety of structured documentation tools.

Task-specific Clinical Terminologies: Balancing Rigor with Usability

Previous research demonstrates that inherent limitations of specific terminologies, such as inadequate domain coverage or the shortcomings associated with post-coordination outlined above, can reduce clinicians' ability to document or to view structured clinical data efficiently.^6,8 Developers who adhere to the rigorous terminology-related goals set out by Cimino, Chute et al., and Elkin et al. are not always guaranteed to create terminologies that are easily and directly usable by health care providers during routine clinical tasks.⁸ Rector⁷ has suggested that tension between clinical usability and meticulous knowledge representation may result from a fundamental conflict between the needs of humans and those of computer programs that use terminologies. According to Rector's view, human users require flexible, expressive terminologies that model common colloquial phrases, while computer programs are generally designed to process formally defined concepts having rigidly defined interrelationships. This echoes the statement by Rassinoux and colleagues that pre-coordination and post-coordination may serve complementary roles.⁸¹

Recognizing the need to balance terminology domain coverage with clinical usability, Spackman et al.,^89,90,91 Rector,⁶⁵ and Chute et al.⁹ have all suggested that terminology developers limit their scope from creating a single monolithic terminology that meets all users' needs to building terminologies designed for specific usage categories. Common categories of usage include classifying clinical data for administrative purposes such as billing, representing knowledge for research and data interchange, and supporting efficient documentation of clinical findings into medical problem lists.

Spackman et al.⁸⁹ in 1997 described a three-part categorization schema for terminologies, based on their intended uses (▶). First, terminologies may support data entry in a user interface designed for clinical documentation (consistent with the current authors' definition of interface terminology). Second, terminologies may serve as the substrate for computer programs that parse textual documents and reports in an attempt to “recognize” distinct clinical concepts. Third, terminologies may represent clinical concepts and their interrelationships for computer storage, retrieval, manipulation, and analysis. While Spackman et al. articulated that reference terminologies meet this latter need, they did not fully define the functions of interface and parsing terminologies and excluded terminologies designed for classification tasks (such as ICD-9-CM).

Table 4.

Relative Importance of Terminology Attributes to an Interface Terminology and to a Clinical Terminology in General

Terminology Attribute	Clinical Terminology	Interface Terminology
Statement of purpose, scope, and comprehensiveness	√	√
Complete coverage of domain-specific content	√	√
Use of concepts rather than terms, phrase, and words (concept orientation)	√
Concepts do not change with time, view, or use (concept consistency*)	√	√
Concepts must evolve with change in knowledge	√	√
Concepts identified through nonsense identifiers (context-free identifier)	√	√
Representation of concept context consistently from multiple hierarchies	√
Concepts have single, explicit formal definitions	√	√
Support for multiple levels of concept detail	√	√
Methods, or absence of, to identify duplication, ambiguity, and synonymy	√
Synonyms uniquely identified and appropriately mapped to relevant concepts	√	√
Support for compositionality to create concepts at multiple levels of detail	√	√
Language independence	√
Integration with other terminologies	√
Mapping to administrative terminologies	√
Complete coverage by domain-specific terms and synonyms		√
Presence of assertional knowledge		√
Presence of optimal compositional balance		√

^*Includes the concepts “multiple consistent views” and “concept permanence.”

Table 3.

The Three Terminology Classes⁸⁹ by Spackman et al.⁸⁹

Terminology Class	Intended Usage Task
Interface	Support a user-friendly structured data entry interface
Processing	Optimize natural language processing
Reference	Enable storage, retrieval, and analysis of clinical data

Characterizing terminologies as “software meant to support interactions between humans and computers,” Rector⁶⁵ in 1998 identified six possible tasks for terminologies: (1) support efficient data entry and query formulation; (2) record and archive clinical information; (3) support sharing and reuse of clinical information; (4) infer and suggest knowledge according to decision support algorithms; (5) support terminology maintenance; and (6) to create a natural language output from manual structured input. In Rector's model, some terminology tasks optimize data entry (i.e., task 1), others support storage, processing, and usage of clinical data by computerized tools (tasks 2, 3, 4), while others enable computer systems to create human readable documents that represent the data. Rector added that, to enhance usability, terminologies designed to support efficient data entry should constrain how concepts can be put together, evoking Horrocks'⁸⁵ sanctioning.

Chute et al.⁹ in 1999 expanded on the Spackman et al. categorization schema. They used the phrase “entry terminology” to refer to the uses that Spackman et al. described for interface and parsing terminologies. Chute et al. also provided a category for classification terminologies, here called aggregate and administrative terminology. In the Chute et al. model, three categories of terminologies work together, each taking on complementary roles. The “entry” terminologies of Chute et al. allow users to interact easily with concepts through common colloquial terms and synonyms. Entry terms can then map to explicitly defined concepts in a more formal terminology, such as a reference terminology, which can then define relationships among concepts. Concept relationships in reference terminologies are typically defined formal definitional logic (i.e., description logics are explicit formal definitions of the relationships among concepts; in SNOMED CT, the concept “chest pain” includes the description logic encoded relationships is-a “pain of truncal structure” and has-finding-site “thoracic structure”¹²). Concepts in reference terminologies may also be mapped to additional terminologies, such as those designed to support tasks such as billing and disease reporting.

Interface Terminologies: Clinical Terminologies Designed to Support Human–Terminology Interaction

Spackman's term interface terminology, which is elsewhere called colloquial terminology^10,15 and application terminology,¹¹ has come to be used for Chute's “entry terminology.”⁹ Campbell et al.¹² in 1994 described interface terminologies as those designed to support efficient structured clinical documentation into electronic health record system interfaces and computerized note capture tools, primarily by modeling the clinical concepts commonly used by health care providers. They stated that interface terminologies may also help users view categorical data by providing common colloquial terms as synonyms and enabling natural language text generation.

While a single conceptual framework for terminologies can help developers and evaluators work toward a common model, such a framework may not be suitable for all terminology types. The terminological attributes outlined by Cimino, Chute et al., and the ISO for reference terminologies may be insufficient for clinical interface terminologies, which serve different purposes. Terminologies designed to support structured clinical documentation may require extensions that improve expressivity and usability by, for example, increasing the breadth of synonym coverage to improve the user's ability to select structured concepts that capture the nuances of clinical narratives.^6,41 The “usability” of an interface terminology refers to the ease (e.g., speed, level of comfort, accuracy) with which its users can accomplish their intended tasks (e.g., documentation of patient care) using the terminology. In addition, Campbell²¹ and Kahn et al.²³ have demonstrated that interface terminology usability correlates with the presence of attributes that enhance efficiency of term selection and composition. The authors speculate that the usability of a clinical interface terminology designed for capturing structured documentation correlates with (1) presence of relevant assertional medical knowledge, as defined below; (2) adequacy of synonymy; (3) a balance between pre-coordination and post-coordination; and (4) mapping to terminologies having formal concept representations.

Assertional Knowledge in an Interface Terminology

Interface terminologies generally incorporate assertional knowledge. Assertional knowledge is information that provides nuance and context to a concept, but does not define it.^70,76,92 For example, “thorax pain” and “chest pain” may have the same formal definition (both concepts could reasonably have the formal definition is-a “pain” and has-finding-site “thoracic structure”); however, the former may imply more strongly to a health care provider that the location of the pain is in the chest wall per se, while “chest pain” tends to suggest a possible cardiac or pulmonary cause. Assertional knowledge may define attributes distinguishing “thorax pain” from “chest pain” by including relevant synonyms, associated diagnoses, common symptoms, usual modifiers, and describing prevalence in a given patient population. Assertional knowledge in an interface terminology can be made up of lists of associated concepts, synonyms, and common modifiers and may be more relevant to clinical users than definitional knowledge. For example, the assertional knowledge related to “chest pain” may include links to a normal status⁸⁶ (e.g., “chest pain” is normally absent in a healthy population, even though it may be usually present in a patient with angina), to a list of severity modifiers (e.g., “mild,” “moderate,” and “severe”), and to lists of common associated diagnostic concepts (e.g., myocardial infarction, pneumonia, esophagitis, botulism). The representation of the concept “chest pain” in a terminology system may also include assertional knowledge that links it to common associated symptoms based on etiology, such as fever, cough, and sputum production for various types of bronchitis and pneumonia.

Rassinoux et al.,⁸⁰ Horrocks,⁸⁵ Rector et al.,⁸⁴ and Masarie et al.⁸⁶ claimed that assertional knowledge–based links and supplemental information embedded in an interface terminology enhance its usability by decreasing the number of steps required for users to find or compose the terms needed for a given task. For example, to model a complex concept like “chest pain” in a reference terminology that requires post-coordination, a user would compose the term from distinct concepts for “chest” and “pain” using description logic relationships (i.e., “chest pain” is-a “pain,” has-finding-site “chest”). In this model, the user would have to take additional steps to add more concepts or modifiers (e.g., “mild”) and their description logic encoded relationships (e.g., has-severity). By contrast, an interface terminology modeling the concept chest pain would likely include a pre-coordinated concept “chest pain” with linked lists of allowable qualifiers, including severities (e.g., “mild,” “moderate,” “severe”).⁸⁶ A user selecting “chest pain” in an interface terminology could then select the relevant modifiers without being required to search the entire terminology. This distinction is illustrated in ▶.

Figure 1.

Two approaches to composing the concept “severe chest pain.” (Top) A user selects concepts and modifiers directly from a reference terminology permitting post-coordination, using description logic to combine unrelated atomic concepts sequentially, starting with “pain,” then adding the location modifier “chest” and the severity modifier “severe.” (Bottom) The user can combine the pre-coordinated concept “chest pain” in an interface terminology with the formally linked modifier “severe” from the list of chest pain modifiers. All concepts and modifiers in the interface terminology are mapped to formal representations in an external reference terminology. Both approaches allow the user to compose a meaningful concept having a formal representation.

Associating concepts with common relevant modifiers allows users to modify them without performing separate searches for additional terms. For example, in the Masarie et al.⁸⁶ frame-based interlingua system, the generic definition of “chest pain” included slots for common modifier lists (called item lists above), such as severity of pain (i.e., “mild,” “moderate,” and “severe”) and nature of pain (i.e., “crushing,” “burning,” “knife-like,” “tearing,” etc.). Interface terminologies can associate concepts with their assertional knowledge by using links to what the National Library of Medicine (describing MeSH) and Wang have each called “allowable qualifiers.”^93,94,95 Allowable qualifiers explicitly define the relationships between concepts and their relevant modifiers and corollary concepts. Allowable qualifiers can be created using Horrocks'⁸⁵ sanctioning rules or item lists of Rassinoux et al.⁸⁰ and Masserie et al.,⁸⁶ among other techniques.

When included in the design of an interface terminology, assertional knowledge must be added concept by concept. For example, a developer creating the interface term “chest pain” would need to identify all relevant clinical concepts and modifiers, such as lists of topographical locations across the chest, severities, common chest pain characters, and associated concepts including nausea, cough, and dyspnea. In addition, the terminology developer may need to determine whether chest pain is normally absent or present in a healthy population. Once such assertional knowledge is defined, the developer would need to model it in the terminology by selecting or creating the appropriate concepts, modifiers, and linkages. A similar exercise would need to be performed for every concept. While the authors believe that including assertional knowledge will enhance interface terminology efficiency, this has not been formally quantified in empiric studies. It is equally likely that including assertional knowledge will increase the complexity of creating and maintaining such terminologies and that doing so may not be feasible in every implementation.

Synonymy in an Interface Terminology

Synonymy refers to the number of individual terms that can correctly represent a unique concept. Synonym types may include alternate phrases (e.g., “dyspnea” and “shortness of breath”), acronyms (e.g., SOB for “shortness of breath”), definitional phrases (e.g., “a sensation of not getting enough air during breathing”), and eponyms.⁸⁷ Rosenbloom et al.⁹⁶ demonstrated that inadequate synonymy reduced clinicians' ability to use a terminology for classifying medications' physiologic effects. Cantor and Lussier⁹⁷ have suggested that explicitly defined homonyms, polysyms (i.e., a single term that has many meanings such as “cold,” which may refer to a perceived temperature or to a disease syndrome), antonyms, and acronyms may be as important in interface terminologies as synonyms. Clinical interface terminologies are specifically designed to represent the variety of common colloquial phrases in medical discourse; rich synonymy should improve the nuance with which users can express themselves when using the terminology. While rich synonymy may increase usability, Fung et al.⁸⁷ recently demonstrated that synonyms can increase a terminology's ambiguity by either duplicating single concepts or merging multiple concepts. The increased ambiguity introduced by synonymy may be partially solvable by making the context more explicit and by permitting users to see other synonyms and definitions.

Synonym coverage can be evaluated using the metrics of expressivity and accuracy. The authors define expressivity as how well a term's linguistic components match the words in the phrase it is meant to model (i.e., whether all parts of a target phrase can be represented using the terminology). Accuracy is defined as how well a term's clinical meaning represents the meaning of the phrase it is meant to model (i.e., how well the meaning of the “best match” in the terminology corresponds to the meaning of the target phrase). The significance of expressivity and accuracy is best illustrated through an example. It is possible that a clinician might want to use a terminology to describe the presence of a patient's “feathery discomfort occurring across the chest.” A terminology may include the concept “chest discomfort” and the modifiers “noncrushing” and “anterior chest wall,” but not the modifier “feathery.” While “noncrushing” and “feathery” may be considered synonyms when describing chest discomfort, they use different words and most likely evoke different nuances to a clinician or a patient. In this case, the composition “noncrushing chest discomfort” used to describe “feathery chest discomfort” may be accurate (i.e., the two phrases have the same meaning in the sense that both would be true when applied to the patient), but it is not fully expressive (i.e., the two phrases have different linguistic character).

Balancing Pre-coordination and Post-coordination in an Interface Terminology

Interface terminologies may include pre-coordinated concepts that can be further post-coordinated as necessary. Rector⁶⁵ noted that interface terminologies should restrict post-coordination to creating medically meaningful concepts, and Rassinoux et al.⁸¹ have proposed that pre-coordination and post-coordination be limited to “relevant and important concepts in medicine” both to reduce the inefficiencies of post-coordination and the size of a pre-coordinated terminology. Rassinoux et al.⁸¹ articulated that limiting pre-coordinated terms to those that actually are clinically meaningful are best for the interface vocabulary, but that there should be an “overlay” of a post-coordinated deeper representation that facilitates computer processing and understanding of the pre-coordinated terms. In this way, interface terminologies can balance the benefits of pre-coordination (i.e., minimizing nonsensical compositions, reducing effort required to select an appropriate concept representation for a clinical notion) and post-coordination (i.e., allowing increased content coverage and flexibility).²¹

The authors define compositional balance as the balance between pre-coordination and post-coordination in a terminology. Compositional balance by design facilitates concept selection by minimizing the effort required for users to compose complex concepts from more atomic concepts and to search through long lists of fully defined pre-coordinated concepts. Campbell²¹ has described terminological degrees of freedom as a numerical assessment of the complexity of a colloquial phrase; this measure is calculated by adding together the number of atomic concepts present in a canonical coding of a pre-coordinated concept. Degrees of freedom can provide a quantitative representation of compositional balance. For example “severe chest pain” in MEDCIN can be mapped to (and said to include) the three atomic concepts and modifiers “severe,” “chest,” and “pain” from SNOMED CT. Exposing degrees of freedom in complex concepts can reveal both the proportion of concepts in a terminology that requires a compositional expression and the average number of atomic concepts required to compose interface terms. The authors speculate that there exists a level of compositional balance that maximizes usability and that this level may vary by the interface terminology's intended use and clinical domain.

Mapping Interface Terminologies

Interface terminologies are generally designed to enable human interaction with structured concepts rather than to provide formally defined models of the concepts. Once medical information is captured using an interface terminology, it can be mapped to terminologies having more formal representations. Spackman et al.,⁸⁹ Campbell et al.,¹² and Chute et al.⁹ demonstrated that interface terminologies can be mapped to reference terminologies for subsequent storage, management, and analysis of clinical data. Chute et al. and Campbell et al. noted that concepts in an interface terminology do not require formal definitions of their interrelationships (e.g., the subset-superset relationship, “severe chest pain” is-a “chest pain”) when such information can be implied or referenced from mapped reference terminologies. Elkin et al.,⁹⁸ expanding on a demonstration by Masarie et al.⁸⁶ during early work on the UMLS, have suggested that exposing the implied semantics common to pre-coordinated concepts can assist with concept mapping and improve mapping accuracy. For ambiguous concepts, however, defining the relationships based on mappings (rather than the other way around) may lead to inaccuracies. For example, the interface term “chest pain” may imply a cardiac symptom based on its association with other concepts; mapping it in a reference terminology to the concepts and relationships, “chest pain” is-a “pain,” has-finding-site “chest” may lose this nuance. Because interface terminologies commonly contain pre-coordinated concepts, defining the semantic and assertional knowledge directly may also improve mapping to reference terminologies.

Recommendations for Developing Interface Terminologies

It is likely that creating usable interface terminologies will not require de novo terminology development. One approach to developing interface terminologies would be to construct them from existing terminologies, such as reference terminologies. Doing so would involve creating clinically meaningful compositions, appropriate synonyms, and linkages between concepts and related concepts or modifiers. Constructing interface terminologies in this way would permit the underlying formal structure provided by the source reference terminology to remain, while simultaneously presenting clinicians with usable complex terms. It is likely that clinical users will require different levels of detail and coverage of varying domains based on their usage needs. From this standpoint, a single standard reference terminology (e.g., SNOMED CT) used as the starting point for interface terminology development will permit a uniform back-end representation despite the diverse terms that users require.

Interface terminologies are often designed for display in the user interface of structured clinical documentation or electronic health record systems. It is likely that terminological attributes, such as those outlined above, have an impact on terminology usability regardless of the system in which they are used. Likewise, particular user interfaces may have their own characteristics that affect usability. To date, there have been only a few investigations quantifying the interactions between interface terminologies and the user interfaces that use them. Usability studies by Poon et al.,²⁴ McKnight et al.,⁴² and Cimino et al.⁴¹ have begun to tease interface terminology attributes apart from user interface attributes. These studies are limited in that each evaluated only a single terminology implemented in a single user interface. To quantify and distinguish effects of terminology attributes and user interface attributes on usability, the authors believe that it will be necessary to measure similar usability outcomes across multiple terminologies and user interfaces, each having different characteristics. Investigators should work to distinguish terminological and user interface characteristics when evaluating interface terminologies.

Developers and investigators should consider the proposed desiderata when evaluating interface terminologies. Specifically, interface terminologies should be studied in terms of how well they cover the domain they model, whether they include relevant assertional medical knowledge–based links to improve efficiency in the human-terminology interface, whether they contain adequate terms and synonyms to permit accurate and expressive coding, whether they address the right balance between pre-coordination and post-coordination, and whether they are mapped to terminologies having formal concept representations. Additional research correlating each of these attributes with usability for clinical documentation and formal knowledge representation is necessary.

Conclusions

Historically, developers have created various types of clinical terminologies to meet specific needs. As a result, the terminologies' attributes, structures, and goals differed. One specific genre of clinical terminology, interface terminologies, by design facilitates clinician users interacting with the more cumbersome internal categorical data representations used in application programs. Interface terminologies should be developed and evaluated (using objective and reproducible metrics) according to their purpose, for example, how well an interface terminology supports efficient data entry for a structured documentation tool. Improving and evolving interface terminologies require evaluation metrics such as adequacy of attributes, degree of synonym coverage, quantity and quality of relevant assertional knowledge, and degree of compositional balance. The authors believe that to improve and guide the evolution of interface terminologies, feedback based on formally defined evaluation metrics is necessary.