XEVMPD Data Quality: Reconciliation, Completeness and Detecting Hidden Errors

Introduction

The quality of medicinal-product data in the Extended EudraVigilance Medicinal Product Dictionary (XEVMPD) is an important part of the regulatory infrastructure supporting pharmacovigilance in the European Union and European Economic Area.

Marketing authorisation holders (MAHs) are required to submit information on medicinal products to the European Medicines Agency (EMA) under Article 57(2) of Regulation (EC) No 726/2004 and to keep that information up to date. The requirement applies to medicinal products authorised through the centralised, national, mutual-recognition and decentralised procedures, subject to the applicable scope of the legislation. EMA specifies timeframes for initial submissions and for amendments to the terms of marketing authorisations. [1][2]

For an MAH, however, compliance with the submission requirement is only one aspect of data quality. A medicinal-product record may have been submitted successfully and may remain present in XEVMPD while containing information that is incomplete, incorrect, inconsistent with another authoritative source, or no longer current.

This distinction is important because XEVMPD data are not maintained independently of the wider pharmacovigilance system. Product information is used in the regulatory and pharmacovigilance environment for identification and analysis of medicinal products. EMA has therefore undertaken systematic quality-control activities on Article 57 data and has published methodologies and guidance addressing the quality of submitted information. [3][4]

The practical challenge for an MAH is consequently broader than ensuring that XEVPRM messages are accepted.

The organisation needs to be able to demonstrate that the medicinal-product information it maintains in XEVMPD represents the applicable regulatory state of its products, that changes are captured through the product lifecycle, and that discrepancies are identified and corrected in a controlled manner.

This is where reconciliation becomes important.

A useful reconciliation does not merely compare two databases and list differences. It establishes what the data should represent, compares that expected state with the XEVMPD record, investigates discrepancies and determines whether an apparent error is isolated or indicative of a wider control problem.

Learning Objectives

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

• explain why successful XEVPRM submission does not establish complete data quality;
• distinguish completeness, correctness, consistency, currency and traceability;
• identify appropriate sources against which XEVMPD information may be reconciled;
• distinguish a data discrepancy from a confirmed data error;
• investigate discrepancies using a source-to-record data lineage;
• recognise when an individual error may indicate a wider population-level problem;
• design a proportionate XEVMPD reconciliation process;
• distinguish corrective data maintenance from corrective and preventive action;
• understand how product-data quality can affect downstream pharmacovigilance activities;
• develop meaningful metrics for monitoring XEVMPD data quality.

The 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 information is submitted electronically using the Article 57 data format, implemented through the Extended EudraVigilance Product Report Message (XEVPRM) and maintained in XEVMPD. [1][2]

EMA currently describes XEVMPD as the Article 57 database and provides requirements and guidance for the submission and maintenance of authorised-medicine information. [2][5]

The MAH's obligation is not satisfied merely by creating an initial record. Information must be maintained when relevant changes occur. EMA specifies, for example, that amendments to the terms of a marketing authorisation following variation, transfer, renewal, suspension, revocation or withdrawal are subject to notification within the applicable timeframe. [2]

This makes XEVMPD a lifecycle data-management responsibility rather than a one-time submission exercise.

A product record that was accurate when first submitted may become inaccurate later if the regulatory state changes and the corresponding product information is not maintained.

Technical Acceptance and Substantive Accuracy

XEVMPD submissions are subject to validation against the applicable schema and business rules. EMA describes technical validation as part of the Article 57 data-submission process. These controls are important because they prevent or reject certain types of invalid or inconsistent submissions. [5][6]

Technical validation nevertheless has a defined purpose.

It establishes that a submitted message satisfies the rules being applied by the system.

It does not establish that every value in the message corresponds to the correct underlying regulatory source.

Consider a simple example.

An MAH submits a product record containing a pharmaceutical form that is represented using a valid controlled term. The message passes the relevant validation rules.

The pharmaceutical form in the approved regulatory documentation is different.

The submission may therefore be technically acceptable while the medicinal-product information is substantively incorrect.

The distinction can be expressed as follows:

These are related controls, but they answer different questions.

What Does "Good" XEVMPD Data Mean?

Data quality is easier to assess when its dimensions are defined explicitly.

