XEVMPD Data Quality: Common Errors, Validation and Maintenance

How MAHs can maintain accurate and current XEVMPD data, identify common Article 57 data-quality problems, understand EMA validation, and build practical controls around submission and maintenance.

Audio Lesson 10 min

XEVMPD Data Quality: Common Errors, Validation and Maintenance

Introduction

XEVMPD compliance is sometimes treated as a submission task.

That is too narrow.

For a marketing authorisation holder (MAH), the practical requirement is not simply to submit medicinal-product information to the European Medicines Agency (EMA). The information must remain accurate and up to date throughout the relevant product lifecycle.

The Extended EudraVigilance Medicinal Product Dictionary (XEVMPD), also referred to in the Article 57 context as the Article 57 database, exists to support the standardised collection, reporting, coding and evaluation of medicinal-product information in the European Economic Area (EEA). EMA uses the information to support identification of medicines and pharmacovigilance activities. 2

This creates a different type of compliance problem from a one-time regulatory submission.

A product can have been submitted correctly at authorisation and become incorrect later.

A product record can also be technically accepted while containing information that subsequently requires correction or clarification.

The important operational question is therefore:

How does the MAH know that the information in XEVMPD remains accurate, consistent and current?

This article examines XEVMPD data quality from that perspective.

It focuses on:


Learning Objectives

After reading this article, the reader should be able to:


Regulatory Context

Article 57 and the XEVMPD

Article 57(2) of Regulation (EC) No 726/2004 establishes the legal basis for the submission of medicinal-product information to the EMA.

The EMA states that all holders of marketing authorisations for medicines in the EU and EEA must submit information on authorised medicines and keep that information up to date. 3

The information is submitted to XEVMPD using the Extended EudraVigilance Product Report Message (XEVPRM) schema. Companies may submit through the EudraVigilance Gateway or through the EMA's XEVMPD user interface. 4

This distinction matters:

submission is an event; maintenance is a lifecycle activity.

An MAH that successfully submits a product record but does not maintain it when relevant information changes does not have a complete data-quality control process.


What XEVMPD Is Used For

EMA describes XEVMPD as a database designed to support:

EMA also publishes selected Article 57 product information publicly. The published data include fields such as:

This illustrates an important point.

XEVMPD is not merely an internal regulatory database.

Its information contributes to the wider European medicines regulatory and pharmacovigilance information environment.


What Does "Data Quality" Mean?

Data quality is often used as if it means simply "correct."

In practice, several dimensions matter.

A useful framework is:

Accuracy

Does the value correctly represent the authorised medicinal product?

Completeness

Are the required and relevant data elements populated appropriately?

Consistency

Does the XEVMPD record agree with authoritative source information and related records?

Currency

Does the record reflect the current status of the medicinal product?

Standardisation

Are controlled terms, identifiers and structured fields used appropriately?

Traceability

Can the MAH explain where the information came from and why a change was made?

These dimensions are related but not identical.

A record can be complete but inaccurate.

It can be accurate at the time of submission but become outdated.

It can also contain individually correct fields that are inconsistent with one another.

Therefore:

"The record was accepted" is not equivalent to "the record is high quality."


How EMA Approaches XEVMPD Data Quality

EMA has established specific quality-control methodologies for Article 57 medicinal-product data.

The Agency's guidance library includes:

EMA has also described systematic quality review of Article 57 data submitted by industry, including activities aimed at ensuring that the information is accurate and up to date. 8

This is important for MAHs because it demonstrates that data quality is not merely an internal preference.

It is an explicit regulatory concern.


Technical Validation Is Not the Same as Content Validation

One of the most important distinctions in XEVMPD work is between technical acceptance and content quality.

A submission may undergo technical validation against the relevant message structure and business rules.

That answers questions such as:

But a technically valid message can still contain inappropriate content.

For example:

A product name may be syntactically acceptable but incorrectly represented.

Or:

A substance may be entered using an inappropriate term even though the XML is technically valid.

Or:

An authorisation status may be technically permitted but no longer reflect the actual regulatory status.

Therefore:

technical validation asks whether the submission can be processed;

