QPPV.COM

WHODrug Coding in Pharmacovigilance

Explains how WHODrug standardises medicinal-product information in pharmacovigilance, how product names and substances are represented, how B3 and C3 coding differ, and how coding quality affects ICSR processing, aggregation and signal analysis.

Take test

WHODrug Coding in Pharmacovigilance

WHODrug coding standardises medicinal-product information so that medicines reported under different brand names, substance variations, languages and markets can be identified and analysed consistently. In an individual safety case, this supports accurate representation of the suspect, interacting and concomitant medicines. At aggregate level, it allows safety data to be grouped by product, substance and therapeutic class rather than depending only on free-text product names.

The coding problem is different from MedDRA coding. MedDRA asks, in effect, what medical event was reported? WHODrug asks what medicinal product or substance was reported?

A reporter may provide a precise marketed product, such as a named tablet with a known strength and country. Another report may say only “paracetamol”, “my blood-pressure medicine”, or a brand name used for several different formulations. The coder's task is to use the information actually available to identify the most appropriate WHODrug record without inventing detail.

The practical sequence is:

reported product information → preserve source verbatim → identify product/substance → use contextual information → select the most appropriate WHODrug record → retain coding version and identifier → use coded data for case processing and analysis

Good WHODrug coding therefore depends on both terminology knowledge and careful product identification.

Purpose and Scope

This article explains WHODrug coding from a pharmacovigilance perspective.

It covers:

It does not reproduce proprietary WHODrug data or attempt to replace the current UMC User Guide, Best Practices or C3 coding guidance. WHODrug Global is a licensed terminology. The purpose here is to explain the coding principles a pharmacovigilance professional needs to understand when working with the terminology.

WHODrug Global and Its Data Model

What WHODrug Global Is

WHODrug Global is Uppsala Monitoring Centre's international medicinal-product terminology. UMC maintains the dictionary for standardised identification and analysis of medicines and related products.

Its coverage includes conventional medicines as well as other medicinal-product categories such as:

WHODrug provides connections between product names, active substances and therapeutic classifications so that safety data can be retrieved at different levels of precision.

That is the main analytical value.

A spontaneous report may use a local trade name. Another case may report the active substance. A third may contain a different salt or formulation. WHODrug creates a controlled structure that helps determine which records belong together and which should remain distinct.

WHODrug Is Not Simply a List of Brand Names

A flat product list would be insufficient for pharmacovigilance because one name can relate to several clinically different situations.

A useful medicinal-product terminology needs to support questions such as:

WHODrug addresses these questions through linked identifiers, product/substance records and classification information.

Current 2026 Terminology Context

As reviewed on 2 October 2026, the current WHODrug User Guide is the September 2026 edition.

WHODrug Global is released twice a year, on:

UMC also publishes Version Verification material for the March and September releases.

The March release is generally the more substantial annual update, while both releases can add or revise medicinal-product content. UMC's current Best Practices also emphasise that organisations need a controlled strategy for moving between versions because new products and coding options continue to be added.

This means that WHODrug coding is version-dependent.

A product that cannot be coded specifically in one release may have a specific record in a later release.

The B3 and C3 Formats

WHODrug Global is currently distributed in B3 and C3 formats.

The older B2 and C formats are historical; the terminology has been supplied in the newer B3/C3 formats since 2019.

Both formats provide structured product information, but they support different levels of specificity.

B3 Format

The B3 format contains core information such as:

Its unique identifier is the WHODrug Drug Code.

B3 is therefore well suited to standardising the identity of a reported drug name and its substance relationship.

C3 Format

The C3 format contains the B3 information and adds product-specific information such as:

This permits much more precise identification of an actual marketed product when enough source information is available.

The difference can be represented as:

B3 → what drug name/substance concept is this?

C3 → which specific product record is this, with available market/form/strength detail?

C3 can be used as a stand-alone coding terminology or as a richer reference while coding with B3, depending on the organisation's system and process.

Core WHODrug Concepts

The Drug Name

In WHODrug, the drug name can represent a medicinal product name or a substance-related name, depending on the record.

A source may report:

The coder should first determine what the reporter actually provided.

The terminology should standardise that information without losing the distinction between:

That distinction can matter for pharmacovigilance, particularly for products where formulation, manufacturer or product-specific characteristics are relevant.

Product Name and Substance Name

The current WHODrug User Guide distinguishes product names from substance names.

A product name represents a medicinal product name.

A substance name represents the substance concept used in the terminology.

This matters because a report of a brand name may contain more product-specific information than a report of the active substance alone.

For example:

“Product Alpha 20 mg tablets”

is not equivalent in source specificity to:

“active substance X”.

Both may ultimately contribute to substance-level analysis, but the product-level information should not be discarded when it is available.

Active Substances

WHODrug links product names to their active substance or substances.

This allows safety data to be aggregated above the individual brand level.

For example, several national trade names may contain the same active substance.

A substance-level search can then retrieve cases that would otherwise remain separated by brand.

This is one of the main differences between retaining a free-text product name and coding to a medicinal-product terminology.

The WHODrug Drug Code

The WHODrug Drug Code is an alphanumeric identifier built from:

The complete Drug Code uniquely identifies a drug name and its associated substance information, or an Umbrella record, within the B3 structure.

Drug Record Number

The DrugRecNo identifies the substance or combination of substances at a fundamental grouping level.

Records sharing a DrugRecNo relate to the same substance or combination even where there are variations or different product names.

This makes the DrugRecNo important analytically because it connects related medicinal-product records.

Sequence Components

Seq1 and Seq2 provide additional differentiation within the Drug Code structure.

The coder ordinarily interacts with these through the coding system rather than constructing them manually.

