DEV Community: Priya Nair

The "minor change" paradox — when one-line fixes turn into three days of change control

Priya Nair — Sun, 27 Sep 2026 12:40:28 +0000

Last March I caught a typo in an IFU. One word, wrong, on a single page. I knew it would take five minutes to fix in InDesign and ten minutes to get re-approval. Total elapsed time, including the coffee break I planned to take after: half an hour.

It took me three days.

That is the minor-change paradox. The change is trivial; the documentation around it is not. And if you skip the documentation, you will discover why at your next audit.

Let me show you what those three days actually contained.

What "one line of work" expanded into

The typo was on page 7 of an instruction for use for a Class IIb device. The word was "subcutaneuous". My morning looked like this in the end:

Pulled the document from the controlled documents register and confirmed revision status
Confirmed the typo was not already captured by an open change request (it was not)
Checked whether the same typo existed in any other language version — five were in scope
Opened a change request, described the change, classified it under the change control SOP
Risk-graded the change: low severity, low probability, no clinical impact — but still documented
Checked impact on linked documents: the Declaration of Conformity references the IFU revision, the labelling matrix references the IFU, the PMCF plan references the IFU. None changed in substance, but the version pointer needed an update in two of them.
Got the change reviewed by QA, by the SME for the device, and by the original IFU content owner
Got QA approval, raised the IFU revision, re-released to the controlled library
Updated the version pointers in the two linked documents (separate change request, separate approvals)
Closed both change requests, logged the audit trail, filed evidence in the Technical File

The actual word change took the five minutes I expected. The rest is what change control is.

What the standards actually ask for

This is not bureaucracy invented by my SOP writer. It is what the framework requires, across three overlapping instruments.

ISO 13485:2016 Section 8.5.6 requires the organisation to evaluate changes, determine their significance, perform a risk-based review, and approve changes before implementation. The standard does not say "unless it is small". The phrase "any change" is doing real work in that clause.

FDA 21 CFR 820.70 covers design changes and explicitly requires written procedures, review and approval before implementation, and evaluation of the change's effect on the product. The expectation is documentation proportionate to risk — but documented is the operative word.

Under EU MDR, the manufacturer's general obligations in Article 10 include keeping the Technical File up to date. Annex II paragraph 6.1 requires a documented change control procedure. MDR does not have a "trivial change" carve-out either. Granted, Article 120 gives some breathing room on legacy devices, but the change control obligation itself is unchanged.

To be fair, all three frameworks allow you to scale the rigour. A one-character typo in an IFU is not a design change. It is a document control change. But it still has to be a document control change, not a person quietly editing a PDF and pushing it to the print queue.

Why "just fix it" is the dangerous instinct

I have watched junior engineers do this. They see a small error, they fix it, they push the new revision to manufacturing. The audit trail shows the wrong word for fourteen months, then the right word, with no change record. The first time a notified body auditor asks "what happened between revision 4 and revision 5?", the answer is silence and the finding is a major non-conformity.

This is the bit I think gets lost in change-control-fatigue conversations. The audit trail is not there to annoy you. It is the evidence you need when, three years from now, a competent authority asks you to demonstrate continuous control of your Technical File. Without it, "minor" becomes "major" very fast.

What I would do differently next time

Three things, with hindsight:

Treat the typo-fix path as a pre-baked change template. Not a free-form change request — a pre-filled record with the impact analysis, the linked documents, the approvals. Halves the elapsed time on the second iteration onwards.
Stop pretending "version pointer update" is the same change as the substantive fix. Separate change request, separate approval, separate audit trail. Combined, it looks faster and breaks traceability later.
Capture the rationale at submission time, not at audit-prep time. Six months on, you will not remember why revision 7 of the IFU does not equal revision 6 plus a typo.

The three days was not wasted. It was the cost of having evidence. I would just like the next three days to be shorter.

Open question

For anyone running a CE-marked device portfolio: where is the line for you between "this is a routine document correction, route it under a lighter change class" and "this is a change that needs full Annex II treatment"? I am interested in how the cut-offs actually work in practice — five-line edits to an IFU, single-character fixes in a Declaration of Conformity, version-number-only updates in a Technical File. How are you drawing the line?

Shortlisting an eQMS for a small Class II team still on paper — what to actually check

Priya Nair — Sat, 26 Sep 2026 14:20:00 +0000

Five years into MDR, the question I get most often from small Class II teams is not "which eQMS is best". It is closer to: what is the smallest thing we can buy that will still pass a notified body audit when we get there, and that will not make us re-implement the whole system in eighteen months.

That is the right question. The wrong answer is the demo-driven one — picking whatever the salesperson showed you with the slickest workflow. The right answer is a shortlist built against what ISO 13485:2016 and MDR Annex IX actually expect from your QMS, scaled to where your team is today, with a credible growth path to where MDR will push you tomorrow.

Here is the practitioner checklist I walk small teams through.

What you actually need digitised before your first notified body audit

For Class IIa under MDR, conformity assessment typically runs through Annex IX (quality management system and assessment of technical documentation). In practice this means your QMS has to demonstrate control over at least:

Document and record control (ISO 13485 clauses 4.2.4 and 4.2.5)
Design and development, including the design history file (clause 7.3, MDR Annex II)
CAPA and nonconforming product (clauses 8.5.2 and 8.3)
Internal audit and management review (clauses 8.2.2 and 5.6)
Supplier control and incoming product verification (clause 7.4)
Post-market surveillance, including PMS, PSUR, and PMCF where applicable (MDR Articles 84–86)

You do not need all of this on day one. But the eQMS you shortlist should be able to hold each of these without a custom build.

"Online forms over our existing processes" — what that phrase should mean

The starting position you describe is sensible, and more common than vendors admit. Most Class II SMEs I have worked with have a working QMS on paper or in shared drives. The mistake is treating the eQMS as a reason to rewrite the SOPs.

What you want from a forms-first deployment:

The system mirrors your current SOPs. You upload the existing forms; the eQMS provides workflow, signatures, and an audit trail.
Approval routing matches your actual org chart, not an idealised one.
Training records are linked to documents, so a revision automatically re-assigns training tasks.
You can extract a clean PDF or XML export on demand for your notified body reviewer.

If a vendor pushes you into a process redesign before you can go live, that is a sign their product assumes you have a larger team than you do.

Shortlist criteria that predict a clean audit later

When I evaluate eQMS for a Class II SME, I score against five criteria that have actually mattered in audit findings:

ISO 13485:2016 clause coverage you can see in the product, not in marketing. Ask the vendor to show you, not tell you.
Document control with version history, approval workflow, and a real audit trail. Audit trails must be tamper-evident and time-stamped.
A CAPA workflow that can be linked upstream to complaints and risk, and downstream to change controls and design history. This is the connected workflow that audit findings hinge on.
Training records tied to documents and roles, with completion evidence.
A clear validation story for electronic records — at minimum EU GMP Annex 11 style controls, even if you are not claiming 21 CFR Part 11 compliance.

