QPPV.COM

Standardised MedDRA Queries (SMQs): How and When to Use Them

Explains what SMQs are, how narrow and broad scope differ, how hierarchical and algorithmic SMQs work, when SMQs are useful in pharmacovigilance, and why retrieved cases still require medical review.

Take test

Standardised MedDRA Queries (SMQs): How and When to Use Them

Standardised MedDRA Queries are reusable groupings of MedDRA terms designed to retrieve cases that may represent a defined medical condition or safety topic. They solve a problem created by MedDRA's strength: clinical information is coded with considerable granularity, so a medically coherent case series may be distributed across many Preferred Terms, System Organ Classes and types of coded information.

An SMQ brings those related terms together into a standardised search concept.

The important word is potentially. An SMQ does not diagnose patients and does not prove that every retrieved case represents the condition of interest. It identifies records that are suitable for subsequent evaluation.

This distinction separates two stages that are often confused:

MedDRA-coded data → SMQ retrieval → candidate case set → medical review / defined case evaluation → analysed case series

The value of an SMQ is therefore not that it removes medical judgment. Its value is that it provides a standardised, maintained and reusable starting point for finding cases that may otherwise be fragmented across the terminology.

Purpose and Scope

This article explains how to use SMQs in pharmacovigilance and safety-data analysis.

It covers:

It builds on MedDRA Coding in Pharmacovigilance: A Practical Guide, which explains how source information is coded. The present article begins at the next stage: retrieving related coded concepts for analysis.

What an SMQ Is

The MedDRA SMQ Introductory Guide defines SMQs as groupings of MedDRA terms, ordinarily at the Preferred Term level, relating to a defined medical condition or area of interest.

The terms can represent different clinical dimensions of the same safety topic, including:

An SMQ can therefore retrieve cases that would not be found by searching only for the diagnostic PT.

For example, a patient may have a confirmed diagnosis in one case, while another case contains only a characteristic combination of symptoms and laboratory abnormalities.

A clinically designed SMQ can help retrieve both.

Why SMQs Are Needed

Why MedDRA Hierarchy Searches Alone Are Sometimes Insufficient

A simple SOC or HLT search follows the MedDRA hierarchy.

That can be useful, but a medical syndrome may cross hierarchy boundaries.

A safety concept can include:

An SMQ is constructed around the medical concept, not around one branch of the terminology.

This makes SMQs especially useful where clinically related cases are distributed across several PTs or SOCs.

Standardisation Is the Main Benefit

An organisation can always create its own list of MedDRA terms.

An SMQ adds something different:

The MedDRA Data Retrieval and Presentation PTC identifies these as important benefits of SMQs.

Standardisation improves comparability because two users applying the same SMQ version and scope are starting from the same underlying query logic.

SMQs Are Not Regulatory Diagnoses

Retrieval by an SMQ should not be interpreted as confirmation that the case meets a clinical diagnostic definition.

A broad SMQ intentionally trades specificity for sensitivity.

Even a narrow SMQ is designed for retrieval rather than final adjudication.

The MedDRA Data Retrieval and Presentation PTC therefore advises users to evaluate retrieved cases against the original question and to define criteria for subsequent case evaluation.

This means that a statement such as:

“There were 42 cases retrieved by the SMQ.”

does not necessarily mean:

“There were 42 confirmed cases of the condition.”

The analytical report should make clear what the count represents.

SMQ Development and Maintenance

SMQs were developed through collaboration between CIOMS, ICH and the MedDRA maintenance organisations, with participation from regulators and industry.

The CIOMS working group developed 107 level-1 SMQs before completing its original development pipeline in 2020. Since MedDRA Version 23.1, beginning with the COVID-19 SMQ, MSSO has been responsible for ad hoc development of new topics in coordination with international experts.

SMQs continue to be maintained as MedDRA evolves.

The important operational conclusion is that an SMQ is not a frozen term list copied once into a spreadsheet and reused indefinitely.

Its content is version-dependent.

The SMQ Introductory Guide

