QPPV.COM

MedDRA Coding in Pharmacovigilance: A Practical Guide

Explains how MedDRA is structured and how pharmacovigilance professionals should translate source information into accurate, consistent MedDRA terms without adding or losing clinical meaning.

Take test

MedDRA Coding in Pharmacovigilance: A Practical Guide

MedDRA coding converts reported clinical information into a standardised terminology that can be transmitted, aggregated and analysed consistently across pharmacovigilance systems. The apparent task is simple: select a term that matches the source wording. The actual task is more demanding because the coder must preserve the reporter's meaning, choose the correct level of specificity, avoid unsupported interpretation and understand how the selected term will behave in the MedDRA hierarchy during retrieval and analysis.

A well-coded case should allow two things to happen at the same time:

  1. the individual case should remain medically faithful to what was reported;
  2. the coded data should aggregate meaningfully with similar cases.

Poor coding can damage both objectives. Over-interpretation can manufacture a diagnosis that the reporter never made. Under-specific coding can dilute a signal. Inconsistent coding of the same clinical concept can fragment case series across several Preferred Terms. Failure to account for MedDRA version changes can alter counts over time even when the underlying case population has not changed.

The current ICH-endorsed MedDRA Term Selection: Points to Consider therefore treats term selection as a controlled medical-coding activity rather than a clerical lookup exercise.

Purpose and Scope

This article explains practical MedDRA term selection in post-authorisation pharmacovigilance and ICSR processing.

It focuses on:

Standardised MedDRA Queries are important enough to warrant their own article. They are therefore introduced only where needed to explain why coding quality affects retrieval.

Regulatory and Methodological Framework

MedDRA is the Medical Dictionary for Regulatory Activities, developed under ICH for coding regulatory information relating to human medical products.

In EU ICSR reporting, adverse reactions and events are transmitted using MedDRA terminology. Current GVP Module VI directs users to provide an appropriate MedDRA term at the reaction/event level and to follow the latest ICH-endorsed MedDRA Term Selection: Points to Consider.

The main methodological sources are:

These documents are guidance and terminology standards. They are not themselves EU legislation. EU reporting obligations arise from the applicable pharmacovigilance legal framework and GVP/EudraVigilance requirements.

What MedDRA Coding Actually Does

The source may say:

“The patient became very dizzy, collapsed and was admitted overnight.”

The case processor first determines what clinical concepts were actually reported. MedDRA coding then represents those concepts using standardised terms.

The coding process should therefore be understood as:

Source verbatim → clinical concepts identified → most appropriate current LLT selected → linked PT and hierarchy inherited → coded data stored/transmitted → later aggregation and retrieval

The coder should not start from the signal category they expect to see later.

For example, if the source reports “dizziness” and “collapse” but no diagnosis of syncope, the coder should not silently convert the case into a diagnosis merely because “syncope” seems clinically plausible.

The Five-Level MedDRA Hierarchy

MedDRA is organised into five levels:

System Organ Class (SOC) ↓ High Level Group Term (HLGT) ↓ High Level Term (HLT) ↓ Preferred Term (PT) ↓ Lowest Level Term (LLT)

Each level has a different function.

Lowest Level Term

The LLT is the level used for term selection and data entry.

LLTs include:

The MTS:PTC states that the LLT that most accurately reflects the reported verbatim information should be selected.

The coding objective is therefore not “find a PT that looks close”. It is “find the current LLT that best represents the source”.

Preferred Term

A Preferred Term (PT) represents a distinct medical concept used for consistent aggregation, display and analysis.

Several LLTs can map to the same PT.

For example, source expressions that differ linguistically may aggregate under one clinically meaningful PT.

This is why coding at LLT level preserves source specificity while PT-level outputs support analysis.

High Level Term

An HLT groups related PTs.

HLTs are useful for broader clinical grouping but are generally not used as the primary data-entry level.

High Level Group Term

An HLGT groups related HLTs into a still broader clinical category.

System Organ Class

The SOC is the highest level of the hierarchy.

SOCs provide broad groupings such as:

The SOC is useful for high-level presentation, but direct SOC-level review can miss important clinical patterns if used without understanding MedDRA's multiaxial structure and granularity.

Core Term Selection Principles

Why the LLT Matters

The LLT carries the closest representation of the reporter's wording.

Consider the difference between:

All four concern the mouth, but they do not describe the same clinical concept.

Selecting a broad term because it is convenient can erase meaning at the point of coding.

The MTS:PTC therefore gives three core instructions:

The last instruction is particularly important because terms that appear linguistically similar may sit under different PTs and produce different analytical consequences.

Current and Non-Current LLTs

MedDRA retains some terms as non-current LLTs to preserve historical data and terminology continuity.

A non-current LLT should not be selected for new coding.

If a legacy case is already coded to a term that later becomes non-current, the organisation's versioning strategy determines how it is handled. That is different from using the obsolete term for a new case.

A coding system should therefore prevent or clearly warn against selection of non-current LLTs.

Check the Hierarchy, Not Only the Words

A search result can look correct lexically but still represent the wrong concept.

The coder should inspect:

This hierarchy check helps detect:

MedDRA coding is therefore not simply text matching.

Multiaxiality

MedDRA is multiaxial.

A PT can be linked to more than one SOC when the concept is medically relevant in more than one classification.

For example, an infectious respiratory condition may be relevant both to:

MedDRA assigns one SOC as the primary SOC and the others as secondary SOCs.

The primary SOC is used for standard cumulative presentation and prevents double counting when all SOCs are displayed.

