MedDRA Coding for Trial Safety Data

MedDRA coding is the process of mapping a clinical trial’s free-text descriptions of adverse events, medical history, indications, and other clinical findings to standardized terms in the Medical Dictionary for Regulatory Activities (MedDRA) — the step that turns a site’s own wording (“felt queasy after dosing”) into a structured, aggregatable, submission-ready term. Every coded event lives somewhere in MedDRA’s five-level hierarchy, and getting that placement right, consistently, across an entire trial and across trial database lock and MedDRA version changes, is what this guide covers.

The MedDRA hierarchy in one table

MedDRA organizes terms into five levels, from most granular to broadest. Coding always happens at the LLT level; every other level is derived automatically from that choice.

Level	Name	What it represents	Example (nausea)
1	SOC — System Organ Class	The broadest grouping, by etiology, manifestation site, or purpose (e.g. all gastrointestinal disorders)	Gastrointestinal disorders
2	HLGT — High Level Group Term	A grouping of related High Level Terms under a SOC	Gastrointestinal motility and defecation conditions
3	HLT — High Level Term	A grouping of closely related Preferred Terms	Nausea and vomiting symptoms
4	PT — Preferred Term	The single, unambiguous medical concept used for coded reporting and aggregation	Nausea
5	LLT — Lowest Level Term	The verbatim-adjacent term a coder actually selects; every LLT maps to exactly one PT	Feeling sick, Queasiness, Nausea

Two structural points matter for coding practice, not just terminology:

Coding happens at the LLT, everything above is derived. A coder searches for and selects the LLT that best matches the verbatim term (e.g. “queasy” → LLT “Feeling sick”); MedDRA’s structure then supplies that LLT’s single parent PT and, from there, its SOC/HLGT/HLT lineage automatically. Coders do not choose a PT or SOC directly.
MedDRA is multiaxial. A single PT can legitimately link to more than one SOC (for example, a term with both an infective and a respiratory dimension), but exactly one of those SOCs is designated the Primary SOC for default output, aggregation, and reporting — this is what keeps summary tables from double-counting the same event under two different organ classes.

Last verified 2026-08-16 against MedDRA’s own Introductory Guide documentation and corroborating regulatory-informatics sources (Oracle Argus Safety documentation). The five-level structure and multiaxial/Primary SOC design are stable, low-change-risk facts of MedDRA’s architecture — they have not changed across MedDRA versions.

Who maintains MedDRA, and why that matters for coding decisions

MedDRA was developed under the International Council for Harmonisation (ICH) and is maintained on ICH’s behalf by the Maintenance and Support Services Organization (MSSO). The MSSO is the authority a coding team defers to on ambiguous placement, new-term requests, and version-to-version change rationale — it is not a vendor-specific or sponsor-specific decision. Within ICH’s own guideline taxonomy, MedDRA sits under the Multidisciplinary (M) category alongside the ICH M4 Common Technical Document format, reflecting that it is a cross-cutting terminology standard rather than a safety- or efficacy-specific guideline in its own right.

The coding procedure: from verbatim term to a locked, coded record

Capture the verbatim term as reported. The site or subject’s own description — not a coder’s paraphrase — is what goes into the case report form (CRF) or safety database first. Recoding starts from this original text every time, which is why verbatim quality (specific, complete, not pre-coded by the reporting site) is itself a data-management concern.
Search for the best-matching LLT. Coders use MedDRA-aware coding software (built into most electronic data capture and safety database platforms) to search the current MedDRA dictionary for an LLT that reflects the verbatim term as closely as possible, following MSSO’s published coding conventions — favoring specificity over a vague or overly broad match, and never inferring a diagnosis the verbatim text does not support.
Let the PT/HLT/HLGT/SOC lineage derive automatically. Once the LLT is selected, its parent PT and upstream hierarchy populate without further coder judgment — this is what makes MedDRA-coded data aggregable across sites, sponsors, and submissions using a shared structure.
Route ambiguous or novel verbatim terms for medical review. A verbatim term with no clean LLT match, or one that could plausibly map to more than one clinically distinct PT, should not be force-fit by a coder alone — it goes to a medical reviewer (often a nurse coder lead or medical monitor) for a documented decision, consistent with the sponsor’s coding conventions and Good Clinical Data Management Practices (GCDMP).
Apply coding consistently within a study, not just within a single coder’s judgment. Sponsors maintain study-specific coding conventions (a living reference of prior decisions on ambiguous or recurring verbatim terms) precisely so two coders — or the same coder six months apart — reach the same LLT for the same verbatim text.
Reconcile before database lock. Coding completeness and consistency are checked as part of the broader data-cleaning pass ahead of database lock — an uncoded or inconsistently coded adverse event is a query, the same as any other data discrepancy.

