DEV Community: Rajiv Iyer

The dead link in our legacy DHF ate a sprint. Now traceability is a living system.

Rajiv Iyer — Thu, 15 Oct 2026 08:19:04 +0000

A senior engineer pinged me one Tuesday morning: "There's a 404 in the DHF." Not a web 404. A traceability 404 — a dead link between a design input and the test report that was supposed to prove it.

We are a contract manufacturer in Bangalore producing components for three global medtech OEMs. We inherit Design History Files from customers, add our process-specific verification, and run the design transfer. This particular DHF was eight years old, originally authored under 21 CFR 820.30(j), and had lived through at least two design transfers before ours.

What broke

The dead link sat in a Verification Traceability Matrix (VTM) — the spreadsheet that maps design inputs to outputs, to verification activities, to test reports, and back to risk controls. Someone, in some prior revision, had renamed a test protocol ID. The matrix referenced the old ID. Eight years of subsequent changes piled on top, and no one had ever re-walked the matrix to confirm every cell still resolved.

When our team tried to extend the VTM for a new supplier-driven change, a script that cross-checked IDs found a dangling reference. The protocol did not exist. The test report that was supposed to reference the protocol had a footnote saying "superseded by [new ID]" — but nothing in the DHF told you what that ID was, or where the new protocol had landed.

That is how we lost a sprint. Not to the change itself. To reconciling eight years of trace records by hand.

What the standard actually asks for

ISO 13485:2016, clause 4.2.5, says records shall remain readily retrievable and protected from loss. Clause 7.3.9 says design and development changes shall be reviewed, verified, and validated as appropriate, and the records of those changes kept. Clause 8.2.1 says feedback — including complaints and nonconforming product — has to feed back into the risk file.

None of those clauses say "your traceability shall be stored in a spreadsheet." But the implicit ask is that traceability must be live — you must be able to demonstrate the chain, not just point at a static document and hope.

The FDA's 21 CFR 820.30(j) asks for a DHF that contains, or references, the records necessary to demonstrate that the design was developed in accordance with the approved design plan. EU MDR Annex II asks for similar — the technical documentation has to allow the manufacturer to demonstrate conformity.

The common thread: traceability has to be demonstrable. A VTM frozen in 2017 and never re-walked does not satisfy that.

What we did to fix it

We did three things, in this order.

Rewrote the affected VTM by hand. Two engineers, four working days. Painful, but unavoidable.
Wrote a small Python script that walked every cell, looked up the referenced ID in our document repository, and flagged unresolved ones. Anything flagged got a comment in the VTM itself.
Scheduled that script to run on every revision commit. A dead link now blocks the PR, the same way a broken unit test would.

The script is not clever. It does plain string matching against IDs, because our IDs follow a strict format. Semantic similarity is for a different problem — I wrote about that last year (see the 0.87 problem). Here, exact match is the right tool.

What I would do differently next time

If I were starting this DHF fresh, I would not author the VTM as a spreadsheet at all. I would author it as code — a small structured file (YAML, if you like), one record per trace link, validated on commit. Each link would carry a timestamp, a status, and the IDs it points to. The "matrix view" would be a rendered output, regenerated on every change.

Treating traceability as code means:

Every change to a trace link is a diff you can review.
A dead link is a CI failure, not a discovery during an audit.
The DHF and the VTM cannot drift, because they are the same artifact.

That is what I mean by treating traceability as a living structure. A static matrix, however complete, decays. A structure that re-validates on every change catches the ripple instantly.

The change that exposed the dead reference did not cause the decay. Eight years of changes did, and we had no system to flag them in flight.

What we still have to reckon with

We have forty-plus suppliers of our own. Each one ships a CoA, a test report, a certificate of conformance. Each of those has to land somewhere in our traceability. The same decay problem applies to our supplier records.

We are not there yet. But the principle holds: if a link can break silently, it will. The only fix is to make breakage impossible to merge.

What does your team's traceability look like — a spreadsheet someone updates quarterly, or a structure that re-validates on every change? I would be curious to hear how others draw the line between "documented" and "demonstrable."

One NCR form to rule them all stopped working the day we added our 30th supplier

Rajiv Iyer — Wed, 14 Oct 2026 09:29:12 +0000

Last month, a buyer pinged me: "Why is this incoming-inspection NCR asking me whether the customer filed a complaint?" Fair question. It's because we'd been using the same issue form for every non-conformance, deviation, and complaint that landed in our QMS — and the form was getting worse at all three.

We run a contract manufacturing shop in Bangalore. Components for three global medtech OEMs, about 42 active suppliers of our own (raw materials, sub-assemblies, packaging), and somewhere between 800 and 1,100 supplier COAs a quarter depending on the order book. Our internal QMS is small: two QA people, one RA, plus me wearing multiple hats. So the temptation to "just use one form" is enormous. We gave in. Here's what broke.

ISO 13485 quietly expects them to be different

ISO 13485:2016 does not, strictly, force you to use three templates. But it draws clear lines that a generic form flattens:

Clause 8.2.2 covers complaint handling as its own process, with its own recording, evaluation, and investigation steps
Clause 8.3 covers nonconforming product and expects you to identify the affected product, segregate it, and decide on disposition
Internal process deviations (often sitting under 8.5.6 — validation, and the change-control side of 8.5.6) want a different evidence trail: process parameters, operator, equipment, time of occurrence

When you collapse those into one form, you end up with fields that are meaningless for half the records and mandatory-but-forgotten for the other half. The data starts to rot. Our notified body noticed in the last audit — politely.

The specific friction at a CMO

A supplier-side NCR for an incoming stainless-steel bracket needs:

Supplier heat/lot number and the COA we received against that lot
Receiving inspection record (method, sample size, accept/reject criteria)
Disposition: rework, scrap, use-as-is with concession
The supplier CAPA trigger and who owns it

It does not need "patient harm indicator" or "complaint source."

An internal process deviation from CNC turning needs:

The work order, operator, machine, and parameter sheet
Post-deviation first-article inspection
Link back to the validated process and any process change ticket
Engineering sign-off on the containment

It does not need "supplier batch number" or an EU MDR Article 87 reportability flag.

A customer complaint — which for us always comes in from one of our OEM customers about a component we made — needs:

The OEM's complaint reference, traced down to our internal lot
A check against MDR reporting timelines (Article 87 for serious incidents)
A root-cause methodology and a controlled CAPA workflow
An audit trail of every interaction back to the original reporter

