I told a room of very anxious engineers last week: calm down, the world didn’t end on 2 August. It’s in force, nothing exploded, and the real paperwork that matters for systems already deployed is due 2 December. To be fair, the fireworks around 2 August were understandable — new module live, headlines, panic — but the people who rushed to reprint labels then are the same ones who’ll be surprised in November when the disclosure work finally lands.
I’ve been through enough EUDAMED rollouts, UDI back-and-forths, and notified-body audits to know the pattern: a visible milestone creates loud, immediate action. The invisible milestone — the date when disclosure, public registration, and mandatory submissions are actually due — lands later and heavier. Treat 2 August as the bell, not the summit.
What actually changed on 2 August (and what didn’t)
- What changed: a component of the database went live and authorities confirmed the module was "in force". That’s useful — it’s where we’ll be submitting data.
- What didn’t change: the compliance obligations for devices already on market didn’t magically transfer overnight. Many manufacturers have a later deadline for disclosure and public registration of systems already running. That deadline is 2 December.
In practice this means the technical work — collating device-level data, reconciling UDI assignments with labels and IFUs, redacting proprietary information, and preparing the public-facing entries — will still be needed. The window between 2 August and 2 December is the grace period, not the finish line.
Where teams misallocate effort
I saw three common mistakes in the past week:
- Reprinting labels and rushing logistics before confirming whether a label change is required. A label change can itself be a change requiring change-control, risk review, and possibly a notified-body notification.
- Treating the new module like a “submit once and forget” task. Data cleanliness, traceability and re-submission workflows matter.
- Assuming notified bodies will guide every disclosure detail. Notified bodies check the technical files and evidence; they won’t upload your marketing text or redact your confidential business information for you.
Those are QMS problems as much as regulatory ones. If your change-control board is overloaded, this is when automated CAPAs and connected workflow become defensible investments — not marketing fluff.
Practical checklist for the 2 December disclosure
Start now. The tasks below are the ones that bite late and are often under-estimated.
-
Inventory and mapping
- List all systems and devices "already running" that will require a public entry.
- Map each item to its current Technical File, UDI (if already assigned), labelling status, and market status (CE-marked, under transition, withdrawn).
-
Documentation and redaction plan
- Identify what in your Technical File and device description is public vs confidential.
- Draft redaction rules ahead of time; applying ad-hoc redaction across many files is slow and audit-unfriendly.
-
Data reconciliation
- Reconcile internal UDI master with what’s printed on labels and what’s in your eQMS.
- Prepare a reconciliation log — notified bodies will expect traceability.
-
Change control and risk
- Run a focused change-impact analysis for any updates required to meet the disclosure format.
- Open CAPAs for any gaps found in labeling, software build, or clinical evidence. Use CAPA-driven risk assessment to prioritise work.
-
Technical file readiness
- Ensure the Summary of Safety and Clinical Performance (SSCP) or equivalent public summaries are in a publishable state if required.
- Confirm PMCF/PMS data you plan to reference is current and defensible.
-
Submission rehearsals
- Run a dry-run in a staging instance (or with a spreadsheet that mirrors the submission fields).
- Capture screenshots and a stepwise procedure to avoid last-minute login and role issues.
How I’ve handled this as an RA lead
I stopped treating EUDAMED submissions as a single-operator task years ago. My practical steps:
- Centralised the device inventory in the eQMS so the same source-of-truth feeds labels, UDI tables, and submission exports. This avoided the classic “label says A, database says B” problem.
- Set up a small "disclosure sprint" team: RA, regulatory affairs, one systems engineer, and the QA owner for change control. Two-week sprints focused on batches of devices.
- Used a pre-approved redaction template for Technical Files. Not perfect, but consistent and reviewable.
- Mapped each disclosure item back to a traceability entry in the QMS. If a notified body asked for provenance, I could point to the CAPA, change order, and risk assessment.
Yes, it’s a bit like hiking — you can sprint down the slope to get to a milestone, but you still have the ridge to cross. The eQMS is your rope and map; use it for connected workflow, not just document storage.
What auditors will look for
Notified bodies aren’t looking to catch you out. They want evidence that:
- The device in the public register matches your Technical File and UDI records.
- You have traceability from label to UDI to submission.
- Confidential information was considered and handled according to documented policy.
- Risks arising from any disclosure-driven changes were assessed and mitigated.
Automated CAPAs and AI-assisted drafting tools can speed up authoring, but ensure everything remains reviewable and traceable. “Safe assistance” is the phrase I use internally: tools can help, but the review trail must be human-led.
Final practical tip
Divide the work into three buckets and assign owners now:
- Data owners (device inventories, UDIs)
- Documentation owners (redaction, SSCP/public summaries)
- Process owners (change control, CAPA, submission rehearsals)
When the noise returns in November — and it will — you want people executing a plan, not discovering roles.
What’s your team doing this month to avoid a November scramble for the 2 December disclosures?
Top comments (0)