UDI database registration is the act of submitting the data elements specified in MDR Annex VI Part B to the UDI database inside EUDAMED, under MDR Articles 28 and 29, before placing a device on the EU market. The manufacturer prepares the Annex VI Part B dataset against the Basic UDI-DI and UDI-DIs already assigned under Article 27, enters the data through the EUDAMED user interface or via the machine-to-machine interface described in Commission Implementing Regulation (EU) 2021/2078, validates the submission against the technical documentation and the Notified Body certificate where applicable, and then keeps every field current for as long as the device is on the market under Article 29(3). This post is the step-by-step guide to preparing, entering, validating, and maintaining that record, and the specific mistakes that cause rejections and audit findings.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • UDI database registration sits at the intersection of MDR Article 28 (which establishes the database) and Article 29 (which places the submission obligation on the manufacturer before placing the device on the market).
  • The data submitted is the Annex VI Part B dataset, attached to the Basic UDI-DI and the UDI-DIs. The UDI-PI is not submitted to the database; it lives on the physical unit under Annex VI Part C.
  • Entry is done via the EUDAMED user interface for small catalogues or via the machine-to-machine interface specified in Commission Implementing Regulation (EU) 2021/2078 for larger ones.
  • Validation is a structured internal review that cross-checks the database record against the technical documentation, the declaration of conformity, the label, and the Notified Body certificate.
  • Update obligations under Article 29(3) are ongoing. Every change to an Annex VI Part B field requires a record update, and the QMS change control process must include a EUDAMED maintenance action.

Why this step is where founders get stuck

The first six steps in the device registration sequence are conceptual and strategic. Choose an issuing entity. Assign a Basic UDI-DI. Define UDI-DIs. Design the label. Talk to the Notified Body. Most founders can reason their way through those decisions with a careful reading of Articles 27 and 29.

The seventh step is operational, and operational is where regulatory projects quietly stall. A founder sits in front of the EUDAMED UI, or stares at the XML schema for the machine-to-machine interface, and realises that every field needs a source and every source needs to agree with every other source. What looked like a form to fill in turns out to be an integration problem between the technical file, the label, the certificate, the QMS, and a public database that will outlive the current team. This is the post that walks through that integration without pretending it is simpler than it is.

The pillar for this cluster is What is EUDAMED?. For the legal architecture behind the submission, read MDR Articles 27–29: UDI Requirements Decoded for Startups and What is UDI? first. For the end-to-end device registration sequence that contains this step, read Device Registration in EUDAMED: Step-by-Step. This post zooms into the database submission itself.

Step 1 — Prepare the Annex VI Part B data elements

Database entry fails when the data is not ready before the form opens. The first step is to assemble the Annex VI Part B dataset in a single place, cross-checked against every other document that references the same field.

MDR Article 28(1) directs the Commission to set up and manage the UDI database to validate, collate, process, and make available the information referred to in Annex VI Part B. Article 29(1) requires the manufacturer, before placing a device other than custom-made on the market, to assign a Basic UDI-DI and provide it to the UDI database together with the other core data elements referred to in Part B of Annex VI. Annex VI Part B is the authoritative list. Read it directly from the consolidated text.

The practical preparation list, written as fields a startup actually fills in:

  • Basic UDI-DI — assigned under the rules of the chosen issuing entity, grouping devices that share intended purpose, risk class, and essential design and manufacturing characteristics per Article 2(15).
  • UDI-DI at each packaging level — one per primary pack, one per higher-level carton or case, each under the issuing entity's allocation rules.
  • Manufacturer identification — name, address, and Single Registration Number issued under Article 31. The SRN links the device record to the actor record automatically.
  • Authorised representative identification — SRN, name, and address where the manufacturer is established outside the Union.
  • Risk class — the MDR Annex VIII class, consistent with the technical documentation and the Notified Body certificate where applicable.
  • Device name or trade name and device model — as they appear on the label.
  • Device description and EMDN code — the European Medical Device Nomenclature code assigned by the manufacturer after consulting the EMDN tree.
  • Quantity per package configuration — the number of units per UDI-DI at each packaging level.
  • Special attributes flags — single-use, reusable, sterile, sterile at point of use, implantable, measuring function, containing medicinal substances, containing substances of concern (CMR or endocrine disruptors), latex content, and the other regulatory flags listed in Annex VI Part B.
  • Status — on the market, no longer placed on the market, recalled, with the corresponding date fields.
  • Links to the instructions for use — where electronic IFU is provided under Commission Implementing Regulation (EU) 2021/2226, the URL.
  • Clinical investigation references — where relevant identifiers exist for investigations supporting the clinical evaluation.
  • Notified Body identification number — where the conformity assessment involves a Notified Body.

