DEV Community: Priya Nair

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?

Near-misses vs device failures — what MAUDE actually tells a European RA

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

I monitor vigilance and post‑market data as a daily job. I live in Annex II/IX/XIV when I’m writing Technical Files or PMCF plans, and I also keep an eye on external sources — not least MAUDE, the FDA’s Manufacturer and User Facility Device Experience database. It’s tempting to treat MAUDE like a crystal ball: search a competitor, find a pattern, fix your product. To be fair, it’s useful — but it is not what most people expect.

Near-miss vs device failure — definitions that matter

First, a quick operational distinction I use in my files (and which feeds risk-management and CAPA):

Near‑miss: an event in which a device did not cause harm but had the potential to do so (intercepted failure, recovered error, or an instance where use‑environment or user action nearly led to an incident). In ISO 14971 terms this is a hazardous situation that did not lead to harm but had potential.
Device failure / incident: a malfunction or performance issue that resulted in harm (injury, deterioration of health, or death) or a serious deterioration as defined in MDR vigilance provisions.

Why this matters: near‑misses are leading indicators — they let you act before patient harm. Device failures are lagging indicators — they tell you something has already gone wrong and must be reported and corrected per your legal obligations.

What MAUDE shows (and what it doesn’t)

In practice this means treating MAUDE as a signal source, not definitive evidence.

What MAUDE is good for:

Surface-level pattern spotting across manufacturers — repeated device malfunctions, recurring software version mentions, or repeated user‑interface complaints often appear in narratives.
Revealing use‑environment and user behaviour issues (off‑label use, user errors, connection/compatibility problems).
Early warnings about packaging, labelling, and connector compatibility problems — those show up frequently in free text.

What MAUDE is not:

A root‑cause confirmation tool. Most entries are preliminary — they report what someone observed, not what your internal investigation later found.
A complete dataset. It’s US‑centric, has mixed submitter quality (manufacturer vs user submissions), duplicates, and variable narrative clarity.
A substitute for your vigilance obligations under MDR Articles 87–92 (vigilance and post‑market surveillance in the EU) or 21 CFR Part 803 (US MDR) — you still need to report, investigate, and take corrective action per the applicable regulations.

How I use MAUDE in a practical PMS programme

I don’t monitor MAUDE because it’s novel — I use it as part of a connected PMS feed. Steps I follow:

Regular scans: weekly keyword and competitor searches. The keywords include device model identifiers, software versions, and common failure modes we know from our risk register.
Triage: not every hit becomes an investigation. My triage criteria usually include:
- Any mention of patient harm (mandatory escalation).
- Recurrent themes across multiple reports.
- New or unexpected modes of failure not listed in the current risk analysis (ISO 14971).
Open an investigation in the QMS: even a near‑miss gets a record. Traceability is essential — link the MAUDE entry to a complaint record, risk assessment, and any CAPA. In an eQMS this should be a connected workflow: an alert creates a review task, which then maps to a CAPA if needed.
Risk reassessment and trending: if the near‑miss changes the likelihood or severity in the risk assessment, update the ISO 14971 record and the technical documentation (Annex II content, where applicable).
Feed into PSUR/PMCF: aggregate signals for periodic safety update reports and PMCF activities per MDR Articles 87–92 and your PMCF plan.

Near‑misses: why they’re often underused

From audits and NB interviews I’ve run, the same themes recur:

Near‑misses get logged as “anecdotes” in a project spreadsheet and never make it into formal complaint/CAPA workflows. This destroys traceability and prevents trend analysis.
Where software or human factors are involved, MAUDE narratives often hint at user confusion — but unless you treat those hints as design signals, you won’t prevent the incident.
Teams fear over‑reporting. To be fair, there’s regulatory noise: not every near‑miss requires a field safety corrective action. But under ISO 13485 and MDR PMS expectations, you must capture user feedback and evaluate it objectively.

Practical triggers that have worked for me

I use simple, reviewable triggers for escalating a near‑miss into CAPA-driven assessment:

Repetition: same failure mode appears X times across independent reports within Y months (define X/Y for your device risk).
Severity drift: a near‑miss points to a failure mode that could reasonably lead to serious harm if frequency increases.
New mode: a type of failure not previously evaluated in the risk analysis.
External corroboration: MAUDE plus similar signals from other registries, literature, or distributor/clinical feedback.

