I spent last week reconciling our internal part numbers with GTINs and wrestling with the EUDAMED UDI uploader again. If your calendar still treats 26 May 2026 as “someone else’s problem”, it isn’t. EUDAMED mandatory means predictable: more public-facing obligations, more data to maintain, and more threads for your QMS to manage. To be fair, the database does the right things in principle. In practice this means planning, clean data, and demonstrable processes.
What’s actually becoming mandatory in May 2026
A few high-level implications every manufacturer should treat as firm:
- Actor registration (you’ll need a Single Registration Number from your competent authority before you can act in EUDAMED).
- Device registration (Basic UDI-DI, UDI-DI linkage, device records that match your Technical File).
- Public summaries where applicable (implantable/Class III devices — these summaries must be uploaded and maintained).
- Vigilance and market surveillance modules will be the single point of record for some activities.
- UDI submissions will need to be correct and auditable in EUDAMED — yes, that UDI module you’ve cursed before.
None of this is new in concept, but the deadline makes it non-negotiable. You will be judged on whether the data and processes are audit-ready, not on good intentions.
Immediate operational actions I run through with teams
When I brief colleagues, I give them a simple, prioritized list:
- Obtain your SRN (Single Registration Number). No SRN, no actor actions in EUDAMED.
- Cleanse UDI/GTIN mappings. Wrong Basic UDI-DI in EUDAMED creates audit friction and downstream vigilance headaches.
- Map device families to Basic UDI-DI and ensure your internal BOM/versioning ties to the EUDAMED record.
- Identify which devices require SSCP/public summaries and draft them now — reviewers will quibble about wording and claims.
- Test the EUDAMED test environment where possible; don’t wait for the live portal.
These are deliberately practical steps. For a small medtech SME, they are the difference between a calm submission and a week of late-night firefighting.
QMS/process implications — what actually changes for you
EUDAMED isn’t a separate admin task; it intersects with your QMS at multiple points. Expect to update SOPs and workflows for:
- Device registration and changes (tie device record updates to design change control).
- UDI assignment and verification (add checks in incoming inspection and supplier control workflows).
- Post-market surveillance and vigilance workflows (link EUDAMED reporting to CAPA initiation).
- PRRC responsibilities (who in your organisation is accountable for the data and submissions).
Practical detail: link your device records to change-control entries so a Basic UDI-DI change automatically surfaces in your impact analysis. A connected workflow reduces manual reconciliation — and creates audit evidence without heroic spreadsheet surgery. Automated CAPAs and CAPA-driven risk assessment features in your eQMS become very useful here: when a field issue maps to a device record, an automated CAPA can be raised and traced to the device’s EUDAMED entry.
IT and data hygiene — don’t underestimate this
EUDAMED will be unforgiving of inconsistent data. My standard checklist for IT/data people looks like:
- Master data audit: harmonise part numbers, nomenclature, and GTINs.
- Export a CSV/flat-file of current device records — compare to the EUDAMED schema early.
- Verify your UDI generation process and who signs off on Basic UDI-DI assignment.
- Ensure audit trails exist for any person who edits EUDAMED-relevant records.
If you use an eQMS, make sure it can export the fields EUDAMED asks for. If not, plan a controlled manual process and document it. Validation of your data-export process saves time; smooth validation also saves nerves and resources during an audit.
Notified bodies and audits — what I’ve learned in practice
Notified bodies are already asking to see evidence that device records match what will go into EUDAMED. Two practical lessons from recent interactions:
- Expect questions about traceability between your Technical File and your EUDAMED entries. That means documentable links (trace matrices or native eQMS traceability).
- If processes cannot be verified remotely, a partial on-site audit may be required later — update your annual audit plan accordingly.
To be fair, notified bodies are trying to avoid inconsistent public records. In practice this means they’ll push for demonstrable, repeatable processes rather than one-off fixes.
A short timeline to run now (my go-to for teams with a quarter to spare)
- Now (0–3 months): SRN application, UDI/GTIN cleanup, identify SSCP candidates, test EUDAMED submissions in the sandbox.
- Next (3–6 months): SOP updates, link device records to change control, run mock submissions and internal audits.
- Last lap (6–12 months): Final uploads, reconcile with Technical Files, evidence pack for notified body.
If you use an eQMS that supports connected workflow and traceability, use it. If you’re still on spreadsheets, make the manual controls auditable and reviewable.
Final notes — what I would do differently next time
I’d start earlier on the Master Data cleanup and insist on end-to-end testing between the QMS and the EUDAMED submission process. Also, don’t treat EUDAMED as a one-off project; it’s an ongoing operating requirement. Keep a living checklist, and make sure PRRC (or the person responsible for regulatory compliance) signs off on every public summary and UDI assignment.
What single internal process are you planning to change before May 2026 to make your EUDAMED submissions audit-ready?
Top comments (0)