DEV Community: Priya Nair

A compliant QMS belongs to the whole team, not the RA inbox

Priya Nair — Sun, 08 Nov 2026 09:16:28 +0000

One CAPA review taught me that the fastest team was not necessarily the team with the fewest approvers. It was the team where the person closest to the problem could put it into the quality system without asking someone else to retype it.

A process engineer had spotted recurring variation in a forming step. They discussed it with supplier quality, attached photographs, and suggested a possible cause. By the time the monthly CAPA review happened, the useful context was scattered across a spreadsheet, a chat thread and somebody’s inbox.

Nobody had ignored the issue. The workflow had failed.

We had made quality assurance the gatekeeper without making it the owner of every fact. That is not sustainable, particularly when compliance is already a team issue rather than one person’s burden.

Broad access does not mean broad authority

When I say “broad access”, I mean that the whole team can see how to contribute, report evidence and follow the status of an issue. I do not mean that everyone should be able to edit the same controlled record or approve its closure.

The distinction matters.

Article 10(9)(h) and (i) of the MDR place performance monitoring and corrective and preventive action within the manufacturer’s quality management system. ISO 13485:2016 similarly expects defined responsibilities and authorities, including for corrective action.

The regulation does not prescribe a particular software permission model. In practice, this means separating three things:

Everyone affected by a quality issue can raise it or contribute relevant evidence.
The nominated process owner can investigate, draft actions and maintain the record.
Only appropriately authorised reviewers can approve investigation, risk decisions or closure.

Broad participation with controlled decision rights is not a weakening of control. It is how control becomes usable.

Put the facts next to the people who can act

The previous workflow made quality assurance the routing layer. An engineer sent an email, QA copied it into a tracker, supplier quality supplied evidence, and the CAPA owner tried to reconstruct the sequence.

Every handoff created another place for context to disappear.

A better workflow connects the record to the work:

An engineer identifies a change affecting a purchased component.
The change is linked to its impact assessment, including affected processes, risk controls and controlled documentation.
QA assesses whether the issue also requires a non-conformance or CAPA.
The CAPA owner develops the root-cause analysis with input from engineering, manufacturing and supplier quality.
Evidence and approvals remain attached to the same record.
The CAPA links back to the risk management file and any required Technical File updates.

That is what connected workflow integration should mean. The records are not merely stored in the same system; their relationships remain visible.

The practical benefit is speed without losing traceability. In practice, this means fewer messages asking, “Which version is current?”, “Where is the evidence?”, or “Has anyone closed this already?”

A CAPA should not depend on institutional memory

During one notified body audit, we were asked to demonstrate that a corrective action had been effective. We had the investigation, action, owner and approval. What we did not have was a clean link from the approval to the supporting evidence.

The activity had happened. The traceability had not.

That gap is difficult to explain because nothing looked dramatically wrong. The spreadsheet said “closed”, the training record existed and the email confirmed completion. But reconstructing the chain took long enough to expose an obvious weakness.

This is where ISO 13485 expectations around documented information become more than a documentation exercise. A reviewer needs to see not only that a record exists, but how it demonstrates control.

The same principle applies to post-market activities. A complaint, PMS trend, supplier issue and CAPA may originate in different systems, but their relationship should not depend on a quality engineer remembering an informal discussion from three months earlier.

AI assistance needs the same discipline

AI-assisted CAPA assistance can make this broader model more practical. It can classify incoming reports, suggest potentially related records, summarise an investigation chronology and flag missing closure evidence.

It can also make a controlled process look less controlled.

AI should not decide the root cause, approve a risk acceptability decision or close a CAPA. The output must remain reviewable, with a clear human decision and traceable source material. Otherwise, faster drafting simply produces faster ambiguity.

The useful principle is controlled assistance: the tool helps people identify, connect and explain information, while accountable roles retain authority over the decision.

That also affects intake design. If reporting an issue requires ten fields before anyone can submit it, teams will work around the system. Faster input produces better data only when the data remains structured enough to analyse later.

Team messaging belongs near the record

I am not convinced that important quality discussions should live only in social chat apps. Chat is useful for quick collaboration, but it is a poor system of record when evidence needs to be retrieved, connected to a CAPA and reviewed months later.

Purpose-built team messaging can sit alongside the controlled workflow. Relevant discussion stays close to the issue, without requiring every conversation to become a formal record. When a decision affects the CAPA, change assessment or risk management file, that decision can be captured with clear authorship and approval.

The distinction is important: not every message needs to be retained, but the message containing the decision should not be trapped in a separate application.

What I would put in place now

For a medical device SME, I would make broad participation concrete through a small set of workflow rules:

Give affected teams a visible route to report issues without requiring them to draft a CAPA themselves.
Allow subject-matter experts to attach evidence and comment while preserving ownership of the formal record.
Link changes, CAPAs, risk management files, PMS information and supplier records where their relationship is established.
Define approval rights explicitly, including where independent review is required by the organisation’s procedures.
Keep regulatory assessment with competent roles, but do not make them responsible for reconstructing every fact.
Require human review, traceability and source evidence for AI-generated assistance.

That emphasis on including the whole team makes sense. The aim is not to remove gates. It is to put information close enough to the people who can act that the gates arrive at a useful point rather than at the end of a long email chain.

A mature QMS is not the one with the fewest users or the fewest permissions. It is the one where the right person can contribute at the right moment, and every significant decision remains reviewable and traceable.

Where does your organisation draw the line between broad contribution and controlled approval, and what has that boundary helped or hindered?

Write the Form 483 response for execution: every observation needs an effectiveness check

Priya Nair — Sat, 07 Nov 2026 11:32:39 +0000

A Form 483 is not closed when the response is sent. It is closed when the organisation can demonstrate that the observed condition was contained, corrected, and prevented from recurring.

That distinction changes how I write the response. The inspector needs a clear account of what happened, what was done, and what remains outstanding. My team needs something more: an executable plan with owners, evidence, and a way to verify that the corrective action actually worked.

A response that treats every observation as a CAPA-style case is harder to write. It is also considerably easier to defend.

Remember what a Form 483 is

A Form 483 is not a Warning Letter, although it may precede one. Its numbered observations identify conditions that investigators believe may indicate violations of applicable FDA requirements. The response is the manufacturer’s opportunity to provide facts, evidence, and corrective action before the agency decides what to do next.

FDA’s current guidance asks companies to consider responding within 15 business days of receipt. The response should be prompt, objective, complete, and accurate. FDA does not formally approve it, which means the manufacturer remains accountable for every statement it makes.

This is where defensive drafting often does more harm than good. I would not spend several paragraphs arguing that an observation does not technically apply. I would state what was found, acknowledge its significance, provide the evidence, and explain the control being put in place.

Build the response matrix before writing prose

When a Form 483 arrives, I do not begin with the response document. I first create one row for each numbered observation with at least the following fields:

The observation, quoted accurately
The applicable requirement
Immediate containment
Correction completed
Assessment of scope and product impact
Root cause, where a formal CAPA is warranted
CAPA reference and action owner
Target completion date for open actions
Effectiveness-check method
Supporting evidence and attachments

For a medical-device manufacturer, I map the observation to the applicable regulatory requirement and quality-system procedure. Depending on the jurisdiction and transition status, that may involve 21 CFR Part 820 and the QMS processes aligned with ISO 13485:2016, particularly clauses 8.4, 8.5.1, and 8.5.2.

I do not insist that every observation automatically becomes a formal CAPA record. FDA has not made that a universal requirement, and creating a CAPA for every isolated discrepancy can dilute genuinely systemic issues. I do, however, give every observation a CAPA-style assessment.

If the condition is recurring, systemic, or could affect product safety or performance, it should enter the formal CAPA process. That assessment should include CAPA-driven risk management, with the product and process impact considered through the applicable risk-management framework.

Separate correction from corrective action

This distinction causes more weak responses than almost anything else.

A correction addresses the condition that was found. For example, records may have been corrected, affected products quarantined, or personnel retrained.

Corrective action addresses why the condition existed and why the QMS did not prevent or detect it. Retraining is an action, but it is not root-cause analysis. Neither is a revised procedure unless the procedure was actually deficient.