Assemble these in one table, one spreadsheet, or one record in the QMS. Cross-reference each field to the source document that owns it — the technical file section, the label file, the certificate, the declaration of conformity. When a field has two candidate values in two documents, stop and reconcile before opening EUDAMED. Data that is inconsistent at preparation time will be inconsistent after submission.

Step 2 — Choose the entry method: UI or machine-to-machine

The second step is the entry method decision. Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021 lays down the detailed rules for the application of Regulation (EU) 2017/745 as regards EUDAMED, including data submission channels. Two channels are supported.

The EUDAMED user interface. A web form that walks the operator field by field through the Annex VI Part B dataset. The UI is the right choice for a startup with one device, a handful of variants, and a manual release cadence. It is also the right choice for the first device a team ever registers, because the UI surfaces validation errors one field at a time and trains the team on the data model.

The machine-to-machine interface. An API-based submission channel, specified in (EU) 2021/2078 and documented by the Commission, that allows bulk upload of device records from the manufacturer's own system. The machine-to-machine interface is the right choice when the catalogue exceeds roughly twenty device records, when new variants are added frequently, or when the manufacturer already holds the master data in a structured system such as a PLM tool or an ERP with a product master module.

The subtraction test applies here too. A small startup with five UDI-DIs and a slow release cadence does not need to build a machine-to-machine integration to register five records. The UI is sufficient and the integration cost — specification, development, testing, validation — does not pay back. A scaling manufacturer with hundreds of variants across multiple product families does need the integration, because manual entry at that scale becomes its own source of error. Pick the channel that matches the real scale, not the imagined future one.

Whichever channel is chosen, the operator submitting the data must be authenticated against EUDAMED under the actor record created in Step 1 of the broader device registration sequence. The submission is bound to the SRN.

Step 3 — Validate the submission before marking complete

The third step is validation. Submission is not complete when the data has been typed into the form. It is complete when the data has been cross-checked against every parallel source that holds the same field.

Validation is a structured walk-through, not a vibe check. For each field in the submitted record, confirm:

  • Basic UDI-DI matches the Basic UDI-DI on the declaration of conformity, on the technical documentation cover sheet, on the Notified Body certificate (where applicable), in the clinical evaluation report, and in the Summary of Safety and Clinical Performance for Article 32 devices.
  • UDI-DI at each packaging level matches the UDI carrier printed on the corresponding label.
  • Manufacturer SRN matches the current SRN on the actor record and on any parallel registrations.
  • Authorised representative SRN matches the SRN on the authorised representative's actor record and on the mandate agreement.
  • Risk class matches the class stated in the technical documentation, on the certificate, and in the conformity assessment file.
  • Device name matches the label word for word.
  • EMDN code accurately reflects the device type; a best-fit code is better than a generic one.
  • Special attributes flags match the corresponding statements in the technical documentation and the IFU.
  • Status and date fields match the actual market status on the day of submission.
  • IFU URL resolves to the current IFU and is under the manufacturer's control.

Any mismatch found at validation is fixed at the source. A field in the EUDAMED record that disagrees with the technical file is a finding waiting to happen the next time a Competent Authority or a Notified Body cross-references the two. Fixing the disagreement in EUDAMED without fixing it in the source document hides the problem, it does not solve it.

Validation is also the last checkpoint for Article 27(6). That paragraph requires the manufacturer to verify, before placing the device on the market, that the Annex VI Part B data has been submitted in accordance with Article 29. A documented validation step satisfies Article 27(6) with a clear record. An undocumented "we pressed submit" does not.

Step 4 — Satisfy the ongoing update obligations

