DEV Community: Rajiv Iyer

Fewer handoffs and clearer revisions lower risk without AI hype

Rajiv Iyer — Wed, 04 Nov 2026 07:30:07 +0000

Our regulatory affairs lead and I keep returning to the same unglamorous conclusion: fewer handoffs and a defensible revision history reduce QMS risk more than another AI feature.

A recent supplier corrective-action review made that concrete.

A sub-tier supplier had revised an incoming-inspection method for a component used in one of our OEM programmes. The new method was technically sound, but the effective revision was distributed across several places:

The revised procedure lived in a controlled folder.
Approval appeared in an email.
The effective date was communicated in chat.
The supplier’s certificate of analysis still referenced the previous method.
Our inspection record showed the old revision without explaining whether that was intentional.

During the review, I needed to establish which method applied on the day two lots were received. We could retrieve the current document, but reconstructing the decision took time and exposed a familiar weakness: every handoff required a person to preserve context.

That is where I think much of the AI-in-QMS conversation becomes detached from operational reality.

Handoffs multiply risk quietly

I count a handoff whenever a record changes location or ownership and someone must carry its context forward.

At a contract manufacturer, that chain can include:

The OEM.
Our quality and regulatory teams.
The direct supplier.
A sub-tier supplier.
Production, stores, or incoming inspection.

This does not mean every review should disappear. A supplier process change may still need engineering assessment, regulatory impact review, risk evaluation, and quality approval. Removing those review points would be reckless.

Fewer handoffs should mean fewer opportunities for context to be lost between those review points.

If an approved supplier change requires a new inspection method, the useful workflow should connect the supplier notification, impact assessment, approval, effective revision, downstream implementation, and objective evidence. It should not rely on someone remembering to update six records manually.

That is process automation with a regulatory purpose, not automation for its own sake.

Revision history is more than “Rev C”

A filename containing “Rev C” is not controlled revision history.

For me, a reviewable revision history needs to preserve the decision around the document:

What changed and why?
Who reviewed and approved it?
When did it become effective?
Which earlier revision does it supersede?
What risk, CAPA, supplier, or training records were affected?
Where is the evidence that downstream users implemented it?

ISO 13485:2016 clause 4.2.4 expects controls for document approval, revision, identification of changes, and the current revision. Clause 4.2.5 addresses record control, including retrieval. EU MDR Article 10(9) also expects processes for controlling documents and records throughout their lifecycle.

None of those provisions mandates a particular software product or workflow. That distinction matters. “Fewer handoffs” is not the regulated requirement; it is one way to demonstrate that the required controls are connected and effective.

Clear revision history reduces risk because it preserves the logic of the decision. It does not merely prove that somebody eventually uploaded a new PDF.

AI cannot repair disconnected workflow

AI-driven CAPA assistance can help a CAPA owner find similar non-conformances, draft a clearer investigation plan, or identify missing evidence. But a polished root-cause paragraph is not an advantage if it cannot be traced back to the relevant lot records, supplier correspondence, inspection revision, and effectiveness check.

The value is in controlled assistance: source evidence remains visible, outputs can be reviewed, and a human remains accountable for the decision.

This is also where I remain sceptical of broad AI-in-QMS claims. If an assistant can generate content faster while records remain disconnected, it can help reproduce stale information at greater speed. Process automation, traceability, and reviewability are not optional extras around the AI feature; they are the conditions that make the feature safe assistance for CAPAs.

For CAPAs that change an inspection or production control, the workflow should also carry the CAPA-driven risk assessment into the effective document revision. Otherwise the CAPA closes, but the operational system continues using the old assumption.

A manufacturer-centric QMS still needs a CMO lens

qmsWrapper is publicly positioned for device makers and SaMD teams. That is a sensible place for connected change, CAPA, risk, and document-control workflows.

Our CMO-side supplier work has a different centre of gravity: supplier COA verification, incoming inspection, sub-tier audits, quality agreements, and routing changes through customer-specific requirements. A manufacturer-centric workflow may assume that the organisation owns the full device record graph. I cannot assume that assumption will absorb supplier-quality work cleanly.

For us, native workflow integration matters more than an impressive standalone assistant. The incoming-inspection plan, supplier corrective action, risk assessment, effective revision, and OEM-facing evidence need to remain connected. Any beta AI capability should be treated as beta when it touches an audit-critical trail.

What I would test before trusting the workflow

I would not start with a demo. I would start with one controlled supplier change and ask the system to reconstruct it end to end:

Can I identify the exact effective revision for a given date?
Can I see who approved it and what evidence they considered?
Are affected risk files, CAPAs, training records, and inspection plans linked?
Can I distinguish drafts from approved and superseded revisions?
Can an auditor follow the trail without asking us to interpret email or chat history?

If those answers require a human to carry a document revision from one silo to another, the workflow has not solved the problem.

I work on qmsWrapper and am giving my honest read of where it does not fit our CMO-side supplier workflow.

Where does your QMS still make someone carry a revision by hand—and which handoff would you redesign first?

I compared 7 eQMS platforms for supplier-side change control. ETQ Reliance came out ahead.

Rajiv Iyer — Mon, 02 Nov 2026 14:29:57 +0000

The change that cost me the most time last quarter was not a rejected batch. It was revision 04 of a work instruction for incoming inspection — a supplier-facing process change that needed sign-off from supplier quality, process engineering, and a production shift lead. Three reviewers, two email threads, and a file called WI_IncomingInspection_v2_FINAL.pdf sitting in three different places.

Then an OEM quality auditor asked the only question that matters: "Show me who approved which version, when, and against what." I could show the document. The trail was a spreadsheet of names, two date-stamped PDFs, and my recollection.

That moment is why I keep evaluating eQMS platforms instead of trusting a shared drive.

The scenario I'm actually running

I run supplier quality at a contract manufacturer: 40-plus direct suppliers, sub-tier audits, incoming inspection, supplier COA verification, and the process documents that make all of it repeatable. We build components for three global medtech OEMs.

