A QMS Is Required. But Is It Learning?

Every medical device manufacturer in this market has a QMS. We have to. FDA in the United States and Health Canada in Canada both require formal quality systems (and equivalent obligations exist in other jurisdictions our team may eventually ship into). Most of us already have complaint handling, CAPA, post-market surveillance, risk files, supplier controls, and design controls — and the audit binders prove it. The question we are starting to ask is no longer do we have a QMS? — it is does our QMS bring prior review context back when the next event lands?

This article is the manufacturer-side companion to our earlier piece, Why Medical Device RA/QA Teams Need a Product-Specific Compliance Digital Twin. That article defines the concept. This one looks at it from the reviewer’s daily work: when a new product event arrives, does prior context show up automatically — or does each reviewer re-organize the history by hand?

1. The morning a complaint lands on the reviewer’s desk

Picture the kind of morning every RA/QA team has had at least once this quarter.

A complaint comes in on one of our infusion pumps. Same product line. The reviewer opens the complaint record. What is already sitting somewhere in our QMS, but is not in the reviewer’s pane right now:

• A complaint with a similar failure mechanism was reviewed nine months ago. The reviewer at the time concluded: not reportable, monitor with a screening review at six months.
• A peer-device recall on a related component was reviewed five months ago. Conclusion: relevant to monitor, not relevant to this product right now — with the rationale.
• A supplier change-control on the part this complaint touches is pending. The supplier-quality reviewer is a different person on a different team.
• A software update last quarter touched the alarm subsystem named in this complaint.

The honest question for our team: when this morning’s reviewer sits down with the complaint, do all four of those previously-reviewed items appear in the same pane, with the prior rationale already attached? Or does the reviewer have to remember to look, hunt across four different folders, and rebuild the rationale by hand?

If the second answer is closer to reality, that is not a QMS deficiency. The QMS recorded everything correctly. It is a learning-loop gap — the gap between storing a record and retrieving it on the next event. That gap is what this article is about.

2. The question that actually shows up in our daily work

Reviewer-perspective, three concrete questions our team can put to its own quality system today:

1. When the next product event lands on someone’s desk, does prior review work come back into context automatically, or does the reviewer have to remember to go look for it?
2. We know to put the new Decision Record into the PMS narrative, the risk file, the CAPA screen, the supplier review — once it is filed there, does it come back to the next reviewer when it would help?
3. Does the system organize the prior history for the next review, or does each reviewer re-organize the same history by hand, every time?

Storing a record and bringing the record back when it is needed are two different jobs. The QMS is good at the first. The second is where most teams still rely on the reviewer’s memory and on whoever is on shift that day — and where the team gets compounding value if the system can do it automatically.

3. Static records in a dynamic world

The medical device our team is responsible for is not standing still:

• customer needs evolve as procedures and care settings change
• clinical workflows in hospitals, clinics, and home use shift
• nurses, physicians, technicians, and patients report new use issues
• competitors release new technology that changes the comparison set
• suppliers change components, materials, or manufacturing methods
• software and firmware are updated, sometimes faster than the design history file
• labeling and IFU expectations change as regulators issue new guidance
• new external signals appear in MAUDE, openFDA, and Health Canada (and equivalent surfaces in other jurisdictions)
• regulators update what they expect from the post-market surveillance file

If the quality system that represents this product is static — a folder structure, a set of templates, a periodic management review with the same agenda — then the system will lag the product. That lag is exactly where a serious field issue tends to land first.

4. A QMS should not be a filing cabinet

A static quality system is still useful. It stores complaint records, CAPA records and effectiveness checks, post-market surveillance reports, risk-file notes, supplier files, external-signal reviews from regulators and peer recalls. That kind of record-keeping holds up during audit and inspection — and that matters.

But a filing cabinet, however well organized, does not necessarily make the next review better. Honest test questions our team can ask:

• If a similar-device recall was reviewed six months ago, does it become a review point automatically when our product later receives a related complaint?
• If a service issue appears again on the same component, does the next reviewer see the last rationale — including the options that were considered and the one that was selected — without having to dig?
• If a supplier change touches a component linked to prior complaints, does the prior context appear automatically in the supplier change review?
• If a software update touches a known risk area, does the reviewer see the prior review history for that risk area, or do they start from a blank page?
• If a peer device’s warning letter cites an issue with a component family we also use, does that signal land on our product’s next review agenda automatically?

If the honest answer to several of these is “no, the reviewer would have to find that themselves,” the QMS is doing its compliance job but not its learning job. The reviewer is doing the learning manually, every time.

5. What the public data does and does not tell us

Before going further, a deliberate honesty note. We do not claim in this article that “recalls are rising” or “warning letters are accelerating.” The honest position is that, before drawing any directional conclusion, we have to be careful about what is being counted, when, and against what denominator. Here is what we checked and what each surface actually exposes.

Surfaces we examined