The important PV principle is that the full coded identifier carries more structured meaning than the free-text name alone.

The C3 Record Identifier

C3 adds a Record Identifier (RID).

The RID uniquely identifies a specific C3 record and, unlike the Drug Code, is a serial identifier without intrinsic coding meaning.

A C3 RID can distinguish a specific combination of product attributes such as:

This allows the same reported product to be represented at different levels of detail depending on how much source information is known.

C3 Information Levels

A central feature of C3 is the ability to code at different information levels.

The least specific record may identify only the product name and ingredient relationship.

More detailed records can add:

UMC's current C3 guidance recommends coding to the most detailed level possible using the information available at the time of coding.

This principle should be understood carefully.

It means:

use available evidence to choose the most specific supported record

not:

fill missing fields by assumption so that a more detailed record can be selected.

Specificity must come from the source or reliable contextual information, not from coder invention.

Core Coding Principles

Source Verbatim Must Be Preserved

The original reported product information should remain available even after coding.

For example:

reported:

“the blue 10 mg tablet I take for blood pressure”

coded:

a specific product record, if sufficient contextual information allows confident identification

The original wording still matters.

It allows a reviewer to determine:

The coded record standardises the product. It should not replace the source history.

Coding Is Product Identification, Not Causality

WHODrug coding does not decide whether a medicine caused the adverse event.

A case can contain:

The medicinal-product terminology identifies the product.

The case role and causality fields determine how that medicine relates to the event.

A coder should not select a different product record merely because one medicine is considered more likely to be causal.

The Practical Coding Question

For every medication entry, ask:

  1. What exactly did the source report?
  2. Is it a product name, substance name, class, or vague description?
  3. Are country, manufacturer/MAH, form or strength known?
  4. Is the name unique?
  5. Is it a single-ingredient or combination product?
  6. Does contextual information support a more specific record?
  7. Am I adding information that the source does not support?
  8. Is the original verbatim preserved?
  9. Is the selected WHODrug version recorded?

The remaining sections apply this method to the product-identification situations that most often create inconsistent coding.

Product Identification in Practice

Most WHODrug coding errors arise before the code is selected. The difficulty is usually not finding a matching string; it is deciding what product the source actually refers to.

A reliable coding process therefore moves from source evidence to product identification before it moves to dictionary selection.

Trade Names

A trade name can provide highly useful product-level specificity.

If the reporter provides:

C3 may allow selection of a highly specific product record.

For example:

“Brand X 50 mg tablets bought in Country A.”

is more informative than:

“Brand X.”

The coder should use the extra information if it is reliable.

However, a trade name should not automatically be treated as globally unique.

The same name may be used for different ingredients in different countries, or for different formulations containing different substance variations.

Non-Unique Drug Names

UMC specifically identifies non-unique names as an important WHODrug concept.

A drug name can be non-unique because:

This is a major pharmacovigilance risk.

If a coder chooses the first exact text match without checking the ingredient and context, a case can be assigned to the wrong substance.

B3 Representation of Non-Unique Names

In B3, non-unique product names are differentiated by appending the relevant ingredient information to the name.

The purpose is to make records that share the same visible trade name distinguishable.

The coder should therefore inspect the ingredient-linked record rather than selecting a name based only on its surface text.

C3 Representation of Non-Unique Names

C3 has more product-level information available and therefore does not depend on the same display convention.

Country, MAH, form, strength and other C3 information can help distinguish records that would otherwise have the same drug name.

This is one reason why contextual information is so important in C3 coding.

Country Is Product Information

Country can materially change product identification.

A brand reported in one country may:

Country should therefore be used when the source supports it.

But country should not be guessed merely from:

The relevant product country is the market associated with the medicinal product as reported or reliably established.

Marketing Authorisation Holder and Manufacturer Context

C3 can include marketing authorisation holder information.

This can help distinguish products sharing:

However, the MAH should be used as contextual evidence rather than assumed from internal company knowledge when the source does not support that identification.

For example, if a reporter says only:

“Brand X”

and several Brand X records exist, the fact that the case was received by one manufacturer does not automatically prove that its own product was used.

Follow-up or other evidence may be needed.

This is especially important in spontaneous reports where reporters can contact one company about a medicine made by another.

Pharmaceutical Form

Pharmaceutical form can distinguish otherwise similar product records.

Examples include:

Form can also help exclude an incorrect match.

If the source says:

“Brand X eye drops”

a tablet record with the same trade name is not an appropriate product identification.

The coder should still avoid inferring the exact form from route alone if several formulations remain possible.

Strength

Strength can be useful for confirming a specific product record.

For example:

“Brand Y 5 mg tablet”

may correspond to a more detailed C3 record than:

“Brand Y tablet”.

Strength should be coded only when supported.

A prescribed daily dose is not always the same thing as product strength.

For example:

“Patient takes 20 mg daily”

could mean:

The coder should not convert dose into product strength without adequate evidence.

Route of Administration

Route can help identify the correct medicinal-product record even though it is not equivalent to pharmaceutical form.

A source saying:

“injected intramuscularly”

may help distinguish an injectable preparation from an oral product.

But route should be interpreted with care because:

Product coding should preserve the product identity separately from the medication-use event.

Indication as Context

UMC C3 guidance recognises that contextual information such as indication can help identify a product.

For example, a trade name may exist in multiple records with different intended uses or ATC assignments.

If the source clearly states why the medicine was being used, that information can help select the most appropriate record.

Indication should support identification, not override contradictory product information.

A coder should not force a drug into an expected therapeutic class simply because the indication suggests one.

Exact Match Is Not Always Correct Match

A common error is:

source name → exact text match → accept first result.

The better workflow is:

source name → identify all plausible matches → compare ingredients → compare country/form/strength/MAH where available → select best-supported record.

This is especially important for:

Generic Names

A reporter may provide only a generic or substance name.

If the source says:

“paracetamol”

the coding should not be upgraded automatically to a specific branded product.

A substance-level record may be the most faithful representation.

This can still support substance-level aggregation.

The absence of a brand is not a coding failure if the source never identified one.

Substance Variations

Medicinal products can contain different forms of the same underlying active moiety, such as:

WHODrug's Drug Code structure links related substance variations at defined levels.

The coder should preserve the variation when it is actually reported and a specific record is available.

For example:

“substance hydrochloride”

contains more information than:

“substance”.

But the coder should not infer a salt from a product name if the source does not support that level of detail.

Substance Base Versus Substance Variation

The DrugRecNo structure helps connect substance variations to the same underlying substance grouping.

This supports aggregation across related forms while retaining more specific substance information where available.

The practical PV benefit is that analysis can occur at different levels.

A case may be coded to:

The organisation's analysis strategy should therefore understand the WHODrug hierarchy rather than relying only on the displayed drug name.

Combination Products

Combination products require careful product identification because more than one active substance is involved.

A reported product may contain:

WHODrug represents the combination as a linked set of substances.

In the B3/C3 structures, multi-ingredient generic names are represented using the component substances in a standardised way.

The coding objective is to identify the combination product, not to replace one reported combination medicine with several unrelated medication entries unless the source actually reported separate medicines.

Why Combination Coding Matters

Suppose a fixed-dose product contains A + B.

If the case is coded as:

as though the patient took two independent products, the database loses the fact that exposure was to a fixed combination.

That can affect:

The combination record should be used where it accurately represents the reported medicine.

Substance-Level Analysis of Combinations

A combination product can still contribute to substance-level analyses of its ingredients.

That is one advantage of a structured dictionary.

The product-level record preserves the actual exposure, while the ingredient relationships support broader analyses.

This is preferable to destroying product specificity at coding stage merely to make substance-level retrieval easier.

Vitamins, Minerals and Complex Products

Some products contain:

The same coding principles apply:

  1. identify the actual reported product if possible;
  2. use the most specific supported WHODrug record;
  3. do not reconstruct a detailed ingredient list from assumptions;
  4. preserve the source verbatim.

For complex products, follow-up can be particularly valuable if the safety question depends on one ingredient.

Umbrella Records

WHODrug contains Umbrella records that can be used when the reported information is too broad for a more specific medicinal-product record.

They act as controlled placeholders for general categories.

The use of an Umbrella record is preferable to inventing a precise product that the source does not support.

However, broad placeholder coding reduces analytical specificity.

If additional information can reasonably be obtained, follow-up should be considered before settling permanently on a very broad record.

Vague Product Descriptions

Examples include:

The coder should not choose a named product merely because it is common.

The appropriate response is:

vague source → evaluate whether a broader WHODrug record is available → seek follow-up if important and feasible → retain verbatim → avoid unsupported specificity.

A vague medication history should remain vague rather than become falsely precise.

Misspellings

Trade names are frequently misspelled.

A coding tool may support:

The coder should confirm the result using contextual data.

A one-letter difference can identify:

The first fuzzy match should never be treated as proof of identity.

Phonetic and Transcribed Names

Telephone reports can produce names such as:

The source record should make clear what the reporter actually said.

If a probable match is selected, the evidence supporting the choice should be reconstructable.

Where multiple plausible products remain, follow-up is preferable to forced coding.

Abbreviations

Medication abbreviations can be highly ambiguous.

A short form may refer to:

Context should be used cautiously.

The coder should not expand an abbreviation into a specific medicine unless the case supports that interpretation.

Herbal Products

WHODrug Global includes herbal remedies.

Herbal coding can be challenging because the source may provide:

The same principle applies: select the most specific supported record without manufacturing ingredient certainty.

Botanical composition can vary materially between products that appear similar in ordinary language.

Missing Drug in WHODrug

A genuine medicinal product may not yet be present in the installed version.

UMC provides a Change Request process for:

UMC's coding support also advises checking whether the product is already available or scheduled for a future release before submitting a request.

The case should retain the original reported drug name while the coding issue is being resolved.

The organisation should have a controlled approach for:

Do Not Create Local WHODrug Records

An organisation should not create unofficial records inside the WHODrug namespace merely to force a match.

A local alias may be used within software to support searching, depending on validated system design, but the underlying standard identifier should remain an official WHODrug record.

If a needed medicinal product is missing, the UMC Change Request pathway should be used.

This protects standardisation across:

Pharmacovigilance Roles and Product Coding

A medicinal product can play different roles in an ICSR.

Common case roles include:

WHODrug identifies the medicinal product. The case-processing system records the role.

These functions should remain separate.

A product should not be coded differently because it is suspect rather than concomitant. Product identity is one question; its relationship to the event is another.

Suspect Medicines

The suspect medicine should be coded to the most specific supported product or substance record.

If the source clearly identifies:

that detail should be used where the organisation's WHODrug format and system support it.

If the source identifies only the substance, the coder should not manufacture a specific brand.

The causality assessment belongs elsewhere in the ICSR.

The coding task is to identify the reported medicinal product as accurately as possible.

Interacting Medicines

A medicine reported as interacting should also be coded according to its product identity.

The presence of an interaction allegation does not change the dictionary rules.

For example:

“The reporter believed Drug A interacted with Drug B.”

requires:

If one product is only vaguely identified, that uncertainty should remain visible.

Concomitant Medicines

Concomitant medication coding is analytically important because co-medication can affect:

However, concomitant medicines are often reported with less detail than the suspect product.

