DEV Community: Priya Nair

Why small medtechs are quietly exiting the EU — and what I do differently when budgets tighten

Priya Nair — Wed, 01 Jul 2026 15:30:46 +0000

I manage CE‑marking and post‑market surveillance for Class IIa/IIb devices. Over the last five years I’ve watched more than one promising SME start a Technical File only to stop when the cost and complexity rose past their runway. This isn’t a single cause — it’s a compound of MDR requirements, notified‑body availability, and realistic evidence expectations. I’ll be blunt: MDR was supposed to protect patients and harmonise the market. To be fair, it does that in principle. In practice this means rising fixed costs that disproportionately hit small teams.

Where the budget pressure comes from

Several MDR elements repeatedly create hard, early cost inflection points for SMEs:

Annex II (Technical Documentation): the detail expected in device description, design and manufacturing information, and risk management is deeper and more granular than before. Drafting a defendable Technical File is staff‑intensive or expensive to outsource.
Annex IX / conformity assessment: fewer notified bodies, longer timelines, and more extensive audit scope. Longer time to certificate equals longer time to revenue.
Clinical evidence expectations (Article 61 and MDCG guidance): equivalence claims are scrutinised and PMCF requirements in Annex XIV are real workstreams, not checkboxes.
Post‑market requirements (PSURs, vigilance, periodic safety reporting): ongoing resource needs rather than one‑off costs.
Notified‑body unpredictability: differing interpretations of the same clause force repeat work and extra studies.

None of the above is novel reading, but the cumulative effect is what matters. A small team faces simultaneous needs for technical documentation, a robust QMS (ISO 13485 aligned), clinical follow‑up, and an audit‑ready system. The cheapest path — cut corners — is also the quickest route to a nonconformity during NB audit.

Real trade‑offs I’ve seen SMEs make (and why they often fail)

Delay market entry to raise funds. That buys time but not certainty: the regulatory bar moves and costs rise while you wait.
Narrow the intended use to avoid higher classifications. This helps, granted, but classification pitfalls and borderline features can undo the plan at audit.
Hire consultants to "get it over the line." Consultants help, but they add cost and hand‑offs create traceability gaps unless you rigorously manage the interface.

A particularly common failure mode: an SME pays for a clinical equivalence justification, the NB requests an additional PMCF study design, and now the budget must stretch to a small observational study plus CRF management, CRO oversight, and data cleaning. Those costs are not trivial and they compound with the direct NB fees.

What I do differently when budgets are small

When I work with constrained teams I push for surgical prioritisation and pragmatic evidence planning — not minimalism, but realism:

Prioritise the markets and SKUs that matter. EU-wide coverage is attractive, but start where you can realistically get notified‑body time and early reimbursement.
Focus Technical Files on traceable substantiation. Annex II requires evidence; a traceable matrix that links claims to design outputs, risk controls, and clinical data saves hours during audits.
Reuse valid data, but satisfy MDCG: equivalence can work if the justification is airtight. In practice this means thorough device/component comparison tables and access to unredacted data where needed.
Design PMCF that answers specific residual risks, per Annex XIV. Broad, expensive studies that attempt to prove everything rarely fit early budgets. A targeted registry or pragmatic cohort can often be defensible.
Make the QMS work for you: invest in tools that provide change impact analysis, connected workflows for CAPA and risk, and reviewability for audit trails. The tool should reduce administrative friction, not add it.

Software and process choices that actually reduce cost

I am pragmatic about eQMS. Features that matter for an SME under MDR:

Document traceability that links requirements (MDR/Annex sections), risk controls, and clinical evidence.
Change impact mapping so a design change shows all affected procedures, files, and pending CAPAs.
PMCF and PSUR workflows that create structured artefacts rather than free‑text notes — this saves outsourced study time.
CAPA workflows that enable automated CAPAs with reviewability and clear assignment, so issues don’t pile up.

To be clear: software isn’t a silver bullet. It reduces repetitive labour and improves audit readiness, which translates to lower external costs, but it requires discipline and the right configuration.

Where regulators and notified bodies could help (my wish list)

More consistent guidance on equivalence and PMCF expectations across notified bodies.
Faster, clearer decisions on borderline classification to avoid late surprises.
Templates or harmonised matrices for demonstrating traceability from claim to evidence under Annex II.

To be fair, there are pockets of good practice. Some notified bodies publish detailed questions and checklists that help SMEs prepare. But not every NB does this, and the inconsistency is a real burden.

Final thought

The result is a market where capital‑rich firms can absorb the rising baseline costs and smaller innovators are forced to choose between a costly pivot or leaving the EU. That outcome worries me because it reduces competition and limits patient access to novel devices.

What pragmatic changes have you made to keep a small device programme financially and regulatorily viable under MDR?

AI can tell you "what is a CAPA" — but it can't say a CAPA is adequate

Priya Nair — Wed, 01 Jul 2026 08:08:49 +0000

I use generative AI every week to speed up routine quality work. It writes the first draft of a supplier non‑conformance report, it summarises a lengthy audit finding into a one‑page CAPA brief, and it normalises language across our change requests. Those uses are helpful, repeatable, and — crucially — reviewable.

Where organisations get into trouble is when they let the same models answer the fundamentally judgmental question: "Is this CAPA adequate?" That question is not a definitional lookup. Adequacy requires demonstrable evidence, contextual risk judgement, and traceable decisions — exactly the things regulators ask for.

What AI is good at: clear, repeatable, low‑judgement tasks

In practice, I rely on AI for explicit, constrained tasks. Examples that work:

Drafting a plain‑English definition: "What is a CAPA", differences between containment and corrective action, or regulatory expectations under MDR/ISO standards.
Formatting: turning free‑text incident notes into a standard CAPA template (owner, target date, proposed containment, proposed corrective action).
Literature searches and summarisation: pulling together relevant standards language (ISO 13485, ISO 14971), notified‑body guidance, or recent MDCG documents into a digestible paragraph.
Creating checklists: containment verification steps, test matrix suggestions, or documenting what evidence you should collect.
Translating regulatory wording for engineers: "per MDR XXX, you need to demonstrate..." (I use it to draft emails that won’t lose the reviewers).

These tasks are high‑throughput and benefit from connected workflow: the draft goes into the eQMS, the CAPA owner reviews, and a training is triggered if procedures changed. Automated CAPAs and AI‑driven CAPA assistance are valuable here — as long as the human remains the accountable reviewer.

Where AI is dangerous: adequacy, root cause, and risk judgement

Judgemental work is where AI frequently misleads. Problems I’ve seen in audits or notified‑body interactions:

Overconfident assertions. The model can state that the root cause is "supplier process drift" without the traceable investigation that supports it.
Missing context. A CAPA for an implantable device requires a different risk appetite and verification plan than one for a packaging defect. AI often ignores those differences unless explicitly primed.
False completeness. A CAPA plan generated by AI might list "retrain staff" and "update procedure", but omit verification metrics, acceptance criteria, or post‑implementation monitoring.
Audit trail gaps. If AI drafts the CAPA and edits are not documented in the QMS, you lose reviewability and traceability — both red flags for auditors.

A notified body cares about demonstrable verification: evidence that the corrective action addressed the root cause and that effectiveness checks were performed. They will not accept a persuasive narrative alone.

Practical rules I follow (and require from my teams)

I built a short governance checklist that I now apply whenever AI touches a CAPA. It’s lean but effective:

Purpose‑scope: AI may draft the initial CAPA text, but the designated CAPA owner remains accountable. The owner must sign off in the eQMS.
Evidence first: Require the investigation evidence (test results, supplier corrective action, process data) to be uploaded before closing the CAPA.
Acceptance criteria: Every corrective action must define objective acceptance criteria and a verification plan (who, what, when, how measured).
Traceability: Link CAPA to associated change controls, risk assessments (ISO 14971), and affected Technical File/IFU sections in the QMS.
Review logs: Record that AI was used, what prompts were given, and the human edits — preserve the chain of decisions for auditors.
Escalation: If the CAPA impacts clinical claims, sterilisation, biocompatibility, or essential requirements under MDR, escalate to regulatory/clinical lead for review.

Those rules map neatly to ISO 13485 expectations for corrective action and the MDR requirement to maintain a robust quality management system. In practice this means the CAPA record shows the thought process, the evidence, and the verification results — not just a polished narrative.

How to integrate AI safely into your QMS workflows

A few tactical steps that helped our small medtech stay audit‑ready:

Treat AI as a drafting tool not an approver. The CAPA owner must add the rationale and evidence in the record.
Configure your eQMS so AI‑generated drafts are flagged and versioned. Reviewability matters; auditors will ask for the history.
Use AI to generate a "risk impact checklist" that the CAPA owner completes. This forces consideration of clinical impact, patient safety, and regulatory obligations.
Automate follow‑ups: training, supplier audits, or design changes that flow from a CAPA should trigger tasks and link back to the original CAPA (connected workflow).
Validate where necessary: if AI‑generated tests or acceptance criteria are used to close a CAPA, ensure the test method is validated and recorded.

I've seen the time savings. I've also seen a CAPA closed too quickly because the narrative looked thorough. The time saved drafting must not create risk later when the evidence is thin.

Final thought

AI is an excellent assistant for definitions, drafting, and checklists. It’s not an assessor of adequacy. To be compliant and defensible you need documented evidence, clear acceptance criteria, and human accountability built into the workflow — the things auditors actually check.

How have you balanced speed gains from AI with the need for rigorous CAPA evidence in your QMS?

Management review that isn't a slide show — genuine quality signals

Priya Nair — Thu, 25 Jun 2026 11:25:37 +0000

I used to dread management-review season. The folder would arrive with ten slide decks, two long PDFs, and a hopeful calendar invite. Management would attend for 20 minutes, nod politely, and we'd file the slides. Then a notified-body auditor would ask for the "evidence of management decisions being implemented" and the room would go quiet.

Management review is a regulatory requirement (see ISO 13485:2016 clause 5.6 and, for MDR manufacturers, your QMS obligations under Article 10(9)). To be fair, the requirement is short on prescriptive detail — it tells you what to review, not how to show you actually acted. In practice this means the difference between a theatre piece and a living management system. Here is what I use to keep ours in the latter category.

What management review should signal (not merely state)

Think of the review as a control point, not a presentation. A genuine management review gives you these signals:

Traceable decisions. Every decision links to an action, an owner, and an expected completion date — and you can trace progress in the QMS.
Evidence of closure. When the review notes a CAPA or change, there is evidence the activity completed and was verified (not "we closed it" on a slide).
Risk posture updated. Risk files reflect any decisions — e.g. risk control implementation, benefit-risk re-evaluation, or new hazards identified through complaints/field data.
Resource alignment. If management approved more people or budget, that uplifts the capability and is visible in hiring or supplier contracts.
Measurable trends. You see controlled KPIs with acceptance thresholds and actions when thresholds are breached.

If you don't have those, it's a slide show.

Practical inputs I demand before the meeting

Auditors and regulators look for documented inputs. My checklist for the pre-read package is deliberately short and standardised:

Open CAPAs / top 10 CAPA status with root-cause and verification evidence.
Audit results (internal, supplier, and external) with corrective actions and trend commentary.
Product performance signals: complaints, vigilance reports, field corrective actions, and high-level trending.
Post-market activities: PMCF progress, and PSUR/periodic reporting summaries where applicable.
Supplier performance and critical supplier risks.
Changes under review: change-control summary with impact assessment.
Regulatory landscape: new guidance, notified-body findings, or market constraints.
Resource & training needs, and any unresolved financial constraints.

Package these as data tables, not slides. I want direct links to the records — minutes should point to the CAPA IDs, audit report IDs, and change-control numbers. Connected workflow matters; when CAPA #1234 is discussed, I should be able to open it from the meeting note.

Structure that forces action (what we actually do)

We run a two-part review:

Tactical session (monthly, 45–60 minutes)
- Short, evidence-based: top three risks, top three open CAPAs, supplier hot-spots.
- Decisions are tactical: reallocate resources, escalate to strategic, approve urgent changes.
Strategic management review (quarterly/annual as required)
- Review trends, product portfolio risk posture, regulatory changes, and the QMS effectiveness measures.
- Make strategic decisions and approve resource plans.

Both use the same minute template so audit trails are uniform.

Minute template — the non-negotiable fields

A good minute looks like a transaction record:

Unique meeting ID and date.
Attendees and their roles (attendance is an auditable control).
Inputs reviewed (list with links/IDs).
Decisions made (short sentence).
Action items: owner, due date, priority, link to CAPA/change ticket if applicable.
Follow-up verification: who will confirm completion and by when.
Sign-off by top management.

This gives you automated CAPAs and a controlled assistance feel: decisions turn into assignable, traceable tasks.

Red flags auditors ask for (and what fixes them)

Notified bodies repeatedly ask for three things:

Where did this decision come from? Fix: link minutes to the input record.
How do you know it worked? Fix: show verification records and risk-file updates.
Who is accountable? Fix: assign owners with due dates and follow-up evidence.

If you cannot show traceable links, you will get a finding.

Tech that helps — but don’t outsource judgement

An eQMS with connected workflow lets you mirror actions across modules: link a management-review decision to a Change Control, CAPA, and the affected Technical File document. This reduces transcription errors and improves reviewability.

That said, tools don’t replace judgement. Automated CAPAs or AI-assisted summarisation can help with the pre-read (pulling trends, flagging anomalies), but the human decision about residual risk, business impact, and resource trade-offs stays with management. Use technology for process automation and traceability — don’t let it perform the decision.

Quick list: tangible quality signals to show an auditor

Signed minutes with links to records and CAPA IDs.
A closed-loop example: decision → CAPA → verification → change logged in the Technical File and risk file updated.
Trend charts where thresholds trigger a management action, and evidence the action occurred.
Resource approvals followed by recruitment/hiring or supplier-contract changes tied to the decision.
Evidence that PMCF/PSUR outputs influenced decisions.

Final note

If your management reviews feel like theatre, start small: require the pre-read data pack, standardise your minute template, and force one decision into the QMS workflow every meeting. You’ll trade theatrical slides for auditable transactions — and that is exactly what regulators want to see.

How have you turned one management-review finding from a notified body into a permanent process change in your organisation?

AI for CAPA: fine for "what is it", risky for "is it adequate

Priya Nair — Thu, 25 Jun 2026 11:25:34 +0000

I started experimenting with AI in our eQMS triage last year because the CAPA backlog was simply not sustainable. The model could classify deviations, draft a root-cause template and even suggest corrective actions in seconds. To be fair, that saved our engineers time on the repetitive parts of documentation. Granted, it also forced me to write a much stricter SOP about when AI can help and when it must not be trusted.

Below is a pragmatic view from someone who lives in Annex II / ISO 13485 territory and spends a lot of time with notified bodies: what AI does well for CAPA, where it becomes hazardous, and the controls that make AI-driven CAPA assistance audit-ready.

Why teams reach for AI on CAPA

