An Introduction to MedDRA Coding: Structuring Clinical Terminology in Drug Safety & CDM

Introduction

When a patient or physician reports an adverse event during a clinical trial or post-marketing surveillance, they describe symptoms in everyday, non-standardized language. A patient might report that their “head felt like it was pounding,” while a nurse logs “throbbing temporal pain.” Both individuals are describing the same underlying clinical condition, yet computer safety databases and global regulatory authorities cannot efficiently aggregate, search, or analyze unstandardized text strings.

To create mathematical order out of raw human feedback, the global pharmaceutical industry relies on MedDRA (Medical Dictionary for Regulatory Activities). Developed under the auspices of the International Council for Harmonisation (ICH), MedDRA is a rich, highly specific medical terminology designed to facilitate the sharing of regulatory information internationally.

For professionals in Pharmacovigilance (PV) and Clinical Data Management (CDM), mastering MedDRA coding is not just about vocabulary—it is a critical data-integrity skill that directly impacts signal detection, patient safety, and regulatory compliance.

1. The 5-Level Hierarchy of MedDRA

MedDRA is structured as a multiaxial, five-level hierarchy. This architecture moves from highly specific verbatim expressions at the bottom to broad anatomical or physiological categories at the top.

[SOC] System Organ Class
  └─ [HLGT] High Level Group Term
      └─ [HLT] High Level Term
          └─ [PT] Preferred Term
              └─ [LLT] Lowest Level Term  <-- Entry Point for Verbatim Text

1. Lowest Level Term (LLT)

  • Definition: The most granular level of the dictionary, containing thousands of colloquial terms, synonyms, and even common historical typos.

  • Operational Role: Captures the verbatim concept reported by the patient or clinician as closely as possible.

  • Example: Pounding headache, Cephalea, or Sick headache.

2. Preferred Term (PT)

  • Definition: A distinct, single medical concept used for official reporting, statistical analysis, and regulatory submissions. Every LLT maps directly to one PT.

  • Operational Role: Serves as the fundamental unit for aggregate data analysis and signal detection.

  • Example: Headache.

3. High Level Term (HLT)

  • Definition: A broader grouping that connects related Preferred Terms based on anatomical site, etiology, or pathology.

  • Operational Role: Assists medical reviewers in analyzing clusters of related medical conditions.

  • Example: Headaches NEC (Not Elsewhere Classified).

4. High Level Group Term (HLGT)

  • Definition: A high-level aggregate grouping related HLTs together under broader physiological categories.

  • Operational Role: Used for high-level safety summaries and overview assessments in safety reports.

  • Example: Headache disorders.

5. System Organ Class (SOC)

  • Definition: The highest level of the hierarchy, dividing all medical terms across major body systems, biological etiologies, or operational contexts (e.g., Surgical and medical procedures).

  • Operational Role: Categorizes events for high-level safety profiling across broad body systems.

  • Example: Nervous system disorders.

2. Practical Coding Scenario: From Raw Text to SOC

To understand how a verbatim term translates into the MedDRA structure during ICSR processing or data cleaning, consider this real-world workflow:

Hierarchy Level Applied Term Explanation
Verbatim Reported Text “Patient woke up with a sharp, throbbing headache.” Raw data received from clinical site or consumer report.
Lowest Level Term (LLT) Throbbing headache (Code: 10043542) Selected by the safety coder to match the verbatim concept.
Preferred Term (PT) Headache (Code: 10019211) Standardized concept automatically mapped by the safety database.
High Level Term (HLT) Headaches NEC Grouping term for non-specific headache events.
High Level Group Term (HLGT) Headache disorders Broad physiological group.
System Organ Class (SOC) Nervous system disorders Primary body system classification.

3. Core Rules of MedDRA Coding

To maintain consistency across global safety teams, coders follow strict ICH MedDRA Term Selection Points to Consider (MTS:PTC) guidelines:

  1. Do Not Embellish or Interpret: Code only what is explicitly documented. If a report states “chest pain,” do not assume or code “Myocardial infarction” without medical confirmation.

  2. Code the Diagnosis Over Symptoms: If a report lists both symptoms (fever, cough, shortness of breath) and a confirmed diagnosis (COVID-19 pneumonia), the primary code must represent the definitive diagnosis.

  3. Handle Unclear Terms via Queries: If reported text is ambiguous or contradictory (e.g., “Patient took medication and felt bad”), issue a data query to the clinical site rather than making an arbitrary coding guess.

  4. Version Management: MedDRA updates twice a year (March and September). Data management teams must perform regular dictionary up-versioning to ensure ongoing study datasets align with current regulatory codes.

4. Why Standardized Coding Matters in Data Operations

Global Harmonization

Regulatory agencies like the US FDA, EMA (Europe), and PMDA (Japan) receive millions of adverse event reports annually. MedDRA provides a single, universal medical language that eliminates translation barriers and terminology discrepancies across international borders.

Quantitative Signal Detection

Safety algorithms (such as Proportional Reporting Ratio calculations) rely on PT-level groupings. By mapping hundreds of localized verbatim descriptions—such as “upset stomach,” “sour stomach,” and “epigastric burning”—to the single PT Dyspepsia, data systems can instantly flag abnormal statistical spikes indicating a potential safety signal.

Regulatory Compliance (E2B Standards)

Electronic Case Safety Reports (ICSRs) transmitted via ICH E2B(R3) gateway protocols mandate MedDRA LLT and PT numerical codes for every reported adverse event, medical history item, and cause of death.

Leave a Reply

Your email address will not be published. Required fields are marked *