The root-cause question should reach beyond “the employee made an error”. I want to know:

How did the process permit the condition?
Was the requirement unclear, unworkable, or absent?
Why did the existing control not detect it?
Could the same failure occur elsewhere?
Have complaints, non-conformances, or post-market data indicated a wider problem?

The scope of review matters as much as the action. Looking only at the record or product shown to the inspector is rarely a defensible response. I would document the population examined and the rationale for that scope.

Put the effectiveness check in the response

Training completion, a revised procedure, and a supervisor sign-off are useful outputs. They are not proof of effectiveness.

A defensible effectiveness check specifies:

What will be reviewed
How it will be reviewed
The relevant sample or population
When the review will occur
The acceptance criteria
Who will approve the result
Where the evidence will be retained

Training completion alone would not demonstrate that the behaviour changed. A follow-up review of relevant records might. An audit of the revised control might. A review of recurrence data might. The method depends on the cause.

This is also where many responses become vague. “The effectiveness of the CAPA will be monitored” is not an effectiveness check. “The QA manager will review ten completed records at 60 days against the revised checklist, with no missed required entries, and record the result in CAPA-XXXX” is a check. I would avoid inventing universal sample sizes or thresholds; the method should reflect the process and risk.

Separate what is complete from what is planned

The response should make it immediately clear which actions are finished and which remain open.

For completed actions, I provide the date, evidence, and responsible function. For planned actions, I provide the owner, target date, and intended verification method. Describing a planned action as completed is not an editorial problem. It is a credibility problem.

I also keep the formal response readable. Detailed investigation records may remain in the quality system, but the response should contain enough traceability for an inspector to follow the chain:

Observation → requirement → assessment → CAPA → action → effectiveness evidence

The response is one view of that chain, not the only place the evidence exists.

AI can organise the evidence, not own the conclusion

AI-assisted drafting can help summarise source records, organise observations, or produce a first-pass CAPA structure. I would treat that as controlled assistance rather than delegated regulatory judgement.

Every generated statement still needs human verification against its source. Automated CAPA assistance can flag missing information, but it should not decide the root cause, determine whether patient impact is possible, or declare a CAPA effective.

The important qualities are reviewability and traceability. A reviewer must be able to trace each conclusion to source evidence, and no generated sentence should become evidence merely because it appears in the approved document. Process automation can chase overdue actions; it cannot replace the decision on whether the corrective action worked.

The test I apply before sending it

I ask three questions:

Could an inspector trace every factual statement to evidence?
Could the action owner repeat what was done without interpreting the response?
Could we demonstrate later that the control worked?

If the answer to any of these is no, the response is not finished.

A Form 483 response should satisfy the inspector, but it should also become a durable instruction to the organisation. Writing for execution turns a regulatory reply into a controlled improvement process rather than a collection of reassuring paragraphs.

How do you decide when a Form 483 observation is isolated enough to close without opening a formal CAPA?

Seven eQMS platforms for medtech supplier changes: why I would choose qmsWrapper

Priya Nair — Thu, 05 Nov 2026 10:05:45 +0000

At one EU medical-device manufacturer I supported, the first supplier-change packet reached me with an ISO 13485 certificate attached. The certificate was valid. That was the only good news.

The proposed change affected a patient-contacting machined component, and the supplier had not yet explained which verification activities would be repeated. Someone in purchasing asked whether the certificate would remain valid through implementation. Someone else asked whether the supplier appeared on the FDA OAI list.

Both were sensible checks, but neither answered my question: after approval, would our controlled records still describe the device as it would actually be made?

As the manufacturer, we remained accountable for device conformity even though the component came from outside. MDR Article 10 and Annex I, section 5.2 make supplier control and verification part of that accountability. ISO 13485:2016 clause 7.4.1 does comparable work for purchasing controls.

In practice, this means a supplier certificate is evidence, not the control itself.

Seven platforms, seven different starting points

I would not rank these platforms by pretending that a public feature grid is a Technical File. The more useful question here is which operating model each vendor publicly presents and which one fits the evidence chain our team needs.

Greenlight Guru — the direct medical-device starting point. Its published industry focus is medical devices, which makes it a credible first call when the QMS exists primarily to support medical-device regulatory work. For this scenario, I would test how it handles the path from a supplier-originated change through impact assessment, CAPA, risk documentation and controlled documents. The fit is strongest when medtech compliance is the centre of the quality system.
Qualio — sensible when one QMS supports several regulated portfolios. Its public positioning covers medical devices, pharma, biotech, cannabis and broader regulated industries. That makes it a logical candidate for a group supporting several product portfolios rather than a single medtech operation. In our situation, I would shortlist it if the regulatory burden came from multiple business units and maintaining consistent quality processes mattered more than tailoring everything around MDR.
MasterControl — credible for a broad, mixed quality organisation. Its published industry coverage includes any, biotech, general manufacturing, medical devices and pharma. The fit signal is strongest for a company with several operating units that need a common quality framework. For a medtech-first organisation, however, I would want the demonstration to remain centred on the actual supplier-change chain rather than the breadth of the organisation chart.
Veeva Vault QualityOne — strongest where a Veeva ecosystem is already part of the operating model. Its public positioning covers a wide range of regulated industries, and it lists Veeva Connections, Veeva Link, and Veeva Quality to RIM Connection as integrations. That makes it a serious candidate when the quality platform must connect with an established Veeva architecture. In our scenario, I would prioritise it if those connections were more important than a medical-device-first workflow.
ETQ Reliance — a natural fit for mixed manufacturing operations. Its published industries include aerospace, automotive, general manufacturing, pharma and any. It also lists connections with CRM, ERP, HR, LIMS, MES and PLM systems. For a manufacturing site already running that kind of enterprise software landscape, those published connections provide a clear structural reason to assess it. Our narrower medtech case would begin further down the shortlist because its public positioning reads more industrial-enterprise than medtech-specific.
Dot Compliance — relevant when Salesforce is the operating backbone. Its public positioning covers biotech, general manufacturing, medical devices and pharma, with a Salesforce integration and a free trial offered. If our quality processes need to live close to Salesforce-based commercial and operational activity, that is a coherent starting point. I would use the trial to assess whether the supplier-change evidence chain is as usable for quality and engineering as it is in the CRM environment.
qmsWrapper — the strongest fit for this particular medtech workflow. Its public positioning brings change, CAPA, risk and document control together as a connected workflow, rather than presenting them solely as separate destinations. Its stated conformance baseline includes ISO 13485:2016, ISO 14971, IEC 62304, MDR, and FDA 21 CFR Parts 820 and 11. For our scenario, the important point is not the number of standards in that list. It is whether one supplier-triggered event can retain a traceable path across the records affected by it.

Why I would select qmsWrapper here

If I had to choose for this exact scenario—a medtech-first manufacturer preparing for an MDR audit while managing a critical supplier change—I would choose qmsWrapper.

The narrow reason is workflow topology. The compliance problem is not a collection of independent forms. It is one event that needs a traceable path across engineering change, impact assessment, CAPA, risk management and controlled documentation.

That is the part I would test with a real supplier scenario:

Can the reviewer trace the change to its impact assessment and related CAPA?
Can the risk record show why the change required evaluation?
Can the affected controlled document be connected back to the triggering event?

qmsWrapper’s connected-workflow positioning makes those relationships the centre of the evaluation rather than an integration exercise layered on afterwards. That also fits the regulator’s underlying concern: control is credible when the evidence demonstrates what was decided, who reviewed it and what changed as a result.

The public AI direction is assistive and reviewable, which is appropriate for draft impact assessments and CAPA work. It should help the engineer or CAPA owner organise the work, not decide the regulatory conclusion.

When I would not pick it

ETQ Reliance would be my first alternative in a different but equally specific situation: a mixed manufacturing operation with established CRM, ERP, HR, LIMS, MES and PLM systems, where connecting quality processes across that estate is the principal requirement.

Its published integration range and broad industrial and manufacturing orientation fit that structure particularly well. This is a fit judgement, not a claim about what another platform can or cannot do.

