Root Cause Analysis (RCA)

Root Cause Analysis (RCA) is a structured investigation method used to identify the underlying cause of a nonconformity, failure, or complaint rather than its visible symptom. In medical device manufacturing, RCA supplies the evidence that justifies a corrective action under a quality management system and prevents the same defect from recurring.


What is Root Cause Analysis (RCA)?

Root Cause Analysis (RCA) is the investigative stage of a corrective and preventive action (CAPA) process. It answers a single question: what condition, if removed or controlled, would stop this problem from happening again? The output is a documented causal chain that links observed evidence to a specific, addressable failure in a process, design, material, or control.

RCA sits at the point where a quality event enters the system: a production nonconformance, a failed in-process inspection, an internal audit finding, a supplier deviation, a field complaint, or an adverse event report. The investigation runs before any corrective action is chosen, because a fix selected without a verified cause is guesswork.


Why Root Cause Analysis (RCA) matters in medical device development

A medical device defect does not stay inside the factory. A misapplied solder profile on a patient monitor PCBA, a contaminated fill on a sterile package, or an undetected software regression in a Class II device can all reach a clinician or a patient.

Regulators treat weak investigations as a systemic quality failure, not an isolated slip. Under the FDA Quality Management System Regulation (QMSR), effective February 2, 2026, 21 CFR Part 820 incorporates ISO 13485:2016 by reference, and corrective action requirements now sit in ISO 13485 clause 8.5.2. Investigators expect to see cause determination documented, effectiveness verified, and the action scaled to the risk of the problem. FDA Form 483 observations and warning letters routinely cite investigations that stopped at the symptom or closed without an identified cause.

The commercial cost is real, too. A repeated nonconformance triggers rework, scrap, and lot holds. If the defect escapes, it can force a field safety corrective action under EU MDR 2017/745 or a medical device report under 21 CFR Part 803.


The Root Cause Analysis (RCA) process

RCA is a defined sequence, not a brainstorming session. Most device manufacturers run it in six stages.

  • Define the problem. State what failed, where, when, on which lot or serial numbers, and against which specification. Vague problem statements produce vague causes.
  • Contain the issue. Quarantine affected product, assess devices already distributed, and document the containment decision. Containment is not corrective action.
  • Collect evidence. Pull device history records, batch records, equipment logs, environmental monitoring data, training records, and returned units. Physical failure analysis often decides the case.
  • Analyze causes. Apply a formal tool: 5 Whys for simple linear failures, an Ishikawa (fishbone) diagram to sort candidate causes across method, machine, material, personnel, measurement, and environment, or fault tree analysis for complex safety-related failures.
  • Verify the cause. Reproduce the failure, or demonstrate that removing the suspected condition eliminates it. An unverified cause is a hypothesis.
  • Feed CAPA and risk management. Route the verified cause into corrective action, update the risk file under ISO 14971:2019 if new hazards or higher probabilities emerge, and revisit the process FMEA.

Two connections are easy to miss. RCA outputs often require change control, and a process change may trigger revalidation of an IQ/OQ/PQ package. If the cause touches design rather than production, the finding flows back into design controls and the design history file.


Common challenges and best practices

The most frequent failure is stopping at human error. “Operator did not follow the procedure” is a symptom. The real cause is usually an ambiguous work instruction, a fixture that allows misassembly, inadequate training verification, or a process with no error-proofing.

The second failure is scope. Teams investigate one complaint and never ask whether the same cause sits in adjacent product families, sister lines, or a shared supplier. Trend data from complaint handling and post-market surveillance should feed that question.

Good practice looks like this. Assign a cross-functional team, not a single quality engineer. Time-box the investigation and escalate when it stalls. Write the causal statement so a stranger can follow the logic from evidence to conclusion. Distinguish between containment, correction, corrective action, and preventive action, because auditors will. Then close the loop with effectiveness checks against predefined acceptance criteria.


How SJML helps with Root Cause Analysis (RCA)

Syrma Johari MedTech (SJML) runs RCA and CAPA as part of its complaints handling and vigilance services, alongside adverse-event reporting and post-market surveillance. Investigations draw on the same in-house capability that builds the product: PCBA and molding process knowledge, IQ/OQ/PQ process validation, PFMEA, SAP-integrated MES traceability, and in-house electrical safety, EMC, and reliability labs for failure analysis. QARA teams tie verified causes back to ISO 14971 risk files, design history files, and change control so remediation holds up under ISO 13485 and MDSAP audits.

Talk to SJML’s QARA team →


Frequently asked questions

What is the difference between root cause analysis and CAPA?

Root Cause Analysis (RCA) is one step inside CAPA. RCA determines why a nonconformity occurred. CAPA is the wider process that includes intake, containment, investigation, action selection, implementation, effectiveness verification, and closure. A CAPA without a verified root cause tends to produce actions that treat symptoms, a common audit observation in device quality systems.

Which RCA tools are accepted for medical devices?

No regulation mandates a specific tool. ISO 13485 clause 8.5.2 requires that causes of nonconformities be determined, and leaves the method to the manufacturer. Teams commonly use 5 Whys, Ishikawa (fishbone) diagrams, fault tree analysis, and is/is-not comparative analysis. Choose the tool by problem complexity and risk, and document why it was appropriate for that investigation.

When is root cause analysis required?

Investigation is expected whenever a nonconformity, complaint, audit finding, or adverse event indicates a possible quality system or product failure. Under the FDA QMSR, complaint records must show review, evaluation, and investigation where a device may have failed to meet specifications. Risk determines depth: a minor cosmetic defect and a potential patient-harm event do not warrant the same investigative effort.

How do you verify a root cause is correct?

Verification means demonstrating causality, not asserting it. Reproduce the failure by reintroducing the suspected condition under controlled conditions, or show that eliminating it stops the failure across a statistically meaningful sample. Supporting evidence includes failure analysis data, process capability studies, and retrospective lot review. If the cause cannot be verified, document that limitation and treat the action as risk-based mitigation.


Related terms

  • CAPA (Corrective and Preventive Action)
  • Nonconformance
  • Change Control
  • Process Validation (IQ/OQ/PQ)
  • Post-Market Surveillance (PMS)

Table of Contents

Free EU MDR Technical Documentation Compliance Checklist

Understand documentation gaps and use our single-window worksheet to prepare for Notified Body review.

Related Glossaries

Ask Sygma AI

AI-Powered Assistant

SJ Assistant