Stuffing all of these into one form gave us an average of nine fields per record that were always blank, two fields that everyone forgot to fill because they only mattered for one record type, and an audit-prep ritual where we'd export to Excel and re-bucket the data just to look at it in a meeting.

What we changed

We split the issue types into three configurable templates. Each one now has:

A short header the operations team can scan in two seconds — record type, source, affected lot/PO/WO
The data fields that belong to that issue type, and nothing else
A mandatory linkage to the parent lot, work order, or supplier
A disposition step that's relevant to the actual workflow (NCRs go to MRB; deviations go back to engineering; complaints go to the OEM-relationship owner)
A different SLA and escalation rule

I'll be honest — it wasn't elegant. We did it with a psql schema for the templates, a thin Python middleware to validate inbound records, and about six hours of back-and-forth with the people who'd actually fill these in. The first iteration was over-engineered. The third was the one we kept.

On tooling

If you want a quick walk-through of how a modern eQMS handles per-issue-type schemas, this video is a reasonable watch:

[youtube link]

For the device-maker and SaMD teams we share an industry with, configurable per-type templates are genuinely useful and reduce the audit-prep ritual enormously. For us at the CMO, where many of the records originate at the supplier and we don't control upstream forms, it's about half-useful. We still have to coax suppliers into our schema through the COA. Tools with open API and webhook access (qmsWrapper, for instance, publishes event streams on issue state changes) make that integration tractable; closed-schema tools don't.

I work on qmsWrapper — this is my honest read of where it fits and where it doesn't, especially from a CMO's supplier-quality seat.

Takeaways

Three templates cost us less to build and maintain than one. We didn't need new software or a 40-page procedure. We needed to admit that "issue" was a useless word to a buyer, a CNC operator, and a regulatory lead — and that the fields each one was being asked to fill were, for them, mostly noise.

One small request to anyone reading this: if you've gone the other way and stuck with a single form and made it work somehow, I'd genuinely like to hear what your secret was. And if you split templates — which field did you end up adding or removing in month three that you wish you'd gotten right in week one?

Form builders are not workflow engines: a CMO's eQMS shortlist problem

Rajiv Iyer — Tue, 13 Oct 2026 08:20:09 +0000

The form-builder trap

I have built an eQMS shortlist six times in the last three years. Twice for the CMO I work at, once for a friend running a Class IIa startup in Eindhoven, three times for consulting engagements. Every single shortlist collapses the same way: five vendors, four of them are form builders with branding.

That is not quite fair. They are very good form builders. The validation is solid. The audit trail is there. The e-signatures work. But when I ask the demo engineer to show me how their workflow engine handles a real cross-object flow — say, an incoming COA fails a critical spec, triggers a non-conformance, opens a CAPA, and routes the CAPA to the supplier-quality engineer and the OEM customer's complaint owner in parallel — the answer is almost always: "you can configure that with our form rules."

Form rules. Not a process engine. Not an event-driven workflow. Rules on a form.

What "process engine" means at a CMO

At a contract manufacturer, supplier quality is a different shape than it is at an OEM. I have 42 active suppliers, three OEM customers, and I receive close to a thousand certificates of analysis a quarter. The work is not "device history record management." The work is cross-record orchestration:

A COA lands in our supplier portal. I need it parsed, the values checked against the incoming inspection spec, and the result routed without a human touching it unless something is off.
If a value is off, a non-conformance opens automatically, attaches to the lot, and triggers an automated supplier CAPA.
The CAPA has to link to the right OEM customer complaint record, because their notified body audit is in eight weeks and they need to show a connected workflow between their field signal and my supplier signal.
When the supplier responds, my QA reviewer has to be able to see the chain — COA, NC, CAPA, root cause, effectiveness check — in one place. Traceability is not a report. It is the system.

That is a process server. That is event routing. That is a state machine for a quality record. None of that is "form rules."

What I look for in a demo

I have started carrying a checklist. The questions that separate a real process engine from a form builder:

Can I model a state machine, not just a sequence of steps? Real CAPAs branch. They reopen. They get parked. They have sub-states. The state machine is the workflow; a form with checkboxes is not.
Can a transition on Object A trigger actions on Object B without me writing a custom integration? If the answer is "use our API and a webhook," that is an integration tax.
Are SLA timers, escalations, and parallel routing first-class? Or are they "available in the enterprise tier"?
Is the audit log structured around events, or around field changes? I need to answer "what happened to this lot between receipt and disposition" in one query, not by stitching six reports.
Can I version a workflow? When the CAPA process changes after the next notified body audit, the old CAPAs need to run on the old workflow. Form rules do not version well. (This is the part where I pause, refill the filter coffee, and ask the demo engineer to take the question again, slowly.)

Where qmsWrapper fits, and where it does not

I should disclose something here. I work on qmsWrapper. I build the supplier-side automation on top of it. So my view is biased and I say so plainly.

qmsWrapper is built for device makers and SaMD teams. The way change, CAPA, risk, and document control actually link to each other is genuinely well done for that buyer. If you are a Class IIa team in the Netherlands with two QA people and a mounting CAPA queue, the native workflow integration will save you from a lot of glue code. Every state change is logged, every approval is traceable.

What it is not built for, and where I would push back, is the CMO supplier-quality side. There is no first-class supplier COA object. There is no incoming inspection workflow out of the box. I run that layer in Python and Postgres on my side, which is fine for me, but if you are a smaller CMO without an automation person, the gap is real. The marketing page does not pretend otherwise; the partner pitch from resellers sometimes does.

I work on qmsWrapper and have given my honest read of where it does not fit a CMO supplier-quality use case.

The CMO shortlist that actually works

The platforms I have seen that pass my five questions tend to fall into two buckets. The first is enterprise QMS that costs as much as a flat in Whitefield and assumes you have a QMS administrator. The second is BPM-first platforms that have a real process server, and a QMS-shaped skin on top, but the skin is thin.

I have not found a mid-market eQMS that is genuinely process-engine-first and CMO-shaped. If you have, I want to hear about it.

What am I missing?

If you are running supplier quality at a CMO or a contract testing lab, what does your eQMS actually do for cross-record orchestration? Which vendor surprised you? Which one disappointed? I am especially interested in platforms that handle the supplier COA → NC → CAPA → OEM complaint chain as one connected workflow, not four separate forms with email notifications between them.

