XEVMPD Data Quality: Reconciliation, Completeness and Detecting Hidden Errors

A reconciliation is not merely a comparison of two files. Its purpose is to determine whether the actual Article 57/XEVMPD representation corresponds to the regulatory state that should exist, and to explain discrepancies when it does not.

Purpose and Scope

Article 57(2) of Regulation (EC) No 726/2004 creates the legal framework for electronic medicinal-product information maintained by marketing authorisation holders (MAHs) with EMA. The XEVMPD record is therefore part of a wider regulatory-data environment, and its reliability cannot be judged solely from the fact that a message was accepted.

Reconciliation adds a different control. It asks:

• Is every product that should be represented present?
• Are products represented only where appropriate?
• Do material fields correspond to authoritative regulatory sources?
• Does the record reflect the current lifecycle state?
• Are apparent differences legitimate or erroneous?
• Does one discrepancy indicate a wider population-level defect?

The focus of this article is therefore detective control and investigation, rather than field-entry technique or lifecycle submission mechanics.

Defining the Expected Population

The first step is to define what is being reconciled. “Compare XEVMPD with the regulatory database” is not sufficiently precise.

A portfolio reconciliation should specify the population, cut-off date, jurisdictions, authorisation types and any justified exclusions. The expected population may be constructed from controlled regulatory records, but the source itself must be understood and qualified.

If an internal portfolio contains 500 records and XEVMPD contains 496 apparent matches, the immediate conclusion is not that four Article 57 records are missing. The unmatched records may include duplicates, products outside scope, different identifiers or genuine omissions. They are discrepancies requiring investigation.

Establishing the Expected State

There may be no single universal “source of truth” for every field. Instead, data governance should identify the authoritative source for each concept.

The expected XEVMPD representation is then derived from those sources using the applicable data model and terminology.

Reconciliation Dimensions

Completeness

Completeness asks whether all required product records and relevant fields are represented. It must be assessed against a defined population rather than a raw count.

Correctness

Correctness asks whether the XEVMPD values accurately represent the authorised product. A field can be populated and technically valid while still being wrong.

Consistency

Consistency asks whether differences between XEVMPD and related systems are expected and explainable. Literal equality is not always appropriate because data models differ.

Currency

Currency asks whether the record reflects the current regulatory state following variations, transfers, renewals, suspensions or withdrawals.

Traceability

Traceability asks whether the organisation can reconstruct how a value came from the regulatory source into the Article 57 submission and, where relevant, how it later changed.

Matching Strategy

Reliable matching uses stable identifiers where possible and applies controlled secondary attributes where identifiers are incomplete or inconsistent. Name-only matching is fragile because product names, strengths, presentations and local-language representations can vary.

A reconciliation algorithm or manual process should therefore distinguish:

• exact identifier matches;
• probable matches requiring review;
• unmatched source records;
• unmatched XEVMPD records;
• duplicates or many-to-one relationships.

The matching logic itself should be documented and tested. Otherwise a reconciliation can create false discrepancies or conceal real ones.

From Discrepancy to Confirmed Error

A difference should pass through a structured investigation before it is labelled an error. The basic sequence is:

observed value → expected value → discrepancy → source verification → explanation → confirmed error or justified difference.

This prevents two opposite mistakes: correcting legitimate differences simply to make systems match, and dismissing meaningful discrepancies as harmless formatting.

Example: stale MAH identity

Suppose the regulatory source shows Company B as the current MAH while XEVMPD shows Company A. The investigator should identify when the transfer became effective, whether the Article 57 process was triggered, whether a submission was made, whether it was acknowledged successfully and whether other products in the same transfer are affected.

The final finding may be an isolated stale record. It may instead reveal that the transfer workflow did not trigger Article 57 maintenance for an entire portfolio.

Hidden Errors

Some defects are invisible in ordinary record-by-record review because each value looks plausible.

Valid but wrong controlled values

A valid route or pharmaceutical-form term can be selected for the wrong product. Schema validation will not necessarily expose the semantic error.

Systematic mapping defects

A mapping table can transform hundreds of source records consistently but incorrectly. High apparent consistency may therefore be evidence of a shared error rather than good quality.

Missing lifecycle events

A record can look internally coherent while representing a regulatory state that ceased to apply months earlier.

Population blind spots

If the reconciliation source omits a product, comparing XEVMPD only with that source can falsely suggest complete coverage. The source population itself therefore requires qualification.

Duplicate identities

A product may appear to be present when duplicate or fragmented records make the portfolio count misleading. Counts should be supported by record-level identity logic.

Root-Cause Expansion

When a confirmed error is found, the investigator should ask what population was exposed to the same failure mechanism. This is the difference between correcting a record and controlling a system.