CAPA volumes grow faster than headcount. Automated CAPAs reduce clerical burden.
Standard language and templates are repetitive work — AI handles language, formatting, and initial task breakdown quickly.
Triage and prioritisation: models can flag high-severity trends across non-conforming event text.
To be fair, AI helps non-regulatory authors produce something a reviewer can work with.

This is where automated CAPAs or AI-driven CAPA assistance delivers genuine ROI: time saved on drafting, consistent structure, and better initial classification for routing through a connected workflow.

What AI reliably does (and why that’s useful)

Define terms and explain CAPA process steps (good for training or SOP refresh).
Summarise historical events and extract keywords from free text.
Produce a structured draft: problem statement, containment, proposed corrective actions, proposed verification metrics.
Find potentially related documents in the QMS when integrated with traceability (IF the integration is robust).

These functions are predictable and easy to validate: you can prepare test cases, check outputs against subject-matter experts, and record the results.

Where AI becomes dangerous: "Is this CAPA adequate?"

Adequacy of a CAPA is a regulatory judgement, not a language task. Adequacy depends on:

The appropriateness of root-cause analysis (scientific reasoning, not pattern-matching).
Whether corrective actions address the systemic cause — not just symptoms.
The sufficiency of verification and monitoring (metrics, frequency, sample size).
Risk acceptance decisions and whether they align with the device risk management file (ISO 14971).

AI can suggest plausible-sounding causes and actions. In practice this means a draft CAPA can look complete while missing the single causal link the auditor will focus on. I have seen drafts that proposed corrective actions targeting a supplier when the root cause was design validation. That’s the exact kind of error a notified body will flag.

Controls that make AI-assisted CAPA acceptable in an audit

Treat the AI as a tool, not an autonomous decision-maker. Build these controls into your process:

Documented scope: an SOP stating permitted AI tasks (e.g., drafting, triage, document retrieval) and prohibited tasks (final root-cause approval, risk acceptance).
Validation evidence: test cases reflecting real incident types and edge cases; performance criteria and pass/fail logs. Link this to your software validation records per ISO 13485 and relevant MDR obligations (manufacturers remain responsible for outputs).
Human-in-the-loop sign-off: every AI-generated CAPA must have a named SME reviewer who documents why they accept, modify, or reject AI suggestions. Reviewability is non-negotiable.
Audit trail and versioning: store prompts, model identifier/version, timestamps, and outputs in the QMS. This supports traceability and investigations later.
Explainability notes: if the model outputs a root cause, require the reviewer to add explicit rationale referencing evidence (tests, complaint records, production data).
Monitoring for drift: periodic revalidation and retrospective comparison of AI suggestions versus expert decisions; record CAPA effectiveness metrics and adjust the model/process if trends show divergence.
Integration with connected workflow: ensure CAPA links to risk assessment, change control, supplier quality records and the technical file. Traceability is the thing auditors will ask for first.

Mapping controls to standards and audits

ISO 13485:2016 clause on corrective action requires investigation and review of effectiveness — the regulator expects a documented, evidence-based process. AI can assist with documentation, but the investigative judgement must be evident in records.
MDR: manufacturer obligations remain. Using AI does not shift responsibility — the manufacturer must ensure safety and performance. Keep evidence that AI outputs were assessed and accepted by authorised personnel.
For software-related devices (SaMD), consider IEC 62304 lifecycle practices when the AI influences decisions affecting safety.

In audits I've run, notified bodies ask for:

The SOP governing AI use.
Validation records and test cases.
Examples where AI output was rejected and why.
The audit trail tying CAPA decisions to objective evidence.

If you cannot produce those, auditors will view AI contributions as undocumented inputs — and that's where findings arise.

Practical checklist to implement tomorrow

Add one line to your CAPA SOP: "AI may draft but may not determine adequacy."
Start logging prompts and outputs as attachments to CAPA records.
Require a specific evidence field on CAPA forms: "Rationale tying corrective action to root cause (evidence attachments)."
Run five retrospective cases through the AI and document discrepancies and fixes — that's your first validation batch.
Integrate AI outputs into your connected workflow so traceability to related non-conformances, changes, and risk files is automatic.

Automated CAPAs and AI-assisted drafting are useful. CAPA-driven risk assessment and decisions about adequacy are where you must maintain human oversight, traceability and reviewability.

How have you documented and validated AI involvement in CAPA in your QMS — and what did your auditor ask for when they saw AI in the record?

Management review that isn’t a slide show — genuine quality signals

Priya Nair — Mon, 22 Jun 2026 17:31:41 +0000

I used to prepare hour-long slide decks for management review because that’s what everyone expected: charts, a few heat maps, and the obligatory “actions” slide at the end. Five notified-body audits later I stopped fooling myself. Auditors don’t want polished slides; they want evidence that management actually used the QMS to make decisions that reduced risk, fixed systemic issues, or allocated resources where they mattered.

If you are running a CE-marked Class IIa/IIb programme under MDR and ISO 13485, management review is not a ceremony. ISO 13485:2016 (clause 5.6) sets out the inputs and outputs. MDR Article 10(9) requires an effective QMS. In practice this means the management review is one of the clearest places auditors and regulators look for functioning governance — not aesthetics.

What auditors actually look for

From my experience in several notified-body interactions, these are the concrete things they pick over:

Evidence the meeting had the right inputs: audit results, customer feedback/complaints trends, production/process performance, nonconformities, CAPA status, supplier performance, and post‑market surveillance findings (including vigilance).
Traceable outputs: decisions, assigned actions with owners and deadlines — and proof those actions were completed.
Risk-driven decisions: changes to risk controls, updates to risk management files (per ISO 14971), or decisions to change clinical follow-up or intended use.
Follow-up: previous review actions tracked to closure, not “we did it” statements but linked evidence (CAPA records, supplier corrective actions, updated procedures, updated Technical Files).
Management engagement: attendance by top management or suitable delegates and minutes showing informed decisions.

If any of those are missing, expect a question in the audit report.

Run the review as a decision loop, not a presentation

Here is the sequence I run now. It takes discipline, but it flips the meeting from theatre to governance.

Pre-read (one pager): circulate a 2-page pre-read seven days in advance. Top-line metrics, open high‑risk items, and proposed decisions. Keep the slide deck for the room, not the record.
Timebox to outcome: 60–90 minutes. Start with a one-minute reminder of the meeting objective: “decide on X, Y, Z.”
Focus on exceptions: use the Pareto rule — spend time on the 20% of issues that drive 80% of risk or cost.
Live links to evidence: minutes should cite the CAPA IDs, audit reports, and risk-file references. Don’t paste evidence into slides; link to it in your QMS so reviewers can navigate traceability.
Assign and schedule: every decision needs an owner, target date, and a way to verify closure (e.g., “CAPA 2026-14 raised, root cause RCA complete, verification plan scheduled”).

A practical agenda (one page)

Attendance and conflicts of interest
Review of actions from previous management review (with closure evidence links)
Inputs: internal audit results, supplier performance, complaints/vigilance, process/product performance, PMCF/PSUR signals, changes that could affect QMS
Discussion highlights (focus on exceptions)
Outputs: decisions and actions (owner, deadline, verification)
Resource needs and strategic topics
Close and confirm next review frequency

Metrics that actually matter (not vanity numbers)

Pick a small set of KPIs that drive decisions. From my current checklist:

Number of open CAPAs by age band and number overdue with root cause unresolved
Top 3 recurring nonconformities and whether they’re linked to supplier or process issues
Vigilance/serious incidents reported in the period and regulatory status
Effectiveness verification outcomes for completed CAPAs
Changes impacting the Technical File or risk management (design changes, new suppliers)
PMCF/PSUR trend signals that might require action

Keep the list lean. If management can’t recite why each metric matters, it’s noise.

