The RA/QA Gap Is Not Evidence Collection. It Is Decision Reuse.

Most medical device RA/QA teams do not have an evidence-collection problem. The public surfaces have been searchable for years. Peer-device recalls, MAUDE / openFDA adverse-event reports, FDA warning letters, Health Canada recalls and safety alerts, field actions, complaint trends, and supplier signals are all available to anyone willing to open the right database. The real problem is the step after collection: turning that evidence into a structured, reusable RA/QA decision that the next reviewer — or the next inspector — can read cold.

Why similar-device signals need to become structured review points, not just archived narratives or attachments.

A recent LinkedIn discussion on this same question surfaced a consistent qualitative pattern: RA/QA practitioners describe the bottleneck not as a lack of source material, but as the absence of a structured way to convert that material into a documented review decision that can be reused on the next similar event. We are not putting a percentage on that pattern — the conversation was indicative, not statistical — but it lines up with what reviewers describe in their own daily work.

This article lays out the four-layer model TrueMedDevice uses to close that gap, an infusion pump example showing how event-type ambiguity actually plays out at the reviewer’s desk, and the boundary line we hold ourselves to.

The gap is not evidence collection. The gap is turning evidence into reusable RA/QA decisions.

Three observations RA/QA reviewers make when we talk to them:

• The public databases are not the bottleneck. FDA and Health Canada surfaces are accessible.
• What is hard is mapping a recall on a peer device, or a MAUDE pattern on a similar component, to this product’s risk file, this supplier, this SOP, and this reviewer’s decision.
• What is harder still is making sure the rationale used today comes back automatically the next time a similar event appears — not stored as a PDF attachment that nobody re-reads, but as a structured review point on the product file.

That is the work the four layers below are designed to organize.

Layer 1 — External Signal Mapping

The first layer maps external public signals to the specific device or product the RA/QA team owns. Sources include peer-device recalls, FDA MAUDE / openFDA adverse-event reports, FDA warning letters, Health Canada recalls and safety alerts, field actions, complaint trends visible in public surfaces, and import-alert or 483-observation patterns.

The hard part is not the search. The hard part is product-relevance triage. A general recall on an infusion pump line tells you nothing useful until someone has answered:

• Is the failure mechanism described in that recall present in our design surface?
• Does the named component, alarm subsystem, supplier, software module, or use-step exist in our product?
• If yes, what is the prior review history on the same failure mechanism in our file?

The point of Layer 1 is to reduce signal overload — not to flag every external event, but to map only the ones with a credible mechanism-level connection to the reviewer’s product, and to carry forward what failure mode each one represents.

Layer 2 — Event Definition / Triage

The second layer fires when something happens internally: a new complaint, a supplier issue, a service or maintenance finding, a labeling concern, a failed test, a risk-file question, a training escalation, or a screening trigger for the quality system. Before the team can choose what to do, they have to classify what kind of event it actually is.

The same surface symptom can sit under very different categories:

• Use error — the user did something outside the labeled use.
• IFU comprehension — the labeling exists but was not understandable in context.
• Training issue — the user was not adequately trained on the SOP / IFU step.
• Usability / design issue — the design itself made the error easier to make.
• Service / maintenance issue — the device drifted out of spec because a service step was missed.
• Supplier issue — an incoming component changed and propagated downstream.
• Product safety / design / control issue — the failure mechanism is in the design or control strategy.

The reviewer’s choice here drives everything downstream. Layer 2 is designed to make that choice explicit — with the candidate categories surfaced side by side and the rationale for selecting one (or holding several open) captured at the time of review.

Layer 3 — Action Decision Support

The third layer connects the external signals (Layer 1), the current internal event (Layer 2), the relevant failure mechanisms, the applicable FDA / Health Canada / regulatory / standard references, the existing QMS / risk controls on this product, and the prior internal history on the same mechanism. It then surfaces the action paths a reviewer would normally consider:

• Watchlist — mechanism not yet present in our product surface; monitor.
• Risk-file review — reassess whether the existing risk control still covers the mechanism.
• Supplier follow-up — request validation summaries, change notices, or traceability records.
• Labeling / usability review — check whether the IFU or user-interaction step still reads correctly in light of the signal.
• Service procedure review — confirm whether the service / maintenance path needs updating.
• Complaint trend monitoring — widen the complaint surface around the same mechanism.
• Screening for the corrective-and-preventive workflow — assess whether the threshold for opening a formal corrective-action assessment is met.
• Formal corrective-action assessment — open the assessment with the prior context already attached.

What Layer 3 does not do is make the choice. The candidate paths are surfaced; the rationale prompts are surfaced; the prior reviews on the same mechanism are surfaced. The RA/QA team selects the path and documents why — including which paths were considered and rejected, and on what basis.

Layer 4 — Inspection-Ready Record

The fourth layer is the reason the first three layers are worth doing. A review that lives only in someone’s memory or in an unfiled attachment cannot be reused. Layer 4 produces a structured review record — a review pack — that can be attached to the QMS, the corrective-action workflow, the post-market surveillance narrative, the risk file, the complaint record, or an inspection-readiness folder.