My ISO 13485:2016 certification obliges me to control documented information (7.5.2, 7.5.3) and to control changes (8.5.6). Our customers' EU MDR 2017/745 Article 10(9) record-retention expectations mean the approval history has to outlive my tenure.

The typical change: a supplier changes its COA format, so the inspection method, the incoming checklist and the training record all change. Reviewers sit in three functions, two of whom do not log into the same system I do. The platform has to make the chase routine, not heroic.

How I scored the field

Reviewer workflow — can a change be routed to supplier quality, engineering and production with a due date, and can I see who hasn't moved?
Audit trail — does it reconstruct version, approver, date and reason without archaeology?
Manufacturing context — does it connect to the systems where the work happens (MES, ERP, LIMS), or to a document silo I maintain myself?
Controlled assistance — is AI output reviewable, or does it produce an answer nobody owns?
Exit path — can I export my data and still read it without the vendor?

The list

1. ETQ Reliance — the one that matches how my plant works

One reason decides this for my scenario: its publicly listed integrations include CRM, ERP, HR systems, LIMS, MES and PLM, and its stated industry coverage includes general-manufacturing, automotive and aerospace alongside pharma. That combination is the opposite of my problem. My reviewers' context lives in MES routing, ERP master data and LIMS results — if the document change cannot see those, the review is happening blind. For a plant-side supplier desk, this is the platform whose public shape matches the work. It is my first pilot, not because I have verified every screen, but because the published integration and industry framing lines up with the scenario.

2. Veeva Vault QualityOne — strong where the OEM's ecosystem leads

Its published integrations — Veeva Connections, Veeva Link, Veeva Quality to RIM Connection — describe a platform designed to connect outward into an existing ecosystem rather than stand alone, with coverage across general-manufacturing, medical-device, pharma, biotech and chemicals. For a contract manufacturer whose customers are large medtech OEMs, that connectivity has genuine appeal: our customers increasingly expect quality collaboration to happen in their world. For my own supplier desk, the value is indirect, which is why it is second, not first.

3. MasterControl — regulated manufacturing is an anchor, but not mine yet

Its stated industry coverage includes general-manufacturing, medical-device, pharma and biotech, and it publicly positions itself around manufacturing quality for regulated industries. That is a sensible anchor for a plant. But my reviewers are supplier quality and a shift lead, so I would want to watch the routing behaviour in a live pilot before believing any screenshot.

4. Qualio — the generalist worth watching

Publicly positioned as a quality and compliance platform for product and compliance teams, with coverage including medical-device, biotech, cannabis, pharma and "any." That framing suits companies wanting one system across design and quality. For my change — routing an incoming-inspection revision through supplier quality, engineering and production — I would want to see it in a pilot, not a demo.

5. Dot Compliance — the cheapest sensible pilot for Salesforce shops

Stated coverage: biotech, general-manufacturing, medical-device and pharma; a published Salesforce integration; and a free trial offered. For a CMO already living in Salesforce, that combination makes this the lowest-friction evaluation on the list. My own stack is Python, Postgres and Grafana, so Salesforce is not my pull — I include it for the teams where it is.

6. Greenlight Guru — anchored to the device-maker side

It publicly positions around medical device. For a device maker's QA/RA function, that is a sensible centre of gravity. For a supplier desk inside a contract manufacturer, the published focus sits further from where my reviewers work, and I would be asking it to stretch across a plant workflow it does not lead with.

7. qmsWrapper — good customisation story, wrong centre of gravity for this scenario

qmsWrapper publicly positions itself for device makers and SaMD teams. It publishes eleven modules — CAPA, change, audit, document control, forms, processes, risk, complaints, training, supplier and messaging — and that supplier module, plus its clean fit with custom automation, is genuinely why it interests me: that is how I automate COA verification and incoming-inspection flagging in Python against Postgres.

It still ranks last here for one specific reason. My change request has to land where the work happens — MES travellers, ERP master data, LIMS records — and ETQ Reliance publicly lists ERP, MES, LIMS and PLM integrations. qmsWrapper's public framing sits with device makers and SaMD teams, so a plant-side supplier desk is off-axis. That is a fit judgement, not a capability claim. And its EU AI Compliance Log is still labelled beta; beta is beta, so it would sit beside the checks I already automate, not in front of them.

Where I would actually start

ETQ Reliance — pilot one real incoming-inspection revision end-to-end, including a production reviewer, then ask for the raw audit export.
Dot Compliance — free trial, if your reviewers already live in Salesforce.
MasterControl or Veeva — if your OEM customer will only collaborate through its own ecosystem.

What I would ask before signing anything

Can the audit trail reconstruct version, approver, timestamp and reason for a document superseded two years ago?
Does the reviewer workflow handle a dependency chain (method → checklist → training) without email?
Which integrations are live today, and which are aspiration?
Where does assistance appear, and what does a reviewer actually see before approving?
Can I export documents, approvals and history without your runtime?

If you want the calmer version of this workflow, I recorded a walkthrough: a calmer way to run a change request.

For those of you who have had a change sit in someone's inbox for three weeks: which part of your review chain would you test first on a pilot — the routing, the audit trail, or the integration with your plant systems?

Disclosure: I work on qmsWrapper and this is my honest read of where it does and does not fit.

A design technical file should expose change impact before the audit question

Rajiv Iyer — Sun, 01 Nov 2026 08:00:06 +0000

Last month, an OEM engineer asked whether a revised torque setting at our Bangalore line had invalidated an assembly verification. The information existed; the answer did not.

One revision sat in a manufacturing traveller, the change rationale was buried in email, and the approved design output remained in the OEM’s Design History File. We rebuilt the evidence chain manually before I could confidently say yes or no.

That episode captures a recurring problem in medtech: teams do not necessarily lack documents. They lack dependable relationships between documents.

At a contract manufacturer, our quality system handles incoming inspection, supplier COA verification, non-conformance, CAPA support, and sub-tier audits. Product design control often remains with the OEM. The difficult interface is where one organisation’s controlled change meets another organisation’s manufacturing evidence.

