EMDN (European Medical Device Nomenclature) is the seven-level alphanumeric classification system the European Commission designated under Article 26 of MDR Regulation (EU) 2017/745 and Article 23 of IVDR Regulation (EU) 2017/746 to identify medical devices in EUDAMED. Picking the right code is a tree-walk: start at one of the alphabetical Categories, descend through Group and Type levels, and stop at the most granular terminal term that accurately describes the device. The EC publishes the full list, refreshed annually, on the EMDN portal.
Current release: EMDN V3 (European Commission EMDN portal, 2025 publication). Verify the version stamp on the EC portal at submission time. The Commission updates EMDN annually; codes may be added, edited, split or marked obsolete with each release.
What EMDN is and why the EC chose it
EMDN is the regulator-led nomenclature the European Commission designated for use in EUDAMED, the European database on medical devices established under MDR Articles 33 to 43. The EC’s own UDI Helpdesk states the rule plainly: under MDR Article 26 and IVDR Article 23, EMDN “aims at supporting the functioning of the European database on medical devices (EUDAMED)” and is associated with each UDI-DI registered there.
The Commission did not invent EMDN from scratch. It was built on the Italian Ministry of Health’s Classificazione Nazionale Dispositivi medici (CND), which was already in regulatory use in Italy, Greece and Portugal. After consultations during 2019 and 2020, the first published version of EMDN was released on 4 May 2021. Commission Implementing Decision (EU) 2019/939 (renewed by Decision (EU) 2024/2120) designates the four UDI issuing entities whose UDI-DI carries the EMDN code on every EUDAMED device record.
The catalogue today carries roughly 8,500 terminal codes spread across 23 Categories and seven hierarchy levels. Three properties make it usable for regulatory work: it is free at point of use, the EC manages the update cycle (so the structure does not drift with vendor product cycles), and every terminal term carries both a code and a descriptive label that anchors the classification to a real device characteristic.
How to read the EMDN hierarchy
The EC structures EMDN as a seven-level alphanumeric tree. Three named levels open it; the remaining four are progressively granular detail layers underneath the Type level.
A code is alphanumeric, begins with the Category letter, and contains at most thirteen characters. Each level carries a paired code and term; the term is a concise description of the devices clustered under that level. The terminal term is the lowest level applicable to the device. As MDCG 2021-12 Rev.1 puts it, “manufacturers must always assign the most granular and terminal code and term available (lowest level in the tree) to their device.”
The browser at the EC EMDN portal renders the tree as an expandable structure; you click into a Category, then a Group, then a Type, until further expansion stops or no longer fits the device. The downloadable Excel and PDF list the full tree flat with codes, terms and parent paths for offline navigation.
The “most specific code wins” principle
MDCG 2021-12 Rev.1 states the rule directly: pick the lowest applicable terminal term. The principle exists for retrieval, not pedantry. EUDAMED uses the EMDN code to group devices for post-market surveillance, vigilance analysis and notified-body technical-documentation sampling. A parent-level code that captures three device families inflates the apparent population under that node and degrades every downstream filter.
The decision logic for a single device runs in four steps.
- Identify the Category letter that matches the device’s principal function or material class.
- Read the Group descriptions under that Category and pick the one whose definition encompasses the device.
- Descend through Type and any applicable detail sub-levels, comparing the term at each step against the device’s instructions for use, label and declaration of conformity.
- Stop at the lowest level whose term still accurately describes the device. That is the terminal term; record its code.
A worked example using EMDN V3. A 2-piece Luer-cone, single-use syringe supplied with a needle:
| Level | Code | Term |
|---|---|---|
| Category | A | Devices for administration, withdrawal and collection |
| Group | A02 | Syringes |
| Type | A0201 | Single-use syringes |
| Detail 1 | A020102 | Infusion and irrigation syringes, single-use |
| Detail 2 | A02010201 | Infusion and irrigation syringes, Luer cone, single-use |
| Detail 3 | A0201020101 | Infusion and irrigation syringes, 2-piece Luer cone, single-use |
| Terminal | A020102010101 | Infusion and irrigation syringes, 2-piece Luer cone, 2-piece with needle, single-use |
A02 alone is the wrong answer for this device. A020102010101 is the right one. The terminal term should match the device’s primary function and the structural features that distinguish it within the Type subtree, not its packaging or accessory features.
Multi-function devices are the documented exception. MDCG 2021-12 Rev.1 Question 7 records that for “complex medical device systems which allow a large array of diagnostic and therapeutic functions, more than one code may be used.” There is no priority order between the multiple codes; all carry equal weight in EUDAMED. If you find yourself wanting two codes for a single-function device, the indication is usually that you have not yet found the right terminal term.
If you are stuck on terminal-term selection, EUDAPrep shortlists candidate EMDN terminal terms for your device from the EC’s current catalogue and surfaces them for your review. The shortlist is deterministic; you confirm the final selection before any XML is generated.
GMDN to EMDN: what mapping exists, what doesn’t
The most common starting position for a manufacturer new to EUDAMED is “I have a GMDN code already.” That is useful context but not a destination. GMDN is the Global Medical Device Nomenclature operated by the GMDN Agency as a paid membership service; EMDN is the EC’s free, regulator-led nomenclature. The two were built by different bodies for different regulatory ecosystems, and no official one-to-one mapping exists between them.
| Dimension | GMDN | EMDN |
|---|---|---|
| Owner | GMDN Agency (independent, UK-based) | European Commission, supported by MDCG |
| Access | Paid membership tiers | Free, downloadable in PDF and Excel |
| Structure | Three-level “preferred term” model | Seven-level alphanumeric tree (Category → Group → Type → details) |
| Code count | ~28,000 terms | ~8,500 terminal codes |
| Primary regulator use | US FDA, Australia TGA, UK MHRA among others | EUDAMED under MDR and IVDR (mandatory) |
| EUDAMED relevance | Not the EUDAMED nomenclature | The designated EUDAMED nomenclature |
What does exist for moving between the two is partial. The GMDN Agency operates a matching service that takes a GMDN preferred term and surfaces candidate EMDN codes; a fee applies. Academic mapping work (notably the CORE-MD initiative) has documented the structural mismatches and proposed mapping tools but has not produced a Commission-endorsed table. The EC’s webinar Q&A material on EMDN covers the same ground from the regulator’s side: an EMDN selection is a fresh tree-walk against the EC catalogue, not a translation from GMDN.
The workflow for a GMDN-anchored manufacturer runs in five steps.
- Pull the GMDN preferred term from your existing documentation. Treat it as a description of the device, not as a code to translate.
- Use the term’s wording and the device’s IFU to identify a likely EMDN Category and Group on the EC portal.
- Walk the tree from Group down through Type and any detail sub-levels, comparing each term against the device.
- Stop at the lowest accurate terminal term. Record the EMDN code.
- Cross-check the candidate against the EC’s currently published catalogue version before submission; a code that was terminal in last year’s release may have been split or marked obsolete in this year’s.
Manufacturers with portfolios of fifty or more devices typically find a fully manual walk uneconomic; a tool that extracts product descriptions from IFU, label and declaration-of-conformity text and shortlists candidate EMDN terminal terms from the EC’s official list against those descriptions narrows the work to a review step. The PRRC retains documented responsibility under MDR Article 15(3); the tool produces candidates, not a determination.
When no EMDN terminal term fits: the code extension 99 pattern
The EMDN tree does not yet describe every conceivable device. For genuinely residual cases, the catalogue carries “Other” terminal entries at the deepest applicable level of each Type, encoded by the extension digits “99”. MDCG 2021-12 Rev.1 Question 9 records the rule in plain language: “Only if the most granular levels do not match the device’s description, the manufacturer may assign the code extension ‘99’ which refers to ‘other’ within that level type.”
Per MDCG 2021-12 Rev.1, code extension “99” is used only when no granular terminal term matches the device. UDI-DIs registered against a ‘99’ code are flagged for additional scrutiny during the annual EMDN review procedure, so the choice carries downstream attention.
Three conditions distinguish a correct ‘99’ assignment from a sloppy one.
First, the manufacturer has read the entire applicable subtree, not just the first few terms under the parent. The MDCG guidance puts the responsibility for that review squarely on the manufacturer.
Second, no existing terminal term genuinely fits. Close-enough does not count; if a published terminal term describes the device materially, that term is the right answer even when its label is not a perfect match for marketing copy.
Third, the manufacturer files an EMDN update proposal in parallel. Question 10 of MDCG 2021-12 Rev.1 sets out the workflow: assign the ‘99’ code now, and submit a proposal through the EMDN platform or the MDCG Nomenclature Working Group for a new terminal code, providing a thorough device description. The annual update procedure (MDCG 2024-2 Rev.1) processes proposals submitted by 31 January in the same calendar year.
Architecturally, EUDAMED also exposes “other” fallback codes on several non-nomenclature enum fields (for example, Critical Warnings and Storage and Handling Conditions) with mandatory free-text; those fallbacks share a name with the EMDN ‘99’ pattern but operate on different fields of the device record.
How EUDAMED uses your EMDN selection on submission
The EMDN code lands on the device record in the UDI/Devices module. In the bulk-upload XSD, it sits inside the UDI-DI device structure under the MDNCodes element (field ID FLD-UDID-149, “Nomenclature code” in the EC data dictionary). The element is mandatory on Regulation devices and accepts one or more EMDN codes per UDI-DI to support the multi-function exception.
The EMDN code and the Basic UDI-DI travel together on the device record. The Basic UDI-DI identifies the device family; the EMDN code identifies the device’s classification under the EU nomenclature; the two co-occur on every UDI-DI registered under that Basic UDI-DI. EUDAMED uses both jointly for retrieval, sampling and post-market grouping.
A short illustration of the element in context:
<udiDI>
<basicUDIIdentifier>0470001234567A1</basicUDIIdentifier>
<MDNCodes>
<code>A010101</code>
</MDNCodes>
</udiDI>(The full UDI-DI structure carries additional mandatory elements; the snippet above isolates the nomenclature field.)
MDCG 2019-13 Rev.1 ties the EMDN selection to Annex II technical documentation. For MDR class IIa and IIb devices, the fourth level of EMDN defines the “generic device group” that notified bodies use to sample technical documentation; for IVDR class B and C devices, the third level plays the equivalent role. A manufacturer with five devices that share a fourth-level EMDN parent presents one generic device group to the notified body, not five separate technical-documentation files for sampling purposes. The EMDN choice is therefore not only a classification act but a tech-documentation aggregation act.
The 28 May 2026 and 28 November 2026 deadlines (see EUDAMED registration deadlines) both presuppose that every device record carries a valid EMDN code from the current catalogue. The portal rejects bulk-upload payloads whose MDNCodes element is missing or carries a code not in the published list.
Common pitfalls in EMDN assignment
Five patterns account for most EMDN rejection or rework events in practice.
Picking a parent-level code instead of the terminal term. “Close enough” at the Type level when a detail sub-level is available degrades EUDAMED retrieval and complicates notified-body sampling. Walk the tree all the way down before settling.
Submitting against a stale catalogue version. A code that was terminal in EMDN V2 may have been split or marked obsolete in V3. The EMDN Excel download carries no version-stamp inside the cells; the version sits in the filename and on the EC portal page. Re-verify against the live EC catalogue immediately before the submission window opens. Per MDCG 2021-12 Rev.1 Question 23, obsolete codes remain visible in EUDAMED for at least five years but are blocked for new registrations and updates.
Multi-function devices treated as single-EMDN. A drug-eluting stent, an integrated diagnostic-and-therapeutic device, a software platform with several intended uses: these are the devices the MDCG explicitly permits multiple EMDN codes for. Assigning one code and hoping for the best understates the device’s scope.
Software-as-a-medical-device borderline cases. The EMDN software entries do not yet describe every clinical-function variant of SaMD. The right move is to assign the closest terminal term, file a parallel proposal for a new code, and document the rationale in the device technical file.
Waiting for the perfect new code. The EMDN annual update cycle runs once a year with a 31 January submission cut-off. A new code submitted in February will not appear in the catalogue until December or January of the following year, leaving an 11-to-23-month gap. Ad-hoc updates outside the annual cycle are restricted to notified bodies and competent authorities. The corrective pattern is to assign the closest existing terminal term (or ‘99’ where genuinely warranted), submit the new-code proposal in parallel, and update the EUDAMED registration once the new code is published.
EMDN refresh cadence: keeping your selection valid
The EC updates EMDN on an annual cycle. The submission window for new-code proposals closes on 31 January each year; the annual release of the updated catalogue is published in December or January of the following cycle, alongside an enumeration of changes since the previous version. The procedure is set out in MDCG 2024-2 Rev.1.
A change to the catalogue affects in-flight EUDAMED records in three ways. Codes split into more granular terminals become non-terminal and can no longer be used for new registrations or updates to existing ones. Codes marked obsolete remain visible in EUDAMED for at least five years from the obsolescence date but cannot be used for new submissions. New codes become available immediately; manufacturers with devices that now fit a newly-published terminal term update their EUDAMED records and their related regulatory documentation, at the latest ahead of the next annual surveillance audit.
Two practical implications. First, a code chosen against a 2025 EMDN snapshot may not be valid for a 2026 submission window; verify the version stamp at the time of upload, not at the time the device technical file was first drafted. Second, the manufacturer carries the watching brief. The EC does not contact individual manufacturers when a code they have used is changed; the change is published on the MDCG documents page and applies from publication. Standard practice is to review each annual EMDN release against the device portfolio and notify the notified body of any impacted codes ahead of the surveillance audit.