MedDRA Coding Explained: The Hierarchy, How It Works in ICSR Processing, and Where Coders Go Wrong

Every day, safety databases around the world receive adverse event reports written in ordinary human language. A patient says they had “the worst pounding headache of my life.” A physician writes “query MI, ruled out.” A caregiver reports that their father “went a bit yellow.” None of these phrases can be counted, grouped, or analysed as they stand. Multiply them by millions of reports across thousands of products and dozens of languages, and you have a mountain of data that means nothing until it is standardised.

MedDRA is the tool that does the standardising. The Medical Dictionary for Regulatory Activities is the terminology that regulators worldwide expect to see in safety reports, and MedDRA coding is the skill of mapping messy real-world language onto it accurately. It sounds mechanical. It is not. Good coding takes clinical understanding and a firm grasp of the conventions, and it is one of the first things that separates a competent pharmacovigilance professional from a struggling one.

What MedDRA is, and what it is for

MedDRA is a standardised medical terminology developed under the International Council for Harmonisation and maintained by its Maintenance and Support Services Organization. It is used across the drug and device lifecycle to code adverse events, medical and surgical history, indications, and investigation results.

The point of it is aggregation. If one report says “heart attack,” another says “myocardial infarction,” and a third says “MI,” a regulator trying to spot a safety signal needs all three to count as the same event. MedDRA gives every one of them a single standardised term. Once data is coded consistently, you can query it, count it, trend it over time, and compare it across products. Without a common terminology, none of that is reliable.

The five-level hierarchy

MedDRA is structured as a five-level hierarchy, from the broadest grouping down to the most specific wording.

Level	Full name	What it does
SOC	System Organ Class	Broadest grouping, usually by body system or purpose
HLGT	High Level Group Term	Groups related HLTs
HLT	High Level Term	Groups related PTs by anatomy, pathology, or function
PT	Preferred Term	The single medical concept used for most reporting
LLT	Lowest Level Term	The closest match to how the event was actually described

A few things about this structure matter in daily work.

Coders work at the LLT level. The Lowest Level Term is where you capture the reporter’s language most faithfully. “Headache,” “cephalgia,” and “sore head” might all exist as distinct LLTs, and each one links to the Preferred Term Headache. You pick the LLT that best matches the verbatim, and the PT follows automatically because every LLT maps to exactly one PT.

The PT is the workhorse of reporting. Most regulatory aggregation, line listings, and signal analysis happen at the Preferred Term level. The PT is the standardised medical concept. When someone asks “how many cases of hepatic failure do we have,” they mean at the PT level.

MedDRA is multi-axial. A single Preferred Term can appear under more than one System Organ Class. For example, a PT related to an infection of a specific organ might link both to the Infections SOC and to the SOC for that organ system. To prevent the same case being counted twice when you sum across all SOCs, each PT has one designated primary SOC. Cumulative counts are taken along the primary SOC axis. This is a detail that trips up people building aggregate reports, because ignoring the primary-SOC rule inflates counts.

Above the coding levels sit Standardised MedDRA Queries, or SMQs. These are pre-defined, validated groupings of PTs that relate to a particular medical condition of interest, built to support signal detection. If you want to find every case that might relate to, say, drug-induced liver injury, an SMQ pulls together the relevant terms so you are not manually assembling a term list each time.

How coding fits into ICSR processing

In Individual Case Safety Report processing, coding is not a standalone step. It sits inside the workflow that turns an incoming report into a structured, submittable case.

A case arrives. Someone captures the verbatim terms exactly as reported, which is important because the original wording has to be preserved. The events are then coded: each reported reaction becomes an LLT, and the PT is derived from it. Medical history and indications are coded the same way. The medications in the case, meanwhile, are coded using WHODrug rather than MedDRA, which is covered below.

Once coded, the case can be assessed for seriousness, expectedness, and causality, and the coded terms feed the seriousness and expectedness logic. Expectedness, for instance, is judged by comparing the coded event against the reference safety information, and that comparison is only reliable if the coding is right. A miscoded event can make a listed reaction look unlisted, or hide a genuinely unexpected event inside a broader term. Coding errors do not stay contained. They propagate into the regulatory decisions built on top of them.

This is also why coding is not something to rush. It looks like the low-value part of case processing, the bit you want to get past to reach the “real” assessment. In fact it is load-bearing for everything downstream.

Versioning: why the same term can move

MedDRA is not static. It is updated twice a year, with a major version released in March and a minor version in September, following an X.0 and X.1 numbering pattern within each year. Each update can add new terms, promote or demote LLTs, reclassify PTs, and change term status.