Set these as configurable thresholds in your eQMS so that automated CAPAs or investigation records are created. That is controlled assistance, not magic: the action is driven by the trigger, but investigators still review and authorise.

A few dos and don’ts

Do:

Treat MAUDE as a complementary data source for PMS and PSUR.
Link each external hit to your traceable QMS record (complaint, risk assessment, CAPA).
Use near‑misses to drive preventive actions — changes to IFU, training, or design modifications.

Don’t:

Use MAUDE narratives as final evidence of root cause.
Ignore near‑misses because they didn’t cause harm this time.
Let trends sit in spreadsheets outside the QMS; you need reviewability and traceability for audits.

Final note

To be blunt: vigilance that starts only after harm is visible is too late. Near‑misses are the early warning bells, and MAUDE is one of several bell towers. Integrate those bells into your QMS so that investigation, CAPA, risk reassessment, and documentation all live in the same connected workflow — that’s how you convert signals into safer devices.

How are you currently using MAUDE or other external databases in your PMS process, and what’s the most actionable near‑miss you’ve turned into preventive change?

How I validate LLMs for GxP work — scope, evidence, and the auditor's checklist

Priya Nair — Fri, 29 May 2026 17:29:22 +0000

I started seeing LLMs in the quality workflows at my company two years ago. At first it was hobbyist — someone using ChatGPT to rephrase a CAPA description — and then teams wanted to do more: triage complaints, propose root causes, draft PSUR paragraphs. That change forced a hard question: when does a convenience tool become a GxP-relevant system that needs validation?

Below I lay out a practical, auditor-focused approach I use for any LLM/AI-assisted tool when the outputs touch GxP activities. It’s based on risk principles (ISO 14971), software lifecycle thinking (IEC 62304, GAMP 5 practices), and plain experience with notified-body and competent-authority questions. To be fair, this is a pragmatic checklist — not a white paper.

Start with scope: what the model actually does

First thing I ask: what is the intended use and is there a patient- or product-safety implication?

Human-only drafting / admin tasks (e.g., rewording SOP text) — lower risk, but still consider records and traceability.
Decision-support (e.g., suggesting a corrective action, classifying complaint severity) — medium to high risk; requires stronger controls.
Autonomous actions (e.g., auto-submitting an MDR 7 report) — usually unacceptable for GxP without full validation and strict guardrails.

In practice this means writing a short Intended Use Statement for the tool. That statement determines the rest of the validation effort.

Risk assessment shapes evidence requirements

I treat every LLM as a software component in the QMS. Per ISO 14971 thinking, map harms and their probabilities:

What can the model get wrong? (omission, hallucination, bias)
What is the consequence if it’s wrong? (regulatory non-compliance, incorrect CAPA, delayed MDR report)
What controls reduce that consequence? (human review, confidence thresholds, audit logs)

The output here is a simple risk control matrix linking each hazard to mitigation(s). In practice, auditors expect to see this matrix and the decision rationale behind human-in-the-loop rates.

Validation deliverables I prepare

When the LLM crosses into GxP territory I treat it like any other validated system. The minimum evidence package I keep ready:

Validation/Qualification Plan — scope, responsibilities, acceptance criteria.
User Requirements Specification (URS) — who uses it, what it must do, limits of use.
Functional Specification / Design Description — including model architecture if known, connectors, and data flows.
Risk Assessment — as above, with residual risk justification.
Test Protocols and Test Results — test cases against URS, edge cases, failure modes.
Traceability Matrix — URS ⇄ test cases ⇄ mitigations.
SOPs and Work Instructions — how users must use it, review expectations, escalation routes.
Change Control Record — versioning of prompts, model changes, fine-tuning events.
Training Records — who is authorised, training content, competency checks.
Monitoring Plan — KPIs, periodic re‑validation triggers, performance drift checks.
Incident & CAPA Log — evidence that issues are handled under the QMS.

Auditors will open the validation report first. If it’s thin, they’ll follow the traceability to the SOPs and training records next.

What I test — beyond “does it answer?”

Testing has to be task-focused and reproducible:

Functional correctness: test expected outputs for a representative test set (including negatives).
Robustness: feed malformed, ambiguous, or adversarial prompts.
Hallucination checks: deliberately ask for unsupported facts and confirm the model abstains or signals uncertainty.
Consistency: same prompt, different runs — check variance and document acceptable ranges.
Safety filters: confirm profanity, PII leakage, and regulated-advice filters are in place.
Human‑in‑loop behaviour: measure reviewer override rates and time-to-detect errors.

