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