View the talks from the OpenRegulatory Conference 2021!

Updated September 30, 2021

Template: Incident Assessment Form

Sven Piechottka
ISO 13485

This is a free template, provided by OpenRegulatory.

A preview of the template is shown below. You can download it as Word (.docx), PDF or markdown file.

The template license applies (don't remove the copyright at the bottom).

Download as:

Related Documents

The following templates are Documents or SOPs related to this template. That means that they mention this template somewhere and (most likely) contain instructions on how and when to fill it out.
Beginning of template

Incident Assessment Form

Regulations Document Section
Medical Device Regulation Art. 87 and 89 All
Medical Device Directive Art. 10 All
ISO 13485:2016 Section 8.2.3 All
MPDG, MPEUAnpV, MEDDEV 2.12/1 rev. 8 All


This template is used to assess whether an event with a potentially negative impact on the state of health constitutes a reportable incident.

General Information  
Description of Event: <Describe e.g. the cause that led to the event, the relationship between device and event, urgency of required actions>
Report Date and Time:  
Affected Medical Device: <Enter UDI here>
Incident Assessment: The event is a reportable incident:
( ) Yes ( ) No
Action Planned: <Describe FSCA>

Incident Assessment Framework

The following criteria are based on the MEDDEV 2.12/1 rev. 8 guidance document. Any event which meets all three criteria listed below is considered an incident and must be reported to the competent national authorities.

For correct understanding, keep in mind that the template form below can be also used to document appropriately why an event was NOT considered a reportable incident!

(1) General Event Description and Occurrence

Criterion: An event has occurred that could be considered a reportable incident.

Applicable? ( ) Yes ( ) No
Explanation: <if no, describe why this is not applicable>
Category of event  

Examples for possible event categories are as follows. For more examples, see MEDDEV 2.12/1 rev. 8 guidance.

  • technical failure mode leading to unexpected behaviour of medical device
  • incorrect product claims (marketing material, instructions for use, labelling)
  • new hazard-related use scenario occurred, i.e. usability problem

Note: The incident assessment must also consider information resulting from testing, reading the instructions for use or scientific data that indicate implications as outlined in step 3 below.

(2) Relationship Between the Device and Event

Criterion: A (direct or indirect) causal relationship is suspected between the device and the event.

Applicable? ( ) Yes ( ) No
Explanation: <if no, describe why this is not applicable>

Note: When assessing the relationship between the device and event the Medical Device Safety Officer / Person Responsible for Regulatory Compliance must take the following points into consideration:

From a risk management perspective, this decision should be made conservatively, i.e. if the situation is complex and/or potentially caused by multiple medical devices, the MDSO / PRRC should have a tendency to assess this as “applicable” even if the matter still remains unclear.

(3) Event Outcomes

Criterion: The event led, or might have led, to one of the following outcomes:

Applicable? ( ) Yes ( ) No
Explanation: <if no, describe why this is not applicable>
Outcome: ( ) death of a patient, user or other person
( ) serious deterioration in state of health of a patient, user or other person

A serious deterioration in state of health includes at least one of the following:

Please note: Incidents also include events where serious medical consequences have not occurred but could occur in the future under similar circumstances. If you are unsure, check the intended use of the device to assess whether the event should be excluded based on its (counter-)indications.

Guidance for Assessment

Guidance Document Explanation
Intended Purpose
See MEDDEV 2.12/1, section 4.6 ‘Definitions’; See MDD Article 1.2 paragraph (g)
The use for which the device is intended according to the data supplied by the manufacturer on the labelling, in the instructions for use and/or in promotional materials.
See MEDDEV 2.12/1, section 4.6 ‘Definitions’ and annex I for examples
Any malfunction or deterioration in the characteristics and/or performance of a device, as well as any inadequacy in the labeling or the instructions for use which, directly or indirectly, might lead to or might have led to the death of a patient, or user or of other persons or to a serious deterioration in their state of health.
Direct or Indirect Harm
See MEDDEV 2.12/1, section 4.6 ‘Definitions’
A physical injury or damage to the health of people, or damage to property or the environment.In the majority of cases, diagnostic devices will, due to their intended use, not directly lead to physical injury or damage to health of people. These devices are more likely to lead to indirect harm. Harm may then occur as a consequence of the medical decision, action taken/not taken on the basis of information or result(s) provided by the device or as a consequence of the treatment of cells or organs outside of the human body that will later be transferred to a patient.
Examples of indirect harm include misdiagnosis, delayed diagnosis, delayed treatment, inappropriate treatment, absence of treatment transfusion of inappropriate materials. Indirect harm may be caused by imprecise results, inadequate quality controls, inadequate calibration, false positive or false negative results.
Field Safety Corrective Actions
See MEDDEV 2.12/1, section 4.6 ‘Definitions’
FSCA is an action taken by a manufacturer to reduce a risk of death or serious deterioration in the state of health associated with the use of a medical device that is already placed on the market. Such actions, whether associated with direct or indirect harm, should be reported and should be notified via a field safety notice.

FSCA may include: the return of a device to the supplier; device modification; device exchange; device destruction; advice given by manufacturer regarding the use of the device and/or the follow-up of patients, users or others (e.g. where the device is no longer on the market or has been withdrawn but could still possibly be in use).

Manufacturers can as part of ongoing quality assurance identify a failure of a device to perform according to the characteristics specified in the information for use provided by the manufacturer. If the failure might lead to or might have led to death or serious deterioration in the state of health associated with the use of a medical device and has an impact on a product that has already been placed on the market the manufacturer must initiate a FSCA.

Examples of failure modes may include software anomalies (e.g. incorrect correlation between patient sample and the obtained result, invalid controls or invalid calibrations).

A device modification can include:
- Permanent or temporary changes to the labelling or instructions for use (for example: advice for revised quality control procedures such as use of third party controls\, more frequent calibration or modification of control values).
- Software upgrades following the identification of a fault in the software version already in the market. This should be reported regardless of whether the software update is being implemented by customers\, field service engineers or by remote access.

Advice given by the manufacturer may include modifications to the clinical management of patients or samples to address a risk of death or a serious deterioration in state of health related to the characteristics of the device. For diagnostic devices, corrective action taking the form of the recall of patients or patient samples for retesting or the review of previous results constitutes FSCA.

Template Copyright See template license.

Please don’t remove this notice even if you’ve modified contents of this template.

End of template


Regulatory compliance is not rocket science.

But finding a good consultant is.

No Cookie For You Privacy Policy Imprint
No QMS on this planet will save you from creating crappy software.