XEVMPD Lifecycle Maintenance: Managing Variations, Transfers, Renewals and Withdrawals

Introduction

XEVMPD maintenance is sometimes treated as a final administrative step after a regulatory procedure has been completed.

That is a risky way to think about it.

The regulatory lifecycle of a medicinal product does not stop when an initial XEVMPD record is created. Marketing authorisations change. Products are transferred between marketing authorisation holders. Authorisations are renewed, suspended, revoked or withdrawn. Product information can change as a result of variations.

When those changes affect information represented in XEVMPD, the Article 57 data must be maintained.

The important question is therefore not:

"Has the regulatory procedure been completed?"

It is:

"What changed, does that change affect XEVMPD data, and has the corresponding medicinal-product record been maintained correctly?"

EMA states that marketing authorisation holders must keep information on authorised medicines up to date. Current EMA guidance states that amendments to the terms of marketing authorisations following variation, transfer, renewal, suspension, revocation or withdrawal must be notified to EMA no later than 30 calendar days from the date on which the amendments were authorised. 1

This article explains how to approach that maintenance as a controlled lifecycle process rather than as isolated data-entry work.

Learning Objectives

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

• explain why XEVMPD maintenance is a lifecycle activity;
• distinguish a regulatory lifecycle event from its XEVMPD data impact;
• identify common events that can trigger XEVMPD maintenance;
• understand the importance of the 30-calendar-day maintenance requirement;
• explain why transfers require particular care;
• understand how variations can affect structured medicinal-product data;
• distinguish product-data maintenance from the underlying regulatory procedure;
• design a practical regulatory-to-XEVMPD change-control process;
• recognise when a single XEVMPD discrepancy may indicate a wider portfolio problem;
• understand what evidence should be retained to demonstrate controlled maintenance.

Regulatory Context

Article 57 Data Must Remain Current

The legal framework for Article 57 medicinal-product data is intended to provide EMA and the European regulatory network with accurate and current information on medicines authorised in the EU/EEA.

EMA describes the maintenance obligation as an ongoing requirement. Since the initial implementation of Article 57, the focus has moved from initial submission and data remediation to maintaining the information over the product lifecycle. 2

This distinction is important.

An MAH can have a perfectly acceptable initial XEVMPD record and still have poor Article 57 data quality if subsequent regulatory changes are not reflected appropriately.

The lifecycle therefore looks more like:

authorisation → XEVMPD record → regulatory change → impact assessment → XEVMPD maintenance → acknowledgement/review → reconciliation

rather than:

authorisation → XEVMPD submission → finished

The Maintenance Deadline

For amendments to the terms of marketing authorisation that affect the relevant medicinal-product information, EMA states that the information must be notified no later than 30 calendar days from the date on which the amendments were authorised. EMA identifies variations, transfers, renewals, suspensions, revocations and withdrawals within this maintenance framework. 3

The critical operational point is that the regulatory event should trigger a controlled assessment.

The XEVMPD team should not have to discover regulatory changes accidentally.

A mature process should make the connection explicit:

Regulatory event → XEVMPD impact assessment → maintenance action → quality control

What Does "Maintenance" Actually Mean?

Maintenance does not necessarily mean changing every field in an XEVMPD record whenever any regulatory event occurs.

Instead, the MAH should determine:

1. What changed?
2. When did it become effective or authorised?
3. Which product or products are affected?
4. Which XEVMPD data elements represent that information?
5. Does the change require an XEVMPD update?
6. What transaction or maintenance process applies?
7. What evidence demonstrates that the update was completed?

This distinction prevents both under-reporting and unnecessary changes.

The Regulatory Event Is the Starting Point

A useful principle is:

Do not start with XEVMPD. Start with the regulatory change.

For example:

A variation changes the strength of a medicinal product.

The correct sequence is:

variation approved → identify affected product(s) → determine affected XEVMPD data → prepare maintenance → submit → review acknowledgement → reconcile

Not:

someone notices that the strength field looks old → manually edit XEVMPD

The first approach is controlled.

The second depends on someone noticing a discrepancy.

Variations

Why Variations Matter

Variations can change information represented in the Article 57 data.

The impact depends on the nature of the variation.

Possible affected information can include, depending on the particular regulatory change:

• product name;
• pharmaceutical form;
• strength;
• route of administration;
• active substance information;
• authorisation-related information;
• other structured medicinal-product information represented in XEVMPD.

Not every variation necessarily changes an XEVMPD field.

The correct approach is therefore not:

"Every variation requires the same XEVMPD update."

It is:

"Every relevant variation should undergo an XEVMPD impact assessment."