content validation asks whether the information is appropriate.

The EMA's own XEVMPD training material describes an initial submission process involving technical validation followed by content validation and standardisation, with MAH review and correction where required. 9

That distinction should be built into an MAH's internal quality system.


Common XEVMPD Data-Quality Problems

The exact error profile varies by portfolio and operating model, but several categories recur.

1. Outdated Regulatory Information

A product record may accurately reflect the product at the time of initial submission but fail to reflect subsequent changes.

Potential triggers include:

The key control question is:

What internal event causes the MAH to review XEVMPD?

If the answer is "someone remembers to check it," the process is vulnerable.


2. Incorrect Product Naming

Medicinal-product names require structured treatment.

EMA has published specific best-practice guidance concerning the splitting of the full presentation name in XEVMPD. The guidance addresses how the full presentation name should be represented in the relevant structured elements. 10

This matters because a product name is not necessarily a single free-text field from a data-quality perspective.

The MAH needs to understand:

A common mistake is to treat the XEVMPD product name as something that can simply be copied from an SmPC title without considering the underlying data structure.


3. Substance Naming Problems

Substance information is another important quality area.

EMA has conducted quality-control activities involving the XEVMPD substance controlled vocabulary, including identification and merging of duplicate substance names. 11

This demonstrates why uncontrolled local naming can create problems.

A company may internally use:

XEVMPD requires the medicinal product to be represented using the appropriate structured terminology.

The internal product master should therefore not be assumed to be identical to the XEVMPD representation.


4. Controlled-Vocabulary Errors

XEVMPD depends heavily on standardised terminology.

This includes controlled information relating to areas such as:

The purpose of controlled vocabulary is not cosmetic.

Standardisation enables information to be searched, linked, analysed and interpreted consistently.

An apparently small terminology error can therefore have consequences beyond the individual record.


5. Inconsistent Product Information

Another important category is inconsistency between XEVMPD and authoritative source documents.

Potential sources include:

For example, suppose an MAH's regulatory database identifies one MAH entity while an XEVMPD record continues to identify a previous entity.

Each record may have been correct at a particular point in time.

Together, however, they are inconsistent.

That is a data-governance problem.


6. Incorrect or Outdated MAH Information

MAH information is particularly important because organisational changes can affect multiple product records.

Potential triggers include:

The control problem is therefore not simply:

"Was the XEVMPD record updated?"

It is:

"Does the organisation have a controlled process that identifies every XEVMPD record affected by an organisational change?"

That is a much stronger question.


7. Pharmacovigilance Contact and PSMF Information

Article 57 data include information relevant to pharmacovigilance contacts and the PSMF.

EMA's publicly available Article 57 data include the country of location of the PSMF and MAH pharmacovigilance contact information. 12

This creates an obvious maintenance requirement.

If a relevant pharmacovigilance-system change occurs, the MAH should not rely solely on the PV department to remember whether an Article 57 update is required.

The change-control process should identify the relevant downstream systems and records.


8. Duplicate or Fragmented Records

Data quality can also be affected by duplicate or incorrectly fragmented representations.

This can occur when:

EMA's historical quality-control activities around substance names illustrate the importance of deduplication and controlled terminology. 13

The lesson is broader than substances:

A medicinal-product master-data environment needs controls against both incorrect records and unnecessary duplication.


9. Lifecycle Changes Not Reflected in XEVMPD

One of the most common conceptual errors is treating the initial submission as the main compliance event.

In reality, medicinal products move through lifecycle states.

Examples include:

Each potentially creates a question:

Does this change affect information held in XEVMPD?

That question should be embedded in the regulatory change-control process.


A Practical Example

Consider a hypothetical generic medicinal product.

At initial authorisation, the MAH submits:

The submission is technically accepted.

Six months later:

The regulatory team updates its regulatory database.

The PV team updates relevant internal records.

But nobody triggers an XEVMPD review.

The XEVMPD record now contains information that was once correct but is no longer current.

Nothing "went wrong" during the original submission.

The failure occurred in lifecycle governance.

This is why XEVMPD quality should be treated as a controlled process rather than a submission project.