Secondary links remain important for retrieval.

This has a direct consequence for pharmacovigilance:

A signal may not be visible where a reviewer intuitively expects it if the reviewer looks only at one SOC path.

Coding quality and retrieval strategy therefore have to be considered together.

Coding Is Not Causality Assessment

MedDRA coding records what was reported.

It does not decide whether the medicine caused the event.

If the reporter states:

“Patient developed pneumonia while taking Product X, but the doctor considered it unrelated.”

the pneumonia should still be coded if it is part of the reported case.

The causality assessment belongs in the appropriate case fields.

The MTS:PTC specifically advises users to select terms for all reported adverse events/reactions regardless of causal association.

The same separation applies to seriousness, expectedness and listedness.

These are distinct regulatory assessments.

Coding Is Not Medical Diagnosis

The coder may recognise a likely diagnosis from the source information.

That does not permit the coder to create that diagnosis if it was not reported or medically established according to the source.

For example:

“Severe upper abdominal pain with raised amylase and lipase.”

may suggest pancreatitis.

If pancreatitis was not reported as a diagnosis, coding the symptoms and investigation abnormalities is more faithful than creating an unreported diagnosis.

This principle—do not add information—is one of the most important protections against coding-driven distortion of the safety database.

The Practical Coding Question

For each source statement, the coder should ask:

  1. What exactly was reported?
  2. Is there a diagnosis, a sign/symptom, an investigation result, an outcome, a product-use issue or another concept?
  3. Is the concept definitive or provisional?
  4. What is the most specific current LLT that represents it?
  5. Does the hierarchy confirm the intended meaning?
  6. Am I adding any medical information that is not present in the source?
  7. Am I omitting any reported concept that should be coded?

The rest of the article applies this method to the situations that cause the most coding inconsistency.

Coding Clinical Information

Diagnoses, Signs and Symptoms

One of the most common coding decisions is whether to code:

The answer depends on what the source actually says and whether the diagnosis is definitive or provisional.

Definitive Diagnosis With Characteristic Signs and Symptoms

When the source reports a definitive diagnosis together with signs or symptoms that are characteristic of that diagnosis, the MTS:PTC preferred approach is generally to code the diagnosis rather than separately coding every associated manifestation.

For example:

“The patient was diagnosed with community-acquired pneumonia after developing fever, cough and shortness of breath.”

If pneumonia is stated as the diagnosis, coding the diagnosis preserves the medical conclusion already provided by the source.

Coding every characteristic symptom as a separate reaction can artificially multiply the apparent number of events in the case.

However, a symptom that is clinically distinct, unusually important or not clearly part of the diagnosis may still warrant separate coding.

The coding decision should preserve the reported clinical information rather than apply a mechanical “diagnosis only” rule.

Provisional Diagnosis

The approach changes when the diagnosis is provisional.

Source wording can include:

For a provisional diagnosis accompanied by signs or symptoms, the MTS:PTC preferred option is to code the provisional diagnosis and the reported signs/symptoms.

This protects the case from losing stable clinical facts if the tentative diagnosis later changes.

For example:

“Possible pulmonary embolism; patient had sudden dyspnoea and pleuritic chest pain.”

The source contains both a provisional diagnostic concept and reported manifestations.

The coded case should preserve that uncertainty.

No Diagnosis Reported

If the source gives only signs, symptoms or findings, code those reported concepts.

Do not create a diagnosis based on medical inference.

For example:

“Abdominal pain, amylase elevated and lipase elevated.”

should not automatically become pancreatitis unless the source reports or establishes pancreatitis.

The safety database should represent what is known, not what the coder thinks is most likely.

Preserve the Reporter’s Level of Specificity

A coding system should neither broaden nor narrow the source without justification.

Consider:

“Pain in the right knee.”

If a specific LLT exists that reflects right-knee pain, that term may better preserve the source than a broad musculoskeletal pain term.

Conversely:

“Joint pain.”

should not be converted into knee pain merely because the patient's history mentions knee disease elsewhere in the case.

Context can help interpret meaning, but it should not be used to invent specificity that the source did not provide.

Ambiguous Wording

Some source expressions can legitimately have more than one interpretation.

Examples include:

The coder should first look for clarifying information in the case.

If the ambiguity materially affects coding and follow-up is possible, clarification may be appropriate.

If clarification is not available, select the term that best reflects the information without adding unsupported meaning.

A vague source should generally remain vague in coding rather than becoming artificially precise.

Abbreviations

Abbreviations can create significant coding errors because the same letters can represent different concepts.

For example, an abbreviation may refer to:

Organisation-specific coding procedures should define how ambiguous abbreviations are handled.

A safe approach is:

  1. use the context;
  2. consult accepted medical usage;
  3. avoid unsupported expansion;
  4. request clarification where feasible if the distinction is important.

The coder should not select a specific term simply because one interpretation is more common.

Misspellings and Informal Language

Source data often contain:

MedDRA contains many lexical variants at LLT level, which helps map imperfect source wording to a standard concept.

The coder should still verify that the selected LLT carries the intended meaning.

A near-text match is not enough.

A single letter can change the medical concept, and the MTS:PTC specifically warns that small lexical differences can matter.

Investigations and Laboratory Results

MedDRA includes a dedicated SOC Investigations for:

A laboratory abnormality should not automatically be converted into a disease diagnosis.

For example:

“ALT increased to three times the upper limit of normal.”

should be represented by the appropriate liver-enzyme investigation term if no diagnosis has been reported.

