Characteristics of a Good Nursing Nomenclature From an Informatics Perspective

The reasons for developing a vocabulary or nomenclature usually dictate its characteristics (Ingernerf, 1995). For example, if a nomenclature is developed primarily for classifying nursing intensity, its terms will describe patient characteristics that impact resources needed for care. If a nomenclature is developed primarily for billing, then its terms will describe actions or procedures that can be billed to a third party. In nursing, as in most other health disciplines, there are no nomenclatures that have been developed primarily for use in automated clinical information systems. Therefore, designers of information systems that rely on capturing and using structured clinical information have had to make do with nomenclatures that were designed for other purposes. A great deal of work has been done in the past few years to examine existing nomenclatures for their suitability for automated clinical systems, and most have been found significantly lacking (Campbell, 1997; Henry, 1998). In this paper, we will examine how data are used in automated clinical systems, and review the resulting requirements of a "good" nomenclature from the perspective of a system designer.

It is important to state at the outset that a great deal of excellent work has been done with respect to nursing nomenclatures in the past few decades. Among the earliest is the work done at the Omaha Visiting Nurses Association to classify the problems that nurses define in the home health setting, along with the expected outcomes, the interventions that nurses use, and the actual patient outcomes. This set of terms and the recommended methods of using them is known as the Omaha System (Martin & Scheet, 1992). Among the best known nomenclatures is the North American Nursing Diagnosis Association (NANDA) Approved List of diagnostic labels (North American Nursing Diagnosis Association, 1994). More recent work includes the Nursing Interventions Classification (NIC), developed at the University of Iowa (McCloskey & Bulechek, 1996), the Home Health Care Classification (HHCC) developed at Georgetown University (Saba, 1992) (see note), and the Nursing Outcomes Classification (NOC), also developed at the University of Iowa (Johnson & Maas, 1997). At the University of Virginia, Ozbolt and colleagues culled hundreds of terms from patient records to develop the Patient Care Data Set (PCDS) (Ozbolt, Fruchtnicht & Hayden, 1994; Ozbolt, 1996), which codifies patient problems and actions delivered by all caregivers during a patient's hospital stay.

All of the aforementioned nomenclatures have been recognized by the American Nurses Association as nomenclatures that should be included in a Unified Nursing Language System (Lang, 1995). All have been or are in the process of being added to the Unified Medical Language System developed and supported by the National Library of Medicine (Lindberg, Humphreys & McCray, 1993).

Today's health care environment demands that automated patient record systems deliver the following functions:

1. Provide the legal record of care
2. Support clinical decision making
3. Capture costs for billing, costing and/or accounting purposes
4. Accumulate a structured, retrievable data base for
   a. administrative queries
   b. quality assurance
   c. research
5. Support data exchange with internal and external systems

All of these functions depend on data. Each function places requirements on the nomenclature that is used to capture and store that data. As we will see, sometimes these requirements conflict with one another, which further confounds the effort to develop a single, comprehensive nomenclature for use in automated systems. Each function will be discussed in turn.

1. Provide the Legal Record of Care

In order to provide the legal record of care, the system must capture the clinician's expression of patient assessment, diagnosis, goals, the plan of care, the care actually delivered, the patient's responses to care, and the actual patient outcomes. A nomenclature that captures all of the enormous richness of this data set across the spectrum of patient care settings must have what is known as domain completeness. Existing nursing nomenclatures cover various aspects of the nursing process in varying depths in one setting or another, but none can claim domain completeness.

Even if a nomenclature claimed to have terms that describe all of the aspects of care in all settings, it must still support the human tendency to local variation. So the nomenclature must support synonymy, the ability to express the same concept in different ways depending on local preference. At this time, none of our nomenclatures supports synonymy. In addition to representing the entire domain, the terms in the nomenclature must be able to describe care at the clinical level, not at an administrative or epidemiological level; therefore the nomenclature's terms must have sufficient granularity to describe, for example, not only that a wound exists, but what the precise characteristics of the wound are, including size, location, nature and amount of drainage, etc.

Because our patients are complex beings, the description of their conditions is also complex, thus the need for the ability to qualify the description of their conditions with modifiers such "mild," "moderate," and "severe." Because nursing is not a hard science, it must be possible to represent the degree of certainty of a finding (such as "possible xxx" or "probable yyy") and it must also be possible to record a negative finding (such as "no evidence of'¦" or "patient denies'¦"). Some of our nomenclatures do have modifiers that can be attached to terms. For example, modifiers such as "potential," "actual," "family," and "individual" can be attached to problem terms in the Omaha System, and NANDA terms can be qualified with such descriptors as "acute," "chronic," "impaired," and so on.