Validation Framework

A useful internal validation process can operate at several levels.

Level 1 — Source Validation

Compare the XEVMPD record against authoritative source documents.

Potential sources include:

The principle is simple:

Every important XEVMPD value should have an identifiable authoritative source.


Level 2 — Structural Validation

Check whether the record uses the appropriate data structure.

Questions include:

This is where understanding the XEVPRM structure becomes important.


Level 3 — Content Validation

Ask whether the information actually describes the authorised medicinal product correctly.

For example:


Level 4 — Cross-System Reconciliation

Compare XEVMPD with relevant internal systems.

Potential comparison sources include:

The goal is not necessarily to make every system identical.

Different systems serve different purposes.

The goal is to identify material discrepancies that require investigation.


The Reconciliation Trap

Reconciliation is valuable, but "make everything match" is not a sufficient methodology.

Suppose the regulatory database contains a product description optimised for regulatory document management while XEVMPD requires a structured representation.

A literal string comparison may report a difference.

That does not necessarily mean one system is wrong.

Therefore reconciliation should distinguish between:

Expected differences

Differences caused by legitimate system structure or purpose.

Unexplained differences

Differences that require investigation.

Confirmed errors

Differences where an authoritative source establishes that one representation is incorrect or outdated.

This distinction prevents reconciliation from becoming a meaningless exercise in chasing formatting differences.


Data Quality Dimensions in Practice

A practical XEVMPD quality assessment can use the following matrix.

Dimension Question Example failure
Accuracy Is the value correct? Wrong strength
Completeness Is required information present? Missing relevant field
Consistency Does it agree with authoritative records? Different MAH
Currency Does it reflect the current lifecycle state? Previous MAH retained
Standardisation Is the appropriate controlled terminology used? Incorrect substance term
Traceability Can the source and change history be demonstrated? No documented basis for update

This framework is useful because it turns the vague concept of "data quality" into assessable controls.


Initial Submission Controls

A strong initial-submission process should not begin with XEVMPD entry.

It should begin with source-data preparation.

Step 1: Identify the Authoritative Sources

Determine which documents and systems provide the source for each important data element.

Step 2: Build the Product Data Set

Assemble the information required for the XEVMPD submission.

Step 3: Perform Independent Review

Where appropriate, have a second qualified person review the prepared data.

Step 4: Submit

Submit using the applicable XEVPRM process or XEVMPD interface.

Step 5: Review the Acknowledgement

Do not treat the acknowledgement as the end of the process.

Review the result and determine whether further action is required.

Step 6: Reconcile the Final Record

Confirm that the submitted representation corresponds to the intended medicinal-product record.

This creates a controlled chain:

source → preparation → review → submission → acknowledgement → reconciliation


Maintenance Controls

The strongest maintenance processes are event-driven.

Instead of relying solely on a periodic reminder, define regulatory and organisational events that trigger an XEVMPD assessment.

Examples include:

The trigger should not necessarily mean that an XEVMPD update is always required.

It should mean:

"Assess whether an XEVMPD update is required."

That is a more controlled approach.


Periodic Review

Event-driven controls should be complemented by periodic review.

Why?

Because not every failure originates in the formal change-control system.

Potential failures include:

A periodic review provides an independent opportunity to detect residual problems.

The frequency should be risk-based.

A small, stable portfolio may justify a different approach from a large multinational portfolio undergoing frequent regulatory change.

The important principle is that the rationale should be documented.


What Should a Periodic XEVMPD Review Look Like?

A useful review might include:

Portfolio completeness

Is the expected product population represented?

Regulatory status

Does the recorded status correspond to the current regulatory situation?

Product identity

Are names, substances, strengths, pharmaceutical forms and routes appropriate?

MAH information

Is the current MAH represented correctly?

Pharmacovigilance information

Are relevant PV contact and PSMF-related data current?

Controlled vocabulary

Are appropriate controlled terms used?

Exceptions

Are discrepancies documented, investigated and resolved?

Change history

Can material corrections be traced to an underlying source or change event?

This is much more useful than simply asking:

"Did we check XEVMPD?"


Managing Discrepancies