Most eQMS comparisons assume you are the device maker. They are wrong for a CMO.

Rajiv Iyer — Mon, 12 Oct 2026 12:07:36 +0000

Most eQMS comparison posts assume you are the device maker

We are a contract manufacturer in Bangalore running incoming inspection and supplier COA verification across 42 active suppliers. Three OEMs ship through our lines. None of them need what I need. They audit us; I do not audit them. Their QMS runs inward. Mine runs outward — across an inbox, a shared drive, and a paper form that someone prints at 4pm when the supplier truck arrives. When the supplier misses a COA, my QA lead puts the phone down and mutters the only word that fits: solvadhillai — it has not solved itself.

So when I read comparison posts that end with "the best eQMS for medical device SMEs," I read them from a different chair. I am not the device maker. I am the device maker's manufacturer. The vendor list that fits one does not necessarily fit the other. Here is what I am trying to solve, and here is what I found when I worked through it.

The actual problem

I have a paper process. Supplier COA arrives, gets logged, goes to incoming inspection, gets reviewed against the device history record, gets approved, gets filed. Today that routing happens across three systems and a printed checklist.

What I want is:

A single map of the route from intake to sign-off
Routing that runs itself once the COA lands
Plant-floor visibility from a LIMS and a MES pull
Pricing a CMO of our size can actually defend

I do not need another form builder. I need routing. Does that exist at SME pricing? Here is what I think after walking through the usual suspects.

1. Greenlight Guru — not built for our seat

Greenlight Guru publicly positions itself for medical device companies. That is the right frame for an OEM QA team at a Class IIb manufacturer with two products. The conversations its public materials centre on are DHFs, design controls, and submissions — that is OEM work, and it is not where my world sits. I am the OEM's CMO. I do not own design control.

2. Veeva Vault QualityOne — broader on paper, heavier in practice

QualityOne is positioned across pharma, biotech, and medical device, with the Veeva Connections and Veeva Link integrations behind it. For a mid-sized CMO, the question is not whether it can cover our scope — it can — but whether the platform shape matches what we are doing. The publicly stated integrations point toward regulatory submissions and RIM workflows. If your routing problem is supplier COAs into incoming inspection rather than submission dossiers, you are paying for capacity you will not use.

3. Dot Compliance — the SME-budget shape

Dot Compliance is positioned for biotech, general manufacturing, med-device, and pharma, with Salesforce integration and a publicly offered free trial. For a CMO validating routing logic before committing a year of spend, the free trial line is genuinely relevant. Salesforce is a plus if supplier data already lives in a CRM. On its own it is not a full incoming-inspection answer, but it is the most budget-shaped of the device-adjacent options.

4. MasterControl — wide industry coverage, plant-floor friendly

MasterControl is positioned across general manufacturing and medical device, which is closer to where a CMO actually sits. For a plant-heavy operation that wants routing tied to inspection, batch, and release, that industry positioning puts it in the running. I would still want a deeper look at supplier-side routing in a demo, because public positioning is not the same as a configured instance, but it is a credible second conversation.

5. ETQ Reliance — the routing fit I keep coming back to

ETQ Reliance publicly positions for general manufacturing, aerospace, and automotive, with stated integrations into LIMS, MES, PLM, ERP, HR systems, and CRM. For a CMO doing incoming inspection of supplier COAs, those three lines matter most:

LIMS — because our inspection data does not live in a browser tab
MES — because our plant-floor QA does not either
PLM — because the COA has to land against the right device record

The integration breadth is what makes the routing problem solvable — not as one feature, but as a chain. For the paper-process-to-routing problem in this post, this is where I land.

6. qmsWrapper — the honest read

I work on qmsWrapper, so I will say it plainly: it is not the right fit for supplier-heavy CMO work in the form it publicly positions today. The reason is fit, not capability. qmsWrapper is publicly built and marketed for device makers and SaMD teams. Its public positioning does not centre supplier-quality routing or general manufacturing plant work. If your world looks like ours — 42 suppliers, three OEMs, an inbox full of COAs — the tool's public framing is aimed at the people who audit you, not at the people routing your day. That is the honest answer, and it is the reason this post ranks it last.

The recommendation

For a CMO whose paper process is supplier intake → review → approval → sign-off, and whose plant runs on inspection data pulled from a LIMS and a MES, ETQ Reliance's publicly stated integration breadth is the closest match to the actual workflow. I would still validate supplier-side routing in a demonstration, because public positioning is not the same as a configured instance. But if you are scoping this problem today, that is where I would start the conversation.

I work on qmsWrapper. This is my honest read of where it does not fit — not a vendor pitch.

How is everyone else routing supplier COAs through incoming inspection — one system, three systems, or a printed checklist that nobody wants to fix?

The cloud shift helps. The partner-program pitch doesn't reach a CMO.

Rajiv Iyer — Sun, 11 Oct 2026 07:39:37 +0000

We process close to a thousand certificates of analysis a quarter across 42 active suppliers. Last month, between two inspection bays, I pulled a COA on my phone and realised I had the wrong revision. The supplier had updated the document at 11:47 that morning; my cached copy was from the previous day. That, in a sentence, is why the cloud shift matters.

Where the cloud argument lands cleanly

For device makers and SaMD teams, the pitch for cloud-based QMS is straightforward and mostly right. Documents are current because there is only one revision. Audit trails are continuous because no one is logging out of a desktop client to walk to another workstation. Suppliers, notified bodies, and remote reviewers all look at the same artifact. When your team is split across two sites — or your notified body auditor is reviewing from Berlin while you are in Eindhoven — that single source of truth is not a luxury; it is table stakes.

The qmsWrapper piece on the cloud shift lays this out plainly. The wins — current documents, real-time audit trails, less spreadsheet sprawl — are real, and I see them in the smaller corners of my own stack where I have moved bits of supplier-quality work to a Postgres + Grafana rig. I do not disagree with the framing.

Where the partner-program extension stops reaching me

The same piece then argues that a partner program — consultants, implementation specialists, validation support — extends the cloud benefit. The reasoning is that even a solid platform fails if a small device maker does not have the bandwidth to roll it out, and partners fill that gap. Fair in principle.

But I am not a device maker. I am a contract manufacturer, and the partner-program logic does not map cleanly onto how CMOs buy and use tools. We sit on the other side of the table. When we evaluate an eQMS platform, the buying decision is shaped by:

Which OEMs we manufacture for, and what their eQMS expectations are on supplier portals
How the platform handles supplier-side workflows — incoming inspection, COA verification, supplier non-conformance, SCARs
Whether our 42 suppliers can interact with the system at all (a few are 12-person machine shops running paper)
Whether the validation package covers the CMO context, not just the OEM context

A partner network built around device-maker rollouts may not know how to map those workflows onto a CMO's incoming-inspection reality. I would argue that is not a flaw of the network — it is simply that the network was built around the OEM use case the platform targets.

What I would actually want from a "partner" if I were buying

If a vendor asked me what would extend the cloud benefit for a CMO of my size, I would ask for:

Someone who has done an eQMS rollout under multiple OEM quality agreements, not one
A validation package that explicitly covers contract-manufacturing workflows: sub-tier supplier control, customer-furnished material, rework and scrap disposition
Someone who can sit in on a joint audit with an OEM and explain how our QMS interacts with the OEM's own system
Pragmatic ISO 13485:2016 plus customer-specific-requirement mapping, not a generic device-maker playbook

The cloud helps. The partner program extends the cloud help for the audience it was built for. Neither is wrong. Neither was built for me.

An honest note on my position

I run supplier quality at a contract manufacturer that produces components for three global medtech OEMs. When I write about eQMS tooling on the supplier side, I am not a neutral observer — qmsWrapper is a vendor in this space, and the platform is positioned publicly for OEMs and SaMD teams rather than CMOs running supplier-side workflows. I work on qmsWrapper, and this is my honest read of where the cloud-and-partner pitch lands and where it does not reach a CMO.

Open question

For the CMOs and supplier-quality folks reading — when you have evaluated a vendor's partner program, what did you actually need from it that the OEM-focused pitch did not cover? I am curious whether anyone else has had the "great network, wrong audience" experience.

Writing a Form 483 response for the inspector is a mistake — write it for your own team

Rajiv Iyer — Sat, 10 Oct 2026 12:11:24 +0000

There are two ways to write a Form 483 response. One is for the inspector who issued it. The other is for your own team eighteen months from now, when the follow-up inspection arrives or the warning letter escalates. The first version is faster. The second is harder to write and easier to defend. If you only have time for one, write the second.

Why "write for the inspector" feels safe

The instinct is reasonable. An inspector hands you a list of observations at the close of an inspection. You have fifteen business days. The literal reading of each observation invites a literal correction: here is the SOP we updated, here is the record we created, here is the training we delivered. Tight. Responsive. Defensible on the page.

This works when each observation is genuinely a one-off. It fails when the observation is a window into a systemic gap. The 21 CFR 820.100 CAPA clause, the 820.198 complaint handling clause, the 820.50 purchasing controls clause — these are systemic by design. A "fix the record" response to a systemic observation is exactly the response that returns at the next inspection cycle, sometimes with interest.

The CAPA-shaped response

A response that treats each observation as a CAPA has four parts, and all four need to be in the response document even if some are short:

Containment — what you did immediately so the risk is bounded while the real fix is in progress. This is the only part that looks like the "write for the inspector" approach.
Root cause investigation — what you actually did to understand why the observation is true. Not a guess. A documented investigation, even if brief, with a stated method (5-Why, fishbone, fault tree — pick one and apply it honestly).
Corrective and preventive action — the systemic change. SOP update, training, tooling, supplier qualification, design control linkage — whatever the root cause points to. Each action has an owner and a date.
Effectiveness check — how you will know, in measurable terms, that the action actually worked. Not "training was completed." A metric, a monitoring window, a threshold. "For the next 90 days, incoming rejection rate for supplier X will be reviewed monthly and must remain below 2%."

The effectiveness check is the part most teams skip. It is also the part that separates a response that closes an observation from a response that closes a problem.

The CMO angle: when you are tier-2

I run supplier quality at a contract manufacturer. Three global medtech OEMs, forty-plus direct suppliers, components going into Class IIa and IIb devices. My facility gets inspected in two contexts: directly by FDA (rare, but it happens for-cause), and indirectly when an OEM client gets a 483 and the inspector pulls our records.

In the second case, my CMO's processes show up in the OEM's CAPA. The OEM's response has to talk about supplier controls. If our supplier-side evidence is just a fixed record and a training log, the OEM's CAPA has nothing to lean on. If we hand them a CAPA-shaped response with a documented root cause and a defined effectiveness check, they can cite it. Same observation, different downstream defensibility.

The lesson: if you are tier-2, your response quality is your customer's response quality. Build the response you would want to receive from your own suppliers.

This is also why a connected workflow matters in principle — change, CAPA, risk, document control, training all linking so that when an observation lands you can pull the chain without re-typing what you already know. Tools like qmsWrapper pitch this for device makers, and the pitch is correct for that audience. At a CMO with our supplier volume, we run our own Python + Postgres + Grafana stack stitched to the QMS; the principle transfers, the product fit does not. There is a particular sandhosham — that quiet relief — when a properly closed CAPA shows up at the next audit and the inspector just nods and moves on. You only get that if the links were real to begin with.

Disclosure: I work on qmsWrapper. The connected-workflow pitch is right for device makers; it does not fit CMO supplier-quality work, and this is one of those cases.

Why harder to write means easier to defend

Three reasons the CAPA-shaped response survives scrutiny that the literal response does not:

The follow-up inspection uses your own metric. When the effectiveness check has a number, a window, and a threshold, the next inspector is reading your homework against your own rubric. You have either met it or you have a story for why you have not. Either is better than a void.
Cross-references get cheaper. A root cause that points to training gets cross-referenced into the training system. A corrective action that touches document control gets cross-referenced there. A preventive action that touches supplier qualification links up. The response starts to look like a system that knows itself, not a memo that explains itself.
The warning letter is harder to write. If the 483 escalates, FDA pulls the response. A response that is mostly narrative is easy to characterize as "firm's corrective actions appear adequate on paper but lack objective evidence of effectiveness." A response with stated metrics and trending data is much harder to escalate.

A practical structure

If I were writing the response tomorrow, the layout would be:

One-paragraph executive summary
Observation-by-observation section, each with the four CAPA parts above
An effectiveness-check summary table at the end — observation, metric, window, threshold, owner
Cross-reference appendix to the linked records

