Maintaining XEVMPD Through the Product Lifecycle: Variations, Transfers, Renewals, Suspensions and Withdrawals

Introduction

The submission of medicinal-product information to the Extended EudraVigilance Medicinal Product Dictionary (XEVMPD) is not a one-time regulatory activity. Marketing authorisation holders (MAHs) are required to maintain the information they have submitted and to update it when relevant changes occur during the lifecycle of a medicinal product.

This is a direct consequence of the purpose of the Article 57 database. XEVMPD is intended to provide structured information on medicines authorised in the European Union and European Economic Area and to support activities including the identification and analysis of medicinal products in the pharmacovigilance system. EMA therefore expects the information held in the database to remain current. [1][2]

The practical difficulty is that regulatory lifecycle events do not originate in XEVMPD.

A variation is assessed through the applicable regulatory procedure. A marketing-authorisation transfer is handled through a regulatory process. A renewal changes the regulatory status of an authorisation. A suspension or withdrawal may change the status of the medicinal product. Changes to the qualified person responsible for pharmacovigilance (QPPV) or the location of the pharmacovigilance system master file (PSMF) arise from changes within the pharmacovigilance system.

XEVMPD maintenance is therefore an interface between the regulatory lifecycle and the medicinal-product data lifecycle.

The important control is not simply that someone knows how to submit an XEVPRM. The organisation needs a reliable mechanism by which a regulatory or organisational change is identified, assessed for its XEVMPD impact, translated into the appropriate data change, submitted within the applicable timeframe and subsequently verified.

This article examines that process and uses practical examples to illustrate where lifecycle maintenance commonly succeeds or fails.

Learning Objectives

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

• explain why XEVMPD requires continuing lifecycle maintenance;
• distinguish initial submission from post-authorisation maintenance;
• identify regulatory events that may require XEVMPD updates;
• explain how variations can affect medicinal-product data;
• understand the particular data implications of marketing-authorisation transfers;
• distinguish renewal from other lifecycle changes;
• understand the treatment of suspension, revocation and withdrawal;
• explain how QPPV and PSMF information is maintained through Article 57;
• identify the interfaces that should exist between regulatory affairs, pharmacovigilance and XEVMPD data management;
• recognise common lifecycle-maintenance failures;
• design a controlled process for identifying, submitting and verifying XEVMPD changes.

The Regulatory Basis for Maintenance

Article 57(2) of Regulation (EC) No 726/2004 requires MAHs to submit information on authorised medicinal products to the EMA and to keep that information up to date. EMA's current reporting guidance describes the requirement as a continuing obligation rather than a one-time submission. [1][2]

For new marketing authorisations, EMA states that information must be submitted within the applicable timeframe following notification of the granting of the marketing authorisation. EMA also specifies maintenance requirements for amendments to the terms of marketing authorisations. [2]

The practical consequence is that the XEVMPD record should be regarded as a representation of the current regulatory state of the product, not as a historical snapshot of the information submitted when the product was first entered into the database.

This distinction becomes important when considering lifecycle events.

The Lifecycle Concept

A medicinal product may pass through many regulatory states during its lifetime.

A simplified lifecycle might look like:

Initial authorisation

↓

Post-authorisation variation

↓

Renewal

↓

Further variations

↓

Transfer of marketing authorisation

↓

Suspension or withdrawal, where applicable

The actual sequence varies between products.

The XEVMPD maintenance process needs to accommodate these changes without losing the relationship between the medicinal product and its regulatory history.

This is why lifecycle maintenance is best understood as a controlled data process rather than a series of unrelated submissions.

What Should Trigger an XEVMPD Assessment?

Not every organisational or regulatory event changes XEVMPD data.

The relevant question is:

Does this event change information that is represented in the Article 57 data set?

Potential triggers include:

• granting of a new marketing authorisation;
• amendments to the terms of a marketing authorisation;
• variations;
• transfers of marketing authorisations;
• renewals;
• suspensions;
• lifting of suspensions;
• revocations;
• withdrawals;
• changes to the QPPV;
• changes to the pharmacovigilance enquiry information;
• changes to the location of the PSMF;
• other changes affecting information maintained in the Article 57 database.

EMA's Article 57 guidance specifically identifies post-authorisation maintenance associated with variations, extensions of the terms of marketing authorisations, transfers, suspensions, lifting of suspensions, revocations and withdrawals. [2][3]

The trigger should therefore be incorporated into the organisation's regulatory change-control process.

The Regulatory-to-XEVMPD Interface

A well-controlled process can be represented as:

Regulatory event

↓

Regulatory assessment

↓

XEVMPD impact assessment