A document archive is not a connected technical file

The familiar design-control expectations in ISO 13485 §7.3 and FDA 21 CFR 820.30 include controlled design inputs, outputs, review, verification, validation, and changes. For products placed on the EU market, the corresponding technical documentation must demonstrate how those controls were applied.

The standards do not prescribe a particular user interface. But a practical technical file should make the following chain inspectable:

Intended use or use case
Associated hazards and risks
Design inputs and risk controls
Design outputs
Verification and validation activities
Test protocols, results, and approved evidence

The value is not the number of links. It is the ability to move forward and backward through that chain without opening five folders and guessing which revision is current.

The design technical file walkthrough shows this as a connected workflow: use cases, risks, design inputs and outputs, and tests remain linked as work changes. It also demonstrates AI-powered search for locating relevant elements quickly.

That is closer to how design controls behave during a live programme than a PDF index assembled the week before an audit.

“Real time” should mean visible state, not automatic compliance

A connected file becomes useful when people work with it. If a supplier changes a process, a material, or a test method, the affected records should not silently remain green.

Here, real time should mean that status and relationships remain connected to their source records. It should not mean that software decides whether a change is acceptable.

The connected view is only as trustworthy as the data feeding it. An audit-ready system cannot treat an uncontrolled spreadsheet upload, an expired revision, or an unapproved test result as equivalent to approved evidence. Traceability still depends on document control, ownership, approval state, and review discipline.

That distinction matters more to me than another polished dashboard.

AI search is useful only when a human can verify it

I am sceptical of most AI-in-QMS marketing, including my employer’s. “AI-powered search” can sound like a claim about intelligence when it may only be a claim about convenience.

Still, search is valuable when design and quality teams use different vocabulary for the same thing. A hazard register may describe an insertion force. A requirement may use a different term. A test protocol may identify neither phrase.

A useful search experience lets someone ask:

Where is the verification evidence for the risk control associated with this design input?

It should then return source-linked candidate records rather than a generated paragraph that merely sounds authoritative. Before I rely on a result, I want to see:

The underlying document or record
Its current revision
Its approval status
The relationship being searched
Any links to stale or superseded items

AI should narrow the search space, not adjudicate compliance. This is controlled assistance: a reviewer must be able to inspect the source, challenge the result, and record the decision.

The same reviewability standard should apply to AI-driven CAPA assistance elsewhere in the QMS. A generated answer is not evidence. An approved record, with provenance and history, is.

The audit test I would use

Before believing that a technical file is connected, I would run a small change-impact exercise rather than follow the happy path.

Pick one active use case and trace it to its risk, design input, design output, and test evidence.
Start from an approved test result and trace backward to the requirement and risk it verifies.
Introduce a controlled change to a process, material, or test method.
Check whether affected records and approvals are visible without manual spreadsheet comparison.
Use search to retrieve the exact approved evidence, then inspect its revision and status.

If the first two steps require document archaeology, the file is an archive with hyperlinks. If a controlled change produces no visible downstream impact, the links are decorative.

Where qmsWrapper fits—and where it does not

qmsWrapper publicly positions itself around structured documentation for FDA DHF and EU MDR technical files, together with AI-powered search for audit-ready evidence. That is a sensible focus for device manufacturers and SaMD teams. For a small organisation preparing for a notified-body audit, connected design documentation can remove a substantial amount of manual evidence hunting.

My own use case is different. I work on the supplier side of a contract manufacturing organisation, with more than 40 suppliers, incoming inspection controls, supplier COAs, and sub-tier audits to manage. qmsWrapper can sit alongside custom supplier-side automation, but it does not qualify a supplier, verify a certificate of analysis, or replace a supplier-quality process.

I would push back on any description of it as a complete supplier-side eQMS. That is not where it fits. A CMO needs the design-document workflow to connect cleanly with supplier controls; it does not need those two systems to pretend they are the same thing.

For design-control teams, the linked walkthrough is worth using as a stress test. Pick one risk, follow the evidence chain, make a controlled change, and then ask whether the technical file shows the impact and retrieves the right evidence instantly.

That is a more meaningful test than counting features in a demonstration.

Disclosure: I work on qmsWrapper and am giving my honest read of where it fits—and where it does not.

Which link in your design-control workflow still requires a manual evidence hunt before the next audit?

Our traceability matrix was six months stale. The spreadsheet was never the real problem.

Rajiv Iyer — Sat, 31 Oct 2026 05:50:41 +0000

Our traceability matrix was six months stale, and I hated every cell of it. The surprising part was that replacing the spreadsheet with a more expensive eQMS would not have fixed the underlying problem.

During a notified-body review of a customer design file, the reviewer asked to see how a revised design requirement connected to its specification, risk control, verification evidence and design-change record. We produced the matrix quickly. The evidence behind it took much longer to assemble.

That gap told us more than any procedural non-conformance could.

A matrix is not a ceremonial annex

It is tempting to describe the traceability matrix as the first document a notified body asks for. That is not universally true, and claiming otherwise would be theatre. But it is often one of the first views an assessor requests because it compresses the design-control system into something navigable.

The matrix is not a separately named regulatory deliverable in ISO 13485:2016 or FDA 21 CFR 820.30. Instead, the expectations sit across the framework:

ISO 13485:2016 requires documented design and development evidence and control of design changes.
21 CFR 820.30 addresses design requirements, outputs, verification, validation and design changes.
ISO 14971 expects risk controls to remain connected to the requirements and evidence that demonstrate their effectiveness.
EU MDR Article 10(9) and Annex IX place design and production controls inside the manufacturer’s quality-management system.
IEC 62304 adds another traceability layer when software is part of the design.

No single row proves compliance. What matters is whether a requirement remains linked through its complete life.

For us, the matrix had become a snapshot of an earlier conversation. The controlling records continued moving, but the spreadsheet did not.

How our “living” matrix became archaeology

We support manufacturing programmes for global medtech OEMs. Each customer had its own document repository, revision convention and change process. Our site maintained manufacturing specifications, process-validation records, supplier controls and internal verification evidence.

