Data Version Management in EUDAMED

Data version management in EUDAMED is a critical issue that is often poorly understood by medical device manufacturers. Unlike a traditional database, EUDAMED is based on strict traceability, in which certain data is considered immutable. Any modification of these so-called non-modifiable attributes requires the creation of a new UDI-DI identifier, with significant consequences for operational processes.

Each time UDI-DI data is submitted, the quality of the information transmitted is therefore paramount: the possibilities for correction are either non-existent or very limited and conditional. An error in a critical attribute can thus have disproportionate impacts, including the relabeling of devices already in stock with a new UDI-DI. Understanding these versioning rules, as well as the criteria that trigger a new UDI-DI, is therefore essential to anticipate impacts and avoid costly errors.

Written by

Christophe Devins

Published on

Understanding the Complexity Behind Data Modifications in EUDAMED

Restrictive modification rules

EUDAMED is a regulatory database with its own rules that are binding on all manufacturers who wish to distribute their medical devices in European Union countries.

Compared to the requirements of a purchasing group (GPO) on a manufacturer’s catalog data, little data in EUDAMED is modifiable, and when it is, these changes are tracked.

Thus, modifying data in EUDAMED often results in the creation of a new UDI-DI and, for modifiable data, an increment in the data version for the UDI-DI concerned.

It is therefore important to keep a few simple rules in mind:

Modifications prohibited in EUDAMED once device data has been published:

  • Most attributes become non-modifiable after publication. They are considered ‘triggers’ in the sense that they lead to the creation of a new UDI-DI (or, in case of errors, the deletion of the existing record).
  • Physical deletion of a record (“delete”) is only possible in “draft” status, i.e., before publication.
  • Logical deletion of a record (“discard”) is only manual and possible if the device is not involved in a vigilance action.

Traceability of data authorized for modification

  •  The value of certain attributes can be modified. These attributes are not considered ‘triggers’. However, such modifications do result in a new version of the record in EUDAMED history.

Some exceptions to the versioning of modifications:

  • Adding EU countries
  • Status in EUDAMED: Draft → Submitted → Registered (Published) → Discarded

Impact on Business Processes

Mandatory planning

Any significant change to the product, or to an attribute marked as a ‘trigger’ in EUDAMED, will lead to the generation of a new UDI-DI and the submission of a new record.

This requires:

  • Publication of quality data
  • Data validation prior to publication
  • EUDAMED training for teams responsible for managing, collecting, validating, and publishing data

Complex error management

  • Correcting non-modifiable data can only be done by manually deleting the record (Discard).
  • Updates to modifiable data are versioned.

System coordination requirements

Effective coordination between EUDAMED and your internal information system requires:

– Synchronization of historical data between EUDAMED and your internal systems
– Implementation of version control within your regulatory product repository
– Full alignment between the records and data changes made in EUDAMED and those reflected in your internal traceability system

Understanding the Status of Records in EUDAMED

“Draft” status

  • Data can be freely modified
  • Can be completely deleted
  • Not visible in public EUDAMED
  • Recommendation: Correct data before publication

“Registered” status

  • Official compliance status
  • Data visible in EUDAMED
  • Modifications limited to certain attributes
  • New versions automatically created by EUDAMED when attributes change
  • Logical deletion possible under “discarded” conditions

Note: The intermediate “submitted” status applies to devices requiring EU certification. Modifications are locked under this status.

“Discarded” status

  • Maintained in EUDAMED history
  • Not visible in public searches

EUDAMED Triggers

Many attributes in EUDAMED cannot be modified once published. Changing them can trigger a new UDI-DI and require relabeling of devices already produced.

Examples of triggers related to Basic UDI-DI:

  • Change of notified body → FLD-UDID-01 “Issuing entity Basic UDI-DI”
  • Change of legal manufacturer → FLD-UDID-10 “Legal Manufacturer SRN”
  • Change of risk class → FLD-UDID-16 “Risk class”

Examples of triggers related to UDI-DI:

  • Change in base quantity → FLD-UDID-151 “Quantity of device”
  • Change in commercial reference → FLD-UDID-163 “Reference/Catalog number”
  • Change in clinical dimensions → FLD-UDID-146 “Clinical Sizes”

Version Management Strategies

Principle 1: Upstream validation

Enhanced validation process:

  • Technical validation: data compliance
  • Business validation: consistency with technical documentation
  • Regulatory validation: alignment with certificates and declarations
  • Quality validation: comprehensive ALCOA+ checks

Support tools:

  • Pre-publication validation checklist
  • Data simulation in test environment
  • Cross-validation by multiple users
  • Automatic checks before submission

Principle 2: Planning changes

Anticipate modifications:

  • Schedule product changes
  • Integrate MDR/IVDR triggers
  • Coordinate with certification cycles
  • Plan regulatory updates
  • Synchronize with EUDAMED changes

Principle 3: History and traceability

Ensure documentation:

  • Justify each version creation
  • Link to product modifications
  • Maintain traceability with technical documentation
  • Archive previous versions

Maintain history:

  • Retain all versions internally
  • Map EUDAMED versions to internal references
  • Maintain certificate traceability

Tools and Processes to Control Versioning

Expected features

  • Automatic change tracking
  • Validation workflow before publication
  • Change simulation in test environment

Recommended architecture

  • Central regulatory repository
  • Automatic synchronization (M2M)
  • Bidirectional EUDAMED synchronization

Business Impacts

Direct costs

  • Time spent re-entering data
  • Resources for manual management
  • Product launch delays
  • Process complexity

Indirect costs

  • Risk of non-compliance
  • Confusion between active versions
  • Audit traceability issues
  • Impact on relations with authorities

Optimization and Best Practices

Optimization of changes

  • Plan updates carefully
  • Validate data before publication
  • Coordinate updates with product cycles

Efficiency improvement

  • Control costs via M2M automation
  • Standardize modification workflows

Conclusion

Version management in EUDAMED is not just a technical constraint; it is a strategic pillar of compliance.

Keys to success:

  • Anticipation: validate data before publication
  • Organization: clear processes and defined roles
  • Automation: M2M publishing tools for EUDAMED
  • Training: educate teams on EUDAMED specifics

Companies that master versioning ensure compliance, streamline processes, and demonstrate adaptability.

ACKOMAS: Expert Control of EUDAMED

The ACKOMAS platform natively integrates efficient change management in EUDAMED.

With its automated workflows, validation controls, and full traceability, ACKOMAS transforms versioning complexity into a smooth, secure process.

📘 Download the complete EUDAMED guide

FAQs

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.