Every SMQ has supporting documentation in the MedDRA SMQ Introductory Guide.

Depending on the SMQ, this can describe:

Before applying an unfamiliar SMQ, the analyst should read its guide section rather than treating the SMQ name as a sufficient description.

Two queries with similarly intuitive names can have importantly different structures or limitations.

SMQs Primarily Use Preferred Terms

SMQ content is ordinarily defined using PTs.

This aligns with the role of PTs as the principal analytical level in MedDRA.

If a database stores events at LLT level, retrieval tools need to account for the LLT-to-PT relationship appropriately.

The SMQ content file does not simply repeat every LLT under each included PT.

The implementation therefore depends partly on the data model and query tool.

A safety analyst should understand whether the system is searching:

SMQ Scope Is a Retrieval Choice

Many SMQs offer more than one way to search.

The most common distinction is:

Some SMQs are hierarchical.

Some use algorithms.

One uses weighted categories.

The correct option depends on the question being asked.

The next step is therefore to understand what each search architecture is designed to do.

Narrow and Broad Scope

The narrow/broad distinction is the most common SMQ design feature.

The MedDRA guidance describes the trade-off simply:

A broad search includes the narrow terms plus additional broad terms.

That means the broad result set contains the narrow result set and then expands beyond it.

Narrow Scope

Narrow terms are more specific for the medical condition of interest.

They are useful when the analytical priority is to identify records that are more likely to represent the condition.

Typical reasons to begin with narrow scope include:

Narrow scope does not eliminate false positives.

A retrieved case still needs to be interpreted in context.

Broad Scope

Broad terms are less specific but improve sensitivity.

They can retrieve cases in which:

This can be particularly useful for:

The cost is noise.

A broad search can retrieve many cases that do not represent the condition after medical review.

Sensitivity and Specificity Are Analytical Choices

There is no universal rule that narrow is “better” than broad.

The correct scope depends on the purpose.

Consider a suspected safety issue where missing a possible case would be more problematic than reviewing extra cases.

A broad search may be appropriate.

Consider instead a high-volume database where the objective is to trigger immediate review of only highly relevant incoming cases.

A narrow scope may be more practical.

The analyst should therefore document:

Broad Search Does Not Mean “Broad PTs Only”

By definition, the broad search includes:

narrow terms + broad terms

This is a frequent implementation error.

If a tool searches only terms labelled “broad” and excludes the narrow terms, it is not performing the standard broad SMQ search.

The broad result should be the union of both scopes.

Example: Lactic Acidosis

MedDRA guidance uses lactic acidosis to illustrate the narrow/broad trade-off.

A narrow search can identify cases where the specific condition is represented directly.

A broad search can additionally retrieve cases containing related findings or manifestations where the formal diagnosis was not coded.

The broad result therefore increases the chance of finding incompletely characterised cases.

It also increases the amount of medical review required.

Case Review Should Be Planned Before Retrieval

An SMQ search should not end with a case count.

Before running the query, define what happens to the output.

Possible next steps include:

The evaluation method should match the purpose.

A signal-detection screen may need a different review process from a formal cumulative safety analysis.

Hierarchical SMQs

Some SMQs contain sub-SMQs organised in a hierarchy.

This gives the analyst flexibility to retrieve:

The structure is conceptually similar to using a broad clinical umbrella with several more specific branches.

Why Hierarchy Matters

Suppose the safety question concerns only thrombocytopenia.

A superordinate haematopoietic-cytopenia SMQ may also include:

Using the entire hierarchy could therefore be unnecessarily inclusive.

Selecting the specific thrombocytopenia sub-SMQ is more aligned with the question.

The MedDRA DRP:PTC uses this type of example to show why analysts should not automatically apply the highest-level SMQ.

Superordinate and Subordinate Queries

A hierarchical SMQ can contain:

The correct implementation depends on the SMQ documentation.

Some sub-SMQs are designed for standalone use.

Others should be interpreted only within the superordinate structure.

The Introductory Guide should therefore be checked before extracting one branch.

Hierarchical SMQs Prevent Unnecessary Dilution

