EUDAMED FAQ

Use of the UDI/Devices module has been mandatory since 28 May 2026. For Regulation Devices whose first unit is placed on the EU market on or after that date, registration must be completed before the device is placed on the market.

If the first unit was placed on the market before 28 May 2026 and further units of the same Regulation Device or Legacy Device are placed on the market afterwards, the official transition timetable specifies 28 November 2026 as the latest registration date. This does not mean that all historical records had to be fully registered by 28 May.

Primary sources: European Commission — UDI/Device registration · UDI/Devices transition timetable

No. The current UDI/Devices transition timetable does not provide a blanket later special deadline for Class I devices. The determining factors are again whether the first unit was placed on the market before or on or after 28 May 2026, and whether further units are placed on the market afterwards.

The fact that a Notified Body is not involved in the registration process for many Class I devices does not alter the manufacturer's obligation to register the UDI/device. The data fields actually required depend on the MDR data set, the risk class and the device characteristics.

Primary sources: EU transition timetable · UDI/Device registration

Yes. Mandatory use from 28 May 2026 and the transition logic set out in the official timetable apply to both MDR and IVDR scenarios. An IVDR device must, however, use the IVDR-specific data set; it is not identical to the MDR data set.

Whether and by when a specific record must be registered should therefore be determined from the device status and date of placing on the market—not from a general statement such as ‘all IVDs by one single date’.

Primary source: European Commission — UDI/Device registration and data sets

For Legacy Devices whose first unit was placed on the market before 28 May 2026 and of which further units are placed on the market afterwards, the Commission specifies 28 November 2026 as the latest registration date.

Legacy Devices are not registered with a Basic UDI-DI in the same way as MDR/IVDR Regulation Devices. They use the EUDAMED DI/EUDAMED ID logic, which is explained separately below.

Primary sources: EU transition timetable · EUDAMED Help Centre — Legacy identifiers

Manufacturers, authorised representatives, importers and system/procedure pack producers are recorded as distinct Actor types under Economic Operators. A Regulation Device or Legacy Device is registered by the manufacturer; a system or procedure pack is registered by the producer responsible for it.

For a non-EU manufacturer, the Actor registration is first verified by the specified authorised representative, who must already be registered, and is then assessed by the competent authority. This must be distinguished from the subsequent registration of devices.

Primary sources: EUDAMED Help Centre — Actor introduction · UDI/Devices business rules

Yes. If an organisation performs several Actor roles, it must register each role separately. The manufacturer and importer roles therefore receive separate Actor records and separate Actor IDs/SRNs.

Users associated with several Actor records must select the correct Actor context before performing an action. This prevents device registrations or links from being created under the wrong role.

Primary source: EUDAMED Help Centre — Multiple roles

An importer with the required Linker profile creates the relationship in the Importer dashboard. The importer searches for the registered non-EU manufacturer using criteria including SRN, name or country, enters the required dates and confirms the link.

The currently published EUDAMED Help Centre procedure does not describe a separate approval step by the manufacturer after this confirmation. This is a statement about the documented EUDAMED process—not about contractual coordination between the companies.

Primary source: EUDAMED Help Centre — Linking a non-EU manufacturer to an importer

Select the correct manufacturer Actor and register the Basic UDI-DI together with its first associated UDI-DI. Depending on whether MDR or IVDR applies, enter the identification, device characteristics, additional device information, market information and, where applicable, certificate references and packaging UDI-DIs.

In the documented process, a Basic UDI-DI cannot be registered without at least one associated UDI-DI. The fields displayed depend, among other things, on the legal framework, risk class and answers to preceding characteristic questions. Even for a single device, the information should be reviewed for technical accuracy before submission.

Primary sources: Register Regulation Devices · Basic UDI-DI and UDI-DI procedure

Registered records are updated using ‘Create new version’, provided the field concerned can be changed. The manufacturer opens the record, creates a new version, changes the permitted information and submits that version.

The field rules are not uniform: under the current business rules, a Device Name can be added, changed and deleted. Different restrictions apply to a Device Model. The identification details of a Basic UDI-DI cannot be corrected freely. ‘Name’, ‘Trade name’ and ‘Model’ must therefore not be treated as the same field. Before any change, it must also be assessed from a regulatory perspective whether the device still belongs to the existing Basic UDI-DI.

Primary sources: EUDAMED Help Centre — Create new version · UDI/Devices business rules

The identification details of a stored Basic UDI-DI cannot be changed freely like ordinary master data. EUDAMED also checks the format and uniqueness of identifiers. A second registration must not be misused as a way to correct an existing record.

An identical UDI-DI may occur in the special case of an equivalent Legacy Device and Regulation Device from the same manufacturer; EUDAMED then uses it to link the records. This does not create a general right to use the same identifier for different devices. If an association is incorrect, the cause, registration status and permitted system action should be checked before creating a new record.