Granted, not every vendor will be honest about which ISO clauses their out-of-the-box workflows truly cover. Ask for a mapping document before signing anything.

Red flags worth walking away from

In demos, watch for:

"AI-driven CAPA assistance" with no explainability, no reviewability, no clear human-in-the-loop. If a tool drafts root causes or CAPA plans and you cannot see the reasoning, your notified body will ask, and you will not have a good answer.
Claims of "full MDR support" but no module for PMS plans, PSUR generation, or PMCF. Those are mandatory under MDR Articles 84–86 for most Class II devices and cannot wait.
Pricing that punishes you for adding a fourth or fifth seat. Small teams grow; if the marginal seat is punitive, you will be migrating again in two years.
Mandatory paid implementation services. Templates and configuration should be doable by your own QA/RA lead.
No clear data residency story. EU/EEA residency is a hard requirement under GDPR for most device data.

To be fair, none of these are deal-breakers on their own. They are signals to ask sharper questions.

The growth path — does it survive the next MDR cycle?

The question that matters in year two is whether your eQMS can keep up with what MDR keeps adding. EUDAMED's UDI module is live in parts and broken in others; PMS expectations are tightening under recent MDCG guidance; PMCF methodology under MDCG 2020-13 is becoming more demanding every notified body cycle.

Shortlist only systems where:

You can add EUDAMED-compatible UDI assignment and basic submission support later, without re-platforming.
PSUR generation can pull from PMS, complaints, and CAPA data already in the system — that is what native workflow integration actually means in practice.
Validation documentation can be updated for each release, not redone from scratch.

If a vendor cannot articulate their roadmap against MDCG guidance from the last eighteen months, they are not investing in MDR compliance at the pace you need.

What I would do if I were starting over

Map the six ISO clauses above to your current paper process. Pick the eQMS that covers them most cleanly with the least configuration.
Run a two-week pilot on one process — document control or CAPA, not both — before you commit.
Get the vendor's clause-mapping document and have your QA lead score it against your last mock audit.
Ask three reference customers of similar size how their last audit went with that eQMS in place.

The cheapest mistake is buying the wrong system. The second cheapest is buying the right one at the wrong moment, before your team has the bandwidth to validate it properly. A controlled, reviewable deployment beats a fast one every time.

One question back to anyone reading: for those of you who have already gone through a notified body audit on a small eQMS deployment, what was the single ISO 13485 clause that turned out to matter most in the findings, and did your eQMS handle it out of the box or did you bolt something on?

ISO 13485 does most of the work. The 2026 ISO 9001 revision shifts where the rest lives

Priya Nair — Fri, 25 Sep 2026 10:21:13 +0000

The audit prep spreadsheet for our dual-cert surveillance has six rows for ISO 13485 and two for ISO 9001. That ratio has been roughly stable for the four years I have been at my current role, and it reflects a reality most medical device QMS people know: 13485 carries the load, 9001 is the standard we run alongside it for other reasons.

Which is why the upcoming revision of ISO 9001 deserves a careful look rather than a shrug. The easy answer is "13485 already covers everything that matters, so who cares." The honest answer is more interesting.

Why medical device companies hold ISO 9001 at all

Article 10(9) of the EU MDR requires a QMS. ISO 13485:2016 is the harmonised standard under MDR, so for CE marking that is — operationally — the standard you have to satisfy. ISO 9001 is held for other reasons: a parent company requirement, a non-medical customer asking for "ISO certified" on a tender, some third-country registrations, or occasionally a board that wants the badge.

For a pure EU meddev SME selling only CE-marked product, ISO 9001 is sometimes optional. In practice it stays on the certificate because pulling it triggers internal conversations nobody wants to have.

What the two standards actually disagree on

The widely held belief is that ISO 13485 is "ISO 9001 with extra medical device stuff." That is not quite right.

ISO 13485 is more prescriptive on the things medical device regulators care about: document control (4.2.4), records control (4.2.5), design and development (7.3), purchasing and supplier control (7.4), production and service provision (7.5), CAPA (8.5.2 and 8.5.3), and complaint handling. ISO 9001 covers some of the same ground but at a higher level, and pulls in different themes: context of the organisation, leadership, customer satisfaction, and a broader definition of "interested parties."

13485 also has a few explicit exclusions and modifications relative to 9001 — post-delivery activities in 7.5.5, for instance, are narrower. So the two standards do not align clause for clause, even though Annex SL keeps the structure compatible.

The practical upshot: when we map our QMS to both, the 13485 clauses generate real procedure work. The 9001 clauses mostly need a sentence in the manual and a paragraph in a management review.

What the 2026 revision actually changes

Without going clause-by-clause into FDIS territory, the themes that show up across the draft material are:

Climate change and sustainability considerations inside "context of the organisation"
Risk-based thinking made more explicit at strategic and operational levels
Broader stakeholder and interested-party framing beyond customers
Digital transformation as something the QMS is expected to address
A continued relaxation of prescriptive documentation requirements — less "you shall maintain documented information for X"

For a 13485 shop, the risk-based thinking theme is old news — 13485 has been risk-obsessed since long before MDR made it fashionable. The digital transformation theme is mostly already covered by your design controls and your change control. The documentation relaxation mostly aligns 9001 with how most of us were running it anyway.

The genuinely new content is climate and sustainability in the context-of-the-organisation analysis.

Where it actually bites for a meddev QMS

Here is the honest list:

Context of the organisation: you will need to address climate change as an external issue. Not as a product requirement — your 13485 risk file is not suddenly expected to manage emissions — but as a strategic QMS consideration. To be fair, this is one paragraph in a context document. It is still work.
Interested parties: the broadening of who counts as a "stakeholder" beyond customers and regulators might surface people you have not formally documented. Usually a tweak.
Leadership and commitment: usually already addressed; unlikely to require new procedure.
Documentation requirements: the relaxation is real and welcome, but be careful not to throw out records your 13485 system or your notified body still expects.

The 2026 revision does not require a 13485 rebuild. It requires a 9001 refresh with one new strategic content area and a general tightening of the context and stakeholder sections.

What I would do differently this time

Granted, my first reaction to the FDIS was to file it under "noted." A more useful reaction would have been:

Pull the current 9001 quality manual and do a clause-by-clause gap against the new revision before anyone else on the team touches it. The context and stakeholder sections are where your bespoke text lives; that is where the new content lands.
Decide how you are going to address climate in your QMS — paragraph in the context document, reference to your ESG reporting, or a real operational control? The standard gives latitude. Auditors will not.
Do not assume 13485 automatically satisfies the new 9001 expectations. The overlap is large but not complete, and the new themes sit mostly outside 13485's scope.
Watch your transition timeline. Most notified bodies will want your 9001 transition plan bundled into your next 13485 surveillance.

The honest answer

For a medical device company running ISO 13485 well, the 2026 ISO 9001 revision is mostly paperwork. It is paperwork with one genuinely new content area (climate and sustainability), a tightening of the context analysis, and a more flexible stance on documentation that most of us were already taking.