Hierarchy is especially useful where one broad medical area contains clinically distinct subconditions.

A safety signal may become diluted if unrelated subtopics are combined.

For example:

specific clinical question → select relevant sub-SMQ

rather than:

specific clinical question → retrieve entire superordinate SMQ → review large unrelated case set

The hierarchy allows the query to remain standardised without forcing every analysis to use the maximum scope.

Algorithmic SMQs

Some SMQs use an algorithm.

The purpose is to identify cases that may not contain a definitive narrow diagnostic term but contain a meaningful combination of broader findings.

In an algorithmic SMQ:

This is fundamentally different from searching all broad terms independently.

Why Algorithms Exist

A single broad term can be non-specific.

For example:

Each on its own may occur in many unrelated clinical situations.

A specific combination within the same case can be much more suggestive of the medical condition.

An algorithm therefore uses co-occurrence to improve specificity while retaining sensitivity beyond the narrow diagnostic terms.

Example: Anaphylactic Reaction

The MedDRA DRP:PTC uses the Anaphylactic reaction SMQ as an example.

The algorithm can retrieve:

or combinations such as:

The exact term lists and algorithm belong to the applicable SMQ version.

The important principle is that the case qualifies because of the combination of coded concepts within the same case.

Do Not Treat an Algorithmic SMQ as a Flat Term List

If an analyst simply runs:

all narrow terms OR all broad terms

for an algorithmic SMQ, the result is not equivalent to applying the algorithm.

The MedDRA guidance explicitly warns that applying narrow and broad terms without the algorithm will yield different results.

This is a significant implementation risk where software can import SMQ terms but cannot execute:

An analyst should confirm the capabilities of the query tool before relying on an algorithmic SMQ.

Weighted Algorithm

A special case is Systemic lupus erythematosus (SMQ).

This SMQ uses weighted categories.

Broad categories are assigned weights reflecting their relevance.

The algorithm combines those weights to determine whether the case reaches the specified threshold.

The purpose is the same as other algorithms: to recognise a medically meaningful pattern that is more informative than isolated broad terms.

The exact weight logic should be applied from the current SMQ documentation rather than reconstructed from memory.

Categories Are Part of the SMQ Design

Category labels are not optional descriptive metadata.

For an algorithmic SMQ they are part of the executable logic.

A validated implementation should therefore preserve:

Flattening the content into a two-column “SMQ name + PT” table can destroy information needed for correct execution.

Not Every SMQ Has Every Feature

An SMQ may be:

The analyst should not assume that all SMQs behave alike.

The Introductory Guide is therefore part of using an SMQ correctly, not optional background reading.

When to Use an SMQ

An SMQ is most useful when the safety question is medical-concept based rather than tied to one exact Preferred Term.

Typical applications include:

The MedDRA Data Retrieval and Presentation PTC describes several of these applications explicitly.

Focused Case Retrieval

A focused search begins with a defined safety question.

For example:

Is there evidence of acute pancreatitis associated with Product X?

Searching only PT Acute pancreatitis may miss cases coded as:

An appropriate SMQ can provide a more complete candidate set.

The workflow should be:

safety question → select applicable SMQ → choose scope/algorithm → retrieve candidate cases → medical review → final case series

The SMQ is therefore part of the retrieval strategy, not the entire signal evaluation.

Emerging Signals

When a potential new risk is suspected, an SMQ can help determine whether related cases already exist in the database under different MedDRA terms.

A broad scope can be useful at this stage when sensitivity is important.

The reviewer may then classify the retrieved cases into categories such as:

The classification system should be defined for the specific analysis.

Routine Signal Detection

The DRP:PTC notes that the full set of SMQs can be applied to a database for signal-detection purposes.

This does not imply that an organisation is required to run every SMQ routinely.

The appropriate method depends on:

SMQs can complement:

They should not be treated as a universal replacement for PT-level signal detection.

SMQs and Disproportionality Analysis

An organisation may calculate disproportionality measures on SMQ-defined groupings.