Because human beings operate on their own perceptions of the world, the same term will have different meanings to different people, thus the need for a definition of each term in the nomenclature to insure non-ambiguity. Most of our nomenclatures do contain definitions of their terms, which assists with both understanding the meaning of a particular term, and also helps to assure consistency in use of the term. In fact, definitions for terms is one of the requirements for recognition of a nomenclature by the American Nurses Association, as is demonstrated clinical utility (McCormick, Lang, Zielstorff, Milholland, et al, 1994).

There are other types of attributes that contribute to the description of conditions, actions and patient states that, when combined with core concepts, result in complex phrases such as "Stage 2 pressure ulcer at the right lateral malleolus." A nomenclature that had such a phrase in it would have to have many variants including whether it was stage 1, 2, 3 or 4, the anatomic location, whether it was right or left, lateral or medial, etc. In our example, the entire phrase has been "pre-combined" to include all of the qualifiers. But experience with systems that use pre-combined phrases has shown that as new knowledge and new circumstances arise, the need for new phrases mushrooms; the vocabulary quickly becomes unwieldy, and lacks parsimony.

From an informatics perspective, it would be better if the nomenclature were more "atomic," with all qualifiers supplied from separate "axes" such as laterality (right, left, medial, lateral, etc.), anatomic location, stage or degree, and so on. Such a nomenclature would then be multi-axial and combinatorial, providing not only maximum parsimony, but maximum flexibility and extensibility. A few of our nomenclatures are somewhat combinatorial. The Omaha System, for example, allows combination of problem labels with modifiers, and allows action terms to be combined with "targets" to describe planned actions, but it is not accurate to say at this point that any of them is multi-axial.

When nomenclatures are combinatorial, it is helpful to supply rules for how the different axes can be combined, so that nonsensical phrases such as "left social isolation" do not occur. For example, the Omaha System states that its coded signs and symptoms should not be used when the prefix "Potential" is attached to a problem term. By definition, a problem that is "potential" does not have signs or symptoms. Rules such as this make up the syntax and grammar of a nomenclature.

While a nomenclature that is multi-axial and combinatorial and highly granular is desirable for many reasons, it can also be difficult to use by the clinician. Imagine having to make four clicks to select from four different lists of terms the words that make up the phrase as "Stage 2 pressure ulcer at the right lateral malleolus." One thing that clinicians abhor is an automated system that takes more time to use than the manual system they are used to. The technical challenge in developing a system that is both acceptable to clinicians and also captures data at a granular level in a form that can be manipulated by the computer for several different purposes is enormous. In fact, what we mostly see is compromise: we may ask the clinician to select a core concept from a list of terms (like "Stage 2 Pressure Ulcer") and allow the rest of the detail to be described in narrative text. Of course, it is then not possible to advise the nurse to consider infection when the drainage is described as odorous and purulent if that information is recorded in narrative text rather than in coded terms.

To summarize, a nomenclature that is useful for recording clinical care must have domain completeness, it must support synonymy, it must have sufficient granularity, it must be parsimonious, its terms must be able to be qualified with modifiers (including certainty and negation), and its terms must be non-ambiguous. At the same time, it must be easy to use in the clinical setting.

2. Support Clinical Decision Making

The ability of an automated system to support clinical decision making depends largely on how well the data available to it are structured. The nomenclature used to record information is one aspect of that structure. Consider, for example, the desire to have the system advise the nurse when a particular patient is at high risk for falling, or to propose appropriate measures to prevent pressure ulcers, or to recommend the most cost-effective wound treatment given a description of the wound. None of this can be done without assessment data that are recorded using a nomenclature that is quite granular. Furthermore, the data must be coded in such a way that they are easily retrievable and able to be manipulated by the computer. This requires that each term in the nomenclature have a unique identifier that can be used for coding.

Experience with the maintenance of large nomenclatures has shown that the unique identifiers must be context-free, that is, the code should not indicate that the term belongs in one section of the taxonomy or another. This is because knowledge evolves, and using context-dependent codes creates serious problems when a code has to be moved to a different section of the taxonomy, or when the same term can logically belong in more than one section of a taxonomy (that is, when it can have multiple parents). It's extremely difficult to design decision support systems when the data required for a decision can exist under multiple codes. Of course, the quality of the data used for decision support is paramount, so the attributes of clarity and non-redundancy in the nomenclature will be key, along with the need to have clear definitions of each term so that clinicians use the terms accurately and consistently.

3. Billing/Costing/Accounting