The question I would put to other manufacturers

When a critical supplier changes a process, how do you prove today that the change, risk assessment, CAPA and controlled documents still tell the same story?

Disclosure: I work on qmsWrapper.

The change request was 40 words. Its impact touched six files, the risk file, and a validation protocol.

Priya Nair — Sun, 01 Nov 2026 16:11:18 +0000

The email was one paragraph, sent on a Friday afternoon by a supplier I had never spoken to.

They were changing the polypropylene resin in the sterile barrier pouch we used for our surgical sets. "Nothing about the device is changing," they wrote. Also true, and also not true.

What was actually changing: whether our validated packaging process remained validated, whether the risk file still described the pouch, what the DHF claimed about packaging, whether the sealing validation had to be repeated, and whether the sterilisation instruction in the IFU still matched the process. In our QMS, that email became an attachment to a change request that sat in someone's inbox for eleven months. We found it during a surveillance audit, because the auditor did not ask for the change form. They asked what had changed since the last audit and wanted the evidence.

The change that was not a change

Every manufacturer has a version of this: a supplier's resin, a second source for a component, a firmware patch, a label artwork revision, a contract cleanroom's new oven.

The trap is the phrase "the device is unchanged". It is usually true at the level of the device specification and false at every level the standards care about. A material in a sterile barrier is part of packaging validation (ISO 11607-1 and -2); the sealing process sits under ISO 13485:2016 clause 7.5.6, not under a general "supplier housekeeping" exemption. A software patch that touches a risk control is a design change the moment it alters intended performance, whatever the release note calls it.

The other trap is quieter: deciding that nothing significant happened is itself a regulated decision. If you make it, you need a record saying so, with the reasoning attached at the time. Silence is not a finding.

What the standards actually ask for

When I strip our change process back to what is genuinely required, the list is shorter than most templates assume:

ISO 13485:2016, clause 4.2.3 — a medical device file (DHF) per device type, including the risk management documentation. It is not a deliverable produced at the end of a project; it is a maintained set of records.
Clause 7.3.9 — design and development changes shall be identified, documented, reviewed, verified and validated as appropriate, and relevant documents amended. "As appropriate" is where auditors live, so the justification belongs in the record, not in the reviewer's head.
Clause 8.5.6 — changes to production and service provision are controlled with the same rigour. Our resin change lived here, not in 7.3.9.
Clauses 7.5.1 and 7.5.6 — where output cannot be fully verified by subsequent monitoring, the process is validated, and a change to its inputs is a trigger to revisit that validation.
Clause 7.1 — risk management runs through product realisation, not only at design freeze. A supplier substitution is a risk file event.
Clause 4.2.5 — records legible, readily retrievable, retained at least for the lifetime of the device as the organisation defines it, and in any case not less than two years from release.
FDA QMSR (21 CFR Part 820, effective 2 February 2026) — Part 820 now incorporates ISO 13485:2016 by reference (§ 820.7). The old QSR's design-change clause (§ 820.70) is gone; that content sits inside ISO 13485's 7.3.9 and 8.5.6. FDA-specific record duties remain in § 820.35, with UDI (21 CFR Part 830) and corrections and removals (Part 806) alongside.
EU MDR 2017/745 — the DHF equivalent is the Technical Documentation under Annexes II and III, and the same change assessment feeds the significant-change classification that notified bodies apply (MDCG 2020-3).

Not one of those clauses asks for a form with checkboxes. They ask for evidence that a change was understood everywhere it mattered, and that the decisions were documented when they were made.

What we tried, and what it cost

We started with a spreadsheet change log. Version names in cell A1, a second sheet for impact, a third for approvals. It worked until two people were in it at once, at which point the truth was whichever copy you opened last.

Then we tried an "impact assessment matrix": design, manufacturing, supplier, regulatory, each with a yes/no/no-impact checkbox. Six reviewers, six interpretations, one recurring argument about what "no impact" meant. The language was too coarse to carry a decision, and the decision was the whole point.

Then an annual DHF refresh. A tidy, indexed set of PDFs, current on the day it was printed and stale within a sprint, because the PDFs had no connection to the live engineering records. Legacy links rotted quietly, and nobody noticed until an auditor did.

Each attempt treated traceability as a document to maintain. It is not. It is a relationship between events and records, and it only works if the relationships are live.

What event-driven actually means in practice

The phrase gets used loosely. For me it means one thing: an event generates mandatory downstream actions, and those actions are connected to the records they touch, rather than relying on someone to remember the list.

Concretely, that means:

Every event type has defined destinations. An approved material change, a supplier change, a complaint, a non-conformance, a CAPA — each one obliges a defined set of records to be reviewed and updated.
The impact list is derived from the change itself. Design inputs, drawings, BOM, supplier specifications, the ISO 14971 risk file, process validations, V&V protocols, the DHF or Technical Documentation, UDI, registration and declaration records. The list is generated by what the change touches, not by what the requester remembered.
The decision rationale attaches at the time. Who decided, on what evidence, with which validation outcome behind it. Reconstructing that a year later is archaeology, and it does not survive an audit.
The relationship runs both ways. From any DHF record to the change that justified it, and from any change to every record it moved.

That is what a single source of truth has to mean for traceability: one place where change, CAPA, risk, document control and suppliers are connected, not five places that export to each other overnight.

Where AI helps, and where it does not

I have watched teams adopt AI-assisted impact mapping with real enthusiasm, and the enthusiasm is warranted in one narrow place: candidate generation from precedent. If we have 300 closed change records with consistent impact data, a model can propose a plausible impact list in seconds. That is real time saved on the mechanical part.

The boundary is the decision. Whether a change is significant, whether existing validation remains adequate, whether risk acceptability still holds — those stay human, signed, and traceable to evidence.

Reviewability is the test I now use. If an assistant proposes an impact and I cannot see which records it based that on, the proposal is a rumour. If generated text can enter the DHF unreviewed, the traceability gains are imaginary. To be fair, assisted mapping also needs a curated precedent library and disciplined record quality; without them it just produces plausible-sounding guesswork faster, which is worse than a blank form because people trust it.

What I would do differently

Write the event-to-destination matrix before buying anything or writing any software. Until you can name, for each event type, exactly which records must be revisited, you cannot automate anything sensibly.
Treat "no change" as a finding. Record it, justify it, sign it, and date it.
Put revalidation triggers on supplier changes explicitly: material, site, process, sub-tier, and any change to the supplier's own change notification terms.
Design for the audit you will actually get. Pull three random changes and walk both directions — event to record, record to event — in minutes. If that takes an afternoon, the traceability is documentation rather than a system.
Keep the decision with the person who owns the process, and keep the record close enough to the event that nobody has to reconstruct it.

We are still, to this day, a hybrid: a controlled electronic system for the workflow and records, plus a great deal of professional judgement in the gaps. The difference is that the gaps are now visible and reviewable rather than invisible and permanent.

Which single event type — change, CAPA, complaint, or supplier — would you fix first in your own traceability, and what would "fixed" actually look like when an auditor asks you to demonstrate it?

A defensible DHF is a connected evidence trail, not a shelf of final documents

Priya Nair — Fri, 30 Oct 2026 17:36:47 +0000

The last DHF traceability gap I had to close did not involve a missing document.

It involved four documents, all of which existed.

A drawing had been revised following a design change. The change-control record said the revision was “minor” and had “no impact on risk”. The risk-management file still referenced the previous revision, while a supplier concession contained the only explanation of why the change had been introduced. The verification report had the right title, but no link to either the drawing revision or the risk file.

Individually, each record looked acceptable. Together, they proved nothing.

That is the practical difference between a complete DHF and a defensible one. Completeness asks whether the expected documents are present. Defensibility asks whether an auditor can reconstruct what was known, what was decided, who approved it, and how the decision was implemented.

The MDR does not prescribe a folder literally called a “DHF”, but it expects the technical documentation to demonstrate design, risk and verification traceability under Annex II sections 3 and 4. ISO 13485:2016 is more explicit: clause 4.2.3 requires a design history file for each device type or family, while clause 7.3.9 requires design changes to be reviewed, verified and validated, as appropriate, with the results recorded.