Examples include:

The coder should not upgrade vague concomitant information simply to make the medication list appear complete.

Treatment of the Adverse Event

A medicine administered to treat the adverse event is not automatically a suspect or concomitant exposure relevant to event causation.

For example:

“The patient developed anaphylaxis after Product X and was treated with adrenaline.”

Both Product X and adrenaline can be coded as medicinal products, but their roles are different.

The case chronology and medication roles should make that distinction clear.

Medication History and Prior Exposure

Past medicines can be clinically important.

A prior product may help explain:

The same WHODrug terminology can be used to identify the historical medicine, but the data field and dates determine its role.

A product coded correctly in the wrong case field can still mislead later analysis.

Biologicals, Vaccines and Complex Products

Biological Medicines

Biological products increase the importance of exact product identification because safety questions may be:

WHODrug can support standardised product/substance coding, but product coding is only one part of biological traceability.

Where available and relevant, the ICSR may also need separate information such as:

A WHODrug identifier should not be treated as a substitute for batch/lot information.

Biosimilars

For biosimilars, the distinction between:

can be pharmacovigilance-relevant.

A report that names the exact brand should retain that specificity.

A report that states only the active substance should not be assigned to one particular biosimilar without evidence.

This matters because inaccurate brand attribution can distort product-specific safety surveillance.

The coding principle remains the same:

use the most specific product identity supported by the source

not:

select the most likely brand based on market share or local formulary assumptions.

Vaccines

Vaccines can also require product-specific identification.

A vaccine report may include:

WHODrug coding can standardise the medicinal-product identity, while vaccine-specific case fields preserve administration and batch information.

A product-code match should therefore be checked against the source rather than treated as sufficient on its own.

Multi-Valent and Combination Vaccines

Combination vaccines can contain several antigenic components within one medicinal product.

The administered product should be coded as the reported combination product where possible.

Separating the vaccine into several hypothetical individual products would destroy the exposure identity.

Ingredient-level analysis can still be supported through the structured product/substance relationship.

Investigational Products

WHODrug can contain investigational substances and products.

UMC also uses specific classification conventions to support identification of investigational drugs.

In a clinical-development context, coding strategy should be aligned with:

The present article focuses on pharmacovigilance principles, but the core rule remains: product identity should be coded without revealing or inventing information that is not legitimately available to the coder.

Blinded Clinical-Trial Products

Blinded product information requires special control.

If the case-processing team does not know whether the patient received active product or comparator, WHODrug coding should not break the blind.

The medicinal-product representation should follow the study's controlled blinded-data convention.

If unblinding later occurs, the record can be updated according to the applicable process.

This is an example where the most specific theoretically possible product code is not appropriate because the source available to the coder does not legitimately establish that identity.

Interfaces and Special Product Situations

Product Quality Complaints

A product-quality complaint may contain unusually precise product information, such as:

If an adverse event is also present, this information can improve product coding in the ICSR.

The quality investigation and pharmacovigilance case should remain linked where appropriate, but their data serve different purposes.

WHODrug standardises medicinal-product identity.

The quality system investigates the defect.

Batch/lot information and complaint identifiers should be retained in their appropriate fields.

Medication Errors

Medication-error cases can also contain product information that differs from intended use.

For example:

“The patient was prescribed Brand A 10 mg but accidentally took Brand A 20 mg.”

The product identification should represent the product actually taken where this is known.

The medication error is coded and assessed separately.

Product strength can be essential to reconstructing the error, but it should be taken from source evidence rather than calculated retrospectively unless the process allows and documents that derivation.

Counterfeit, Falsified or Uncertain Products

A report may involve a suspected counterfeit or falsified product.

The visible brand name may imitate a legitimate product, but the actual composition may be unknown.

The coder should not automatically assume that the counterfeit contains the authentic product's active ingredient.

The ICSR and quality/falsification workflow should preserve:

Where no precise WHODrug match can be justified, broader or temporary coding may be more faithful than false certainty.

Follow-Up and Coding Changes

Follow-Up Can Improve Product Identification

Product coding should be reconsidered when follow-up provides new information.

Initial report:

“A blood thinner.”

Follow-up:

“It was Brand Z 5 mg tablets.”

The second report may allow a much more specific WHODrug record.

The safety database should preserve:

The coder should not overwrite the history in a way that makes it appear that the brand was known from the beginning.

Follow-Up Can Correct the Product

A reporter may correct an earlier product name.

For example:

Initial:

“I think it was Brand A.”

Follow-up:

“I checked the box; it was Brand B.”

The case should be updated to reflect the corrected source information.

The change is not simply a dictionary recoding exercise; it is new source information.

That distinction matters for:

Internal Coding Correction Versus New Source Information

A coder may discover that the source always said Brand A, but the case was accidentally coded to Brand B.

Correcting that error is an internal coding correction.

No new source information has been received.

The audit trail should distinguish:

source changed from coding interpretation corrected.

This mirrors the distinction already used in MedDRA coding and Day Zero governance.

E2B(R3) and Data Exchange

E2B(R3) and Medicinal-Product Data

ICH E2B(R3) provides the structured framework for electronic transmission of ICSR medicinal-product information.

WHODrug can support standardisation of product data within regulatory and pharmacovigilance workflows, but WHODrug use is not a universal ICH requirement for every jurisdiction.

UMC publishes separate technical guidance for use of WHODrug Global in E2B(R3) XMLs uploaded through VigiFlow eReporting for Industry.

Other authorities can have their own medicinal-product coding expectations.

The organisation should therefore distinguish:

WHODrug coding strategy from destination-specific electronic reporting requirements.

Do Not Confuse WHODrug Identifier With E2B Field Meaning