The table is the move. ISO 13485:2016 §8.5.2 expects you to verify that corrective action does not adversely affect the ability to meet applicable regulatory requirements. A response that demonstrates it is doing exactly that, in a format a reviewer can scan in two minutes, lands differently.

Closing thought

The hardest part is not the writing. It is the discipline to ask, of each observation: what is the systemic gap, and how will I know I closed it? If you can answer that on paper, the response writes itself. If you cannot, the response is the wrong response.

When was the last time your team's 483 response held up eighteen months later — and what made the difference? I would like to hear what an "effectiveness check" actually looks like in your shop.

Auditor overreach or a real gap? How I tell in the room

Rajiv Iyer — Thu, 08 Oct 2026 07:04:54 +0000

The 9:14 a.m. request

Day two of an external surveillance audit. The lead auditor set her coffee on the table and asked for a complaint log going back two years. We have one. I knew what she was going to say when she saw it. Half the items she would call "complaints" were logged as "feedback" — written inquiries from clinicians about device operation that did not, by my procedure's read, constitute complaints.

This question comes up at three of our last five audits: how do you tell whether the auditor is pointing at a real gap, or asking for a record the standard does not require you to keep? The answer is in the room, not after. By the time the finding lands on paper, you have lost the chance to frame it.

Years ago I would have reached straight for whatever she asked for. The Tamil word that fits is கடமை (kadamai) — duty, the reflex to comply first and justify later. Years of audit prep have taught me to slow that reflex. Not to defy, not to fabricate, but to read the clause before reaching for the file.

The mental model I use

There are three shapes this kind of question can take.

A real gap. The standard explicitly requires a record you do not have. ISO 13485:2016 §8.2.1 requires complaint handling records. §8.3 requires nonconforming product records. §7.6 requires calibration records. §7.5.5 requires traceability records for implantable devices. If your procedure says you keep them and you do not, the auditor is right. Acknowledge and CAPA.
Auditor overreach. The standard says "maintain records that demonstrate the QMS is operating effectively" — a general obligation under §7.5.1 — but does not enumerate the specific record the auditor names. The auditor has invented a record type that exists nowhere in your QMS and is not demanded by the standard or your notified body's audit checklist.
The grey zone. The standard requires "documented information" for a clause, the auditor names a specific format, and your procedure does not. Both readings can hold. EU MDR and ISO 13485 lean on outcome language precisely so they can be read in different ways. The auditor's interpretation is defensible; so is yours.

What I

Questioning the medtech "partner program" — when a broker is just a broker

Rajiv Iyer — Mon, 05 Oct 2026 13:43:44 +0000

The pitch always sounds reasonable. A "partner program" promises vetted suppliers, shared audits, pre-negotiated terms, and faster onboarding. From a CMO perspective, that should be music. We sit on 40+ active suppliers, and the cost of qualifying a new sterilization partner is measured in months, not weeks. So when a broker approached us last year waving a curated network of "audited" medtech suppliers, I sat up. Then I read the contract. Then I asked questions. Then I started writing this down.

This is not a screed against partnership models. Some are genuinely useful. But a few of them are repackaged brokerages dressed in risk-sharing language, and the rosy rhetoric hides a real shift in who carries the QMS accountability. If you are a small manufacturer — two QA people, mounting CAPA backlog, next notified body visit in eight months — that shift can break you quietly.

What "partner program" actually means

In medtech, a partner program is usually one of three things:

A referral network — a broker introduces you to suppliers they have not audited, and disappears.
A managed supplier program — the broker claims ongoing qualification, monitoring, and re-audit on your behalf, often for a fee layered on each PO.
A license/white-label arrangement — the broker lets you resell or co-brand product from an OEM whose own QMS you do not see.

The middle one is the one with the most interesting compliance teeth. Because if a managed supplier program fails, the question your auditor will ask is not "did the broker do its job?" — it is "did you control your supplier?" That question lands on the legal manufacturer, not the broker.

I have also seen a fourth, quieter variant: a programme that on paper is managed, but in practice the broker sends you a one-page "summa form" — summa meaning "merely" or "just for show" in Tamil — to confirm supplier status, and calls that qualification. The form is the entire audit trail. That is the version to watch for.

Where the accountability gets fuzzy

I sat in a CAPA review where a non-conformance had travelled through a managed supplier, then through a sub-tier broker, then to us. The chain of custody was clean. The chain of responsibility was not — and with it, the traceability of who owned what. Three QMS managers from three companies tried to point at each other. The root cause analysis, when it finally landed on my desk, had been rewritten four times because nobody wanted to own it.

This is the heart of the risk. ISO 13485:2016 §7.4.1 and §7.4.2 are explicit: purchasing controls apply to the legal manufacturer, and the legal manufacturer must evaluate, select, monitor, and re-evaluate suppliers based on their ability to meet requirements. 21 CFR 820.50 says the same thing in different words. EU MDR 2017/745 Article 10(9) extends this to economic operators in the chain.

None of those clauses go away because you have a partner program. The oversight obligation does not transfer. A broker can do work on your behalf, but the burden of demonstrating control — at audit — stays with you. If a regulatory body later asks for the qualification evidence and the answer is "the broker has it," that is a finding waiting to be written.

The risks I've seen in practice

A few patterns worth naming, all from real incidents in our network:

Audit evidence lives in the broker's portal. When the supplier's quality documents are stored in a system you do not control, your own records become derivative. During an unannounced notified body follow-up, derivative evidence is a weak place to stand.
CAPA routing falls between stools. Suppliers assume the broker is tracking action items. Brokers assume the legal manufacturer is. CAPAs age out, root causes drift, and effective verification never quite happens.
Change control gets thinned. A broker mediates a process change at the supplier, but the impact assessment on your design history file is "the supplier confirmed no impact." That confirmation is not an impact assessment.
Confidentiality boundaries blur. You may be sharing your design inputs, your drawings, your COA templates with a partner who is also partnered with two of your competitors. Read the data terms carefully.

What I would ask before signing

If you are weighing one of these programs, here is the short list I now keep on my desk:

Does the contract explicitly state that the legal manufacturer retains supplier control responsibility under ISO 13485 §7.4 and 21 CFR 820.50?
Can I obtain the broker's raw supplier audit reports, not just summary scorecards?
Does the broker's QMS have a written interface agreement with each tier-1 supplier, and can I see it?
Who owns the CAPA record when a non-conformance crosses the broker boundary — the supplier, the broker, or me?
What is the change-control workflow when a supplier modifies a process, and where does my DHF get updated?
If the broker is dissolved or acquired, what happens to the supplier records and my access to them?