To be useful for an audit, test cases must be reproducible (seeded prompts, fixed model versions) and linked to acceptance criteria in the URS.

Data provenance and training transparency

GxP auditors care about data lineage. With closed commercial LLMs you may not have full training-set visibility. That’s acceptable if you:

Document what you do and don’t know about the model.
Assess residual risks from unknown training data (e.g., biased outputs).
Apply compensating controls (restricted scope, human review, provenance tagging).

If you fine-tune or maintain private training data, keep records: dataset descriptions, versioning, and why the data set is appropriate.

Ongoing monitoring — validation is not one-and-done

Expect auditors to ask: how do you prove the model still works in six months?

Define KPIs: accuracy for a labelled sample, rate of reviewer overrides, time-to-detect anomalies.
Set re-validation triggers: major model updates, drift beyond thresholds, new use cases.
Retain logs: prompts, responses, user IDs, timestamps, and reviewer decisions. Make these searchable — when an auditor asks for "the last ten examples the model suggested for MDR reports", you should not be doing forensic investigation.

Connected workflow and traceability matter here: a system that links prompt → model output → reviewer decision → final artefact wins audits because evidence is straightforward to extract.

What auditors typically ask — and how I answer

From experience, these are the questions I get or expect:

“What is the intended use?” — point to the URS and SOP.
“How did you validate accuracy and safety?” — show the validation plan, test protocols, and results.
“How do you detect and handle hallucinations or incorrect outputs?” — show filters, reviewer steps, escalation.
“Who can change prompts or model versions?” — show change control, permissions, and version history.
“How do you retain evidence for regulatory submissions?” — show logs, export capability, and retention SOP.
“How do you guard patient data and PII?” — show data handling and anonymisation practices.

Be specific, bring the traceability matrix, and don’t hand-wave about "the model is stable".

Final notes — operational realism

To be frank, many teams under-document early. That is costly. Start small: validate a narrow, well-scoped use case, automate evidence capture, and iterate. “Controlled assistance” with human review is the default safe strategy. Granting autonomous actions to an LLM in a GxP context is rare and requires robust evidence.

I’d rather an auditor see a well-scoped, fully traced validation for a small use case than a broad, undocumented deployment.

What narrow LLM use case in your QMS would you validate first, and what acceptance criteria would you set for it?

Interoperability and connectivity: practical compliance for connected medical devices

Priya Nair — Fri, 29 May 2026 17:29:19 +0000

I’ve owned the regulatory side of several Class IIa/IIb connected devices. The technical novelty never worried me as much as the regulatory choreography: clinical risk that appears only when your device talks to hospital systems, software updates that silently change behaviour, and notified-body requests that treat “interoperability” as a full-scope feature, not an optional nice-to-have. To be fair, the regulatory focus is correct — connectivity expands the harm envelope. In practice this means your Technical File must treat interoperability as a product feature, with the same rigour as hardware safety or software verification.

Why regulators care (short version)

Connected devices create new hazard pathways: network attacks, data corruption, unexpected clinical workflows.
Interoperability failures show up at scale: a single erroneous message can affect many patients.
Regulators and notified bodies expect evidence you considered these hazards and designed mitigations into the device and processes.

Genau: this is about safety and continuous assurance, not just one-off testing.

Standards and artefacts you will actually need

Don’t confuse “standards bingo” with readiness. The core references I use when preparing a Technical File and responding to NB questions are:

ISO 14971 — risk management, explicitly including system-level risks introduced by connectivity.
IEC 62304 — software lifecycle; include your architecture, S/W safety classes and V&V evidence.
IEC 62366-1 — usability, because human-system interfaces change when systems interoperate.
IEC 81001-5-1 (cybersecurity guidance for health software) and organisation-level cybersecurity policies.
Communication/interop specs (FHIR/HL7, DICOM, proprietary APIs) — provide protocol conformance evidence and test reports.
SBOM (software bill of materials) and vulnerability management records — increasingly asked for in audits.

What notified bodies typically ask for (and what I prepare)

From the audits I’ve been through, expect these concrete requests:

System architecture diagram showing interfaces, trust boundaries, and data flows.
Threat model and cybersecurity risk assessment mapped to ISO 14971 risks.
Test reports: protocol conformance, fuzzing/negative tests, and integration tests with target systems (or documented test harnesses/emulators).
Penetration-test summary and remediation plan; and evidence of follow-up verification.
Software update/SOTA (secure over-the-air) policy, rollback and integrity verification tests.
SBOM and supplier attestations for third-party components.
Clinical evaluation addressing connected use-cases and a PMCF plan that monitors connectivity-related incidents.
Traceability matrix mapping requirements → risks → mitigations → test cases. If you lack one of these artefacts, the NB will either ask for it or place heavy conditions on your certification.

Common pitfalls I've seen (so ist das halt)

Assuming the hospital network will make your device safe. Networks vary; you must design assuming hostile or misconfigured networks.
Equivalence claims for third-party modules that lack public verification evidence. Notified bodies push back hard here.
Testing only “happy path” interactions. You need negative tests and state-recovery scenarios.
No documented update/rollback testing. A patch that breaks interoperability is a legitimate field hazard.
Fragmented traceability. If a connectivity CAPA starts in support tickets but isn’t linked to your risk file and design change records, auditors will flag it.

Practical checklist for your Technical File (copy-paste friendly)

Architecture diagrams and interface specifications.
Risk assessment including network-related hazards and mitigation traceability.
Cybersecurity policy, threat model, and penetration-test report with remediation evidence.
SBOM and supplier cybersecurity assessments.
Interoperability and integration test reports (including negative tests).
Software lifecycle evidence (IEC 62304): requirements, design, unit/integration/system tests.
Clinical evaluation addressing connected scenarios and PMCF plan that tracks connectivity incidents.
Update policy, verification of update mechanism, and logs/audit-trail evidence.
Traceability matrix linking all of the above.

How your QMS can make this bearable

Connected devices create change — firmware updates, protocol tweaks, CVE patches. Your QMS must treat these as expected ongoing activities:

Use change impact analysis that includes “communication interfaces” and downstream system dependencies.
Link CAPAs to risk-file amendments and verification tasks — automated CAPAs are handy when you need to enforce a follow-up test after an update.
Maintain a reviewable, traceable record of supplier security attestations and SBOM updates.
Make the PMS/PSUR workflow native: connect your vigilance reports to your cybersecurity incident-response so field incidents trigger risk re-evaluation automatically.

A connected workflow that keeps traceability and reviewability front-and-centre reduces audit friction. To be explicit: this is not magic; it's process automation that prevents missed links between an incident report and a design change.

Final practical tip

Plan for interoperability tests early. Emulators and test harnesses save expensive hospital-integration time and make your NB comfortable with scope-limited external testing. And do the negative tests — recovery from malformed inputs, reconnection after network disruption, and update failures. Not glamorous, but auditors notice the gaps.

What interoperability or connectivity evidence did your notified body ask for that surprised you — and how did you close the gap?

MDR reform (Dec 2025): what the new “breakthrough” pathways mean for small medtech teams

Priya Nair — Tue, 26 May 2026 09:44:18 +0000

The reform package that circulated in December 2025 finally puts an explicit “breakthrough” or accelerated pathway on the table for certain high‑need devices. To be fair, this isn’t a magic shortcut — it’s a rejig of incentives and obligations that will matter most to small and mid‑size teams trying to get novel devices to patients without drowning in cyclic additional-data requests.

I’ve been the RA lead on Class IIa/IIb dossiers through multiple MDR cycles. The devil is, as ever, in the details: how notified bodies interpret “safety first” versus “timely access”, how manufacturers document conditional approvals, and how PMCF and PMS are enforced afterwards. Below I translate the practical consequences of the proposals and give a short checklist for teams with an audit or CE submission due in the next 12 months.

What the “breakthrough” pathway is designed to do (practical reading)

In plain terms, the proposals aim to:

Create an accelerated assessment route for devices that address an unmet clinical need or offer a substantial improvement over existing options.
Allow a more modular evidence strategy: earlier market access based on a narrower pre‑market package, with stricter and tightly monitored post‑market requirements.
Tighten the link between conditional authorisation and active PMCF/PMS obligations, with clearer milestones and reporting triggers.

To be fair, regulators are trying to balance two things: patient access to innovation and the MDR’s higher baseline for clinical evidence. In practice this means more emphasis on real‑world evidence and enforceable PMCF rather than a lower bar for initial clinical data.