The matrix was supposed to connect those records. In practice, it contained copied identifiers, manually maintained revisions and links to files stored in several locations.

A design requirement changed. The specification followed. The verification protocol was updated and a new report issued. The matrix still pointed to the previous revision. In another row, a risk-control record had been revised without the matrix being updated.

Nothing dramatic had happened. That was the problem. Each individual record had been controlled. The relationships between them had not.

The spreadsheet was not the villain. It was a perfectly reasonable starting point. The failure was treating copied data as if it were live traceability.

What I now expect a controlled matrix to show

For every design requirement, the traceability chain should provide enough context to navigate forward and backward without relying on institutional memory:

The controlled requirement and its current revision.
The related design specification or design output.
The relevant hazard, risk-control and risk-management references.
The verification method, protocol, report and outcome.
Design-validation evidence where applicable.
Every associated design change and impact assessment.
Record owner, approval state and effective date.

The important distinction is between a value copied into a cell and a controlled link to the authoritative record. A copied revision will eventually become wrong. A live link can reveal that the source record has changed and trigger a review.

A useful matrix should also expose orphaned evidence. If a verification report has no requirement, a changed specification has no impact assessment, or an approved design change has not reached verification, those are gaps—not administrative noise.

For a small medical-device company, Excel can still support this model. It can also support an uncontrolled mess. The tool matters less than the rule that authoritative records are linked, changes trigger review, and humans approve what is published.

The CMO boundary generic eQMS discussions often skip

This is where my perspective differs from the usual device-maker narrative.

At a contract manufacturer, we do not own every part of the product design. The OEM may control design requirements, the risk-management file and design validation. We control the manufacturing translation, process validation, supplier qualification, incoming inspection and related non-conformances.

That ownership boundary has to be visible.

A supplier certificate of analysis may confirm that incoming material met an agreed specification. It does not, by itself, verify an OEM design requirement. A supplier corrective action may resolve a component issue without proving that the design risk control remains effective. A manufacturing process change may have no design impact—but somebody has to make and document that determination.

The useful connected workflow is therefore not one undifferentiated list of documents. It is a controlled chain with explicit ownership:

OEM-owned design evidence.
CMO-owned process and supplier evidence.
Shared impact assessments where the two meet.

Any matrix that blurs those boundaries creates false confidence. It may look complete while quietly implying that a supplier record closes a design-control obligation that only the OEM can close.

AI assistance should expose uncertainty, not hide it

AI-assisted traceability checks could compare changed requirements and specifications, identify missing verification links and propose updates to affected rows. That is useful, particularly when change control already suffers from CAPA backlogs.

But the assistance must remain controlled. A reviewer should see the source record, the proposed change and the reason for the recommendation before anything enters the approved matrix. An AI-generated update does not become controlled evidence merely because it was generated quickly.

The same principle applies when an automated CAPA triggers a change-impact review. Automation can identify the possible touchpoints. A qualified person still has to determine whether the product design, risk assessment or verification evidence is affected.

In other words, the goal is not a faster first draft. It is reviewability, traceability and a visible audit trail.

The product boundary I keep testing

qmsWrapper publicly positions its Advanced Design Control Traceability Matrix around consistent execution with built-in traceability and live, updatable links across design requirements, design specifications, verification and design changes. That is the right architectural shape for a device maker.

However, I run supplier quality at a CMO with more than forty suppliers, and qmsWrapper is built and marketed for device makers and SaMD teams, not specifically for CMO-side supplier work. I would not use a device-maker traceability matrix as evidence that supplier COAs, incoming inspection or sub-tier audit findings are covered without seeing that workflow demonstrated. The supplier-design boundary is the part I keep testing.

I work on qmsWrapper and am giving my honest read of where it does not fit.

The five-minute test I would run before an audit

Before the next design-file review, I would open the matrix and try to complete five actions:

Select a recently changed requirement.
Follow it to the current specification.
Navigate to the associated risk control.
Reach the current verification report.
Identify the change record that explains the revision.

If any step requires someone to remember another spreadsheet, search a shared drive or contact the person who originally built the matrix, the matrix is not living. It is an archive with links.

Our six-month-stale spreadsheet was embarrassing. More importantly, it exposed a broken connected workflow. Fixing it required more than changing the colour of a cell; it required deciding which records were authoritative, who owned each relationship and what would trigger review when those records changed.

Which link in your design traceability chain is still maintained through memory rather than a controlled record?

The 80/20 complaint about ISO 13485 audits misses the real problem

Rajiv Iyer — Sat, 24 Oct 2026 06:14:48 +0000

During a recent customer audit, a reviewer asked me to produce three records for one rejected component lot:

The incoming inspection report
The nonconformance record
The corrective and preventive action record

We had all three. What we did not have was a defensible chain between them.

The material had been quarantined before use. The supplier had responded. The CAPA existed. But the evidence sat in an incoming-inspection application, a shared drive and a CAPA spreadsheet.

The reviewer was not primarily interested in why the component failed. They wanted to know:

Was the record approved and current?
Did it identify the affected lot?
Was the supplier evidence attached?
Did the disposition reference the investigation?
Did the effectiveness check close the same issue that was opened?

We spent the morning reconstructing the history. The underlying quality work was sound; the proof was fragmented.

Why auditors end up in the document room

I do not have credible stopwatch data proving that ISO 13485 auditors spend exactly 80% of their time on formatting and 20% on quality. I would not manufacture that statistic from a handful of audits.

But I can defend a related practitioner observation: a large portion of audit preparation at our contract manufacturing site is spent making evidence understandable, retrievable and connected.

This is partly what ISO 13485:2016 asks for. Auditors can sample documented information related to:

Document control under clause 4.2.4
Record control under clause 4.2.5
Monitoring and measurement under clause 8.2.6
Control of nonconforming product under clause 8.3
Corrective action under clause 8.5.2

Quality-system conformity is demonstrated through evidence. When that evidence is incomplete, outdated or disconnected, the reviewer must reconstruct it.