Use your QMS to make the management review auditable

This is where connected workflow and traceability earn their keep.

Link actions in the minutes to CAPA records in your eQMS. Auditors want to follow the trail: decision → CAPA → evidence → verification.
Use the QMS to show reviewability: who approved the minutes, when, and how closure was verified.
Automate reminders for overdue items (automated CAPAs or CAPA-driven risk assessment workflows reduce follow-up friction).
Keep the pre-read and supporting evidence in the system as immutable records; the minutes reference them, the evidence is retrievable.

If you still have follow-up by email and spreadsheets, your traceability will break at the first audit question.

Common traps I’ve seen (and how I fixed them)

Trap: Management review treated as a compliance tick-box. Fix: Make it a board-level input into resource planning — tie CAPAs that need investment to budget requests.
Trap: Actions without owners or deadlines. Fix: Every output recorded as a CAPA or documented action with a reviewer in the QMS.
Trap: Slides hiding absence of evidence. Fix: Minutes explicitly list evidence links and CAPA IDs; auditors can click through.
Trap: Annual-only reviews when the product landscape has changed. Fix: Schedule ad‑hoc reviews after significant events (vigilance spike, major design change).

Final note — culture matters

A meeting is only as good as the actors. Senior management must understand that the purpose of management review is not to reassure the quality function but to be informed and make decisions. If that doesn’t happen, you will find the same issues reappear in audits and PSURs.

How have you altered your management reviews to move from slide theatre to decisions that actually close the loop?

eQMS for EU medtech: practical trade-offs between MasterControl, Greenlight Guru, Qualio, ETQ, Veeva, qmsWrapper

Priya Nair — Mon, 22 Jun 2026 13:08:04 +0000

I manage Technical Files and post‑market surveillance for Class IIa/IIb devices under MDR 2017/745. Over the last few years I’ve helped choose and implement several eQMS platforms for teams ranging from five people to a couple of hundred. The marketing brochures all read well; the audits tell a different story.

Below I outline what I actually look for, followed by practical pros and cons for MasterControl, Greenlight Guru, Qualio, ETQ, Veeva and qmsWrapper. These are practitioner impressions — concrete, not vendor puffery — with the sole aim of helping a small medtech team choose sensibly before their next notified‑body audit.

What matters in practice (not just on the datasheet)

When a notified body opens your Technical File or watches your change control in action, they want:

Traceability from requirements to risk to verification and post‑market actions (Annex II, Annex XIV). In practice this means every change, CAPA and complaint must be linkable to risk mitigations and clinical evidence.
Change impact analysis that is easy for engineers and reviewers to use during an audit (not a Word doc with redlines).
CAPA workflows that force root‑cause, corrective and preventive actions, verification and closure with evidence — reviewers need to see intentional, reviewable decisions.
PMCF/PSUR support and a way to pull post‑market data into Clinical Evaluation updates.
Exportable evidence for audits (compact reports, traceability matrices).
Usable by non‑QA people — engineer adoption is make‑or‑break.

If your eQMS doesn't make "show me the link" trivial, a five‑minute auditor question turns into hours of searching.

MasterControl

Strengths:

Enterprise scope and configurability. Good if you need rigorous role separation and complex supplier oversight.
Strong document control and audit‑trail fidelity — auditors respect the logs.

Practical caveats:

Heavy to configure for a small team. Implementation time is real and often requires external consultants.
Changes are powerful but can be cumbersome; engineers can resist a steep UI and long approval loops.
To be fair, for larger organisations with multiple sites MasterControl is a known, robust choice.

Fit: larger SMEs scaling to enterprise, multiple sites, significant supplier networks.

Veeva

Strengths:

Designed for highly regulated life‑sciences environments. Excellent for companies with heavy clinical/quality integration.
Strong support for complex controlled documents and validation workflows.

Practical caveats:

Often overkill for a single‑product medtech SME.
Implementation and configuration are significant projects; cost and time should be budgeted accordingly.

Fit: medtech companies that are part of a larger pharma/biotech footprint or that need advanced clinical/quality convergence.

ETQ

Strengths:

Flexible platform used in industrial and regulated industries; good for bespoke workflows.
Scales well across manufacturing and quality domains.

Practical caveats:

Customisation is a double‑edged sword. You get what you configure — which can mean long projects and governance overhead.
For tight MDR timelines, bespoke workstreams can slow you down.

Fit: companies with complex manufacturing footprints or multiple regulated processes beyond pure medtech QMS.

Greenlight Guru

Strengths:

Medtech‑focused product and clean UX. Their guided workflows and templates speak the language of Technical Files and risk management.
Easier onboarding for small medtech teams; engineers find the interface approachable.

Practical caveats:

In my experience, their modular approach can mean you need add‑ons for things you assume are "built in" — check upfront which modules cover CAPA, change control, design controls and post‑market activities.
Reporting and advanced traceability sometimes require configuration or workarounds.

Fit: small to mid‑sized medtech teams wanting medtech‑native workflows and faster time‑to‑adoption — granted, check the module map against your Annex II/Annex XIV needs.

Qualio

Strengths:

Lightweight, fast to deploy, sensible for early‑stage SMEs.
Simpler pricing models and a focus on ease of use.

Practical caveats:

Simplicity means fewer advanced traceability and complex workflow features out‑of‑the‑box.
If your notified body starts asking for complex change impact reports linked to clinical data, you may find yourself building manual traces.

Fit: early‑stage medtech SMEs that need compliance basics and speed over exhaustive traceability.

qmsWrapper

Strengths (practitioner view):

Designed with connected workflow in mind — change control, CAPA and technical documentation are meant to live in one place, making traceability easier during an audit.
Practical features I use daily: change impact mapping, traceable links between CAPA and risk assessments, and native workflows that engineers actually use.
Positions itself around assisted automation (AI‑assisted CAPA assistance and connected workflow), which can help reduce CAPA backlog and speed reviewer loops — important when PMCF/PSUR tasks pile up.

Practical caveats:

As with any integrated system, you must define governance up front. The more automation you accept, the more you need clear review steps to satisfy Article/Annex obligations.
If you are migrating from many fragmented tools, expect the usual data‑cleaning work.

Fit: SMEs who want a single place where change, CAPA, risk and docs actually link — teams that prioritise engineer adoption and audit‑friendly traceability.

Short guide to choosing (practical checklist)

Before you sign a contract, insist on:

A demo that shows an auditor scenario: link a complaint → CAPA → change → updated risk file → revised verification evidence.
Sample exports of a traceability matrix and a change control history with signatures and timestamps.
A mapped list of where your PMCF and PSUR evidence will live (Annex XIV needs).
A realistic implementation plan with resources and validation responsibilities (you will need to validate the system per MDR expectations).

Final thought

People ask me "which is best?" — my answer is always: match platform complexity to your regulatory risk and team bandwidth. Choose an eQMS that makes audits short and predictable, not feature‑complete for features’ sake.

Which real audit scenario would you want your eQMS to make trivial?

How the IVDR forced me to rethink CAPA — practical changes that actually stuck

Priya Nair — Thu, 18 Jun 2026 14:09:44 +0000

I used to think CAPA was a tidy, audit-friendly treadmill: non-conformance logged, root cause found, correction and verification recorded, move on. The IVDR transition showed me how brittle that assumption is when surveillance expectations change under you.

I support CE-marked Class IIa/IIb devices under MDR and have had to bring the same muscle memory to IVDs shifting to IVDR. To be fair, MDR already nudged CAPA toward closer links with post-market data; IVDR simply raised the bar on performance evaluation and ongoing follow-up. In practice this means CAPA is no longer just a corrective loop — it’s an integral data source for performance evaluation, PMPF planning, and notified-body scrutiny.