If the answers to any of those are vague, the partnership is not yet ready to bear the weight of a notified body visit.

What I would do differently

If I were starting over, I would not outsource my supplier quality oversight to a broker. I would consider outsourcing activities — pre-screening questionnaires, COA verification, scheduled re-audit calendars — and I would keep the QMS decision rights firmly on our side. The work the broker does is work I can review. The accountability the broker absorbs is accountability I cannot review, because I no longer hold it.

A partner program is a tool. Tools can extend reach or they can erode grip. The difference is whether the QMS accountability stays in your hands and is supported by a connected workflow you control, or whether it has quietly migrated into a contract clause that reads well and survives nothing.

Have you been through a managed supplier program that genuinely held up at audit? Or one that collapsed the moment a non-conformance crossed the boundary? I would like to hear how the CAPA routing worked in practice.

A partner-side QMS rollout playbook — five phases I run the same way at every client

Rajiv Iyer — Sun, 04 Oct 2026 10:47:26 +0000

When I run a QMS rollout now, I run it the same way every time. Five phases. Same kickoff memo. Same deliverables checklist. Same exit criteria. The first three rollouts I did, I improvised — and every improvisation taught me something the next client had to pay for. This is the partner-side flow I now bring into every engagement, end to end.

A bit of context. I've been on both sides of this — a QA tech lead at a contract manufacturer for over a decade, and now taking on a handful of consulting engagements on the side. The plants I work with are Class I and Class IIa device shops, mostly 20 to 80 heads, often running paper-based QMS or a half-deployed eQMS that nobody finished rolling out. The pattern is depressingly consistent: somebody bought a tool two years ago, configured 40% of it, and the rest is held together by shared drives and tribal knowledge. My job is to take that mess and land it on the other side of an ISO 13485 audit with the system actually used, not just configured.

Here's how I structure the work.

Phase 1 — Discovery and gap framing (week 1)

No templates yet. No tool config. Just three things in the first five days:

A process map of the as-is QMS: how a CAPA actually moves today, where change requests sit, who owns what.
A gap list against ISO 13485 clause by clause, with the gaps scored by audit risk, not by document count.
A short list of "showstoppers" — things that would fail a notified body audit today, full stop.

I write this up in a single memo, two to three pages, no slides. The first rollout I did, I produced a 60-page discovery report. The client read none of it. Now I write the memo the way I write a CAPA executive summary — the auditor will read the first page and skim the rest.

Phase 2 — Configuration and document architecture (weeks 2-4)

This is where most consultants burn trust. They disappear into the tool for three weeks and come back with a configured system nobody asked for. The fix is simple: the document architecture is decided before configuration, in a half-day workshop with the QA manager and the process owners.

The non-negotiable outputs from the workshop:

One controlled document hierarchy (policy, SOP, work instruction, form, record).
A record-retention matrix that matches the client's markets — EU MDR, FDA 21 CFR Part 820, MDSAP, UKCA — not a generic 7-year rule.
A naming convention that survives the next two reorgs.

Configuration then follows the architecture. Not the other way around.

Phase 3 — Pilot on one process, end to end (month 2)

Pick one process and run it through the configured system, end to end, with real records. Not a sandbox. Not a demo dataset. A real CAPA, a real change, a real complaint, opened by the people who will own these records after go-live.

The pilot catches things no UAT script will. It catches the form field that's mandatory in the tool but meaningless to the business. It catches the workflow that nobody explained to the people who'll actually use it. It catches the integration that "works in staging" and breaks on day one.

I run the pilot for three weeks minimum. Less than that, and you're testing the tool, not the rollout.

Phase 4 — Training that isn't a recording (months 2-3)

Every QMS rollout I've watched die has died in training. Not because the training was bad — because it was the same generic recording played for everyone from the QA manager to the line operator.

What I do instead:

Role-based sessions: QA/RA, process owners, end users, system admins. Different curricula, different durations.
Each session ends with the user opening the system and doing their job in front of me. Not a demo — their actual workflow.
A one-page "where do I do X" cheat sheet for each role. Print it. Laminate it. Tape it to the monitor.

Recording-based training is a regulatory convenience and a learning disaster.

Phase 5 — Hypercare and audit-readiness check (month 3 onward)

The last 30 days before go-live is hypercare — I'm on call, the client is using it for real, and we meet twice a week to triage issues. But hypercare isn't just "fix the bugs." It's an audit-readiness walk-through:

Pull a random CAPA and trace it through the system, record by record.
Pull a random change and confirm the impact assessment links to the right documents.
Pull a random complaint and confirm the investigation timeline is reconstructable.

If any of those traces breaks, the rollout isn't done. The tool is configured; the system isn't.

What I'd do differently now

Three things, looking back:

Set the exit criteria in writing on day one. "Done" means different things to the consultant, the QA lead, and the CEO. Pick one definition. Mine is: the client passes a Stage 1 audit using only the new system.
Charge for change management, not configuration. Configuration is the cheap part. The hard part is getting 30 people to use the system instead of their old shared drive. If your SOW has 70% configuration and 15% change management, the rollout is going to fail and it's not going to be the tool's fault.
Don't promise a go-live date in week one. Promise a go-live window. The honest answer at kickoff is "between week 12 and week 18, depending on pilot results." Anyone who gives you a date in week one is selling.

What the standard actually asks for

ISO 13485 clause 4.1.6 is the line I keep coming back to: "the organisation shall document procedures for the validation of the application of computer software used in the quality system." Validation isn't configuration. It's the documented evidence that the system does what you say it does, in the client's environment, with the client's users. Every rollout I've seen skip validation has come back to bite at audit.

Question for the consultants here: what's the one phase you always run the same way, regardless of client size or industry? I'm curious whether there's a phase I'm under-weighting.

The 0.87 problem: when semantic linking makes inconsistent records look connected

Rajiv Iyer — Sat, 03 Oct 2026 03:11:12 +0000

A 0.87 match that almost shipped

Last quarter I built a small semantic-similarity layer over our CAPA database. The pitch to myself was simple: an engineer files a CAPA, the system surfaces related complaints, prior CAPAs, and design changes with confidence scores. The faster the linkage, the faster the impact assessment. The faster the assessment, the more robust the closure.