That does not mean auditors are obsessed with neat binders. A procedure without execution evidence is merely a claim. A training record without evidence that the trained activity occurred is another claim. A CAPA without a documented effectiveness review is an unfinished claim.

Formatting becomes the visible burden because traceability is the underlying requirement.

Where CMO reality makes the multiplier worse

We work with more than 40 suppliers and process close to a thousand certificates of analysis in a typical quarter. Each certificate may need to be connected to:

The supplier and manufacturing site
The material and lot
The applicable specification revision
The incoming inspection result
Any nonconformance or deviation
The final material disposition

In a device-maker’s QMS, much of this evidence is internal. In a CMO, it crosses organisational boundaries.

An OEM may own the design and control the specification. We own incoming inspection, supplier performance, production controls and manufacturing records. The quality event may begin in a supplier’s process, continue in our goods-in area and end in a disposition recorded by our team.

When each handoff has its own format and storage location, formatting effort multiplies.

A supplier may provide a valid certificate with a clear result, but if it cannot be joined to the lot we inspected, our team spends time transcribing and reconciling it. The incoming inspection may be correct, but if its reference to the certificate is buried in a note field, the reviewer will still have to reconstruct the connection.

Nobody in that chain necessarily failed to do the right technical work. The system failed to preserve the proof.

The distinction I wish audit reports made

There is a difference between cosmetic formatting and traceability work.

Formatting waste looks like:

Converting the same record into several file formats
Renaming files to satisfy a checklist
Copying information into a template after it was captured elsewhere
Maintaining parallel spreadsheet and QMS versions

Traceability work looks like:

Linking the supplier certificate to the inspected lot
Connecting a nonconformance to its containment decision
Preserving CAPA ownership, evidence and effectiveness checks
Showing how a risk assessment changed after corrective action

Auditors require the second category. Process automation should remove the first.

The problem is that many QMS tools are good at generating compliant-looking records without solving the joins between operational evidence. The output becomes polished, but the history is still fragmented.

Automation should preserve the decision, not decorate it

For a small medtech manufacturer, useful automation should do at least four things.

Capture information once, close to the work where it happens.
Preserve links between records, lots, suppliers, risks and actions.
Keep human review and approval visible.
Make missing evidence or unresolved actions obvious.

Controlled assistance can help here. AI-assisted CAPA drafting may summarise inspection history, supplier responses and recurring nonconformances. But the generated explanation must remain reviewable and traceable to its sources. A polished root-cause paragraph without evidence behind it is merely formatting at a higher level.

This is where I remain sceptical of broad “AI in QMS” claims, including those around our own products.

qmsWrapper publicly positions itself around quality workflows for device makers and SaMD teams, including a bridge between development work in Jira and quality oversight for FDA and ISO 13485 workflows. That connected-workflow model is relevant to many SMEs.

But at a CMO, “connected” has to include supplier evidence, lot genealogy, incoming dispositions and CAPA effectiveness across external boundaries. I would not assume a device-maker-oriented workflow automatically solves the supplier-side traceability problem we face.

Disclosure: I work on qmsWrapper and am giving my honest read of where it does not fit.

We should measure readiness differently

Page count is a poor measure of audit readiness. I would rather track:

Time required to reconstruct a material-disposition decision
Number of duplicate evidence records
Broken links between nonconformances, CAPAs and effectiveness checks
Overdue supplier corrective actions
Time from nonconformance detection to documented containment
Whether recurring supplier issues update the associated risk assessment

These measures tell us whether the QMS supports operational quality. They also expose whether process automation is removing work or simply producing more records.

The unpopular opinion I would defend is not that auditors are unfair or that formatting is quality. It is that a mature QMS should make operational quality easy to demonstrate. If most audit time goes into reconstructing documentation, the QMS has become a document repository with workflow attached.

For QA and RA leaders reading this: which part of your next notified-body audit consumes more time—finding the record, proving that it is current, or reconstructing the decision behind it?

One-line design changes are not one-line changes

Rajiv Iyer — Tue, 20 Oct 2026 06:48:34 +0000

The change notification arrived with one line describing the change. "Update mating feature per DFMEA revision B." That sentence touched twenty-three verification reports across four part families, two of which were already in distribution.

I am writing from a contract manufacturer's bench. We manufacture components to our customers' drawings, and design changes arrive as revisions rather than fresh starts. The version our OEM customer issues is rarely the version we end up working with. We need to know, for every change, which drawings we hold, which inspection plans we have approved, which work instructions we have trained, and which verification records are now stale. That map cannot live in someone's head.

What "traceability" actually means in design control

The intent behind the design and development clauses in ISO 13485, and the equivalent expectations under MDR, is that an organisation can answer a small set of questions quickly and reliably:

Which requirement does this design output satisfy?
What verification demonstrated this output meets the requirement?
What changes have been made to the requirement, and which outputs and verifications are now affected by that change?

The whole exercise is in service of those questions. A requirement traceability matrix is the conventional answer. I have seen them in Excel, in SharePoint lists, and in the heads of engineers who have worked on the same product for years. They work, until they don't.

Memory is not a control

The first time I watched an engineer trace a single design input through to its verification record, it took her fifteen minutes. She knew where to look because she had been involved in the original transfer. A year later, when a similar trace was needed for a different part, the same engineer took three days. Two of those days were spent finding the colleague who originally wrote the verification protocol, because he was the only person who remembered which test report ID mapped to which clause.

That second trace was the trace that mattered. It was needed for a customer audit, and the question being asked was exactly the one the standards are written around. The answer, when we eventually produced it, was correct. The journey was an audit finding waiting to happen.

What "connected" looks like in practice

A traceability matrix that lives as a single document is brittle. The relationships need to exist in the system, not on the page. When a change happens, the propagation looks like this:

A requirement is updated. Every design output linked to that requirement is flagged for review.
An output is updated. Every verification referencing that output is queued for re-assessment.
A verification protocol is revised. The linked requirement becomes the starting point for re-review.