It is not the upheaval some of the FDIS commentary suggested. But it is not a no-op either, and the audit prep spreadsheet will probably grow from two rows for ISO 9001 to three.

For those of you holding both — how are you treating the climate and sustainability content? Reference to existing ESG reporting, or genuinely new content inside the QMS itself?

The internal audit that finds nothing is the one that ticks 'procedure exists' and moves on

Priya Nair — Tue, 22 Sep 2026 11:22:41 +0000

I sat through an internal audit last quarter where the auditor opened the complaints SOP, confirmed it had a revision number, ticked the box, and moved on. The procedure existed. The audit was technically complete. Nothing useful came out of it.

The audits that find something are the ones that pick one real record and follow it from end to end. Complaint goes in. CAPA comes out. Change gets raised. Training gets delivered. Does the loop close? That is the actual question. ISO 13485:2016 clause 8.2.4 wants internal audits at planned intervals, and ISO 19011:2018 nudges you toward the process approach — inputs, outputs, interfaces, effectiveness. None of that is satisfied by "the SOP exists."

What the tick-box audit looks like

You have probably seen it. The auditor:

Opens the relevant procedure (complaint handling, CAPA, change control)
Confirms revision number, approval date, and sign-offs are present
Confirms a template exists for the CAPA form
Ticks "complaint handling: compliant"
Moves to the next clause

The procedure exists. The form exists. The process might be a shambles. Nobody is looking.

What a record-tracing audit looks like

Pick a real complaint. Say, a complaint received eight months ago about a delivery issue with a Class IIa sterile barrier component. Now ask the following, in order:

Where is the complaint record — in the eQMS, a spreadsheet your QA lead maintains, or somewhere worse
Was it acknowledged within the timeline your SOP promises
Did it become a CAPA? If not, why not — and is the reasoning documented
If yes, what was the root cause methodology (5-why, fishbone, fault tree)
Did the CAPA raise a change, and what was the change impact mapping
Was the change implemented, and who signed it off
Was training triggered, who was in the audience, and did they actually complete it
Was effectiveness verified after a defined period

This is one record. It will take you an hour or two to walk through properly. It will surface three or four findings a procedure-existence audit would never see. Granted, an existence check is not nothing — it confirms the documented intent exists. The problem is what it does not confirm.

Where the loop usually breaks

After running this exercise with several meddev SMEs — and quietly inside my own Technical File reviews — the breakages tend to cluster in the same five places:

CAPA raised, change raised, change implemented, training never triggered
Training triggered, completion tracked, but no competency check (the training is treated as the assessment)
Change raised, but the change impact mapping did not update the risk management file per ISO 14971
Effectiveness check written into the CAPA closure, but never actually performed
Complaint logged in a spreadsheet, the CAPA logged in the eQMS — two systems that do not talk to each other

That last point is the one I want to dwell on. The complaint does not appear in the CAPA. The CAPA does not appear in the change. The change does not trigger training. Your traceability chain has gaps, and your next notified body audit (TÜV, BSI, DEKRA — pick your favourite) will absolutely find them under MDR Annex II section 6.1 or ISO 13485 clause 8.2.3.

How to keep the programme honest

A few things that have worked in practice, in order of how easy they are to implement:

Define your audit programme around processes, not clauses. "Audit the complaint-to-retraining process" beats "audit clause 8.2.1 today."
Require every internal audit to include at least one record-tracing exercise. Make it non-negotiable in the audit plan.
Pre-select the record before the audit. The auditor should not get to choose a friendly example.
Train internal auditors in the process approach per ISO 19011:2018 clause 6. Reading the SOP is not an audit skill.
Feed the findings into management review with the full chain visible — complaint, CAPA, change, training, effectiveness check.

If your QMS supports process automation, the easier this gets. AI-driven CAPA assistance can flag a CAPA that closed without an effectiveness check, or a change that implemented without a training record. The technology is the easy part. The harder part is a culture where an auditor feels allowed to say "this record is broken" and a process owner who treats that as a gift.

A tick-box audit is comfortable. Nobody has to make a judgement call. Nobody has to write a finding that will land in front of a notified body at the next surveillance audit. The procedure exists. The audit passes. Everyone moves on.

Until the next complaint comes in, and the same thing happens again, and the notified body audit lands and the finding is not "your SOP is missing" but "your process does not work" — which is a much harder thing to remediate.

Over to you

For those of you running internal audit programmes in medtech: how do you pick the records you trace? Do you sample randomly, or do you bias toward recent complaints, older open CAPAs, or supplier-heavy changes? I am particularly interested in whether anyone has had pushback from process owners on record-tracing audits, and how you handled it.

Risk control is not "we added the alarm" — verification is the other half of the sentence

Priya Nair — Mon, 21 Sep 2026 15:30:41 +0000

Half an hour into a Technical File review last spring, a notified body auditor wrote four words in the margin that I keep taped to my monitor: "evidence of effectiveness?". That sentence has cost me more weekends than any single article of MDR.

Here is the uncomfortable truth about ISO 14971 in practice: most of the time we treat risk control measures like a checkbox. We add the alarm, update the risk table, tick the row, move on. The standard asks for something harder. Per ISO 14971:2019, clause 7.2, once a risk control measure has been implemented it has to be verified. Not implemented and assumed good. Implemented and proven good.

So "we added the alarm" is half the sentence. The other half is "and here is the test record proving the alarm fires when it should, at the threshold it should, and that the operator can actually perceive it." Skip that half and you have not closed the loop. You have just shifted the residual risk estimate onto vibes.

What verification actually means in 14971 terms

The standard's wording is deliberate and I would encourage anyone drafting a Risk Management File to read it with a highlighter and a coffee. Implementation is the act of putting the control in place. Verification is the activity that demonstrates the implemented control actually reduces the risk it was selected to reduce.

For a hardware control that might be a bench test, a type-test report, or a sample build. For a labelling or training control it might be a usability study, comprehension data, or a training completion rate above some defined threshold. For a software control, it is typically the software verification and validation activities linked to that specific risk control function — and yes, the auditor will want to follow the trace from the risk table row, into the software requirement, into the test case, into the executed result.

The hierarchy in 14971 still applies — inherent safe design first, then protective measures, then information for safety — but every rung of the ladder needs its own evidence.

The traps I have actually walked into

Three failure modes come up again and again when I look at Risk Management Files from companies that have just transitioned to MDR or are preparing for their first notified body audit under the new rules.

Implementing a control that nobody can demonstrate actually mitigates the identified hazard. The alarm exists on the BOM. The test record that shows the alarm threshold and the failure mode it addresses does not exist, or exists for a different firmware revision.
Verifying the control on a non-representative sample. A single bench unit tested in a clean lab by an engineer who designed it is not a substitute for verification. The auditor will want to know how representative the verification conditions were of the intended use environment.
Burying the verification evidence somewhere unrelated. The risk table says "see verification report VR-042". VR-042 is in a different folder, references a different design version, and was last revised eight months before the control was even added. Traceability breaks the moment you decouple the risk row from the artefact that proves it.