A safety database may store:

These layers should be mapped deliberately.

The fact that a WHODrug record contains product information does not mean every field should be copied blindly into an ICSR message.

E2B mapping should follow:

Regional Requirements Vary

Some regulatory environments specify particular WHODrug formats or coding expectations.

Others may accept or require different medicinal-product identifiers.

WHODrug's regional-integration services reflect this variation.

A global company should therefore avoid one uncontrolled assumption such as:

“Our internal WHODrug code is the regulatory product identifier everywhere.”

A safer architecture separates:

Product Coding in Case Management

Product Coding and Duplicate Detection

Accurate product coding can help identify duplicate ICSRs.

Two reports may use:

WHODrug relationships can reveal that the medicinal-product exposures are closely related.

However, duplicate detection should not rely on drug coding alone.

The same product can be used by many patients.

Duplicate assessment still requires:

Product Coding and Case Linking

Coding also supports linking records from:

If one system stores free text and another uses standardised product identifiers, reconciliation becomes harder.

Consistent medicinal-product coding improves cross-system comparison.

This is one reason product-coding governance belongs within the pharmacovigilance quality system rather than being treated as a purely technical data-management task.

Versioning and Dictionary Governance

WHODrug Global changes over time.

UMC releases new versions twice each year, on 1 March and 1 September. New releases can contain:

An organisation therefore needs a documented upversioning strategy.

The strategy should define:

The September 2026 Context

As reviewed on 2 October 2026, the September 2026 WHODrug Global release is the current release.

The corresponding User Guide and Version Verification material are current reference documents for that release.

An organisation should not describe its production dictionary simply as “current WHODrug” without identifying the actual release.

For reproducibility, record the precise version used.

Version Changes Can Affect Coding Specificity

Suppose an initial case was coded in March because the exact local product did not yet exist in the installed terminology.

The coder selected a broader substance-level or placeholder record.

In the September release, the exact product is added.

The organisation then has a choice under its controlled versioning policy:

Each approach has analytical consequences.

The important control is consistency and traceability.

Post-Marketing Upversioning

UMC Best Practices recognises that post-marketing databases may use a pragmatic strategy in which historical verbatim terms are not automatically recoded every time a new WHODrug version is implemented.

That can make version transitions operationally simpler.

However, retaining historical coding also means that equivalent product exposures can remain at different levels of specificity across time.

Aggregate analysis must therefore understand:

Continuous Recoding Is Not Automatically Better

A fully recoded database may improve version consistency but also introduces:

The appropriate strategy depends on:

There is no universal rule that every historical case must be recoded at every release.

The organisation should define and justify its approach.

WHODrug Change Analysis Tool

UMC provides the Change Analysis Tool (CAT) to help users analyse changes between WHODrug versions.

This can support:

A version transition should therefore be more than a technical dictionary-file replacement.

The pharmacovigilance impact of the change should be considered.

Version Verification

UMC publishes a Version Verification document with the March and September releases.

This provides a controlled way to verify the installed WHODrug version.

In a regulated safety environment, version verification helps demonstrate that:

This is particularly important where:

do not all upgrade at exactly the same time.

Version Alignment Across Vendors

A vendor coding on September 2026 while the MAH database still uses March 2026 can create:

Agreements should therefore define:

Version control is part of data-exchange governance.

2026 Structural Changes

The March 2026 release introduced structural changes that are important for current implementations.

UMC's 2026 structural-change material includes changes such as:

These changes matter because internal systems, data mappings and SOP terminology can become outdated even when coding practice itself has not changed.

RID and ISO IDMP Should Not Be Confused

The renaming of the C3 identifier to RID helps distinguish WHODrug's internal record identifier from identifiers used in ISO IDMP contexts.

A C3 RID identifies a WHODrug record.

ISO IDMP identifiers serve related but different standardisation purposes.

A pharmacovigilance system should not treat any field labelled “MPID” as interchangeable without understanding which standard and version it represents.

Data mapping should be explicit.

Classification and Grouping

ATC Classification

WHODrug includes Anatomical Therapeutic Chemical classification information.

ATC can support:

But ATC should not be treated as the product identity itself.

A product can have a precise WHODrug identity and also one or more therapeutic classifications.

B3 and C3 ATC Differences

The B3 and C3 formats handle product-level ATC assignments differently.

In B3, medicinal-product records are connected to the ATC classifications associated with the substance grouping.

In C3, an individual medicinal-product record is generally assigned the ATC code reflecting that product's intended use, while substance-level records can retain the wider set of relevant ATC classifications.

This can improve analytical specificity in C3.

It also means that an analyst should understand which format generated the ATC grouping being used.

ATC Is Not Indication Coding

An ATC classification can help characterise a medicine's therapeutic use.

It does not prove why a particular patient used the product.

The patient's indication should be coded from the case source in the appropriate clinical field.

A product's ATC classification should not be substituted for the patient's reported indication.

Automated Coding and Quality Control

Auto-Coding

Automated coding can improve speed and consistency where medication names are repetitive and well structured.

UMC provides WHODrug Koda as an automated coding service, and commercial safety/clinical systems may also provide coding engines.

Automation can be useful for:

However, product coding often depends on context that a simple text match does not contain.

Where Auto-Coding Can Fail

Non-Unique Brand Name

Source:

“Brand X”

Two WHODrug records contain the same name but different ingredients in different markets.

A text-only algorithm may select one without using country or ingredient context.

Strength Confused With Dose

Source:

“takes 20 mg daily”

The algorithm may map to a 20 mg product even though the patient takes two 10 mg tablets.

Substance Selected Instead of Product

Source:

exact brand and form are available