Primary sources: Basic UDI-DI information · UDI-DI identification

First indicate whether critical warnings or contraindications are present. If ‘Yes’ is selected, choose the applicable types offered by EUDAMED. If ‘Other’ is selected, a description and its language are required.

The wording must not be copied from generic examples. The approved, consistent product information for the specific medical device is authoritative. The website, labelling, instructions for use, technical documentation and EUDAMED record should not contradict one another.

Primary source: EUDAMED Help Centre — UDI-DI characteristics

When entering a Basic UDI-DI, EUDAMED first asks whether a Device Model exists. If ‘Yes’ is selected, the model is mandatory and the device name is entered additionally, if available. If ‘No’ is selected, the device name is mandatory.

The field should not be populated with an invented value merely to pass a mandatory-field check. It must reflect the manufacturer's actual device identification. Also note that different field rules apply to subsequent changes to the model and name.

Primary source: EUDAMED Help Centre — Basic UDI-DI information

There is no single short list of mandatory fields that applies equally to MDR, IVDR and every Legacy Device scenario. The Commission publishes separate data sets. Whether individual fields are mandatory or visible depends, among other things, on the legal framework, risk class, device characteristics, certificate requirements, market status and previous answers.

Typical data areas include the Basic UDI/device relationship, UDI-DI and issuing entity, EMDN, name/model, device characteristics, UDI-PI types, packaging, market information, authorised representative and—where applicable—certificate or other regulatory references. For reliable preparation, the appropriate official data set should be mapped field by field against the organisation's source data.

Primary source: European Commission — MDR, IVDR and Legacy Device data sets

No. The blanket statement that ‘both date fields are always mandatory’ is incorrect. In the current UDI/Devices business rules for Data Exchange, the start and end dates in Market Information are designated as optional.

These must be distinguished from the market status, the Member State where the device was first placed on the EU market and the countries in which the device is made available. Separate conditions apply to this information. For manual entry, the conditions currently displayed in the form and the appropriate official data set should therefore be observed.

Primary sources: UDI/Devices business rules, BR-DTX-UDI-096 · Additional device information

No. The field describes the Member States or territories provided for in the EUDAMED data set in which the device is or is intended to be made available on the EU market. It is not a general list of every country in which a device is distributed worldwide.

For a device with the status ‘On the EU market’, the current EUDAMED Help Centre states that this information is mandatory for certain risk classes; it can also be recorded for other risk classes. A device not intended for the EU market can be registered with the corresponding status. The status and country information must therefore not be conflated.

Primary sources: EUDAMED Help Centre — Market information · UDI/Devices business rules

It means the Member State in which the specific device was or is intended to be placed on the EU market for the first time. The field asks neither for the manufacturer's registered office nor for the first country of sale worldwide.

If the device is not intended for the EU market, the corresponding device status must be selected. If it is made available on the EU market, the actually applicable Member State must be derived from the market-launch process. The field should not be populated mechanically from a customer address, importer address or company headquarters.

Primary source: EUDAMED Help Centre — Additional device information

A Basic UDI-DI groups device variants that share the same fundamental regulatory characteristics. The EUDAMED Help Centre specifically refers to the same intended purpose, the same risk class and comparable essential design and manufacturing characteristics.

A Basic UDI-DI can cover one or more UDI-DIs, but it is neither a quantity group nor a technical upload container. Whether two variants belong together must therefore not be determined by the number of records or by a desire to minimise the number of XML files.

Primary source: EUDAMED Help Centre — Categorisation of devices

No. A Basic UDI-DI is not assigned to a Legacy Device. For Legacy Devices, EUDAMED instead uses an EUDAMED DI as the higher-level identification element and—if no UDI-DI exists—an EUDAMED ID derived from it.

If a UDI-DI already exists, it is used to identify the Legacy Device and EUDAMED generates the associated EUDAMED DI. If no UDI-DI exists, the manufacturer provides the required identification basis; EUDAMED generates the EUDAMED DI and EUDAMED ID. These identifiers are functionally comparable, but they are not equivalent to a Basic UDI-DI assigned by the manufacturer to a Regulation Device.

Primary sources: Legacy identification details · Generation without UDI-DI

If no suitable code exists, the current EMDN FAQ provides for selection of the appropriate ‘99 — Other’ code and submission of a reasoned change proposal via the EMDN Submission Platform. If a new code is subsequently created, the manufacturer must update the EUDAMED registration and the associated regulatory documentation.

EMDN is developed further through a public annual procedure. EUDAMED displays version histories and can indicate that an update is required when codes are discarded, split or reduced in scope. At the same time, the Commission notes that individual notification of all affected users is not currently available. Companies should therefore monitor changes actively.