• openFDA Device Enforcement endpoint — open.fda.gov/apis/device/enforcement. Returns FDA Recall Enterprise System (RES) records. Coverage starts in 2004 and is updated weekly. Each record carries fields including report_date, recall_initiation_date, classification, status, product_code, and reason_for_recall.
• openFDA 510(k) endpoint — open.fda.gov/apis/device/510k. Returns premarket notification submissions, 1976 to present, monthly updates.
• FDA Warning Letters — warning letters search. Each letter is dated and links to the firm. There is no headline year-by-year “medical device only” rollup published on the search page itself; counts depend on how the search is filtered.
• FDA Form 483 observations — FDA’s 483 FAQ and the agency’s Inspection Classification Database. Observation totals reported in agency annual reports are aggregated across product centers; medical-device-only year-on-year totals require additional filtering.
• FDA Establishment Registration & Listing — CDRH establishment registration. Useful as a denominator proxy only — registered establishments are not the same as active products or SKUs.
• Health Canada Recalls and Safety Alerts — recalls-rappels.canada.ca. The portal currently exposes a daily-updated CSV/JSON feed covering food, health products, and consumer goods. The medical-device subset is one of several risk types in that feed and must be filtered out for a device-specific count.

Why we are not publishing a yearly trend chart

The numerator and denominator both move:

• FDA’s recall posting date (when RES received the record) is not the same as the firm’s recall initiation date. The two surfaces differ by months for many records.
• One recall event can produce multiple records (one per device code, one per affected lot range), so “count of records” is not the same as “count of events.”
• FDA Form 483 observation count is not the same as warning letter count; warning letters are issued only on the subset of inspections where post-inspection findings warrant escalation.
• The natural denominator — “active medical devices on the US or Canadian market” — is itself ambiguous. Registered establishments, listed devices, cleared 510(k)s, and active MDALL licences each measure different things.

Without a per-product-code, per-jurisdiction analysis with explicit numerator and denominator definitions, the responsible thing is to avoid a directional claim. So we are not publishing one. The reviewer-side question — “when the next event lands, does prior context come back automatically?” — stands independent of trend direction. Even if recall rates were perfectly flat, the rate at which our own QMS reuses prior context on the next similar event is the variable our team controls.

6. From external signals to usable review points

Most teams already collect external signals. The harder step is turning a collected signal into a reusable review point that brings prior context into the next product event review. Concretely, the pipeline we are building toward looks like this:

External signal → Review Point → Product Memory → Internal Product Event Review → Decision Record → Follow-up / writeback → next review.

The signal sources are familiar:

• a peer device recall in the same product code
• a MAUDE trend on a failure mechanism we have seen before
• a Health Canada notice on a related component family
• an FDA warning letter citing an issue we should at least screen for
• a customer complaint that smells like a known failure mechanism
• a repair or service record that recurs on the same lot or component
• a supplier or component change that touches a previously reviewed risk control
• a software or firmware update that touches a known risk area
• a labeling or IFU concern raised by a clinician or training partner

The collection step is necessary but not sufficient. The valuable work is the writeback: when a Decision Record is created on a current event, the rationale, the options considered, and the rejected options become a Review Point that lives in the product’s memory, so the next reviewer (possibly a different person on a different shift) can start from prior context instead of from zero.

7. The closed loop — capture, evaluate, decide, act, learn

Five steps a quality system should run through on every meaningful product event:

1. Capture. Internal events (complaints, service, supplier change, software change, labeling concern, manufacturing signal) and external signals (peer recalls, MAUDE trends, regulator notices) land in the same product context.
2. Evaluate. The reviewer identifies failure mechanisms and the review points that may apply, drawing on the product’s own history and on prior reviews of similar signals — and the prior reviews are already on screen, not buried in another folder.
3. Decide. RA/QA compares candidate actions, selects one, and records why the others were rejected — not as defensive paperwork but as future context for the next reviewer.
4. Act. The Decision Record is attached to or summarized in the appropriate QMS destination — PMS narrative, risk-file update, complaint investigation, CAPA screen, supplier review, labeling review, management review, or training trigger. The QMS still owns the record-of-truth.
5. Learn. The review point and the rationale are written back into product memory so the next similar event does not start from zero.

The loop only closes if step 5 happens. If it does not, every review starts from a blank page, the team relies on whoever has the longest memory, and the same prior context gets re-discovered by hand each time.

8. What changes for the reviewer’s day

The benefits we are building toward are deliberately framed at the level of the reviewer’s actual workflow, not at the level of audit-readiness:

• The next event opens with prior context already attached. The reviewer does not have to remember which prior reviews to look up — they are already on the screen, with the prior rationale and the rejected-option list visible.
• The previously-rejected options come back when a similar event recurs. The next reviewer does not re-litigate options the team already considered; they see what was rejected and why.
• Cross-event retrieval finds related prior reviews automatically. A new complaint that matches a prior failure mechanism brings the prior review into the new pane — without manual search.
• Handoffs between reviewers do not lose prior reasoning. A reviewer who has never seen the product before can read the prior rationale cold, including what was tried and what was set aside.
• The same workflow integrates with existing QMS destinations. The Decision Record still goes into the PMS narrative, the risk file, the CAPA screen, the supplier review — whichever the team’s SOP says it should. The closed loop is additional, not replacement.
• Compliance is the floor; reviewer time is the constraint. When prior context is already organised, the same hour of reviewer time produces a more defensible review, more consistent rationale, and a record the next reviewer can pick up without a meeting.

