Incident Assessment Form
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
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
Under EU MDR 2017/745:
- Serious incidents must be reported immediately via EUDAMED (Article 87)
- Incidents must be evaluated using the three-criteria test (Article 2(64-65))
- Field Safety Corrective Actions may be required based on incident severity (Article 89)
- Must comply with MDCG 2023-3 guidance for incident reporting
Special attention required for:
- Events occurring during clinical investigations (Article 80-82)
- Incidents involving multiple devices or manufacturers
- Software updates that could affect device safety or performance
- Post-market clinical follow-up findings that reveal new risks
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-003
Section 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 |