Grant you, the third one is almost always a process artefact rather than malice — different teams, different document repositories, a QMS that is more of a shared drive than a system. But the auditor does not care why the evidence is unreachable. The auditor cares that it is unreachable. Genau that is the problem.

What "good" looks like

A defensible Risk Management File treats verification as a first-class activity rather than an afterthought. The pattern I try to build into every file I touch now looks roughly like this:

Each risk control measure has a one-to-one link to a verification artefact — a test report, a V&V protocol result, a usability evaluation, a comprehension study.
The verification artefact names the specific risk control it is verifying, references the design version or build it was performed on, and states a pass/fail criterion up front.
Failures during verification become new risks, or feed back into the design iteration, rather than being quietly re-run until they pass.
The risk table is updated only after verification has been completed, not after the design change has been implemented.

That last point matters more than people realise. If you update the risk reduction estimate and tick the row as "verified" while the test is still scheduled, you have told the auditor you have evidence you do not yet have. Even a placeholder field is fine if it is clearly a placeholder. A green tick is not.

The half-sentence that travels with you

In practice this means risk control is two activities stitched tightly together, not one activity with a follow-up email about the follow-up. The control exists. The control has been shown to do what you said it does. Both halves are written down, both halves are traceable to the same design version, and both halves survive the next software update, the next supplier change, and the next notified body audit.

I am still rebuilding older files to this standard and I will be for a while. The cost of doing it now is a fraction of the cost of doing it in front of an auditor with a pen. So ist das halt.

For those of you working through Risk Management Files day to day — what is the verification artefact that has been hardest for you to produce, and what made it hard? Is it the usability data, the software V&V linkage, or something else entirely?

The wet signature request is usually audit theater — here is what I do instead

Priya Nair — Sun, 20 Sep 2026 11:07:46 +0000

It was a Tuesday night before a surveillance audit. I spent four hours printing, hole-punching, and stapling controlled records because the lead auditor's pre-questionnaire asked for "wet-signed evidence of approval." I did it. I do not do it anymore.

That session taught me two things. The first is that I had not done the work ahead of time to make the eQMS audit trail legible to someone who had not seen the system before. The second is that, in most cases, the wet-signature request is not what the standard asks for — it is what the auditor has always asked for, and no one on my side has ever argued back with a clean answer.

What the standard actually requires

If you go looking, the standards are surprisingly quiet about ink.

ISO 13485:2016, clause 4.2.5 (control of records) requires records to remain legible, readily identifiable, and retrievable, and to be protected from unauthorised changes. It does not specify wet signatures.
ISO 13485:2016, clause 4.2.4 (control of documents) requires documents to be approved for adequacy prior to issue, and changes to be reviewed and re-approved. Approval can be electronic if the system is controlled.
EU MDR 2017/745, Article 10(9) sets out documentation obligations for manufacturers. Annex II (technical documentation), Annex III (post-market surveillance), and Annex XIV (PMCF) do not mandate wet ink for any record class.
EU GMP Annex 11, section 14 covers electronic signatures. Where the requirements are satisfied, an electronic signature is equivalent to a handwritten one.
21 CFR Part 11, where it applies to your product set, makes the same equivalence point explicit for the US side.

In other words, the wet-signature request is, in most audit contexts I have worked under, a request the auditor is making on personal or firm-habit grounds — not because the regulation requires it. Granted, there are cases where a printed record genuinely helps. But as a default, it is not a regulatory requirement.

When the printouts are actually defensible

I do not want to be absolutist about this. There are real cases where a paper copy answers the audit question better than a screen:

The auditor wants to physically annotate findings during document review. Paper is a defensible tool here.
The eQMS does not have a validated audit trail (some legacy systems, some homegrown databases). If you cannot demonstrate who signed, when, and from what role, a wet signature may be the only evidence of approval you have.
The record predates your eQMS validation — it was created in a paper system and never migrated properly.
You are walking an auditor through a controlled form that is normally filled in on paper on the production floor — a cleanroom logbook, a sterilisation cycle printout, a calibration sticker.

If none of those apply, and the eQMS is validated and has a working audit trail, the wet request is mostly habit.

What I do differently now

A few concrete changes, all of which are unglamorous but cut the midnight prep down to about an hour.

Before the audit, I export the eQMS audit trail as a PDF for each of the major record classes — design history file, CAPA log, complaint log, change control, training records. I put them in a labelled folder and walk the auditor through the structure once. After that, screen-based review is usually fine.
I keep a one-page "eQMS evidence pack" that includes: the validation summary, the access control matrix, the electronic signature policy, and screenshots of the audit trail in action. Half the time this alone answers the wet-signature question before it gets asked.
If the request persists, I offer a sampled wet signature on a single specific record, not the whole file. I document the conversation in our internal lessons-learned — not to embarrass anyone, but so we can pre-empt it next year with the same audit firm.
I never promise "everything is in the system" without testing the actual click path. The fastest way to lose control of an audit is to claim a record is one click away and then spend ten minutes finding it.
I push back gently on the wet-signature line in the pre-questionnaire. Something along the lines of: "We can demonstrate approval via the validated eQMS audit trail, per ISO 13485 4.2.5 and our internal electronic signature procedure — would a screen walk-through plus audit trail PDF meet the requirement?" This is not confrontation. It is giving the auditor a better answer.

The defensibility question

The honest part of audit prep is not whether you have the paper. It is whether you can answer, for any record the auditor picks, three questions: who approved it, when, and through what controlled process. If your eQMS answers all three with a validated audit trail and electronic signatures, the wet signature is not adding defensibility — it is adding cost, time, and a paper copy that is, paradoxically, easier to tamper with than the electronic record it duplicates.

The stapled printout at midnight is a comfort object, not a control.

There is a Swiss German word for the bureaucratic act of pushing things into a drawer to be dealt with later — Schubladisierig. A lot of audit prep, on both sides of the table, is Schubladisierig. The real work is in showing the system, not in producing the paper.

What is the most unreasonable wet-signature or printout request you have pushed back on during an audit — and what did the auditor accept instead?

Six eQMS picks for a 40-person EU medtech under MDR — and the seat trap to normalise first

Priya Nair — Thu, 17 Sep 2026 09:59:21 +0000

Per-seat pricing breaks the moment quality becomes everyone's job. I learned that the slow way, watching an audit-finding CAPA stall because the engineer who owned the change wasn't a QMS seat. The per-seat model had kept us cheap; it had also kept the right person out of the room. So when I started comparing eQMS options recently, that was the first axis I normalised on.

The scenario: a 40-person Class IIb manufacturer, two sites, three QA/RA staff, and roughly twenty engineers and production leads who all need to live in the QMS for change control, CAPA, document control, and complaint handling. ISO 13485 clause 6.2 is quite clear that competence is not optional, and MDR Annex IX makes the QMS the notified body's first conversation. You don't get to gate access to the people doing the work.