The fourth step is not an action but an ongoing obligation. Article 29(3) requires the manufacturer to keep the information up to date following the placing of the device on the market. Article 29(2) applies the same principle to actor-level data. Update obligations are where most database drift occurs.

The trigger categories a startup must plan for:

  • Identifier-affecting changes. A change in device name, model, intended purpose, labelling, or other attributes enumerated in Annex VI Part C triggers a new UDI-DI under Article 27(5). A new UDI-DI is a new database record. The old record transitions to an appropriate status rather than being deleted.
  • Non-identifier changes to Annex VI Part B fields. A change of authorised representative, a change of IFU URL, a change to a special attribute flag (for example, a new substance of concern flag added to the regulation), or a change in the EMDN code following a nomenclature update all require the existing record to be updated.
  • Status changes. When a device is no longer placed on the market, when it is recalled, when it is superseded by a new variant, the status field and the corresponding date are updated.
  • Certificate changes. When the Notified Body certificate is renewed, amended, or withdrawn, the reference in the device record has to reflect the current certificate.

The operational mechanism that prevents drift is a change control hook in the QMS. EN ISO 13485:2016+A11:2021 requires documented change control. Every change request that affects a field in Annex VI Part B should explicitly include a EUDAMED maintenance action as a mandatory step. Without that hook, every change that happens in the real device slowly pulls the public record out of alignment, and the gap becomes a compounding audit risk.

A quarterly EUDAMED reconciliation run — a short review in which every live record is compared against the current technical file — catches anything the change control hook missed and is cheap relative to the cost of fixing a multi-record divergence under audit.

Step 5 — Recognise the common mistakes before you make them

The mistakes that show up repeatedly in UDI database submissions are a short list. Recognise them in advance and plan around them.

Submitting without an SRN. The actor record under Article 31 must be complete first. Every device record is bound to an SRN, and the form will not accept a submission without one.

Typing the Basic UDI-DI and UDI-DI instead of generating them. UDIs are allocated under the rules of the designated issuing entity. Typing a free-form string into the Basic UDI-DI field because "it is only an identifier" produces a non-conformant record that will fail validation.

Mismatching the Basic UDI-DI with the Notified Body certificate. When Article 29(2) applies, the Notified Body works from a specific Basic UDI-DI. If the database record uses a different one, the certificate and the record do not match, and Step 3 validation will catch it too late if the submission has already been made.

Picking a generic EMDN code when a specific one exists. A generic code makes the device harder to classify downstream and attracts questions at audit. The EMDN tree is navigated until the most specific applicable node is reached.

Using a URL for the IFU that you do not control. The IFU URL field must point to a resource under the manufacturer's control, with version management under (EU) 2021/2226 for eIFU where applicable. A marketing page URL is not an IFU URL.

Forgetting Article 27(6) verification. The pre-market verification that the database submission has been made is itself an obligation. A record of the verification — a signed checklist, a release note, a QMS record — closes the loop.

Treating submission as the end of the work. Article 29(3) makes the record a living object. Teams that submit once and never look at the record again create exactly the drift the Article was written to prevent.

The Subtract to Ship angle on UDI database entry

UDI database registration is a candidate for the Subtract to Ship framework for MDR because the waste is so easy to identify. The real work is the Annex VI Part B dataset, submitted once per Basic UDI-DI and UDI-DI, validated against the technical file and the certificate, and maintained under change control. That is the whole job.

Everything outside that job is a candidate for removal. Parallel spreadsheets that mirror Annex VI Part B without feeding EUDAMED, custom dashboards that reformat the public record into an internal view, "UDI database readiness" workshops that do not end with a concrete submission plan, and speculative early submissions before the Basic UDI-DI and the technical file are stable — all waste. If a proposed activity does not trace to Article 28, Article 29, Annex VI Part B, or Commission Implementing Regulation (EU) 2021/2078, it does not belong in the UDI database workstream.

The master copy of the Annex VI Part B data lives in one place, ideally in the QMS or the product master system that change control already touches. EUDAMED is the destination, not a second master. Every additional copy of the same data creates another place for it to drift.

