MedDRA Coding Demystified: What Every PV Professional Needs to Know

If you've spent any time in pharmacovigilance, you've encountered MedDRA. You may have used it daily without fully understanding what's happening beneath the surface. Or you may be new to PV, staring at terms like "Preferred Term" and "System Organ Class" and wondering how they all fit together.

Either way, this blog is for you.

MedDRA — the Medical Dictionary for Regulatory Activities — is one of the most important, most widely used, and most frequently misunderstood tools in all of drug safety. Get it right, and your adverse event reports are consistent, comparable, and regulatory-ready. Get it wrong, and you create downstream problems that can compromise signal detection, delay submissions, and in serious cases, leave real safety signals buried in incorrectly coded data.

Here's everything you need to understand MedDRA clearly — including the updates that matter most in 2026.

What Is MedDRA and Why Does It Exist?

MedDRA is a standardised international medical terminology developed by the International Council for Harmonisation (ICH) in the 1990s. Its core purpose is elegantly simple: give every adverse event, medical condition, symptom, and drug-related medical concept a standardised term so that safety data can be compared consistently across countries, companies, databases, and regulatory authorities.

Before MedDRA, the same event might be reported as "headache" in one country, "cephalgia" in another, and "head pain" in a third. A regulatory authority trying to detect a safety signal across global data would be comparing apples to oranges to pineapples.

MedDRA fixed that. By assigning standardised terms to medical concepts, it made global pharmacovigilance possible.

Today, MedDRA is mandatory for adverse event reporting in the European Union, Japan, and all ICH member regions. The FDA requires it for electronic submissions across NDAs, ANDAs, BLAs, and INDs. It is the universal language of drug safety.

As of version 29.0, released in March 2026, MedDRA contains over 81,000 Lowest Level Terms — a figure that reflects both the extraordinary scope of the dictionary and the ongoing challenge of working with it accurately.

The Five-Level Hierarchy: Understanding the Structure

MedDRA's structure is hierarchical — five levels, from the broadest to the most specific. Understanding this hierarchy is foundational to everything else in MedDRA coding.

Level 1: System Organ Class (SOC)
The highest level — the broadest grouping. There are 27 SOCs in MedDRA, each representing a major body system or category of medical concept.

Examples: Cardiac disorders, Nervous system disorders, Gastrointestinal disorders, Investigations, Social circumstances

SOCs are used for aggregate safety summaries and high-level regulatory reporting. When a PSUR says "the most commonly affected system organ class was Gastrointestinal disorders," it's referring to this level.

Level 2: High-Level Group Term (HLGT)
A grouping within the SOC — more specific than the SOC but still a broad category. Each SOC contains multiple HLGTs.

Example: Within Cardiac disorders SOC → Cardiac arrhythmias HLGT

HLGTs are used primarily for data analysis and signal detection — grouping related conditions for statistical review.

Level 3: High-Level Term (HLT)
A further grouping within the HLGT. Becoming more specific — now describing related types of a medical condition.

Example: Within Cardiac arrhythmias HLGT → Supraventricular arrhythmias HLT

HLTs provide the middle layer of analysis — useful for identifying clusters of related events.

Level 4: Preferred Term (PT)  (The Most Important Level)
This is where the real work of MedDRA coding happens. The Preferred Term is the standardised medical concept assigned to an adverse event. It is the level used in Individual Case Safety Reports (ICSRs), clinical trial databases, and regulatory submissions.

When a patient reports "chest tightening and difficulty breathing," the coder's job is to assign the appropriate Preferred Term — perhaps Dyspnoea or Chest discomfort, depending on the clinical context and the available information.

Every PT belongs to a primary SOC, ensuring consistent classification in aggregate analyses.

Level 5: Lowest Level Term (LLT)
The most granular level — the entry point where raw, verbatim adverse event terms are first coded. LLTs include synonyms, abbreviations, lay terms, and variant spellings that all map upward to a single PT.

Example: LLTs "Chest tightness," "Tightness in chest," "Chest pressure," and "Constriction of chest" all map to the PT Chest discomfort

Coders work at the LLT level first — finding the LLT that most closely matches the reported term — and the system maps automatically to the appropriate PT, HLT, HLGT, and SOC above it.

The Golden Rule of MedDRA Coding

Before going further, there is one principle that underpins all good MedDRA coding practice:

Code what is reported, not what you think it means.

This sounds simple. In practice, it is one of the most frequently violated principles in pharmacovigilance.

When a patient reports "my heart was racing," the coder's job is not to diagnose the patient. It is not to determine whether they had atrial fibrillation, anxiety, or too much caffeine. It is to find the MedDRA term that most accurately represents what was reported — which in this case might be Palpitations or Heart rate increased, depending on the precise wording.

Interpretation creep — where coders subtly upgrade or downgrade the clinical severity of a reported term — is one of the most common sources of MedDRA coding inconsistency. It happens with the best intentions and creates real problems in signal detection, because terms that should cluster together get scattered across different PTs.

Code the report. Let the medical reviewers interpret the clinical significance.

The Three Most Common MedDRA Coding Mistakes

Mistake 1: Coding to the Wrong Specificity Level
MedDRA coding should be as specific as the information allows — no more, no less.

If a patient reports "liver problems," coding to Hepatic failure when there's no clinical evidence of failure is over-coding. But coding only to Hepatic disorder when the reporter has specified "elevated liver enzymes confirmed on blood test" is under-coding. The correct PT in that case is Alanine aminotransferase increased or Liver function test abnormal, depending on what's documented.

The principle: use the most specific term supported by the available information.

Mistake 2: Coding Symptoms Instead of the Diagnosis (or Vice Versa)
When both a diagnosis and its symptoms are reported, the MedDRA guidance is clear: code the diagnosis, not the individual symptoms — unless the symptoms provide additional clinically relevant information not captured by the diagnosis code.

For example, if a patient is reported to have had a myocardial infarction with associated chest pain and shortness of breath, code Myocardial infarction as the primary PT. Coding Chest pain and Dyspnoea separately alongside it creates redundancy and distorts aggregate analyses.

The exception: when the symptoms reveal something the diagnosis code doesn't capture — additional PTs may be appropriate.

Mistake 3: Using Outdated MedDRA Versions
MedDRA is updated twice a year — in March and September — with each version adding new terms, modifying existing ones, and occasionally retiring or reclassifying outdated terminology.

Using MedDRA version 26.1 when the current version is 29.0 means you may be using retired terms, missing newer and more specific PTs, and creating data inconsistencies with submissions that use the current version.

Always check which version is required by your regulatory authority and your organisation's SOPs — and ensure your coding database reflects the current version.

MedDRA in Practice: The Coding Workflow

Understanding the structure of MedDRA is one thing. Knowing how coding actually works in a real PV environment is another.

Here is a simplified version of the typical coding workflow for an Individual Case Safety Report:

Step 1: Identify the verbatim term. The adverse event as reported by the patient, healthcare professional, or reporter. This is the raw, unprocessed language — "stomach cramps," "felt dizzy when standing up," "couldn't sleep."

Step 2: Search for the closest LLT. Using your MedDRA browser or safety database (Oracle Argus, Veeva Vault Safety, ArisGlobal, etc.), search for the LLT that most closely matches the verbatim term. The goal is the closest match that is still accurate — not a synonym that changes the clinical meaning.

Step 3: Confirm the mapped PT. Once you've identified the LLT, confirm that the PT it maps to accurately reflects the reported event. If the PT feels clinically wrong for the reported term, search for a more appropriate LLT.

Step 4: Assign the primary SOC. Each PT has a primary SOC. Most databases assign this automatically. However, some PTs have multiple SOC assignments — confirm you're using the correct primary SOC for your submission type.

Step 5: Quality check and document. Document your coding decision, including the verbatim term, the selected LLT, and the rationale for any non-obvious coding choices. This documentation is critical for audits and for consistency when the same term appears in future cases.

Important MedDRA Conventions to Know

Beyond the core structure, a number of specific conventions govern MedDRA coding in practice. Every PV professional should be familiar with these:

The "Signs and Symptoms" vs. "Diagnosis" convention. As discussed above — code the diagnosis when available and confirmed. Code signs and symptoms only when no confirmed diagnosis is documented, or when the symptoms provide clinically relevant additional information.

Serious vs. Non-Serious events. While seriousness is not a MedDRA concept per se, certain MedDRA terms are flagged as Important Medical Events (IMEs) — a list maintained by MSSO of terms that are considered serious by nature regardless of how the reporter described them. Coders need to know this list, because IME terms trigger different reporting timelines.

