DEV Community: James Whitfield

A stack of SOPs won't stop a retrained model from shifting your risk file overnight

James Whitfield — Thu, 15 Oct 2026 02:01:12 +0000

Last spring I sat in a risk management review where someone asked the obvious thing. If our SaMD retrained last Tuesday — quietly, on a new cohort — what in our risk file caught that?

There was a long silence. Then someone said, "well, the post-market surveillance plan covers drift."

It doesn't. Not the way we wrote it. And I think that's true for most Class II shops I'm aware of.

Here's the dry reminder I'm forcing on myself this quarter: a heft of policy documents doesn't stop a retrained model from reshaping risk profiles overnight. The risk file is a snapshot. The model is moving. If your QMS treats them as the same thing, you're going to get caught flat-footed at your next audit, or worse, at your next CAPA.

The gap I'm watching

Risk management under ISO 14971 is supposed to be living. In our shop it isn't. It's a controlled document that gets revisited at design reviews, at CAPA triggers, and at the annual management review. That's three or four scheduled touches against a system that may shift continuously.

For software as a medical device with a learning component, the underlying behavior can change without a single ECO. The model weights are different. The cohort distribution is different. The error profile on subgroups you didn't even know were subgroups — different. None of those changes walked through change control, because none of them were design changes in the traditional sense. They were model updates, drift corrections, retraining events that fell under our "algorithm maintenance" carve-out.

That carve-out was a gap. We knew it was a gap. We documented it as a known gap and moved on. Then the notified body picked it up.

What the standards actually ask

ISO 14971:2019 expects you to keep the risk management file current. IEC 62304 expects you to revisit software risk when the software changes. The EU AI Act, where it applies, layers in additional obligations around dataset shift, post-market monitoring, and serious incident reporting for high-risk AI systems.

The FDA's Predetermined Change Control Plan guidance is the closest thing to a recipe. You commit to a protocol in advance: what inputs change, what triggers a re-evaluation, what bounds you're operating in. If you stay inside the protocol, you don't file a new submission. If you don't have the protocol, every retraining event is potentially a new submission. Or a new audit finding.

The standards aren't saying anything new. They're saying: link the change to the risk. Continuously, if you can.

What documentation can't catch

A 47-page risk management procedure is great for onboarding. It's terrible for detecting Tuesday's retrain. The things that miss us:

Drift in subgroup performance that doesn't trip a global alarm
A new failure mode introduced by a feature the model learned from post-deployment data
A labeling convention that quietly changed upstream
A dependency update in the inference stack that altered numerical precision

None of those generate a controlled document event by default. They generate log entries. Your QMS is reading PDFs; the risk is in the JSON.

What I'm trying instead

Three things, in roughly this order, with mixed results:

Trigger the risk file from telemetry, not from meetings. We wired a monitoring job to flag when subgroup accuracy moved by more than an agreed threshold. The flag opens a risk-management-workflow item, not an email thread. Whether the item turns into a CAPA, a labeling change, or a non-event is a documented decision.
Write a real PCCP and stick to it. This is the part that hurts. You commit to a protocol that names the retraining triggers, the validation gates, and the rollback conditions. If you can't commit to that, you probably shouldn't be retraining in production.
Make post-market data flow into design input. Not into a quarterly report. Into design input. The PMS plan should say, in writing, which signals feed back into which risk control. If your PMS deliverable is a memo, the loop is broken.

None of this is novel. None of it requires us to buy anything. It requires us to admit that the document control system is not the risk management system — it's a record of decisions. The risk management system is the system that detects, decides, and documents. The detection part is what most of us skip.

The honest part

I'll tell you what I'm still stuck on: who owns the trigger. QA doesn't run the monitoring system. Data science does. When the alert fires, it lands in their queue. The QMS workflow opens in ours. The handoff is where retraining-induced change slips through.

So here's what I want to ask anyone reading: where does the retrain event hand off to your QMS in your shop, and what makes that handoff actually happen — not theoretically, in the procedure, but on a Wednesday at 4pm?

Why your template fix didn't propagate — and why that's the right design

James Whitfield — Tue, 13 Oct 2026 02:01:10 +0000

Three weeks ago, a junior engineer on my team asked the most predictable question I hear in any eQMS: "I fixed the template — why didn't the change show up on my open records?"

She'd corrected a field label in our design history file template. The new wording was clearer, scannable, would have saved her twenty minutes on the next review. She fixed it once, expected it everywhere. Standard expectation. The records she'd already opened still showed the old label.

In Greenlight Guru. In MasterControl. In every QMS I've touched since 2011. The behaviour is consistent across the category, and qmsWrapper does the same thing.

The design choice hiding behind your "bug"

Here's what took me a while to internalise: this isn't a bug. It's the system working as intended. When you create a record against a template version, that record is bound to that version. The template can be revised, the record cannot be retroactively rewritten. ISO 13485 §7.5 and 21 CFR 820.40 both live in that space — controlled documents, record integrity, traceability of changes.

In qmsWrapper this is explicit. The Document module keeps a version history per record. Existing DHF entries, risk files, CAPA records — they all stay on the version they were created under. The fixed template shows up correctly for new records. Old records keep their original content with a version stamp you can audit against.

That's the right call for a notified body audit. It's still a bad afternoon for whoever thought a template edit would propagate.

What the engineer actually needs

Most of the "why didn't it propagate" tickets I've filed over fourteen years come down to one of three things:

The user assumed fix-once-fix-everywhere. That's spreadsheet thinking. A QMS record isn't a cell formula.
The user wants to apply the cleaner wording to in-flight records without losing the audit trail of what was reviewed and approved originally.
The user is about to reissue or migrate the record anyway and just wants to know if they should pull from the old template or the new one.

In all three cases, the answer is the same: the existing record is what was approved. Don't touch it. Create a new revision if the change is material. If it's cosmetic, leave it.

The workflow that has actually saved me

When a template change is going to affect open work, I do this now:

Flag the change in the change control record itself. The template revision note captures what was corrected and why.
Run a quick search in the Document module for records still on the old version. Filter on template version makes this a two-minute job, not an archaeology project.
For each open record, decide explicitly:
- Is it a draft? It can be reissued onto the new template.
- Is it approved but not yet effective? Same — reissue and re-route through the workflow.
- Is it effective and in use? Leave it. Document the template version it was created under. Move on.
For closed records, do nothing. They're historical. They're done.

