DEV Community: James Whitfield

The change record wasn't wrong. It was filed against the wrong project — and it paused our release.

James Whitfield — Tue, 10 Nov 2026 03:02:01 +0000

At 22:40 on a Thursday, eleven days out from a release train, I opened a change record that had been approved three weeks earlier — by two competent people who had both done exactly their job.

Nothing about the record looked wrong. The change was a supplier substitution: a new adhesive lot in the enclosure assembly for one of our Class II device families. The supplier sent the notification, engineering wrote a sensible justification, QA checked the chemical characterization package, and the change went through review and approval without a hitch.

What was missing was a sentence nobody could find: what does this change touch?

The scope that wasn't there

The request had been created against a site-level quality bucket rather than the device program it actually affected. With three programs in flight, whoever filed it didn't want to guess wrong, so they parked it somewhere generic.

Generic is where dependencies go to disappear. Once it was approved, no downstream process picked it up:

The ISO 14971 risk management file for that device family never received the new lot data.
The DHF index didn't pull in the updated supplier qualification record.
The incoming inspection instruction kept the old lot acceptance criteria.
The training assignment for the receiving inspector went to a site group nobody read.

We caught it during release readiness review because I was walking the open change queue against the release checklist. The checklist itself was fine. It was manual, and it was only ever populated for changes scoped to a product. Site-level changes were assumed to be product-agnostic. That assumption cost us eleven days and a re-review of the supplier's process capability data.

What the standard actually asks for

Here's what I had to sit with afterwards: ISO 13485:2016 never asks for a project.

Clause 7.1 talks about product realization planning. Clause 7.3.9 asks that changes to the product or the QMS be reviewed, verified and validated as appropriate, and documented. Clause 7.5.6 asks that changes to documented information be identified, reviewed, revised and approved. ISO 14971 asks that you evaluate the change against the risk management plan. And for a supplier substitution on a cleared device, there's a separate question about whether the change needs a new 510(k).

None of that language requires a project tree. What it requires is that you can demonstrate, years later, that every affected output was considered and that the right people signed it. A project scope is simply the cheapest mechanism I've found for making that demonstration possible — it turns "did we check everything?" from a memory test into a query.

That distinction matters when someone asks me to justify the rule. The rule isn't in the standard. The auditability is in the standard. The rule is just my implementation of it.

What I changed

No scope, no approval. A change record must carry a device or program scope before it can enter an approver's queue. If it genuinely spans programs, it gets a parent scope with linked child records instead of a generic bucket.
The release impact assessment became a query, not a checklist someone remembers to open.
A weekly "orphan sweep." Any open change with a blank scope, or a scope that matches no active program, gets reviewed by hand. Not elegant, but it's the only thing that catches the leftovers.
Approver training now says the quiet part out loud: approving the justification is not the same as confirming the downstream outputs were updated. Two of my reviewers told me afterward they'd genuinely never been told that.
"Unscoped" stopped being a valid state, including for site-level work. If it isn't attached to a product, it's attached to an owner, a date, and a defined scope like a process improvement — but it still has to live somewhere with a name.

The 22:40 review was the symptom

The late-night part sounds more dramatic than it was. Mostly it was fatigue.

The review was scheduled late because the release gate sat outside the contract manufacturer's working hours in their timezone, and because the documentation checks had been slotted after engineering sign-off rather than planned alongside it. That's the same problem wearing a different hat: when work is scoped, it has an owner, a duration, and dependencies, and it appears in a plan. When it isn't scoped, it appears as a surprise at 22:40.

I also want to be honest about what we didn't solve. Our project tree is not the DHF index, and if we let the two drift into parallel truth sets, we'd have the original problem with better metadata. We still have open changes sitting in the site bucket that I review by hand each month. It's administrative debt, and I've stopped pretending otherwise.

What I'd still change

If I ran this again, I'd put documentation impact on the release plan at the same level as verification activities, rather than as a gate that happens afterwards. I'd also run a monthly query for changes approved in the last 90 days with no downstream linked records — not because it proves a problem, but because it's the question that would have caught this one, and it takes about ten minutes.

For those of you running mixed portfolios: how do you scope a change that genuinely affects more than one product without the structure turning into a second index that drifts from the DHF?

The missing link: quality events lose their risk rationale before effectiveness review

James Whitfield — Sun, 01 Nov 2026 02:03:22 +0000

Last year, a labeling discrepancy reached our final effectiveness review with what looked like a complete record.

The event involved two versions of a label being used during finished-unit release. We contained the affected units, corrected the labeling, strengthened the verification instruction, and retrained the personnel involved. The actions were reasonable. The independent reviewer asked a different question:

“Show me where the original assessment recorded why this event did not introduce a new hazard or alter the intended use.”

That rationale existed. It just was not connected to the final review in a way a reviewer could follow without reconstructing several separate records.

The correction had not disappeared. Neither had the training or effectiveness data. What disappeared was the evidence chain connecting the original event to the final conclusion.

The part I now think gets lost most often

A quality event should not automatically become a CAPA. The preliminary assessment needs to determine whether the event requires correction, investigation, escalation, regulatory evaluation, or formal corrective action. That decision can change as information emerges.

The weak point for me is not the final effectiveness check itself. It is the connective rationale between these stages:

The original event description, scope, and source
The preliminary severity and risk assessment
The reason for escalating—or not escalating—the event
The relationship between the investigation findings and existing risk controls
The rationale connecting the corrective action to the identified cause
The evidence that the action was implemented and produced the expected result

Each of those records may be adequate on its own. Together, they can still tell a different story.

In my experience, this happens most often when a reviewer receives a polished closure summary without direct traceability to the underlying evidence. A summary can explain what happened, but it can conceal the fact that the original risk decision, root-cause analysis, and action rationale were never formally connected.

That is a traceability problem, not merely a writing problem.

What the standard actually requires

ISO 13485:2016 clause 8.5.2 requires corrective action to eliminate causes of nonconformities and prevent recurrence. It also requires the effectiveness of corrective actions to be reviewed.

The standard does not prescribe a particular form, workflow, or number of required documents. That flexibility is useful, but it means the organization must design a defensible connection between the event and its closure.

Clause 8.4 adds the expectation that data are analyzed for indications of nonconformity or other adverse trends. Clause 4.2.5 requires control of records so evidence of conformity is maintained, legible, and readily retrievable. “Readily retrievable” should not mean that an experienced reviewer knows where three people keep them.

ISO 14971:2019 is also relevant when an event provides production or post-production information. The event should feed back into the risk management process rather than remain isolated from it. For electronic records and signatures, 21 CFR Part 11 may add further requirements, although it does not define the CAPA process for us.

The standards do not say that every event needs a CAPA. They do make it difficult to defend a closure when nobody can show why the event entered the process, how its risk was assessed, or how the chosen action addressed the cause.

What we changed after the labeling event

Our first response was to improve the final summary. We created a cleaner one-page closure narrative with consistent headings.

That made the package easier to read, but it did not solve the problem. In fact, it made missing evidence easier to hide. A strong narrative can imply that a connection exists when the underlying process never documented it.

We replaced the summary-first approach with an evidence map. For each formal corrective action, the record now needs to answer five questions:

What exactly was received, and what was the event’s initial scope?
What did the preliminary assessment conclude, and why?
What evidence supports the stated cause?
How does the action address that cause rather than only the immediate symptom?
What specific evidence supports implementation and effectiveness?

The map points back to controlled source records instead of copying their full content. That preserves the original wording, dates, and approvals while making the relationship visible.

We also separated two questions that had started to blur together:

Implementation verification: Was the approved action actually completed?
Effectiveness verification: Did the action produce the intended control or prevent recurrence?

A training session being completed proves implementation. It does not, by itself, prove effectiveness.

For effectiveness, the review now defines the expected change before judging the result. Depending on the action, that may involve audit performance, observed process adherence, recurrence data, or a combination. We also document the limitations of the evidence. For lower-frequency events, “no recurrence observed” may provide weak assurance simply because the review period or sample was not capable of detecting recurrence.

The effectiveness reviewer should also be someone other than the person who implemented the action. Independence does not mean starting from scratch; it means asking whether the evidence actually supports the claim.

What I would do differently from the start

If I were designing this workflow again, I would capture an event baseline at intake and preserve it throughout the investigation. That baseline would include:

The original report, not only the later summary
Product, configuration, lot, or serial information
The initial impact assessment and decision rationale
Any immediate containment
Links to relevant risk controls
The reason for changing scope or escalating the event

I would not wait until closure to reconstruct that context. By then, the investigator knows what happened, and the reader may not.

I would also require an explicit statement when a conclusion remains uncertain. “Insufficient evidence to establish recurrence” is more reviewable than silently implying confidence. Regulators and notified bodies generally respond better to a clearly bounded uncertainty than to a polished claim unsupported by the record.

The change I value most is simple: treat the event-to-effectiveness connection as evidence that must be built, not context that reviewers are expected to remember.

In your quality-event process, which piece of evidence most often becomes difficult to reconstruct by the time someone reviews effectiveness?

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.