Reality Check — Is your UDI database submission ready to go?

  1. Do you hold a valid SRN under Article 31 against which the device record will be bound?
  2. Have you assembled the full Annex VI Part B dataset in one place, with each field cross-referenced to its source document?
  3. Have you chosen between UI entry and the machine-to-machine interface under (EU) 2021/2078, and does the choice match the real scale of your catalogue?
  4. Does the Basic UDI-DI in your draft submission match the Basic UDI-DI on the declaration of conformity, the technical documentation, and the Notified Body certificate where applicable?
  5. Do the UDI-DIs in the draft submission match the UDI carriers printed on the corresponding labels?
  6. Is the EMDN code the most specific applicable node rather than a generic one?
  7. Do the special attributes flags agree with the statements in the technical documentation and the IFU?
  8. Does your QMS change control process include a EUDAMED maintenance action for every change that affects an Annex VI Part B field?
  9. Have you planned an Article 27(6) verification step that produces a documented record before the device is placed on the market?

If you cannot answer seven or more of these cleanly, the UDI database submission is not yet ready to run.

Frequently Asked Questions

What is the UDI database in EUDAMED? The UDI database is the module within EUDAMED that holds the data elements specified in MDR Annex VI Part B for every Basic UDI-DI and UDI-DI. It is established by MDR Article 28 and its detailed functioning is governed by Commission Implementing Regulation (EU) 2021/2078. The data is intended to be accessible to the public free of charge under Article 28(3).

When must the UDI database submission be made? Article 29(1) requires the manufacturer to submit the Basic UDI-DI and the Annex VI Part B data elements to the UDI database before placing the device on the market. For devices involving a Notified Body, the Basic UDI-DI must additionally be provided to the Notified Body before applying for conformity assessment under Article 29(2).

Is the UDI-PI submitted to the UDI database? No. The UDI-PI — lot, serial, software version, manufacturing date, or expiry date — lives on the physical unit under Annex VI Part C. Only the Basic UDI-DI and UDI-DI, together with the Annex VI Part B dataset, are submitted to the database.

Can I submit via the EUDAMED user interface, or do I need the machine-to-machine interface? Either is acceptable. Commission Implementing Regulation (EU) 2021/2078 supports both channels. The UI is usually the right choice for small catalogues and first-time submissions. The machine-to-machine interface is the right choice for larger catalogues or where the master data already lives in a structured system. Pick the channel that matches actual scale.

Who owns the UDI database record after submission? The manufacturer, bound by the SRN issued under Article 31. Article 29(3) places the ongoing update obligation on the manufacturer for as long as the device is on the market. No other actor — not the Notified Body, not the importer, not the distributor — owns the device record.

What happens if we submit inconsistent data? The record becomes a public artefact that contradicts the technical file, the label, or the certificate. Competent Authorities and Notified Bodies cross-reference these sources at audit, and any discrepancy produces a finding. Fix inconsistencies at the source before submission, not after.

How often should we review the UDI database record after submission? Continuously through QMS change control, with an additional quarterly reconciliation against the current technical file. Article 29(3) makes the record a living object; the maintenance cadence should match the rate at which the underlying device, its labelling, its IFU, and its certificate change.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 27 (Unique Device Identification system), Article 28 (UDI database), Article 29 (registration of devices), Article 33 (European database on medical devices — Eudamed), Article 34 (functioning of Eudamed), Annex VI Part B (core data elements to be provided to the UDI database together with the Basic UDI-DI) and Annex VI Part C (the UDI system). Official Journal L 117, 5.5.2017.
  2. Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021 laying down rules for the application of Regulation (EU) 2017/745 of the European Parliament and of the Council as regards the European Database on Medical Devices (Eudamed). OJ L 426, 29.11.2021.
  3. European Commission, EUDAMED information page — current module status, user guides, EMDN nomenclature browser, and machine-to-machine interface documentation. Readers should consult this page directly when preparing a submission, because the operational details and the live status of the UDI/device registration module are maintained there.

This post is part of the EUDAMED, UDI and Registration category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The pillar for this cluster is What is EUDAMED?. For the end-to-end device registration sequence that contains the database submission step, read this post alongside Device Registration in EUDAMED: Step-by-Step.