Three concrete changes that will matter to RA/QA teams

Evidence becomes staged, not absent
- You can expect notified bodies to accept a smaller clinical package pre‑market if there is a robust, time‑bound PMCF plan with clear triggers and data collection methods.
- That shifts workload from pre‑market dossier assembly to post‑market systems design: PMS, PMCF, registries, and data pipelines must be ready on Day 1.
Conditional approvals mean harder surveillance
- Conditional or accelerated CE will come with contractual or regulatory milestones — expect tighter scrutiny at surveillance audits and more frequent PSUR/SSCP updates.
- In practice this means your CAPA and change‑control processes must be able to handle near‑real‑time evidence gaps and corrective actions.
Notified bodies get clearer remit — but interpretations will still vary
- The proposals attempt to clarify criteria for accelerated routes and the role of expert panels. That should reduce arbitrary equivalence rejections, granted, but local interpretation and resource constraints at notified bodies will still determine speed.
- Early, structured engagement with your chosen NB will remain essential.

What to do now — a practical checklist for SMEs

You cannot wait until the final text to prepare. Here’s what I’d prioritise this quarter:

Strengthen your PMCF and PMS design
- Map real‑world data sources (clinics, registries, device telemetry).
- Make PMCF protocols prescriptive: objectives, endpoints, timelines, interim analyses.
Put traceability where it matters
- Link clinical objectives to risk controls and post‑market actions in your Technical File (Annex II material).
- Use connected workflow tools so change control, CAPA, and risk assessments update the TF automatically.
Rehearse conditional milestones
- Draft PSUR/SSCP update templates with triggers mapped to PMCF milestones.
- Ensure contractual readiness for enhanced surveillance (supplier agreements, clinical sites).
Talk to your notified body early
- Present a staged evidence plan and ask for written expectations about PMCF milestones and audit frequency.
Invest in real‑time CAPA capability
- If you haven’t already, introduce automated CAPAs or AI‑assisted prioritisation to handle potentially higher rates of PMS signals. The emphasis must be on controlled assistance and reviewability — regulators will want to know who signed off on what.

Why this still won’t be easy

A faster pathway on paper does not mean fewer obligations. If anything, the net burden shifts:

Pre‑market work gets narrower but PMCF becomes more operationally demanding.
Notified bodies will need to police conditional approvals. If NB capacity isn’t increased in parallel, you’ll see delays at the review and surveillance stages.
EUDAMED and UDI infrastructure alignment remains critical. You may need to submit interim data earlier and more often.

From experience, these operational gaps are where small teams fail: strong technical files but weak PMS pipelines. The reform proposals recognise that, but they don’t buy you the time to build those systems after you’re on the market.

Quick note on tooling — what features actually help

If you’re thinking about tooling, focus on functionality that supports a staged evidence model:

Traceability across TF, risk assessments, PMCF and CAPA (connected workflow).
Change impact mapping visible in one place so you can show linkage between a PMCF signal, a CAPA and a TF update.
Automated CAPAs and AI‑assisted prioritisation to triage incoming PMS data — always with audit trails and human review baked in.
Templates for PMCF protocols and PSUR cycles mapped to milestones.

Those are not marketing talking points; they are the workflows that get inspected.

Final thought

The December 2025 proposals are a meaningful step towards balancing innovation and safety. For small teams, the opportunity is clearer pathways to patients — provided you can operationalise a high‑quality PMCF/PMS regime and maintain tight traceability.

Which part of your QMS would you prioritise to be ready for a conditional/accelerated pathway: PMCF design, real‑world data pipelines, or CAPA automation?

Where usability files actually fail — and how to stop firefighting later

Priya Nair — Wed, 20 May 2026 16:27:27 +0000

I’ve reviewed more than my share of usability files during Technical File audits and NB interviews. To be fair, failures rarely come from a single missing test or a badly designed UI widget. They’re almost always systemic: gaps in context-of-use thinking, weak traceability to risk controls, and an over-reliance on training or the Instructions for Use (IFU) as a “fix”. In practice this means the usability file looks tidy on paper but fails to convince a notified body (or worse, fails in the field).

The standards you really need in your corner

ISO 62366-1:2015 — the usability-engineering process and the usability file (formative + summative work).
ISO 14971:2019 — risk management, including use-related hazards; the two must be linked.
For software devices, IEC 62304 plays into usability expectations for software lifecycle and risk controls.

