14

Coding of AEs and Drug Names

As pharmacovigilance becomes more mechanized and computerized, the need for standard terminologies, formats, dictionaries, narratives, and abbreviations grows. The first two major areas that have been standardized are the medical coding of adverse events (AEs) and medical history and the coding of drug names. Medical coding has become standardized in the world of pharmacovigilance with the use of the Medical Dictionary for Regulatory Activities (MedDRA). Several other coding systems have been used. Two prominent ones are COSTART, which the U.S. Food and Drug Administration (FDA) used for AE coding until moving to MedDRA, and WHOART, from the Uppsala Monitoring Centre. See Web Resource 14-1 for further information on WHO-ART. Some still use WHO-ART, although MedDRA is now becoming the accepted standard from the International Conference on Harmonization (ICH). Some older drug labels in the United States and elsewhere still have non-MedDRA terms (e.g., COSTART) but newer labeling had been “MedDRA-ized.”

Coding is done so that companies, regulators, and others are able to communicate with each other using the same medical language. AEs are coded so that similar cases are described (coded) in the same consistent way and so that they can easily be retrieved, analyzed, and compared. It is invaluable for signal detection and analysis.

MedDRA

MedDRA was developed by the ICH based on earlier work by the United Kingdom health authority. It is owned by the International Federation of Pharmaceutical Manufacturers and Associations, acting as trustee for the ICH Steering Committee. A service organization known as the Maintenance and Support Services Organization (MSSO) serves as the repository, maintainer, and distributor of MedDRA as well as the source for information on MedDRA. Detailed information is available from the MedDRA website (Web Resource 14-2).

MedDRA is a terminology developed for drugs and devices used for standardized coding of medical issues, including AEs and medical history. It is hierarchical, which means that it has multiple levels (five), ranging from the most general to very specific. It is available in English, with some or all of it also available in Czech, Dutch, French, German, Italian, Portuguese, Spanish, and Japanese. A Chinese translation has just been released.

Regulatory Status

European Union: MedDRA use is obligatory in the European Union. All serious adverse event (SAE) reports must be submitted electronically using MedDRA codes. MedDRA is to be used for the reporting of suspected, unexpected, serious adverse events (SUSARs) to the EudraVigilance clinical trial and postmarketing modules. Periodic Safety Update Report (PSURs) must have the AE terms in MedDRA. Product labeling, the Summary of Product Characteristics (SmPC), and Risk Management Plans should also use MedDRA. Volume 9A also recommends using “Standardized MedDRA Queries” for case retrieval when signaling.

United States: It has “more or less” been mandated by the FDA for use in AE reporting. The FDA published a rule mandating its use in 2002, and its use is required in the proposed regulations of March 2003. In 2009, the FDA issued proposed rules requiring AE submission electronically (E2B) using MedDRA. However, these rules have not been put into final regulations and are not in force. Interestingly, in the update of the clinical trial regulations (21CFR312) the FDA explicitly stated that they are not requiring MedDRA for IND safety reporting, though they did not state explicitly why. Nonetheless, MedDRA is used in most AE reporting to FDA. In practice, as MedDRA is obligatory for the European Union, Japan, and elsewhere and has no widely used “competitors,” it is wise to use MedDRA consistently for AE reporting.

Japan: Adverse event reports should be submitted in the Japanese version of MedDRA. MedDRA/J is to be used in Periodic Infection Reports and PSURs as well as for reporting infection terms for medical devices with biologic components.

Canada: MedDRA is recommended for coding adverse reaction reports and for the Product Monograph (product labeling).

See the MSSO regulatory website for updates and further regulatory information (Web Resource 14-3).

MedDRA is updated twice yearly (April and October), and, in general, users update their own computer systems within 30 to 60 days of receipt of the upgrade. This too is not fully mandated everywhere but is the common practice. Users may request the addition of new codes to future versions of MedDRA by applying to the MSSO, which then reviews each request. Codes also may be moved, deleted, changed, demoted, and promoted by the MSSO in the updates. The version number “bumps up” each year.

MedDRA terms cover diseases, diagnoses, signs and symptoms, therapeutic indications, medical and surgical procedures, and medical, social, and family histories. MedDRA does not cover drug and device names, study design, patient demographic terms, device failure, population qualifiers (e.g., rare, frequent), and descriptions of severity or numbers. It does not give definitions of AEs.

Originally, MedDRA was developed for postmarketing AEs, but it is now used widely for clinical trial AEs. This has produced complex issues with regard to long trials that might run a year or more and go through one or more MedDRA upgrades. When and how to update the codes in an ongoing trial is complex and has multiple solutions.

MedDRA Version 13.0 now has more than 80,000 terms arranged into five hierarchical categories:

An example of coding:

• SOC: Cardiac disorders
  
• HLGT: Cardiac arrhythmias
  
• HLT: Supraventricular arrhythmias
  
• PT: Sinus bradycardia
  
• LLT: Bradycardia sinus, sinus bradycardia
  