For medicinal-product data, five dimensions are particularly useful:

1. completeness;
2. correctness;
3. consistency;
4. currency;
5. traceability.

These dimensions should not be treated as interchangeable.

Completeness

Completeness asks whether the population and information that should be represented are actually represented.

At portfolio level, the question might be:

Are all medicinal products within the defined Article 57 population represented in XEVMPD?

At record level, the question becomes:

Are the applicable data elements populated appropriately?

Completeness requires a defined scope.

For example, an MAH may have 250 products in an internal regulatory portfolio. A comparison with XEVMPD identifies 247 apparent matches.

It would be tempting to conclude that three products are missing.

That conclusion is premature.

The internal portfolio may contain products outside the population being reconciled. A product may have been represented using an unexpected identifier. A duplicate may exist. A lifecycle event may have changed the expected representation. Alternatively, the internal portfolio itself may be incomplete.

The first finding is therefore:

Three records require investigation.

Only after the discrepancies have been investigated can the organisation determine whether the problem is actually incomplete XEVMPD data.

Correctness

Correctness concerns whether the information in XEVMPD accurately represents the underlying medicinal product and its applicable regulatory information.

Examples include:

• product name;
• pharmaceutical form;
• route of administration;
• strength;
• substance;
• organisation;
• marketing authorisation information;
• legal basis;
• relevant lifecycle information.

Correctness requires an appropriate source against which the value can be assessed.

A value is not necessarily correct because it is present, because it has been used historically, or because the system accepts it.

Consistency

Consistency concerns agreement between related representations of the same information.

Examples may include comparison of XEVMPD with:

• the internal regulatory master;
• the applicable marketing authorisation documentation;
• controlled organisational data;
• product master data;
• other relevant regulatory systems.

Consistency requires interpretation.

Two systems may legitimately contain different representations because they have different purposes or data models. A difference therefore does not automatically indicate an error.

The relevant question is:

Is the difference expected, explainable and controlled?

Currency

Currency concerns whether the record reflects the current applicable regulatory state.

This is particularly important for lifecycle events.

A product may undergo:

• variation;
• renewal;
• transfer;
• suspension;
• revocation;
• withdrawal;
• other changes affecting the terms of the marketing authorisation.

A record that was correct before the event may no longer be correct afterward.

Currency therefore cannot be demonstrated solely by showing that the record was once correct.

The organisation needs a process that connects regulatory change to XEVMPD maintenance.

Traceability

Traceability concerns whether the organisation can reconstruct the origin and history of the information.

For an important data element, an investigator should ideally be able to move from:

XEVMPD value

to

submission

to

internal source

to

regulatory evidence

to

regulatory event or decision.

The exact implementation will depend on the organisation's systems and procedures.

The principle is straightforward: an important regulatory-data value should not exist without a defensible explanation of where it came from and why it has its current state.

Reconciliation as a Control

Reconciliation is often described as a comparison between two datasets.

That description is incomplete.

The purpose of reconciliation is to determine whether the actual data representation corresponds to the expected state.

A useful conceptual model is:

authoritative source

↓

expected regulatory state

↓

expected XEVMPD representation

↓

actual XEVMPD representation

↓

discrepancy

↓

investigation

↓

root cause

↓

correction and verification

The important step is the construction of the expected state.

Without it, the reconciliation may identify differences without establishing whether those differences matter.

Defining the Reconciliation Population

The first step in a reconciliation is to define the population being assessed.

A statement such as:

"Reconcile the XEVMPD database against the regulatory database."

is insufficient.

The organisation should define what is included.

For example:

All medicinal products for which the MAH holds an applicable EEA marketing authorisation as of the defined reconciliation date.

The exact population definition will depend on the purpose of the exercise.

A periodic portfolio reconciliation may have one scope.

A transfer-related reconciliation may have another.

A post-migration reconciliation may focus on records affected by the migration.

Scope should therefore be documented before the comparison begins.

Establishing the Expected State

The next step is to determine what each record should represent.

This requires appropriate source information.

There is not necessarily one universal "source of truth" for every field.

The authoritative source should be determined according to the particular data element and the organisation's governance model.

For example:

The purpose is not to declare one database superior to all others.