It should not automatically be coded as hepatitis, drug-induced liver injury or liver failure.

Likewise:

“QTc prolonged to 520 ms.”

should be coded to the reported electrocardiographic finding unless an arrhythmia or clinical diagnosis is also reported.

This distinction is important because investigation terms and disorder terms may aggregate differently during analysis.

Normal Results

Normal results may matter in selected contexts but should not be coded routinely merely because they appear in the source.

Coding should focus on information relevant to the case and the organisation's controlled procedure.

For example, if a laboratory result is explicitly reported as normal to rule out an important differential diagnosis, it may be useful in narrative interpretation but may not need to be coded as a reaction/event.

The purpose of MedDRA coding is not to reproduce the entire medical record as reaction terms.

Increased, Decreased and Abnormal

The direction of an abnormal investigation should be preserved when known.

If the source says:

“serum potassium was low”

the coding should reflect a decreased potassium measurement rather than a generic “potassium abnormal” concept where a more specific current LLT is available.

If the source says only:

“potassium abnormal”

the coder should not infer whether it was increased or decreased.

Specificity should follow the source.

Diagnoses Established After Initial Reporting

A case may begin with symptoms and later receive a definitive diagnosis.

Example:

Initial report:

“Chest pain and shortness of breath.”

Follow-up:

“CT pulmonary angiography confirmed pulmonary embolism.”

The follow-up may justify coding the definitive diagnosis.

The organisation's coding procedure should define whether earlier symptom terms remain coded or whether the case is recoded according to the final diagnosis, consistent with the MTS:PTC and the need to preserve reported information.

The case history should make the evolution visible.

Coding changes should not erase the fact that the diagnosis was established later.

Death and Other Patient Outcomes

Death, hospitalisation and disability are generally outcomes or seriousness criteria, not adverse events in themselves.

If the source reports:

“The patient developed myocardial infarction and died.”

the myocardial infarction is the event. Death is captured as the outcome and seriousness criterion.

A separate death term is not usually needed merely because the case was fatal.

If death is the only clinical information reported, however, the most specific available death term should be selected.

Similarly, if the source says only:

“The patient was hospitalised.”

and no underlying event is described, a hospitalisation term may be the only available concept.

The distinction matters because coding an outcome as though it were an additional event can distort event counts.

Death Terms That Carry Clinical Meaning

Some death-related terms communicate more than the outcome alone.

For example, a source may report:

Where the death concept itself adds important clinical information, coding that concept may be appropriate in addition to other reported events.

The key question is whether the term represents a clinically meaningful event, not merely the fact of death.

Procedures Versus Conditions

A procedure is not the same as the condition for which it was performed.

For example:

“The patient underwent dialysis.”

does not by itself establish renal failure.

The case may contain enough context elsewhere to establish the underlying diagnosis, but the coder should not infer the disease solely from the procedure.

MedDRA includes SOC Surgical and medical procedures for procedural concepts.

The source should determine whether the procedure, the underlying condition, or both are appropriate to code.

Medical History Versus Current Event

A patient's history can contain diagnoses identical to current adverse events.

For example:

“History of migraine; developed severe headache after treatment.”

The historical migraine and the current headache are different data concepts.

The coder should avoid accidentally coding the historical diagnosis as the current reaction.

Safety databases typically provide separate fields for:

MedDRA can be used in all of these contexts, but the data field determines the meaning.

This is why coding accuracy depends not only on selecting the right term but also on placing it in the right case context.

Indication Versus Adverse Event

The same MedDRA term can appear as:

For example, “hypertension” may be:

The source chronology and case context determine which role it plays.

A quality review should therefore assess both:

  1. the selected term;
  2. the field in which it was coded.

More Than One Term

Sometimes a source concept cannot be represented adequately by a single MedDRA term.

The MTS:PTC allows more than one LLT to be selected where necessary, but warns that multiple coding can create redundant counts.

For example, a complex concept may contain:

If no single MedDRA term captures all of it, more than one term may be needed.

The organisation should have a consistent policy for such situations.

If a genuinely missing concept is likely to recur, a MedDRA change request may be more appropriate than a permanent organisation-specific workaround.

When to Request a New MedDRA Term

If no existing term adequately represents the reported concept, the MTS:PTC recommends submitting a change request to the MSSO rather than altering the MedDRA hierarchy or inventing local terminology.

This preserves standardisation.

A local “custom MedDRA term” may solve one immediate coding problem but create larger problems for:

The terminology should remain standard; local procedures should explain how to handle gaps while a formal change request is considered.

Special Situations and Product-Use Concepts

MedDRA is not limited to adverse-event diagnoses and symptoms. It also contains terminology for product-use circumstances that are important to pharmacovigilance, including:

These concepts should be coded according to what was reported, with clinical consequences coded separately when appropriate.

Medication Errors

For MedDRA term selection, medication errors are unintentional and preventable events that may cause or lead to inappropriate medication use or patient harm while the medicine is under the control of a healthcare professional, patient or consumer.

The coding principle is:

code the error that was reported, together with its clinical consequences.

For example:

“The patient was accidentally given the wrong medicine and became hypotensive.”

contains two concepts:

Both should be represented.

The error describes what happened in medicine use. The hypotension describes what happened clinically.

Capture the Error Stage

Medication errors can occur at different stages:

Where the source identifies the stage, coding should preserve it.

Consider:

“The doctor prescribed 100 mg instead of 10 mg, but the pharmacist identified the error before dispensing.”