The engine returns the generic active-substance record because it has the highest lexical confidence.

The result is technically codable but unnecessarily loses product specificity.

Wrong Combination

Source:

a combination trade product

The engine finds one component and codes only that substance.

The exposure identity is fragmented.

Misspelling Produces Wrong Brand

A fuzzy match returns a product with a similar spelling but different active ingredient.

The result can create a false suspect substance in the safety database.

Human Oversight

Automated product coding should therefore be governed by confidence thresholds and review rules.

A practical model can be:

high-confidence unambiguous match → controlled auto-code

ambiguous/non-unique/context-dependent match → human review

missing or conflicting product information → coding query/follow-up/escalation.

The exact thresholds are organisation-specific operational controls rather than universal regulatory requirements.

WHODrug Koda and Other Coding Engines

UMC describes Koda as an automated coding service designed to improve coding efficiency, consistency and quality.

Use of an automated engine does not remove the organisation's responsibility for:

The quality question is not whether the tool uses AI.

It is whether the coding output reliably represents the source information.

Coding Quality Dimensions

WHODrug coding quality can be assessed across four dimensions.

Accuracy

Did the selected record represent the correct medicine?

Specificity

Was the most detailed supported record selected without inventing information?

Consistency

Would comparable source information be coded similarly across coders, affiliates and vendors?

Traceability

Can a reviewer reconstruct how the coding decision was made?

A code can be structurally valid yet still fail one or more of these quality dimensions.

Organisation-Specific Coding Convention

A global PV organisation benefits from a controlled WHODrug coding convention.

It can define how to handle:

The local convention should supplement current UMC guidance rather than contradict it.

Coding Quality Control

Case-level QC can ask:

These checks focus on medical/product meaning, not merely whether the identifier exists.

Inter-Coder Consistency

Differences between coders can reveal weak rules.

For example:

These differences can create systematic analytical bias.

Periodic coding-concordance review can therefore be useful.

The goal is not identical coding regardless of source context.

The goal is consistent application of the same decision principles.

Vendor Oversight

Outsourced coding should operate under the same standards as internal coding.

Useful controls include:

Turnaround time alone is not evidence of good coding quality.

Audit Trail

Coding changes should be auditable.

A reviewer should be able to distinguish:

These are different events and can have different implications for analysis.

Product Coding and Aggregate Analysis

WHODrug supports aggregation at several useful levels.

A reviewer may want to analyse:

The correct level depends on the safety question.

A product-specific manufacturing issue may disappear if analysis is performed only at active-substance level.

A class effect may be missed if analysis is restricted to one trade name.

Coding should preserve enough structure to allow both kinds of questions.

Product-Level Versus Substance-Level Signals

Consider two scenarios.

Product-Level Pattern

Cases cluster around:

Substance-level aggregation may obscure the pattern.

Substance-Level Pattern

The same adverse event appears across several products containing the same active substance.

Brand-level fragmentation may obscure the pattern.

WHODrug coding enables movement between these perspectives when product identification is sufficiently accurate.

Combination-Product Analysis

Combination products create another analytical choice.

A safety reviewer may need to know:

A structured medicinal-product terminology allows those analyses without destroying the original combination-product identity.

ATC and Class-Level Analysis

ATC can support therapeutic-class analyses, but the analyst should understand:

ATC is a useful classification system, not a universal pharmacovigilance case definition.

Standardised Drug Groupings

WHODrug also provides Standardised Drug Groupings (SDGs) for certain analysis use cases.

These are distinct from the core product-coding process.

They can support retrieval of defined drug groups, but the analyst should use the current SDG documentation and understand the grouping logic.

They should not be confused with MedDRA SMQs, which group medical-event terminology rather than medicinal products.

Practical Coding Workflow

A reliable WHODrug coding process can be organised into eight steps.

Step 1 — Preserve the Reported Drug Information

Capture the source wording as reported.

This can include:

The verbatim record is the evidence against which the coding decision can later be reviewed.

Step 2 — Determine What Kind of Information Was Reported

Ask whether the source identifies:

Do not begin by assuming a brand.

Step 3 — Search WHODrug

Search using the reported name.

Review:

Step 4 — Resolve Ambiguity With Context

Use reliable case information to distinguish plausible records.

Useful context can include:

If several possibilities remain, follow-up may be preferable to unsupported selection.

Step 5 — Select the Most Specific Supported Record

For C3, UMC recommends coding to the most detailed level supported by the available information.

This means specificity should increase only when the evidence supports it.

The coder should not add:

merely to reach a more detailed RID.

Step 6 — Confirm the Product Role

Ensure the medication is stored appropriately as:

WHODrug identity and medication role should not be confused.

Step 7 — Check the Version and Audit Trail

Record the applicable dictionary version.

If coding changed because of:

the reason should remain traceable.

Step 8 — Review the Whole Case

Confirm that the product coding is consistent with:

A code that looks correct in isolation can still contradict the overall case.

Worked Examples

Worked Example 1 — Exact Product Identification

Source:

“Patient used Brand A 25 mg tablets purchased in Germany.”

The current C3 data contain a matching product name, country, tablet form and 25 mg strength.

Coding approach

Select the most specific C3 record supported by those details.

Why

The source supports product-level specificity.

There is no reason to reduce the case to the active substance alone.

Worked Example 2 — Substance Only

Source:

“Patient was taking metformin.”

No brand, country-specific product, form or strength is reported.

Coding approach

Use the appropriate substance/generic record supported by the source.

Why

Assigning a specific trade product would add information that was never reported.

Worked Example 3 — Non-Unique Trade Name

Source:

“Patient took Brand B.”

WHODrug shows that Brand B can contain different ingredients in different markets.

Country and strength are not available.