It is to establish which source should be used to determine the expected value for the question being investigated.

A Simple Reconciliation Example

Consider a hypothetical generic medicine:

Generic Medicine A 10 mg tablets

The regulatory source indicates:

Marketing authorisation holder: Company B

The internal regulatory master also indicates:

Company B

XEVMPD contains:

Company A

This is a clear discrepancy.

It is not yet a complete root-cause finding.

The investigator should determine:

• when Company B became the MAH;
• whether the change resulted from a transfer;
• whether the transfer was completed in the applicable regulatory process;
• when XEVMPD should have been updated;
• which organisation identifier was used;
• whether the XEVMPD record was subsequently maintained;
• whether other products affected by the same transfer show the same problem.

The final conclusion might be:

One product record contains an incorrect MAH.

Alternatively, the investigation may establish:

A portfolio-level transfer was not incorporated into the XEVMPD maintenance process, affecting 37 medicinal-product records.

The second finding is materially different.

From Discrepancy to Root Cause

A reconciliation should distinguish between the observation and the explanation.

For example:

Observation: XEVMPD shows Company A.

Expected state: Company B.

Discrepancy: XEVMPD does not reflect the current MAH.

Root cause: The regulatory transfer process did not generate or communicate the required XEVMPD maintenance activity.

These are four different statements.

The first describes what was observed.

The second describes what should have been present.

The third describes the difference.

The fourth explains why the difference occurred.

This distinction is important when determining corrective action.

When One Error Indicates a Larger Problem

A single incorrect record can represent either an isolated mistake or evidence of a systemic control weakness.

Suppose one product has an incorrect pharmaceutical-form mapping.

The investigation should ask how the value was generated.

If the answer is:

The mapping was selected manually for this product.

the issue may be isolated.

If the answer is:

The same mapping table was used for 500 products.

the appropriate question becomes:

Are the other 499 records affected?

The original discrepancy has now become a sampling trigger for a wider investigation.

This is one of the most important analytical uses of reconciliation.

It does not merely find errors.

It can reveal the mechanism by which errors enter the data.

Worked Example: A Missing Product

Assume that an MAH's defined regulatory population contains 100 products.

The XEVMPD reconciliation identifies 98 apparent matches.

Two products do not match.

The investigation produces the following results:

The original 2% discrepancy rate therefore does not represent a 2% XEVMPD data error rate.

One discrepancy was caused by a scope-definition problem.

The other represented an actual data-maintenance issue.

This illustrates why raw match percentages should not be interpreted without investigating the underlying discrepancies.

Worked Example: A Stale Record

Consider a product whose XEVMPD record was created in January.

In October, the marketing authorisation is transferred to another MAH.

The XEVMPD record still shows the former MAH during a review in December.

The error is not necessarily a failure of the original submission.

The original record may have been entirely correct.

The problem occurred later.

The investigation should therefore examine the lifecycle process:

1. How was the transfer captured internally?
2. Which function was responsible for identifying the XEVMPD impact?
3. Was the required XEVMPD maintenance activity initiated?
4. Was the submission prepared correctly?
5. Was the change acknowledged?
6. Was the resulting XEVMPD record checked?
7. Were other transferred products reviewed?

This is a lifecycle-management investigation rather than a simple data-entry investigation.

Worked Example: A Technically Valid but Incorrect Value

Suppose an authorised product has a particular pharmaceutical form.

The XEVMPD submission contains another pharmaceutical form that is a valid controlled term.

The XEVPRM is accepted.

During a subsequent reconciliation, the discrepancy is identified.

The investigation finds that the data-entry specialist selected the wrong valid term from a controlled list.

The problem is therefore not that the terminology was invalid.

The problem is that the terminology was applied incorrectly.

This distinction is useful because the corrective action should address the actual failure mechanism.

Possible controls might include:

• clearer source-data instructions;
• improved mapping tables;
• reviewer verification;
• training;
• automated comparison against internal master data;
• controlled maintenance of mapping logic.

The appropriate response depends on the root cause and the affected population.

Reconciliation and Data Lineage

Data lineage is particularly useful where XEVMPD information is assembled through several systems.

Consider the following chain:

Approved regulatory document

↓

Regulatory information system

↓