It has long been advocated that atomic-level data captured in the course of clinical care should be able to be used for multiple purposes, including billing, costing, and/or accounting (Dick & Steen, 1991; Zielstorff, Hudgings & Grobe, 1993). In order to accomplish this, it must be possible to map the terms used in the clinical nomenclature to other nomenclatures that are used for billing, such as Current Procedural Terminology (CPT) (American Medical Association, 1993), or HCFA Common Procedure Coding System (HCPCS). Medical diagnoses may also be required for billing purposes, so terms for recording diagnoses must be able to be mapped to such nomenclatures as International Classification of Diseases '” Clinical Modification (ICD9-CM) (National Center for Health Statistics, 1980).

4. Accumulate a Structured Data Base for Administrative Queries, Quality Assurance and Research

As with decision support, an automated system that provides the capability to store and retrieve data from a structured data base is highly dependent on the nature of the nomenclature used to capture the data. The same characteristics apply: The terms must have unique identifiers to allow coding; data quality must be supported through the attributes of clarity and non-redundancy in terms, and definitions of terms should be available to support accurate, consistent use. Since the purposes of these databases are wide-ranging, domain completeness as well as granularity are key requirements. The research system may require atomic-level data for certain purposes, while the administrative system may require that atomic-level data be rolled up into broader categories. When the nomenclatures is designed to be hierarchical, it is much easier to roll up the more granular data into groupings that make sense at the broader level. The ability to map the clinical terms to other standard classifications may be required as well.

5. Exchange Data with Internal and External Systems

Health care agencies seldom have the luxury of a single, monolithic automated system. It is far more common that an agency will have multiple computers using different software platforms to accommodate their information processing requirements for clinical systems, administrative systems, financial systems, research systems, etc. When clinical data are needed by other systems, it must be possible to supply that data without re-entering it. Standards for packaging data and transporting them to "foreign" systems are evolving; to the extent that a nomenclature is structured to conform to those standards, then exchanging data will be made easier (Board of Directors of the American Medical Informatics Association, 1994).

A major effort is underway to develop a clinical nursing classification scheme expressly for use in automated systems. The International Council of Nurses sponsors development of the International Classification of Nursing Practice (ICNP) (International Council of Nurses, 1996; Neilson & Mortensen, 1996). Still in its early phases, the nomenclature is intended to provide a common language for describing all of nursing practice across all settings and geographic locations. It includes a framework for mapping to existing nomenclatures and classifications. The developers encourage feedback and suggestions for additions and changes funneled through the American Nurses Association (Warren & Coenen, 1998).

The characteristics of a "good" nursing nomenclature from an informatics perspective are summarized in Table 1. Most of them have been listed by others as required attributes in any classification scheme that will be implemented in a computer-based patient record (Campbell, Carpenter, Sneiderman, Cohn et al, 1997; Henry, Warren, Lang & Button, 1998). Much of that work has foundations in the work of the Canon group, a gathering of researchers whose aim was to synthesize existing efforts at medical concept representation (Evans & Cimino, 1994).

The topic has taken on more urgency in the past few years because of frustration with the slow pace of implementation of automated systems to support clinical care (United States General Accounting Office, 1993), and because of federal initiatives such as the Health Insurance Portability and Accountability Act of 1996 (HIPAA) that will require standards for coding and transmitting claims and other medical record data. The work of the nomenclature developers who are cited here, as well as the work of informaticians who examine, compare and evaluate existing nomenclatures for applicability in automated systems, is absolutely fundamental to achieving automated clinical systems that support both efficiency and effectiveness of care.

Note: The name of the Home Health Care Classification (HHCC) System was changed to the Clinical Care Classification (CCC) System in 2003.

Author

Rita D. Zielstorff, RN, MS, FAAN
rzielstorff@partners.org

Rita D. Zielstorff, RN, MS, FAAN is Corporate Manager, Clinical Information Systems Research and Development, Partners HealthCare System. She also holds the appointment of Computer Scientist in the Department of Medicine at Massachusetts General Hospital. For the past 25 years, she has worked in analysis, design, implementation and evaluation of information systems for health care. Ms. Zielstorff is the author of over 50 publications in the field. Her current responsibilities are to develop and implement methods for clinical decision support for Partners-wide systems, including guidelines, alerts, clinical algorithms, and condition-appropriate order sets. She has served on numerous national committees and panels dealing with informatics in health care, including the American Nurses Association Steering Committee on Databases to Support Clinical Nursing Practice. She is concluding her chairmanship of the ANA Nursing Information and Data Set Evaluation Center (NIDSEC) Committee. In 1990 she was elected to the American College of Medical Informatics, and in 1991, to the American Academy of Nursing.