Not every discrepancy has the same significance.

A practical classification might distinguish:

Critical

Potentially affects identification, regulatory status or information with significant downstream implications.

Major

Represents a material inconsistency or outdated information requiring timely correction.

Minor

Limited-impact issue such as a non-material administrative or formatting discrepancy.

The exact classification system should be defined by the MAH's own quality system.

The important principle is proportionality.

A typo that has no effect on medicinal-product identification should not automatically be treated in the same way as an incorrect active substance or MAH.


Root-Cause Analysis

Repeated XEVMPD errors should not be handled only as individual corrections.

Suppose ten products contain the same type of error.

The immediate action is:

Correct the ten records.

The quality-system question is:

Why did the same error occur ten times?

Possible root causes include:

This is where XEVMPD data quality becomes a pharmacovigilance governance issue rather than a simple data-entry issue.


Outsourced XEVMPD Activities

Many MAHs outsource some or all Article 57 data activities.

Outsourcing can be efficient.

It does not remove the need for MAH oversight.

The MAH should understand:

The critical governance question is:

Can the MAH demonstrate that it controls the outsourced process rather than simply assuming that the vendor is maintaining the data correctly?


Vendor Quality Controls

Where XEVMPD activities are outsourced, useful controls can include:

EMA notes that where a company uses a third-party service provider for medicine-data submission, training of a staff member of the third-party provider can satisfy the training requirement for submission activities. 14

That does not eliminate the MAH's need to understand and oversee the process.


A Worked Data-Quality Example

Consider a fictional generic medicine:

Product: Generic Drug 10 mg tablets
MAH: Example Pharma Ltd
Route: Oral

The initial XEVMPD record is correct.

A year later, the MAH transfers the marketing authorisation to:

Example Pharma Europe S.à r.l.

The regulatory database is updated.

The product's approved name also changes as part of a regulatory variation.

The XEVMPD record remains unchanged.

A periodic reconciliation identifies:

The discrepancy is therefore not simply a data-entry error.

The root cause is a missing change-control interface between regulatory lifecycle management and XEVMPD maintenance.

The corrective action should therefore have two components:

Immediate correction

Update the affected XEVMPD record.

Preventive action

Modify the regulatory change process so that relevant changes automatically trigger an XEVMPD assessment.

This is the difference between:

fixing data

and

fixing the system that produced bad data.


Another Example: The Technically Valid Wrong Substance

Suppose an MAH submits a product using a substance term that is accepted by the submission system but does not represent the intended standardised substance concept appropriately.

The submission may pass technical validation.

The issue may nevertheless be identified during content-quality review.

The correct response is not:

"The system accepted it, so it must be correct."

The correct response is:

  1. identify the authoritative substance concept;
  2. review the applicable controlled vocabulary;
  3. determine the correct representation;
  4. correct the XEVMPD data;
  5. assess whether similar products are affected;
  6. determine whether the internal source system also needs correction;
  7. investigate why the wrong representation was selected.

This example illustrates why technical acceptance and data quality are separate control objectives.


Another Example: The Missing Maintenance Trigger

Suppose an MAH has 40 authorised products.

A regulatory variation changes the pharmaceutical form for three products.

The regulatory team updates the regulatory database.

No XEVMPD trigger exists in the variation procedure.

Six months later, a review finds that the three XEVMPD records still contain the previous information.

The immediate problem is outdated product data.

The deeper problem is process design.

The appropriate CAPA question is therefore:

What mechanism should have connected regulatory lifecycle change with Article 57 maintenance?

Potential corrective measures might include:


How to Build a Practical XEVMPD Quality System

A proportionate framework can be built around five controls.

1. Ownership

Define who owns the process.

Ownership should not be confused with performing every task.

There may be separate roles for:

But accountability for the overall process should be clear.


2. Source-of-Truth Mapping

For important XEVMPD data elements, identify the authoritative source.

For example:

XEVMPD information Potential authoritative source
Product identity Approved regulatory documentation
Substance Controlled regulatory/master-data source
Strength Approved product information
Pharmaceutical form Approved product information
Route Approved product information
MAH Current regulatory record
PSMF information Current PV governance record
PV contact information Current PV organisational record