Internal product master

↓

XEVMPD mapping

↓

XEVPRM

↓

XEVMPD

If a final value is incorrect, the investigation can move backwards through the chain.

For example:

• Was the regulatory source interpreted incorrectly?
• Was the internal master incorrect?
• Was the mapping incorrect?
• Was the wrong XEVPRM operation selected?
• Was the correct submission subsequently superseded?
• Was the XEVMPD record changed during an EMA quality-control activity?

The answer determines where corrective action belongs.

EMA Quality Control and the Local Database

EMA's published quality-control methodology is particularly relevant to this issue.

EMA performs quality-control activities on Article 57 medicinal-product information and may amend medicinal-product entities as part of that process. The current quality-control document also advises organisations maintaining local databases to review and retrieve product entities that have been amended by EMA and to incorporate the corrected information into their internal systems before the next relevant maintenance submission. [3]

This creates an important bidirectional consideration.

The internal system may be used as a source for XEVMPD submissions.

At the same time, XEVMPD may undergo Agency quality-control activity that changes the representation.

The organisation therefore needs to consider how corrections made in the regulatory environment are reflected back into its own data.

A local database that is never reconciled after external correction can become a source of recurring discrepancies.

Historical Data and Error Dating

When an error is identified, it is useful to establish when the error began.

Suppose a product has been represented incorrectly since 2023 and the issue is discovered in 2026.

The investigation should consider:

• when the incorrect value was introduced;
• which submissions contained it;
• whether the product changed during the period;
• whether related products were affected;
• whether downstream processes used the incorrect representation;
• whether the issue was previously detected and not corrected.

The purpose is not simply historical curiosity.

Dating the error helps determine its population impact and whether downstream activities may require assessment.

Reconciliation After Regulatory Change

Certain regulatory events are particularly suitable for event-driven reconciliation.

These may include:

• marketing-authorisation transfers;
• major variations;
• renewals;
• suspension or withdrawal;
• acquisition or divestment of portfolios;
• changes in legal entity;
• regulatory-system migrations;
• major vendor changes.

For example, following a portfolio acquisition, the organisation could identify all products acquired, establish their expected regulatory state and verify that the corresponding XEVMPD information has been appropriately represented.

This is more targeted than waiting for the next periodic reconciliation to discover lifecycle discrepancies.

Reconciliation After System Migration

System migration creates a different type of risk.

The source data may be correct before migration, but information can be lost or transformed during the transition.

Potential issues include:

• changed identifiers;
• altered terminology;
• incorrect organisation mappings;
• loss of lifecycle history;
• incorrect product relationships;
• changed data conventions;
• incomplete transfer of historical records.

A migration reconciliation should therefore examine more than record counts.

A result such as:

10,000 records migrated from the old system to the new system.

does not demonstrate that the information retained its intended meaning.

The relevant question is whether the information and relationships that matter were preserved.

Full Versus Risk-Based Reconciliation

Not every reconciliation has to use the same method.

A full population reconciliation provides comprehensive coverage where the organisation has the capability and where the risk warrants it.

A risk-based approach may instead use targeted testing.

Relevant selection criteria can include:

• recent lifecycle changes;
• complex products;
• multiple strengths or pharmaceutical forms;
• recent transfers;
• previous data-quality findings;
• new vendors;
• system changes;
• products with unusual regulatory histories.

Sampling should be linked to the purpose of the exercise.

A random sample can be useful for estimating general quality.

A targeted sample is useful for testing known areas of risk.

The two approaches should not be confused.

What Should Happen When a Discrepancy Is Found?

A useful investigation can be structured around six questions.

What is different?

Identify the precise data element or record discrepancy.

What should it be?

Establish the expected state using the appropriate authoritative source.

Why is it different?

Determine the immediate and underlying causes.

How many other records may be affected?

Assess the potential population.

Does the discrepancy have downstream significance?

Consider whether product identification, regulatory reporting, pharmacovigilance or other processes may have relied on the incorrect information.

What needs to change?

Correct the affected data and address the underlying control weakness where necessary.

This structure prevents reconciliation from becoming an exercise in generating unresolved exception lists.

Data Correction and CAPA Are Different Activities