This can help identify patterns distributed across related PTs.

However, grouping changes the analytical unit.

A signal present at one highly specific PT can be diluted when combined with many less-specific terms.

Conversely, a clinically coherent cluster may become more visible when related PTs are aggregated.

The query scope should therefore be chosen with the analytical method in mind.

Current EU GVP signal-detection guidance notes that formal MedDRA groupings such as SMQs have not universally proven superior to PT-level analyses for routine statistical signal detection. Their value depends on the question and method.

Signal Evaluation

SMQs are particularly useful after a potential signal has already been identified.

The reviewer may use:

The resulting case series can then be evaluated for:

The SMQ does not perform those assessments.

Periodic Safety Reports

SMQs can help identify cumulative cases for:

A periodic-report search strategy should be reproducible.

Document at least:

Without this information, a later reviewer may be unable to explain why the case count changed between reporting periods.

Single-Case Alerts

SMQs can also be used to trigger alerts when a newly entered case contains a term relevant to an important safety issue.

Narrow scope or a specific sub-SMQ may be more practical for this purpose because broad searches can create excessive alerts.

Potential uses include:

An alert should identify a case for review.

It should not automatically classify the case as confirmed.

Clinical-Trial Aggregate Review

SMQs can be applied to clinical-trial data, particularly when:

The MedDRA guidance notes that broad SMQ use can be appropriate in early development because sensitivity may be particularly important.

The analyst should nevertheless consider differences between:

An SMQ provides term grouping. It does not replace statistical design.

Regulatory Queries

A regulator may request a cumulative review of a safety topic.

An SMQ can provide a standardised starting point, especially when both the MAH and authority understand the query.

However, the regulatory question may require:

The response should state exactly what search was used.

It is better to report:

SMQ X, broad scope, MedDRA 29.0, plus specified additional PTs

than to describe the result generically as an “SMQ search” when the standard query was modified.

Selecting the Search Strategy

Choosing Narrow or Broad in Practice

A useful decision rule is:

Start Narrow When

Start Broad When

Use Both When

The analysis needs to show the effect of scope.

For example:

This gives the reader more information than presenting only one unexplained total.

Interpreting Retrieved Data

Retrieval Is Not Adjudication

This principle should remain explicit in every SMQ analysis.

A broad SMQ result may contain:

Even narrow results can contain clinically incompatible cases.

Medical review should therefore be planned according to the intended use.

Define the Unit of Analysis

SMQ searches can return:

These are not necessarily equivalent.

One case may contain several PTs included in the same SMQ.

If the output counts every matching event rather than unique cases, the apparent number of cases can be inflated.

The analysis should therefore state whether counts represent:

Multiple Matching Terms in One Case

An algorithmic SMQ may intentionally rely on multiple terms within the same case.

A non-algorithmic broad search can also retrieve several included PTs from one ICSR.

The query engine should therefore preserve the relationship between:

case ID → matching PTs → SMQ scope/categories → final case-level result.

Flattening results into a list of terms without case linkage can make correct interpretation impossible.

Duplicate ICSRs

SMQ retrieval does not solve duplicate management.

The same patient may be represented by:

Duplicate assessment should be performed according to the underlying case-management process.

A signal analysis based on duplicated ICSRs can overstate the apparent evidence regardless of how well the SMQ was constructed.

Coding Quality Still Determines Retrieval Quality

SMQs operate on coded data.

If coding is wrong, the query cannot reconstruct the source correctly.

Examples include:

The retrieval chain is therefore:

source quality → coding quality → SMQ implementation → case review → safety interpretation

An SMQ cannot compensate fully for defects earlier in that chain.

Versioning and Reproducibility

SMQs are part of the MedDRA release and therefore change as MedDRA changes.

A query executed with one version cannot be assumed to contain exactly the same PTs, scope assignments, hierarchy or algorithms in a later version.

This creates two related versioning questions:

  1. Which MedDRA version was used to code the data?
  2. Which MedDRA/SMQ version was used to retrieve the data?

Those versions should be understood before results are compared.

