Your device data,EUDAMED-ready.

Upload

Map

Classify

Deliver

The output is validated against the EUDAMED v3.0.30 XSD before export, and against 88 checks across 19 EUDAMED business rules, covering MDR, IVDR and the legacy directives, before delivery. That is what we check and what we stand behind. The upload itself stays with you: EUDAMate prepares the data, it does not submit it.

No. Nothing you upload is used to train any model, and your files are processed in the EU: the spreadsheet itself is deleted once it has been parsed. One thing is kept deliberately. When you approve an EMDN code, we keep that approval, the device name it was made against, and the code, and we use it to improve EMDN recommendations. EMDN is the Commission's public nomenclature rather than anyone's property, and no customer ever sees another customer's device data. It is why your second upload is better than your first. Your prepared device data stays in your account so you can reopen a project, and we delete it on request.

No. EUDAMate is a data preparation tool with no connection to EUDAMED. We map your device data to the EUDAMED field schema, classify EMDN codes, and validate against 88 checks across 19 EUDAMED business rules. The result is a clean CSV you feed into your submission portal or tool. We are the step before submission, not submission itself.

Any tabular format: Excel (.xlsx, .xls), CSV, or TSV, including raw ERP exports. Column names can be in any language: German, French, Turkish, English. The mapping to 67 EUDAMED fields is handled for you.

Enough to start. Most ERPs hold a fraction of what EUDAMED wants, and a part number plus a description is normal. A legacy device needs 23 mandatory fields. We fill 17 of them from what you upload and list the rest field by field. We can't invent data you don't have. What we can do is tell you which fields are missing and where they usually come from, before you start instead of after a rejection.

The RDR is a PDF documenting every AI suggestion, every human override, and the reason for each decision. It's designed for your QMS binder, hash-chained and tamper-evident, aligned with ISO 13485 documentation requirements.

Every AI suggestion comes with a confidence score: Green (high confidence, auto-approvable), Yellow (moderate, review suggested), or Red (low or missing, manual entry required). You see the alternatives, you can override with a logged reason, and you approve every classification. The RDR records who approved what.

Yes. Legacy device support is a core focus. By November 27, 2026 every legacy device you are still placing on the EU market needs a EUDAMED record. Two things are out of scope. First, devices for which you place no further units on the EU market from 28 May 2026, the date the UDI/DEV module became mandatory. Second, legacy devices whose Regulation equivalent, MDR or IVDR, is already registered under the same UDI-DI, reference number or trade name, provided no change was made that assigns that Regulation device a new UDI-DI. The two exemptions come back differently. The first falls away if any post-market or vigilance action occurs. The second is narrower: the legacy device needs registering only where the action concerns the legacy device and not its registered Regulation equivalent (MDCG 2024-11, Q8 and Q14). The pipeline handles MDR, IVDR, MDD, AIMDD and IVDD, including the EUDAMED DI versus Basic UDI-DI distinction that legacy devices need.

Submission portals handle the upload to EUDAMED. They need clean, structured data to work. EUDAMate is the step before: we take your device data as it is and produce the clean CSV those portals expect. Complementary to your existing submission workflow, not a replacement.

If your file is rejected because of a mapping or validation error we produced, you get a full refund and a corrected file. We do not indemnify classification decisions you reviewed and approved. The RDR records who approved what, which is the point of it.