The "not otherwise specified" (NOS) principle. When the available information doesn't support a more specific term, MedDRA provides NOS terms—for example, Rash NOS when the type, location, and characteristics of the rash haven't been documented. NOS is not a shortcut for lazy coding — it's the appropriate choice when the data don't support specificity.

Combining events. Some reporters describe a single event using multiple terms — "headache with nausea and vomiting." This is not three separate events. Depending on clinical context, it may be appropriately coded as a single PT (such as Migraine if clinically consistent) or as multiple PTs if the symptoms are genuinely independent. The guiding question: do the reported terms represent one event or multiple events?

MedDRA in 2026: What's Changed

The most recent updates are worth knowing for any practitioner working with current regulatory submissions.

Version 29.0 (March 2026) is the current release, containing over 81,000 Lowest Level Terms — a significant expansion that reflects the continued growth of therapeutic areas, particularly in biologics, gene therapies, and rare diseases. New terms have been added for emerging treatment modalities, and several older terms have been reclassified to improve clinical precision.

ICD-10 to MedDRA mapping update (January 2026) reflects ongoing efforts to improve cross-terminology interoperability, making it easier to correlate MedDRA-coded safety data with hospital and clinical records coded in ICD-10. As ICD-11 adoption grows globally, further mappings between ICD-11 and MedDRA are anticipated — an important development for real-world evidence integration.

AI-assisted coding is emerging as a significant development. Several major safety platforms are beginning to integrate AI tools that suggest MedDRA codes based on verbatim terms, flagging coding inconsistencies and accelerating the review process. These tools are not replacing human coders — the regulatory expectation remains that a qualified human reviews and confirms all coding decisions. But they are meaningfully accelerating the workflow, particularly for high-volume case processing environments.

Why MedDRA Coding Quality Matters Beyond Compliance

It's tempting to think of MedDRA coding as a compliance exercise — something you do because regulators require it, checked for accuracy during audits, filed and forgotten.

That's the wrong frame entirely.

MedDRA coding is the foundation of signal detection. Every pharmacovigilance analysis — whether it's a disproportionality analysis using reporting odds ratios, a PSUR aggregate summary, or an AI-powered anomaly detection run — depends on MedDRA codes being applied consistently and accurately. A signal that should emerge from a cluster of related PTs gets buried if those PTs have been inconsistently coded across cases. A safety issue in the Cardiac disorders SOC gets missed if a series of cases were miscoded to Investigations.

Real patients are protected by good MedDRA coding. That's not an abstraction. It's the reason the dictionary exists.

Building Your MedDRA Competency

For PV professionals looking to strengthen their MedDRA skills, here's where to focus:

Learn the hierarchy deeply. Don't just memorise the five levels — understand how they relate to each other and why PT is the level that matters most for regulatory submissions.

Practice with real cases. The only way to build coding confidence is to code. Work through published ICSRs, coding exercises, and real case narratives. Many PV training programs provide structured coding practice as part of the curriculum.

Stay current with version updates. Subscribe to MSSO update notifications. Every new release includes a summary of added, modified, and retired terms. Staying current is part of professional practice.

Understand your safety database. Whether your organisation uses Oracle Argus, Veeva Vault Safety, or another platform, understand how MedDRA is implemented within it — how searches work, how multi-SOC terms are handled, how version updates are applied.

Know the IME list. The Important Medical Events list is not optional knowledge. Terms on this list affect your reporting timelines and your regulatory obligations.

The Bottom Line

MedDRA is complex, but it's learnable. And once you understand the logic behind the five-level hierarchy, the coding conventions, and the relationship between accurate coding and meaningful signal detection, it stops feeling like a compliance burden and starts feeling like what it actually is: a precision instrument for patient safety.

In a field where the quality of the data directly determines the quality of the safety signal, MedDRA coding is not a back-office function. It is front-line patient protection work.

Get it right, and you contribute to a system that catches drug safety issues before they become crises. That's not a small thing. That's the whole point.

 
At QuantaEra IT Solutions, our pharmacovigilance training programs cover MedDRA coding from first principles through to advanced regulatory application — combined with the data analytics skills that are transforming drug safety roles globally. Explore our Programs and build the expertise the industry needs.