Match the Query to the Data

The MedDRA Data Retrieval and Presentation PTC emphasises the impact of versioning on retrieval.

If historical cases were coded under an earlier version and the current SMQ contains newly added or restructured terms, a query built only from the current version may not retrieve older data as expected unless the data have been appropriately recoded or mapped.

The analyst should therefore document:

This matters particularly for longitudinal analyses.

Why Counts Can Change Between Versions

An SMQ result can change even when no new case has entered the database.

Possible reasons include:

A change in SMQ count should therefore not automatically be interpreted as a change in safety incidence or reporting frequency.

Version impact should be considered first.

Current Version Context

As reviewed on 1 October 2026, MedDRA Version 29.1 has been released and its current SMQ Introductory Guide is available through the MedDRA support/download site.

However, MSSO lists 2 November 2026 as the global ICSR transition date for MedDRA 29.1.

This distinction is relevant to SMQ work because:

The query version should therefore be stated explicitly rather than described merely as “current MedDRA”.

SMQ Changes Should Be Controlled

When an organisation moves to a new MedDRA version, it should assess the impact on safety queries that matter to its pharmacovigilance system.

High-priority queries can include:

Useful controls include:

This is recommended operational practice rather than one prescribed regulatory validation format.

Modification and Custom Queries

SMQ Modification

Sometimes the standard SMQ does not fit the precise analytical question.

The analyst may need to:

MedDRA guidance permits users to customise queries when scientifically justified.

But terminology matters.

If the standard term content or structure is modified, the resulting query should not continue to be called an SMQ.

The DRP:PTC recommends referring to it as a:

modified MedDRA query based on an SMQ

or another name that clearly distinguishes it from the ICH-endorsed standard query.

Why Naming Matters

Suppose one company reports:

“We searched SMQ Torsade de pointes/QT prolongation.”

but actually removed several broad terms and promoted another term into narrow scope.

A regulator or partner reading the report may reasonably assume that the standard SMQ was used.

The result is not reproducible.

A better description is:

“Modified MedDRA query based on SMQ Torsade de pointes/QT prolongation, broad scope, with PT Syncope excluded for this product-specific analysis.”

That statement makes the deviation visible.

Product-Specific Modification

The MedDRA DRP:PTC gives examples where modification can be clinically reasonable.

A product may have a well-established background association with one broad SMQ term that creates excessive noise unrelated to the safety question.

Removing that term can improve the usefulness of the focused query.

Likewise, a broad term may be particularly important for one product and could be treated differently in a modified query.

The important controls are:

Organisation-Constructed Queries

A custom search developed entirely by an organisation should not be labelled an SMQ.

The term SMQ is reserved for the standardised, maintained MedDRA queries.

Organisation-constructed queries can be valuable and sometimes necessary.

Examples include:

But the query should have a distinct name and documented methodology.

When No Suitable SMQ Exists

SMQs do not cover every medical topic or safety issue.

The DRP:PTC explicitly lists incomplete topic coverage as a limitation.

If no suitable SMQ exists, options include:

The analyst should not force an unrelated SMQ to answer a question for which it was not designed.

Validate the Search Against the Question

The presence of a validated standard query does not eliminate the need to confirm that it is fit for the specific analytical purpose.

Before use, ask:

The standardisation is in the query content. The appropriateness of using that query remains a scientific decision.

Technical Implementation

SMQs are distributed as structured MedDRA data and can also be reviewed in MedDRA tools.

An implementation may use:

The technical implementation should preserve all information needed for the SMQ's design.

For a simple narrow/broad SMQ this may include:

For algorithmic or hierarchical SMQs it may additionally include:

Test Algorithm Support

The DRP:PTC explicitly warns users not to assume that all software supports algorithmic SMQs.

A safety database may display the SMQ name and retrieve its terms but fail to execute the category combination.

That can create an apparently valid but analytically wrong result.

Before production use of an algorithmic SMQ, test:

The expected result should be compared with known test cases.

Event-Level Versus Case-Level Logic

This distinction is critical for algorithms.