That constant change has real operational consequences. Terms have a “current” or “non-current” status, and you are expected to code to current LLTs. A term that was appropriate in one version might be reclassified or deprecated in the next. When a company upgrades to a new MedDRA version, it has to decide how to handle previously coded data, which can mean re-evaluating or re-coding affected terms so that historical and new data remain consistent. Version control is therefore part of the job, not an afterthought. A line listing that mixes terms coded across several MedDRA versions without proper management can produce misleading counts.

For a working coder, the practical rule is simple: know which version you are coding in, code to current terms, and understand that an upgrade is a data management event, not just a software update.

MedDRA versus WHODrug

A common point of confusion for people new to pharmacovigilance is the relationship between MedDRA and WHODrug. They are not competitors and they do not overlap. They cover different halves of a case.

Aspect	MedDRA	WHODrug (WHO Drug Dictionary)
Codes	Medical concepts: events, history, indications, investigations	Medicinal products and substances
Maintained by	MSSO, under ICH	Uppsala Monitoring Centre
Used in a case for	The reactions, the medical background, the indication	The suspect and concomitant medications
Structure	Five-level medical hierarchy	Drug and substance hierarchy with ingredient and ATC linkage

A single ICSR almost always uses both. WHODrug codes what the patient took. MedDRA codes what happened to them and why they were taking it. A well-processed case has the drugs coded in WHODrug and the events, history, and indication coded in MedDRA, and a coder needs to be comfortable moving between the two.

Where coders go wrong

Most coding errors are not exotic. They cluster around a handful of recurring judgement calls, and knowing them in advance is most of the battle.

Coding a diagnosis when only symptoms were reported, or the reverse. If a reporter gives you a confirmed diagnosis, you generally code the diagnosis rather than fragmenting it into individual symptoms. If they only report symptoms with no unifying diagnosis, you code the symptoms and do not invent a diagnosis the reporter did not make. Getting this direction wrong, splitting a stated diagnosis into pieces or lumping loose symptoms into a diagnosis nobody confirmed, is one of the most frequent mistakes.

Coding provisional or ruled-out diagnoses as if they happened. “Query MI, ruled out” does not mean the patient had a myocardial infarction. Coding a differential or excluded diagnosis as a real event puts a false signal into the database. You code what was actually experienced or confirmed, not what was considered and dismissed.

Treating death as the event. Death is an outcome, not an adverse event in itself. If a patient died of hepatic failure, the event is the hepatic failure and death is captured as the outcome. Coding “death” as the reaction loses the clinically meaningful information about what actually caused it.

Picking a technically valid but clinically wrong term. MedDRA often offers several plausible LLTs for a given phrase. The closest wording is not always the right medical concept. A coder has to choose the term that captures the reporter’s clinical meaning, not merely the one whose letters match most closely. This is exactly the kind of judgement that automated coding tools get wrong, and why human review of AI-suggested codes still matters.

Ignoring specificity that was actually provided. If the reporter specified a location, laterality, or severity that a more specific term captures, dropping to a vaguer term throws away real information. Conversely, coding a level of specificity the reporter never gave invents detail that was not there. Match the term to what was reported, no more and no less.

Losing the verbatim. The original reported wording has to be preserved alongside the code. Overwriting or discarding the verbatim removes the ability to audit or re-evaluate the coding later, which is both a quality problem and, in a regulated environment, a compliance one.

Why this skill still matters in an AI era

Automated MedDRA coding tools are now common in ICSR processing, and they are genuinely useful for high-volume, straightforward events. But they do not remove the need for skilled coders. They change what the coder does.

When a tool suggests a code, someone has to decide whether it is right. That decision requires exactly the understanding described in this guide: how the hierarchy works, why a term might be technically plausible but clinically wrong, how versioning affects term status, and where the recurring pitfalls sit. A coder who understands MedDRA deeply catches the machine’s systematic errors efficiently. A coder who treats the tool’s output as correct by default lets those errors through. The premium on genuine MedDRA competence has gone up, not down.

MedDRA coding is taught as a core component of iLearn CRI’s Pharmacovigilance course (3 months, ₹40,000), alongside the ICSR processing workflow, seriousness and causality assessment, and the safety database exposure that most drug safety roles expect from day one. Coding is not a side skill in pharmacovigilance. It is one of the foundations the rest of the discipline is built on, and it rewards being learned properly rather than picked up in fragments on the job.