To be fair, August felt scarier on paper — the staggered applicability dates made everyone check their calendars — but now that Article 50 actually applies I’ve stopped worrying about August and started worrying about December.
If your organisation already runs any AI-enabled functionality in a medical device (embedded algorithm, decision support, image enhancement, triage assistant), Article 50’s disclosure requirement isn’t a distant “we’ll do it in Q4” task. Every system we had running before the new rule has until 2 December to present the required disclosure to users. In practice this means the work belongs on your September sprint, not some cosy December scramble.
Why this is more than a label update
At first glance the obligation looks simple: add a line to the UI and the IFU saying “this system uses AI.” I wish it were that tidy.
Real life brings several knock-on items you must evaluate and document:
- Change control: any UI/IFU/software update requires a formal change request. If the change affects the user interface or the software’s intended purpose, you must assess whether it’s a significant change under MDR/IVDR guidance and whether notified-body involvement is necessary.
- Risk and usability: update your risk assessment and usability validation — the wording, placement, and prominence of the disclosure are usability-relevant. If disclosure changes user interaction or decision-making, that belongs in the risk file.
- Technical File / Design Dossier: add traceability showing why the disclosure was added, who approved it, and what evidence (usability tests, translations, legal review) supports it.
- Localisation: every market language needs the correct translation and sign-off. That’s rarely a one-day task.
- Software lifecycle: release planning, regression testing, deployment, and rollback procedures — they all need coordinating with QMS and IT.
- Post-market: update PMS plans and PSUR templates to reflect the disclosure and any user-reported issues stemming from it.
How I schedule it (practical steps)
We treat this like a product change that’s timeboxed and owner-assigned. My checklist looks like this — adapt it to your size:
- Create a change request now (not October). Assign a single owner.
- Do a rapid impact map (Technical File, IFU, UI, training, translations, regulatory submission needs). Use your eQMS connected workflow to link the CR to affected documents and risks.
- Draft disclosure text and several placement mock-ups for the UI and IFU. Keep it factual and non-promotional: who, what, and any relevant limitations.
- Run a short-form usability test (3–5 representative users) focussed on whether the disclosure is noticed and understood.
- Update risk assessment and IFU/label versions; capture approvals.
- Plan the software release: CI/CD slot, validation, release notes, and rollback.
- Prepare translations and legal sign-offs for target markets.
- Update PMS/PSUR templates and training materials.
- Close the change request with traceability showing each step. If you use automated CAPAs or AI-assisted CAPA assistance, ensure any CAPAs opened from user feedback are linked back to the change.
If that list looks long, good — it is. That’s why “we’ll do it in Q4” turns into week-48 panics: translation queues, validation overlaps, and a suddenly full notified-body calendar.
Common traps I’ve seen
- Leaving wording to Product Marketing. Marketing loves to tweak copy; this is a regulatory statement. Legal/regulatory should approve final text.
- Treating the disclosure as a cosmetic label only. Placement and prominence matter for user understanding; ignore usability and you’ll be back with complaints.
- Not involving IT early. Release windows and validation are the usual blockers when teams assume a simple patch.
- Forgetting translations. A single-language push is quick; a dozen markets is not.
- Ignoring traceability. Not enough linked evidence in the Technical File turns a small change into a desktop audit nightmare.
Who signs what (quick roles)
- Product Owner: owner of CR and deployment timing.
- Regulatory/RA: wording, legal risk, notified-body interaction.
- Usability/QE: placement testing, user instructions.
- Software/IT: build, CI/CD, validations, release.
- Localization/vendor management: translations and proofing.
- QMS owner: change control, traceability, update to PMS/PSUR.
Use your tools — but use them correctly
A good eQMS changes this from a Gantt sheet into connected work:
- Link change request to every impacted document (IFU, Technical File, risk assessment) so reviewers see context.
- Use automated CAPAs only when post-release issues appear; the system should create traceable CAPA-driven risk assessment actions, not magic fixes.
- Keep reviewability: all approvals and evidence should be in one trail. Traceability is not a table — it’s the system.
To be clear: none of this is optional if you want a clean audit trail and to avoid last-minute forced releases. Also, remember to evaluate whether your disclosure changes the device’s intended use in a way that might affect conformity — sometimes adding functionality-level statements does.
Final practical timeline (three-month sprint)
- Week 1–2: Create CR, impact map, draft text, assign owners.
- Week 3–4: Usability check on wording and placement; legal/regulatory sign-off.
- Week 5–6: Translation and localization, technical builds scheduled.
- Week 7–8: Validation, regression test, release window reserved.
- Week 9–10: Release and post-market monitoring active.
If you don’t have capacity for that, reprioritise now. In my team we’d rather shift a feature backlog item than risk a scrambled, non-traceable disclosure in late November.
Has anyone actually scheduled this work — who’s the owner in your organisation and what timeline did you commit to?
Top comments (0)