Suppose one ICSR contains:

The algorithm may identify the case because those terms co-occur in the same record.

If the query system evaluates terms independently at event-row level and never recombines them by case ID, it may fail to recognise the pattern.

Conversely, if the system combines terms across different patients, it can generate false matches.

Algorithmic SMQs therefore require correct case-level relational logic.

Active and Inactive Content

MedDRA releases can contain status information relevant to query content.

Production processes should use the current SMQ content supplied for the applicable version.

Historical analytical records should preserve the version actually applied.

An organisation should not quietly substitute a newer SMQ definition into an old analysis while continuing to describe the old result as though nothing changed.

Reproducible Search Record

For an important analysis, retain enough metadata to recreate the query.

A practical search record can include:

Element Example
Medical question Acute pancreatitis signal evaluation
MedDRA version 29.0
SMQ Acute pancreatitis
SMQ ID Recorded from current distribution
Scope Broad
Algorithm Applied if specified
Sub-SMQ If applicable
Modifications None / listed explicitly
Database Safety DB production snapshot
Cut-off 30 September 2026
Unit Unique ICSRs
Duplicate rule Defined
Case-review criteria Attached/controlled
Query code/version Preserved

This record separates query reproducibility from the later medical conclusions.

Query Governance

SMQ governance should connect:

query definition → technical implementation → medical review → version change → repeat analysis

This is particularly important for recurring searches.

A one-time analyst can remember why a term was excluded.

A periodic process running every six months cannot rely on memory.

The rationale should be preserved in a controlled artefact.

Do Not Freeze an SMQ Forever

An organisation may be tempted to validate an SMQ implementation once and then never change it.

That defeats the purpose of a maintained terminology.

A better model is:

The goal is controlled evolution, not permanent freezing.

Practical SMQ Workflow

A defensible SMQ analysis can be organised into eight steps.

Step 1 — Define the Medical Question

State the safety issue clearly.

Avoid beginning with:

“Which SMQ can we run?”

Begin with:

“What clinical concept are we trying to identify, and why?”

The query should serve the safety question.

Step 2 — Identify the Relevant SMQ

Review the current list of SMQs.

If one appears relevant, read its current Introductory Guide section.

Confirm:

Step 3 — Choose the Search Architecture

Decide whether to use:

Document the rationale.

Step 4 — Confirm MedDRA and SMQ Version

Verify:

Do not assume “latest released” means “version currently used by the database”.

Step 5 — Validate the Technical Execution

Confirm that the tool correctly implements:

This is especially important for algorithmic SMQs.

Step 6 — Retrieve Candidate Cases

Run the query against the defined dataset.

Record:

Step 7 — Apply Medical Review

Evaluate retrieved cases using predefined criteria.

The criteria may include:

Step 8 — Report the Method and Result Separately

Describe:

This prevents the retrieval count from being mistaken for the final medically confirmed case count.

Worked Examples

Worked Example 1 — Emerging Pancreatitis Signal

A safety team sees several pancreatitis reports for a recently marketed product.

Initial Question

Are there additional cases in the safety database that may represent acute pancreatitis but were coded under related findings rather than the diagnosis itself?

Search Choice

Use Acute pancreatitis SMQ.

Because the safety issue is emerging and sensitivity matters, the team chooses the broad search.

Output

The broad search retrieves:

Review

The medical team classifies cases according to a predefined pancreatitis case framework.

Some broad matches are excluded because the findings were attributable to another condition.

Interpretation

The final medically compatible case series is smaller than the SMQ retrieval count.

That is expected.

The SMQ has done its job by finding candidate cases.

Worked Example 2 — Automated Alert for Anaphylaxis

A product has an identified risk of anaphylaxis and the safety team wants rapid review of new cases.

Search Choice

A narrow SMQ alert may provide a manageable set of highly relevant cases.

If the organisation uses the algorithmic Anaphylactic reaction SMQ, the technical system must correctly evaluate category combinations within each case.

Operational Risk

A system that merely searches all broad terms independently may generate many false alerts or fail to reproduce the actual SMQ algorithm.