I have spent the last year wiring these links together with a small Python service over a Postgres database. The structure is simple: a requirements table, a design outputs table, a verifications table, and a changes table. Foreign keys hold the relationships. A single view shows the full chain for any requirement, and a change event fires alerts to the owners of every record in scope. No one's memory is on the critical path.

The slow part is not the database. The slow part is convincing people to enter the relationships as they work, rather than reconstructing them after the fact. A retroactive matrix is a forensic exercise. A forward-built matrix is a byproduct of doing the work.

What I would still do differently

The system does not replace review. It surfaces what needs to be reviewed. A change still needs a human to decide whether the linked verifications need to be repeated, whether the linked risk controls need re-evaluation, whether the linked work instructions need re-training. The map points; it does not decide. That distinction matters, because reviewers are the control, and the system provides reviewability.

I would also start earlier. The cost of wiring relationships after a design has been transferred is real, and it scales with the number of linkages. The cost of wiring them during transfer is part of the transfer. We have a habit now of treating traceability links as a transfer deliverable, not a transfer follow-up.

The thing I would change most: I would make the change-impact view visible to the people who actually receive the change, not just to QA. When an OEM customer sends us a revision, the production engineer, the supplier quality engineer, and the inspection planner all need to see the same scope. Putting it on a shared screen saved more time than any report I have written this year.

A question I keep returning to

When you receive a design change, how long does it take you to answer, with proof rather than memory, the question of which verification records are now affected?

AI drafted the impact list. I still own the audit answer.

Rajiv Iyer — Mon, 19 Oct 2026 04:02:53 +0000

The change that looked small

Last month, a change request landed on my queue for a heat-treat subcontractor who had moved two of their furnace zones to a different EMS provider. Twelve components in scope. Four device families downstream. The change form asked one question at the top: which DHF documents does this touch?

For a Class IIa implant component, that question is not a checkbox. Get it wrong and the notified body's next surveillance audit will find orphaned drawings, outdated process validations, or a sterilization map that no longer reflects actual load patterns. Before our QA team in Germany closes the change, somebody has to think through the cascade.

That somebody is, and remains, a human.

What the AI did well

The same change request fed into an automated impact analysis. It pulled cross-references from our PLM, matched the affected part numbers against the active device master records, and produced a draft list of impacted documents inside a couple of minutes. Compare that to the afternoon I would have spent pulling the same list by hand, cross-referencing supplier codes against DHF indices, and chasing confirmations from four process engineers.

The draft was 80% there. It caught the obvious items: the validation protocol for the heat-treat cycle, the incoming inspection procedure for the affected surface finish, the supplier quality agreement itself. It also flagged two drawing callouts that had been quietly outdated for eighteen months and were, frankly, due a refresh anyway.

What the AI did not know

The draft missed three things:

Two of our implants share a sterilization load configuration that is not formally linked to the heat-treat step, but is affected because the new EMS vendor uses a different tray geometry.
One device family had moved to a different cleaning process six months earlier, and the impact on that line was different from the cleaning process used by the other three.
A long-standing CAPA whose corrective action was tied to this exact furnace's temperature uniformity map.

None of that lives in a part number. None of it sits in a cross-reference table. It lives in the heads of two process engineers who have been on the line for the better part of a decade, and in the CAPA log they are still working through.

AI-assisted impact analysis will surface what your data structure can express. It will not — and probably should not — pretend to know the things only your team knows.

What the standard actually requires

Under ISO 13485:2016's document control and change control requirements, changes have to be reviewed and approved prior to issue, with the impact considered and the rationale recorded. The phrasing is deliberate. "Reviewed" implies a human has interrogated the reasoning and signed off on it. "Approved by" names a person, not a system.

EU Annex 11 and 21 CFR Part 11 both come into play when the impact analysis lives in an electronic QMS. The audit trail has to show who reviewed, when, and what they actually considered. A status of "reviewed and approved" with no record of what the reviewer looked at is not compliant. It is a checkbox.

If an AI drafted the impact list, the audit trail has to show what the AI produced, what the reviewer added, what they removed, and what they left alone. Otherwise the next auditor will ask, reasonably: how do you know this was a thoughtful review and not a click-through?

The accountability frame

Here is how I draw the line for my own team:

The AI proposes an impact set. It is drafting work, not a decision.
The human reviewer accepts, rejects, or amends each item. Each decision gets a recorded note against that item.
The approver (a different person, usually the QA manager) signs off knowing the reviewer has attested to their own judgments, not just rubber-stamped the AI's output.
The whole chain — prompt, response, reviewer notes, approval — is retrievable for the audit, not because the AI is exotic, but because the change is regulated.

This is the line I keep coming back to: AI helps you surface impact; accountability lives with the human who reviewed the reasoning. The two statements are not in tension. The first is a productivity claim. The second is a regulatory claim. Mixing them up is where QMS leaders get themselves into trouble.

What to look for in any controlled assistance

If you are evaluating AI assistance — automated CAPAs, AI-driven CAPA assistance, AI-guided impact mapping, whatever the marketing calls it — the question is not whether the model is clever. It is whether the reasoning is reviewable and the audit trail holds. Concretely:

Can you see the inputs that produced the output?
Can the reviewer leave a per-item justification that survives the next system upgrade?
Does the approval step bind to a human identity, with a date and a hash of what was approved?
Is the AI's reasoning itself covered by the same change control as the rest of the QMS, or does it live in a side process that nobody owns?

If the answer to any of these is "we will figure that out later," the system will fail an audit before it fails technically. Process automation is only as defensible as the records it leaves behind.

Open question

In your QMS, can your auditor trace a single change from "AI suggested X" all the way through "the reviewer assessed X and concluded Y because Z"? Or is the AI's contribution still a black box on the far side of someone's approval signature? I would be curious how others are handling the review-record problem in practice.

Your eQMS shortlist collapses back to forms. Here's what a real workflow engine actually does.

Rajiv Iyer — Sun, 18 Oct 2026 08:30:13 +0000