Worked Example: Strength Change

Consider a hypothetical generic medicine:

Generic Drug 10 mg tablets

A variation results in authorisation of an additional strength:

Generic Drug 20 mg tablets

The regulatory procedure is complete.

The XEVMPD assessment should then ask:

• Is this an existing product being changed?
• Is a new medicinal-product representation required?
• Which structured product attributes are affected?
• Are the existing 10 mg and new 20 mg presentations being represented correctly?
• Are there related records that need review?

The answer should be determined using the current XEVMPD business guidance and the actual regulatory information.

The important lesson is that the variation approval itself does not automatically prove that the corresponding XEVMPD representation is correct.

Worked Example: Pharmaceutical Form Change

Imagine that a hypothetical medicinal product changes from:

immediate-release tablet

to:

modified-release tablet

The regulatory documentation establishes the approved pharmaceutical form.

The XEVMPD process should then assess whether the relevant structured pharmaceutical-form information has changed and whether associated product attributes are affected.

The mistake would be to update only the obvious field without checking whether the change alters the way the medicinal product is represented as a whole.

This is a recurring data-governance principle:

A change in one regulatory attribute can have implications for the representation of the medicinal product as a structured data object.

Renewals

Renewals are another lifecycle event that should be incorporated into the XEVMPD maintenance process.

EMA's current post-authorisation implementation guidance states that, similarly to variations, updates should be submitted to the Article 57 database by MAHs following renewals where relevant changes affect the data. 4

The practical workflow should therefore include:

renewal outcome → determine whether Article 57-relevant information changed → update XEVMPD where applicable → reconcile

A renewal should not be treated as automatically irrelevant to XEVMPD simply because the product existed in the database before the renewal.

Transfers of Marketing Authorisation

Transfers deserve particular attention.

A transfer changes the relationship between the medicinal product and the organisation responsible for the marketing authorisation.

That creates both regulatory and data-governance implications.

EMA's current 2026 implementation guidance states that both the former and new MAHs must follow the XEVMPD transfer process, regardless of whether the product is centrally or non-centrally authorised. 5

For centrally authorised products, EMA describes an interaction between the marketing-authorisation information in SIAMED/PMS and the organisation information in XEVMPD. The relevant organisation mappings need to align for the product information to be correctly associated. 6

This is not merely administrative housekeeping.

Why Transfer Errors Can Be Serious

EMA specifically notes that failure to follow the transfer process may result in creation of new medicinal products, with the consequence that the correct lifecycle of a medicinal product may no longer be trackable. 7

That is a much more important problem than:

"The MAH name is wrong."

The deeper problem can be:

"The product's identity and lifecycle continuity have been broken in the data system."

That distinction is important for both data quality and inspection readiness.

Worked Example: Marketing Authorisation Transfer

Consider a hypothetical product:

Generic Drug 10 mg tablets

Company A is the original MAH.

The marketing authorisation is transferred to Company B.

A superficial approach might be:

1. find the XEVMPD record;
2. change Company A to Company B;
3. save the record.

That may not represent the required transfer process.

A controlled approach asks:

• Has the regulatory transfer completed?
• Which organisation is the former MAH?
• Which organisation is the new MAH?
• Are the relevant organisation identifiers correctly mapped?
• What does the current XEVMPD transfer process require?
• Which party must perform each part of the process?
• Does the existing medicinal-product identity remain linked correctly?
• Has a duplicate/new product been inadvertently created?
• Can the resulting lifecycle still be followed?

The final question is particularly important.

The goal is not simply to produce a record that says "Company B."

The goal is to preserve the correct medicinal-product lifecycle.

Centrally Authorised Versus Nationally Authorised Products

The relationship between XEVMPD and other EMA product-management systems can differ depending on the authorisation pathway.

EMA's current guidance describes specific interactions between XEVMPD and Product Management Services (PMS), including the handling of centrally authorised products and organisation mappings. For non-centrally authorised products, MAHs remain responsible for following the applicable XEVMPD process. 8

This means an SOP should avoid assuming that one transfer workflow applies identically to every product.

A useful decision point is:

CAP or non-CAP?

Then determine the applicable current regulatory and XEVMPD process.

Suspensions

A suspension can affect the regulatory status of a medicinal product.

The XEVMPD maintenance process should therefore include assessment of the relevant status information.

The important distinction is:

suspension of an authorisation is a regulatory event.

The XEVMPD task is to ensure that the medicinal-product data representing the applicable status are maintained according to the current business process.

The MAH should not simply assume that a suspension means deleting the product.

Lifecycle data should preserve the history and status of the medicinal product rather than erase it.

