What This Guide Covers
A EUDAMED device registration can be rejected for many reasons across several modules: actor registration, device data, XML bulk upload, and machine-to-machine (M2M) submission. This guide covers one slice of that surface, the one with the clearest, most citable primary source: rejections at the device-data (UDI/Devices) level that trace to a specific, numbered rule in the European Commission's own EUDAMED Business Rules documentation for that module.
The Actor module has its own, separately published business rules document, with its own catalogue of format and mandatory-field rules (Actor ID format, Notified Body number format, mandatory fields for actor-registration assessment, and more) plus a distinct set of rules added for mergers and acquisitions. Reviewing that catalogue rule by rule, to the same standard as the device-data rules below, is more than this installment can verify carefully. Rather than pad this guide with a rushed pass over unverified rules, we are publishing the device-data half now and treating actor-registration rejections as separate, future material.
How Device Validation Works
EUDAMED's device registration validates submitted data against a published set of business rules maintained by the Commission alongside the DTX schema. Two categories of rule cause the rejections covered here. The first concerns the EMDN code assigned to a device: EMDN is MDR Article 26's nomenclature requirement, revised annually, and a code that was valid when a device was first registered can change status later. The second concerns conditional relationships between device-data fields, where one answer makes another field mandatory, forbidden, or constrained to a specific value.
Both categories share a common trap: the data was correct when it was submitted, and the rejection appears only later, either because the underlying nomenclature moved or because a second field was added or changed without checking it against the first.
EMDN Code Lifecycle Rejections
EMDN codes are not static. The Commission's annual revision process can change an existing code's status in ways that affect every device already registered with it. The EUDAMED UDI/Devices Business Rules document defines four outcomes for a code revision: Corrected, Scope extended, Discarded, and Split (a fifth, Scope reduced, is referenced alongside Discarded and Split in the rules governing device-record messaging).
- Discarded (Rule ID RULE-00026 / RULE-00027): the code's status changes from Active to Inactive. It can no longer be chosen in the EMDN hierarchy tree, and the interface displays it in grey to distinguish it visually from active codes.
- Split (Rule ID RULE-00028 / RULE-00029): the code is no longer a leaf in the hierarchy, so it can no longer be selected for a device; it must have at least two child codes beneath it once split.
- Automatic vs. manual update (Rule ID RULE-00052): when a new EMDN batch is loaded, devices carrying a code marked Corrected or Scope extended are updated automatically, with no new device version required. Devices carrying a code marked Discarded, Split, or Scope reduced are not updated automatically.
- Manufacturer action required (Rule ID RULE-00032): if a device's current EMDN code has been Discarded or Split, the manufacturer or producer must remove that code and select a replacement the next time they create a new version of that device. A code marked Scope reduced is exempt from this requirement.
- Warning messaging (Rule ID RULE-00030): a device record carrying a code with a Discarded, Split, or Scope reduced history displays a warning with the date the change took effect, so the status is visible before it blocks a resubmission.
The practical effect: a device can sit untouched in EUDAMED for a year, valid when registered, and become blocked on its next version update purely because the EMDN nomenclature moved underneath it. This is why an EMDN classification step that only runs once, at initial registration, is not enough for a portfolio that will be resubmitted or updated after each annual EMDN revision.
Field-Level Conflicts That Block Registration
The second category is internal to the device record itself: one field's value makes another field mandatory, forbidden, or fixed to a specific value. These are documented as individual numbered rules in the same Business Rules document.
| Rule | Condition | What Happens |
|---|---|---|
| RULE-00183 | Risk Class = Class I | Implantable must be False. A device submitted with Risk Class I and Implantable = True fails validation. |
| RULE-00184 | Implantable = True | Reusable surgical instrument must be False. The two properties cannot both be True on the same device. |
| RULE-00182 | Applicable regulation = MDR, Risk Class = IIb, Implantable = Yes | The "Is it a suture, staple, dental filling, dental brace (…)?" property becomes mandatory. Outside that exact combination it is not required. |
| RULE-00185 | Device is a System, Procedure Pack, or marked as a Kit | "Additional product description" becomes mandatory (and must be provided in a language from the approved list). For other Regulation or Legacy devices it stays optional. |
| RULE-00186 | "Is it a Kit" = Yes, or device is a System / Procedure Pack | The device cannot also carry a Special Device Type marking. The two classifications are mutually exclusive. |
| RULE-00160 | Single Use Device = Yes | Maximum number of reuses cannot be provided. The field only applies to devices not flagged as single-use. |
| RULE-00168 | Direct marking = Yes, or Quantity of Device = 1, or the DI is a Master UDI-DI | Unit of Use DI cannot be provided (errors ERROR-00153 / ERROR-00154). It is only valid when Direct marking = No and Quantity of Device > 1, and never applies to a Master UDI-DI. |
Primary Sources
Both documents below are published by the European Commission and updated with each EUDAMED production release. Rule IDs are stable across releases (the "OLD BR ref" annotations in the source documents map older internal references to the current RULE-##### numbering); the version numbers below reflect the release current at the time this guide was verified.
| Document | Covers | Version Referenced |
|---|---|---|
| EUDAMED Business Rules, UDI/Devices | EMDN code lifecycle rules, device-data field constraints, Basic UDI-DI and SS(C)P linkage rules | Production v2.25.2, 2026 |
| EUDAMED Business Rules, Actor Registration | Its own field-format and mandatory-field rule catalogue, plus a separate mergers-and-acquisitions ruleset; not reviewed rule by rule for this guide (planned for a follow-up) | Production v2.27.0, 2026 |
The pattern across both categories is the same: EUDAMED is checking a device record against a set of published, numbered rules, not applying hidden judgment. A rejection traces to a specific rule every time. Reading the record against that rule, rather than guessing, is the fastest way to fix it and the only way to fix it correctly the first time.
Frequently Asked Questions
Why does EUDAMED reject a device that used to have a valid EMDN code?
Because the EMDN code itself changed status, not the device data. EMDN codes get revised every year, and a code your device previously used can become Discarded, Split into more specific children, or have its Scope reduced. When that happens the code's status changes to Inactive and it can no longer be selected in the EMDN hierarchy tree, even though it was valid when you first registered the device.
Does EUDAMED automatically update my device's EMDN code when the nomenclature changes?
Only for two change types: Corrected and Scope extended. For those, EUDAMED updates the device's code automatically and no new device version is needed. For Discarded, Split, or Scope reduced changes, EUDAMED does not update the code automatically. The manufacturer or producer has to select a replacement code and submit a new device version.
What is the Unit of Use DI and when does providing it cause a rejection?
The Unit of Use DI is an identifier for an individual item within a device that ships as a multi-unit package, such as one instrument inside a kit. Under the official business rules, it can only be provided when the UDI-DI is not directly marked and the base Quantity of Device is greater than one; it does not apply to a Master UDI-DI at all. Providing it outside those conditions is what triggers the validation error.
Why would a device with Implantable set to true get rejected on Risk Class I?
The business rules encode a direct conflict between those two fields: a device with Risk Class I must have Implantable set to false. Class I devices are, by definition in this ruleset, non-implantable, so submitting Implantable = true alongside Risk Class I fails validation regardless of what the physical device actually is. The risk class has to be corrected, or the implantable flag does, before the record will pass.
Is this every reason a EUDAMED submission can be rejected?
No. This guide covers device-data and EMDN-code rules published in the EUDAMED UDI/Devices Business Rules document. Actor registration rejections and XML bulk-upload or M2M-specific errors are not covered here and are sourced from different official documents; treat this as a first, verified installment rather than a complete error reference.