• Verbatims: Slow heart rate, sinus bradycardia, slow pulse, and so forth

Verbatim terms are not MedDRA terms but rather the terms used by reporters, patients, and investigators. They may be medical, lay, or slang terms. Many companies create verbatim dictionaries in which they map the verbatim terms to MedDRA LLT- or PT-level terms. Note that in this example “sinus bradycardia” is a verbatim, LLT, and PT at the same time. Note also that all PTTs are LLTs (but not vice versa).

Browsers: Because there are so many terms, it is necessary to search for a needed term by computer rather than reading through a printed version of the terminology. For this, the MSSO and other companies have developed software, called “browsers,” to allow a user to find the terms he or she needs. The MSSO makes available a downloadable browser to all subscribers (Web Resource 14-4).

Commercial browsers are also available. With the browser, one or more words (e.g., pain in the leg) are typed in, and the browser software determines whether there is a direct word-for-word match at one or more of the hierarchical levels. If so, it gives the direct “hit” along with the hierarchical tree; that is, if the direct hit is an LLT, it will display the PT, HLT, HLGT, and SOC (both primary and secondary if more than one exists). If not, most browsers suggest choices for the user to pick from. Some browsers do autoencoding where one may type in a narrative (prose paragraphs), and the browser will extract and code all medical-sounding terms for the user to examine and accept or reject.

The actual coding of AEs is a very complex subject and cannot be fully covered here, but some general thoughts and issues on coding are addressed. The goal of coding is to create one or more AE codes that capture the essence of the problems that the patient experienced. There should not be too many or too few terms but just enough. That is, we should follow the “Goldilocks Principle” and use codes that are “just right,” or as Albert Einstein put it: “Everything should be made as simple as possible, but not simpler.” Defining “just enough,” however, is difficult. There are many complexities that one encounters when coding:

• Should one be “a lumper or a splitter”? That is, should one code “flu-like syndrome” (the lumper) or “fever,” “malaise,” “fatigue,” “muscle aches,” “headache,” “chills,” and “runny nose” (the splitter)? This may be evident to the reader for a term such as “flu-like syndrome” but less clear for the “Hermansky-Pudlak syndrome” (albinism, visual problems, platelet defects with bleeding, lung disease, and often kidney and gastrointestinal disease).
  
• Should one code “cascade effects” or “secondary effects”? For example, if a patient becomes dizzy and falls, breaking his or her shoulder and abrading his or her skin, the primary event is dizziness (and should be coded) but should the other terms—the fall, shoulder fracture, skin abrasions—also be coded and thus considered as AEs associated with the drug in question in the database and future labeling?
  
• Should signs (hepatomegaly) and symptoms (abdominal pain) be coded, or only diseases and diagnoses?
  
• Should provisional or “rule out” diagnoses be coded?
  
• How specific should one be? Should one code “skin rash on face and neck” or just “rash”?
  
• Should one code “low blood glucose” or “hypoglycemia”? This actually represents the question about whether one should code laboratory abnormalities as AEs. In practice, this is done in an arbitrary and inconsistent manner and can be a problem in clinical trial reports or dossiers for Market Authorization (MA) approval when the number of AEs of hypertension do not equal the number of patients whose recorded blood pressure on physical exams went up, clearly demonstrating that not all elevations in blood pressure were considered to be reportable or codable by the investigator or company as AEs.
  
• Coding may be done at a less specific level, coding “edema” instead of “facial edema” or “lung disease NOS (not otherwise specified)” instead of a more specific diagnosis (e.g., pneumococcal pneumonia). This type of “lumping” can mask or hide certain AEs or problems.
  
• Coding consistency and variability is often a problem, especially when there are multiple coders or coding is done over time (e.g., in a long clinical trial). One might see “elevated liver enzymes,” “abnormal liver enzymes,” “elevated ALT,” or “elevated AST,” all of which are capturing the same condition in different patients at different times. This poses problems when one is attempting to retrieve all the cases of liver problems to do safety signaling (see “Standardized MedDRA Queries” section below) or aggregate AE tables.
  
• Having too many codes for a particular case makes it hard to understand what the primary or major issues were. In practice, many users try to limit the number of codes in each case to six or eight at most.
  
• Cultural differences may affect coding across countries or regions. In addition, language issues may alter coding, especially if people are coding in a language (English) that is not their primary language.

There is, in many cases, no single correct answer to a coding question. Rather it is necessary that coders agree on certain standards, or “conventions,” that define (sometimes arbitrarily) how to code. The MSSO has published several versions of its coding suggestions entitled “MedDRA® Term Selection: Points to Consider, ICH-Endorsed Guide for MedDRA Users. Application to Adverse Drug Reactions /Adverse Events & Medical and Social History & Indications.” See Web Resource 14-5.

The FDA, in its “Guidance for Industry Premarketing Risk Assessment” of March 2005 (Web Resource 14-6), has commented on coding:

Stay updated, free articles. Join our Telegram channel

Join