Primary sources: MDCG 2021-12 Rev. 2 — EMDN FAQ · European Commission — EMDN · EUDAMED Help Centre — Search EMDN

No. EUDAMED does not list Excel as a separate input method. The officially available methods are manual entry through the user interface, upload of EUDAMED-compliant XML files and M2M Data Exchange. Excel can be used upstream as a structured data source or data-entry template.

In the Europe IT XML process, the customer completes a defined Excel template. Europe IT validates the data, generates EUDAMED-compliant XML files following a successful check and uploads them for the customer through the manual XML upload process. XML generation, data validation and the upload itself are separate steps.

Primary source for the input methods: EUDAMED Help Centre — Guidelines on Data Exchange · Europe IT service: Prepare UDI data with Excel

No. With XML Bulk Upload, files are generated in a structured format and validated against EUDAMED schemas, but according to the Commission, uploading and downloading remain manual user actions. With M2M Data Exchange, an external backend communicates automatically with the EUDAMED backend services.

Europe IT uses M2M as the technical transmission method within suitable solutions. In the Global Submission Portal the customer uploads the Europe IT Excel template, receives automatic validation and, when the data contain no errors, initiates the M2M submission by clicking ‘Transmit’. In GUDI for SAP the customer manages, checks and approves data in GUDI and transmits them directly from there to the authority via M2M. Europe IT does not position this as an arbitrary, isolated standard interface installed in the customer's system.

Primary sources: Data Exchange — Purpose · M2M prerequisites

The choice does not depend solely on 100, 1,000 or any other fixed number of UDI-DIs. The decisive factors are the data source, Basic UDI/UDI-DI structure, relationships, data quality, submission frequency, need for changes, source system and desired operating model.

• Project-based XML process: for a clearly defined data transmission in which Europe IT validates Excel data, generates XML and manually uploads the files.
• Global Submission Portal: for customer-controlled, recurring submission workflows using the Europe IT Excel template, with automatic validation, M2M transmission, status and authority feedback.
• GUDI: for UDI data management in SAP, with authority-specific modules, approval, validation and direct M2M transmission from GUDI.
• Consulting and data preparation: when the device scope, data model, responsibilities or data quality first need to be clarified.

A neutral comparison is available at Compare EUDAMED transmission methods.

Note: The volume ranges specified by the Commission are guidance values. They do not replace a project-specific assessment of the technical and operational conditions.

First check the Actor context, record type, status filter and combination of search filters. Management views often show drafts by default; other statuses must be retrieved using filters. In the general search, a record must satisfy all selected filter conditions at the same time.

Are you searching for a Basic UDI-DI, a UDI-DI, an EUDAMED DI or an EUDAMED ID? Are you in the correct manufacturer Actor? Are you viewing internal management or the public search? These questions are more reliable than undocumented assumptions about upper- and lower-case letters or claims that partial searches are generally unavailable.

Primary sources: Manage Basic UDI-DI/EUDAMED DI · Search & View devices

Treat the feedback as a specific rule violation and first preserve the complete context. This includes the transmission time, Actor, module, record identifier, field or XML path, submitted value, error code, message text and record version.

1. Separate technical formatting errors from substantive data errors and authorisation/status problems.
2. Correct the affected source—not merely a derived XML file.
3. Revalidate dependent fields and relationships.
4. Only then resubmit and check the status and authority feedback.

In GSP and GUDI, the customer can retrieve status information and authority feedback. The customer corrects substantive data errors and also initiates any resubmission. Recurring messages and guidance on interpreting them can be found in the EUDAMED error library.

Note: An error message initially demonstrates only that a particular system rule or business rule has not been satisfied. Its substantive cause must be investigated using the affected record.

Not as a blanket rule. The Commission explains that, once an EUDAMED module becomes mandatory, the corresponding obligations under the former directives and their national implementations cease to apply. In particular, this is intended to avoid duplicate device and certificate registration for the same EU process.

However, this does not mean that EUDAMED replaces every national register, reporting channel or area of responsibility for every market role and every situation. For example, the MDR expressly allows Member States to retain or introduce national provisions on the registration of distributors. A reliable statement must therefore examine the specific national obligation, not merely the name of a database.

Primary sources: European Commission — EUDAMED Q&A on transition deadlines · MDR, in particular Article 30(2)

Assess the country, market role, device type and specific reporting or registration action separately. Do not ask only ‘Is there still a database there?’ Ask, for example: Does the requirement concern the manufacturer, importer or distributor? Is it an Actor, device, distribution or another type of registration? Does it apply to MDR/IVDR devices or to a special case?

The competent national authority should be used as the primary source. The EUDAMED registration and any remaining national obligation must be managed as separate target systems in the process. This page therefore does not generalise country-specific residual obligations without a current source.

EU legal basis: Regulation (EU) 2017/745. For the specific country, the current publication from its competent authority is additionally authoritative.