The important concepts include:

The coder should not transform the scenario into a dispensing error merely because the pharmacist discovered it.

Do Not Infer a Medication Error

The MTS:PTC specifically warns against inferring medication errors.

For example:

“The patient took half the recommended dose.”

does not establish whether the lower dose was:

If the source does not establish intent, select a term that reflects what is actually known rather than assuming an error.

Likewise:

“Dose exceeded the usual maximum.”

may support an overdose concept if the source information establishes that an excessive dose was taken, but it should not automatically be coded as an accidental medication error unless the circumstances support that conclusion.

Medication Error With No Clinical Consequence

Medication errors can be pharmacovigilance-relevant even when no adverse event occurs.

If the source specifically states that an error occurred without clinical consequences, the preferred MTS:PTC approach is generally to code the medication error itself.

An additional “no adverse effect” concept can be used according to the organisation's coding convention where appropriate.

For example:

“The medicine was administered by the wrong route, but the patient had no symptoms.”

The primary coding objective is to capture the wrong-route medication error.

The absence of harm does not erase the error.

Potential and Intercepted Medication Errors

MedDRA includes terminology for potential medication errors and intercepted errors.

These are distinct concepts.

A potential medication error describes a circumstance that could lead to an error even though the error has not occurred.

An intercepted medication error describes an error that occurred in the medication-use process but was prevented from reaching the patient.

The coding should preserve the stage at which the error occurred, not merely the stage at which somebody noticed it.

This distinction is important for prevention analysis because:

have different corrective actions.

Overdose

MedDRA term-selection guidance defines overdose for coding purposes as exposure above the maximum recommended dose in quantity and/or concentration.

If overdose is explicitly reported or clearly established by the source, code the overdose concept.

Where intent is known, a more specific concept such as:

may be appropriate.

Where intent is not known, do not infer it.

Overdose With a Clinical Event

If an overdose is reported with a clinical consequence, code both.

For example:

“The patient accidentally took twice the prescribed quantity and developed profound somnolence.”

The case contains:

The overdose is the product-use circumstance; the somnolence is the clinical event.

Overdose Without a Clinical Event

If the report explicitly states that an overdose occurred without clinical consequences, the overdose term remains important.

The absence of an adverse event does not make the overdose disappear from the coded safety record.

As with medication errors, organisations may choose to capture a “no adverse effect” concept according to their controlled coding convention.

Misuse, Abuse and Addiction

Misuse, abuse and addiction have distinct meanings and should not be coded interchangeably.

The coding decision should reflect:

A patient deliberately using a medicine for a therapeutic purpose in a manner not intended by the product information may represent misuse.

Use for a non-therapeutic purpose may represent abuse.

Addiction is a clinical concept and should not be inferred merely from repeated use or dose escalation without supporting information.

The case narrative and source should support the selected term.

Off-Label Use

Off-label use should be handled carefully because authorised product information differs by region and can change over time.

The MTS:PTC describes off-label use as intentional prescribing, dispensing or recommendation by a healthcare professional for a medical purpose not in accordance with the authorised product information.

Where off-label use is explicitly reported, the appropriate off-label concept can be coded.

If the indication is known, the coding should preserve both:

If an adverse event occurs, the clinical event is coded as well.

For example:

“Product X was prescribed off label for Condition Y and the patient developed atrial fibrillation.”

contains three potentially relevant concepts:

Suspected Off-Label Use

The MTS:PTC also recognises that off-label use may sometimes be suspected based on medical knowledge even when the words “off label” are not explicitly stated.

That judgment requires:

This is not a licence to label every unusual treatment as off label.

Regional authorisations differ, and the indication, age, dose, route or population may be authorised in one region but not another.

Pregnancy and Breastfeeding Exposure

Pregnancy-related reports require careful coding because the exposure itself and any clinical consequences are separate concepts.

The first question is:

who was exposed?

Potentially relevant subjects include:

Exposure With Clinical Consequences

If a pregnancy or breastfeeding exposure is reported with a clinical event, the MTS:PTC recommends representing both the exposure and the event.

For example:

“The patient continued Product X during pregnancy and developed a generalised rash.”

contains:

Similarly:

“The infant was exposed through breast milk and developed vomiting.”

contains:

Coding only the event can lose the important exposure context.

Coding only the exposure can lose the clinical consequence.

Exposure Without Clinical Consequences

If pregnancy exposure is reported with no adverse outcome, the exposure itself may still be coded.

The preferred approach is generally to represent the exposure concept.

An additional “no adverse effect” term can be used according to organisational convention when the absence of a clinical consequence is specifically reported.

Congenital Conditions

If a condition is described as congenital or is medically established as present at birth, the coding should reflect the congenital concept where available.

The coder should not assume that every condition in a newborn is congenital merely because it was detected soon after birth.

Conversely, a condition explicitly stated to be congenital should not be represented with a generic acquired term merely because that wording is more familiar.

The hierarchy should be checked because congenital concepts commonly have a primary link to SOC Congenital, familial and genetic disorders even when the anatomical manifestation belongs to another SOC.

Product-Quality Issues

MedDRA contains terminology for product-quality problems within SOC Product issues.

These can include issues involving:

A product-quality issue may occur:

Product Quality Issue With a Clinical Event

If a patient reports that a product defect caused a clinical problem, code both the quality issue and the clinical consequence where appropriate.

For example:

“The prefilled syringe leaked, the patient received only part of the dose, and symptoms of the underlying disease worsened.”