Coding approach

Do not select one ingredient-specific record merely because it appears first.

Review the case for additional context and seek follow-up where important and feasible.

If the identity cannot be resolved, use the controlled broader/temporary approach permitted by the organisation's coding convention.

Why

An incorrect ingredient assignment can create a false suspect substance.

Worked Example 4 — Country Resolves the Product

Source:

“Brand C 10 mg, purchased in Country X.”

The same trade name exists elsewhere with a different ingredient.

Coding approach

Use the country information to identify the appropriate product record, assuming the source and current WHODrug data support the match.

Why

Country is clinically meaningful product-identification context.

Worked Example 5 — Dose Is Not Strength

Source:

“Patient takes 40 mg every morning.”

No product strength is stated.

Coding approach

Do not automatically select the 40 mg formulation.

Why

The dose could have been delivered by:

Dose should not be converted into strength without evidence.

Worked Example 6 — Fixed Combination

Source:

“Patient takes Brand D, containing substances X and Y.”

Coding approach

Code the fixed-combination product if the reported product can be identified.

Why

Creating separate X and Y medication entries would misrepresent the actual exposure.

Substance-level retrieval can still occur through WHODrug's structured ingredient relationships.

Worked Example 7 — Biosimilar Brand Known

Source:

“The patient received Biosimilar Brand E, batch 12345.”

Coding approach

Preserve and code the exact product brand where a matching record is available.

Retain the batch separately in the appropriate ICSR field.

Why

Product-specific traceability matters for biologicals; WHODrug coding does not replace batch information.

Worked Example 8 — Biological Brand Unknown

Source:

“Patient received active substance F.”

The reporter cannot identify the brand.

Coding approach

Code at the substance level supported by the source.

Why

Do not attribute the exposure to a reference product or biosimilar without evidence.

Worked Example 9 — Product Quality Complaint

Source:

“Brand G 100 mg prefilled syringe leaked during administration.”

The patient also reports reduced therapeutic effect.

Coding approach

Use the exact product record supported by brand/form/strength.

Capture:

in their appropriate fields/processes.

Why

Product identity, quality defect and clinical outcome are connected but distinct data elements.

Worked Example 10 — Follow-Up Improves Coding

Initial report:

“Antibiotic.”

Follow-up:

“It was Brand H 500 mg capsules.”

Coding approach

Update the product coding to the more specific supported record.

Preserve the initial source and coding history.

Why

The product became more identifiable because of new source information, not because the coder guessed.

Worked Example 11 — Missing Product

Source provides a legitimate marketed product that cannot be found in the installed WHODrug release.

Coding approach

Verify:

If still missing, follow the organisation's controlled temporary-coding process and use UMC's Change Request mechanism where appropriate.

Why

An official terminology gap should not be filled with an invented local WHODrug code.

Worked Example 12 — Fuzzy Match Is Wrong

Source:

“Brand J.”

The auto-coder assigns Brand I because the spelling is similar.

Brand I contains a different active substance.

Coding approach

Reject the automated match.

Search the full dictionary and use product context.

Why

Lexical similarity is not product identity.

Downstream Pharmacovigilance Implications

Coding Quality and Signal Detection

Product coding determines which cases enter product- and substance-level safety analyses.

The chain is:

source product information → WHODrug coding → product/substance grouping → case series → signal analysis

An upstream error can therefore become a downstream signal error.

For example:

wrong trade-name match → wrong active substance → case appears under wrong product → false product-event association.

The inverse can also occur:

specific product coded only to broad substance → product-specific pattern becomes diluted → manufacturing/formulation signal is harder to detect.

Coding Quality and Exposure Attribution

Accurate product identification is particularly important when several similar therapies are used sequentially.

A patient may have received:

If the wrong product is coded, the event can be attributed to the wrong exposure during cumulative review.

Chronology and exact product identity should therefore be assessed together.

Coding Quality and Reconciliation

Reconciliation between PV and other functions often depends on product matching.

For example:

Quality record:

Brand K 20 mg tablets, batch 111

PV case:

substance K

The records may represent the same patient and event, but the different specificity makes automated matching harder.

Consistent coding and retention of source product identifiers improve reconciliation across:

Coding Quality and Aggregate Reporting

Aggregate reports may summarise cases by:

WHODrug supports product/substance standardisation, but the analyst should document which level was used.

A count by substance is not equivalent to a count by exact marketed product.

This is especially important for:

Relationship With MedDRA

WHODrug and MedDRA solve complementary problems.

Terminology Primary question
WHODrug What medicinal product or substance was involved?
MedDRA What medical event, condition or related concept was reported?

A safety case can therefore be represented conceptually as:

WHODrug-coded product + MedDRA-coded event + case chronology/context = structured ICSR evidence.

The companion article MedDRA Coding in Pharmacovigilance: A Practical Guide explains the event-coding side of this relationship.

Inspection and Governance

Inspection Perspective

An inspector or quality reviewer evaluating WHODrug coding could ask:

The objective is not to prove that every case contains the maximum possible product detail.

The objective is to demonstrate that the coding reflects the best-supported product identity available from the source and that the process is consistent and traceable.

Illustrative Failure Modes

The following are hypothetical examples, not actual inspection findings.

First Exact Name Match Selected

A coder searches the brand and selects the first result without reviewing ingredients or country.

Why it fails: the name is non-unique and the case is assigned to the wrong active substance.

Substance-Level Coding Used Despite Exact Brand

A reporter provides exact brand, form and strength, but the coder selects only the generic substance.

Why it fails: clinically useful product specificity is unnecessarily lost.

Strength Derived From Daily Dose

The patient takes 20 mg/day and the coder selects the 20 mg presentation.