A common mistake is to treat correction of the XEVMPD record as the complete corrective action.

Suppose ten products contain the same incorrect mapping.

The records should be corrected.

That does not necessarily resolve the underlying problem.

The organisation should determine why the mapping was wrong and why the error was not detected earlier.

Potential root causes could include:

• an incorrect mapping table;
• inadequate review;
• unclear work instructions;
• a vendor error;
• an interface problem;
• inadequate change control;
• a system configuration problem.

The data correction restores the records.

A CAPA, where warranted, addresses the control failure that allowed the error to occur or persist.

The two activities should therefore be distinguished.

Data Quality and Pharmacovigilance

The connection between XEVMPD data quality and pharmacovigilance should be considered carefully.

Not every XEVMPD discrepancy has a direct patient-safety consequence.

Nevertheless, medicinal-product data form part of the infrastructure used to identify and analyse safety information.

EMA's quality-control material describes the use of validated medicinal-product information in activities including the codification of individual case safety reports and signal-management processes. [3]

Consider a simplified example.

A medicinal product is represented through two inappropriate or inconsistent product representations.

If safety reports are associated with those representations inconsistently, the reports may be fragmented across product populations.

That could affect subsequent analysis.

This does not mean that every duplicate or terminology discrepancy will produce such an outcome. The point is that product-data quality can become relevant to pharmacovigilance when the affected data are used downstream.

The assessment should therefore be based on the actual data flow rather than on an assumption that every XEVMPD error is a safety issue.

The Role of Controlled Terminology

Controlled terminology is an important component of XEVMPD data quality.

A controlled term can be valid while being inappropriate for a particular product.

This distinction is important.

For example, selecting a valid pharmaceutical-form term does not demonstrate that the term is the correct representation of the authorised product.

Similarly, a valid substance term may be incorrectly selected or applied.

EMA has undertaken specific quality-control work on controlled vocabularies, including substance names and medicinal-product terminology. [4]

This demonstrates why data-quality controls need to consider both:

• whether a value is permissible; and
• whether it is appropriate for the particular product.

Vendor-Supported XEVMPD Maintenance

Many organisations use external service providers to support medicinal-product data maintenance.

Outsourcing the operational activity does not remove the need for appropriate oversight.

The MAH should understand:

• which system is the source for the vendor;
• who approves source data;
• who performs the XEVMPD submission;
• who reviews acknowledgements;
• who manages exceptions;
• who performs reconciliation;
• how errors are escalated;
• how vendor-generated corrections are verified.

A useful control is to ensure that the vendor's process can be traced back to the MAH's regulatory source.

The organisation should be able to answer:

"If this XEVMPD value is challenged, where did it come from?"

The answer should not simply be:

"The vendor entered it."

Metrics for XEVMPD Data Quality

Metrics can be useful, but they should describe the nature of the data-quality problem rather than reduce it to one number.

Potential measures include:

Population coverage

The proportion of the defined in-scope population represented in XEVMPD.

Material discrepancy rate

The number of material discrepancies identified relative to the assessed population.

Lifecycle discrepancy rate

The frequency with which relevant regulatory lifecycle changes are not reflected appropriately.

Reconciliation closure time

The elapsed time between identification and verified resolution of a discrepancy.

Recurrence

The frequency with which the same root-cause category reappears.

Root-cause distribution

The proportion of findings attributable to source data, mapping, lifecycle management, system, vendor or process causes.

Repeat finding rate

The proportion of previously identified error types that recur after corrective action.

Metrics should be interpreted with context.

For example, a 0.5% discrepancy rate may appear small, but its significance depends on what those discrepancies represent.

A single systematic error affecting a critical product field may warrant more attention than many minor discrepancies.

What Evidence Should Be Retained?

A reconciliation should produce sufficient evidence to demonstrate how the conclusion was reached.

Depending on the purpose and risk of the exercise, this may include:

• defined reconciliation scope;
• population extract;
• source-system evidence;
• XEVMPD extract;
• reconciliation logic;
• discrepancy list;
• investigation records;
• source regulatory documents;
• correction submissions;
• acknowledgement records;
• CAPA documentation where applicable;
• final verification.

The purpose of retaining this evidence is not to create a larger administrative burden.