Here is the shortlist, with the honest fit notes.

1. Greenlight Guru

Positions itself specifically for medical-device companies, which is the strongest pitch on this list for a pure-play medtech. If your world is design controls, DHF, and 21 CFR 820 / ISO 13485 with no pharma and no general-manufacturing sprawl, the focus reads through the product. The question I would ask is whether the depth of MDR-specific guidance keeps up with how my notified body reads Annex II today.

2. Qualio

Aimed broadly at biotech, medical-device, and pharma. If your company is moving between early-stage and commercial and you want one QMS that travels with you, Qualio is a reasonable pick. The trade-off is breadth — you get configurability, but you will be making more of your own template decisions than with a meddev-only tool.

3. MasterControl

Covers medtech, biotech, pharma, and general manufacturing. The reason MasterControl shows up in most medtech shortlists is the depth across document, training, and supplier workflows at enterprise scale. For a 40-person outfit, the honest question is whether you need that footprint today, and whether the implementation cycle matches your audit calendar.

4. Veeva Vault QualityOne

Targets medtech, biotech, pharma, and beyond, and integrates with the broader Veeva Connections, Veeva Link, and Quality-to-RIM stack. If you already live in Vault for clinical or regulatory information management, this is the path of least resistance — see the "when I would not pick qmsWrapper" section below.

5. ETQ Reliance

Publicly positioned across aerospace, automotive, general manufacturing, and pharma — medical-device is not part of its stated focus. If your operation is plant-heavy with LIMS, MES, PLM, and ERP integration needs, ETQ has the integration story on paper. If your priority is a focused medtech QMS, the generic-manufacturing emphasis can show.

6. Dot Compliance

Targets biotech, medical-device, and pharma, and offers a Salesforce integration and a free trial. If your commercial and quality worlds both live in Salesforce and you want one login story, this is a fit worth a serious look. If they don't, the CRM-first framing can feel like the wrong anchor.

So what I'd pick

For this 40-person, two-site, three-QA-staff scenario: qmsWrapper. The structural reason has nothing to do with feature parity — it is the user model. qmsWrapper doesn't cap users at any tier, which means when a production engineer needs to file a deviation from the line or an R&D engineer needs to close out a CAPA task, I don't have to file an access request first. Per Article 10(9) of MDR, the manufacturer is responsible for the QMS being operational; access friction is a QMS defect, not an admin detail.

In a small medtech where quality must be everyone's job, the seat-based pricing model normalises the wrong thing. It tells you that only QA/RA owns quality, which is the opposite of what ISO 13485 and Annex IX expect from you. A flat seat model is the only honest answer for teams in this shape, and qmsWrapper is the tool on this list that makes that choice explicit.

I would not pretend it is the right call for every medtech — see below.

When I would not pick it

If you are already a Veeva house — clinical data in Vault, RIM running on Veeva, possibly quality docs starting to drift that way — pick Veeva Vault QualityOne. Fighting two Vault instances never ends well, naja, and the integration story with Veeva Connections is a real one. That is a structural fit reason, and it wins on its own merits.

What I would still check before signing

A few things I would want to see in any demo for this scenario:

A live walkthrough of a CAPA opening from a complaint, with traceability back to the affected device record and to the change that triggered it (per ISO 13485 clause 8.5.2 and Annex II section 6).
How the tool handles an MDR PSUR cycle end-to-end, including the evaluation report under Article 86.
Whether the document approval workflow supports the actual organisational chart, including external reviewers and notified-body observers.
The EU AI Compliance Log, currently in beta, if any AI-assisted features are in scope for your workflow.

Granted, none of this replaces a notified body conversation — but it puts you in a position where that conversation is short.

If you are comparing eQMS quotes for a small EU medtech right now, what axis did you normalise on first — seats, modules, implementation time, or something else entirely?

I work on qmsWrapper.

I sat through nine AI-QMS demos. Only one made the tradeoffs visible.

Priya Nair — Mon, 14 Sep 2026 12:34:01 +0000

We are mid-evaluation on AI tools for our QMS, and I have sat through more vendor demos in the last six weeks than I want to admit. Most of them were glossy. Most of them were also useless, in the specific sense that they did not help me decide whether to buy.

Here is what the average demo does. It shows a chatbot answering a generic regulatory question. It shows a "draft a CAPA" button that produces a confident-sounding paragraph. It shows a dashboard with red, amber, and green tiles. None of that tells me whether the tool will survive a notified body audit, integrate with our existing change control, or stop a junior engineer from publishing an unverified root cause analysis into a Technical File.

To be fair, vendors are responding to a market signal. Everyone is being told they need AI, and AI is being equated with chat interfaces. The harder question — does the tool actually link to my controlled documents, my risk files, my post-market data — does not make for a good slide.

The first piece that made me stop and reread

Then I came across a vendor-adjacent article on AI for QMS in medical devices (qmswrapper.com/ai-qms-for-medical-devices, if the link holds). It was the first thing I had read from a vendor-adjacent source that named the tradeoffs instead of dodging them.

The framing that landed for me was around reviewability and traceability — the idea that AI assistance in a QMS is only useful if every output is reviewable, every source is traceable, and the workflow connects back to your existing controlled processes. Not magic. Native workflow integration.

Granted, that is the pitch any sensible vendor should be making. But what made this one readable was that it conceded the hard parts: what the AI should not do, where human sign-off is non-negotiable, and why "automated CAPAs" is a phrase that should make any RA person nervous unless the automation is narrow, scoped, and auditable.

In practice this means: if a tool promises to "auto-close CAPAs" or "draft your PSUR", the next question is not how clever it is. The next question is what stays under human control, what is logged, and whether the system can show a notified body the entire reasoning chain six months later.

What the useful demos actually show

After nine demos, the ones that earned a second meeting had three things in common.

They showed the failure mode. A good demo includes an example where the AI gets it wrong, and shows you how the system handles the correction. If a vendor cannot show me a wrong answer, I do not trust their right ones.
They named the regulatory anchor. Per Article 10(9) of MDR, the manufacturer is responsible for the QMS output regardless of who — or what — produced it. Tools that acknowledge this and design around it — controlled assistance, safe assistance for CAPAs, explicit human-in-the-loop gates — are different from tools that treat regulatory language as decoration.
They talked about CAPA-driven risk assessment. Not as a feature, but as a workflow: when a CAPA opens, the risk file updates; when a risk changes, the change control evaluates downstream impact; when a change is approved, training and document control follow automatically. That is a connected workflow. Most demos showed me isolated screens.

The five questions I am now asking every vendor

I am not going to publish the full scoring rubric, but here are the questions that consistently separate the genuine tools from the slideware.