Revocations

Revocation is another lifecycle event identified by EMA within the Article 57 maintenance framework. 9

Again, the key question is not:

"Should we delete the product?"

It is:

"What does the applicable XEVMPD process require to represent this regulatory status change?"

This is a good example of why XEVMPD should be managed as a structured regulatory data system rather than as a spreadsheet of active products.

Withdrawals

Withdrawals should similarly trigger an assessment of the relevant XEVMPD record.

The withdrawal of a marketing authorisation does not mean that the product never existed.

The regulatory history remains important.

The correct maintenance action therefore needs to preserve the appropriate product lifecycle status according to the current XEVMPD business rules.

Do Not Confuse Product Withdrawal With Record Deletion

This distinction is important.

Imagine:

Product authorised → marketed → withdrawn

The regulatory lifecycle contains all three states.

Deleting the record would potentially destroy useful historical information.

A lifecycle system should instead represent the change in status through the applicable mechanism.

The exact transaction should always follow the current EMA guidance.

XEVMPD and Product Management Services

The European medicines regulatory network is progressively implementing ISO IDMP-based product data management.

EMA's current implementation material describes interactions between XEVMPD and Product Management Services, including circumstances in which changes entered into SIAMED or XEVMPD subsequently update PMS. 10

This makes lifecycle maintenance increasingly a data-integration problem, not merely a regulatory-submission problem.

A future-proof process should therefore consider:

• regulatory source systems;
• XEVMPD;
• PMS;
• Organisation Management Service (OMS);
• internal regulatory-information systems;
• pharmacovigilance systems;
• vendor systems.

The objective is not to make all systems identical.

It is to maintain controlled relationships between authoritative data sources.

The Single Source of Truth Problem

One of the hardest practical questions is:

"Which system is authoritative?"

The answer may depend on the data element.

For example:

• regulatory approval documents may establish the legal regulatory state;
• internal regulatory systems may manage procedural records;
• XEVMPD contains the Article 57 representation;
• OMS manages organisation master data;
• PMS integrates product information under the evolving IDMP framework.

The solution is not to declare one system universally authoritative.

Instead, define:

data element → authoritative source → downstream systems → reconciliation responsibility

That creates a much stronger data-governance model.

Worked Example: Regulatory Change but No XEVMPD Update

Consider a hypothetical company with 15 authorised generic products.

A regulatory variation changes a product's pharmaceutical form.

The variation is completed.

However, the XEVMPD team is not automatically notified.

Six months later, an internal review discovers that the XEVMPD record still contains the previous information.

The obvious conclusion is:

"The XEVMPD team forgot to update it."

That may be true.

But it is not yet a root cause.

A proper investigation asks:

• Was XEVMPD impact assessment part of the variation workflow?
• Was Regulatory Affairs required to notify the XEVMPD team?
• Was there an automated trigger?
• Did the regulatory system identify the affected data element?
• Was the variation screened for Article 57 impact?
• Was the update assigned to someone?
• Was the submission completed?
• Was the acknowledgement reviewed?
• Could other products have the same problem?

The visible failure is an outdated record.

The systemic failure may be the absence of an interface between regulatory change control and XEVMPD maintenance.

Worked Example: One Transfer, Many Products

Suppose Company A transfers a portfolio of 40 medicinal products to Company B.

The transfer team treats each product as an independent data-entry exercise.

After completion, three products appear as newly created records rather than continuing the expected lifecycle.

The problem is no longer three isolated errors.

It may indicate a systemic failure in:

• organisation mapping;
• transfer instructions;
• identifier handling;
• data preparation;
• quality control;
• or the transfer process itself.

This is why lifecycle events affecting many products should be managed as portfolio-level change events, not simply as 40 unrelated XEVMPD tasks.

The Regulatory-to-XEVMPD Interface

A mature operating model should define an explicit handoff.

For example:

The exact organisational structure can differ.

The control points should not disappear.

Four-Eyes Review

For material lifecycle changes, independent review can provide a useful control.

The preparer determines:

• what changed;
• what XEVMPD fields are affected;
• what submission is required.

The reviewer independently checks:

• source evidence;
• product identity;
• data mapping;
• transaction type;
• expected result.

This is particularly valuable for:

• transfers;
• complex variations;
• organisation changes;
• product-status changes;
• large portfolio updates.

The appropriate level of review should be risk-based.

Change-Control Triggers

A useful SOP can define events that automatically trigger an XEVMPD assessment.

Examples include:

• new marketing authorisation;
• variation approval;
• variation implementation where applicable;
• renewal;
• transfer;
• suspension;
• lifting of suspension;
• revocation;
• withdrawal;
• changes to QPPV information;
• changes to pharmacovigilance enquiry information;
• changes to the location of the PSMF;
• other regulatory changes affecting Article 57 data.

The precise applicability of each trigger should be mapped to the current XEVMPD business guidance.

The point is to create a screening mechanism, not to assume every event produces the same submission.

QPPV-Relevant Maintenance

Some XEVMPD maintenance concerns pharmacovigilance-specific information rather than the medicinal product itself.

EMA's Article 57 implementation material identifies maintenance of information concerning the QPPV, pharmacovigilance enquiry details and the location of the pharmacovigilance system master file among the maintenance topics addressed through the Article 57 framework. 11

This creates an important interface between:

• pharmacovigilance;
• regulatory information;
• XEVMPD operations.

A QPPV change should therefore not be considered complete merely because the internal organisational chart has been updated.

The relevant regulatory data should also be assessed.

Common Lifecycle-Maintenance Failures

Failure 1 — XEVMPD Is Not Included in Regulatory Change Control

The regulatory team completes the variation.

Nobody assesses Article 57 impact.

Root cause: missing process interface.

Failure 2 — Every Variation Is Treated Identically

The organisation creates a generic "XEVMPD update" task without assessing what actually changed.

Root cause: procedural activity substituted for impact assessment.

Failure 3 — Transfer Treated as Simple Name Replacement

The new MAH is entered into the record without following the applicable transfer process.

Potential consequence: lifecycle continuity problems or creation of a new medicinal product representation. 12

Failure 4 — Withdrawal Treated as Deletion

The product disappears from an internal active-product list and the team assumes the XEVMPD record should also disappear.

Root cause: misunderstanding of lifecycle data.

Failure 5 — No Portfolio Assessment

One error is corrected without asking whether other products were affected.

Root cause: record-level rather than system-level thinking.

Failure 6 — No Reconciliation

The submission is sent and an acknowledgement is received, but nobody verifies that the intended lifecycle state is represented correctly.

Root cause: submission treated as the end of the process.

Metrics for Lifecycle Maintenance

A useful XEVMPD maintenance dashboard should measure more than submission volume.

Timeliness

Percentage of applicable maintenance submissions completed within the required timeframe.

First-pass quality

Percentage accepted without requiring correction.

Regulatory-to-XEVMPD lag

Time between regulatory event and completion of the XEVMPD maintenance process.

Reconciliation completion

Percentage of maintenance transactions with documented post-submission verification.

Recurrence

Frequency of repeated maintenance errors by root-cause category.

Portfolio impact

Number of products affected by systemic lifecycle errors.

Transfer integrity

Percentage of transferred products for which lifecycle continuity is confirmed.

Metrics should be used to identify weaknesses rather than simply to demonstrate that tasks were completed.

Inspection Perspective

An inspector may ask:

"How do you know that regulatory changes are reflected in XEVMPD?"

A weak answer is:

"Our XEVMPD team checks the database."

A stronger answer explains the control chain:

regulatory event → impact assessment → assigned XEVMPD task → source-data verification → submission → acknowledgement → reconciliation → documented evidence

The inspector may then ask:

"Show me an example."

That is where the process must be supported by evidence.

Useful evidence can include:

• regulatory approval documentation;
• XEVMPD impact assessment;
• task assignment;
• submitted transaction;
• acknowledgement;
• review record;
• correction history;
• reconciliation;
• CAPA or deviation where applicable.

A Practical Lifecycle Checklist

For each relevant regulatory event, ask:

Regulatory event

• What changed?
• When was it authorised or implemented?
• Which product(s) are affected?

XEVMPD impact

• Does the change affect Article 57 data?
• Which fields or relationships are affected?
• Is the change a new product, an update, a status change or another transaction?

Source

• What authoritative document establishes the change?
• Is the source current?

Submission

• What XEVMPD process applies?
• Is the current guidance being used?
• Is the submission within the applicable timeframe?

Quality control

• Was the transaction independently reviewed where appropriate?
• Was the acknowledgement evaluated?
• Was the resulting record reconciled?

Systemic assessment

• Could other products be affected?
• Is there a recurring error?
• Does the event require a process, system, training or vendor intervention?

Teaching Example: The 30-Day Clock

Suppose a variation affecting XEVMPD-relevant information is authorised on 1 September.

The organisation should not interpret the deadline as:

"We have until the end of September whenever convenient."

The control should begin when the regulatory event occurs.

A good workflow creates:

1 September — regulatory outcome

↓

XEVMPD impact assessment

