---
title: IMDRF Adverse Event Terminology: Coding Feeds MDR Vigilance
description: IMDRF Adverse Event Terminology is how Eudamed codes vigilance data. Here is how to build the lookup into your complaint intake before you need it.
authors: Tibor Zechmeister, Felix Lenhard
category: Post-Market Surveillance & Vigilance
primary_keyword: IMDRF adverse event terminology coding MDR
canonical_url: https://zechmeister-solutions.com/en/blog/imdrf-adverse-event-terminology-coding
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# IMDRF Adverse Event Terminology: Coding Feeds MDR Vigilance

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **The IMDRF Adverse Event Terminology (AET) is the international coding system that Eudamed uses to classify vigilance data. Under MDR Articles 87–92, when you report a serious incident, the receiving competent authority expects the event to be codable to IMDRF AET categories. Founders who treat complaint intake as free text — "patient complained, device didn't work" — discover at first audit that they cannot efficiently produce trend reports, PSURs, or regulator-ready vigilance submissions. Build the coding in from day one.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- IMDRF Adverse Event Terminology is a structured, hierarchical coding system for classifying medical device adverse events.
- Eudamed uses IMDRF AET as its nomenclature for vigilance reports under MDR Article 33 and the Commission Implementing Regulation (EU) 2021/2078.
- MDR Articles 87–92 require serious incident reporting, trend reporting, and field safety corrective action reporting — all of which are structured by the IMDRF AET categories.
- MDCG 2023-3 Rev.2 (January 2025) provides the current interpretation of vigilance terms and concepts aligned with IMDRF.
- Startups that code complaint intake against IMDRF AET from day one can produce trend reports, PSURs, and regulator submissions in hours rather than weeks.
- The coding effort at the source is minimal. The cost of retrofitting it onto years of free-text complaint data is enormous.

## Why this matters

In our first vigilance audit of an early-stage SaMD company, the auditor asked a simple question: "Show me all complaints involving incorrect algorithm output over the last twelve months." The QA lead opened a spreadsheet. The complaint description column was free text. Entries like "user said result seemed wrong," "false positive," "algorithm error," "clinician disagreed with classification." No categorisation. No coding. Just prose.

The auditor waited while the QA lead filtered, sorted, and manually re-read 80 complaints to build the list. It took 40 minutes. The auditor's next question was: "How would you do that if you had 8,000 complaints?" The QA lead had no good answer.

That is the gap IMDRF Adverse Event Terminology closes. It is a structured vocabulary with defined categories for device problems, clinical signs and symptoms, health effects, investigation findings, and more. When every complaint is coded against that vocabulary at intake, trend reports become a database query instead of a manual exercise. Vigilance reports to competent authorities land in the format Eudamed expects. And crucially, the company can actually see patterns in its own data — which is the point of post-market surveillance in the first place.

## What MDR actually says

The vigilance framework sits in MDR Articles 87 through 92, and the post-market surveillance framework sits in Articles 83 through 86. The specific mentions that matter for coding:

- **Article 87** requires manufacturers to report any serious incident to the relevant competent authorities within specified timelines.
- **Article 88** requires trend reporting — a statistically significant increase in the frequency or severity of non-serious incidents or expected undesirable side-effects that could have a significant impact on the benefit-risk analysis.
- **Article 89** sets out the analysis of serious incidents and field safety corrective actions.
- **Article 92** requires the use of Eudamed for vigilance reporting (once Eudamed is fully operational).
- **Article 33** establishes Eudamed as the European database on medical devices, with Commission Implementing Regulation (EU) 2021/2078 (26 November 2021) setting the functional specifications.

The crucial link: Eudamed's vigilance module uses structured nomenclature. MDCG 2023-3 Rev.2 (vigilance terms and concepts Q&A, January 2025) confirms alignment with international harmonisation efforts, and IMDRF AET is the underlying terminology Eudamed uses to categorise device problems, patient problems, and investigation results.

IMDRF AET is not a legally binding standard in the way that EN ISO 13485 is. It is informational. But it is how Eudamed structures vigilance data, which means it is effectively how you must structure your own vigilance data if you want your submissions to land cleanly and if you want to be able to answer regulator questions without manually re-reading years of free text.

### The IMDRF AET hierarchy

IMDRF AET is organised into a set of annexes, each covering a specific category of event attributes:

- **Annex A — Medical Device Problem Terms.** The nature of the device failure or malfunction. Categories like "Activation, positioning or separation problem," "Connection problem," "Contamination / decontamination problem," "Material integrity problem," "Output problem," "Power problem," "Protective measures problem," "Software problem," "Human-device interface problem," etc. Each top-level category has sub-levels with more specific terms.
- **Annex B — Type of Investigation.** How the incident was investigated (visual inspection, functional testing, software log review, etc.).
- **Annex C — Investigation Findings.** What the investigation concluded about the root cause.
- **Annex D — Investigation Conclusions.** The final outcome category.
- **Annex E — Health Effects — Clinical Signs and Symptoms or Conditions.** What the patient experienced clinically.
- **Annex F — Health Effects — Health Impact.** The severity and nature of patient harm.
- **Annex G — Medical Device Component Terms.** Which component of the device was involved.
- **Annex H — Medical Device Problem Causes.** The underlying cause category.

Each annex is a hierarchical tree with codes. A well-coded complaint maps to one or more codes from Annex A (what went wrong with the device), one or more from Annex E and F (what happened to the patient, if anything), and after investigation, codes from Annex B, C, and D (how you investigated and what you concluded).

## A worked example

A SaMD device for retinal image analysis receives a complaint: a clinician reports that the algorithm classified a clearly abnormal image as normal, and the error was caught only because the clinician reviewed the image anyway.

Free-text intake: "False negative. Clinician says algorithm missed obvious pathology. Patient OK because clinician overrode."

IMDRF AET-coded intake:
- **Annex A (Device Problem):** Output problem → Incorrect output → False negative result.
- **Annex G (Component):** Software component → Image analysis algorithm.
- **Annex E (Clinical sign):** No clinical sign (patient asymptomatic at time of event).
- **Annex F (Health impact):** No health consequence (error intercepted).
- **Severity under MDR Article 87:** Non-serious (no patient harm, no potential for patient harm realised) — but flag for trend analysis per Article 88.

Now imagine 300 complaints over 18 months, all coded this way. The trend report becomes: "23 complaints coded as Annex A false negative result for retinal image classification, distributed across 14 clinical sites, no associated patient harm per Annex F, but trending upward from 0.8/month in months 1-6 to 2.2/month in months 13-18." That is a trend report you can defend in front of an auditor. It is also a signal you can act on in your CAPA system.

Now imagine the same 300 complaints as free text. You cannot produce that report without manually re-reading every single complaint.

## The Subtract to Ship playbook

The work here is not heavy. It is just specific. Here is the lean build-out:

1. **Download the current IMDRF AET annexes.** IMDRF publishes the AET document set on imdrf.org. Pull the current version. Note that the terminology is updated periodically — check for the current release before you finalise your complaint intake form.
2. **Select the subset of codes relevant to your device.** You do not need every code in every annex. For a SaMD, Annex A subcategories under "Output problem" and "Software problem" matter; for an orthopaedic implant, Annex A "Material integrity problem" and Annex G mechanical component codes matter. Build a device-specific coding lookup — typically 20 to 60 codes from Annex A, 10 to 30 from Annex G, and the full Annex E/F trees.
3. **Build the coding into the complaint intake form.** Not as a free-text field labelled "device problem." As a structured drop-down or multi-select linked to the IMDRF code and its human-readable description. Complaint intake person selects one or more codes at intake, based on the initial information. The code can be refined later during investigation, but it is never blank.
4. **Link the coding to the investigation workflow.** When the complaint moves to investigation, the investigator selects codes from Annex B (type of investigation) and, on conclusion, Annex C (findings) and Annex D (conclusion). These become structured data points that feed the trend analysis automatically.
5. **Connect the coded data to CAPA and risk management.** When a specific Annex A code appears above a threshold frequency, the QMS should trigger a review — does this constitute a trend per MDR Article 88? Does it affect the risk file per EN ISO 14971:2019+A11:2021? Does it require a CAPA?
6. **Use the codes to drive your PSUR or PMS report.** For Class IIa, IIb and III devices, the PSUR per MDR Article 86 requires analysis of complaint and incident data. With IMDRF coding in place, the analysis section writes itself from database queries. For Class I devices, the PMS report per Article 85 benefits equally.
7. **Mirror the coding onto your Eudamed serious incident reports.** When you file a serious incident report under Article 87, the Eudamed form requires categorisation using the structured nomenclature. If your internal system already uses IMDRF AET, the mapping is direct.

The Subtract to Ship principle: do the coding once, at the source, when the complaint is fresh and the details are known. Every minute invested at intake saves hours at audit time, trend analysis time, and regulator submission time. Start the day you open your first complaint ticket — even if your device is not yet on the market. Code your beta tester feedback. Code your clinical investigation adverse event reports. Build the habit before it matters.