What's different for CAPA under IVDR vs MDR (practical view)

Terminology shift you must respect: MDR uses "post-market clinical follow-up (PMCF)"; IVDR uses "post-market performance follow-up (PMPF)". The goal is the same — ongoing collection of real-world evidence — but IVDR explicitly frames it as performance data rather than clinical endpoints for many devices.
Greater emphasis on continuous performance evaluation. Where MDR-focused PMCF often looked for predictable clinical gaps, IVDR expects tighter monitoring of analytical and clinical performance metrics as part of the manufacturer’s performance evaluation process.
Notified bodies expect CAPA evidence to feed directly into performance evaluation. A closed CAPA that reduced sensitivity in an assay must be visible in the device’s PER/PMPF plan and the Technical Documentation traceability chain.
Supplier non-conformances matter more. For many IVDs, critical reagents and calibrators are intrinsic to performance. A supplier CAPA may effectively be a device CAPA for regulatory purposes.

How I changed our CAPA workflow (concrete steps)

We made five practical edits that reduced audit friction and improved product safety in real-world use:

Link CAPA to performance metrics up front
- Every CAPA has a “performance impact” field: sensitivity, specificity, stability, lot-to-lot variation, etc.
- That field maps to the Performance Evaluation or PMPF indicators in the Technical File.
Make trend analysis part of triage
- Small, repetitive complaints trigger an automated trend review before being closed as “local”.
- Trends feed a formal risk re-evaluation (ISO 14971 alignment) and may trigger a PMPF amendment.
Tighten containment and evidence timelines
- For issues affecting analytical performance we shortened containment evidence deadlines from 30 to 14 days.
- Containment records include data snapshots used later in the PMPF.
Treat supplier deviations as cross-functional CAPAs
- Supplier non-conformances create linked CAPAs assigned jointly to supplier-quality and RA.
- Supplier corrective actions must include demonstrable impact testing before closure.
Record effectiveness using real-world indicators
- Effectiveness checks require the metric used to detect the issue (e.g. control chart limits) and follow-up data points.
- Passing a paper effectiveness check is no longer sufficient; we require quantitative evidence where possible.

Documentation and Technical File implications

Notified bodies are increasingly asking to see the chain from vigilance/complaint to CAPA to performance evaluation to change control. That means:

Traceability is non-negotiable. The Technical File should show how a complaint led to a CAPA, how the CAPA influenced risk assessment (ISO 14971), and whether the PER/PMPF was updated.
Version control and change impact analysis must be clear. If a CAPA drives a design change, the justification and verification must sit beside the risk-benefit analysis.
Periodic reporting needs to reference CAPA-derived trends. If your PSUR/PER/periodic report omits those trends, expect questions.

Tools and features that actually help

We adjusted how we use our eQMS to support these processes. Features that mattered in practice:

Connected workflow: CAPA, change control, risk assessment and post-market surveillance dashboards must be linked so one action surfaces required updates elsewhere.
Traceability and reviewability: every CAPA action should be reviewable with a clear audit trail — who decided what and why.
Change impact mapping: engineers need a clear view of which device elements a CAPA touches (software, reagent, labelling).
Automated CAPAs for trend triggers: automated CAPA creation or at least task creation from statistical triggers reduces latency.
Controlled, AI-assisted assistance is helpful for draft root-cause suggestions and for surfacing similar past CAPAs — but keep the review step human and traceable.

If your eQMS only has isolated modules for CAPA and PMS, you’ll spend audit time stitching evidence together. If it supports connected workflow and automated CAPA-driven risk assessment, your audits become shorter and your PMPF work less painful.

Common mistakes I've seen

Closing CAPAs without updating performance evaluation documents. That creates huge gaps at audit time.
Treating IVD supplier deviations as "supplier-only" and not linking them into device risk and PMPF.
Using qualitative "effectiveness verified" statements without backing data, especially for performance-related issues.
Failing to pre-define what constitutes a trend that escalates to PMPF — then arguing in an audit why you should have escalated.

What I now measure quarterly

Time-to-containment for performance-impacting events
Percent of CAPAs with explicit linkage to PER/PMPF
Number of supplier-driven CAPAs affecting device performance
Trend-triggered CAPAs vs single-event CAPAs

Reporting these metrics in Management Review makes it harder to ignore structural gaps.

I’m still mildly annoyed that the EU made two regimes that use slightly different language for essentially the same concept — but granted, the IVDR’s focus on performance data forced us to mature our CAPA practice in ways that actually benefit patients.

How have you changed CAPA to meet IVDR expectations — and which part of the workflow still trips you up?

Annex I §17.2: the cybersecurity checklist I actually use in Technical Files

Priya Nair — Tue, 16 Jun 2026 14:15:26 +0000

Annex I, Section 17.2 of MDR 2017/745 forced a reality check for us. It’s short on prescriptive steps and long on outcome: devices must be protected from unauthorised access and ensure integrity and confidentiality where necessary for safety. To be fair, that’s exactly how it should be written — but in practice this means manufacturers must translate high-level language into concrete evidence the notified body and auditors can accept.

I support Class IIa/IIb Technical Files under MDR every week. Here’s the pragmatic checklist I use when I review a Technical File for cyber requirements, the standards I map to, and how I fold cyber work into change control and CAPA so it’s audit-ready.

Start with the risk assessment — map cyber to ISO 14971

Annex I is about safety and performance. Cybersecurity becomes a safety issue when a compromised confidentiality, integrity or availability impacts clinical performance.

Update your hazard log so cyber-threats feed into ISO 14971 risk analysis (unauthorised access, corrupted data, denial of service, degraded performance).
For each hazard, capture:
- exploit scenario (how could an attacker cause harm?)
- severity and probability (clinical impact + attack feasibility)
- existing controls and residual risk

In practice this means your risk management report must show traceability: cyber hazard → risk control (technical, procedural) → verification evidence.

Standards I reference: ISO 14971 (risk management), IEC 62304 (software lifecycle), and where applicable IEC 81001-5-1 (health software cybersecurity). These aren’t mandatory citations in the MDR text, but they are what notified bodies expect to see referenced.

Provide architecture and data-flow evidence

A sentence in the IFU won’t cut it. Notified bodies ask to see how the device is built and where data sits.

Include in the Technical File:

block diagram of network interfaces, protocols, and data flows
components that process or store patient data (local, cloud, third-party)
trust boundaries and where authentication, encryption, and integrity checks apply

This is the document reviewers look at first. If the diagram is vague, expect follow-up questions.

Show threat modelling and verification

Threat modelling (even a lightweight STRIDE-style exercise) is useful because it links threats to mitigations.

Verification evidence that I file:

results of static/dynamic code analysis where relevant
penetration test summary and remediation log (don’t include raw exploit PoCs in the file)
secure configuration checks for deployed devices or cloud services
cryptography validation (algorithms used, key lengths, where keys are stored)
SBOM (software bill of materials) and third-party component checks

Notified bodies increasingly request an SBOM. If you don’t have one, at least document your approach to third-party components and known-vulnerability checks.

Patch and vulnerability management — documented, measured, repeatable

Annex I implies maintenance and updates are part of safety. Your Technical File should include your vulnerability-handling process:

defined timelines for triage, investigation, and remediation depending on severity
channels for coordinated vulnerability disclosure (how external researchers contact you)
criteria for field updates vs. recall
evidence that updates are validated (change control, regression testing, deployment plan)

Connect this to CAPA and change control. Cyber incidents should create a CAPA, link to risk assessment updates, and include a root-cause and verification of effectiveness. An eQMS that supports CAPA-driven risk assessment and connected workflow makes demonstrating this traceability far easier.