9. A note on terminology — “operational digital twin”

One label for the artifact above is operational digital twin for product quality and compliance. We use the phrase deliberately and narrowly: a digital representation of one product’s quality and compliance operating life — the events, signals, decisions, options considered, rationale, follow-ups, and review points that accumulate around one product family over time.

It is not a digital twin of a component, a sensor model, a machine simulation, a finite-element model, or a software-stack simulation. It is not a replacement for the QMS, the design history file, or the risk file. The label is a convenience; the substance is the loop above. If the term distracts more than it helps, it is just as accurate to call it living quality memory — the article still works.

10. What TrueMedDevice is building, and what it does not do

TrueMedDevice is building review-support tools that help medical device teams turn product events and external signals into Review Points, Decision Records, options considered, rejected-option rationale, QMS follow-up context, product memory, and next-review triggers. The current product surfaces:

• Public Record Explorer — search the public regulatory record for one product or company across FDA and Health Canada surfaces.
• Product Status Snapshot — a dated, source-backed snapshot of what FDA and Health Canada have publicly published about one product.
• Product Event Decision Record — for a single internal product event, capture the considered options, the selected action, the rationale for rejecting the others, and the QMS attachment destination.
• Review Point Library — the per-product set of saved review points produced by prior Decision Records and accepted external-signal reviews.
• Product Memory retrieval — when a new event opens, the workspace retrieves the relevant prior Review Points so the new review starts with prior context.

For the workspace mechanics — how a single review actually runs end-to-end — see Product Review Workspace for Medical Device RA/QA Teams. For a worked example of what one workspace output looks like for a single infusion pump review, see Anatomy of a Review-Ready PMS Evidence Pack for Infusion Pump Reviews.

The boundary is explicit and unchanged from our earlier articles. TrueMedDevice does not determine reportability, CAPA need, recall classification, regulatory applicability, standard applicability, product safety, compliance status, importability, market acceptance, or FDA clearance / approval. The qualified RA/QA team makes those determinations and owns the conclusion. The tools above prepare the evidence and preserve the rationale so the team’s judgment runs on better-organized inputs.

A QMS should not be a filing cabinet. It should bring prior context to the next event. Compliance is the floor. Building a system that brings prior review work back into the reviewer’s pane — automatically, on the next event — is the part that compounds. That is the direction TrueMedDevice is building toward.

Review support only. RA/QA owns the final decision. Not legal advice, not a regulatory determination, not a final marketability determination, not a safety guarantee, and not a compliance certificate. Final decisions on regulatory, safety, legal, and quality matters remain with the customer’s qualified RA/QA professionals.

FAQ

Are you saying our QMS is wrong?

No. The QMS is required, it is auditable, and it does its job for compliance — storing the records correctly. The argument is narrower: when the next event arrives on a reviewer’s desk, the prior context that already exists in the QMS does not always come back automatically. That is a learning-loop question, not a compliance-deficiency question, and it is the part the reviewer notices most directly in their daily work.

What is the concrete daily benefit for our RA/QA team?

The next event opens with prior context already attached. The previously-rejected options and the rationale come back without manual search. Cross-event retrieval pulls related prior reviews into the new pane. Reviewer handoffs do not lose prior reasoning. The Decision Record still flows into the existing PMS / risk file / CAPA / supplier review destinations. None of this replaces the reviewer’s judgment — it just removes the “re-organize the history by hand” step from every review.

How is this different from the compliance digital twin you described in your earlier article?

The earlier article (compliance digital twin) defines what the artifact is. This article looks at it from the reviewer’s daily work: the difference between storing a record and retrieving it on the next event. The earlier piece is the noun. This one is what the noun does for the reviewer.

Why not publish a clean “recalls per year” chart?

Because the numerator and denominator both move. FDA’s recall posting date differs from the recall initiation date. One recall event can produce many records. Form 483 observations and warning letters count different things. The denominator — “active medical devices on the market” — has at least four reasonable definitions. Without a per-product-code analysis with explicit definitions, a clean trend chart would mislead more than it would inform. The data section names the canonical surfaces and the structural caveats; we deliberately do not assert a directional trend.

Does TrueMedDevice make regulatory or safety decisions for our team?

No. TrueMedDevice does not determine reportability, CAPA need, recall classification, regulatory applicability, standard applicability, product safety, compliance status, importability, market acceptance, or FDA clearance / approval. The qualified RA/QA team makes those determinations and owns the conclusion. TrueMedDevice prepares the evidence and preserves the rationale so the team’s judgment runs on better-organized inputs.

Where do we start?

Pick one product family and one review use case — a recurring complaint, a supplier change, a software update, or a peer-device recall — and build the loop around that. The narrower the starting scope, the faster prior context starts coming back automatically and the easier it is to see whether the next review starts from useful context. From there, the same pattern extends to additional product families.