Why it fails: dose does not prove product strength.

Combination Split Into Separate Medicines

One fixed-dose combination becomes two medication records.

Why it fails: the actual exposure is misrepresented.

Market Share Used to Guess Biosimilar

The exact brand is not known, so the most commonly used local biosimilar is selected.

Why it fails: commercial probability is not source evidence.

Dictionary Version Not Recorded

Six months later, the same verbatim codes differently and no one can determine why.

Why it fails: WHODrug content is version-dependent.

Vendor Uses Different Release

The vendor sends identifiers from a newer version than the MAH system supports.

Why it fails: imports, coding consistency and aggregate grouping can diverge.

Auto-Coder Accepts Similar Spelling

A fuzzy match assigns the wrong brand with a different ingredient.

Why it fails: text similarity replaced product verification.

Missing Product Replaced With Local Fake Record

A coder creates an unofficial WHODrug-like identifier.

Why it fails: standardisation is lost and downstream data exchange becomes unreliable.

Batch Number Stored Only in Free Text

A biological product is coded correctly, but the batch is not retained in the appropriate field.

Why it fails: WHODrug product identity does not replace batch-level traceability.

Practical WHODrug Coding Checklist

Before finalising a medication code, verify:

Governance

WHODrug coding should connect four controls:

source-data quality → coding quality → terminology/version governance → analytical feedback.

The final feedback loop matters.

Aggregate reviewers may detect problems not visible in individual cases, such as:

These patterns should feed back into:

Product coding is therefore part of pharmacovigilance system quality, not merely data entry.

Key Takeaways

References

  1. Uppsala Monitoring Centre. WHODrug User Guide. September 2026. Current terminology, B3/C3 structure, Drug Code, C3 RID and product/substance concepts.
    https://who-umc.org/media/ebtbw4jm/whodrug-user-guide-september-2026.pdf

  2. Uppsala Monitoring Centre. WHODrug Best Practices, Version 7.0. Current coding and upversioning best-practice guidance for B3/C3.
    https://who-umc.org/media/q1kdtecs/whodrug-best-practices-vers-7-0.pdf

  3. Uppsala Monitoring Centre. How to use the WHODrug C3 format for drug coding, Version 3.0. Current C3 coding guidance.
    https://who-umc.org/media/dlnnqcsj/how-to-use-the-whodrug-c3-format-for-drug-coding-3-0-en.pdf

  4. Uppsala Monitoring Centre. WHODrug Global: What is WHODrug Global? Current product overview and release schedule.
    https://who-umc.org/whodrug/whodrug-global/what-is-whodrug-global/

  5. Uppsala Monitoring Centre. WHODrug Version Verification. Current and archived March/September verification documents.
    https://who-umc.org/whodrug/documentation/version-verification/

  6. Uppsala Monitoring Centre. WHODrug Global Structural Changes 2026, Version 3.0. March 2026.
    https://who-umc.org/media/w11lai1c/whodrug-global-structural-changes-2026-v3-0.pdf

  7. Uppsala Monitoring Centre. WHODrug Change Analysis Tool. Current service supporting impact analysis between WHODrug versions.
    https://who-umc.org/whodrug/whodrug-global/applications-and-services/

  8. Uppsala Monitoring Centre. WHODrug Koda. Current automated WHODrug coding service.
    https://who-umc.org/whodrug/whodrug-global/applications-and-services/koda/

  9. Uppsala Monitoring Centre. Technical guidance for use of WHODrug Global in XMLs uploaded in VigiFlow eReporting for Industry for E2B(R3) compliance, Version 3.0.
    https://who-umc.org/whodrug/documentation/industry-ereporting/

  10. Uppsala Monitoring Centre. Coding drug information with WHODrug. VigiFlow support guidance.
    https://support.who-umc.org/vigiflow/entering-and-structuring-data-in-reports/coding-drug-information-with-whodrug

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

Regulatory Note

This article explains WHODrug coding principles for pharmacovigilance as reviewed on 2 October 2026.

WHODrug Global is a licensed terminology maintained by Uppsala Monitoring Centre. The User Guide, Best Practices and C3 coding guidance provide terminology and methodological guidance; they do not themselves create universal legal pharmacovigilance reporting obligations.

Requirements for medicinal-product coding and identifiers in regulatory submissions vary by jurisdiction and submission system. Organisations should therefore apply current ICH E2B specifications, applicable regional implementation guidance and authority-specific requirements separately from their internal WHODrug coding strategy.

WHODrug content, identifiers, files and associated structures evolve between releases. The production release, format and regulatory mapping should be verified before implementing coding or data-exchange changes.

The worked examples and failure modes in this article are illustrative. They do not reproduce proprietary WHODrug records and are not presented as actual inspection findings.

Revision History

Related Articles

EudraVigilance Reporting: A Practical Guide to ICSR Submission

EudraVigilance reporting is an end-to-end regulated process from receipt of safety information to accepted E2B(R3) submission and subsequent follow-up. This article explains current EU post-authorisation ICSR reporting rules, reporting pathways, acknowledgement handling, data quality, corrections, compliance monitoring and QPPV governance.

How to Write an ICSR Case Narrative

Explains the regulatory purpose of the ICSR case narrative, what information belongs in it, how to organise chronology, distinguish reported facts from assessment, manage follow-up and contradictions, and produce a concise stand-alone medical story suitable for regulatory review.

ICH E2D(R1): What Changed in Post-Approval Pharmacovigilance

Explains why ICH E2D was revised, what changed in E2D(R1), how the new source and report classifications affect ICSR management, and what MAHs and QPPVs should have implemented in the EU after the 2026 transition.

Last reviewed: 2026-10-02

QPPV.com