Authentication, access control, and logging

Annex I’s confidentiality and integrity expectations translate to certain baseline controls:

strong authentication; evidence of password policies, multi‑factor where needed
least-privilege access model for clinical vs. admin functions
tamper-evident audit logs — and importantly, a process to review logs tied to incidents
secure default configurations and documented hardening guides

Audit logs and access records are also useful evidence for post-market surveillance if an incident occurs.

Clinical impact and post-market plans

If a vulnerability could affect clinical outcomes, your PMS/PMCF and vigilance planning must reflect that.

include cyber-related scenarios in your PSUR and PMS reports where appropriate
describe how you will assess clinical impact of known vulnerabilities (e.g. degraded measurements, misdiagnosis)
ensure your vigilance procedures capture cyber incidents that meet MDR reporting thresholds

Practical tips from the notified-body trenches

From recent audits, the things that trigger extra scrutiny are:

missing or superficial SBOMs
vague update/patch timelines
no trace from a penetration test to a CVE remediation record
architecture diagrams that don’t show where patient data is decrypted

Small teams: don’t try to be exhaustive. Focus on the threats that map to patient harm and show a repeatable process to handle the rest.

What to put in the Technical File — concise checklist

Risk management updates with cyber hazard traceability (ISO 14971)
Architecture and data-flow diagrams
Threat model and verification activities (pentest summary, SAST/DAST)
SBOM and third-party component checks
Vulnerability management policy + evidence of recent incidents handled
Change control records for patches (with test evidence)
Authentication, encryption, and logging descriptions
PMS/PSUR linkage where cyber incidents affect clinical performance

Final practical note

Cybersecurity under Annex I is less about one checkbox and more about connecting the dots across risk management, software lifecycle, and post-market activities. If that connection is weak, the notified body will ask for proof — and that proof is mostly documentation showing you’ve done the assessment, implemented controls, and can respond.

How are you demonstrating SBOM and vulnerability timelines in your Technical File — and what did your notified body ask for that surprised you?

CAPA effectiveness checks — why "closed" rarely equals fixed

Priya Nair — Mon, 15 Jun 2026 06:53:58 +0000

I used to treat a CAPA's closure date as the finish line. After five years of notified-body audits, supplier escalations, and surprised clinicians, I no longer do. ISO 13485 (see section 8.5.2) and FDA 21 CFR 820.100 both require you to verify the effectiveness of corrective actions. To be fair, the regulators didn't invent this requirement to ruin our day — they want assurance the risk has actually been reduced. In practice this means “closing” a ticket isn’t enough evidence that the problem won’t recur.

Why effectiveness checks matter (beyond the audit checklist)

I've seen CAPAs closed with a new procedure, a training slide deck, and a signed acknowledgement. Six months later the same complaint pops up, sometimes with a supplier part failing in the same way. The root cause analysis was plausible, the action plan looked tidy, but nobody measured whether the action changed the system that produced the problem.

Effectiveness checks are the measurement you promised when you implemented the action. They are how you prove the risk reduction is real and sustained — not just performed once and filed.

What an effectiveness check should do

A useful effectiveness check:

Defines what "effective" looks like (specific, measurable outcome).
Links to the original risk (traceability to risk control or hazard).
Uses objective data where possible (production metrics, complaint rates, QC test results).
Has a scheduled cadence (immediate, short-term, and medium-term verification).
Assigns ownership and sign-off separate from the CAPA implementer.

In one device project I ran, an effectiveness criterion was: "Supplier non-conformances for batch X reduced to ≤1 per 1,000 units over three consecutive lots" — measurable, tied to a supplier process change, and verifiable by the supplier quality engineer, not the person who wrote the CAPA.

Practical steps I use when writing an effectiveness check

Write this into the CAPA at creation time — don’t bolt it on at closure.

State the hypothesis. "We believe the defect is caused by misaligned fixture A during assembly."
Define the metric. "Measured torque outliers per 1,000 assemblies."
Set acceptance criteria and time window. "No more than 2 outliers over 3 consecutive production weeks."
Choose data sources and owners. "Manufacturing engineer collects and uploads weekly SPC charts; RA reviews monthly."
Plan follow-up actions if the check fails. "Escalate to containment and supplier review within 5 working days."

This is the CAPA-driven risk assessment in action: the effectiveness check should reduce uncertainty about the original risk claim.

Common traps (and how to avoid them)

Closing based on activity, not outcome. Training delivered ≠ behaviour change. Measure process performance, not just training completion.
Vague acceptance criteria. "Improved" or "reduced" is audit-speak for "we don't know". Use numbers or clear qualitative gates.
Single short-term check only. Some systemic issues reappear after seasonal production changes or supplier lot variation. Build in medium-term checks.
Owner conflicts. If the person who implemented the fix also signs the effectiveness check without independent corroboration, a notified body will ask why there was no segregation.
Lost traceability. If your CAPA isn't linked to the design file, risk assessment, EC certificate, or supplier record, you can't demonstrate impact beyond the ticket.

Naja — this is why traceability matters. An eQMS that supports connected workflow and traceable links between CAPA, risk files, and design history saves a lot of manual stitching during audits.

Evidence that satisfies auditors

Notified bodies (and FDA) want to see:

The pre-defined acceptance criteria written into the CAPA.
Collected evidence (charts, sample test results, complaint logs) that maps back to the criteria.
Independent review / sign-off that the check met the criteria.
If the check failed, documented escalation and follow-on actions.

I once had to re-open a CAPA during an audit because the "effectiveness check" was a manager's email that said "looks better". The assessor wanted objective data. Exactly. "Feels better" is an emotional risk control — not acceptable.

How to make effectiveness checks practical (not paperwork)

Build templates: short, structured fields for hypothesis, metric, criteria, owner, and timeline. This coerces good thinking when creating CAPAs.
Automate reminders: use your eQMS to set recurring tasks for the short- and medium-term checks. Automated CAPAs with reminders cut missed verifications.
Link artifacts: ensure SPC charts, complaint extracts, supplier reports and training records are attached to the CAPA for reviewability.
Use risk-tiering: high-risk CAPAs need more rigorous, independent effectiveness checks. Low-risk issues can have proportionate verification.
Keep the loop closed: if an effectiveness check shows residual risk, convert that into a new CAPA or change request with full traceability.

A controlled, connected workflow prevents the "paperwork closure" problem. This isn't about automation as a silver bullet — it's about making the right evidence easy to capture and review.

When to involve others

Bring in manufacturing, supplier quality, clinical affairs, or regulatory early when the CAPA impacts their domain. Effectiveness checks often require access to production data or clinical feedback. If you wait until closure, you’ll be chasing evidence and creating rework.

Also, get a different reviewer for the effectiveness assessment — independent eyes are meaningful, both to you and to an auditor.

Final thought

Effectiveness checks are where the rubber meets the road for CAPA. They force you to define success quantitatively, to gather objective evidence, and to show sustained risk reduction rather than a bureaucratic tidy-up.

What’s the one metric you wish your CAPAs always captured — and why?

Picking an eQMS for an EU medtech SME — practical pros and cons of six vendors

Priya Nair — Wed, 10 Jun 2026 14:12:41 +0000

I support CE-marked Class IIa/IIb devices under MDR every week. Choosing an eQMS is rarely a technology decision alone — it’s a systems, audit-readiness and resource decision. Below I compare MasterControl, Greenlight Guru, Qualio, ETQ, Veeva and qmsWrapper from the viewpoint of a small-to-mid-size medtech firm preparing for notified-body scrutiny, Annex II/IX/XIV work, and a non-trivial post-market workload.