It worked. Too well, in one specific case.

The model flagged a CAPA about a supplier-side dimensional drift on a machined titanium housing as 0.87 semantically similar to a design change from eighteen months earlier — a different supplier, a different alloy, a different revision. The text overlap was genuine: both mentioned "fit," "tolerance," and "downstream assembly." The confidence score was honest about the words. It was silent about the context.

I almost sent the impact assessment to the OEM citing that design change as the "related" historical record. A junior engineer on my team caught it. She asked, in the calm way junior engineers ask the questions seniors should have already asked: "Why is it related? What is the actual chain of decisions?"

I did not have a good answer. The similarity score was not a decision. It was a hint dressed up as one.

What the standard actually asks for

ISO 13485:2016, clause 8.5.2(f), expects you to "review the effectiveness of any corrective action taken." The regulator does not care how you found the related records — search, similarity, gut, a colleague's memory. It cares that you can show the decision chain. What records did you consider? What did you conclude? Why was that conclusion appropriate given the context?

EU MDR's Annex XIV on clinical evaluation, paired with the MDCG guidance on sufficient clinical evidence, pushes the same point differently: the assessment is a human artefact, supported by traceable records, and the assessor has to be able to justify the chain. GAMP 5, the risk-based framework for computerized systems from ISPE, asks the same question about any system that feeds a regulated decision: are the inputs identifiable and reproducible?

Provenance is the part you cannot synthesise. You can synthesise the suggestion. You cannot synthesise the audit trail.

The failure mode I keep seeing

The pattern, in our own quality system and in two of the three OEMs we supply, runs like this:

A similarity score surfaces "related" items that share vocabulary but not operational context.
The CAPA owner, often under cycle-time pressure, accepts the linkage and builds the impact assessment on top of it.
Closure notes reference records whose connection to the current issue is asserted by the model, not by the CAPA owner.
When the notified body or FDA inspector asks, six months later, "why did you treat these as related," the answer is the model's score — which is not a justification.

This is the inflation problem. Semantic linking makes inconsistent sources look connected. Worse, the visual neatness of a graph — nodes, edges, similarity scores rendered in green — can crowd out the awkward question of whether the connection is real in the operational sense. Words are not decisions. Phrases are not approvals.

What I now require before a similarity score becomes a reference

Three things, after that 0.87 incident. These are not in any standard; they are our internal practice, and I would defend them to any auditor.

Source consistency check. Before any related record can be cited in a CAPA, the underlying data sources have to be reconciled. Supplier COA on file vs. incoming inspection result. Design history file revision vs. the actual drawing on the shop floor. If the sources do not agree, no similarity score gets a vote.
Explicit human ratification. The CAPA owner writes, in plain language, why record A is related to record B. Not "model says 0.87." They write the decision. The decision, not the score, is what goes into the closure record.
Traceable decision lineage. The decision has to be retrievable from the CAPA file without the model running. If the model disappears tomorrow, the justification must still stand. This is the part that survives the audit, not the part that made the engineer feel confident.

A senior colleague on the shop floor, who has been in the QA lab longer than I have, calls the third rule "konjam aasaiyaa" — a little patience — and I have come to agree.

The honest version of the pitch

I am not against semantic linking. I use it. The CMOs I know are running on tight teams and tighter timelines, and anything that helps an engineer find the right prior record faster is worth keeping.

But there is a difference between assistance and authority. A similarity score is assistance. It is a hint about where to look. It is not a substitute for the human decision that the auditor will ask about, and that the patient's downstream record will ultimately depend on.

The temptation, in any AI-adjacent system in a QMS, is to let the score do the work. The job, for the QA lead, is to keep the score where it belongs — at the front of the investigation, not the back of the closure.

The open question I keep returning to

If your semantic-similarity layer is the only thing that says two records are related, and the auditor asks the CAPA owner to defend the linkage from memory and from the file — what is in that file, today, that would let them do it?

The CER grew. The clinical evidence didn't. We let the report outpace the data.

Rajiv Iyer — Fri, 02 Oct 2026 10:54:08 +0000

The CER arrived on a Friday. 200 pages, polished, confident — the kind of document you can hand to a notified body and not lose sleep. The literature search that backed the equivalence claim? A 2019 copy-paste that had clearly been carried across three device families.

What MDR actually asks for, in plain language

Under EU MDR 2017/745, the Clinical Evaluation Report (CER) is the document that demonstrates your device meets the General Safety and Performance Requirements (GSPRs) on the basis of clinical evidence. It is not a marketing document. It is not a literature review dressed up in regulatory language. It is supposed to be the reasoned argument that the device is safe and performs as intended, supported by data that is sufficient in quantity and quality.

MDCG 2020-5 (on clinical evaluation) and MDCG 2020-13 (on clinical evaluation assessment by notified bodies) made this clearer than the old MEDDEV 2.7/1 rev 4 ever did. The CER is expected to be a living document, updated through the device lifecycle, fed by post-market surveillance, post-market clinical follow-up (PMCF), and complaint data. The intent is that the evidence and the report grow together.

That is the theory.

What I see from the supplier side

I work at a contract manufacturer. We do not write CERs. But we supply the post-market data that ends up in them — complaint trends, lot histories, process deviations, supplier non-conformances. And we read a lot of CERs from our OEM customers.

What I have learned is that the CER and the evidence it summarises are not the same thing. The CER is a document. The evidence is a state of the world. The two can drift.

The pattern looks like this:

A Class IIb device with a pre-MDR CE mark gets a new CER for MDR. The CER is 180 pages. The clinical literature on the device itself is a handful of small studies, mostly sponsored.
The equivalence justification names a competitor device. The competitor's clinical data is summarised in three paragraphs, with the underlying studies appended as a bibliography. The bibliography is impressive. The actual reading of those studies is often cursory.
PMS data is in there — complaint rates, trend reports, vigilance cases. But the analysis often stops at "within expected rates" without explaining what "expected" means for this device, in this patient population, on this indication.
The PMCF section says "a PMCF study is planned." The planned study has been planned for three CER versions.

The document is professional. The notified body may accept it. The device is deemed safe. The evidence has not really grown.

Why we let the report outpace the data

I do not think anyone is being dishonest. I think the structure of the regulation makes it easy to do this in good faith.