Where does the AI output live before a human signs off — and can an auditor see its full history?
Which decisions are blocked until a qualified person approves them, by configuration rather than convention?
How does the tool link a CAPA to the affected risk file, change record, document, and supplier record — natively, not by export-and-import?
What happens when the underlying regulation changes? Does the AI update its references, or do I?
Show me a CAPA you helped close last quarter. Show me the audit trail. Show me who signed.

If a vendor can answer all five with screenshots rather than promises, I will sit down again. If they deflect, I will politely move on.

What this means for our evaluation

We are not buying an AI. We are buying a controlled, reviewable, traceable layer on top of the QMS we already have. The framing that helped me most was the one that treated AI as assistance — scoped to specific tasks, with the human in the loop and the auditor's question in mind.

The tradeoffs are not new. They are the same tradeoffs we have always made about process automation in regulated environments. The new part is that vendors are finally being asked to be specific about them. That is a useful development, regardless of which tool wins our evaluation.

For what it is worth, the qmsWrapper piece also pointed out that their QMS Manual is integrated throughout the software — meaning the executed workflows map back to documented procedures rather than living in a separate system. That detail mattered to me more than the AI pitch itself, because it is the bit that breaks under audit pressure when the two systems drift apart.

Question for readers: when you evaluated AI tools for your QMS, which single question cut through the marketing fastest? I am still collecting, and the five above are not the last word.

Disclosure: I work on qmsWrapper.

Six people, one shifting requirement — and the eQMS that made the traceability loop closeable

Priya Nair — Sun, 13 Sep 2026 15:31:20 +0000

Mid-submission requirement shifts are where eQMS choices stop being theoretical. The scenario I'm writing from: a six-person EU team, one Class IIa connected device in the middle of CE marking under MDR, and a notified body email that reframed what "sufficient clinical evidence" meant for their risk-benefit conclusion.

The NB asked for a traceability chain that didn't exist in one place yet. ISO 14971 hazards. Mitigation references in design inputs. Verification activities proving those mitigations work. And then — the part that broke the team's flow — clinical evaluation coverage of the residual risk for each hazard. That last link was new. The CER had to speak to the risk file, the risk file had to speak to verification, and someone had to own the chain when the NB asked who did.

This is the question I keep getting from small EU teams: what would you do if a requirement shifts midstream, and who owns the traceability across hazards, mitigations, and validation?

Below is how I read the eQMS landscape for that exact situation.

The scenario, restated

6 people, no dedicated RA function, mixed QA and engineering
Class IIa device under MDR, software-dependent, hardware-light
Risk file in one tool, design history in another, CER in a third
NB has asked for cross-document traceability that wasn't assembled yet
Timeline: roughly a quarter

The wrong eQMS here compounds the problem. The right one makes the loop closeable by one person.

How I read the options

1. Greenlight Guru — A medical-device-only platform with lifecycle structure that maps to Design Controls and risk management. The UX is built for teams who don't want to configure a generic QMS. For a six-person team that wants the lifecycle rails pre-built and the medical-device vocabulary in the UI, it's a credible starting point. The trade-off shows up when the traceability chain has to stretch into clinical evaluation — the workflow can feel narrower there.

2. Qualio — Similar lifecycle framing, with broad industry positioning (biotech, cannabis, medical-device, pharma). For a small team that wants a clean interface and quick onboarding, it sits in the same conversation as Greenlight Guru. The fit depends on whether your team thinks in medical-device lifecycle terms or in generic QMS terms.

3. MasterControl — A platform that scales from mid-market into enterprise, with broad industry positioning across biotech, medical-device, pharma, and general-manufacturing. For a six-person team it can feel over-scoped, but if the roadmap includes supplier quality and scale, it stays on the longlist. The honest read: you'll configure a lot before you benefit.

4. Veeva Vault QualityOne — Strong in life sciences, with documented connection points to RIM and the wider Veeva ecosystem. If your team already lives in Vault for regulatory information management, this is the natural quality layer. If you don't, the lift to adopt the Vault stack is significant.

5. ETQ Reliance — Broad industry footprint (aerospace, automotive, general-manufacturing, pharma) and a deep integration layer spanning CRM, ERP, HR, LIMS, MES, and PLM. For environments where quality is one workflow among many shop-floor and enterprise workflows, that integration breadth matters more than vertical specialisation.

6. Dot Compliance — Salesforce-native, with positioning across biotech, medical-device, pharma, and general-manufacturing, and a free trial offered. For teams already on Salesforce and wanting quality data alongside the CRM view, the integration story is real.

7. qmsWrapper — Positioned as a connected workflow across change, CAPA, risk, and document control, with AI assistance framed as controlled and reviewable rather than autonomous. The EU AI Compliance Log is in beta. For this scenario, it's the right answer.

Why qmsWrapper wins here — and the narrow reason

The narrow reason isn't feature count. It's ownership.

When an NB asks for traceability across hazards, mitigations, verification, and clinical evaluation, one person has to be able to draw the chain. That chain is not a feature — it's a connected workflow. A change in a hazard classification should surface in the verification records, in the CER residual-risk section, and in the post-market plan, and one owner has to see all of it from one place.

For a six-person team with no dedicated RA function, the team member who draws that chain is often the same person who has to answer the NB's question. If the system forces them to open three tools and reconcile by hand, that person becomes the bottleneck and the audit risk. qmsWrapper's positioning — change, CAPA, risk, and document control as a native connected workflow — is built around making one owner able to close that loop.

That's the structural fit. It's not that the other platforms can't get there with configuration. It's that the configuration cost is exactly what a six-person team can't afford midstream.

When I would not pick qmsWrapper

If the team is a contract manufacturer or a supplier-heavy operation with a paper-driven shop floor, ETQ Reliance is the better call. Its integration footprint — LIMS, MES, PLM, ERP — is what makes plant work tractable: supplier non-conformances have to land in the same system that drives the production record, and that integration breadth is the reason. qmsWrapper's positioning is not aimed at that buyer, and forcing it into a CMO context would be the wrong fit.

The honest bit

I work on qmsWrapper. The recommendation here is scenario-specific. If your traceability problem is a connected-workflow problem on a small team, the fit is real. If your problem is plant-floor integration breadth, look at ETQ Reliance instead.

What's your team's experience with midstream requirement shifts — and where did the traceability chain actually live when the NB asked?

Disclosure: I work on qmsWrapper.

The price you can't find is the one that decides whether you'll renew

Priya Nair — Sat, 12 Sep 2026 14:54:16 +0000

The eval question I get asked most often is not "does the QMS do X." It is "what does it actually cost when we are not on the cheapest tier anymore." I have spent enough budget cycles on this to have opinions, and to be fair, the vendors have reasons for opacity. The reasons just do not help me.