The traceability the record carries:

• What was seen. The external signal, the internal event, the source links, and the date the review was performed.
• Why it mattered. The mechanism connection between the external signal and this product.
• How it was assessed. The event-type classification (Layer 2), the candidate action paths considered (Layer 3), and the prior history on the same mechanism.
• What action was chosen. The path the RA/QA team selected, with the paths that were considered and not selected.
• Why the decision was reasonable at the time. The rationale, the assumptions, the data available, and the open questions documented for the next reviewer.

That record is the artifact that survives the morning of the review. It is what makes the next similar event a 30-minute review instead of a 3-day re-assembly.

An infusion pump example: one complaint, six possible event types

A nurse reports that an infusion pump alarm did not fire when the line occluded during a routine infusion. The complaint lands on an RA/QA reviewer’s desk on Monday morning. Before the reviewer can open the right workflow, the question is: what kind of event is this?

• Use error. Was the occlusion-detection sensitivity set outside the recommended range for the line type? — question for the use-error path.
• IFU comprehension. Does the IFU clearly describe the relationship between line type, occlusion sensitivity, and alarm threshold? — question for the labeling path.
• Labeling / usability. Is the on-screen confirmation step for sensitivity changes designed in a way that makes the wrong setting easy to choose? — question for the usability path.
• Training issue. Was the user trained on the SOP for line-type-specific occlusion settings? — question for the training path.
• Service / maintenance issue. Was the occlusion sensor calibrated within the service interval? — question for the service path.
• Product safety / design / control issue. Is the occlusion-detection algorithm operating within its validated envelope? — question for the design path.

All six are legitimate framings on Day 1. The reviewer almost certainly cannot rule out five of them on the first read — and that is exactly the point. The four-layer model holds the candidate framings open, attaches the evidence each one would need, surfaces the prior review history on the same mechanism (Layer 1 + 3), and lets the reviewer document the path selected, the paths held open pending evidence, and the paths ruled out. The decision — ultimately taken by the qualified RA/QA team — is then traceable: what was seen, why it mattered, how it was assessed, what action was chosen, and why the decision was reasonable on the evidence available that morning.

Three months later, when a similar complaint lands — or when a peer-device recall on the same alarm subsystem appears on the public surface — the prior review is no longer a PDF in a folder. It is a structured review point on the product file, retrievable as context for the next decision.

From external signal to future reuse

The pipeline the four layers form, read end to end:

External Signals → Product Mapping → Event Triage → Action Decision Support → Inspection-Ready Record → Future Reuse

The pipeline is intentionally simple because the work it represents is not. Each arrow hides a judgment call that has to live with the RA/QA team and be documented as such.

What TrueMedDevice does — and does not — do

TrueMedDevice does not replace RA/QA judgment. The platform organizes decision-support information — external signals, mechanism connections, candidate event categories, candidate action paths, prior review history, applicable regulatory and standard references — and preserves the rationale for the path the qualified RA/QA team selects. It does not determine reportability, corrective-action need, recall classification, regulatory applicability, standard applicability, product safety, compliance status, importability, market acceptance, or FDA clearance / approval. Those determinations remain with the qualified RA/QA, regulatory, legal, supplier-quality, and procurement professionals who own them.

The boundary is intentional: review support that strengthens the decision, not a decision the platform makes on the team’s behalf.

Where to start

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

Is the four-layer model a replacement for the QMS?

No. The four layers sit in front of the QMS, organizing decision-support information so the QMS workflow that does open opens with the prior context already attached. The QMS continues to hold the formal records — complaints, corrective-action assessments, change controls, training, audits. Final decisions remain with the qualified RA/QA team.

How is this different from a vigilance feed or a recall alert service?

A vigilance feed delivers signals. The four-layer model adds three things on top: product-specific mechanism mapping (Layer 1), event-type triage on the internal event (Layer 2), and a structured rationale record that survives into the next similar review (Layer 4). The point is not to receive more signals; it is to convert a signal into a documented decision and preserve it for reuse.

Does TrueMedDevice make regulatory or safety decisions?

No. TrueMedDevice organizes decision-support information and preserves the rationale for the path the qualified RA/QA team selects. The platform does not determine reportability, corrective-action need, recall classification, regulatory applicability, standard applicability, product safety, compliance status, importability, market acceptance, or FDA clearance / approval.

What jurisdictions does the external-signal layer cover today?

Currently FDA (United States) and Health Canada. The platform pulls from FDA surfaces (recalls, enforcement, MAUDE / openFDA adverse-event endpoint, warning letters, safety communications, 483 / inspection references) and Health Canada surfaces (recalls and safety alerts, medical device vigilance / incident reports). Other jurisdictions are future roadmap, not currently implemented.

How do we start narrow?

Pick one product family and one review use case — a recurring complaint, a supplier change, a software update, or a peer-device recall on a related component. Run the four layers once, end to end, against that single scenario. The four-layer record produced is the artifact that lets the next similar event start from prior context instead of from a blank page.