↓

Data update

↓

XEVPRM submission

↓

Acknowledgement / processing

↓

Verification

↓

Internal record update

The important step is the XEVMPD impact assessment.

Without it, the organisation depends on individuals remembering that a particular regulatory event also has an Article 57 consequence.

That is fragile.

A controlled process should make the interface explicit.

Variations

Variations are among the most common causes of changes to medicinal-product information.

A variation may alter information such as:

• product name;
• pharmaceutical form;
• route;
• strength;
• substance information;
• indication;
• administration information;
• other information represented in the applicable Article 57 data set.

Not every variation changes every XEVMPD field.

The appropriate question is therefore not:

"Was a variation approved?"

It is:

"Did the approved variation change information that is represented in XEVMPD, and if so, what XEVMPD maintenance is required?"

Example: Variation Affecting Pharmaceutical Form

Consider a generic medicinal product authorised as:

10 mg tablets

A variation changes the pharmaceutical form to:

10 mg prolonged-release tablets

The regulatory procedure establishes the approved change.

The XEVMPD team then needs to determine whether the medicinal-product representation requires amendment and, if so, which data elements and operation are appropriate.

The process should not begin with the XEVPRM.

It should begin with the approved regulatory information.

The XEVMPD record should represent the authorised state after the variation has taken effect according to the applicable regulatory process.

A Variation That Does Not Affect XEVMPD

Now consider a variation that changes a manufacturing site but does not change any Article 57 medicinal-product information.

The regulatory event is important.

The XEVMPD record may nevertheless require no corresponding medicinal-product data change.

This is why a good process includes an impact assessment rather than automatically generating an XEVMPD submission for every variation.

The outcome of the assessment may be:

Variation received → XEVMPD impact assessed → no XEVMPD change required

That decision should be documented according to the organisation's procedures.

Complex Variations

Some variations may change several interconnected fields.

For example, a change in strength may require consideration of:

• strength;
• pharmaceutical form;
• product representation;
• substance relationships;
• additional product entities.

The risk is that one field is updated while a related field remains in the previous state.

This is a data-integrity problem rather than simply a missing-submission problem.

A useful review therefore asks:

What relationships within the medicinal-product record change as a consequence of the regulatory event?

This is one reason why XEVMPD maintenance requires understanding of the data model, not merely the submission interface.

Marketing-Authorisation Transfers

Transfers require particular attention because the legal entity responsible for the medicinal product changes.

A transfer may involve:

• the former MAH;
• the new MAH;
• multiple products;
• multiple member states;
• different regulatory procedures;
• changes to organisation information;
• changes to associated pharmacovigilance information.

The transfer should therefore trigger a controlled assessment of the affected XEVMPD records.

Example: Transfer of a Portfolio

Suppose Company A transfers 30 nationally authorised medicinal products to Company B.

The regulatory process establishes the effective transfer.

The XEVMPD maintenance process should identify the 30 affected product records and determine the appropriate updates.

A weak process might rely on the regulatory team informing the XEVMPD team informally.

A stronger process creates an explicit transfer event in the change-management system and automatically or procedurally identifies the affected product population.

The latter approach is less dependent on individual memory.

Why Transfers Can Produce Systemic Errors

A transfer involving one product may be straightforward.

A portfolio transfer is different.

If the organisation updates 29 of 30 products, the problem may not be one missed data entry.

It may indicate a population-control failure.

The investigation should therefore ask:

• How was the affected population identified?
• Was the list generated from a controlled source?
• Was the list reconciled against the regulatory portfolio?
• Were all products included?
• Were duplicate or historical records handled appropriately?
• Was the resulting XEVMPD state verified?

This is the same principle discussed in data-quality reconciliation: the population is part of the control.

Renewals

Renewal procedures require consideration of whether the information represented in XEVMPD changes as a consequence of the renewal.

A renewal is not simply a calendar event.

The organisation should determine whether the regulatory outcome changes the information that needs to be maintained.

For example:

Renewal completed

↓

Regulatory state assessed

↓

XEVMPD impact assessed

↓

Maintenance performed if required

This avoids the opposite errors of:

• failing to update when an update is required; and
• generating unnecessary changes when the XEVMPD representation has not changed.

Suspension

A suspension can have important implications for medicinal-product status.

The XEVMPD process should therefore identify the regulatory event and determine the appropriate maintenance operation.

Where a suspension is subsequently lifted, the lifecycle continues.

The organisation should be able to demonstrate that:

Suspension

and later:

Lifting of suspension

are both reflected appropriately.

The important control is not merely the submission of the first event.

It is maintaining the correct lifecycle state over time.