Control

Test known positive and negative sample cases before relying on the alert.

Worked Example 3 — Thrombocytopenia Within a Hierarchical SMQ

The safety question concerns thrombocytopenia only.

Using the entire Haematopoietic cytopenias SMQ would also retrieve other cytopenias.

Search Choice

Use the specific thrombocytopenia sub-SMQ if supported by the current guide.

Benefit

The analysis remains standardised while avoiding clinically unrelated branches.

Worked Example 4 — Product-Specific Modification

A broad SMQ contains a PT that is extremely common for the product because of a well-established benign effect.

The term overwhelms the candidate case set.

Approach

The team removes the term for a focused analysis.

Naming

The resulting query is no longer the unmodified SMQ.

It should be described as a modified MedDRA query based on the SMQ, with the excluded PT documented.

Why

Transparency allows another reviewer to reproduce the result.

Worked Example 5 — Version Change Alters the Count

A periodic analysis used MedDRA 28.1 in the previous cycle and 29.0 in the current cycle.

The current SMQ retrieves more cases even before new cases are added.

Investigation

The team identifies changes in SMQ content and historical recoding.

Interpretation

The increase is partly terminological rather than a change in reporting pattern.

Lesson

Version effects should be assessed before interpreting longitudinal differences.

SMQ Limitations

SMQs are powerful retrieval tools, but they have defined limitations.

They Do Not Cover Every Safety Topic

A relevant SMQ may not exist.

A custom query may be required.

They Can Retrieve Noise

Broad searches are intentionally sensitive.

Some narrow searches can also retrieve false positives.

They Depend on Coding Quality

Incorrect or inconsistent MedDRA coding can reduce retrieval quality.

They Depend on Version

Term content can change between releases.

They Depend on Correct Technical Implementation

An algorithmic SMQ can be implemented incorrectly even when the correct term file is loaded.

They Do Not Replace Medical Review

A matching PT is evidence for retrieval, not a confirmed diagnosis.

They Can Dilute Signals

Very broad grouping can reduce a strong PT-level signal by adding many unrelated events.

SMQs Versus Custom Queries

The decision can be summarised as:

Situation Preferred starting point
Standard medical concept covered by SMQ Use relevant SMQ
Need high specificity Narrow scope or specific sub-SMQ
Emerging issue with heterogeneous coding Broad SMQ search
Algorithmic syndrome Apply algorithm, not flat term list
Product-specific noise Modified query based on SMQ
No suitable SMQ Custom MedDRA query
Regulatory request specifies terms Follow request and document method

The most important distinction is transparency.

A customised query can be scientifically excellent.

It should simply not be described as the unchanged standard SMQ.

Inspection and Governance Perspective

An inspector or quality reviewer assessing SMQ use could ask:

The strongest evidence is not simply a saved term list.

It is an end-to-end record showing:

medical question → query selection → version → execution → candidate set → medical review → final interpretation.

Illustrative Failure Modes

The following are hypothetical examples, not actual inspection findings.

Broad Search Terms Used Without Narrow Terms

The system searches only terms marked “broad”.

Why it fails: a standard broad SMQ includes both narrow and broad terms.

Algorithm Ignored

All terms from an algorithmic SMQ are ORed together.

Why it fails: the standard algorithm requires defined case-level combinations.

SMQ Match Treated as Diagnosis

Every retrieved case is counted as a confirmed case of the syndrome.

Why it fails: SMQs identify potential cases for review.

Modified Query Still Called an SMQ

Several PTs are excluded but the report says “SMQ X was used”.

Why it fails: the method is no longer the unmodified standard SMQ.

Query Version Not Recorded

A case series cannot be reproduced six months later.

Why it fails: SMQ content is version dependent.

Case Count Inflated by Event Rows

One ICSR has four matching PTs and is counted four times.

Why it fails: event count was confused with unique-case count.

Current SMQ Applied to Old Unmapped Data

New terms are searched against historical coding without version reconciliation.

Why it fails: relevant older cases may be missed or counts become non-comparable.

