Usage Examples
- Code the verbatim to the most specific LLT; do not jump straight to the PT you think the investigator meant.
- Every AE listing in the CSR needs the MedDRA version stamped on it, or the reviewer cannot reproduce the counts.
- That hepatic imbalance only appears because half the database is still coded on the old MedDRA version.
What is Medical Dictionary for Regulatory Activities (MedDRA)?
Medical Dictionary for Regulatory Activities (MedDRA) is the standardized medical terminology ICH regions use to code adverse events, indications, and medical history in safety reports, structured as a five-level hierarchy from Lowest Level Term up to System Organ Class.
MedDRA exists because free text cannot be counted. A reviewer looking for cardiac risk cannot aggregate "heart attack", "MI", "myocardial infarct", and "coronary thrombosis" written by four investigators in three countries. MedDRA replaces those verbatim strings with a single coded concept, which is what makes cross-study, cross-sponsor, and cross-border signal detection arithmetically possible at all.
MedDRA covers signs, symptoms, diseases, diagnoses, therapeutic indications, investigation names and results, surgical and medical procedures, and medical and social history. MedDRA does not cover drug or device product names, study design, patient demographics, frequency qualifiers, or severity and causality judgements. Those belong to WHODrug, to CDISC structures, and to the reporter's own assessment fields. Coders who push severity into the term are misusing the dictionary.
MedDRA is applied through a coding convention document, not judgement alone. A verbatim term is matched to the most specific Lowest Level Term, which carries it to a Preferred Term and up to a primary System Organ Class. MedDRA is versioned at database lock, and every listing, periodic report, and integrated summary should name the version that produced it.
Not to be confused with
- WHODrug
- WHODrug codes the suspect and concomitant products; MedDRA codes the medical event that happened to the patient. Both are licensed separately and both populate the same ICSR, so "we have MedDRA" does not mean product coding is solved.
- CDISC SDTM
- SDTM defines the shape of the dataset and the variable names (AEDECOD, AEBODSYS). MedDRA supplies the controlled values that go into them. Structure versus vocabulary; a valid SDTM domain can still be full of miscoded terms.
- SNOMED CT and ICD-10
- clinical-care and billing terminologies built to describe a diagnosis at the point of care. MedDRA is built for regulatory safety reporting, which is why it carries investigations, procedures, and social history that a billing code set has no reason to represent.
- Standardised MedDRA Queries (SMQs)
- SMQs are curated groupings of Preferred Terms used to retrieve a safety topic during signal detection. They sit on top of the terminology as a search tool; they are not a sixth level of the hierarchy and they are not interchangeable with an SOC.
MedDRA is not the source of the reporting duty. The CFR sets the deadline and the electronic format; MedDRA is the coded vocabulary those electronic reports are built from, which is why a coding error is a compliance defect rather than a data-entry annoyance.
What you must do
- 1Report any suspected adverse reaction that is both serious and unexpected during an IND, no later than 15 calendar days after the sponsor determines the information qualifies for reporting21 CFR 312.32(c)(1)(i)
- 2Submit each IND safety report in a narrative format, on FDA Form 3500A, or in an electronic format FDA can process, review, and archive21 CFR 312.32
- 3Report each postmarketing adverse drug experience that is both serious and unexpected, whether foreign or domestic, no later than 15 calendar days from initial receipt of the information21 CFR 314.80(c)(1)(i)
- 4Submit safety reports, including ICSRs, ICSR attachments, and the descriptive information in periodic reports, in an electronic format FDA can process, review, and archive21 CFR 314.80(g)
- 5Maintain the coded postmarketing adverse drug experience records that support those reports so the coded view can be reconciled against the source21 CFR 314.80
Common mistakes
Coding the coder's diagnosis instead of the reported term
An investigator writes "chest pain"; the coder, knowing the outcome, codes myocardial infarction. That destroys the audit trail between verbatim and coded term, inflates the event of interest, and is the finding that turns a routine data review into a data integrity question.
Splitting or lumping a single reported event
"Drug-induced liver injury" coded as two separate PTs doubles the count; three distinct symptoms collapsed into one PT hides them. Either way the incidence table in the CSR stops matching the narratives, and the reviewer notices before you do.
Freezing the MedDRA version and never re-versioning
Terms are retired and concepts move between hierarchy levels at each release. A database left on a superseded version produces SOC-level counts that no longer reconcile with the agency's own coded view of the same cases, and the discrepancy surfaces during a periodic report review rather than at a moment of your choosing.
When This Matters
- Code the verbatim to the most specific LLT; do not jump straight to the PT you think the investigator meant.
- Every AE listing in the CSR needs the MedDRA version stamped on it, or the reviewer cannot reproduce the counts.
- That hepatic imbalance only appears because half the database is still coded on the old MedDRA version.
Frequently Asked Questions
The ICH-appointed MedDRA Maintenance and Support Services Organization (MSSO) maintains the terminology under ICH governance. The MSSO issues versioned releases, adjudicates change requests submitted by subscribers, and publishes the coding guidance. Users license MedDRA through the MSSO rather than downloading it freely, and regulators and sponsors work from the same released version.
Related Use Cases
Related Regulatory Intelligence
Related Actions
- Lifecycle Management
Track every sequence operation, amendment, and supplement across the product lifecycle.
- Regulatory Intelligence
Monitor FDA, EMA, ICH, and Health Canada guidance changes across active programs.
- Regulatory Affairs Software
Plan, validate, and execute active submissions in one workspace.