The case may contain:

The pharmacovigilance and quality systems may then need to manage the same source information through different workflows.

Product Quality Issue Versus Medication Error

These concepts should not be collapsed.

A product-quality issue concerns an abnormality introduced through manufacturing, labelling, packaging, shipping, handling or storage.

A medication error concerns unintentional, preventable inappropriate medicine use.

Sometimes both are present.

For example, an unreadable dosing device can be a product-quality issue that contributes to an accidental dosing error.

Coding both concepts may be necessary to preserve the full causal chain reported.

Device-related product presentations can generate both device issues and clinical consequences.

If one MedDRA term accurately captures both, that term may be sufficient.

If not, separate terms may be needed.

For example:

“The delivery device malfunctioned and the patient developed ventricular tachycardia.”

may require representation of:

The coding should distinguish the device problem from the patient outcome.

Drug Interactions

If the reporter explicitly states that a drug interaction occurred, code the interaction and any reported clinical consequence.

For example:

“The reporter considered an interaction between Product X and Product Y responsible for a marked INR increase.”

may contain:

Do not infer an interaction merely because two medicines were taken together and an event followed.

Temporal coexistence is not the same as a reported interaction.

Lack of Effect

Lack of effect can be clinically and pharmacovigilance-relevant, but it should not be inferred merely because a disease worsened.

If the source explicitly reports:

select the most appropriate term.

If the patient deteriorated but the reporter did not state that the medicine failed, the clinical deterioration should be coded as reported rather than converting it automatically into lack of efficacy.

The distinction matters because lack-of-effect terms can be retrieved separately in aggregate analysis.

“No Adverse Effect”

MedDRA includes a “no adverse effect” concept that can be useful where the absence of harm is explicitly reported.

Common contexts include:

The concept should not be added routinely to every case in which no reaction is mentioned.

Its use should follow the MTS:PTC and a documented organisation-specific convention.

The General Rule Across Special Situations

The recurring pattern is:

Reported circumstance + Reported clinical consequence = Code both where the terminology and guidance support both concepts.

But:

Unstated circumstance + Coder inference = Do not create a new concept merely because it seems plausible.

This distinction protects the database from systematic over-coding.

Versioning: Coding Changes Even When the Case Does Not

MedDRA is not static.

The terminology is updated twice each year:

The March release can contain both simple and more complex hierarchy changes. The September release is more limited and contains simple changes.

Changes can include:

This means that the same source verbatim can map differently across MedDRA versions.

Released Version Versus Reporting Version

The newest MedDRA package is not automatically the version that should be used for ICSR reporting on the day it becomes available.

MSSO publishes transition dates so senders and receivers can move to a new version in synchrony.

As of this article's review date, 1 October 2026:

Until the applicable transition, an organisation may still need to report using the prior operational version.

This distinction is important:

latest available terminology ≠ current reporting version in every regulatory exchange

Organisations should verify the current MedDRA version accepted by the relevant regulatory system, including EudraVigilance, rather than assuming that a newly released package should be deployed immediately into production reporting.

Why Version Changes Matter

Version changes can alter:

Suppose a concept previously coded to a broad PT receives a new, more specific LLT or PT in a later version.

New cases may then code more specifically than old cases.

If the historical data are not recoded, a retrieval based only on the new term can miss earlier cases.

Conversely, recoding historical cases can shift counts between PTs even though no new patients were added.

A trend chart can therefore change because the terminology changed, not because the safety profile changed.

Organisation-Specific Versioning Strategy

The MedDRA Points to Consider material recommends that organisations document a versioning strategy.

Different approaches can be used, ranging from:

The appropriate approach depends on:

The strategy should be explicit.

A safety database should not drift into mixed-version behaviour merely because different teams upgraded at different times.

Current and Historical Data

An organisation may legitimately hold cases coded under several MedDRA versions.

The key is to understand what that means during retrieval.

For example:

If aggregate analysis spans several years, version alignment must be considered before interpreting counts.

The MedDRA Version Analysis Tool (MVAT) and version reports are designed to help users understand these changes.

Query Version Must Match Data Version

The MedDRA Data Retrieval and Presentation PTC warns that query terms should be aligned with the version of the data being searched.

A query built from the newest terminology can miss cases coded under older structures.

This matters for:

The analyst should know:

  1. what version the cases were coded in;
  2. what version the retrieval terms were built in;
  3. whether historical terms need mapping or recoding.

This is one reason coding and signal detection cannot be treated as independent disciplines.

Coding Quality

Coding quality has three dimensions:

Medical Accuracy

Does the selected term represent the source correctly?

Consistency

Would comparable source information be coded similarly across:

Traceability

Can a reviewer understand why the selected term was chosen?

A technically valid MedDRA code can still be poor coding if it does not accurately represent the source.

Organisation-Specific Coding Guidelines

The MTS:PTC encourages organisations to document their term-selection methods and quality-assurance procedures in coding guidelines consistent with the ICH-endorsed guidance.

A useful organisation-specific guideline can address:

The local guideline should clarify the global standard rather than override MedDRA.

If a local procedure requires a coding choice inconsistent with MTS:PTC, the organisation risks creating data that are internally consistent but externally non-standard.

Qualified Review

The MTS:PTC recommends that term selection be reviewed by a qualified individual with:

This does not necessarily mean every individual term must be approved by a physician.

The control model can be risk based.

For example, an organisation may combine:

The important point is that coding quality requires medical understanding, not merely familiarity with the browser.

Auto-Coding