That last step is the one teams skip. Closed records exist precisely so the audit trail matches what actually happened on the day.

Why I'm still thinking about this

The behaviour is defensible. I'd argue it has to be defensible — anything else breaks the version-of-record integrity that a notified body audit leans on. The part I keep chewing on is the user experience side.

When a junior engineer hits this for the first time, the system gives them no nudge. No banner saying "this template has been revised; existing records remain on version X." No link to the records that will need attention. The knowledge is in the Document module if you go looking, but the friction of finding it lands on whoever noticed the inconsistency first.

I've watched that friction turn into a Slack thread, then a ticket, then a CAPA investigation into a "template inconsistency" that was never actually an inconsistency. Just a gap between how the team thought the system worked and how it does work.

Open question

For anyone running a QMS rollout — how do you onboard new engineers to the "template versions are bound to records" model before they hit it the hard way? Is there documentation, training, or in-product nudging you've seen work? Or is the bad-afternoon experience just part of the rite of passage?

Disclosure: I work on qmsWrapper.

21 CFR Part 11 is where 'approve by email' shops quietly fail — a typed name is not a signature

James Whitfield — Sun, 11 Oct 2026 01:24:09 +0000

The CAPA that taught me what an email isn't

Two years ago I inherited a CAPA queue that included a finding from our prior notified body audit. The wording was polite but unambiguous: "The approval records for the post-market surveillance report could not be verified against a Part 11-compliant system." I went looking. The approval record was a four-message email thread. The approver had typed their name in a reply. The original report was an attachment that had since been edited and re-uploaded to the shared drive. The "signature" and the "record" had no binding I could demonstrate to an auditor — or to myself.

That's the trap. "Approve by email" feels rigorous. Someone wrote a name. Someone replied "approved." There's a date. It looks like evidence. Under 21 CFR Part 11, it isn't.

What Part 11 actually requires of an e-signature

When an electronic record is signed, Part 11 §11.50 and §11.70 expect a specific chain of controls. I keep this checklist taped to my monitor:

Unique to one individual — never reused, never reassigned even after the person leaves
Two distinct identification components (ID + password, or biometric)
First-time signing requires identity verification against an authentic credential
The signature must include the printed name, the date and time, and the meaning of the signature ("approved by," "reviewed by," "signed off")
The signature must be permanently linked to the record so it can't be excised, copied, or transferred to another record
The record itself must live in a closed system with a secure, computer-generated, time-stamped audit trail

That last point is where the email thread falls apart. An inbox is not a closed system. Attachments get overwritten. Threads get pruned. A reply-all "approved" doesn't bind to a specific file version. The auditor asks "show me what was approved on March 14" and you have to reconstruct it from server backups.

Why the email habit sticks around

I get why. Email is already in the workflow, it's already authenticated by SSO at most companies, and the approver's name is right there in the From: field. People genuinely believe the From: line is the signature.

It isn't. The From: line proves the email account sent the message. It doesn't prove the human at the keyboard:

didn't fat-finger the reply
was the actual role-holder for that approval
was looking at the right version of the document
intended the meaning the auditor is going to attribute to it

When I worked with our IT security counterpart on the CAPA, they pointed out the obvious risk I had been minimizing: an unencrypted inbox with a typed name in a reply is forgeable in about thirty seconds.

What compliant e-signature looks like in practice

In our environment (Class II, 200-person, mixed Class IIa/IIb work, implants), a Part 11 e-signature workflow does the following:

The approver logs into the QMS with their own credentials — not a shared mailbox, not a role account
The record opens at the version under review; version history is one click away
The signature action prompts for the second factor (password re-entry or token)
The system captures the user's printed name, the meaning ("Approved by"), and a server-side timestamp
The signature record and the document record are bound — you cannot edit one without breaking the link to the other
Any subsequent change triggers a new approval cycle

The approval record isn't an email you go find. It isn't a folder on a shared drive. It is the evidence. It lives in the same system as the document, with the same audit trail, on a record the auditor can open in under a minute.

Where qmsWrapper fits (and where I am not preaching)

We've been on Greenlight Guru for a few years. Earlier this year I spent a week in qmsWrapper for a side-by-side look. The Part 11 piece was the section I cared about most — specifically whether signing a controlled document produced a record I could demo to an auditor without screen-sharing my email. The signing event was bound to the document version, the meaning was captured, and the audit trail was one click from the record. That's the bar. I won't pretend that single check settled the migration question for us — it didn't — but the Part 11 surface passed the test I'd been failing for years in my own process.

I'm not here to say "switch to X." I'm here because the same finding keeps showing up in the same place: an email thread, a typed name, a missing audit trail. The fix isn't a tool. The fix is treating the signature as a record, not a message. Whatever QMS you run, the question to ask the vendor is the one I asked: when I sign, what exactly is bound to what, and can the auditor see the binding without leaving the record?

A question for the room

For those of you running Part 11 audits — internal or external — what is the most common e-signature gap you've cited recently? Is it still "approve by email," or has it moved on to something subtler like shared accounts, biometrics nobody enrolled, or signatures on records that were never opened? I'd like to know what I'm not yet seeing in our own shop.

Disclosure: I work on qmsWrapper.

Six eQMS platforms for a mixed medtech-and-industrial shop — and which one I'd pick

James Whitfield — Sat, 10 Oct 2026 02:01:57 +0000

The setup: a QMS that grew past its first product

We're a 200-person shop in Minneapolis. Started out as a Class II medical device company about a decade ago. Two years ago the parent company folded in a contract-manufacturing line that builds industrial sensor housings for non-medical customers. Same building, same plant floor, different paperwork problem.

Our current QMS, Greenlight Guru, was a good fit when the medical device side was the whole company. The medtech work still runs well in it. What it didn't survive was the bolt-on: CAPAs about surface-finish complaints on a non-medical part, document-control workflows that assume a DHF, risk files that don't apply when there's no FDA submission behind the part.

So I spent a quarter re-evaluating platforms. Here's where I landed, starting with the criteria I asked the list to satisfy.