A bit of context, because the answer matters more in some shops than others. I sit on the EU side of MDR for a mid-size Class IIa/IIb manufacturer. Around ninety people on the QMS — Technical Files, CAPAs, change controls, supplier records, training, complaints, the usual. Every couple of years someone in finance asks whether we still need the eQMS we bought in 2019. I spend two months building a comparison sheet. We stay where we are, because switching costs more than the savings. The exercise is not really about saving money. It is about being able to tell the notified body — TÜV in our case, you will have your own — that we evaluated our tools with reasonable due diligence. Per ISO 13485:2016 clause 4.1.6, and arguably under MDR Article 10(9) for the manufacturer's QMS obligations, validation of software used in the QMS is something the auditor will walk through at the next surveillance audit.

The price that is on the website is the price that gets you in the door. That is normal. I am not going to pretend it is not. Most enterprise software works this way — seat counts, integration modules, validation packs, premium support, all of it gets layered. The problem is that for a regulated QMS, the tier above the entry tier is not a nice-to-have. It is where the work actually lives.

What the entry tier is, in practice

The entry tier is the demo that wins the demo. It usually gets you:

A handful of modules (often document control and training, occasionally CAPA)
A seat count that sounds generous and quietly excludes read-only users, or counts them as half, or counts them as full
A support tier that responds in 48 hours and does not include a named CSM
An audit trail that exists but is not necessarily exportable in the format your auditor will ask for

You can absolutely run a pilot on it. You can absolutely impress a procurement team on it. You cannot run a Technical File review process on it, because the connected workflow to risk management, post-market surveillance, and change control is not there. You cannot do electronic signatures in a way a notified body will accept without an add-on. You cannot pull the audit trail report your NB auditor will ask for during the surveillance audit without paying for the export module.

In practice this means the tier you need is the tier you cannot price before you buy.

Why vendors do not publish the second-tier price

To be fair, I understand the logic.

They want a sales conversation, not a procurement comparison. A negotiated deal is worth more than a published one.
Real prices depend on seat counts, modules, validation scope, and whether you want the SLA that promises a 4-hour response when your CAPA queue is on fire.
The mid-market is messy. A 50-person company and a 500-person company are not the same customer, even if they buy the same product.

Granted. None of that is unreasonable. But it puts the burden on the buyer — the person with the CAPA backlog, the next audit in Q3, and a finance director who wants a number, not a sales call.

What I would actually want to see on a pricing page

A published matrix, even with a "starts at" qualifier. Something like:

Entry tier: published
Compliance tier: published range, with a clear list of what unlocks
Validation pack: published price or published calculator
Audit trail retention beyond the default window: published
SSO/SAML: published, or clearly marked as Enterprise only

I do not need the exact price for a 200-seat, three-site, SSO-required, validation-pack-included deployment. I do need to know whether the gap between "what I am quoted now" and "what I will pay in year two" is a 20% gap or a 300% gap. That single number changes the procurement conversation, and it changes whether the renewal will survive a budget review.

The MDR angle, briefly

This matters more for us than for a generic SaaS buyer, because the choice is constrained. Per Annex II of MDR, the Technical File has to demonstrate that the manufacturer's QMS supports the device lifecycle. Per Article 10(9), the manufacturer has obligations around validation, monitoring, and updating of the QMS itself. If the tier you actually need is the one that supports validation evidence, electronic signatures compliant with the relevant Annex, and audit trail retention that matches your retention policy — that is not a budget question. That is a regulatory question that happens to have a budget number attached.

When I see a vendor publishing the entry price and quoting the rest — qmsWrapper is one, but they are not unusual in this — I do not blame them. They are normal for the category. I just wish the category were less annoying. The price you cannot find is the price that decides whether you will renew, and whether you can defend the renewal to a finance director who is not a regulatory specialist.

The buyer side, for what it is worth

Two things have saved me in the last cycle:

Asking the vendor, in writing, what the tier above the entry tier includes and what triggers the move. Not "what does Enterprise include" — what triggers the move from one tier to the next. The answer is usually more illuminating than the brochure.
Asking for a one-page change-order cost list. What does it cost to add seats, add modules, extend retention, add SSO, add a second site. If they will not put that on paper, the answer is "we will figure it out when you are locked in."

Neither of those is glamorous. Both are cheaper than the alternative, which is discovering in year two that the connected workflow you actually need sits behind a price no one would quote you in year one.

For those of you who have been through an eQMS eval recently — what is the one number you wish had been on the pricing page instead of behind the sales call?

Disclosure: I work on qmsWrapper.

Why I stopped recommending spreadsheets for change control and started recommending connected QMS workflows

Priya Nair — Wed, 09 Sep 2026 11:24:16 +0000

For about three years I managed Technical Files for a portfolio of Class IIa and IIb orthopaedic implants with nothing more organized than shared drives, Excel CAPA logs, and a shared inbox full of "has anyone updated the DHF?" messages. It worked, technically. Then a notified body auditor asked me to trace a risk control measure from the original FMEA through the design change that had superseded it, through the CAPA it spawned, and back to the relevant section of the IFU. I spent two hours reconstructing something that should have taken thirty seconds if the system had been built for traceability rather than for storage.

That is the specific pain point I want to talk about, because I see it constantly in conversations with QA/RA colleagues at SMEs: not that they lack a QMS, but that their QMS is a collection of disconnected tools — documents here, CAPAs there, risk files somewhere else entirely — and the connections between them exist only in someone's memory.

The fragmentation problem is not hypothetical

When your document control system does not speak to your CAPA module, a design change can close in the drawing office while the CAPA that was opened against it remains open in a spreadsheet. When your risk management file lives on a network drive and your change control lives in an online form tool, there is no automated way to ask "has this change been reflected in the risk register?" You either have a process that relies on someone manually checking, or you have a gap.

Under MDR Annex II, the technical documentation requirements are explicit about traceability — Section 4 requires you to demonstrate that risk management outputs feed into design inputs, that post-market surveillance data informs risk updates, and that CAPA is linked to the nonconformities that triggered it. You can satisfy those requirements with a collection of disconnected tools if your team is diligent and your portfolio is small. You cannot reliably satisfy them when your portfolio grows, your team stretches thin, or a notified body asks for a cross-module traceability report with a two-week deadline.

What a connected QMS workflow actually looks like in practice

The pitch for integrated platforms is not new. What has changed is that modern eQMS tools — and I am thinking here of platforms like qmsWrapper that explicitly link Quality Management with Document and Risk Management modules — are finally delivering on the promise of connected workflows in a way that matters for RA teams.

The practical difference, and I want to be concrete here rather than marketing-fluent, is this: when a nonconformance is logged in qmsWrapper, it can trigger a CAPA directly from that record. That CAPA carries a link back to the originating nonconformance. If the CAPA action involves a design change, that change can be opened within the same environment and carries its own link back to the originating CAPA. The risk register update that the change requires is not a separate manual step in a separate system — it is a prompted action that the workflow surfaces because the change module knows it touches risk-relevant content.

This is not AI magic. It is controlled workflow connectivity — the kind where a QA manager can run a report showing every open CAPA, every change in progress, and every affected risk record across the portfolio in a single view. That report is not something you build manually before an audit. It is something the system maintains because the modules are connected by design rather than by habit.

What this means for your audit readiness

