CAPAs and Vigilance
Incident Assessment Form
Evaluate device incidents systematically determining regulatory reporting requirements and actions.
Summary
The Incident Assessment Form systematically evaluates whether an event with potentially negative health impacts constitutes a serious and reportable incident under medical device vigilance regulations. You use this form to determine if an incident meets the three basic reporting criteria and requires formal notification to competent authorities.Why is the Incident Assessment Form important?
Medical device incidents can cause patient harm, device recalls, and regulatory action that threatens your market access. The Incident Assessment Form provides a structured decision-making framework that ensures you properly classify events and comply with vigilance reporting requirements. This systematic approach protects patients, maintains regulatory compliance, and demonstrates your commitment to post-market safety monitoring. Without proper incident assessment, you risk under-reporting serious events or over-reporting minor issues, both of which can lead to regulatory scrutiny and lost stakeholder confidence.Regulatory Context
Under 21 CFR Part 803 (Medical Device Reporting):
- Manufacturers must report device malfunctions that could cause or contribute to death or serious injury if the malfunction were to recur
- Death or serious injury reports must be submitted within 24 hours to FDA and the user facility
- Malfunction-only reports must be submitted within 30 days to FDA
- Reports must include remedial action taken or planned by the manufacturer
Special attention required for:
- Software malfunctions that affect device safety or effectiveness
- Use-errors due to inadequate labeling or training materials
- Device-device interactions in connected systems
- Cybersecurity incidents affecting device functionality
Guide
Understanding Incident Classification
An incident includes any malfunction, deterioration in device characteristics, use-error due to ergonomic features, inadequate manufacturer information, or undesirable side-effects. Not every incident requires reporting - you must determine if it qualifies as a serious incident.The Three-Criteria Test
You must evaluate every incident against these three mandatory criteria: Criterion A: Does the event meet the definition of an incident according to regulatory requirements? This includes device malfunctions, performance deterioration, use-errors, or inadequate information that affects device safety or effectiveness. Criterion B: Did the incident directly or indirectly lead to, might have led to, or might lead to death, serious deterioration in health, or serious public health threat? Consider both actual outcomes and potential consequences if the incident recurred. Criterion C: Has a causal relationship between the incident and your device been established, is reasonably possible, or is suspected? You don’t need definitive proof - reasonable possibility or suspicion is sufficient.Completing the Assessment
Document the event details systematically, including when and where it occurred, which product version was involved, and what actions you plan to take. If the incident involves multiple users or locations, document each occurrence separately. Identify planned actions such as Field Safety Corrective Actions (FSCA), software updates, or label changes. Specify which competent authorities require notification based on where the incident occurred and where your device is marketed. Make the reporting decision based on your three-criteria evaluation. If all three criteria are met, you must report the incident. If any criterion is not met, document your reasoning and retain the assessment for your records.Integration with Quality Management
Your incident assessment must connect to your CAPA system for systematic issues requiring corrective action. Link assessments to your post-market surveillance activities to identify trends and patterns. Update your risk management file when incidents reveal previously unidentified hazards.Example
Scenario: Your mobile ECG monitoring app crashes during a critical heart rhythm analysis for a patient with known cardiac risk factors. The crash prevents the completion of the analysis, and the patient seeks emergency medical care later that evening due to chest pains. You receive this report through your customer feedback system and must determine if it constitutes a reportable incident.Example Incident Assessment Form
Document ID: IAF-2024-003Section 1: Incident Qualification
| Criteria | Response |
|---|---|
| Does the event meet the definition of an incident according to Art. 2(64) MDR? | Yes - Software malfunction preventing completion of intended analysis |
| Does the incident directly or indirectly lead to serious outcomes? | Deterioration of state of health - Patient required emergency medical care |
| Has causal relationship been established or is suspected? | Yes - App failure prevented timely cardiac assessment |
| Explanation | The software crash constituted a malfunction that prevented the device from completing its intended ECG analysis. While the patient’s emergency care was not directly caused by the device failure, the inability to complete the cardiac assessment may have contributed to delayed recognition of the patient’s condition. |
| Is this considered a reportable incident? | Yes - All three criteria are met |
Section 2: Incident Assessment Report
| Category | Information |
|---|---|
| Event Description | Mobile ECG app (v2.3.1) crashed during heart rhythm analysis at 14:32 on March 15, 2024. Error code: “Memory allocation failure during signal processing.” Patient was analyzing 30-second ECG recording when app terminated unexpectedly. |
| Source of Event | Customer complaint via support email, confirmed by device logs uploaded automatically |
| Location of Event | Patient’s home in Munich, Germany |
| Date and Time Event Reported | March 16, 2024 at 09:15 CET via customer support |
| Product and Version Affected | CardioWatch Mobile App v2.3.1, Build 2024.03.01 |
| Planned Actions | Immediate: Release hotfix v2.3.2 addressing memory allocation issue. FSCA: Issue Field Safety Notice to all users recommending app update. Preventive: Implement additional memory management testing in QA processes. |
| Relevant Competent Authorities | BfArM (Germany) - primary incident location; ANSM (France), AIFA (Italy) - other EU markets where device is sold |
Q&A
What should be done if a new risk is identified during the vigilance database review?
What should be done if a new risk is identified during the vigilance database review?
If you identify a new risk during vigilance database review, add it to your risk assessment to ensure all foreseeable risks are properly documented. Update your risk management file and consider whether additional risk controls are needed for your device.
How should complaints be managed in relation to incident assessment?
How should complaints be managed in relation to incident assessment?
Examine all complaints for product performance and safety issues. Significant complaints should be recorded in your complaint log, and serious ones should be evaluated using the incident assessment form. Minor complaints that can be resolved with instructions typically don’t require formal incident assessment.
What is the difference between reportable and non-reportable incidents?
What is the difference between reportable and non-reportable incidents?
Reportable incidents must meet all three basic criteria: qualify as an incident, lead to or potentially lead to serious outcomes, and have an established or suspected causal relationship with your device. Non-reportable events fail to meet one or more of these criteria but should still be documented for your records and post-market surveillance activities.
How quickly must incident assessments be completed?
How quickly must incident assessments be completed?
Begin incident assessment immediately upon receiving a report. For potentially serious incidents, complete your initial assessment within 24 hours to determine if immediate reporting is required. You can supplement your assessment with additional information as your investigation continues.
Should software malfunctions always be considered incidents?
Should software malfunctions always be considered incidents?
Software malfunctions constitute incidents when they affect device safety, effectiveness, or performance. Minor software bugs that don’t impact the device’s intended use or patient safety may not qualify as incidents. Consider the potential consequences and whether the malfunction could affect clinical decision-making or patient care.