It is to make the conclusion reproducible.

An independent reviewer should be able to determine:

• what population was examined;
• what sources were used;
• how differences were identified;
• how discrepancies were classified;
• what corrections were made;
• how the corrections were verified.

Inspection Perspective

An inspector asking:

"How do you know your XEVMPD data are accurate?"

is asking a different question from:

"Do you submit XEVPRMs?"

A response such as:

"Our submissions are accepted."

does not address the first question adequately.

A more complete explanation would describe:

• the defined source of regulatory information;
• the process for lifecycle maintenance;
• the reconciliation approach;
• how discrepancies are investigated;
• how the impact is assessed;
• how corrections are verified;
• how recurring errors are addressed.

The important evidence is the process in operation.

A documented procedure with no examples may provide limited assurance.

A completed reconciliation with a clear discrepancy investigation demonstrates considerably more.

A Practical Reconciliation Record

A reconciliation record can be structured around the following fields:

The exact format can be adapted to the organisation's quality system.

The important feature is that the reconciliation should connect the observation to the final conclusion.

A More Difficult Example

Consider an MAH with 1,000 medicinal-product records.

A reconciliation identifies 14 discrepancies.

At first sight, this appears to be a small number.

The investigation finds:

• 5 are scope differences;
• 3 are historical records that were superseded appropriately;
• 2 are isolated data-entry errors;
• 2 arose from a vendor mapping problem;
• 2 are associated with a common lifecycle-process failure.

The last two findings affect 48 additional products that had not yet been reconciled.

The original reconciliation therefore identified 14 discrepancies, but the investigation revealed a potentially much larger population affected by one root cause.

This is why reconciliation should be viewed as an investigative control rather than a simple matching exercise.

The Importance of Reconciliation Logic

Automated comparison can identify differences efficiently.

It cannot necessarily determine their meaning.

For example:

System A: "Company B Limited"

System B: "Company B Ltd."

A literal comparison identifies a difference.

A human or appropriately designed normalisation rule may recognise that the values refer to the same organisation.

Conversely:

System A: "Company B"

System B: "Company B Pharmaceuticals"

may or may not represent the same legal entity.

The reconciliation therefore needs appropriate matching logic.

Poor matching logic can produce both:

• false discrepancies; and
• missed discrepancies.

The quality of the reconciliation depends partly on the quality of the comparison methodology.

Reconciliation Should Be Version-Aware

Medicinal-product information changes over time.

A comparison without a defined reference date can therefore be misleading.

For example:

Regulatory source: state as of 1 December

XEVMPD extract: state as of 15 December

A variation authorised between the two dates may explain an apparent discrepancy.

The reconciliation should therefore establish the relevant effective dates where they matter.

This is particularly important for lifecycle investigations.

Current XEVMPD Environment

The XEVMPD environment continues to evolve as EMA implements the wider transition toward ISO IDMP-aligned product-data management.

EMA's current information describes the continuing use of XEVMPD during the transition and the development of Product Management Services (PMS). EMA has also introduced XEVMPDweb as the upgraded interface for external users, with the transition away from the previous external EVWEB interface taking place in 2026. [5][7][8]

This evolution makes data governance increasingly important.

The underlying principles of good data management do not depend on a particular user interface.

The organisation should continue to understand:

• what information it owns;
• which sources establish the expected state;
• how data are transformed;
• how changes are controlled;
• how records are reconciled;
• how discrepancies are investigated.

Those controls remain relevant as regulatory systems change.

Practical Questions for an MAH

A useful internal assessment can ask:

Population

Can we define exactly which products should be represented?

Source

Can we identify the authoritative source for each important data element?

Lifecycle

How does a regulatory event trigger XEVMPD maintenance?

Reconciliation

How do we know that the current XEVMPD population corresponds to the current regulatory population?

Investigation

When we find a discrepancy, how do we determine whether it is isolated or systemic?

Correction

How do we correct the XEVMPD record and verify the result?

Feedback

How do corrections or Agency quality-control changes feed back into our internal data?

Oversight

Can we demonstrate that vendors performing XEVMPD activities are appropriately controlled?

Pharmacovigilance impact

Can we determine whether a product-data problem could affect downstream PV activities?