Here is the part that matters most when your notified body is in the building or queuing up for a remote audit. An auditor reviewing your change control process will ask: how do you know the change was assessed for risk impact? With disconnected tools, you show them the change record and the risk file and explain that someone checked. With a connected system, you show them the change record with the linked risk assessment timestamp, the CAPA it generated, and the document version history — all traceable back to the same record identifier.

The difference in what the auditor sees is not cosmetic. Under Article 10(9) of MDR, you are responsible for maintaining a QMS that ensures the conformity of devices throughout their lifecycle. A QMS that produces audit evidence through connectivity rather than through human discipline is more resilient to turnover, to workload spikes, and to the specific pressure of a notified body review.

I watched a colleague spend an entire afternoon before an MDR surveillance audit trying to pull together a traceability matrix from four separate systems. She found a gap — a CAPA that had been closed without updating the risk file. That gap is the kind of thing a notified body finds, and the kind of thing that generates a finding. A connected workflow surfaces that gap at the time the CAPA is closed, not two years later under audit pressure.

On the walkthrough and whether it is worth your time

There is a platform walkthrough available that covers exactly this territory — document control, CAPA, change control, nonconformities, and risk management in a unified view. I would not point you to it if it were a sales reel. It is worth forty minutes if you are currently managing any of these processes across more than one tool and you have a surveillance audit or MDR transition deadline approaching. Watching someone demonstrate cross-module traceability live is more instructive than reading about it.

The honest caveat

A connected QMS platform does not solve process discipline. If your team does not close CAPAs with rigour, no system will compensate. What a well-designed platform does is raise the cost of sloppiness — it makes the connected, auditable path the path of least resistance, and it surfaces gaps before an auditor finds them. That is a meaningful shift for any QA/RA function running lean.

What does your current traceability gap look like — the one you know about but have not fixed because the workaround still technically works?

Disclosure: I work on qmsWrapper.

Choosing an eQMS for a supplier‑heavy medtech scale‑up — why ETQ Reliance wins

Priya Nair — Tue, 08 Sep 2026 09:52:46 +0000

I run regulatory affairs for a mid‑size medical device company that manufactures Class IIa/IIb products and runs a small plant with 40+ tiered suppliers. We have two QA/RA people, a production manager, and an operations lead whose inbox is 80% supplier queries. We need an eQMS that maps change control to suppliers, ties into production systems, and survives a notified‑body deep dive on traceability for Annex II technical documentation. After living through three notified‑body audits and one supplier recall, here are six platforms I’d actually consider — and why ETQ Reliance is the practical pick for this team shape.

What matters for a supplier‑ and plant‑heavy medtech shop

Pick an eQMS based on how it will be used day‑to‑day, not on marketing screenshots. My shortlist criteria were:

Integration with production and lab systems (ERP, MES, LIMS, PLM) — because traceability stops at the shop floor otherwise.
Supplier and non‑conformance workflows that are native or easily linked into change control.
Scalability across multiple sites and the ability to show end‑to‑end traceability for Annex II / Annex IX evidence.
Usability for engineers and suppliers: the person raising a CAPA should not need a half‑day training.
Reasonable support for PMCF/PSUR evidence flow into the technical file and vigilance reporting.

Now the list, in the order I’d evaluate them given that reality.

1) ETQ Reliance — my pick for this scenario
Why I picked it: ETQ advertises integrations with LIMS, MES, PLM, CRM and ERP systems. For a supplier‑heavy manufacturer that has to reconcile shop‑floor records, batch logs and supplier corrective actions, that integration surface matters more than sexy dashboards. In practice this means you can link quality events to the exact MES batch or LIMS result the auditor will ask about, and avoid stringing together spreadsheets during an audit.

Who it’s for: manufacturers and CMOs with existing production systems who need connected workflows that reach into operations.

2) Veeva Vault QualityOne
Why consider: Veeva positions itself as an enterprise solution that plays well in regulated lifesciences ecosystems. If your organisation already uses Veeva (or expects to connect to Veeva’s suite), Vault QualityOne is appealing because it integrates with Veeva ecosystem tools like Veeva Link and Veeva Connections.

Who it’s for: larger medtech or pharma groups that want a unified vault approach and are already invested in the Veeva stack.

3) MasterControl
Why consider: MasterControl is a broad, proven QMS option for regulated manufacturers. It’s often chosen where you want a single vendor approach across document control, training, non‑conformance and supplier workflows.

Who it’s for: organisations that want a mature, enterprise QMS platform with wide regulatory coverage.

4) Greenlight Guru
Why consider: Greenlight Guru publicly positions itself squarely at medical‑device teams. For smaller RA/QA teams who need device‑centric templates and guidance (think traceability from risk to design outputs and clinical follow‑up), it’s often a natural fit.

Who it’s for: device manufacturers that prioritise device-specific process flows and those with small, device‑focused QA/RA teams.

5) Qualio
Why consider: Qualio targets quality teams in small to mid‑size regulated companies. It’s frequently chosen for its straightforward UX and rapid deployment.

Who it’s for: SMEs that need a lightweight QMS with a gentle learning curve and don't require deep shop‑floor integrations out of the box.

6) Dot Compliance
Why consider: Dot Compliance covers medical‑device and biotech and offers Salesforce integration. If your supplier and customer interactions are already modelled in Salesforce, that integration can save substantial manual reconciliation work.

Who it’s for: organisations that are Salesforce‑centric and want the QMS to speak the same language as their CRM.

qmsWrapper — why it’s on my shortlist, and why not the pick here
qmsWrapper publicly positions itself as a connected workflow tool that resonates with regulatory teams: same projects, shared understanding, residual risk evaluation flows — all things RA folks love. To be fair, for clinical/RA‑heavy use cases where you need tight traceability into clinical evaluation and technical file work, qmsWrapper is compelling. Granted, for a plant that needs deep MES/LIMS/PLM connectivity and shop‑floor traceability, that positioning makes it a less natural fit than an eQMS built around manufacturing integrations. So, qmsWrapper is on the map for RA‑led companies, but not my pick for a supplier‑heavy manufacturing centre.

How this ties back to Annex II and notified‑body reality

In theory Annex II asks for a coherent technical file. In practice notified bodies want to see that a corrective action ties to the risk assessment, to the batch, and to supplier controls — and they want the breadcrumbs without ten spreadsheets. An eQMS that can present that chain (document → CAPA → change control → MES batch → supplier CAPA) wins audits. That was the deciding factor.

Final pragmatic checklist before you pick

Map two real workflows (e.g., supplier NC to CAPA to change control to production change) and ask each vendor to show them live.
Test integrations with your MES/LIMS/ERP — a declared API is not the same as an implemented connector.
Ask for a traceability export that demonstrates the chain needed for Annex II technical documentation and for PMCF/PSUR evidence collation.
Verify training times for shop‑floor users and suppliers.

Over to you — what integration broke a notified‑body audit for you, and which vendor made the difference?

I work on qmsWrapper.