The exact source hierarchy should be defined by the MAH.

The important point is that the source should be explicit.


3. Change Triggers

Define events that require XEVMPD assessment.

This should be integrated into the existing regulatory lifecycle rather than operated as a completely separate process.


4. Quality Review

Define how submitted and maintained data are checked.

This may include:


5. Evidence

Retain evidence showing:

This is essential if the organisation needs to demonstrate control during an audit or inspection.


Metrics That Actually Tell You Something

A weak XEVMPD KPI might be:

"Number of XEVMPD submissions."

That measures activity.

It does not measure quality.

More informative metrics include:

First-pass acceptance rate

How often are submissions accepted without requiring correction?

Data discrepancy rate

How many records contain identified discrepancies during review?

Correction ageing

How long do identified data-quality issues remain unresolved?

Lifecycle-trigger compliance

What proportion of relevant regulatory changes received an XEVMPD assessment within the defined timeframe?

Recurrent error rate

How often does the same type of error recur?

Reconciliation coverage

What proportion of the relevant portfolio has undergone the defined reconciliation?

Vendor error rate

Where activities are outsourced, how frequently are vendor-generated errors identified?

These metrics provide information about the health of the process rather than simply its volume.


When a Data Error Becomes a Governance Problem

A single isolated error does not necessarily indicate a systemic failure.

Repeated errors may.

Consider three scenarios.

Scenario 1

One product contains an incorrect administrative value.

It is detected promptly and corrected.

This may be an isolated data-quality event.

Scenario 2

Twenty products contain the same incorrect value.

This suggests a systematic problem.

Scenario 3

The same error has been identified three times and previous corrective actions failed to prevent recurrence.

This suggests a control-effectiveness problem.

The appropriate response should therefore be proportional to:


XEVMPD and Pharmacovigilance

Although XEVMPD is fundamentally medicinal-product master data, it has a direct pharmacovigilance relevance.

EudraVigilance relies on reliable identification of medicinal products.

EMA describes XEVMPD as supporting accurate identification of medicines, particularly medicines included in reports of suspected adverse reactions. 15

This means poor product data can potentially affect the quality of downstream pharmacovigilance analysis.

For example, inconsistent medicinal-product representations may make it more difficult to:

Therefore:

Medicinal-product master-data quality is part of the infrastructure supporting pharmacovigilance data quality.

This is one reason XEVMPD should not be viewed solely as a regulatory-administration task.


What Should the QPPV Know?

The QPPV does not necessarily need to perform XEVMPD data entry.

But the QPPV should understand the governance implications.

Relevant questions include:

The QPPV's role is therefore primarily one of oversight and assurance, not necessarily operational data maintenance.


XEVMPDweb and the Current Transition

The technical interface used by external users is also changing.

EMA made the upgraded XEVMPDweb user interface available to external users from 10 February 2026. EMA stated that the existing XEVMPD/Art.57 EVWEB and XEVMPDweb would coexist during a three-month transition period, after which external users would be required to use XEVMPDweb. 16

The existence of a new interface does not change the fundamental data-quality obligation.

A new user interface may change:

It does not change the underlying principle:

The MAH remains responsible for submitting and maintaining accurate medicinal-product information.

Therefore a system or interface migration should itself be treated as a controlled change.


Migration and System-Change Risk

Whenever an MAH changes:

there is a risk of introducing data-quality problems.

A migration control should therefore consider:

A technically successful migration is not necessarily a successful data migration.

The question should be:

Does the migrated record remain correct and fit for its intended regulatory purpose?


Audit Questions for XEVMPD Data Quality

An auditor assessing an MAH's XEVMPD process could ask:

Governance

Data sources

Submission

Maintenance

Quality control

Outsourcing

CAPA

Evidence

These questions test whether XEVMPD is being managed as a controlled process.


A Practical XEVMPD Data-Quality Checklist

Before considering the process adequately controlled, an MAH should be able to answer "yes" to the relevant questions below.

Product data

Regulatory data

PV information

Process

Outsourcing