Automated coding systems can improve consistency and speed, particularly for common verbatim terms.

They can also propagate systematic errors at scale.

The current MTS:PTC specifically states that human oversight of term selection performed by IT tools such as autoencoders is needed to ensure that the result reflects the reported information and makes medical sense.

The appropriate workflow is therefore:

source text → automated suggestion → context-aware review → final LLT selection

rather than:

source text → exact/AI match → automatic permanent coding

without review.

Why Auto-Coding Fails

Common failure patterns include:

Lexical Match Without Clinical Context

Source:

“Patient denies chest pain.”

An automated system may detect “chest pain” and code it as an event unless negation is understood.

Historical Condition Misclassified as Current Event

Source:

“Past history of seizure disorder; developed nausea after treatment.”

A model may code both seizure and nausea as current adverse events.

Diagnosis Inferred From Findings

Source:

“AST and ALT elevated.”

A model may infer hepatitis or liver injury.

Ambiguous Abbreviation

Source:

“MS worsened.”

The intended meaning may depend entirely on context.

Wrong Field

A correct MedDRA term can still be placed incorrectly as:

Automation therefore needs access to case context, not just isolated strings.

Quality-Control Review

Coding QC should evaluate both term selection and data placement.

A reviewer can ask:

This approach is more useful than a QC check limited to “is the code valid?”.

Inter-Coder Consistency

If different coders repeatedly select different terms for equivalent source information, aggregate data become fragmented.

Variation may arise from:

Periodic comparison of coding decisions can identify such variation.

The purpose is not to force every case into one term regardless of context.

It is to determine whether variation reflects genuine source differences or inconsistent coding practice.

Vendor Coding

Outsourced case-processing vendors should work from the same coding principles as the MAH.

Useful controls include:

A vendor can meet case-processing turnaround times while still degrading the safety database through inconsistent coding.

Quality oversight should therefore evaluate the medical output, not only speed.

Translation and Coding

Translated source information creates an additional layer.

The ideal sequence is:

original source → medically accurate translation → MedDRA coding

The coder should have access to the original wording when needed, especially where:

MedDRA itself is multilingual, but multilingual terminology does not remove the need to understand the source meaning.

Coding Corrections

A coding error discovered during QC can be corrected without new source information.

For example:

The correction should be traceable.

A coding correction is not automatically new medical follow-up and should not be treated as though a new reporter statement was received.

The audit trail should distinguish:

source changed from internal interpretation corrected.

Follow-Up Can Require Recoding

New source information may legitimately change coding.

For example:

Initial:

“Severe abdominal pain.”

Follow-up:

“CT and surgery confirmed appendicitis.”

The later definitive diagnosis can change the appropriate coding representation.

The organisation's procedure should define how the case is updated while preserving:

Recoding should improve fidelity to the current evidence, not erase the history of how the case evolved.

Coding and Signal Detection

MedDRA coding directly shapes signal-detection datasets.

If similar clinical events are coded inconsistently to several PTs, a true pattern may be diluted.

If broad terms are used when specific terms were available, the signal may lose clinical definition.

If one concept is routinely over-coded into several event terms, counts may be inflated.

The effect can be represented as:

source information → coding choice → PT distribution → retrieval strategy → case series → signal interpretation

Every downstream analysis inherits the coding decisions made during case processing.

Granularity Can Dilute a Signal

MedDRA is deliberately granular.

That is valuable because it preserves clinical precision.

It also means that related manifestations may appear under multiple PTs.

A safety reviewer looking only for one PT can therefore miss:

This is why signal detection may require:

The solution is not to code all cases broadly.

The solution is to code accurately and retrieve intelligently.

Multiaxiality and Retrieval

A PT can appear under several SOCs through multiaxial links, but only one is primary.

A primary-SOC summary prevents double counting and is useful for standard presentation.

A targeted safety analysis may need to examine secondary links as well.

For example, a PT whose primary SOC is based on aetiology may also have a secondary link to the organ system where the clinical manifestation occurs.

The analyst who looks only at the organ-system primary SOC could miss it.

This is a retrieval problem, not a reason to alter the MedDRA hierarchy.

Never Alter the MedDRA Hierarchy Locally

The MTS:PTC explicitly advises users not to make ad hoc structural changes to MedDRA.

Do not:

If the terminology appears wrong or incomplete, use the MSSO change-request process.

Local structural modification destroys the standardisation that MedDRA is designed to provide.

Practical Coding Workflow

A reliable coding process can be organised into seven steps.

Step 1 — Read the Full Source Context

Do not code from an isolated phrase if the full case changes its meaning.

Determine whether the concept is:

Step 2 — Identify Each Reported Medical Concept

Separate the source into discrete concepts without yet selecting terms.

For example:

“The patient accidentally took a double dose and became dizzy.”

contains:

Step 3 — Determine Certainty

Ask whether a diagnosis is:

This determines how signs and symptoms should be handled.

Step 4 — Search for the Most Specific Current LLT

Use the MedDRA browser or controlled coding tool.

Do not stop at the first lexical match.

Review synonyms and more specific terms where appropriate.

Step 5 — Check the Hierarchy

Confirm that the LLT maps to the intended:

This catches many apparently plausible but clinically incorrect matches.

Step 6 — Check for Missing or Added Information

Ask:

Step 7 — Review the Case as a Whole

Look for consistency between:

The final coding should make medical sense when the complete case is read.

Worked Example 1 — Definitive Diagnosis

Source:

“The patient was diagnosed with bacterial pneumonia after fever, productive cough and dyspnoea.”

The source contains a definitive diagnosis and characteristic manifestations.

Coding approach

The preferred approach is to code the diagnosis rather than multiplying the reaction list with every characteristic symptom.

Why

The source has already provided the clinical synthesis.

Separate coding of every manifestation can overstate the number of distinct events.

Worked Example 2 — Provisional Diagnosis

Source:

“Possible pulmonary embolism. The patient developed sudden dyspnoea and pleuritic chest pain.”

Coding approach

Represent:

Why

The diagnosis remains uncertain. The symptoms are established reported facts and should not disappear if the provisional diagnosis changes later.

Worked Example 3 — Laboratory Abnormalities Without Diagnosis

Source:

“ALT and AST were elevated. No diagnosis of hepatitis was made.”

Coding approach

Represent the reported liver-enzyme increases.

Do not create hepatitis.

Why

The coder should not convert investigation results into an unreported diagnosis.

Worked Example 4 — Seriousness Is Not an Extra Event

Source:

“The patient developed acute myocardial infarction, was admitted to hospital and died.”

Coding approach

Represent myocardial infarction as the event.

Capture:

in the appropriate seriousness/outcome fields.

Why

Hospitalisation and death are generally outcomes or seriousness criteria, not additional adverse events.

Worked Example 5 — Medication Error With Consequence

Source:

“The patient accidentally injected a second dose and developed symptomatic hypoglycaemia.”

Coding approach

Represent:

Why

The use error and clinical consequence are separate medically relevant concepts.

Worked Example 6 — Medication Error Without Consequence

Source:

“The medicine was administered by the wrong route, but the patient experienced no adverse effect.”

Coding approach

Represent the wrong-route error.

An additional “no adverse effect” concept may be used according to the organisation's coding convention.

Why

Absence of injury does not remove the medication error from the safety record.

Worked Example 7 — Pregnancy Exposure

Source:

“The patient continued Product X during pregnancy and developed urticaria.”

Coding approach

Represent:

Why

The exposure context and clinical event are both relevant.

Worked Example 8 — Product Quality and Clinical Consequence

Source:

“The injector failed to deliver the full dose and the patient's symptoms worsened.”

Coding approach

Assess and represent, according to the source:

Why

The case may contain several linked but distinct concepts. The coder should preserve the reported chain rather than collapse everything into one event.

Worked Example 9 — Off-Label Use

Source:

“The physician prescribed Product X off label for Condition Y; the patient subsequently developed atrial fibrillation.”

Coding approach

Represent:

Why

Use circumstance, indication and adverse event answer different analytical questions.

Worked Example 10 — Ambiguous Source

Source:

“The medicine made my heart feel strange.”

Coding approach

Do not invent an arrhythmia diagnosis.

Review the rest of the source and seek clarification where feasible.

If no clarification is available, select the most faithful concept supported by the wording.

Why

Vagueness in the source should not become false precision in the database.

How Coding Errors Affect Pharmacovigilance

Coding problems can create several types of downstream distortion.

Coding problem Potential analytical effect
Diagnosis inferred from symptoms False increase in diagnosis-specific case counts
Broad LLT used despite specific source Loss of clinical discrimination
Over-specific term selected Apparent precision unsupported by source
Same concept coded inconsistently Signal dilution across PTs
Symptoms coded in addition to definitive diagnosis without rationale Event-count inflation
Product-use issue omitted Loss of preventability/use-pattern information
Investigation result converted to disease Artificial disease signal
Historical condition coded as current event False adverse-event case
Non-current LLT used for new case Version inconsistency
Wrong field used Misinterpretation despite technically valid term
Query/data versions mismatched Incomplete or distorted retrieval

These are not merely database-cleanliness problems.

They change the evidence seen by:

Coding and Case Narratives

The narrative and coded fields should support one another.

The narrative preserves:

MedDRA provides structured concepts for retrieval.

Neither should be used to compensate for poor quality in the other.

A detailed narrative does not justify inaccurate coding.

Accurate coding does not remove the need for a medically coherent narrative.

Coding and Expectedness

MedDRA coding can influence expectedness assessment because product labels may describe adverse reactions at a different level of clinical specificity.

However, coding and expectedness are separate activities.

A coder should not deliberately select a broader PT simply because it matches the label wording more easily.

The source should be coded accurately first.

Expectedness should then be assessed according to the applicable reference information and company procedure.

Coding and Duplicate Management

Two reports describing the same patient can use different words for the same event.

MedDRA coding can help identify similarities, but duplicate detection should not rely only on PT matching.

For example:

Duplicate assessment should use the whole case:

Coding similarity is supporting evidence, not proof of duplication.

Coding and Follow-Up

Follow-up can:

The coder should therefore re-evaluate coding when medically important follow-up arrives.

A coding field should not be treated as immutable merely because the initial case has already been submitted.

At the same time, the audit trail should show what changed and why.

Inspection Perspective

An inspector assessing MedDRA coding would be interested in whether the organisation produces accurate, consistent and traceable coded data.

Potential questions include:

The evidence should demonstrate effectiveness, not merely the existence of an SOP.

Illustrative Failure Modes

The following are hypothetical examples rather than reported inspection findings.

Coding From the Case Title Only

The coder selects terms from a short intake summary without reviewing the source.

Why it fails: diagnostic uncertainty, history, negation and context can be lost.

First Search Result Wins

The first text match returned by the browser is selected without checking its hierarchy.