These questions provide a more useful assessment of control than simply asking whether the organisation has an XEVMPD SOP.

Common Data-Quality Failure Modes

Several recurring patterns are worth recognising.

Failure to define the population

A reconciliation produces unexplained differences because the systems contain different scopes.

Treating validation as accuracy

The organisation assumes that an accepted submission must be correct.

Incorrect mapping

The source information is correct but is transformed into the wrong XEVMPD representation.

Lifecycle disconnect

A regulatory event occurs but does not trigger the required product-data maintenance.

Stale internal master data

The internal source itself is outdated and therefore propagates incorrect information into XEVMPD.

Vendor boundary failure

The vendor performs the operational activity but there is insufficient review of the underlying source data.

Duplicate representation

The same medicinal-product information is represented more than once or under inappropriate relationships.

Failure to assess population impact

One discrepancy is corrected without investigating whether the same mechanism affected other products.

Failure to verify correction

The organisation submits a correction but does not confirm that the resulting state is correct.

These failure modes can occur independently or together.

An Analytical Approach to Data-Quality Investigation

A useful way to investigate an XEVMPD discrepancy is to work backwards from the observed value.

Start with:

What does XEVMPD currently contain?

Then ask:

What should it contain?

Then:

What source supports that conclusion?

Then:

When did the expected state become effective?

Then:

How was the information transferred into the XEVMPD process?

Then:

Where could the discrepancy have been introduced?

Finally:

Could the same mechanism have affected other records?

This approach is particularly effective because it separates the data problem from the process problem.

The Relationship Between Data Quality and Governance

XEVMPD data quality is sometimes treated as an operational responsibility belonging entirely to a regulatory-data team.

That can be too narrow.

The data may originate in regulatory functions, pass through information-management systems, be maintained by vendors and ultimately support pharmacovigilance activities.

Responsibility for individual activities may therefore be distributed.

Governance should nevertheless ensure that:

• ownership is defined;
• interfaces are controlled;
• changes are communicated;
• discrepancies are escalated;
• corrective actions are followed through;
• significant systemic problems reach the appropriate governance level.

The objective is not to make the QPPV responsible for every product-data field.

The objective is to ensure that product-data weaknesses that could affect the pharmacovigilance system are visible and appropriately managed.

Key Takeaways

XEVMPD data quality is broader than successful electronic submission.

A record can be technically valid and still be substantively incorrect or no longer current.

Five dimensions provide a useful framework for assessment:

completeness, correctness, consistency, currency and traceability.

Reconciliation should begin with a defined population and an expected state supported by appropriate authoritative sources.

A discrepancy is an observation, not automatically a root-cause conclusion.

Investigation should determine:

• what is different;
• what should be present;
• why the difference occurred;
• whether other records are affected;
• whether downstream pharmacovigilance activities may be affected;
• what correction and systemic action are required.

The distinction between correcting data and correcting the process that produced the data is important.

A well-designed reconciliation therefore follows the complete cycle:

define → compare → investigate → assess impact → correct → verify → learn.

The objective is not to achieve an impressive percentage of matching records.

The objective is to maintain a defensible representation of the medicinal-product portfolio throughout its regulatory lifecycle and to be able to demonstrate how that representation is controlled.

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 Medicines Agency. Reporting requirements for marketing-authorisation holders. Data submission and maintenance requirements for authorised medicines under Article 57(2) of Regulation (EC) No 726/2004.

3. 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, current revision.

4. European Medicines Agency. Guidance documents related to data submission for authorised medicines. Includes Article 57 data-quality-control methodology, measures for Article 57 data quality assurance, controlled-vocabulary quality-control documents and related guidance.

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

6. European Medicines Agency. Electronic submission of medicinal product information by marketing-authorisation holders. Article 57(2) of Regulation (EC) No 726/2004. EMA/736031/2014.

7. European Medicines Agency. Data on medicines (ISO IDMP standards): post-authorisation. Current information concerning Article 57 data and the transition toward ISO IDMP-aligned product-data management.

8. European Medicines Agency. Substance and product data management services. Current Product Management Services implementation information and data-enrichment activities.

9. European Commission. Commission Implementing Regulation (EU) No 520/2012 on the performance of pharmacovigilance activities.