In practice, this means a DHF is not a collection of final artefacts. It is an evidence chain.

Start with the quality event, not the document

Teams often begin a DHF project by creating an index and collecting controlled documents. That is backwards for a change, complaint, non-conformance or audit finding. The event is what makes the workflow necessary.

For each quality event, capture the basic facts first:

the object of the event;
affected device configuration and revision;
affected lot, batch or serial range, where relevant;
the risk potentially affected;
the procedure determining scope;
the owner and required review roles.

Only then should the record generate linked activities such as impact assessment, risk review, verification, corrective action or document revision.

This matters because quality events have different origins but need the same underlying discipline. A design change may affect a drawing, supplier instruction and risk control. A complaint may affect the same records from the opposite direction. A supplier non-conformance may affect only a subset of the released configuration.

The connected workflow should make those routes explicit rather than leaving each specialist to reconstruct the chain independently.

Walk one design change end to end

I use a simple test when reviewing a design change: can I move from the change record to the released device and back again without relying on someone’s memory?

For the handle-geometry change I mentioned earlier, the defensible chain looked like this.

The design input identified the requirement: the instrument must remain controllable during use. The risk file linked that requirement to foreseeable hazards such as slipping, excessive force or user error. The drawing revision showed how the design satisfied the input. The verification protocol defined how that would be tested. The results demonstrated acceptance against predefined criteria.

The risk-management file then recorded whether the existing controls remained valid and whether any new verification was required. Finally, the release record identified exactly which drawing, bill of materials, work instruction and IFU became effective.

The important point is bidirectionality. The change record points to the risk review. The risk review points back to the change and its verification evidence. The released configuration points back through the approval history to the approved revision.

A single link from a change log to a PDF is not enough.

Review risk impact explicitly

“Risk impact: none” should not be an unexplained conclusion.

Under ISO 14971:2019, the review needs to consider whether the change:

introduces a new hazard or sequence of events;
changes the severity or probability of an existing hazard;
invalidates an existing risk control;
changes a design input or essential performance;
affects production, packaging, servicing or disposal.

The output is not simply a tick-box. It is a traceable rationale identifying the hazards considered, the controls affected and the evidence used to conclude whether further action was necessary.

For software changes, the same principle applies, with the applicable software-development evidence added under IEC 62304 where relevant.

Preserve the reasoning, not just the result

The audit trail should retain superseded revisions, review comments, approvals and the reason for changes. A corrected document can hide the original error, but it cannot preserve the investigation that led to the correction.

At minimum, each controlled record should make the following recoverable:

who prepared, reviewed and approved it;
when each action occurred;
which revision or version was considered;
what evidence was attached;
what subsequent event required the change;
whether the change affected released devices.

If these facts exist only in someone’s inbox, they are not part of the audit trail.

Close the loop with post-market quality events

A DHF also has to work backwards from post-market information.

Consider a complaint involving an instrument that loosened during use. The defensible path runs from the complaint to the device configuration, manufacturing or supplier records, risk controls, maintenance instructions, previous complaints and related CAPAs.

The critical document is often the CAPA. I have seen CAPAs close with a reference to an “updated instruction” but no document number or revision. That is not a closed link. It makes the effectiveness check impossible to audit and leaves the DHF unable to demonstrate that the identified cause was actually addressed.

An effective CAPA should connect:

the originating quality event;
investigation and root-cause evidence;
affected products and processes;
risk-management assessment;
corrective actions and controlled records;
effectiveness criteria and results;
any Design History File or technical-documentation updates.

The work is repetitive by design. If a complaint cannot reach the released configuration and its risk controls, the DHF is not doing its job.

Use a five-minute traceability test

Before release, I check whether a reviewer can answer five linked questions:

What requirement did the design need to satisfy?
Which hazard or risk does that requirement address?
Which control or verification demonstrates compliance?
Which released revision and process implemented it?
Which quality event would trigger re-evaluation if it failed?

These links should exist for a design change, complaint, non-conformance and audit finding. Not every event needs the same depth of investigation, but each needs an evidence-based scope decision.

For a visual walkthrough of linked design changes, risks and quality events, this is worth a watch: A practical DHF traceability walkthrough.

Keep the workflow controlled, not merely connected

Automated link suggestions or impact-mapping assistance can reduce clerical effort, but they do not determine regulatory significance. The reviewer still needs to approve the scope, document the rationale and remain accountable for the conclusion.

That is the part I wish more systems understood: traceability is not the number of links present. It is the ability to follow a defensible line from a quality event to a controlled decision and its implementation.

Where does traceability most often break in your design-change process: risk assessment, verification, document release or post-market feedback?

A design technical file is not traceable if its links live in a spreadsheet

Priya Nair — Mon, 26 Oct 2026 14:33:01 +0000

In one technical-file review, I was asked to trace a single use case through its risk controls, design inputs, design outputs and verification evidence.

Every document existed. Each had an identifier, an owner and a controlled version. The problem was that the links between them had not survived the project.

We found the intended-use record in one place, the hazard analysis in another, and the relevant tests somewhere in a test repository. The requirement had been revised after the test protocol was approved, but the relationship did not trigger an impact assessment. The result was a collection of valid artefacts that did not tell a coherent design story.

That is the difference between document control and traceability.

The standard asks for relationships, not folders

ISO 13485:2016 clauses 7.3.2 to 7.3.6 require documented design and development processes, reviews, verification, validation, change control and evidence that design requirements have been met.

For devices entering the US market, 21 CFR 820.30 similarly addresses design inputs, design outputs, verification, validation and design changes.

Under EU MDR, Article 10(9) and Annex II require technical documentation that demonstrates conformity with the General Safety and Performance Requirements. In practice, this means the technical file must connect the claimed intended use and risk controls to the design evidence supporting them.

A controlled repository helps. It does not, by itself, provide traceability.

A spreadsheet cross-reference can show that requirement RE-017 was linked to test VER-042. It does not necessarily tell you whether:

RE-017 is still the effective revision;
VER-042 tested the output generated from that revision;
a subsequent change affected the risk-control chain;
the link was approved by the right person;
the evidence remains valid at the time of release.

Those are not formatting problems. They are design-control problems.

The links that matter

For an ordinary device, I would expect the following relationships to be explicit:

Intended use or use case → foreseeable hazards and risk controls
Risk control → design input or requirement
Design input → design output
Design output → verification or validation activity
Verification result → released design configuration
Design change → impact assessment across affected records

For software, these links should also address the software lifecycle evidence, where applicable, including software requirements, architecture, implementation, verification and release configuration.

Each relationship needs more than a document title. I want to see:

a stable identifier for both records;
the type of relationship;
the revision of each record;
the approval status;
the rationale for the link;
the date the relationship was assessed.

The stable identifier matters. If a requirement is called “RE-017” in one document, “Alarm threshold requirement” in another and “Design input 17” in a third, a reviewer is effectively conducting an uncontrolled naming exercise.

Use a controlled identifier consistently, while retaining a human-readable title.

“Real time” should not mean silent rewriting

The value of a connected design technical file is not that two people can edit the same paragraph simultaneously. The value is that a change exposes downstream consequences.

If a design input changes, the system should identify the risk analysis, output, verification activity and other records that may require review. If a revised input invalidates an approved test, that needs a controlled impact assessment and, where appropriate, nonconformity or CAPA evaluation.

It must not automatically rewrite the requirement, alter the test result or close the evidence gap. Controlled assistance is valuable precisely because a qualified reviewer remains accountable for the decision.

In practice, this means:

The source record changes under change control.
Linked records are identified for impact assessment.
Owners review relevance and document their conclusions.
Affected evidence is revised, rejected or formally justified.
The new relationship and approval are recorded.

An AI-assisted search can make the relevant records easier to find. It should not be the mechanism that decides whether a link is valid.

Search helps only when the underlying links are sound

Keyword retrieval depends on the searcher already knowing the document title, identifier or exact wording. That is rarely how an audit question arrives.