Why it fails: lexical similarity does not guarantee clinical equivalence.

Coder Diagnoses the Patient

Abdominal pain plus high lipase is coded as pancreatitis although no diagnosis was reported.

Why it fails: unsupported medical information has been added.

Definitive Diagnosis Plus Every Symptom

A confirmed diagnosis is coded together with every characteristic manifestation without a reason.

Why it fails: the event list can become inflated and analytically misleading.

“Overdose” Automatically Means Medication Error

Every excessive dose is coded as accidental overdose.

Why it fails: intentionality has been inferred.

Every Unusual Use Is Called Off Label

A coder compares the case with one local label and marks use in another country as off label without verifying the relevant authorisation.

Why it fails: regulatory status varies by region and the source context matters.

Auto-Coder Converts Negated History to an Event

“Patient had no history of seizure” becomes a coded seizure reaction.

Why it fails: the tool matched words rather than meaning.

New MedDRA Release Goes Live Immediately

The safety database switches to the September release on release day while the regulatory reporting environment remains on the previous version.

Why it fails: sender/receiver version synchronisation can be lost.

Aggregate Search Uses a Different Version

A signal query contains new PTs but the historical cases were never mapped or recoded.

Why it fails: relevant cases may be missed.

Practical Coding Checklist

Before finalising a coded reaction or event, verify:

Governance

A mature coding system connects four controls:

terminology governance → trained coding practice → case-level quality review → retrieval/signal feedback

The last control is often overlooked.

Signal reviewers can identify coding patterns that case processors cannot see from individual cases, for example:

These observations should feed back into:

Coding quality is therefore part of pharmacovigilance-system learning, not a one-time case-processing activity.

Current Version Note

As reviewed on 1 October 2026, MedDRA Version 29.1 is the latest released version.

MSSO lists 2 November 2026 as the transition date for Version 29.1 for ICSR reporting.

This article intentionally does not say “always use the newest released version immediately”.

The correct production version depends on the applicable reporting environment and controlled transition strategy.

Readers should verify the current MedDRA/MSSO transition information and the version accepted by the relevant regulatory system before production implementation.

Key Takeaways

References

  1. MedDRA Maintenance and Support Services Organization / ICH. MedDRA Term Selection: Points to Consider. ICH-Endorsed Guide for MedDRA Users, Release 4.26. March 2026.
    https://files.meddra.org/www/Website%20Files/PtCs/001329_termselptc_r4_26_mar2026%20%281%29.html

  2. MedDRA Maintenance and Support Services Organization. MedDRA Introductory Guide, Version 29.1. September 2026. Available through the MedDRA support-documentation/download service.
    https://www.meddra.org/

  3. MedDRA Maintenance and Support Services Organization / ICH. MedDRA Data Retrieval and Presentation: Points to Consider, Release 3.26. March 2026.
    https://alt.meddra.org/files_acrobat/001330_datretptc_r3_26_mar2026.pdf

  4. MedDRA Maintenance and Support Services Organization. MedDRA Best Practices — Versioning Methodology. Current support documentation.
    https://www.meddra.org/how-to-use/support-documentation

  5. MedDRA Maintenance and Support Services Organization. MedDRA Version 29.1 release and transition information. September 2026; ICSR transition date 2 November 2026.
    https://www.meddra.org/how-to-use/support-documentation/english/multilingual

  6. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP) Module VI — Collection, management and submission of reports of suspected adverse reactions to medicinal products, Rev. 2. EMA/873138/2011 Rev. 2.
    https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/guideline-good-pharmacovigilance-practices-gvp-module-vi-collection-management-submission-reports-suspected-adverse-reactions-medicinal-products-rev-2_en.pdf

  7. International Council for Harmonisation. ICH E2B(R3): Electronic Transmission of Individual Case Safety Reports. Current ICH E2B(R3) specifications and implementation material.
    https://www.ich.org/page/efficacy-guidelines

Regulatory Note

This article is an educational interpretation of MedDRA term-selection principles and EU pharmacovigilance practice as reviewed on 1 October 2026.

MedDRA is an ICH standard terminology. The ICH-endorsed Points to Consider documents provide methodological guidance for consistent term selection and retrieval; they do not replace applicable EU legislation, GVP, EudraVigilance technical requirements or organisation-specific controlled procedures.

MedDRA is updated regularly. Version numbers, current/non-current terms, hierarchy links, SMQs and transition dates can change. Production systems should therefore verify the current MedDRA release and the version accepted by the applicable regulatory environment rather than relying on the version stated in this article indefinitely.

The coding examples in this article are illustrative. They demonstrate term-selection reasoning rather than prescribing a complete coding decision for every possible case. Actual coding should use the current MedDRA terminology, the full source context and the applicable ICH-endorsed guidance.

Revision History

Related Articles

Day Zero in Pharmacovigilance: When Does the Reporting Clock Start?

Explains when the ICSR reporting clock starts, why Day Zero is not simply the database-entry date, how source-specific rules operate under ICH E2D(R1) and EU GVP, and how to control awareness dates across vendors, partners, literature, digital channels and follow-up.

GVP Module VI Inspection Findings: Common ICSR Case-Processing Deficiencies

A practical inspection-focused guide to recurring weaknesses in individual case safety report processing and the evidence that demonstrates effective control.

GVP Module VI: Case Intake, Triage and Initial Assessment

Explains how potential safety information is received, recognised, logged, dated, triaged and initially assessed under GVP Module VI before validation and case processing.

Last reviewed: 2026-10-01

QPPV.com