I spent most of last quarter evaluating eQMS platforms for a manufacturing function that handles roughly 40 suppliers on behalf of three OEMs. Every demo ended the same way: the "workflow engine" turned out to be a form builder with conditional fields, an email step, and a status column.

This post is the genuine ask, framed from the supplier side. If you're a small to mid-size medtech manufacturer (Class I to IIb, two-person QA/RA, a CAPA queue that keeps you up, change control that lives in someone's inbox), here's what I think you're actually hunting for and why most shortlists quietly collapse.

The form-builder trap

A form builder lets you do this:

Define a CAPA form with fields
Add conditional routing — "if Risk = High, route to QA Manager"
Send an email when the form is saved
Show a status column in a list view

That covers maybe 30% of what ISO 13485 §4.1.4 and 21 CFR §820.40 actually ask for from process control. The other 70% is process behaviour: state machines, parallel branches, SLA escalation, rollback on rejection, automatic re-trigger when a related record changes, and an audit trail at the process-instance level — not just the form-revision level.

The litmus test I now use in demos: when a user clicks "Reject" mid-flow, does the system know what state the record should return to, who needs to be notified, whether dependent records are now invalidated, and what the regulatory significance of that rollback is? Form builders hand-roll each of those rules as field logic. Real process engines model them inside the workflow definition itself.

What the standards actually ask for

ISO 13485:2016 §4.1.4 wants processes to be planned, monitored, and records that "provide evidence that the processes are carried out as planned." §8.5.2 (CAPA) and §8.5.6 (control of changes) want documented procedures, plus verification of effectiveness.

21 CFR §820.40 spells it out for CAPA — documented procedures that include requirements for:

analysing process and quality data to identify nonconformities
investigating the cause of nonconformities
verifying that the corrective action does not adversely affect the ability to meet regulatory requirements
implementing and documenting changes

That last bullet — changes — is where form builders consistently fall over. In our world a CAPA triggers a change in an incoming inspection plan, which then has to push to a supplier corrective action request, which may itself loop back as a new CAPA. A form builder wants three separate forms with three separate workflows and a tired human gluing them together at every step.

What a real workflow engine gives you

In my current stack — custom Python + Postgres, rebuilt twice in five years — these are the things I'd refuse to give up:

A state machine per record type. Not field values driving routing. An explicit model of states and transitions, with the audit trail living on the transitions themselves.
Process-instance IDs that survive across modules. A CAPA that triggers a change triggers a risk re-assessment. The engine should use one ID that traces through all three.
SLA escalation that is configurable, not scripted. When the CAPA owner hasn't responded in 14 days, the engine routes to their manager — it does not only send a reminder email.
Conditional subprocesses that can run in parallel. A risk re-assessment might need input from regulatory while a document update goes to document control simultaneously.
Replayable history. When a notified body or an OEM customer asks "show me every state this CAPA has been in," I want a query answer, not a screenshot chain.

The honest shortlist criteria

If I were rebuilding the shortlist today for a small medtech team with limited bandwidth, I'd ask each vendor four things:

Show me a CAPA workflow with parallel branches, a rollback path, and an SLA escalation. Show me the process definition, not the form.
When a CAPA closes and downstream records are still open, does the engine know — or does it require a human?
Show me the audit trail for a process instance, not a form revision.
Show me a change request that automatically triggers CAPA, risk, and document control records — and trace the linkage between them with one ID.

If they can only show form revisions and email logs, you have a form builder. The branding won't save you.

What I'd do differently next time

I'd stop shortlisting from feature comparison spreadsheets. The features matter, but the architecture underneath does more of the work. I'd ask for a reference customer in the same regulatory class, ask to see their worst-case workflow (not the demo workflow), and ask what the vendor cannot do. That last question has saved me more time than any demo.

If you've actually seen a platform handle the CAPA → Change → Risk loop without a human being the glue, I'd genuinely like to know which one. The shortlists I keep building collapse back to form routing, and I'd like to know what a real option looks like.

The standard is 80 pages. Our QA team only needed to read the workflow.

Rajiv Iyer — Sat, 17 Oct 2026 12:09:28 +0000

The 80 pages of ISO 13485 don't help when a CAPA owner is staring at a blank form at 4 PM on a Friday, two days before a supplier non-conformance has to be triaged.

We are a contract manufacturer. Three OEMs send us drawings; forty-odd suppliers send us components. Most of our CAPAs start somewhere in that supplier traffic. About four years ago, our QA lead — one of the sharpest people in the building — was burning hours she didn't have, not because she didn't know the standard, but because she had to mentally translate it every single time a change, a CAPA, or a supplier NCR landed. The standard was a book. The workflow was a blank field. She had to fill the gap between them from memory, every time.

The shift that fixed this was small in language and large in consequence: we stopped handing people the standard and started handing them the workflow. The workflow carries the standard now. She carries the judgment.

What "workflow-driven compliance" actually means

A well-designed QMS workflow is not a digital form. It is a set of branching questions and gates that encode the standard's decisions. When a CAPA is opened, the workflow does not ask "what happened?" — it asks "is this a process non-conformance, a product non-conformance, or both?" and then routes to the right downstream task. The clause of the standard that requires showing capacity is satisfied by process. The structure is the compliance.

The phrases that matter here are controlled assistance, reviewability, and traceability. A good workflow tells the user what to do, but every step is logged, every approval is captured, and every output is traceable back to the requirement it satisfies. That is the difference between an AI that helps a quality manager write a CAPA and one that carries the CAPA-driven risk assessment through to the change control record. We want the second one.

Three things a workflow should do without being asked

These are the three capabilities I would flag for any SME QA lead who is choosing — or building — a QMS:

It should ask the questions the auditor will ask. If a notified body auditor traces a CAPA back to a risk file, the workflow should already have linked them. If a process change triggers a document re-review, the workflow should already have flagged the affected docs. The audit trail should be a side effect of doing the work, not a separate exercise.
It should connect change, CAPA, risk, and document control as one connected workflow. Most QMS implementations keep these as separate modules and bolt them together with email. That is where things fall apart. Native workflow integration means a CAPA can drive a risk re-evaluation, which can drive a change, which can drive a doc revision — without anyone copy-pasting record IDs.
It should support AI-assisted drafting without removing human review. Automated CAPA assistance is useful for first-pass root-cause suggestions and impact-mapping, but every AI output must be reviewable. The quality manager signs, the QMS records the revision, the audit trail is clean. Safe assistance for CAPAs looks like this: the AI drafts, the human decides, the system remembers.