Revocation and Withdrawal

Revocation and withdrawal also require controlled lifecycle handling.

The terminology is important because the underlying regulatory events are not necessarily interchangeable.

The organisation should rely on the applicable regulatory decision and current EMA guidance rather than creating its own informal interpretation of the status.

A controlled process should capture:

• the regulatory event;
• the effective date;
• the affected medicinal-product population;
• the required XEVMPD maintenance;
• submission and verification.

Example: Withdrawal of a Generic Product

Suppose a generic product is withdrawn from the market following a regulatory decision.

The internal regulatory system records the withdrawal.

The XEVMPD maintenance process receives the event.

The team identifies the affected medicinal-product record and performs the applicable maintenance activity.

The final control is verification.

It is not enough to record:

"XEVPRM submitted."

The organisation should confirm that the resulting representation corresponds to the intended regulatory state.

This distinction becomes particularly important where multiple systems are involved.

QPPV and PSMF Information

XEVMPD is not limited to information describing the medicinal product itself.

Article 57 also supports maintenance of certain pharmacovigilance-system information, including QPPV and PSMF information.

EMA states that the Article 57 database is used for notifying changes to QPPV and PSMF information. Since February 2016, changes to the QPPV and PSMF location for the relevant products are notified through the Article 57 database rather than through a Type IA variation for that purpose. [2]

This creates an important interface between pharmacovigilance governance and regulatory-data maintenance.

Example: Change of QPPV

Suppose an MAH appoints a new QPPV.

The pharmacovigilance governance process identifies:

QPPV change

The Article 57 impact assessment identifies the affected product population and required update.

The XEVMPD information is maintained.

The organisation should then verify that the Article 57 representation corresponds to the current pharmacovigilance system information.

This is a good example of why XEVMPD cannot be managed entirely in isolation from pharmacovigilance governance.

PSMF Location Changes

A change in the location of the PSMF similarly creates an interface between the pharmacovigilance system and Article 57 data.

The internal change-control process should therefore ensure that:

• the regulatory change is identified;
• the Article 57 impact is assessed;
• the applicable update is submitted;
• the result is verified;
• internal records remain consistent.

The exact details should be controlled through current EMA requirements and the organisation's procedures.

The Importance of Effective Dates

Lifecycle maintenance becomes difficult when organisations focus on submission dates but do not control effective dates.

Consider:

Regulatory decision: 1 June

Internal notification: 5 June

XEVMPD submission: 10 June

The significance of each date is different.

The organisation needs to understand:

• when the regulatory change became effective;
• when the XEVMPD update became due;
• when the submission was made;
• when it was processed;
• when the resulting state was verified.

This becomes particularly important when assessing timeliness.

Timeliness Is More Than "Submitted on Time"

A useful lifecycle control distinguishes:

event date

→ notification date

→ impact-assessment date

→ submission date

→ processing date

→ verification date

This allows the organisation to identify where delay occurred.

For example, a submission may have been made within the required timeframe after the regulatory team notified the data team, but the regulatory-to-XEVMPD handoff itself may have occurred late.

The problem would then be an interface-control problem rather than a submission-processing problem.

The Regulatory Event Register

One practical control is a regulatory event register that identifies events requiring assessment for XEVMPD impact.

A simplified structure might contain:

The exact implementation can vary.

The principle is that the organisation should be able to demonstrate that relevant events were identified and followed through to closure.

Connecting Regulatory and XEVMPD Systems

The ideal process is not necessarily fully automated.

However, the interface should be explicit.

For example:

Regulatory system

↓

Change event

↓

XEVMPD impact flag

↓

Task generated

↓

XEVMPD maintenance

↓

Verification

Where automation is not available, a controlled procedural interface can achieve the same objective.

The risk increases when the interface depends entirely on informal communication.

The Population Problem

Lifecycle changes often affect a population rather than a single record.

Examples include:

• portfolio transfers;
• changes affecting multiple strengths;
• changes affecting multiple member states;
• changes to a shared pharmacovigilance system;
• organisational changes affecting multiple products.

The organisation should therefore distinguish:

event identification

from

population identification.

Finding the event is not enough.

The organisation must determine which XEVMPD records are affected.

Example: Shared Pharmacovigilance System

Suppose one QPPV and one PSMF cover 80 medicinal products.

The QPPV changes.

The Article 57 maintenance requirement may therefore affect a population of products associated with the relevant pharmacovigilance system.

A weak process might update only the product that happened to be used as the example during the change.

A controlled process identifies the complete population associated with the relevant system.

This is a good illustration of why master-data relationships matter.

Verification After Maintenance

Verification should answer:

Does the XEVMPD record now represent the intended regulatory state?

It can involve checking:

• product identity;
• changed fields;
• organisation;
• lifecycle state;
• associated pharmacovigilance information;
• affected population;
• processing status.

The level of verification should be proportionate to the change.

A simple change may require a straightforward record check.

A complex portfolio transfer may require population-level reconciliation.

Reconciliation After Major Lifecycle Events

The previous article discussed reconciliation as a general data-quality control.

Lifecycle events provide a particularly useful application.

After a major event, the organisation can compare:

expected post-event population

against

actual XEVMPD population.

For example:

30 products transferred.

The organisation should be able to demonstrate:

30 products identified → 30 products assessed → 30 products maintained as required → 30 products verified.

The numbers are illustrative.

The underlying principle is population traceability.

Vendor Involvement

If an external service provider performs XEVMPD maintenance, the lifecycle process should still be controlled by the MAH.

The vendor may:

• receive regulatory events;
• prepare XEVPRMs;
• submit data;
• monitor acknowledgements;
• perform reconciliation.

The MAH should nevertheless understand how the process works and retain appropriate oversight.

A useful vendor control is to test the complete lifecycle chain using actual examples.

For example:

Show how a recent variation moved from the regulatory decision to the XEVMPD update.

This is more informative than simply reviewing whether the vendor has an SOP.

Common Lifecycle-Maintenance Failures

Regulatory Event Not Communicated

A regulatory event occurs but the XEVMPD team is not notified.

Consequence: maintenance may not occur.

Impact Not Assessed

The event is communicated, but nobody determines whether XEVMPD is affected.

Consequence: either a required update is missed or unnecessary submissions are generated.

Incorrect Population

The event is correctly identified but the affected product population is incomplete.

Consequence: some records remain outdated.

Wrong Data Element

The correct product is identified but the wrong XEVMPD field is changed.

Consequence: the record remains partially inconsistent.

Submission Without Verification

The XEVPRM is submitted and acknowledged, but the resulting record is not checked.

Consequence: an incorrect update may remain undetected.

Internal Master Not Updated

The XEVMPD record is corrected, but the internal product master remains wrong.

Consequence: the next submission may reintroduce the error.

Vendor-Control Failure

The vendor performs the update but the MAH does not review the resulting data.

Consequence: the organisation may lack evidence that the regulatory state is correctly represented.

A Practical Lifecycle-Control Model

A controlled process can be structured as follows.

1. Identify

Capture the regulatory or organisational event.

2. Assess

Determine whether the event affects Article 57 information.

3. Define the population

Identify every affected medicinal-product record.

4. Determine the expected state

Use the applicable regulatory source.

5. Prepare the maintenance

Create the appropriate XEVPRM or use the applicable XEVMPDweb functionality.

6. Submit

Submit within the applicable timeframe.

7. Review processing

Examine acknowledgements and exceptions.

8. Verify

Confirm that the resulting XEVMPD state is correct.

9. Update internal sources

Ensure internal product data remain aligned.

10. Close

Retain evidence of the complete lifecycle.

This sequence is simple, but its value lies in making the interfaces explicit.

Inspection Perspective

An inspector may ask:

"How do you ensure XEVMPD remains current after regulatory changes?"

The answer should describe a functioning process rather than a person.

A strong process can demonstrate:

regulatory event

→ impact assessment

→ affected population

→ submission

→ processing

→ verification

→ internal reconciliation.

Evidence might include:

• change-control records;
• regulatory decisions;
• XEVMPD impact assessments;
• product lists;
• XEVPRM submissions;
• acknowledgement records;
• reconciliation results;
• deviation or CAPA records where relevant.

The exact evidence will depend on the organisation and event.

Metrics for Lifecycle Maintenance

Useful measures include:

Event-to-assessment time

How quickly relevant events are assessed for XEVMPD impact.

Assessment-to-submission time

How quickly required maintenance is submitted after the impact assessment.

Timeliness rate

The proportion of required submissions completed within the applicable timeframe.

Verification completion

The proportion of maintenance activities for which the resulting XEVMPD state was verified.

Lifecycle discrepancy rate

The frequency with which reconciliation identifies records that do not reflect known regulatory changes.

Repeat failure rate

The frequency with which the same lifecycle-control failure recurs.

These metrics are more informative when accompanied by root-cause analysis.

The Relationship With Data Quality

Lifecycle maintenance and data-quality reconciliation are closely related but distinct controls.

Lifecycle maintenance asks:

Did the regulatory change reach XEVMPD correctly?

Reconciliation asks:

Does the resulting XEVMPD state correspond to the expected state?