## Reality Check

1. Do you have a current copy of the IMDRF Adverse Event Terminology annexes, and do you know when it was last updated?
2. Have you built a device-specific subset of IMDRF AET codes — Annex A device problems, Annex G components, Annex E/F health effects — relevant to your device type?
3. Is your complaint intake form structured with IMDRF code selection, or does it rely on free-text description?
4. Can you produce a trend report answering "how many complaints of type X in the last six months" with a database query rather than manual re-reading?
5. Does your CAPA trigger criteria reference IMDRF coded complaint frequencies?
6. Does your PSUR or PMS report template include sections that are populated from IMDRF-coded complaint data?
7. When you file a serious incident report, can you map your internal coding directly to the Eudamed vigilance form fields without re-categorising?
8. Have you trained your complaint intake staff (even if that is one person) on which IMDRF codes apply to common complaint scenarios for your device?

## Frequently Asked Questions

**Is using IMDRF AET legally mandatory under MDR?**
No. IMDRF AET itself is not a legally binding standard. MDR does not contain a direct citation requiring IMDRF AET. However, Eudamed — the European medical device database established under MDR Article 33 and Commission Implementing Regulation (EU) 2021/2078 — uses structured nomenclature aligned with IMDRF for its vigilance module. MDCG 2023-3 Rev.2 (January 2025) on vigilance terms and concepts reflects this alignment. In practice, for your vigilance data to be usable in Eudamed submissions, it needs to be mappable to IMDRF AET categories.

**What is the difference between IMDRF AET and other coding systems like MedDRA?**
MedDRA (Medical Dictionary for Regulatory Activities) is a clinical terminology used primarily in pharmaceutical pharmacovigilance to describe clinical signs and symptoms. IMDRF AET is specifically designed for medical device adverse events and includes device-specific categories (device problems, device components, investigation findings) that MedDRA does not cover. IMDRF AET Annex E (clinical signs) is harmonised with MedDRA in concept, but the full AET set is device-specific.

**Do we need to use IMDRF AET before Eudamed is fully mandatory?**
Yes, and here is why: once Eudamed's vigilance module becomes mandatory, manufacturers with years of free-text complaint data will have to retroactively code it to file any historical analyses. Starting with coded data from day one is the only sane option. Even pre-Eudamed, coded data makes your own PMS and trend analysis possible in practice.

**How often is IMDRF AET updated?**
IMDRF publishes updates to the AET document set periodically as international harmonisation work continues. Check imdrf.org for the current release and subscribe to updates. When a new version is released, review whether any codes relevant to your device have changed and update your internal lookup accordingly.

**Can we build IMDRF coding into our eQMS or do we need a separate tool?**
Most modern eQMS platforms support configurable complaint forms with drop-down fields linked to code libraries. You can typically import the IMDRF AET code set as a reference list and configure your complaint form to require code selection at intake. For very early-stage startups without an eQMS, a well-structured spreadsheet with validated drop-down cells is a legitimate starting point — as long as it is part of a controlled document per MDR QMS requirements.

**What happens if we code something wrong at intake?**
Coding at intake is an initial categorisation based on available information. It is expected to be refined during investigation. What matters for audit is that the coding is deliberate, documented, and updated when investigation reveals more. Getting it perfect at intake is not the goal; getting it structured and traceable is.

## Related reading
- [What Is Vigilance Under MDR](/blog/what-is-vigilance-mdr) — the full vigilance framework under Articles 87-92.
- [MDR Articles 87-92 Vigilance Framework](/blog/mdr-articles-87-92-vigilance-framework) — the legal basis in detail.
- [Customer Complaint Handling Under MDR](/blog/customer-complaint-handling-mdr) — how complaint intake connects to vigilance.
- [Eudamed Vigilance Module](/blog/eudamed-vigilance-module) — how vigilance reports land in Eudamed.
- [Report a Serious Incident to the Competent Authority](/blog/report-serious-incident-competent-authority) — the reporting procedure step by step.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Articles 33, 83-86, 87-92.
2. MDCG 2023-3 Rev.2 (January 2025) — Vigilance terms and concepts as outlined in MDR and IVDR — Q&A.
3. Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021 laying down rules for the application of Regulation (EU) 2017/745 of the European Parliament and of the Council as regards the European database on medical devices (Eudamed).
4. IMDRF Adverse Event Terminology — IMDRF/AE WG documents, current release, available at imdrf.org.

---

*This post is part of the [Post-Market Surveillance & Vigilance](https://zechmeister-solutions.com/en/blog/category/pms-vigilance) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*