Quality Measures and Electronic Medical Systems

The National Committee for Quality Assurance (NCQA) has chosen its quality measures wisely. NCQA has demanded that the measures address care processes that have a strong scientific base, and because of awareness of the cost of quality reviews, has chosen measures that can be defined in terms of data that are present in most administrative computer systems. For example, the denominator for the Health Plan Employer Data Information Set (HEDIS) measure of pneumoccocal immunization rate is derived from a computer search for patients eligible for pneumococcal vaccine, ie, those older than 65 years, or having an International Classification of Diseases, Ninth Revision (ICD-9) diagnosis of heart failure, chronic lung disease, and a few other chronic diseases. Its numerator is derived by a search of procedure codes that indicate pneumococcal vaccine use or by a chart review of a sample of the denominator cases. Thus, a computer can do much of the review work.

NCQA would like to broaden the scope of information included in its quality measures, yet avoid requirements for primary data collection and manual chart review. The data needed for many such measures are already collected in laboratories, pharmacies, radiology departments, and other reporting services. However, it is difficult to deliver these data electronically and intelligibly to a computer system.¹ In this issue of THE JOURNAL, Schneider et al² have defined a set of recommendations for facilitating the delivery and integration of clinical data to practice databases and for encouraging full electronic medical record systems³ in clinical practices.

For the most part, these are good recommendations that will benefit practitioners by enabling more computer automation of their practice and at the same time deliver more comprehensive quality measures. Moreover, the recommendations are generally practical. For example, the kinds of information recommended for effectiveness measures are exactly those that physicians now gather for patient care.

NCQA recommends that health plans adopt Health Level Seven (HL7),⁴ an American National Standards Institute (ANSI) standard for communicating clinical data, and Accredited Standards Committee (ASC) X12N,⁵ a message standard for claims enrollment and other administrative data.These recommendations take advantage of the widespread use of HL7 by hospitals, large practices, and diagnostic reporting services, and builds on government (eg, the Centers for Disease Control and Prevention, Veterans Affairs, and the Department of Defense) efforts to use HL7 and the broad base of X12N's use for administrative purposes. The authors make good recommendations about the 3 other necessary ingredients for greater medical record automation:

Schneider et al recommend coding at the most detailed level of ICD-9, as do many organizations under the banner of better data. I respectfully disagree. The cost of manual coding is proportional to the granularity of the coding system. In many circumstances, coding at full ICD-9 detail is ridiculously excessive, clinically off target, and adverse to efficient electronic medical recordkeeping. For instance, asking physicians to choose between anterior (410.1) and inferior (410.5) myocardial infarction makes sense because the 2 codes predict different outcomes. However, asking physicians to choose among 434 different diagnoses/codes for "tuberculosis" is a carryover of the preantibiotic origins of the ICD and makes no sense.

Furthermore, despite its extreme verbosity in some subject domains, ICD-9 completely lacks clinical expressivity in others. Even with 434 different codes for tuberculosis, ICD-9 has no code for multidrug-resistant Mycobacterium tuberculosis. The ICD-9, with full coding, forces trivial distinctions among upper, middle, and lower lobe lung cancer, but provides no way to distinguish important differences in the cellular morphology, eg, adenocarcinoma vs squamous cell carcinoma. Among the ICD-9 codes for hypertension is a code for "benign essential hypertension" (401.1), which is their preferred term for "hypertension of unspecified cause," but is also an oxymoron. "Hypertension not otherwise classified" (401.9), which better describes most patients with hypertension, is a nonpreferred code because it is "nonspecific and subject to rejection by payers."¹²

The ICD-9 burdens the codes with information other than the identity of the problem or symptom, as though the ICD-9 codes were the only vehicle for communicating information about a patient to third parties. It often includes different codes for a child with a disease and an adult with the same disease, even though the patient's birthdate is always transmitted along with any record that contains an ICD-9 code. The fifth digit usually conveys some factor about the disease other than its identity. For instance, in the case of tuberculosis, the fifth digit conveys how it was diagnosed (eg, whether by smear or by culture). In the case of diabetes, the fifth digit conveys the level of control, but interestingly provides no criteria. With electronic medical records this is neither the most efficient nor most accurate way to convey such information, ie, the computer could send the last glycosylated hemoglobin or glucose level without requiring any coding effort.

The ICD-9 was born and evolved in a universe parallel to and independent of clinical practice, with an initial focus on hospital care. Hospitals could afford the expense of coding specialists to translate the vocabulary of the clinical universe to that of the ICD universe. Office practices cannot. The expectation in the informatics world has always been that the information needs of the clinical world would be primary and that those of the administrative world would be secondary and flow naturally without extra work from the information required to provide patient care. Physicians could record their problems in a computer system as Weed¹³ envisioned nearly 40 years ago, and the computer would map from the problem code to an appropriate ICD-9 billing code. Computer systems would reflect the clinical world, as physicians know it, with problem menus containing names like "hypertension" or "squamous cell lung CA" that link these to the closest, but not necessarily 5-digit, ICD-9 codes. This can happen only if physicians are allowed to choose clinically reasonable levels of ICD-9 precision. Slavish adherence to current ICD-9 coding rules is incompatible with efficient and clinically driven data capture.

NCQA and Schneider et al have taken an insightful and pragmatic approach to quality measures via electronic clinical systems. The needed electronic systems will be more appropriate, useful, and acceptable if they are not constrained by absolute adherence to the peculiarities of ICD-9 coding.