↓

data preparation and review

↓

submission

↓

acknowledgement and reconciliation

The precise operational schedule should provide enough internal margin to ensure the regulatory deadline is not treated as the operational target.

The important lesson is:

Regulatory deadlines should be translated into internal workflow deadlines.

Historical Data and Corrections

Lifecycle maintenance also needs to address historical errors.

Suppose a product has been represented incorrectly in XEVMPD for several years.

Correcting the current record may not be enough.

The organisation should determine:

• when the error originated;
• which versions were affected;
• whether the error was propagated to related records;
• whether the current record can be corrected directly;
• whether historical data require broader review;
• whether the issue indicates a systemic control failure.

EMA has an established programme of quality control for Article 57 medicinal-product data and has published methodology describing how product data are assessed and corrected. 13

This reinforces an important principle:

Data quality is a lifecycle property, not simply a submission-time property.

XEVMPD Maintenance in 2026

The operational environment is also changing.

EMA made the upgraded XEVMPDweb user interface available to external users from February 2026 and subsequently moved toward XEVMPDweb as the external interface. Current EMA guidance and user documentation should therefore be used for operational instructions rather than relying on legacy interface screenshots or old procedures. 14

The broader product-data environment is also evolving around ISO IDMP and PMS.

This creates an important SOP-writing principle:

Document the control objective and decision logic separately from interface-specific instructions.

Screenshots and click-by-click instructions can be maintained as controlled work aids.

The core SOP should explain why the activity occurs, who owns it, what evidence is required and how exceptions are handled.

What Good Lifecycle Governance Looks Like

A mature XEVMPD lifecycle process has five characteristics.

1. Triggered

Regulatory events automatically or reliably trigger XEVMPD assessment.

2. Risk-based

The organisation determines what actually changed rather than applying identical updates to every event.

3. Traceable

The organisation can connect:

regulatory decision → XEVMPD assessment → submission → acknowledgement → final state

4. Reconciled

The process confirms that the intended result was achieved.

5. System-aware

Repeated errors are analysed for wider process, system or vendor weaknesses.

This is much stronger than simply maintaining a list of products and asking someone to "keep XEVMPD updated."

Key Takeaways

XEVMPD maintenance is a lifecycle-control activity.

The main principles are:

1. Start with the regulatory event, not with the XEVMPD record.

2. Assess whether the event affects Article 57 data.

3. Use the current EMA process for the applicable event.

4. Treat variations, renewals, transfers, suspensions, revocations and withdrawals as lifecycle triggers requiring appropriate assessment.

5. Pay particular attention to transfers because incorrect processing can disrupt medicinal-product lifecycle continuity.

6. Do not treat withdrawal as automatic deletion of the medicinal-product record.

7. Connect regulatory change control directly to XEVMPD maintenance.

8. Build internal workflow deadlines ahead of the regulatory deadline.

9. Reconcile the result rather than treating submission as the end of the process.

10. Investigate whether individual discrepancies indicate a wider portfolio or systemic problem.

11. Maintain evidence of the complete control chain.

12. Keep SOP logic stable while updating interface-specific work instructions as EMA systems evolve.

The mature process can be summarised as:

regulatory change → impact assessment → authoritative source → XEVMPD data mapping → controlled submission → acknowledgement → reconciliation → portfolio assessment → corrective action where needed

That is the difference between entering XEVMPD data and governing XEVMPD data.

References

1. European Parliament and Council. Regulation (EC) No 726/2004, Article 57(2), concerning the submission and maintenance of medicinal-product information.

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

3. European Medicines Agency. Data submission on authorised medicines (Article 57). Current EMA guidance on the Article 57 data-maintenance framework.

4. European Medicines Agency. Reporting requirements for marketing-authorisation holders. Current guidance on maintenance of medicinal-product information following variation, transfer, renewal, suspension, revocation and withdrawal.

5. European Medicines Agency. Guidance documents related to data submission for authorised medicines. Current XEVMPD/XEVPRM guidance and data-quality documentation.

6. European Medicines Agency. How to submit information on authorised and investigational medicines. Current information on XEVMPD, XEVPRM and XEVMPDweb.

7. European Medicines Agency. Process for electronic submission of medicinal product information — Chapter 3, current 2026 guidance concerning medicinal-product data and the interaction between XEVMPD and Product Management Services.

8. 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. 71, 2025.

9. European Medicines Agency. eXtended EudraVigilance Medicinal Product Dictionary (XEVMPD) e-learning — XEVMPD data submission process.

10. European Medicines Agency. XEVMPDweb user manual and current XEVMPD training materials.