Hierarchical SMQ Used at Maximum Scope Automatically

The entire umbrella SMQ is run when only one subcondition is relevant.

Why it fails: unrelated branches add noise and can dilute the analysis.

Practical SMQ Checklist

Before finalising an SMQ analysis, verify:

Relationship With MedDRA Coding

SMQ performance depends on the quality of the coded data it searches.

The companion article MedDRA Coding in Pharmacovigilance: A Practical Guide explains:

The relationship is:

accurate source coding → reliable MedDRA data → appropriate SMQ → medically reviewed case series → credible safety interpretation.

An SMQ is therefore one layer in the pharmacovigilance evidence chain.

Current Version Note

As reviewed on 1 October 2026, MedDRA 29.1 and the corresponding SMQ Introductory Guide have been released.

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

The current ICH-endorsed MedDRA Data Retrieval and Presentation: Points to Consider is Release 3.26, issued with the March 2026 MedDRA 29.0 release.

SMQ analyses should record the actual version used. Readers should verify the current MedDRA release and transition information before production implementation.

Key Takeaways

References

  1. MedDRA Maintenance and Support Services Organization. Introductory Guide for Standardised MedDRA Queries (SMQs), MedDRA Version 29.1. September 2026. Available from the current MedDRA support/download site.
    https://alt.meddra.org/

  2. MedDRA Maintenance and Support Services Organization / ICH. MedDRA Data Retrieval and Presentation: Points to Consider, Release 3.26. March 2026, based on MedDRA Version 29.0.
    https://alt.meddra.org/

  3. Council for International Organizations of Medical Sciences. Development and Rational Use of Standardised MedDRA Queries (SMQs): Retrieving Adverse Drug Reactions with MedDRA. Second Edition. Geneva: CIOMS; 2016.
    https://cioms.ch/publications/product/council-for-international-organizations-of-medical-sciences-cioms/

  4. MedDRA Maintenance and Support Services Organization. MedDRA Support Documentation and Transition Dates. Current release information, including Version 29.1 and the 2 November 2026 ICSR transition date.
    https://www.meddra.org/how-to-use/support-documentation/english/multilingual

  5. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP) Module IX Addendum I – Methodological aspects of signal detection from spontaneous reports of suspected adverse reactions. EMA/209012/2015.
    https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-good-pharmacovigilance-practices-gvp-module-ix-addendum-i-methodological-aspects-signal_en.pdf

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

Regulatory Note

This article explains SMQ use as reviewed on 1 October 2026.

SMQs and the MedDRA Points to Consider documents provide standardised terminology and methodological guidance. They do not by themselves create EU legal reporting requirements, define a regulatory signal, or replace medical assessment.

The MedDRA Data Retrieval and Presentation PTC expressly states that its examples and options are not intended to communicate specific regulatory reporting requirements. Regional pharmacovigilance obligations and any study-, product- or regulator-specific requirements should therefore be applied separately.

SMQs evolve with MedDRA. Production analyses should verify the applicable MedDRA/SMQ version, current Introductory Guide and system capabilities before use.

The worked examples and failure modes in this article are illustrative and are not presented as actual inspection findings.

Revision History

Related Articles

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.

Data Sources for Signal Management

Signal management depends on integrating multiple data sources with different strengths, biases and levels of evidentiary value. This article explains how spontaneous reports, regulatory databases, literature, clinical trials, observational studies, real-world data, registries, product information and mechanistic evidence contribute to signal detection, validation and assessment, and how pharmacovigilance professionals should govern source quality, traceability and interpretation.

Disproportionality Analysis in Pharmacovigilance

Disproportionality analysis is a statistical screening approach used to identify product-event combinations reported more often than expected within spontaneous-report databases. This article explains how the main measures are calculated and interpreted, why a signal of disproportionate reporting is not proof of causality or incidence, how EudraVigilance uses the reporting odds ratio, and how quantitative findings should be integrated with clinical review and other safety evidence.

Last reviewed: 2026-10-01

QPPV.com