The first is a process control.

The second is a verification control.

Using both provides stronger assurance than relying on either one alone.

The Relationship With Pharmacovigilance

Some lifecycle events affect information that is directly relevant to pharmacovigilance.

Examples include:

• changes to QPPV information;
• changes to PSMF location;
• changes in product status;
• changes affecting medicinal-product identification.

The QPPV does not need to manage every XEVMPD transaction personally.

The pharmacovigilance system should nevertheless have appropriate visibility of changes that affect its information or its ability to operate effectively.

This is particularly important where regulatory data, product data and PV data are maintained by different functions or vendors.

Current XEVMPD Environment

The XEVMPD environment is evolving as EMA continues implementation of the wider Product Management Services and ISO IDMP framework.

EMA's current material describes XEVMPD as the existing Article 57 database and explains the ongoing transition toward the broader structured product-data environment. [2][8]

In 2026, EMA also introduced the upgraded XEVMPDweb interface for external users. From 11 May 2026, external users no longer access the Article 57 database through the former EVWEB interface and instead use XEVMPDweb. [9]

This is primarily a change in the user interface rather than a reason to redesign the underlying lifecycle-control principles.

The essential controls remain:

• identify the regulatory event;
• determine the XEVMPD impact;
• maintain the affected data;
• verify the result;
• preserve traceability.

Practical Worked Scenario

Consider a company with 25 generic products.

A regulatory transfer moves the marketing authorisations from Company A to Company B.

The regulatory team completes the transfer procedure.

The XEVMPD process receives the transfer notification.

The team identifies the affected products.

The initial reconciliation shows:

25 products expected

25 products identified

The maintenance submissions are prepared.

After processing, the organisation verifies:

24 products reflect Company B

1 product still reflects Company A

The investigation identifies that the product was held under a separate internal product code and was excluded from the original population query.

The correction is made.

The organisation then reviews whether other products are similarly coded.

This scenario illustrates the interaction between:

• lifecycle management;
• population identification;
• data reconciliation;
• root-cause analysis.

The important finding is not merely that one product was missed.

The more useful finding is that the population-identification method did not account for a particular product-code structure.

That can then be addressed in the process.

What Good Lifecycle Management Looks Like

A well-controlled XEVMPD lifecycle process has several characteristics.

Regulatory events are identified systematically.

The organisation knows which events require an XEVMPD impact assessment.

Affected products can be identified from controlled data.

The expected state is derived from appropriate regulatory sources.

Submissions are made within the applicable timeframe.

Acknowledgements and exceptions are reviewed.

The resulting XEVMPD state is verified.

Internal product data are maintained consistently.

Significant discrepancies are investigated for wider impact.

The process is sufficiently documented to demonstrate how a change moved from the regulatory event to the final data state.

This does not require every step to be automated.

It requires the interfaces and responsibilities to be controlled.

Key Takeaways

XEVMPD maintenance is a continuing lifecycle obligation.

A regulatory event should not be assumed to have been fully implemented until its impact on Article 57 data has been assessed and, where necessary, the resulting XEVMPD state has been verified.

The most important lifecycle events include:

• variations;
• transfers;
• renewals;
• suspensions;
• lifting of suspensions;
• revocations;
• withdrawals;
• changes to QPPV information;
• changes to PSMF information.

The central control is the interface between the regulatory event and the XEVMPD record.

A useful lifecycle process is:

identify → assess → define population → determine expected state → maintain → submit → review → verify → reconcile → close.

The affected population is as important as the individual record. Portfolio-level events can expose weaknesses that would not be visible when products are maintained one at a time.

Lifecycle maintenance and reconciliation provide complementary controls. Maintenance changes the data; reconciliation provides evidence that the resulting state is correct.

As the European product-data environment continues to evolve toward the broader ISO IDMP and Product Management Services framework, these principles remain relevant. The technology and interfaces may change, but the need to maintain accurate, current and traceable medicinal-product information remains.

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. Current Article 57 requirements for submission and maintenance of medicinal-product information.

3. European Medicines Agency. Data submission on authorised medicines (Article 57). Current information on post-authorisation maintenance, including variations, transfers, suspensions, revocations and withdrawals.

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

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

6. 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.

7. European Medicines Agency. Guidance documents related to data submission for authorised medicines. Current guidance concerning Article 57 data quality and maintenance.

8. European Medicines Agency. Data on medicines (ISO IDMP standards): post-authorisation. Current information on Article 57 data and the transition toward the Product Management Services framework.

9. European Medicines Agency. XEVMPDweb: upgraded XEVMPD user interface for external users. Current 2026 transition information.