EUDAMED Playground test report: 29 bulk upload scenarios and every error message we got
What EUDAMED accepted and rejected when we uploaded XML for every device service in its Playground in September 2026, with the exact error messages and what caused them.
Between 14 and 20 September 2026 we uploaded XML files for every device service eudaflow supports to the EUDAMED Playground, the Commission's test environment. Each of the 29 service and legislation combinations was accepted at least once. Five update files were rejected first and accepted after a fix. We then downloaded what EUDAMED had stored for 347 devices and compared it field by field with what we had sent: nothing was missing and nothing was stored wrongly.
This page lists what we tested, the places where EUDAMED behaves differently from what its own documents suggest, and every error message EUDAMED sent back, with the cause. Nothing here comes from a production upload: that one has not been made yet.
What we tested
| Test | What was uploaded | Result |
|---|---|---|
| Services × legislations | New device, add UDI-DI, and each update service, under MDR, IVDR and the legacy directives (MDD, AIMDD, IVDD): 29 scenarios | Every scenario accepted at least once |
| Rich content | Certificates, two-level packaging, substances, product designer, clinical investigations, Annex XVI products, software devices | Accepted |
| Bulk registration | One file with 300 devices, then the 301st in a second file; one Basic UDI-DI with 12 UDI-DIs (1 with the device, 11 added afterwards) | All 301 devices registered; 11 of 11 UDI-DIs added |
| Read-back | EUDAMED's download service for 347 devices, compared field by field with the files sent and the 43 updates applied | No data missing, no value stored wrongly |
EUDAMED takes at most 300 devices per bulk file. eudaflow split the 301 devices into two files in upload order; validation plus XML for all 301 took 3.5 seconds on the test machine.
Where EUDAMED and its documents disagree
For ten cases the XSD schema, the data dictionary and the EUDAMED user interface disagreed or said nothing, so we sent one file each on purpose and recorded what EUDAMED did.
| What we sent | What the documents say | What EUDAMED did |
|---|---|---|
| Reference / catalogue number of 121 characters | XSD allows 255; data dictionary and user interface 120 | Rejected: Size |
| Trade name of 256 characters | XSD allows 2000; data dictionary 255 | Rejected: The maximum length is 255. |
| Maximum number of reuses = 1 | Data dictionary says "more than 1" | Accepted |
| An end date for the market in a second country | Optional; the user interface does not check it | Accepted |
| A secondary UDI-DI from HIBCC with a valid check character but a labeler code (LIC) that belongs to nobody | Unknown | Accepted: EUDAMED does not check the LIC |
| Clinical investigation links, one EU and one non-EU country | Unknown | Accepted |
| A Class I device with a clinical investigation link | Unknown | Accepted |
| An EMDN code that is not the lowest level (A0101) | Must be a leaf | Rejected: Nomenclature with CND code A0101 is not a leaf. |
| An EMDN code that does not exist (12345) | Must exist | A server error (M-50000) instead of a normal rejection, with ERR-BR-UDID-636.05-01 in the text |
| An Annex XVI product, Class I, without certificate | Rules not tried in the Playground before | Accepted |
The lesson for anyone preparing files by hand: the schema is the loosest of the three. A file that passes the XSD can still be refused for length, and the stricter limit in the data dictionary is the one EUDAMED applies.
Every error message we received
These are EUDAMED's own words, from its acknowledgements. Device codes are left out.
| EUDAMED's message | What caused it | What eudaflow does now |
|---|---|---|
ERR-BR-DTX-UDID-093.05-01: Please utilise Update of product designer information service to update the information about the product designer (5 times) | A UDI-DI update carried the product designer. EUDAMED updates the designer only through its own service. | UDI-DI updates no longer send the designer; the five files were accepted after the fix. |
Please utilise Update of Market Information service to update Market Information, ERR-BR-DTX-UDID-096.01-02: Market information is required for a device in status "On the EU market" and ERR-BR-DTX-UDID-103.1: Provided country is not in the list of countries in the last Market Information version, all three in one answer | A UDI-DI update that did not carry the device's registered market information. The update may not change the market information (that has its own service), but it may not leave it out either. | The registered market information is sent unchanged with every UDI-DI update; the update was accepted. |
ERR-BR-DTX-UDID-629.05-01: No Product Designer entity found linked to this device. (4 times) | A designer update for a device that had no designer registered as an organisation. | Only a designer registered with the device is updated. |
No device found | A designer update for a certified device. A device registered with certificate information stays "Submitted" until the notified body confirms it, and the designer can be updated only on a "Registered" device. | The template says so next to the field: the designer can be updated only once the device is Registered. |
ERR-BR-UDID-109.05-02: Device Certificate Information cannot be provided for the current Device | A certificate on a device whose class does not need one. | The class and certificate rule was rewritten. |
Certificate should be of type 'Type examination' | An IVDR certificate of the wrong type for that device. | The certificate type is checked against the device class. |
Placed on the market is mandatory. | A device "On the EU market" without the country where it was first placed. | Now an error in the report. |
ERR-BR-UDID-046.05-01: Market information is not applicable when device's status is: "Not intended for the EU market" or "No longer placed on the EU market" | Market rows on a device that is not on the market. | Now an error in the report. |
ERR-BR-DTX-UDI-073.01-01: When the status of the device/system or procedure pack is other than 'On the EU market' then the status of the container package(s) must be the same as the status of the device | Packages with a different status from their device. | Now an error in the report. |
The device identifier code … already exists for the selected issuing agency GS1 | The same device sent a second time, on purpose. | Expected. EUDAMED checks the Basic UDI-DI, the UDI-DI and each package code separately. |
Size, The maximum length is 255., the two EMDN messages | The deliberate cases in the table above. | Both lengths are checked before the XML is written. EMDN codes are not yet checked against the nomenclature; EUDAMED is the check there. |
Three things we did not expect
- EUDAMED can answer SUCCESS before its download shows the change. After an update was accepted, the bulk download kept showing the previous version for a while. Before the next update, check which version EUDAMED shows for the device; an older download leads to a version clash.
- Downloads look different from what you sent without being different.
100comes back as100.0, lists come back in another order, and an organisation's name can come back in another language. The only thing EUDAMED did not keep is the language codeANYon a storage description; the text itself was stored. None of this was lost data. - The portal does not tell you which service a file is for. Twice a file was uploaded under the wrong service in the portal. eudaflow now puts the portal's service name in every file name.
What this does not prove
- All of this is from the Playground. The production environment runs an older schema (XSD 3.0.30, the Playground 3.0.32), and its business rules may differ; we have not uploaded to production yet.
- EUDAMED's rules change with its releases. When a new message appears, we add it to our checks and to this page.
- Our validation documents are written but not yet signed, so we do not call the software "validated".
The acknowledgements behind every line on this page are kept in our validation records; customers can see them on request. The official rules are in the EUDAMED Information Centre: bulk upload and technical documentation.