Notified bodies expect to see usability engineering as part of your overall risk management and Technical Documentation (Annex I/Annex II territory). When those links are thin, they ask for more evidence — and they will.

The common failure modes I keep seeing

Context of use is shallow or generic. “Clinician” or “patient” is not a use description. No environment, no user characteristics, no stressors.
Use-related hazards defined late — after design choices have been made.
Formative testing is present, but there’s no clear, pre-defined pass/fail criteria for the summative (validation) study.
Traceability gaps: you cannot point from a specific use error to the risk control, verification evidence, and IFU wording in a single trace matrix.
Over-reliance on training/IFU as the only mitigation for a design problem (not acceptable without strong justification and evidence).
Summative studies use expert or overly trained participants rather than representative end users.
Post-market surveillance and PMCF ignore use-related trends — usability complaints are siloed as “customer feedback” and never looped back to CAPA-driven risk assessment.
Change control misses “minor” UI tweaks; no re-assessment of use-related risks after release.

What notified bodies actually ask for (from my experience)

A complete usability (usability-engineering) file mapped to ISO 62366-1, with a clear trail from use-related hazards to mitigations and verification/validation evidence.
A documented justification when you rely on training or IFU rather than a design fix, and evidence that those mitigations are effective in real use.
Representative summative validation with predefined acceptance criteria — not exploratory sessions labelled as “validation”.
Evidence that usability issues feed into post-market surveillance, and where appropriate, into CAPA. Traceability is non-negotiable.

Practical fixes I apply (and recommend)

Start with a robust context-of-use matrix. For each user group list:
- physical/mental capabilities
- likely distractions and environmental stressors (lighting, PPE, noise)
- frequency and criticality of tasks
Create a use-related risk register that mirrors ISO 14971 structure. For each use error include:
- direct link to the hazard
- proposed risk control (prefer design over IFU/training)
- verification method and evidence location (document IDs)
Define summative study acceptance criteria up-front. Your notified body will ask “how did you decide it’s safe?” — answer that before the test.
Use representative users for validation. If you expect occasional users in the field, include them, not only your power users.
Treat usability findings like CAPAs: assign owners, set timelines, and close the loop with verification evidence. This is CAPA-driven risk assessment in practice.
Keep a living traceability matrix. Make the matrix the single source where user task — risk — mitigation — verification — post-market data are linked. This is where a connected workflow helps; native workflow integration between change control, risk, and usability documents reduces human error.
If you rely on training or IFU, collect real-world effectiveness evidence (observations, PMCF entries) and be prepared to show it during an audit.

Examples of small decisions that cause big problems

Changing a button label late in development without re-running a quick formative test — a subtle text change can change user expectation and lead to use error.
Moving an alarm tone to be quieter to reduce annoyance, but without checking detectability for the intended use environment.
Translating an IFU but not verifying that critical warnings remain prominent in other languages.

These are small design or process choices that become audit findings because the risk analysis and verification steps were skipped.

Final practical checklist before you lock the usability file

Context of use: fully described and referenced.
Use-related hazards: identified and risk-evaluated per ISO 14971.
Design controls: prioritised over IFU/training; justified if otherwise.
Formative + summative tests: documented, with predefined acceptance criteria.
Traceability matrix: complete and reviewable.
Post-market link: PSUR/PMCF data feeding back to usability and CAPA register.

I’ve found that if you can point an auditor to a single traceable chain from a use task to your summative results and post-market monitoring, the conversation becomes factual rather than speculative.

What’s one small change your team made to a usability process that stopped recurring use-errors — and how did you prove it worked to your notified body?

Why interoperability failures are a product problem — and how to stop firefighting later

Priya Nair — Wed, 20 May 2026 11:25:51 +0000

I’ve spent the last five years arguing with testers, architects, and notified-body assessors about why a device “doesn’t work with the hospital network”. To be fair, network oddities happen — but in almost every case I’ve seen the root cause was a design and compliance gap we could have prevented.

Interoperability isn’t just an engineering exercise. Under the MDR it sits squarely inside your device’s safety and performance case (see Annex I, General safety and performance requirements). Practically, that means connectivity decisions belong in your Technical File from day one, not added as an afterthought at verification.

Why interoperability is more than APIs