Useful questions include:

• Was the value manually selected or algorithmically mapped?
• Which other products used the same mapping rule?
• Did the defect arise from source data, transformation, submission or maintenance?
• Was the same workflow used in other countries or portfolios?
• Could the issue affect product identification or downstream PV activity?

The answer determines the appropriate scope of correction and any preventive action.

Reconciliation Design

A robust reconciliation has a defined protocol or controlled specification covering:

1. objective and scope;
2. population and cut-off date;
3. authoritative sources;
4. matching rules;
5. fields compared;
6. tolerance or expected-difference rules;
7. discrepancy classification;
8. investigation ownership;
9. correction and verification;
10. closure evidence and metrics.

EU legislation does not prescribe this internal format. It is recommended quality-system practice to make the control reproducible and auditable.

Metrics That Mean Something

A raw “match rate” can be misleading. Better metrics distinguish at least:

• records assessed;
• unmatched records;
• discrepancies identified;
• discrepancies confirmed as errors;
• systemic defects identified;
• overdue corrections;
• recurrence after corrective action.

A 99% match rate can still conceal a serious systematic error if the affected 1% includes critical product identity or authorisation-status data. Metrics require interpretation alongside impact.

Reconciliation Frequency

There is no universal EU rule requiring every MAH to perform a complete XEVMPD reconciliation at a fixed interval. Frequency should therefore be justified operationally according to portfolio size, change rate, data history, system migrations, outsourcing and known risks.

Event-driven reconciliations can be particularly valuable after:

• acquisitions or divestments;
• large marketing-authorisation transfers;
• system migration;
• organisational master-data changes;
• discovery of a systematic mapping defect;
• significant EMA data-quality feedback.

Periodic reconciliation can complement, but should not replace, event-driven lifecycle maintenance.

Governance and Outsourcing

Where a vendor submits or maintains Article 57 data, accountability for the MAH's regulatory data does not become a purely vendor matter. The operating model should define source-data provision, submission responsibility, acknowledgement handling, discrepancy management, change notification and oversight.

Reconciliation can be a useful oversight control because it tests the resulting data state rather than relying only on activity reports.

Inspection Perspective

Illustrative inspection questions include:

• How is the expected Article 57 population established?
• Which sources are authoritative for key fields?
• How are legitimate cross-system differences distinguished from errors?
• How is a discrepancy expanded to determine whether other products are affected?
• What evidence shows that corrections reached the final XEVMPD record?
• How are systematic defects trended and prevented from recurring?

These are illustrative questions, not reported inspection findings.

Practical Example

A reconciliation finds 12 products whose XEVMPD pharmaceutical form differs from the regulatory master. Investigation shows that ten differences are legitimate representation differences, one is a single manual-entry error and one results from a mapping table used for 85 products.

The correct response is not “12 corrections.” The ten justified differences should be documented, the isolated error corrected, and the defective mapping investigated across all 85 potentially affected records. The reconciliation has therefore converted a superficial comparison into a population-level quality assessment.

Key Takeaways

Reconciliation begins with a defined expected regulatory state, not with a desire to make two databases identical. A discrepancy is an observation until its sources and meaning have been investigated.

The highest-value reconciliation controls detect hidden systemic defects: stale lifecycle states, valid-but-wrong terminology, defective mappings, duplicate identities and incomplete populations. Root-cause expansion determines whether one error should trigger review of many records.

XEVMPD remains active in 2026 while PMS/IDMP implementation progresses. Reconciliation therefore remains relevant both for current Article 57 compliance and for improving the quality of source data that will support future product-data services.

References

1. Regulation (EC) No 726/2004, consolidated text, Article 57(2). EUR-Lex.
2. Commission Implementing Regulation (EU) No 520/2012, consolidated text, Article 26. EUR-Lex.
3. European Medicines Agency. How to submit information on authorised and investigational medicines.
4. European Medicines Agency. Electronic submission of Article 57(2) data: questions and answers, EMA/159776/2013, current version.
5. European Medicines Agency. Quality Control of medicinal product data submitted as per Article 57(2), EMA/661709/2014 Rev. 7.
6. European Medicines Agency. Measures for Article 57 Data Quality Assurance, EMA/465609/2015.
7. European Medicines Agency. Guidance documents related to data submission for authorised medicines.
8. European Medicines Agency. Substance and product data management services / PMS roadmap, current 2026 information.

Regulatory Note

The legal obligation is to submit and maintain applicable medicinal-product information under the Article 57 framework. The reconciliation methodology, matching rules, metrics and review frequencies described here are recommended operational controls rather than universally prescribed EU procedures. Organisations should apply current EMA reporting guidance and the data model in force at the time of the assessment.