Where the limits are — and where they always will be

A workflow cannot replace judgment. It cannot tell you whether a supplier's process change actually constitutes a process change under your quality agreement. It cannot tell you whether a complaint pattern is a signal or noise. What it can do is make sure that, when the quality manager applies judgment, the right records get linked, the right approvals get requested, and the right documents get reviewed.

This is the part I would have done differently four years ago. I would have spent less time configuring validation evidence and more time on the branching logic of the workflows themselves. Process automation done well is mostly a question design exercise. The standard gives you the requirements. The workflow gives you the conversation. Build the conversation first.

A small practical example

A supplier sends a CoA that does not match the spec on a single parameter. The old workflow asked the inspector to classify the NCR manually — process, product, or both — and then she had to remember whether to open a CAPA, whether to flag the supplier for re-qualification, and whether the deviation had any impact on released product. The new workflow asks one question, branches on the answer, and creates all three records with the right links if they are required. The quality manager reviews, signs, and moves on. The standard is satisfied. The audit trail is intact. The Friday is free.

The standard is not the enemy. It is, however, not the right thing to hand to a quality manager when her actual job is making a judgment. The right thing to hand her is a workflow that has already read it, has already linked the relevant clauses, and asks her only the questions that genuinely need a human answer. Everything else should be process automation, controlled and reviewable.

How are you encoding your standard into your QMS workflows — and where have you seen the branching logic break down in practice?

From spreadsheets to a controlled QMS: the four things the foundation must do

Rajiv Iyer — Fri, 16 Oct 2026 07:50:42 +0000

The first CAPA log I ever maintained lived in a shared Excel file with version numbers in the filename. Last modified by initials in the footer, like a medieval manuscript colophon. It worked — until it did not.

I lead quality at a contract manufacturing organisation in Bangalore. Three global medtech OEMs route components through us. We sit on roughly forty active suppliers feeding our own line. Two years in, the CAPA log had grown past the point where anyone could confidently say which actions were open, which were overdue, and which had quietly been closed in a chat thread that never made it back to the file.

That is the moment you discover what "controlled" actually means in a QMS context.

The three records that have to stay linked

In plain terms, ISO 13485 wants you to demonstrate three things with evidence:

That a defined process exists, was followed, and produced a record (forms and process records).
That the people doing the work were competent to do it (training records).
That when something went wrong, it was investigated, addressed, and prevented from recurring (CAPA records).

The hard part is not any one of those. The hard part is the link between them. The training record needs to point back to the procedure the person was trained on. The CAPA needs to name the nonconformity it was raised against, the process record that triggered it, and the training update that came out of it. When those links live in separate spreadsheets — or worse, in separate people's memories — the system is no longer a system. It is a collection of documents that happens to live in the same folder.

What spreadsheets actually break

Most medtech SMEs start with spreadsheets and many stay there longer than they should. The pattern is predictable:

Shared files accumulate versions faster than anyone reviews them. Latest_FINAL_v3_use_this_one.xlsx is not a controlled record.
Filename discipline erodes the moment someone is on leave.
Audit trails are absent by default. Who changed which cell, and why, is unfindable.
Cross-references are typed by hand. The CAPA log says "see NCR-127." Does NCR-127 actually exist in the same workbook? Is it part of a connected workflow at all, or stranded two folders away?
Review and approval happen out of band — in email, in chat, or verbally. The record never reflects that approval happened.

ISO 13485:2016 §4.2.4 and 21 CFR 820.180 both ask for records that are legible, readily identifiable, and retrievable. The clause reads simply. Living with it for ten years tells you how strict the expectation actually is.

What the foundation has to give you

If you are evaluating — or building — the first controlled QMS for a small manufacturer ahead of a notified-body audit, the foundation should do four things well, in order:

Hold records, not just files. A form submitted today needs to be timestamped, attributable, and immutable once approved. If your team can edit last month's inspection record by opening the file, you do not have a controlled record.
Link records by reference, not by copy-paste. A CAPA should open against a specific nonconformity. A training assignment should attach to a specific procedure revision. The link is the system.
Make review and approval a visible workflow. Reviewers need to see what they are approving, record their decision, and produce evidence that the decision was made on a specific date by a specific person. A small amount of process automation here — routing, escalation, reminders — pays for itself faster than any dashboard you can build.
Survive your first audit. If an auditor asks for every CAPA raised in the last year and every record linked to each one, you should be able to produce that list in minutes, not days.

Notice what is missing from that list: dashboards, AI assistants, supplier portals, fancy analytics. Useful, eventually. Not the foundation.

What I would tell someone starting now

If a two-person QA-RA team asked me which capabilities to prioritise for their first controlled system, the answer is unglamorous.

Forms that enforce fields — dates, signatures, required attachments — instead of capturing whatever the operator typed.
A training register that ties each role to specific procedures and shows competence status at a glance.
A CAPA log that does not allow closure without a verified effectiveness check and linked evidence.
A document control workflow where revisions are versioned and superseded files are not deletable.

Everything else — risk management integration, supplier qualification, complaints handling, change control — is downstream of those four. If the foundation is right, the rest of the modules slot in. If the foundation is spreadsheets pretending to be records, every module you bolt on top inherits the rot.

The CAPA log in our shop today is traceable back to the inspection records, the training records, and the change tickets that touched the affected procedure. When a notified body auditor asks how a particular NCR was handled end to end, the answer is a single search, not a tour through four shared drives.

That is what "controlled" buys you. Not software. Connected, reviewable, traceable records — whatever system holds them.

Open question

For the small medtech teams reading this: what broke first in your current setup — the CAPA log, the training register, or the links between them?

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?