MedDRA version updates: what changes, and how re-coding decisions get made

MedDRA is released on a regular update cycle, and each new version can add, retire, or reclassify terms (for example, moving a PT to a different SOC, or splitting a term MSSO determined was ambiguous). A trial’s coding does not automatically move to a new version the moment one is released — this is a deliberate sponsor/CRO decision, governed by the study’s own coding conventions and typically documented in the data management plan, and it turns on a few recurring questions:

Does the trial stay on its starting version for the life of the study, or upgrade at defined points? Many sponsors fix the MedDRA version at study start and only re-version at a predefined milestone (e.g. before a major interim analysis or database lock) specifically to avoid a moving coding target mid-study.
What happens to already-coded terms when a version change is adopted? MSSO publishes version-to-version change documentation identifying every term affected by a new release; a version upgrade requires re-mapping any previously coded LLT that was retired, split, or reclassified — not a blanket re-code of the whole database.
Is the version used consistent across all data feeding a single analysis or submission? Mixing MedDRA versions within one dataset undermines exactly the aggregation and cross-trial comparability MedDRA coding exists to enable — regulatory submissions expect a single, documented version to be identified for the coded data being submitted.

Last verified 2026-08-16. MedDRA’s update cadence and MSSO’s version-to-version change documentation are well-established, stable facts of how MedDRA is maintained — this page deliberately does not cite a specific current version number, since that changes with each release; confirm the current version directly at meddra.org before relying on one.

MedDRA coding versus related standards it is often confused with

Standard	What it actually does	Relationship to MedDRA coding
MedDRA	Codes the medical event itself (the diagnosis, sign, symptom, or finding)	—
WHODrug (maintained by the Uppsala Monitoring Centre)	Codes the drug or product involved (concomitant medications, suspect products)	Complementary, separate dictionary — a single adverse event record typically carries a MedDRA-coded event and, separately, WHODrug-coded medications
CTCAE (NCI Common Terminology Criteria for Adverse Events)	Grades the severity of an event on a standardized scale	Applied to a MedDRA-coded term, not a substitute for coding it
SDTM (CDISC)	Defines the dataset structure a coded event is submitted in	MedDRA-coded terms populate specific SDTM adverse-event domain variables; SDTM does not itself code anything

Frequently asked questions

What is the difference between the verbatim term and the coded term?

The verbatim term is exactly what the site or subject reported, in their own words. The coded term is the MedDRA LLT (and its derived PT/HLT/HLGT/SOC) a trained coder selected as the best structured match to that verbatim text. The verbatim term is always retained alongside the coded term — coding is an addition to the source record, not a replacement of it.

Why does MedDRA use five levels instead of just one coded term?

The hierarchy lets the same coded data serve two different needs at once: the PT/LLT level supports the granular, one-event-at-a-time detail regulators and safety reviewers need, while the SOC/HLGT/HLT levels above it support meaningful aggregation — summarizing hundreds of individually coded events into interpretable safety tables without losing the underlying specificity.

Who is qualified to perform MedDRA coding?

MedDRA coding is typically performed by trained medical/safety coders — often with a clinical or life-sciences background — working within a sponsor’s or CRO’s documented coding conventions, with ambiguous cases escalated to medical review. It is a specialized function within the broader clinical data management discipline, not a general data-entry task.

Does every adverse event get coded, even minor ones?

Generally yes — protocols typically require coding of all reported adverse events, not only serious ones, because aggregate analysis (e.g. comparing event rates by System Organ Class across arms) depends on complete, consistently coded data, not just the subset that meets seriousness or expedited-reporting thresholds under ICH E2A.

What happens if a verbatim term doesn’t map cleanly to any LLT?

It is escalated for medical review rather than force-fit to the nearest available term. A documented, study-specific coding convention should record how that verbatim term is to be coded going forward, so the decision is applied consistently if the same or a similar verbatim term recurs.