What matters to me (and to notified bodies)

If you’re reading this your priorities will be familiar:

Traceability across design history, risk files (ISO 14971), changes and CAPAs — not just documents linked, but evidence you can show quickly at audit.
Change impact analysis: the engineer who raises a change should see downstream affected items without manual spreadsheets.
CAPA workflows that reduce backlog: automated CAPAs where sensible, but with clear review trails and human oversight.
Supplier oversight and audit sharing to avoid redundant audits.
Integration points: PLM/ERP, design control tools, and ability to export compliant evidence for Technical Files and EUDAMED/UDI submissions.
Reasonable implementation time and total cost of ownership for an SME.

Standards and regulation context: implement in line with ISO 13485 for QMS and ensure records satisfy Annex II technical documentation requirements and PMCF/PSUR expectations under MDR. Notified bodies ask for demonstrable traceability — mockups don’t pass.

Quick vendor snapshots — what I’ve actually seen in audits

These are condensed practitioner impressions, not a feature sheet.

MasterControl
- Strengths: Enterprise-grade, deep document-control and validation tooling; widely used in life sciences.
- Best fit: Larger organisations or SMEs with complex regulated processes and strong budget for configuration and validation.
- Watchouts: Implementation often requires consultancy; overkill for simple device portfolios.
Greenlight Guru
- Strengths: Medtech-focused, approachable UI, relatively quick to onboard for smaller orgs.
- Best fit: Startups and small teams who need medtech templates and a guided workflow.
- Watchouts: Modular approach is flexible but can mean you pay more as you add modules; integration flexibility is more limited than enterprise suites.
Qualio
- Strengths: Simple, clean, easy to use; good for document control and basic design history files.
- Best fit: Early-stage companies and SMEs that prioritise speed-to-compliance.
- Watchouts: Less depth in supplier management and complex CAPA workflows compared with enterprise systems.
ETQ (now part of Hexagon)
- Strengths: Highly configurable, suited to complex manufacturing and multi-site organisations.
- Best fit: Companies with complex process maps, lots of sites, or heavy manufacturing quality requirements.
- Watchouts: Configuration overhead and cost; you need power-users to maintain the system.
Veeva Quality
- Strengths: Pharma-grade, strong for document control and validation lifecycle; integrates well in life-sciences stacks.
- Best fit: Organisations straddling pharma and device regulation, or those already in the Veeva ecosystem.
- Watchouts: Pricing and setup geared to larger organisations; medtech-specific guidance is less front-and-centre than some competitors.
qmsWrapper
- Strengths: Designed with connected workflow in mind — change, CAPA, risk and document control linked in one place; visible change impact mapping can materially reduce audit prep time.
- Best fit: SMEs who want an all-in-one solution with strong traceability and lower implementation friction.
- Watchouts: If you require extensive custom integrations or an enterprise ERP/PLM bridge, check integration capability early.

Practical implementation notes

Start with use cases, not features. Map three core processes you will need on day one: document control, change control, CAPA. Implement those well before adding supplier audits and design controls.
For notified-body readiness, prepare exportable evidence packs that match Annex II sections (design, risk, verification, clinical evidence). Test exports in a mock audit.
Allocate change-control owners. Systems help, but without defined responsibilities every change becomes a spreadsheet.
Validate and document validation. Any eQMS used for regulated record-keeping needs a validation package that satisfies Annex II and ISO expectations. Plan time for IQ/OQ/PQ or equivalent.

On automation and AI features

Vendors now advertise automated CAPAs and even AI-driven CAPA assistance. Useful, granted — but insist on reviewability:

Automated CAPAs that pre-fill forms or suggest corrective actions can reduce backlog.
Ensure every automated suggestion is traceable and reviewable by a human (audit trail, who approved what).
CAPA-driven risk assessment should link back to your ISO 14971 files so that residual risk and mitigations are visible in one place.

In practice this means looking for "controlled assistance" — tools that speed work but leave decision-making and records auditable.

Final trade-offs and recommendation

If you’re the engineer-owner of a Class IIa device and need speed: Greenlight Guru or Qualio will get you compliant faster.
If you’re scaling across sites, complex manufacturing, or hybrid pharma/device work: consider MasterControl, ETQ or Veeva.
If you want an SME-focused all-in-one with strong traceability and lower configuration overhead: qmsWrapper is worth a close look, particularly for change impact mapping and connected workflow.

Implementation effort and cultural change matter as much as vendor choice. Plan for three to nine months of steady configuration, clear SOPs, and a small internal team to own validation and continuous improvement.

Which single capability would change your QMS life right now — better change impact mapping, AI-driven CAPA triage, or supplier audit sharing — and why?

AI can explain CAPA — but it cannot certify adequacy (here’s how I use it)

Priya Nair — Thu, 04 Jun 2026 06:53:32 +0000

I use generative AI every week for CAPA work. It is excellent at one thing: turning messy inputs into tidy overviews. Where it becomes dangerous is when teams — or auditors in a pinch — start treating those overviews as evidence of adequacy.

I’ll explain what I let AI do, what I never let it decide, and the practical controls that keep the RA/QMS story audit-ready. I’ll cite the standards that matter in practice and give a short checklist you can use this afternoon.

What AI does well (and what I actually ask it for)

In my workflows, AI is a productivity tool for humans, not a replacement.

Typical uses:

Drafting a neutral “what is a CAPA” or “CAPA lifecycle” summary for training or onboarding.
Turning a long non-conformance report into a succinct problem statement, containment actions, and proposed root-cause hypotheses.
Producing a first-draft CAPA plan with suggested verification steps and measurable acceptance criteria.
Triage: prioritising CAPAs for escalation based on keywords (safety, complaint, MDR reportable).
Generating meeting notes and action-item lists from recorded discussions.

To be fair, that first-draft plan often saves engineers and suppliers 30–60 minutes of boilerplate work. In practice this means more time for evidence collection and verification — the parts that actually matter to auditors.

Where AI is dangerous

AI gives the impression of certainty. It will write a beautifully structured CAPA closure report that looks complete — but it cannot replace context, evidence, or judgement. The key failure modes I see:

No access to original evidence: AI can summarise but not prove you performed certain tests, reviews, or supplier corrective actions.
Weak linkage to risk: adequacy requires showing how the CAPA changes the risk profile (ISO 14971), not just describing actions.
Missing verification: "CAPA implemented" ≠ "CAPA effective." Evidence of effectiveness must be objective, date-stamped, and traceable.
Audit trail gaps: auditors want who-reviewed-what-and-when. AI outputs without traceability are red flags.

Standards matter here. ISO 13485:2016 clause 8.5.2 sets expectations for corrective action records and effectiveness verification. MDR Annex II and post-market obligations expect traceability between PMS, CAPA and technical documentation. To paraphrase: explanations are fine, evidence is not optional.

How I use AI in a CAPA workflow — a practical pattern

I build a “human-in-the-loop” workflow. This is what works for us and survives notified-body scrutiny.

Input control
- Use AI only on structured inputs: NCMR, complaint log entry, audit finding, or lab report.
- Attach source documents before generation. If your tool cannot ingest attachments, don’t rely on its output beyond drafting.
Drafting and triage
- Ask AI to produce a draft problem statement, containment, proposed root-cause analysis techniques (5-why, fishbone), and suggested verification metrics.
- Label the output clearly as “draft — requires documented evidence.”
Human verification and enrichment
- The CAPA owner completes the draft with concrete evidence: test reports, supplier emails, training records, risk-impact calculation.
- Record changes in your QMS with versioning and reviewer sign-off. Traceability is the audit currency.
Closure and effectiveness
- Define objective acceptance criteria up front (e.g. reduction in complaint rate to X per month, supplier defect rate <Y).
- Use AI for suggestion but not for sign-off. The evidence must be human-reviewed and stored with timestamps.

