Technical guide · EUDAMED UDI/Devices
Content reviewed: 3 September 2026
Guidance for medical device manufacturers
EUDAMED UDI/Devices: requirements and implementation for manufacturers
UDI/device registration involves more than entering identifiers in a form. Manufacturers need reliable product data, traceable relationships between Basic UDI-DI and UDI-DI, defined approvals and a suitable process for validation, submission and authority feedback.
What is EUDAMED UDI/Devices?
EUDAMED UDI/Devices is the module of the European database on medical devices in which manufacturers register UDI and product-related information. It connects product identification with structured regulatory information and makes selected information accessible through the public EUDAMED website.
EUDAMED as a whole comprises six interconnected modules. Since 28 May 2026, use of Actor Registration, UDI/Device Registration, Notified Bodies & Certificates and Market Surveillance has been mandatory. This page focuses on the subject-matter and technical preparation of UDI/device data. For an explanation of all modules, see our overview of the EUDAMED structure.
The short answer: A sound EUDAMED process does not start with the upload. It starts by identifying the products and records concerned, where the required information originates, who is responsible for its content and how future changes will be controlled.
What do manufacturers need to prepare for EUDAMED?
Registration is a company-wide data task. Regulatory Affairs understands the regulatory classification, product management and development know the product, quality management is responsible for controlled processes, and IT provides data sources and submission methods. The following five work packages establish a common foundation.
Define the product scope
Which MDR, IVDR or legacy scenarios apply? Which products need new registration, additions or ongoing maintenance? Transitional cases must not be inferred solely from product counts or market introduction dates.
Assign identifiers
The Basic UDI-DI represents the overarching regulatory relationship between related products. The UDI-DI identifies the specific product version. These relationships must be unambiguous and consistent before submission.
Identify data sources
Information may reside in Excel, SAP, an ERP system, a regulatory database or several specialist systems. For each field, the authoritative system and the person approving changes should be defined.
Ensure data quality
Mandatory fields, permitted values, dependencies and authority business rules must be checked before submission. XML validity alone does not resolve every question about the plausibility of the content.
Define the operating model
Who initiates submission, checks status, evaluates authority feedback, corrects records and triggers resubmission? These roles belong in the target process, not just in error handling.
Keep the concepts separate
Four layers of an EUDAMED UDI process
Many misunderstandings arise from mixing source data, software, submission methods and operating models. These four layers must be considered separately to make a sound decision.
| Layer | Key question | Examples |
|---|---|---|
| 1 · Data source | Where is the data created and maintained? | Excel, SAP, ERP, databases and other structured source data |
| 2 · Europe IT solution | What is used to structure, validate and control data for submission? | Excel/XML process, Global Submission Portal, GUDI for SAP |
| 3 · Submission method | How do approved data technically reach EUDAMED? | Manual entry, manual XML upload, M2M/Data Exchange |
| 4 · Operating model | Who operates the process, and how often? | One-off transfer, recurring submissions, software operation, project support |
An EUDAMED UDI project in six steps
The project workflow connects regulatory decisions with data management and technology. Individual steps may overlap, but each should produce a verifiable result.
1
Scope and regulatory scenarios
Define products, markets, legal frameworks, product status and transitional scenarios. Result: a documented list of the records to be handled.
2
Data inventory and responsibilities
Map the required information to source systems and content owners. Result: visibility of data gaps, duplicates and approval responsibilities.
3
Data model and relationships
Structure Basic UDI-DI, UDI-DI and other regulatory information correctly. Result: a consistent data model for the intended submission method.
4
Content review and validation
Check completeness, permitted values, dependencies and technical rules. Result: data with traceable approval before submission.
5
Submission and status monitoring
Use manual entry, XML upload or M2M as appropriate to the process. Result: documented submission status and authority feedback that can be evaluated.
6
Corrections, resubmission and ongoing maintenance
Evaluate feedback, correct data in the responsible source and resubmit in a controlled way. Result: a repeatable operating process rather than a one-off data exercise.
Existing project diagram
The diagram illustrates the project approach. Binding regulatory deadlines and current EUDAMED requirements are determined solely by the applicable primary sources.
Manual entry, XML or M2M: three submission methods
The European Commission provides three data entry methods. The choice does not depend solely on a fixed number of UDI-DIs. Data structure, Basic UDI-DI relationships, frequency, data quality, source system, validation needs and the intended operating model are equally important.
| Method | Technical meaning | Practical implications |
|---|---|---|
| Manual entry | Data is entered through the EUDAMED user interface. | The user works on individual records in the system. Workload is strongly influenced by scope, variants and the frequency of changes. |
| XML Bulk Upload | Structured data is converted into EUDAMED-compliant XML files and checked against the applicable XSDs. Uploading the files remains a manual step. | XML generation, pre-validation and the actual upload are separate process steps. File structure and upload sequence must match the dataset. |
| M2M / Data Exchange | A suitable external system exchanges data automatically with EUDAMED backend services. | Onboarding, authorisation, the access point, technical rules, status processing and operation must be organised as one connected process. |
From data preparation to submission
How Europe IT supports the EUDAMED UDI process
Europe IT combines UDI expertise, data validation and different submission models. The appropriate service depends on where the data resides, how often submissions are made and how the customer intends to operate the process.
Excel and data preparation
An appropriate Excel template supports the collection of structured source data. The data can then be checked and prepared for the intended submission process.
XML project process
At the customer’s request, Europe IT validates the completed data, generates EUDAMED-compliant XML files after successful checks and uploads them manually to EUDAMED on the customer’s behalf. Validation, XML generation and upload remain clearly separate steps.
Global Submission Portal
The customer uploads the completed template to GSP. After automatic pre-validation and successful checks, the customer initiates submission. For EUDAMED, the portal uses the M2M/Data Exchange process operated by Europe IT and provides submission status and authority feedback.
GUDI for SAP
GUDI brings together shared UDI data and authority-specific fields in SAP. The customer approves data in GUDI and submits it directly from there to the relevant authority via M2M. Submission status and authority feedback are reflected in the process.
Existing process diagram
Typical risks arise before submission
A technical upload can only process data that has already been structured and approved. Significant effort often arises at the interfaces between specialist teams, source systems and authority rules.
Unclear field ownership
When the same information is maintained in several systems, an authoritative source and a clear approval process are often missing.
Incorrect relationships
Basic UDI-DI and UDI-DI must be correctly related in terms of their meaning. Checking columns alone does not replace this modelling.
Validation performed too late
Checking only at submission moves data clarification into a critical project phase and makes root-cause analysis harder.
Missing feedback channel
Status and authority feedback must be assignable to a record, evaluated and addressed in the responsible source.
A one-off project without a maintenance process
Product changes, new variants and corrections require controlled processes after initial registration as well.
Rigid volume thresholds
The number of records is only one decision criterion. Complexity, frequency, quality and the operating model may be more important.
Regulatory status
UDI/Devices has been mandatory since 28 May 2026
According to the European Commission, four EUDAMED modules have been mandatory since 28 May 2026: Actor Registration, UDI/Device Registration, Notified Bodies & Certificates and Market Surveillance. According to the current overview, Vigilance/Post-Market Surveillance and Clinical Investigations/Performance Studies are still in development or analysis.
For UDI/Devices, the Commission provides datasets and information for MDR, IVDR and legacy devices. The registration and transitional requirements applicable to a specific product should be checked against current legislation and primary sources.
Note: This page provides technical and subject-matter guidance and does not replace an individual legal or regulatory assessment.
Frequently asked questions about EUDAMED UDI implementation
What is the difference between EUDAMED and the UDI/Devices module?
EUDAMED is the entire European database with six interconnected modules. UDI/Devices is the module for registering UDI and product-related information.
Since when has the UDI/Devices module been mandatory?
According to the European Commission’s current information, use of the module has been mandatory since 28 May 2026. Transitional and legacy rules may be relevant for individual products.
What is the difference between Basic UDI-DI and UDI-DI?
The Basic UDI-DI is the overarching regulatory identifier under which related products are structured. The UDI-DI identifies the specific product version. For EUDAMED, the relationships between both levels must be represented correctly.
Are XML Bulk Upload and M2M the same?
No. XML Bulk Upload involves generating XML files and then uploading them manually to EUDAMED. M2M/Data Exchange transfers data automatically between a suitable external system and the EUDAMED backend.
Is M2M only useful for very large data volumes?
Not necessarily. Data volume is one factor, but submission frequency, data structure, automation level, source system, validation requirements and the intended operation also influence the decision.
Does Europe IT build a generic EUDAMED interface at the customer’s site?
Europe IT does not position M2M as an isolated generic interface installation. Data Exchange is used within an appropriate Europe IT solution: through the Global Submission Portal or directly from GUDI for SAP.
Who corrects errors and initiates resubmission?
With GSP and GUDI, the customer evaluates and corrects their data and then initiates resubmission. The solutions provide submission status and authority feedback within the process.
Further insight
UDI data management at a glance
The existing video complements the technical guidance with a visual introduction to UDI data management and process design.
Official sources and further information
For regulatory information subject to change, Europe IT refers to the European Commission’s current primary sources.
Next step
Which EUDAMED UDI process fits your data?
We consider the data source, data structure, validation needs, submission method and operating model together. This helps determine whether an Excel/XML process, the Global Submission Portal or GUDI for SAP provides the right foundation.