80 Validation Checks, Before EUDAMED Ever Sees Your File
Not a marketing number — pulled directly from our own generator’s source code. Here’s what we actually check, and where each category of rule comes from.
EUDAMED rejects a bulk-upload batch for reasons well beyond "the XML doesn’t match the schema" — required fields, cross-field business rules, and undocumented server-side behavior that only shows up once you’ve actually submitted something. We validate against all three before you ever upload, with plain-language errors tied to the exact row and field.
Where each rule comes from
Schema & format rules
GS1 GMN vs. GTIN format for Basic UDI-DI and Master UDI-DI, check-digit/check-character validation, EUDAMED’s published code lists (storage conditions, warnings, clinical size types/units, countries) — roughly 9 checks.
Confirmed against real rejections
Rules identified from actual production submissions EUDAMED rejected, then verified against live EUDAMED behavior — not just read off documentation. Listed individually below, dated where we have a confirmation date.
Our own pre-upload safety net
Required-field completeness, cross-field logic (e.g. a market status that needs a country, a clinical size that needs exactly one shape), and cross-row consistency (duplicate codes, dangling references, update-ownership checks) — roughly 64 checks across the BasicUDI, UDI-DI, Legacy, and MarketInfo sheets.
Rules confirmed against real EUDAMED rejections
The rules we’re most confident about, because we didn’t just read them off a spec — we saw EUDAMED reject real submissions over them.
Master UDI-DI (contact lenses) needs a different code format, and rejects Direct marking/Unit of use DI
BR-UDID-731 / BR-DTX-UDID-730 — 2026-09
Four special device types (standard and made-to-order soft/RGP contact lenses) make every UDI-DI under that Basic UDI-DI a Master UDI-DI. The two "standard" types need a GS1 GMN-format code, like Basic UDI-DI — not the ordinary GTIN. All four reject a Direct marking DI or Unit of Use DI outright. Caught before upload instead of only by EUDAMED’s own rejection.
Market country changes are rejected inside a normal UDI-DI update
ERR-BR-DTX-UDI-105.01 — confirmed live 2026-08-18
EUDAMED hard-rejects a UDI-DI PATCH that includes market info — it has to go through EUDAMED’s separate Update Market Information service instead. We drop it from a normal update automatically, with a warning, rather than let the whole update fail.
Clinical Sizes cannot be changed by an update
ERR-DTX-UDI-031-033.02 — confirmed live 2026-07-24
EUDAMED locks a UDI-DI’s Clinical Sizes once it’s first created. Any Clinical Size data on an update row is left out of the generated PATCH automatically, with a warning, instead of guaranteeing a rejection.
A type/unit description is only valid on the generic OTHER code
ERR-DTX-UDI-722.05-02 — confirmed against production
Giving a Clinical Size type or unit description next to a named (non-OTHER) type/unit rejects the entire submission, not just that row — real incident: 79 devices in one batch. We block this before generation, not after.
Declaring a medicinal/blood-derived substance without a Substance row
ERR-BR-DTX-UDI-085.03 — confirmed against production
If a Basic UDI-DI declares a medicinal substance or human blood/plasma substance, at least one of its UDI-DIs must fill in a Substance block — EUDAMED rejects the whole BasicUDI otherwise.
EUDAMED rejects an explicit update version of exactly 1
BR-DTX-UDI-036 — —
Version numbers on an update are meant to auto-increment. If you supply one explicitly, EUDAMED refuses the literal value 1 — we validate this before generation.
FAQ
Is this every rule EUDAMED enforces?
No — EUDAMED’s own server-side checks (ownership, uniqueness, certificate validity, and more) are the final word. This page lists what we check before you upload, to catch as much as possible upfront.
Why do some rules list a confirmed date?
Several of the rules above aren’t just read from EUDAMED’s published schema — they were identified from real production rejections and confirmed against live EUDAMED behavior. We date those specifically because they represent verified, not assumed, behavior.
Does this replace reviewing my own generated files?
No. Validation reduces rejected batches; it doesn’t replace your own regulatory judgement or reviewing EUDAMED’s acknowledgement report after upload.