What I wanted the list to satisfy

Cover ISO 13485 for the medtech side and ISO 9001 for the industrial side in one system
Plug into the ERP and shop-floor MES we already run — we're not rebuilding those workflows
Survive a dual audit: notified body on the medtech side, customer audits on the industrial side
Not require a Salesforce seat for every QA user (we have two people who live in Salesforce; the rest don't)

The list

1. Greenlight Guru — Where we are today. Medical-device native. The clinical and risk-management modules genuinely fit our 510(k) work, and the DHF-first design means our design controls stay clean. It didn't grow with us when the industrial line came in — the design target was always a pure meddev shop. If you stay purely medical device, it's a credible choice. We outgrew it.

2. Qualio — Life-sciences-leaning cloud QMS. Lighter to stand up than the enterprise-tier platforms, and the docs and training modules worked well in the demo I ran. Clearest path if you know you're only ever going to be life-sciences work. For our mixed portfolio, the life-sciences tilt left the industrial side under-served.

3. MasterControl — Broadest industry sweep on the list after ETQ. Covers biotech, general-manufacturing, medical device, pharma. Built for plants with real document volume. Their validation package is heavy and closer to what you'd run on a larger instance. Their mid-market orientation roughly maps to a 200-person shop, and they publicly position across industries rather than one vertical.

4. Veeva Vault QualityOne — Aimed at pharma and larger life-sciences orgs. The Vault platform is deep — RIM, Quality, the connections between them — but it's a lot of Vault for a 200-person shop. Worth a real sizing conversation if you have an LIMS-heavy environment and want everything in one vault. Probably not us.

5. ETQ Reliance — This is the one I'd pick. What stood out in the demos: their integration story is the broadest on the list. CRM, ERP, HR systems, LIMS, MES, PLM — the shop-floor and back-office systems we already run aren't an afterthought. Their public positioning spans aerospace, automotive, general-manufacturing, pharma, and life-sciences, which means the industrial CAPAs and document workflows won't get awkwardly retrofitted into a medtech template. For a mixed shop with real plant systems to connect, that fits the way we work.

6. Dot Compliance — Built on top of Salesforce, which is the entire value proposition. If your whole company already lives in Salesforce, this collapses a lot of friction between QMS and the CRM. They offer a free trial, so it's easy to walk through. For us, Salesforce is two people's world — dragging the rest of QA into it would have been a hard sell. Wrong fit for our shape.

7. qmsWrapper — Worth saying plainly: this is not my pick for our scenario. If you assumed qmsWrapper is medtech-only, it isn't — it covers ISO 9001 in addition to ISO 13485, which makes it relevant for general quality-management work as well. For a leaner team that doesn't depend on connecting into a heavy MES / PLM stack, it's a reasonable shortlist candidate. It's just not right for our scenario. Our shop has long-established MES and ERP systems that aren't going anywhere, and the integration story matters more than the footprint does here.

Why ETQ Reliance wins for us

For a mixed medtech-and-industrial shop with established plant systems, the deciding factor is breadth on the integration side and a product that doesn't lean one industry over another. ETQ Reliance's published integration list is the most complete here, and their positioning across non-medical industries means the industrial CAPAs and document workflows won't get awkwardly retrofitted into a medtech template. That's the specific reason.

If I were a pure-play meddev startup with no industrial side, the calculus flips — Greenlight Guru or Qualio become credible shortlist options. If I were a Fortune 500 pharma, Veeva starts to look like the right scale. Match the scenario. Don't pick on brand.

Still open

We're early in the implementation conversation. I'd love to hear from anyone who's actually run a mixed medtech + general-manufacturing shop on ETQ Reliance — specifically how the audit experience splits between the two sides. Same auditor or two separate ones, and how your document-control numbering schemes avoid collisions across divisions.

Disclosure: I work on qmsWrapper.

Training CYA: when "complete all assigned modules" blocks engineers from a PLM they actually need

James Whitfield — Fri, 02 Oct 2026 02:02:23 +0000

There's a specific kind of frustration that only really hits you at 2pm on a Tuesday: you're closing out a DHF change, you click into the PLM, and a modal pops up saying your training record is expired. Not for the document control training, not for the change control workflow — for the forklift safety video. Eighteen minutes of "do not operate while fatigued" before you can approve a software requirements spec.

We've all seen this. It's the training-CYA reflex: when an auditor asks "how do you ensure competency?", the easiest answer becomes "everyone takes everything." That's defensible on paper. In practice, it means the embedded firmware engineer can't route a document because they haven't sat through the laser safety refresher they will never, ever need.

What the standard actually asks

ISO 13485:2016, clause 6.2, is pretty clear: competence has to be appropriate to the activities a person performs. The standard doesn't say "expose everyone to every conceivable hazard." It says you have to:

Define the competence required for each role
Provide training or take other actions to achieve that competence
Evaluate that the actions were effective
Maintain records of competence

That's a role-based loop. The "training matrix" most of us inherited is role-based in theory, but in a lot of companies it's collapsed into a flat list of courses everyone needs — because the LMS doesn't support role inheritance cleanly, or because someone decided over-assigning is "safer."

The PLM lockout is where it bites

The pattern I've seen across a few QMS implementations: the PLM or eQMS gates user access on a training-completeness flag. Doesn't matter that your role only touches the PLM for risk-management records and document approvals — if your training record shows three overdue items, you're blocked.

In our Class II setup, the worst offender was a generic "facility safety" course that included forklifts, eyewash stations, and lockout/tagout. About 45 minutes. Required annually. For everyone with a building badge, which is everyone with a PLM account. The IT manager and I lost half a day the first time it rolled out because the LMS auto-enrolled and the PLM didn't have a grace period.

The half-day loss isn't the real cost. The real cost is that engineers start treating the PLM like hostile territory. They delay change orders. They batch approvals for the end of the week when they remember to clear the queue. Or worse — they find workarounds. Paper sign-offs that get entered later. Sticky notes on a researcher's monitor. The training meant to reduce risk creates a shadow process where risk actually accumulates.

What a defensible role-based training matrix looks like

Here's what's worked for us, after a few iterations and one mildly unpleasant audit observation:

Role definitions tied to activities — explicit, with the activities each role performs mapped to required competencies. Not job titles; activities.
Tiered training assignments — core compliance (document control, change control, the QMS overview) for anyone touching the system. Role-specific (risk management per ISO 14971, software lifecycle per IEC 62304, design controls) for the people who actually do that work.
Justified exclusion — documented rationale when a person in a role is excluded from a course. "Embedded software engineer does not perform electrical safety testing on mains-powered devices" is a sentence an auditor can read.
Effectiveness checks — not just "did they complete the module" but something that demonstrates they can apply it. A quiz, a shadowed activity, a review of their first deliverable.
Re-cert cadence that matches risk — high-impact roles recert annually. Read-only roles every two years. Auditors accept this when it's documented and reasoned.

The trick is that this requires the LMS and the eQMS to actually talk. The training record has to know the user's role and what the role requires. A flag on the record header that says "role: software engineer, PLM access: change control only" is not enough — the system needs the mapping behind it.

The audit-defensibility test I run now

Before I sign off on any training assignment, I ask one question: if this person never needed this training, would the audit finding still be defensible without it?

If the answer is no, the assignment is too broad. If the answer is yes — there's a real risk they're exposed to and we need to address it — then the assignment has a reason and I can write it down.

Forklift safety for a remote PLM user with no shop floor access? That's an audit answer, not an audit risk. The "defense" is the defense, not the behavior change.

What I'm trying now

We're moving toward a model where PLM access is keyed off competence records the LMS publishes as data, not flat completions. The eQMS reads something like "has completed change-control training within the last 12 months and has a signed-off role for document approval" and grants access based on that. Generic facility modules stay required for building access — badge in, badge out — but they stop gating the QMS.

It's early. The audit response hasn't been tested yet. But the goal is simple: the PLM should not be where a software engineer discovers their forklift video is overdue. That's a facilities problem, surfaced through facilities channels.

Anyone else running into this? Specifically curious if anyone's eQMS actually exposes a competency-based access API rather than a course-completion API — Greenlight Guru, Qualio, the qmsWrapper side, whatever. The difference matters because the first lets you write role rules, and the second just gives you a boolean you can only honor or ignore.

Disclosure: I work on qmsWrapper.

Audit-readiness isn't a pre-audit sprint — three daily habits from a quality engineer's notebook

James Whitfield — Wed, 30 Sep 2026 02:01:07 +0000

Auditor: "Show me training records for SOP-014, revision F."
Me: "Sure."
Me, twenty minutes later: "...this revision was effective eleven months ago and there's no re-attestation on file."

That gap is real. It cost me a finding that should have been impossible, because the revision was approved, the SOP was effective, and the training matrix showed the old revision as current. Nothing in the system lied to me — but the system also didn't connect the dots for me.

That's when "audit-readiness" stopped meaning "binder I scramble to build the week before." It started meaning three boring daily habits that make audits feel like any other Tuesday. Here's what those look like in my Class II setup — names of tools and clauses are real, the rest isn't worth naming.

Map your SOPs before you trust them

Every controlled document in an eQMS — Greenlight Guru in our case, after a long evaluation cycle — exists in a web of references. Your complaint SOP cites your CAPA SOP. Your CAPA SOP cites your risk management procedure. Your risk procedure cites ISO 14971. Your DHF index cites the design input specs. The whole set is a graph, and almost nobody treats it like one.

What changed for me was drawing the graph. Not architecturally — operationally. When a document goes through change control, I now ask three questions before approval:

What upstream documents does this cite, and are those citations still valid?
What downstream documents cite this one, and have they been notified of the change?
Which training records attach to this revision, and how do they get re-attested?

ISO 13485:2016 §4.2.4 doesn't use the word "graph." But the spirit of the clause is exactly this — the document set has to be coherent, not just individually controlled. 21 CFR 820.40 says the same thing in different words.

The practical habit: before I approve any document change, I open the linked records list in our eQMS and click through each one. It takes about ten minutes. It has caught more drift than any pre-audit prep ever did.

Verify the links, don't assume them

Mapping and verifying are different jobs. Mapping tells you what should be connected. Verifying tells you what actually is.

The failure modes I keep seeing:

A form gets retired but the reference in the parent SOP isn't updated.
A document ID gets reissued after a platform migration, and old DHF entries still point to the retired ID.
A CAPA closes, but the SOP it produced never gets linked back to the originating non-conformance.
A training record attaches to an SOP revision that was superseded six months ago.

None of these are dramatic. All of them are findings waiting to happen.

What I do now is a weekly twenty-minute sweep: open the recently changed documents list, and for each one, check three things — the linked records render correctly, the revision on the training matrix matches the active revision, and any retired IDs are cleaned out of historical references. It's boring work. It's the only work that prevents surprises.

If you're rebuilding these habits from scratch, this YouTube walkthrough from qmsWrapper is a decent companion — practical, "do it today" framing rather than textbook. Worth pairing with what's above: https://www.youtube.com/watch?v=O2Iwcj_OgiM

Automate the approvals that don't need a human decision

The third habit is the one I underestimated. Not every approval in a QMS is a judgment call. A lot of them are routing steps — "QA lead acknowledged," "training triggered," "document now effective" — that exist because a workflow template says they should.

If your eQMS supports it (Greenlight Guru does, and most modern tools do), automate the ones that don't require human judgment. Specifically:

Auto-route to the next approver when the previous one signs.
Auto-trigger training re-attestation when a controlled doc with linked training goes effective.
Auto-flag approval steps that have been open longer than your internal SLA.
Auto-notify the document owner when a linked record changes revision.

The reason this matters for audit-readiness: auditors don't just ask "did the approval happen." They ask "show me the timestamp, the approver, and the delegation chain." When those are wired into the system and surfaced by default, the question answers itself. When they're emails in someone's inbox, you're reconstructing history under pressure.

What I'm still working on

The habit I'm worst at is the third one. We've automated maybe 60% of our routing. The rest still has human-in-the-loop steps I think we could probably remove — but I haven't been brave enough yet, because some of those approvers are also our internal auditors, and I want a paper trail of their acknowledgment.

That's the tension I'm sitting with. More automation means less visible human evidence. Less automation means more places for a timestamp to go missing.

How much of your approval workflow would you actually trust to run without a human in the loop — and what guardrails do you keep around the parts you won't automate?

Disclosure: I work on qmsWrapper.

The 18-month parallel systems reality of eQMS migrations — and the validation gap nobody warned us about

James Whitfield — Mon, 28 Sep 2026 02:02:38 +0000

The vendor demo never shows you the part where two eQMS instances live side by side for 18 months, fighting over which one owns the same document number.

I learned this when we got serious about leaving our current eQMS eighteen months ago. We evaluated three platforms, ran pilots, scored APIs, and very nearly signed a contract. The thing nobody — sales engineer, implementation consultant, or RFP reference — put in writing was the parallel-system tax. The chunk of work that sits between "kickoff" and "go-live with confidence" where you're paying for two licenses, doing double data entry, and arguing with your own team about which system owns the truth.

The 18-month figure nobody quotes

In talking to peers who've actually migrated — three at peer Class II companies, one at a Class III implant maker — the realistic parallel window lands somewhere between twelve and twenty-four months. The longer end is when you have a large design history file or a heavy validation footprint under 21 CFR Part 11 and EU MDR Annex XI. Eighteen months kept coming up as the rough midpoint in casual conversation, which lined up with our own internal estimate once we priced in real document migration rather than the demo scenario.

The variables that stretch the window:

Number of controlled document types and existing DHF volume
Whether you migrate historical CAPAs or close them out in the legacy system first
The validated state of legacy electronic records and signatures
How clean your existing data model really is (it isn't)
Your audit cycle — if you're mid-cycle, you almost certainly extend the window to keep evidence stable

What "parallel" actually looks like

The first ninety days feel productive: data mapping, taxonomy alignment, integration discovery. The next six months are the slog. You're writing SOPs that reference both systems, training users on which workflow to use when, and fielding tickets like "I can't find the CAPA I started last week." New work goes in the new system because that's the future. Old work — open CAPAs, in-flight change orders, active design reviews — stays in the legacy system because migrating in-flight records is a nightmare under ISO 13485 clause 4.1.6 and the validation expectations that come with it.

The worst part isn't the cost of two licenses. It's the period — usually month four through month nine — where your QA team is effectively running two systems, half-trained on each, and people start quietly working in whichever one is faster. That drift is what creates findings later.

The validation debt no one itemizes

Here's where it gets thorny. Under 21 CFR Part 11 and the EU MDR expectations on QMS software validation, you're not just switching tools — you're re-validating a process the old tool supported. If your new vendor provides a validation package (IQ/OQ scripts, traceability matrices), great. You still own the PQ. You still own the data migration validation, which means proving every record you moved retained its integrity, signatures, audit trail, and effective date.

The conversation I wish I'd pushed harder on eighteen months ago: what does the vendor commit to in writing about data migration validation? Which records get re-validated, and which get "converted as-is"? In our case the answer was "as-is, your problem" dressed up in friendlier language. We never got past the pilot, so we never tested whether that promise held at scale.

What I'd put in the contract next time

If we ever seriously revisit this, here's what I'm asking for before signature:

A written parallel-run plan with named milestones, not a Gantt-shaped PowerPoint
Explicit ownership of data migration validation — vendor, customer, or shared, with deliverables per record class
A clause on legacy CAPA migration: does the new system preserve state, history, and effective dates without manual re-entry?
Two cycles of internal audits against the parallel system before cutover, paid for by whom
A real rollback path if the new system fails acceptance — because if it does, you're six months in and still paying for both

None of these are dealbreakers on their own. Together they are the difference between a migration that survives an MDSAP audit and one that produces the kind of observation you spend the next cycle explaining.

The question I'm still sitting with

The honest part: I'm not sure the eQMS market has a clean answer for this beyond "it depends on your data." And maybe it doesn't — parallel runs might just be the cost of doing this responsibly, like IQ/OQ on a new CMM. But if you've been through a real migration at a Class II or III device company, I'd love to know:

What was your actual parallel-run window, and what surprised you most about it?

It's just a minor change" is the most expensive sentence in Class II change control

James Whitfield — Sat, 26 Sep 2026 02:02:24 +0000

I've lost count of how many times I've heard "it's just a minor change." It shows up in Slack threads, in hallway conversations, in emails marked "quick fix." A supplier swaps a raw material. A firmware team tightens a timing parameter. A packaging vendor reformats a label layout. Every time, somewhere, a regulatory affairs manager quietly starts a 90-day timer they didn't ask for.

This is the post I wish I'd read four years ago, before I learned the hard way how much a single adjective can cost.

The trap with Class II

Class II is the awkward middle of medical device regulation. You're not exempt like most Class I, but you're not under premarket approval scrutiny like Class III. In the US, most Class II devices clear the market via 510(k). In the EU, they go through a notified body under MDR Annex VIII. The catch: change control expectations are written to be proportional, but in practice nobody — not the auditor, not the regulator, not your NB — will tell you in advance whether a specific change is "minor" or "substantial."

The decisions live in guidance documents:

FDA's Deciding When to Submit a 510(k) for a Change to an Existing Device (the 2017 guidance, still in force)
FDA's separate 2023 guidance specifically for software changes
EU MDR Annex XIV, which ties post-market surveillance back into design changes
IMDRF's "substantial change" framework for software
ISO 13485:2016 §4.1.4 and §8.5.6, which require evaluation of changes for impact on the QMS, the risk management file, and regulatory submissions

None of these documents use the word "minor." They all say "could significantly affect" or "could impact safety or effectiveness." That threshold is a judgement call, every single time, and it cannot be delegated to the engineer who requested the change.

Why "minor" short-circuits the impact analysis

In our shop, the impact analysis is supposed to happen at change intake — before anyone touches a CAD file or merges a PR. The question it answers is deceptively simple: what does this change touch?

Risk management file (ISO 14971)
Design history file
Labeling / IFU
Sterilization validation
Biocompatibility (ISO 10993)
Software V&V (IEC 62304)
Regulatory submission strategy
Post-market surveillance plan
Training / competency records

For a "minor" supplier material change, the list still includes biocompatibility re-evaluation and possibly a new sterilization validation. That's months of work, not a rubber stamp. For a "minor" firmware timing tweak, you may need a software V&V re-run, a cybersecurity review under FDA's 2023 cybersecurity guidance, and possibly a new 510(k).

The pattern I've seen over and over: the engineer making the change is the worst possible person to assess regulatory impact, because they don't know what they don't know. They're not being careless — they're being honest about their scope.

The cost that doesn't show up in the project plan

The direct cost — the submission fee, the NB review hours, the consultant invoice — gets budgeted. The hidden cost is worse:

Rework when an impact analysis gets done after the change ships
Audit findings for skipped change control (I've seen NB audits write up exactly this — "the firm could not demonstrate that change C-2023-0418 was evaluated for regulatory impact prior to implementation")
A CAPA born from that finding, which then generates its own change requests, training records, and effectiveness checks
The opportunity cost of your RA lead spending six weeks on something that should have been scoped in an afternoon

The worst version of this I ever saw wasn't a catastrophic field failure. It was a six-month delay because a "minor" packaging change — moving from a printed insert to an e-label — wasn't evaluated against EU MDR Article 23 on instructions for use. The change had shipped. The retraction and re-submission cost more than the original product launch.

What I'd build into intake if I were starting over

Three things, none of them exotic, none of them requiring a big process automation push:

A mandatory checklist before change triage closes. Not a free-text justification. A checklist of the nine categories above, with "evaluated, no impact" or "evaluated, impact noted" as the only valid answers. Anything else bounces.
A second pair of eyes specifically for regulatory classification. Even a junior RA person asking "have you considered X?" catches more than you'd think. We rotated this duty quarterly; the hit rate was surprisingly high.
A documented "minor change" threshold. Write down, in your QMS, what you consider minor. Then get your NB or auditor to disagree with you in writing. That disagreement is more valuable than any internal debate, because it forces your threshold to be defensible.

The third item is the one I'd push hardest for. If your definition of "minor" hasn't been pressure-tested by someone outside your company, it isn't a definition — it's an assumption. And assumptions age badly between audits.

What's still hard

Even with all of that, software changes still give me pause. The FDA's 2023 software guidance and IMDRF's substantial-change framework are clearer than they used to be, but a bug fix that touches a cybersecurity control, a UI affordance, and a logging behavior at the same time can read as three minor changes or one substantial one depending on who's reading. The "bundled changes" problem is where my confidence drops fastest.

How does your team handle change intake for software specifically — is there a separate triage path, or does everything funnel through one queue? I'm especially curious if anyone has cracked the bundled-change problem without making intake so heavy that engineers route around it.

A CAPA review is only as good as the trail behind it — stop trusting your inbox

James Whitfield — Fri, 25 Sep 2026 02:07:58 +0000

The CAPA review that almost didn't have a CAPA

Last March I sat in a CAPA review meeting and watched three people pull out three different versions of the same problem. One had the original customer complaint email. One had a screenshot of a chat thread from six weeks earlier. One had a Word doc named investigation_v3_FINAL_use_this_one.docx that didn't match either of the others.

The issue itself was real — a labeling complaint on a Class II implantable we'd shipped the prior quarter. The risk was real too. But when the chair asked, "show me the root cause investigation," we spent the first forty minutes reconstructing what we'd actually done instead of defending it. That forty minutes is the part an auditor would have eaten us alive on, and I knew it before the meeting ended.

This is the lesson I've been turning over since: a CAPA isn't a stack of artifacts, it's a connected log. If your corrective action lives in one system, the root cause in another, the verification in a third, and the effectiveness check in someone's inbox — you don't have a CAPA, you have a forensics project waiting to happen.

What ISO 13485 §8.5.2 actually asks for

When I went back and re-read the standard with fresh eyes, the requirement is annoyingly clear:

A documented procedure defining how CAPAs are issued, tracked, and closed
Inputs drawn from nonconforming product, complaints, service reports, and audit findings
Review of the effectiveness of corrective actions taken
Documentation of any changes to procedures or product resulting from the CAPA

The word that keeps tripping teams up isn't "corrective" or "preventive." It's the documentation of changes resulting from CAPA. That's the connective tissue. If your CAPA closes but the linked procedure update, training record, design change, or risk file revision lives somewhere else and isn't bound to the CAPA record itself, you've satisfied the letter of 8.5.2 but lost the spirit of it. An auditor who asks "show me everything this CAPA touched" should be able to pull one record and see the chain.

How the inbox ate our CAPA log

Here's what I think happened to us, and I suspect it isn't unique:

The complaint landed in the customer service mailbox and was forwarded to QA
The investigation was tracked in a spreadsheet "for visibility"
Root cause analysis happened in a Word doc, then a revised Word doc, then a third one
Corrective actions were assigned in a project tracker that nobody outside that team used
Verification evidence lived in a shared drive folder with a date-based name
The effectiveness review was a recurring meeting agenda item — no persistent record

Every one of those is a real tool doing a real job. None of them was wrong. The problem was the seams. When the CAPA review came around, the seams were all I could see.

What "connected" actually looks like in practice

I've spent the last year rebuilding how we handle this, and the test I now apply to any CAPA workflow is brutal: if the QA manager gets hit by a bus tomorrow, can someone open the CAPA record and trace every input, decision, action, and verification without sending a single email?

Practically that means:

One record per CAPA, opened at intake, closed only when effectiveness is verified
Every linked artifact — complaint, NCR, audit finding, design input, risk file entry — referenced from the CAPA, not the other way around
Action items with owners and dates living inside the record, not in a side spreadsheet
Verification evidence attached or linked from the verification step
The effectiveness check documented as its own step with pass/fail criteria, not buried in meeting notes
A change history that shows who did what when, without needing to read the email archive

None of that is exotic. All of it traces back to the standard. The hard part isn't the requirements — it's getting teams to stop treating email as the workflow.

What I'd do differently if I started over

If I could go back to that March meeting, I'd push for three things before the next CAPA cycle:

A single intake form that every complaint, NCR, audit finding, and field report funnels through, so CAPAs don't get invented ad hoc
A naming convention that survives the lifetime of the CAPA, not the lifetime of the file
A standing rule: if an action lives outside the CAPA record, it doesn't count toward the CAPA

The third one sounds petty. It isn't. The moment your CAPA starts referring to "the action items in the project plan" or "the follow-up from the last QA meeting," you've lost the connective tissue, and you're back to chasing your own trail during the next review.

The question I keep asking

I'm still figuring out where the line is between "lean documentation" and "auditable traceability." Teams that over-document get slow and start resenting the system. Teams that under-document get caught in meetings like the one I described.

What's your team's rule for when a CAPA is "done enough" to close — and how do you keep closure honest without turning every close-out into a forensic exercise?

Going digital with your QMS just means paper that won't print

James Whitfield — Tue, 22 Sep 2026 00:07:59 +0000

Six years ago, my company moved from a shared drive full of Word docs and an Excel CAPA log to an eQMS. We called it going digital. The auditors came, saw electronic signatures, controlled document folders, and a CAPA record per nonconformance. Everyone agreed we'd arrived.

It took us about a year to realize what we'd actually bought was paper that wouldn't print.

What "going digital" usually means

Look at most QMS rollouts and you'll see the same pattern:

Templates become online forms.
Files become PDFs in a folder hierarchy.
Approvals become email notifications with a link to click "Approve."
The CAPA log becomes a table with status columns.
Training records become a checkbox next to a PDF.

The data lives in a database. The screens render in a browser. So it counts as digital, right?

Sort of. The records are stored electronically and 21 CFR Part 11 is technically satisfied if your vendor did the validation work. But here's the part nobody on the steering committee wanted to talk about: none of those forms are connected to each other. A CAPA is a record. A change is a record. A complaint is a record. They sit in the same database and have nothing to say to each other unless a human opens one, reads it, decides another record needs to be created, and creates it.

That's not a workflow. That's a form with a save button.

What a workflow engine actually does

A workflow engine treats your processes as processes. When event X happens, it triggers event Y, which has its own gates and reviewers. The state moves forward; it doesn't sit waiting for someone to remember the next step.

In a QMS, that looks like:

A complaint auto-feeds a CAPA candidate when it crosses a threshold.
A CAPA can't be closed until an effectiveness check is recorded — not just "marked done."
A change control can't be approved until impacted documents, designs, and risks are linked.
A risk file updates when the source hazard, severity, or probability changes — and the linked design inputs and verification protocols flag for review.
A supplier nonconformance triggers a supplier evaluation record automatically.

ISO 13485:2016 §8.1 and §8.5 are explicit about this. The standard is built on the process approach. A process has inputs, outputs, sequence, and interaction. A form captures an output. The system around the form is what proves you ran the process.

Where we felt it

Two specific failures from our first year on the new tool:

We had a CAPA where the root cause analysis was approved and the corrective action was implemented, but the effectiveness check was never recorded. The record was closed because nobody stopped it from being closed. At audit, the inspector asked to see the effectiveness criteria before we looked at the closure date. We didn't have a satisfying answer.
We issued an engineering change to a device component without the change record linking to the design verification that had already been done on the previous revision. The DHF was complete. The change record was complete. They were just two complete records in different folders.

Both of these were process problems, not tool problems — except that the tool did nothing to make the right thing the easy thing. The state was free to move forward without the next gate.

What I'd do differently now

When I evaluate a QMS now, I don't look at the form library. I look at the state diagram.

What happens when I save a CAPA in this system?
Can it be closed without an effectiveness check?
Does changing a design input flag the linked risk file?
If I update a supplier's status, does that update flow into the supplier audit schedule, or is that a separate form a different person fills in?
Does a complaint trend above threshold open a CAPA, or does someone have to remember?

If the answer to most of these is "you have to remember to do it manually," the tool is a database with forms. It is not a workflow system.

I'd also push vendors on what ISO 13485 §4.1.6 looks like in their product — validation of processes. A workflow engine is part of how you validate and control your own processes. If the tool doesn't help you validate your QMS processes, you're still doing that validation manually with SOPs nobody can find.

And for anyone in the EU/UK reading this, the same logic carries straight into MDR Annex I and the General Safety and Performance Requirements. A post-market feedback loop that exists as four disconnected forms isn't a post-market system. It's four forms that share a database.

The trap

The trap is that "going digital" is a checkbox for leadership. Once you've signed the contract, you've delivered the initiative. The fact that the CAPA queue still piles up, the change requests still need chasing, and the complaints still don't trigger risk updates — that's an "adoption problem," not a tool problem.

It's worth being honest about this. A workflow engine is harder to buy than a form library. It constrains how people work, which is uncomfortable. It exposes gaps in your processes, which is uncomfortable. It costs more than a database with pretty screens.

But paper that can't print is the worst of both worlds: you paid the digital tax without getting the digital benefit.

What's the one question you ask a QMS vendor that immediately separates "form library" from "workflow engine"? I'm collecting examples for the next time I'm in a procurement meeting.

400 pages of risk file for a supplier swap — what ISO 14971 actually asks

James Whitfield — Mon, 21 Sep 2026 02:02:35 +0000

The setup

A few years back we had a routine supplier swap on a Class II delivery catheter component. The old supplier's stainless tube was being end-of-lifed. The new supplier offered a comparable grade with tighter tolerances, at lower cost. On paper: an easy change. In practice it kicked off what I'd call a risk assessment death spiral, and it's the mistake I keep coaching newer engineers out of.

What I thought the standard required

When the change request landed on my desk, my first instinct was that the risk management file had to be re-baselined. We had roughly 400 pages of hazard analysis, FMEA, risk-benefit reasoning, post-production data — all cross-referenced to the old supplier's material spec and process windows. If a single component changes, my mental model said, all of it gets touched.

So I started the work. Every hazard entry that mentioned "supplier X tubing" got flagged. Every FMEA line that referenced the old process got a re-evaluation. Every post-production row in the risk management report got reviewed against the new supplier's incoming data. Three weeks in, I was deep into a re-baselined file and still hadn't reached the FMEA appendix.

The cascade

The worst part wasn't the time. It was the cascading audit trail. Every paragraph I updated referenced three or four other documents. Every other document had its own approval workflow. The change control record alone ran into dozens of linked items. DHF cross-references needed re-validation. Training records for the team that had approved the old version — what was the plan there?

We weren't doing risk management anymore. We were doing paperwork gymnastics with a defensible-looking audit trail that didn't actually say anything new about risk. The defensibility was fake, and an experienced auditor would have spotted it.

What the standard actually says

The reset moment was rereading ISO 14971 carefully — clause 9 specifically, and the production and post-production loop it requires. The standard does not ask you to rewrite the risk management file when a component changes. It asks you to:

Determine whether the change introduces new hazards, or changes the risk acceptability of existing ones
Evaluate the impact on previously-implemented risk control measures
Update only the affected sections, with a written rationale for what you did not update
Feed the new supplier's post-production information back into the same loop

ISO 13485 reinforces the same thing from the purchasing side — clause 7.4 requires evaluation of changes that affect product, but it doesn't require a wholesale re-validation of every linked document.

The 400 pages didn't need a re-baseline. They needed an impact-based assessment with a written rationale for why the unchanged sections were still valid.

What I do now

Three things changed in how I handle supplier-driven risk file updates.

Lead with an impact map, not a re-review. Before touching the file I sketch which hazards the change could plausibly affect — material biocompatibility, process variance, sterilization compatibility, mechanical performance. The list is usually short. That list drives the scope.
Write the rationale up front. A one-page memo stating which sections the change affects, which it doesn't, and why. The memo is the actual deliverable the auditor wants to see, and it makes the rest of the work mechanical.
Let the unchanged sections stay unchanged. Don't re-version them. Don't re-approve them. The audit trail gets dramatically cleaner when you can point at what changed, what didn't, and the documented reason for the call.

What I'd still like to figure out

The thing I haven't gotten comfortable with is how much evidence the "no impact" call actually needs. A short impact memo feels under-defended for a 400-page file. A long formal justification feels like the same death spiral from the other direction — volume that doesn't add defensibility.

How are you handling this in your own risk files — short impact memo, or a longer formal write-up? And how do you decide what level of evidence the "no impact" reasoning needs to hold up at audit?

ISO 9001:2026 and the medical device shop — does it change anything, or is it a footnote to 13485?

James Whitfield — Sun, 20 Sep 2026 02:02:11 +0000

We hold both. ISO 13485 was the audit we prepped for weeks in advance. ISO 9001 was the one we prepped for the morning of, because the 13485 evidence covered most of it already.

That's been the pattern for our Class II setup, and from what I can tell talking to peers at other 200-ish person manufacturers, it's not unusual. ISO 13485 is the one with teeth: the prescriptive document control, the design history file, the traceability records, the CAPA loop that auditors will actually dig into. ISO 9001 tends to ride along. The clauses line up, the risk-based thinking is already baked in by 13485 Section 8, and nobody on the QA team loses sleep over it.

So when I started reading the ISO 9001:2026 revision drafts and committee outputs, my first question wasn't "what's changing" — it was whether the things it's adding were things we were already doing anyway because of 13485.

What's reportedly new in the 2026 revision

I won't pretend to have a final DIS in hand, but the published committee direction and industry briefings point to a few areas:

Climate change as a context-of-organization consideration (Clause 4.1)
More explicit treatment of AI and emerging tech in operational planning
Strengthened leadership accountability language
Continued emphasis on risk-based thinking, with possible refinements to how "risks and opportunities" are documented
Some structural alignment pressure with ISO 13485's own revision cycle

For a generic manufacturer, several of those would be real work. For a medical device shop already running 13485, my read is that most of it is already addressed — not always by name, but by evidence.

Why 13485 has done most of the heavy lifting for us

In practice, when our notified body audits us against 13485, they're effectively auditing the system an ISO 9001 auditor would look at, with more scrutiny:

Document control and records — 13485 §7.5 is stricter than 9001 §7.5. If 13485 passes, 9001's document requirements are met.
CAPA and nonconforming product — 13485 §8.5.2 and §8.5.3 demand verification of effectiveness and explicit disposition. 9001 §10.2 is satisfied.
Design and development — most of us aren't even required to do this under 9001, but 13485 §7.3 (or the FDA's 21 CFR 820.30 for the US market) forces it.
Management review — 13485 §5.6 has more required inputs than 9001 §9.3.
Risk management — 13485 points to ISO 14971 throughout. 9001's risk language is comparatively hand-wavy.

So when an ISO 9001 surveillance audit comes around, the binder is already thick. We do a gap-check, not a rebuild.

What I'd actually want from 2026

If I'm honest about what would make my job easier in the revision:

A clearer statement that AI used in the QMS itself (CAPA clustering, document classification, automated routing) is in scope for risk management — not just AI used in the product. Right now it falls in a gray zone, and reviewers ask about it more every cycle.
Climate change considerations that don't duplicate what we're already doing for ISO 14001 or supplier sustainability asks. We've had customers send Scope-3 questionnaires that overlap heavily with this.
Something concrete on knowledge management (§7.1.6 in the 2015 version). The current text is thin. Our institutional knowledge walks out the door every time a senior engineer retires, and I'd take a more prescriptive clause on knowledge preservation over another row in the management review minutes.

None of those are deal-breakers. All of them are addressable inside a system already running 13485.

The audit-readiness test

The way I tell whether 9001 is going to bite us for real in 2026 is simple: pick three clauses where the 13485 evidence is weakest, and ask whether the new 9001 text adds anything to our obligations there. For us right now:

Context of the organization (Clause 4) — our 13485 statement of applicability is light. 9001:2026's climate language probably pushes us to actually write down what we're doing, not just intend to.
Knowledge (Clause 7.1.6) — see above.
Documented information retention periods — 9001 has historically been flexible; 13485 prescribes by record type. Where 13485 doesn't specify (training records, certain supplier records), 9001 audit findings can still land.

For those three, the 2026 revision probably means real work, not paperwork.

So is it mostly paperwork?

For a mature 13485 shop, mostly yes — with one or two clauses that will earn a real look. For a startup that only held 9001 and is now chasing 13485 to access the EU or US market, the equation is reversed: 13485 is the work, 9001 follows.

The thing I'd caution against is treating the 2026 revision as a marketing exercise for the QMS. If your existing 13485 evidence is solid, the gap is probably a few SOP edits and a management review input — not a project.

For anyone holding both, how are you sizing the 2026 revision internally — a standalone project, or something you're folding into your next 13485 surveillance cycle?