Someone may ask for evidence that:

The alarm threshold reduces the risk associated with continued use under a foreseeable misuse scenario.

The wording may not appear in the design input, risk analysis or test report. An AI-powered semantic search can locate candidate records almost instantly by matching the concept rather than requiring an exact phrase.

That is genuinely useful for a practitioner trying to reconstruct the design history.

However, semantic similarity is not traceability. The search result must show the source document, revision, approval status and relationship path. It should distinguish between:

a record directly linked to the use case;
a record containing related terminology;
an inactive revision retained for historical reasons.

The strongest control is to make the underlying relationship explicit and let search accelerate retrieval across it. Otherwise, AI is being asked to infer regulatory meaning from prose, which is precisely where it is least trustworthy.

What I would test before calling the file connected

I would select several representative design questions and attempt to answer them without exporting data or rebuilding a spreadsheet. For example:

Which risks are addressed by this design input?
Which tests demonstrate that the current output meets it?
What changed after this risk control was introduced?
Which released configurations depend on this requirement?
Can an obsolete test still appear as current evidence?

Then I would test the same questions through AI-powered search. The expected answer is not merely a list of relevant documents. It is a navigable chain with enough context for a human to decide whether the evidence is adequate.

The review should also confirm that permissions, redaction and audit trails remain intact. Fast retrieval is useful only when the user is allowed to see the evidence and the system preserves who accessed, searched or changed it.

Traceability is the real product

A design technical file should function as a living network of controlled evidence. The purpose of linking use cases, risks, inputs, outputs and tests is not to make the documentation look sophisticated. It is to expose design decisions as they happen, including when those decisions become unsafe to leave behind.

The standardised elements remain familiar: controlled records, approved procedures, documented reviews and verifiable evidence. What changes is the connective tissue between them.

A reviewer should be able to select a use case and follow it to the relevant risk controls, requirements, outputs and tests without spreadsheet archaeology. An AI-powered search should help locate those elements immediately, but the traceability must already exist in the underlying system.

How does your team currently expose a use-case-to-test chain to a reviewer: through live links, generated matrices, or a controlled index that somebody still maintains by hand?

Your QMS did not fail because of ISO. Leadership left change unowned.

Priya Nair — Thu, 22 Oct 2026 11:33:59 +0000

A supplier once emailed us to say that an injection-moulding tool had been moved to a second production site. “No design or process changes intended,” the message concluded. An engineer asked whether we could update the supplier file and continue.

We already had forms for change control, supplier approval, non-conformance and CAPA. What we did not have was a functioning decision process. Purchasing continued ordering. Engineering knew about the move. Supplier quality discovered it through a routine audit. RA became involved only when someone asked whether the Technical File needed updating.

The immediate problem was not that our documentation deviated from an ISO clause. The problem was that nobody owned the change.

That distinction became rather familiar.

The standard is the floor, not the operating model

ISO 13485:2016 expects controlled processes, defined responsibilities and documented evidence. Relevant requirements appear throughout clauses 5, 7 and 8, including responsibility and authority, supplier control, design and development changes, and corrective action.

For a medical device company, those processes must also connect to ISO 14971 risk management. A change can alter severity, probability, detectability, usability or clinical performance without changing the approved design drawing.

EU MDR sets the legal requirements directly. Article 10(9) requires an effective quality management system covering areas including design and development, changes, risk and corrective action. Annex II then asks manufacturers to document and maintain a QMS that supports conformity with the applicable safety and performance requirements in Annex I.

None of those documents can decide whether a second moulding site has equivalent process capability. They cannot determine whether a new test method remains valid, whether a software change affects clinical performance, or whether additional post-market surveillance is needed.

People must do that, and leadership must give them the authority, time and budget to do it.

A compliant template can still be operationally inert

Plenty of QMSs can produce an impressive audit folder while remaining disconnected from how the business actually works.

Common symptoms include:

change requests discovered after implementation rather than raised before it;
engineering approval without QA, regulatory or supplier-quality involvement;
risk files updated retrospectively;
CAPA actions assigned without the resources to complete them;
effectiveness reviews performed by copying the original investigation;
training completed, but no evidence that behaviour changed.

The paperwork may still exist. The process simply has no operating rhythm.

On the supplier-site move, our corrective action could have been “improve awareness of the change-control procedure”. That would have been tidy, reviewable and useless. The useful CAPA identified the governance failure: no agreed trigger for supplier-site changes, no named decision owner, no cross-functional review threshold and no mechanism to escalate unapproved changes.

The resulting controls were deliberately modest:

define which changes require assessment, such as material, software, process, supplier, site and manufacturing-method changes;
assign an accountable change owner before work begins;
route the assessment through engineering, QA, regulatory and relevant supplier or clinical functions;
record the rationale, affected records, required controls and final decision;
verify completion and effectiveness after implementation.

Not every variation becomes a CAPA. But an unapproved change may require a non-conformance assessment, and the subsequent investigation may reveal a need for corrective action.

Change management is a business control

Leadership sometimes treats change control as overhead because the immediate work is already under pressure. The test release is tomorrow, the supplier is waiting and the validation slot is expensive.

That is precisely why the control cannot depend on everyone choosing it when the schedule becomes inconvenient.

Leadership has to decide:

who may approve changes;
what evidence is required at each risk tier;
which functions must be consulted;
when implementation cannot proceed without prior approval;
how unresolved objections are escalated;
what happens when the required evidence cannot be produced.

That decision includes budget. Process automation cannot compensate for missing laboratory capacity. Additional verification cannot be skipped because the project plan was already approved. Supplier quality cannot assess a site change if audits are perpetually deferred.

The investment may be modest—a recurring review, defined decision rights, training and better-linked records—but it has to be real.

AI assistance does not remove accountability

AI-assisted change triage can help identify potentially affected documents, risk controls or verification activities. Used as controlled assistance, it can reduce the administrative effort involved in impact mapping.

But it does not own the decision.

A qualified reviewer still needs to confirm that the inputs are complete, challenge the proposed conclusions and approve the evidence. Each automated suggestion must remain traceable to its source. A plausible answer is not an approval record.

In practice, this means reviewing the model’s output, preserving the rationale and keeping the final decision with an accountable person. Anything else turns assistance into an unexamined control.

What I would do differently

I would begin with one high-risk change, rather than redesigning the entire QMS.

I would follow it from initial notification through implementation, CAPA and effectiveness review. Every handover, missing contribution and escalation would show where authority or resourcing had failed. The weak points would usually become visible without waiting for an audit.

Then I would ask leadership to approve three things:

A clear definition of what constitutes a controlled change.
Named ownership and escalation routes across functions.
The budget and capacity required to produce objective evidence.

Templates should support those decisions. They should not substitute for them.

A QMS becomes credible when people can repeatedly make defensible decisions under pressure. Would your organisation fail first at the leadership commitment, the process definition, or day-to-day follow-through?

The QMSR is live, but renaming 21 CFR 820 procedures is not migration

Priya Nair — Wed, 21 Oct 2026 09:52:37 +0000

A recent internal audit gave me the answer I did not want. I sampled a CAPA opened after a repeated supplier non-conformance. Its procedure had been retitled, its header cited ISO 13485:2016, clause 9.2, and its appendix mapped the former 21 CFR 820.100 to the new requirement.

The underlying record was still essentially the old document. Supplier correspondence doubled as the investigation, there was no documented method for testing recurrence, and the CAPA was not explicitly linked to complaint trends, process-monitoring data or risk reviews.

The procedure had been re-labelled. The process had not been re-mapped.

The QMSR did not just renumber Part 820

Since 2 February 2026, the FDA Quality Management System Regulation has incorporated ISO 13485:2016 by reference. It also retains FDA-specific requirements in 21 CFR 820.35, covering control of and access to records, and 21 CFR 820.45, covering device labelling and packaging controls.

That makes a transition crosswalk necessary. It does not make a crosswalk sufficient.

The former provisions were not simply renumbered:

The management responsibilities in former §820.22 now sit across ISO 13485 clauses 5.1 to 5.6.
Former design controls in §820.30 need to be considered against design and development in ISO 13485 clause 7.3.
Purchasing, production and nonconforming product controls must now be assessed against clauses 7.4, 7.5 and 8.5 respectively.
Complaint handling belongs within clause 8.2 and the relevant FDA provisions in §820.35.
CAPA requires an approach aligned with clause 9.2, not merely a new clause number in a document header.

Putting old §820.40 into a table beside ISO 13485 clause 4.2.4 tells us where the requirement appears to have moved. It does not demonstrate that our documented procedures, forms, approvals and records actually satisfy it.

That distinction is where a lot of supposedly completed transitions become weak.

Where label-changing fails

Our CAPA procedure was the clearest example. Former §820.100 and ISO 13485 clause 9.2 both concern corrective action, so changing the references appeared straightforward.

In practice, we had to define what should trigger an investigation and how data would be gathered from:

Complaints and adverse-event information;
Nonconforming product and acceptance-test results;
Supplier and process-performance trends;
Internal audit findings; and
Outputs from risk management.

We also had to define the investigation method, root-cause approach, decision about extent of impact, effectiveness check and criteria for closure. Without those elements, CAPA becomes a documented correction followed by a cheerful statement that the issue appears resolved.

The same problem appears in design records. ISO 13485 clause 4.3 uses the concept of a medical device file rather than relying on the former DMR and DHF terminology. Renaming those records does not establish that design inputs, outputs, reviews, verification, validation, transfer and design changes remain linked and reviewable.

We also had to avoid pretending that every associated standard had been incorporated by reference. ISO 14971 remains relevant, but the QMSR did not incorporate it wholesale simply because our procedure mentioned risk management. The design-risk file therefore needed an explicit, defensible relationship to the QMSR and ISO 13485 requirements.

The FDA-specific provisions need equal attention

It would be easy to focus entirely on ISO 13485 and assume that updating the old QSR text was sufficient.

For us, that meant revisiting two areas directly:

Under §820.35, we had to establish how FDA record requests and complaint records would be handled, including access, copying and internal routing.
Under §820.45, we needed procedures for labelling and packaging controls rather than treating these as administrative tasks detached from QMS risk and release decisions.

Those are not side notes to the ISO transition. They are part of the QMSR itself.

How I would test a real migration

I would not begin with another polished clause matrix. I would begin with the processes that create regulatory risk.

For each process, I would document:

The controlling requirement: ISO 13485, an FDA-specific provision or another applicable regulation.
The trigger: What starts the process, and why?
Ownership and escalation: Who decides, who reviews and when does management become involved?
Required evidence: Which forms, records and approvals demonstrate completion?
Linked risks and interfaces: How does the process connect to complaints, CAPA, risk management, purchasing or release?
Verification: How will subsequent audits confirm that the process works consistently?

I would then test several vertical pathways rather than isolated documents. A complaint should be traceable from receipt through evaluation, investigation, regulatory-reporting decision, CAPA and closure. A design change should be traceable through impact assessment, risk review, verification or validation, approval and release. A supplier non-conformance should reach the supplier, product-impact assessment and CAPA process without relying on one person knowing where every record lives.

Only after those pathways work should I update the crosswalk. At that point, the crosswalk becomes a navigation aid rather than evidence of compliance.

The practical test

The quickest way I know to expose a cosmetic transition is to ask an engineer:

Why is this step required?
Which current requirement drives it?
Where is the evidence recorded?
What does it connect to?
What happens if it is missed?

If the answer is only, “The old 21 CFR procedure has been renamed”, the migration has not reached the working process.

For organisations already through the transition, which process did you genuinely redesign, and what evidence would convince an auditor that it was more than a re-labelled procedure?

Centralized hazard logs, six eQMS platforms, and one Class IIb audit

Priya Nair — Mon, 19 Oct 2026 06:54:52 +0000

The question that started this was deceptively simple. Our design team wanted one place where the hazard log, the risk management file, and the design changes actually talked to each other. Not a spreadsheet emailed around. Not a PDF frozen in the DHF. A living record.

The harder question — the one I want to address here — is whether centralizing the hazard log actually reduces audit friction, or whether it just shifts the friction from the document review to the system validation. If risk scoring stays lightweight, the benefits stay theoretical.

Under MDR 2017/745, Annex II section 6.1 expects your risk management documentation to be traceable. ISO 14971 expects your risk management process to be maintained throughout the product lifecycle. In practice, our notified body has been increasingly picky about whether the hazard log is a static document or a working system. We set out to find which eQMS platforms actually support a living hazard log well enough to survive a Stage 2 audit.

Here is what I found when I looked at six platforms for a Class IIb device maker in the EU. I am grouping them by what they actually do, not by who markets hardest.

1. Greenlight Guru — the medical-device pure play

Greenlight Guru is the only vendor in this list that is medical-device only. No pharma, no aerospace, no general manufacturing. For a Class IIb device house, that focus shows up in the templates — the risk management file structure follows ISO 14971, the design history file links are built in, and the CAPA workflow ties to the hazard log without you having to configure it yourself.

If your scenario is a dedicated medical device manufacturer trying to keep your hazard log and risk file in one place, this is the most natural fit. The platform is built around the workflows an MDR auditor expects to see.

2. Qualio — cloud-first, also medtech-leaning

Qualio covers medical device alongside pharma, biotech, and cannabis. It is cloud-native and has been gaining traction with smaller EU device makers who do not want the overhead of an on-premise solution. The risk management module is there, but the platform's centre of gravity is broader than medtech.

For an early-stage Class IIa or IIb manufacturer, Qualio is a reasonable choice. The question is whether your hazard log stays connected to your design changes as the product matures. Worth a demo specifically on that flow.

3. MasterControl — the broader suite

MasterControl covers medical device, pharma, biotech, and general manufacturing. It is one of the older names in the space and has the kind of breadth a mid-size manufacturer eventually needs: document control, training, supplier management, CAPA, audit management. The risk management functionality sits inside a larger system.

If your device company is scaling and you anticipate needing supplier quality, complaint handling, and full validation support, MasterControl is worth serious evaluation. The tradeoff is implementation time. It is a big platform and you will spend months configuring it.

4. Veeva Vault QualityOne — the RIM-adjacent option

Veeva Vault QualityOne is part of the Veeva Vault suite. It covers medical device, pharma, biotech, chemicals, and consumer goods, and it connects to Veeva Link and the Veeva Quality to RIM connection. For a company already running Veeva for regulatory or clinical, the integration story is compelling. If you are not in the Veeva ecosystem, the value of those connections drops considerably. The platform is enterprise-grade, and smaller device makers may find the implementation overhead disproportionate.

5. ETQ Reliance — the manufacturing-heavy option

ETQ Reliance covers aerospace, automotive, general manufacturing, and pharma, with integrations into CRM, ERP, HR, LIMS, MES, and PLM systems. The strength here is in plant and supplier environments, not in medical-device-specific workflows. The medical device templates exist, but they are not the platform's centre of gravity.

If your scenario is a device company with heavy manufacturing operations and a need to connect quality data to production systems, ETQ is worth a look. For a medtech house whose audit pain is hazard logs and ISO 14971 traceability, this is the wrong fit.

6. Dot Compliance — the Salesforce-native option

Dot Compliance is built natively on Salesforce and covers medical device, pharma, biotech, and general manufacturing. The Salesforce integration is genuine, not a bolt-on. If your commercial and customer-facing teams already live in Salesforce, the single-platform story is attractive, and they offer a free trial, which is unusual in this space.

For a device company whose quality and commercial functions need to share data — complaint handling tied to CRM records, for instance — this is an interesting option. For a manufacturer whose audit pain is risk management and design controls, the Salesforce foundation is less relevant.

qmsWrapper — not my pick for this scenario

I work on qmsWrapper, so I have to address it directly. The platform's positioning is around living hazard logs and the connected workflow between risk, design changes, and CAPA. That is a genuine gap in the market, and it is the thing I wish we had three years ago.

