CAPA and post-market surveillance for medical devices

CAPA—corrective and preventive action—is where most quality management systems fail. Not because the process is poorly understood, but because CAPA is structurally disconnected from engineering. Complaints, nonconformances, and adverse events are captured in the quality system. Root cause investigations are conducted in the quality system. Corrective actions are documented in the quality system. And the design history file—the engineering record that contains the decisions that led to the problem—lives somewhere else entirely, in a different system, maintained by a different team, in a format that a quality engineer conducting a root cause investigation cannot easily navigate.

MANKAIND eliminates that structural disconnection. The quality events—complaints, MDRs, nonconformances, CAPAs—and the engineering record—design history file, risk analysis, verification and validation records—exist in the same platform, connected by the same traceability infrastructure that was built during development. When a field problem surfaces, the engineering team can trace it directly to the design decision that produced the failure mode, and the corrective action can be implemented as a documented change to the engineering record—not a quality system entry that references a separate design file.

Root cause analysis is an engineering discipline

FDA investigators and notified body auditors consistently find that CAPA effectiveness is the most common quality system deficiency. The failure mode is almost always the same: the root cause investigation did not go deep enough. The documented root cause identifies a proximate cause—an operator error, a supplier nonconformance, a component out of specification—but does not trace that proximate cause back to the systemic engineering condition that allowed it to occur.

A device that generates field complaints about connection failures was probably designed with an insufficient pull force specification, or a verification test that did not represent the range of user techniques, or a material selection that degraded under real-world storage conditions that the test protocol did not cover. The complaint is the signal. The engineering record is where the cause lives. Root cause analysis that does not engage the engineering record produces corrective actions that address symptoms.

MANKAIND supports root cause analysis by surfacing the relevant engineering history at the moment a quality event is initiated. When a complaint is opened for a specific device configuration, the platform connects that complaint to the design outputs, verification records, and risk analysis entries that cover the affected function. The investigator can see, without switching systems, whether the failure mode was identified in the FMEA, what the original risk control measures were, and whether previous complaints for similar failure modes were identified during the design review. That context is what separates a superficial investigation from one that identifies an actionable engineering root cause.

Design changes from CAPAs: the engineering change management problem

When a CAPA requires a design change, the change must be evaluated under 21 CFR 820.30(i)—design changes must be identified, documented, reviewed, and approved before implementation, and must be evaluated to determine if they constitute a significant change requiring a new submission. That evaluation is an engineering judgment: does the change affect the intended use, the safety, or the effectiveness of the device?

Most quality systems handle design change documentation in isolation from the original design record. The change is documented in the CAPA, the change assessment is attached to the CAPA, and the updated design documentation is modified in the DHF—but the connection between the CAPA finding, the engineering rationale for the change, and the updated design record is maintained through document cross-references rather than live traceability.

MANKAIND implements design changes from CAPAs as engineering decisions within the same traceability framework as the original design. The CAPA finding is connected to the affected design inputs or risk control measures. The proposed change is evaluated against the traceability matrix to identify all downstream outputs—design outputs, verification requirements, labeling, manufacturing processes—that are affected. The change assessment is generated from the traceability impact analysis, not drafted independently. When the change is approved and implemented, the DHF is updated in place, with a complete audit trail connecting the field failure to the engineering change that addressed it.

Post-market surveillance: turning field data into engineering intelligence

Post-market surveillance is a regulatory obligation under 21 CFR 822, EU MDR Article 83, and ISO 13485 Section 8.2. It is also one of the most valuable sources of engineering intelligence available to a device manufacturer—and one of the most systematically underused. Field complaint data, MDR/vigilance reports, literature surveillance, and registry data collectively describe how the device performs in the hands of real users, in real clinical environments, under conditions that were approximated but never fully replicated during development.

The problem is that post-market data arrives in forms that are difficult to connect to engineering decisions. A complaint describes a symptom. A literature paper describes an adverse event rate in a patient population. A registry report describes a survival curve. Converting that data into engineering insight requires knowing which design decisions are candidates for the observed failure—and that knowledge lives in the design history file.

MANKAIND maintains a live connection between the post-market surveillance data stream and the engineering record. When complaint trends indicate elevated rates of a specific failure mode, the platform surfaces the FMEA entries, design rationale documents, and verification records associated with that failure mode. The post-market surveillance report—required annually for EU MDR Class III devices and periodically for FDA Class II and III devices—is generated from the structured analysis of complaint, MDR, and literature data against the device's engineering baseline, not assembled manually from multiple data sources.

Trend analysis and the preventive action obligation

The preventive action component of CAPA is the most consistently underdeveloped aspect of medical device quality systems. Preventive action requires identifying potential problems—failure modes that have not yet produced complaints or nonconformances—and taking action before they do. That is a signal detection problem, and it requires a baseline: what is the expected failure rate for this device, under these conditions, given the design's known risk profile?

MANKAIND generates that baseline from the risk analysis. The FMEA's residual risk estimates—probability of occurrence after risk controls, severity of harm—define the expected performance envelope. When post-market complaint rates exceed the expected occurrence rates for specific failure modes, the platform flags the deviation as a potential trend requiring investigation. The preventive action is triggered by engineering analysis, not by waiting for a complaint rate to become visibly alarming.

MDR and vigilance reporting: the engineering evidence chain

An MDR or vigilance report is a regulatory filing. The investigation that precedes it is an engineering analysis. The report must describe the device, the event, the patient impact, and the manufacturer's investigation findings—including the root cause and corrective action. That information flows directly from the engineering record if the engineering record is structured to support it.

MANKAIND generates MDR and vigilance report narratives from the complaint investigation record, the design history file, and the corrective action documentation—maintaining the evidentiary chain from field event to engineering cause to regulatory report. When a follow-up report is required, the platform tracks the corrective action status and generates the update from the implementation record. The regulatory filing accurately reflects the engineering investigation because it is derived from it.

Post-market quality is not a separate discipline from engineering. It is engineering—applied to the evidence that the field generates about how well the original design decisions held up. MANKAIND treats it that way: as a continuous feedback loop between field performance and engineering intelligence, closing the loop that most quality systems leave open.