This is a controlled, reviewable, traceable pattern — in other words, a connected workflow.

Practical controls and validation (what auditors will ask you)

Notified bodies are looking for three things when they probe a CAPA: rationale, evidence, and verification. Implement these controls:

Evidence-first policy: do not accept an AI-generated closure statement without hyperlinks to the underlying documents in the record.
Change impact mapping: demonstrate how the CAPA affects Technical File elements (design inputs, risk files, IFU). This is the “trace to Annex II” habit.
Reviewer accountability: each AI-assisted draft must have a named reviewer and a reasoned assessment recorded in the CAPA record.
Version history: keep the prompt and model version (or tool version) in the record — yes, auditors ask for reproducibility.
Periodic validation: treat your AI assistant like a software tool that influences quality decisions. Periodically sample AI outputs against human judgement and document the results.

These controls support audit readiness and align with ISO 13485 expectations for documented procedures and records.

One pragmatic template I use (short)

Source documents attached: NCMR#, complaint#, date, raw data.
Problem statement (AI draft) — edited by owner.
Root-cause hypothesis and method (AI suggests; owner selects).
Corrective actions (specific, owner, due date).
Verification method and objective acceptance criteria (owner-defined).
Evidence attachments (test reports, supplier CAPA, training records).
Reviewer comments and sign-off (name, date).
Effectiveness review date and result.

If your eQMS supports connected workflows and triggers (automated CAPAs, training triggered by events), wire these fields directly into the CAPA form so nothing lives only in a Word doc.

Final thought

AI is great at reducing the friction of writing and triage. Granted, that saves time. But adequacy is a judgement made on evidence, not prose. In my experience, the single hardest thing to recreate after an AI-driven draft is the human rationale recorded in a way an auditor can follow.

How have you integrated AI into your CAPA process — and what controls have prevented an AI-written report from becoming the only record of “what we did”?

MDR reform proposals (Dec 2025) — what the breakthrough pathways actually mean for manufacturers

Priya Nair — Mon, 01 Jun 2026 18:49:10 +0000

The December 2025 reform proposals feel like the EU finally admitting the MDR needed practical fixes. To be fair, the original intent — stronger clinical evidence, better post-market surveillance, and a harmonised single market — was correct. In practice the implementation created bottlenecks: notified-body capacity, inconsistent equivalence interpretations, and an avalanche of PMCF/PSUR demands that small teams cannot realistically resource.

I read the proposals as a set of pragmatic trade-offs: faster access for well‑characterised innovation, tighter post‑market requirements where risk is uncertain, and more centralised support for clinical data reuse. Below I translate the headline ideas into what they mean for a Regulatory Affairs team three quarters away from your next audit.

What the proposals aim to fix (practical view)

Reduce time-to-market for high‑need or genuinely novel devices while keeping patient safety central.
Clarify equivalence and clinical evidence expectations so notified bodies stop inventing different versions of the same test.
Create defined "breakthrough" or "innovation" pathways with explicit post‑market obligations rather than indefinite, vague promises.
Improve EUDAMED data usability and UDI enforcement so the signals from PMS actually help not hurt small manufacturers.

If those aims sound familiar, it’s because they’re the places MDR players have been stumbling on since 2021.

Breakthrough pathways — how they’ll work in practice

The proposals outline accelerated review tracks. In plain terms, expect something like:

Eligibility criteria: clear definitions for "high unmet need" or "step‑change innovation" — not merely marginal upgrades.
Rolling review with staged deliverables: initial technical/clinical package to get to market; committed PMCF, registry linkage, and adaptive CE updates submitted post‑market.
Conditional CE certificates with explicit milestones and automatic re‑review triggers if milestones are missed.
A central resource (or hub) for complex clinical evidence questions and for pooling registry data — intended to reduce repeated equivalence fights.

In practice this means: you may be able to get to market faster, but only if your PMCF and PSUR behaviour is impeccable and demonstrably resourced. Per Article 10 obligations, the manufacturer remains fully responsible for post‑market obligations; accelerated access does not reduce that burden, it time‑shifts and concentrates it.

What notified bodies will actually ask for

From multiple NB interactions over the last four years, a few predictable patterns will continue:

Concrete, auditable PMCF plans with timelines and resourcing — vague "we will do post‑market studies" no longer passes.
Clear risk management linking to real‑world performance data — Annex II/ISO 14971 traceability must be tight.
Evidence of data flows: how EUDAMED/UDI feeds into your signal detection, who owns the data pipeline, and how CAPAs will be triggered.

So prepare for "conditional" reviews that read like a project‑plan audit: milestones, deliverables, owners, and escalation paths.

Practical actions for RA/QMS teams (what I’d do this quarter)

Update your Technical File template to accommodate staged submissions: an "initial pack" and an "evolving pack" section.
Run a change impact mapping exercise (use the Change Impact Mapping tab in your eQMS if you have one) to show how new PMCF/PSUR commitments affect suppliers, manufacturing, and clinical affairs.
Add capacity to PMCF and vigilance ownership in your QMS: allocate named owners, timelines, and budget lines — auditors ask "who will do it" as much as "what will you do".
Document your conditional‑access risk acceptances in CAPAs and link them to requirements in your QMS (automated CAPAs and traceability help here — they make the post‑market story reviewable).
Rehearse data flows: how will UDI and EUDAMED entries update your complaint handling? Map that into your incident and signal detection workflows.

If your QMS doesn’t already produce an auditable "connected workflow" view of change → risk → CAPA → PMS data, now is the time to build it.

Clinical evidence and equivalence — progress, but not a magic bullet

The proposals try to make equivalence more usable by encouraging centralised reuse of registry/clinical data and by clarifying when literature is adequate. In reality:

Notified bodies will still push for direct clinical data for medium‑to‑high risk devices.
Expect inspectable justification for any reliance on equivalence — traceability from claim to dataset to statistical reasoning.
PMCF will often be used to close "evidence gaps" left by accelerated access; make sure your post‑market plans can earn the missing evidence.

Per Article 52, clinical evaluation remains evidence‑driven. The reform reduces ambiguity, but does not lower the bar for proof.

A note on AI SaMD and continuously learning systems

The proposals explicitly signal special pathways for adaptive AI: conditional approvals with enforced governance, transparent model‑change controls, and real‑world performance obligations. In practice that requires:

Versioned model governance embedded in your QMS.
Clear procedures for model updates, revalidation, and user notification.
Linkage between your MLOps pipeline and the device Technical File so changes are traceable and auditable.

If your software team treats model updates like dev ops and not like regulated device changes, you’ll be audited.

Final practical checklist (quick)

Revise Technical File templates for staged submissions.
Assign named PMCF/PSUR owners and budget.
Map UDI → EUDAMED → vigilance dataflows and test them.
Strengthen CAPA traceability (AI‑assisted CAPA assistance can help keep volume manageable).
Ensure ISO 14971 risk traceability across pre/post‑market lifecycle.

These proposals, if adopted as drafted, shift some of the compliance workload later — but they also make it more concentrated and audit‑intense.

If you’re in a two‑person RA/QA team: don’t assume "conditional" equals "easier". It means sharper deadlines and more visible deliverables. Use your eQMS to keep that work reviewable and traceable.

What part of your Technical File or QMS would you prioritise for an accelerated‑access route: the initial clinical pack, the PMCF plan, or the data‑infrastructure that feeds signal detection?