The CER has to demonstrate conformity now — for the current submission, for the current audit cycle. The evidence is generated over years, across a lifecycle, with all the friction that clinical research involves: ethics approvals, site contracts, patient recruitment, follow-up windows. A document can be drafted in weeks. A meaningful PMCF study cannot.

So we do the only thing we can. We write a thorough, well-structured CER that says what we can say today, and we plan the work that will substantiate the harder claims tomorrow. The problem is that "planned" can become a permanent state. The CER keeps getting updated. The PMCF study stays "in planning." The next revision of the CER describes the same planned study with a slightly later start date.

What I would do differently, in three practices

If I were writing CERs — or supervising the people who do — here is what I would want as standard practice:

Treat the CER as a record of what you know, not a plan for what you will know. Every claim should be traceable to a data source that exists today, not a study that will be done. Aspirations belong in the PMCF plan, clearly marked as gaps.
State the gaps explicitly. MDCG guidance allows for gaps to be identified, with justification. A CER that says "we have no data on long-term implant performance beyond 24 months" is more defensible than a CER that does not mention the gap at all.
Make the equivalence argument honest. If you are claiming equivalence to a competitor device, you need to be able to defend the three criteria (clinical, technical, biological) with specifics. A bibliography is not an equivalence argument.

From the supplier side, the one thing I would ask of every OEM I work with: share the CER's gap list with us. We sit on a lot of manufacturing and complaint data. If the OEM's PMCF plan has a gap, we may be able to help close it — and we should know what the regulator will eventually want to see.

The honest version of the safety claim

Clinical evaluation exists so a device can be deemed safe while the evidence matures. That is the regulatory bargain. The device gets to market. The report gets to grow. The evidence, ideally, catches up.

The failure mode is when the report grows but the evidence does not — when the document gets more polished while the underlying data stays thin. The device is still deemed safe. The CER says so. The notified body accepted it. But "deemed safe" and "demonstrated safe" are not the same sentence, and the gap between them is where post-market problems live.

How do you keep that gap honest in your own CERs — what does your team do to make sure the report and the evidence are moving together, not in opposite directions?

Why our CAPA effectiveness check keeps coming back as an audit finding

Rajiv Iyer — Thu, 01 Oct 2026 07:28:51 +0000

For three NB cycles running, our CAPA effectiveness check has been the same minor observation. And honestly, it deserves to be.

I work at a contract manufacturer with three OEM customers and around forty direct suppliers of our own. Every CAPA we run has two questions the auditor is paid to ask: did you fix it, and did the fix stick? The second one is where we kept stumbling, and it took me longer than I would like to admit to see why.

What the standard actually asks for

ISO 13485:2016 clause 8.5.2 is fairly explicit. Corrective action has to include:

a review of the nonconformity
determination of causes
evaluation of the need for action to prevent recurrence
planning and documenting actions to ensure recurrence is prevented
verification that the corrective action does not adversely affect the ability to meet applicable regulatory requirements
a review of the effectiveness of any corrective action taken

The last bullet is the one that gets abbreviated in practice. The first five are paperwork; the sixth is a question that takes months to answer honestly.

FDA 21 CFR 820.100 does the same dance, and under MDR the expectation is documented through the quality system. Most of us know the requirement. Fewer of us build a process that survives contact with a plant floor.

What we were actually doing

Our pattern, looking back at twelve months of closed CAPAs, was roughly this:

A CAPA opened in February for a recurring dimension drift on a turned part.
Immediate action: 100% inspection at incoming for eight weeks.
Corrective action: process change at the supplier, a new control plan, a pFMEA revision.
Effectiveness check: a single follow-up inspection at week 12 showing zero NCRs.
Close CAPA.

That single follow-up was the auditor's problem. It looked like confirmation bias wearing a clipboard. The original nonconformity had been intermittent in the records, and we "verified effectiveness" with one snapshot. The next cycle, the same drift came back through a different part number.

The auditor's written observation was polite: The verification of effectiveness for CAPA-XXXX does not include objective evidence over a sufficient time period or product mix to demonstrate that recurrence has been prevented.

Translated: you checked once, you got lucky, you closed it.

What "effective" actually means on a plant floor

I had to sit with this for a while before the picture got clearer. Effectiveness, for a CAPA that touches process or supplier behaviour, is not a single inspection. It is a small evidence pack:

a defined lookback window, not "whenever I happen to remember"
a sampling plan across the product family, not just the part that originally failed
a metric that actually moves (SPC Cp/Cpk if the data exists, NCR rate per shift, supplier COA trend)
a documented conclusion that ties the numbers back to the original problem statement

None of this is exotic. All of it is tedious. Tedious is exactly the thing that gets dropped when the queue is long and the next CAPA is already open.

What we changed

I am not going to dress this up as a programme. It is four small habits we built into the CAPA closure step:

A minimum lookback of 90 days for process or supplier CAPAs, longer if the original failure was sporadic. The number is documented in the CAPA record itself, not in someone's head.
Effectiveness evidence tied to the metric that defined the original problem. If the original was a Cpk issue, the verification is a Cpk trend, not an NCR count. If the original was a documentation lapse, the verification is a sample of records, not a single audit.
A second pair of eyes. The CAPA owner drafts the effectiveness review; the QA lead challenges the evidence before closure. Most of my team's improvement here came from being forced to defend the closure to someone who had not lived through the original incident.
A simple log of "where we got it wrong." Every CAPA that comes back as a recurrence goes into a one-page note — what did the effectiveness review miss, and why. We review this at our quarterly QRM meeting. It is not a punishment document; it is a calibration document.

These are not innovations. They are the difference between treating CAPA closure as the end of a project and treating it as the start of a measurement.

The honest part

I still do not think we have fully solved this. The pattern that keeps tripping us is the rare-event CAPA — the ones where the original failure happened once in a blue moon. You cannot run a meaningful 90-day trend on something that may not recur in 90 days. For those, we are still experimenting with adjacent-process evidence and periodic re-checks beyond the formal closure.

The thing I would tell my past self is that the auditor is not the enemy in this. The minor observation on CAPA effectiveness is, in our experience, almost always pointing at a real fragility in the closure step. The fix is rarely heroic. It is mostly the discipline of writing down, in advance, what evidence will count as "this worked," before you start measuring.

What is the audit finding your team sees come back every cycle? I would rather hear about it now than in an observation response.