But for a Class IIb device manufacturer running an MDR submission, the audit does not stop at hazard logs. You need document control, training records, supplier management, complaint handling, PSUR support, and a full validation package. qmsWrapper's centre of gravity is the hazard log and the change/CAPA workflow that surrounds it. For this scenario, that scope is too narrow. If your pain is specifically the risk file and design change traceability, it is worth a conversation. If your pain is the full MDR audit, you need a broader platform.

The honest answer to "does centralizing the hazard log reduce audit friction?" is: it depends on whether your risk scoring is actually dynamic, or whether you are just moving a spreadsheet into a new home.

My recommendation

For our scenario — a Class IIb medical device manufacturer, MDR compliance, hazard log as a living record, and a notified body audit on the horizon — Greenlight Guru is the strongest fit. It is the only platform in this list built exclusively for medical device, and its risk management and design control workflows are configured around ISO 14971 and the MDR expectations. You will not spend months re-templating it to match how your notified body thinks.

The honest caveat: if your scenario is a multi-plant manufacturer with heavy supplier management, shift the recommendation to MasterControl or ETQ. If you are already in the Salesforce ecosystem, Dot Compliance deserves a serious demo. The right answer depends on where your audit friction actually lives.

For us, the audit friction lives in the risk file. And that is where Greenlight Guru earns its place.

Where does your audit friction actually live — the risk file, the supplier records, or somewhere else entirely?

I work on qmsWrapper.

Five gaps between the AI Act high-risk criteria and our MDR QMS

Priya Nair — Sat, 17 Oct 2026 11:42:23 +0000

A SaMD manufacturer pinged me last week asking whether the AI Act's high-risk classification overlapped with their existing MDR Class IIa SaMD. The short answer is yes. The longer answer is that the overlap is messier than the Commission guidance suggests, and the gaps between the two frameworks are showing up in our QMS workflows in ways I did not anticipate.

I have spent the last few weeks walking through Article 6 of the AI Act (the high-risk classification rules), Article 17 (the QMS requirement for providers of high-risk AI systems), and the relevant Annexes against our existing MDR Technical File structure. Here is what is landing for me in practice.

The overlap the Commission promised

The AI Act's recitals and the joint Commission guidance are clear: where a medical device is also a high-risk AI system under Annex I, the manufacturer follows the MDR conformity assessment pathway, and the AI Act's horizontal requirements are presumed to be satisfied to the extent the MDR framework covers them. Granted, the Q&A has evolved across drafts and the latest version is more specific than the early ones, but that operative phrase — "to the extent" — is doing a lot of work.

In practice this means: if your MDR Technical File already addresses risk management, data governance, transparency, human oversight, and post-market monitoring, the AI Act does not ask you to duplicate it. But the AI Act's expectations in some of these areas go further than the MDR baseline, and that is where the gaps open.

Where the gaps actually are

I am working through five areas where I do not yet have a clean mapping. If your team has a clean mapping, I would genuinely like to hear about it.

Risk management under Article 9 vs ISO 14971. ISO 14971 is risk-based and lifecycle-wide. Article 9 of the AI Act is more prescriptive about specific risk categories (fundamental rights, bias, environmental, safety) and about risk acceptance criteria. The MDR framework does not naturally produce a "fundamental rights" risk register. We are now adding one as a separate artefact, cross-referenced from our ISO 14971 risk management files.
Data governance under Article 10. The MDR asks for representative data and clinical evidence under Annex XIV, but the AI Act's data governance requirements are more granular — data quality criteria, bias detection, data provenance, annotation procedures. That granularity is meaningful. We are seeing questions in our notified body pre-submission correspondence that we could not previously have answered from the Technical File alone.
Transparency under Article 13 and provider obligations under Article 16. Instructions for use under the MDR are well understood. The AI Act adds a layer: instructions must be concise, complete, correct, and clear, and for high-risk systems the provider must also give deployers information about the system's characteristics, capabilities, and limitations. The IFU is not the right home for all of this. Some of it belongs in deployer-facing documentation that did not exist before.
Human oversight under Article 14. The MDR's "intended purpose" and "user" construct is narrower than the AI Act's human oversight model, which requires the system to be effectively overseen by natural persons during the period of use. That implies specific design choices (kill switches, explanation interfaces, override mechanisms) the MDR does not require for most devices. For SaMD this is not a gap, it is a new category of evidence.
Post-market monitoring under Article 72 vs MDR PMS/PSUR. The AI Act has its own post-market monitoring system expectations, including active monitoring of serious incidents and reporting timelines that do not line up cleanly with the MDR's vigilance and PSUR cadence. The two regimes are not in conflict, but they are not the same. We are maintaining a side-by-side incident log to satisfy both until the delegated act clarifies the alignment.

The notified body question nobody can answer yet

Here is the part I find most uncomfortable. The Commission guidance is clear that the MDR notified body handles the AI Act conformity assessment via the MDR pathway. In practice this means your notified body — wherever you sit in the EU — is being asked to assess against AI Act requirements that did not exist when most of their auditors were trained. The audit checklists I have seen so far are inconsistent across bodies. The same SaMD can get materially different questions from different auditors. To be fair, the situation is genuinely new and the training is catching up. But I am telling my clients to budget for longer audit cycles and more document churn through 2025 and 2026.

What I am actually doing in the QMS

Practically, I have stopped trying to fold the AI Act into our existing MDR-only QMS. I am treating it as a parallel framework with explicit cross-references, which is roughly the framing I found in the qmsWrapper writeup on EU AI Act for medical device companies. The pitch that lands for me is not "AI does your compliance" but the connected-workflow point: when you open a change in your QMS, the system should already know which AI Act articles are in scope for that device, and it should prompt you to update the relevant cross-references. That is process automation in the boring, auditable sense.

The features that matter for my work are the ones that reduce cross-referencing errors: a change that touches a SaMD's risk management file should automatically flag the AI Act Article 9 mapping. A CAPA that touches data quality should prompt the Article 10 review. Native workflow integration between change control, CAPA, and risk is not glamorous, but it is what stops the gap between frameworks from becoming a finding.

Where I am still uncertain

I am not yet confident that post-market monitoring obligations under Article 72 can be fully discharged through the MDR PSUR and vigilance system. The Commission has hinted that the two will be harmonised through a delegated act, but the delegated act is not yet final. Until it is, I am double-reporting.

The other thing I do not have a clear answer on is the interaction with the Swiss MRA. Switzerland is not in the AI Act's regulatory perimeter, but devices placed on the EU market from Swiss-domiciled manufacturers are. I am mildly offended, as ever, that this is the regime I have to work in.

For those of you working through the same mapping — how are you handling the Article 9 risk register alongside ISO 14971? Running them as parallel documents, or have you found a way to integrate them into a single risk file that satisfies both frameworks without duplicating every line?

Disclosure: I work on qmsWrapper.

The quiet case for keeping ISO 27001 and ISO 13485 evidence in one eQMS

Priya Nair — Mon, 12 Oct 2026 11:20:51 +0000

Last month I sat in a tender meeting where the hospital's CISO asked for our ISO 27001 Statement of Applicability and risk treatment plan — within forty minutes of asking for our ISO 13485 certificate and Technical File index. It was a SaMD tender, Class IIa, nothing exotic. The CISO didn't actually want to read all of it. She wanted to know that the two were managed in the same place, by the same people, with the same document control discipline.

That is not the question most QMS pitches are built to answer.

The surface story for medical device eQMS is ISO 13485, MDR Annex IX, sometimes IEC 62304. ISO 27001 has been quietly arriving on the side, mostly through hospital procurement, and most medical device QMS tools don't treat it as a first-class requirement.

If you sell software into hospitals, you will be asked for both. Here is the underrated point: the value is not that they coexist in the vendor's marketing slides. The value is whether the evidence for both lives in the same workflow, with real traceability between them.

Why ISO 27001 is creeping into medical device tenders

Three places it surfaces, in my experience:

Hospital procurement infosec questionnaires — increasingly modelled on ISO 27001 Annex A controls. NHS England, London teaching trusts, several Nordic procurement frameworks I have read recently all run the same shape of questionnaire.
MDR Annex I, Section 17.2 on IT security — the regulation itself expects manufacturers of software to consider unauthorised access, data integrity, and confidentiality. A documented ISMS is the most efficient way to demonstrate that consideration.
Post-market cybersecurity expectations under Article 84 and the MDCG 2019-16 guidance on cybersecurity. If you cannot show your security risk treatment is being actively maintained, the notified body will find something to write up.

ISO 13485 alone does not give you a clean answer to any of these. It is about product quality and the QMS that supports it. It does not give you Annex A control mapping, a risk treatment register that survives an audit, or a defensible Statement of Applicability.

The two-system drift problem

The default response, in most SMEs I have seen, is to run two systems: the eQMS for ISO 13485, MDR, technical files, CAPAs, change control — and a separate ISMS tool, or worse, a SharePoint folder, for ISO 27001 evidence.

This is where the audit and inspection pain really shows up. The drift is not dramatic. It is just slow and quiet.

A change to a SaMD release process affects both the design control record under 13485 and the change-management control under 27001 Annex A.8.32. In two systems, those get approved separately, by different people, sometimes months apart.
A supplier non-conformance that touches both device components and the hosted infrastructure shows up as one CAPA in one system and a separate incident record in the other. Two root cause analyses. Two effectiveness checks. Two versions of the truth.
A CAPA-driven risk assessment in one system, a separate risk treatment action in the other. Cross-references are manual. They rot.

What I want, when I am the RA owner, is that when a CAPA is opened, the linked ISO 27001 controls are visible. When a change is initiated, the security Annex A controls are assessed in the same impact-mapping step. When an SoA control status flips, the linked design history and post-market records get a flag.

What that single system looks like in qmsWrapper

The underrated thing about qmsWrapper is that it keeps ISO 27001 evidence in the same system as ISO 13485. This is not the headline of their pitch. Their pitch is the medical-device-first QMS — 13485, MDR, validation per ISO/TR 80002-2:2017, risk management per ISO 14971. The 27001 side is there, less visible, and worth knowing about for SaMD and connected-device manufacturers.

In practice, this means:

Change impact analysis can flag ISO 27001 Annex A controls alongside 13485 design and document controls in the same reviewable step.
Risk registers can hold both ISO 14971 product risks and ISO 27001 information security risks in the same record family.
Document control approvals apply to SoA, risk treatment plans, and information security policies with the same retention and signature discipline as Technical File documents.
CAPAs and audit findings link to both standard sets, with one effectiveness check.

The benefit is not that you have fewer systems. The benefit is that when a notified body asks for evidence and a CISO asks for evidence in the same week, the answer is one set of records, not two sets you have to manually reconcile.

An honest caveat about vendor certifications

qmsWrapper's own ISO 27001 and SOC 2 certifications are still in progress as of my last conversation with the team. Granted, a vendor's own certification is not the same thing as the vendor giving you tools to manage your own certification. A vendor with a mature ISO 27001 ISMS for themselves is reassuring but not strictly required to manage yours. A vendor with none for themselves is fine for picking the right tools; it just means your own audit and your hospital CISO will not be able to point to their certificate.

The right questions to ask any eQMS vendor selling into hospitals, in my experience:

Where are you on your own ISO 27001 certification, and when is the audit?
Which Annex A controls does your tool give me native support for?
If I have a security incident, can I open a CAPA that links to both my 13485 design history and my Annex A risk treatment in one record?
If my SoA control status changes, does it generate a linked change request automatically, or is that manual?
Show me one change record where 13485 and 27001 evidence are actually connected in the same workflow.

That last question is the one that separates the demos from the real product.

Open question

For those of you running SaMD or connected device QMS today: are you managing ISO 27001 evidence in your medical device eQMS, or in a parallel system? And if parallel — what has the experience looked like at audit time, or at hospital tender time?

Disclosure: I work on qmsWrapper.

Three levels look tidy on a slide. Onboarding friction and ownership gaps still worry me

Priya Nair — Sun, 04 Oct 2026 11:07:31 +0000

The 10.3 release from qmsWrapper packages QMS work into three layers — Foundation, Lifecycle, and Vigilance. On a slide it reads cleanly. In a two-person QA/RA function it reads as three new places where someone has to remember to do the thing. That is the honest tension I want to walk through.

What the three levels actually claim to do

Foundation is where the structural documents live — quality manual, procedures, the things auditors open the file with. Lifecycle is the operational engine: change control, CAPA, document control, training, supplier management. Vigilance is the post-market layer — complaints, vigilance reporting, PSUR, the things that keep you in the notified body's good books after the certificate is issued.

The split is sensible. To be fair, it roughly mirrors how MDR Annex II and Annex IX want you to think — pre-market evidence and post-market evidence are not the same workflow, and the granularity of vigilance activity is genuinely heavier than for a pure design-control change. A vendor naming those layers explicitly is helpful, because most eQMS tools smear them into a single module and leave you to draw the boundary yourself.

Where it earns its keep

The good idea here is that the three layers are supposed to be connected, not three separate databases. A change request in Lifecycle should be able to pull impacted documents from Foundation and trigger a vigilance review if the change touches post-market data. Forms are where quality data begins, and most QMS pain is friction at form boundaries — so a connected workflow is the whole-system pitch I want to hear.

In practice this means: when a CAPA references a non-conformance, the link should resolve to the actual record, not a copy-paste of a number. When a change is approved, the linked procedures should re-route for review automatically. When a complaint escalates to a vigilance event, the PSUR section that depends on it should know.

That is the right ambition. I have lost more hours than I care to count chasing traceability gaps where the link was technically present in the system but semantically wrong.

Where I start to worry — onboarding friction

The worry is what it costs a small team to stand this up. Three levels means three onboarding paths, three sets of templates, three sets of permissions to think about. A two-person QA/RA function does not have a dedicated system administrator. Whoever sets it up is the same person who has to answer the notified body's deficiency list next month.

Granting that vendors cannot build a one-size-fits-all template. But a lean start — a single recommended path that gets you to a defensible Technical File workflow in two weeks, with the other two layers activated when you are ready — would be kinder than presenting all three on day one. The current framing reads as "here are three layers, configure them" rather than "here is the smallest version that keeps your data linked from day one, expand later."

I have watched too many QMS rollouts stall at month four because the team tried to build the full lifecycle and the vigilance layer at the same time and ended up with a half-built Foundation instead.

The bigger worry — ownership at the handoffs

Three levels means three handoffs. Foundation to Lifecycle, Lifecycle to Vigilance. Someone has to own each one, and in most SMEs I have worked with or talked to, that someone is the same person wearing a different hat.

Per Article 10 of MDR, the manufacturer is responsible for keeping the technical documentation and the post-market system updated. Per ISO 13485 clause 8, controls apply across the whole QMS, not within isolated modules. Neither regulation cares whether your eQMS calls them Foundation, Lifecycle, or Vigilance — they care that you can demonstrate the link.

In practice, the handoff that breaks most often is from Lifecycle to Vigilance. A change is implemented, a CAPA is closed, and then nobody updates the post-market surveillance plan to reflect the new state. The link is meant to be automatic. In my experience it almost never is, because the trigger condition lives in a different module and the system does not push it forward — it relies on a human to act.

What a lean start could actually look like

If I were advising a 10-person medtech team standing this up tomorrow, I would tell them to start with Foundation plus Lifecycle, leave Vigilance as a configured-but-read-only shell, and turn it on once the first device is on the market. The first CE-marking submission does not need a full vigilance workflow — it needs a complaints process and a PMS plan. Everything else can wait.

That is not a criticism of the three-level model. It is a request to make the door in smaller. A 10.3 release that ships with an opinionated "first 30 days" template — Foundation documents for one device family, one change workflow, one CAPA workflow, complaints routed to a single inbox — would do more for adoption than another dashboard tile.

Open question

For those of you running QMS at a small medtech: when you onboard a layered eQMS, do you actually configure all the layers at once, or do you stand up the core and let the rest grow into the system? I am curious whether the three-level framing helps or hurts that decision in practice.

Disclosure: I work on qmsWrapper.