Evidence


The Most Important Distinction

The strongest XEVMPD quality systems understand the difference between:

submission compliance

and

data-quality governance.

Submission compliance asks:

Did we submit the required information?

Data-quality governance asks:

Is the information still accurate, complete, consistent, standardised and current, and can we demonstrate how we know?

The second question is substantially more demanding.

It is also the question that matters most for sustainable compliance.


Key Takeaways

XEVMPD is not a one-time submission exercise.

The MAH must maintain relevant medicinal-product information and ensure that it remains accurate and up to date. 17

The most important lessons are:

  1. Technical acceptance does not equal content quality.

  2. Initial submission and lifecycle maintenance should be controlled separately.

  3. Regulatory changes should trigger an assessment of whether XEVMPD data require updating.

  4. Product naming, substance terminology and controlled vocabularies require particular attention.

  5. Cross-system reconciliation is useful, but differences must be interpreted rather than blindly eliminated.

  6. Outsourcing does not eliminate the MAH's need for process oversight.

  7. Periodic review should complement event-driven maintenance.

  8. Repeated errors should trigger root-cause analysis rather than repeated data correction alone.

  9. Useful metrics should measure quality, timeliness and recurrence rather than simply submission volume.

  10. XEVMPD data quality matters to pharmacovigilance because reliable medicinal-product identification supports downstream safety-data activities.

The practical test of an effective XEVMPD process is therefore not whether an MAH can produce evidence of successful submissions.

It is whether the organisation can demonstrate a controlled lifecycle from:

authoritative source → data preparation → quality review → submission → acknowledgement → maintenance → reconciliation → correction → continuous improvement.


References

  1. European Parliament and Council. Regulation (EC) No 726/2004 laying down Community procedures for the authorisation, supervision and pharmacovigilance of medicinal products for human and veterinary use. Article 57(2).

  2. European Commission. Commission Implementing Regulation (EU) No 520/2012 on the performance of pharmacovigilance activities provided for in Regulation (EC) No 726/2004 and Directive 2001/83/EC.

  3. European Medicines Agency. Data on medicines (ISO IDMP standards): post-authorisation — Reporting requirements for marketing-authorisation holders.

  4. European Medicines Agency. How to submit information on authorised and investigational medicines. Current XEVMPD and XEVPRM submission guidance.

  5. European Medicines Agency. Guidance documents related to data submission for authorised medicines. Includes:

  6. Data quality control methodology for data submitted under Article 57(2) of Regulation (EC) No 726/2004.
  7. Measures for Article 57 data quality assurance.
  8. Quality control of medicinal-product data submitted as per the legal requirement introduced by Article 57(2) of Regulation (EC) No 726/2004.
  9. Guidance on controlled vocabularies and medicinal-product naming.

  10. European Medicines Agency. Quality control of medicinal product data submitted as per the legal requirement introduced by Article 57(2) of Regulation (EC) No 726/2004. EMA/661709/2014 Rev. 7. Last updated 10 June 2025.

  11. European Medicines Agency. Measures for Article 57 data quality assurance. EMA/465609/2015.

  12. European Medicines Agency. Data quality control methodology for data submitted under Article 57(2) of Regulation (EC) No 726/2004. EMA/227883/2014.

  13. European Medicines Agency. European Medicines Agency splitting of the full presentation name of the medicinal product best practice: procedure and principles to handle product name in the EudraVigilance Medicinal Product Dictionary (XEVMPD). EMA/327516/2014 Rev. 3.

  14. European Medicines Agency. European Medicines Agency substance names best practice: procedure and principles to handle substance name in the substance management system. EMA/40951/2014.

  15. European Medicines Agency. Electronic submission of Article 57(2) data: questions and answers. EMA/159776/2013, Version 1.14.

  16. European Medicines Agency. User manual for the eXtended EudraVigilance Medicinal Product Dictionary (XEVMPD) user interface (XEVMPDweb). EMA/389113/2025.

  17. European Medicines Agency. Extended EudraVigilance medicinal product dictionary (XEVMPD) training.

  18. European Medicines Agency. Public data from Article 57 database.

Revision History