When people say “interoperability” they usually mean three things at once:

Data formats and semantics (HL7/FHIR, DICOM, device-specific payloads)
Networking and transport (Wi‑Fi, BLE, TCP/IP, gateways)
Operational behaviours (state machine, timeouts, retries, firmware updates)

A failure in any of these domains can become a safety issue. For example, a delayed message or a dropped firmware update can change device behaviour or clinical decisions. That immediately pulls ISO 14971 risk management and IEC 62304 software lifecycle workstreams into the picture.

In practice this means you must treat interoperability as a full risk item:

Define intended connectivity scenarios in your intended use and user profiles
Map hazards that specifically arise from network interactions
Include mitigations for loss of connectivity, corrupted messages, and incompatible versions

What regulators and notified bodies actually look for

Across different notified bodies the questions vary, but the theme is consistent: “How do you know this will behave safely in the real environment?” Expect to show:

A clear set of intended interoperability use cases in your IFU/labeling (Annex I)
Traceable risk controls for each connectivity hazard (ISO 14971)
Software architecture documentation showing how communication stacks are isolated and managed (IEC 62304)
Cybersecurity risk assessment and patch/upgrade strategy (refer to MDCG guidance and IEC 81001‑5‑1 principles)
Test matrices that include negative tests, flaky network tests, and version interoperability tests

Don’t be surprised if assessors ask for evidence of testing in “production-like” networks. Lab-only tests that assume perfect networks rarely satisfy them.

A practical checklist for your Technical File

I keep the following checklist in every connected-device Technical File. It’s concise enough for a reviewer and exhaustive enough for an audit.

Use-case and architecture

Intended connectivity scenarios and user stories
Network topologies considered (direct, via gateway, cloud)
Software/SW-architecture diagram indicating communication layers

Risk and safety

ISO 14971 hazard analysis items explicitly tying risk to connectivity
Failure modes (e.g., message loss, replay, man-in-the-middle)
Residual risk and rationale

Software & cybersecurity

IEC 62304 software classification and V-model traceability
Cybersecurity risk management file (threat model, mitigations, verification)
Patch/upgrade policy and rollback strategy

Verification & validation

Interoperability test matrix (protocols, versions, edge cases)
Performance tests under degraded network conditions (latency, jitter)
Usability testing for connectivity-related tasks (pairing, reconnection) per IEC 62366-1

Post-market

PMCF/PMPF plan for connectivity incidents
PSUR/SSCP items that monitor interoperable/failure modes
Vulnerability disclosure and coordinated vulnerability response plan

How to operationalise this in your QMS

If your QMS treats connectivity as “just another feature”, you’ll pay in CAPAs later. Here’s what I change when I’m asked to harden a connected product:

Make connectivity a distinct design control stream. Link requirements to architecture, tests, and risk items in one place (connected workflow). This prevents orphaned requirements that live only in Jira tickets.
Use change impact analysis for network-related changes. A seemingly trivial firmware change can affect protocol behaviour — map that through design controls before release.
Formalise supplier assurance for third-party stacks (Bluetooth stacks, cloud SDKs). Ask for evidence: CVE monitoring, security development lifecycle artefacts, and maintenance windows.
Integrate incident handling with PMS. A security vulnerability can be a safety event; ensure your CAPA and vigilance triggers are aligned.
Make traceability visible. In an audit I want to see a single trace from requirement → risk control → test → release. That reduces follow-up evidence requests and lowers audit friction.

If you use an eQMS, make these items native: traceability links, change impact mapping, and a CAPA workflow that includes cybersecurity and interoperability artefacts. Controlled assistance (AI-guided summaries, for example) is useful to surface gaps, but ensure reviewability and audit trails; regulators want to see human oversight.

A few pitfalls I keep seeing

Treating “supported” interfaces as optional. If you ship with a GUI that exposes a connectivity setting, include it in usability and security testing.
Ignoring version interoperability. Backward compatibility testing often gets cut; that’s when upgrades brick integrations in the field.
Leaving vendor-supported cloud dependencies out of the Technical File. Cloud components that influence clinical behaviour are part of the device ecosystem.

Final thought

Interoperability and connectivity are systems problems, not feature checkboxes. Build them into your risk-management and software lifecycle artefacts from the outset, and your CAPA queue will thank you.

What connectivity failure have you seen in the field that could have been avoided with better design and traceability?