MDR Annex II is the technical documentation the Notified Body reviews and the PRRC signs off. EUDAMED is the EU database the same content has to populate before a device reaches the EU market. The two structures do not line up clause for clause: the EC data dictionary names different fields, uses different enumerations, and asks for the content in a different shape. The work in between is the field-by-field mapping. This page covers it section by section: which Annex II clause feeds which EUDAMED module and field, where the mapping is direct and auto-matchable, and where manual review by the PRRC is required. The Johner Institute “Negativeinträge vermeiden” graphic is, as far as we know, the only prior treatment of Annex II to EUDAMED in any language; this page is the full English-language complement.
What MDR Annex II requires of technical documentation
MDR Annex II sets out the technical documentation every manufacturer assembles for every device on the EU market. It is the file the Notified Body reviews for Class IIa, IIb and III, and the file a Class I manufacturer holds and produces on competent-authority request. Six sections structure the file.
Section 1 covers the device description and specification, including variants and accessories. Section 2 covers the information supplied by the manufacturer: the label, the IFU, the package leaflet, and the language coverage across the EU markets the device is placed on. Section 3 covers the design and manufacturing information, including manufacturing sites and key subcontractors. Section 4 carries the General Safety and Performance Requirements conformity matrix, mapping each requirement to the evidence that supports it. Section 5 carries the benefit-risk analysis and the risk management file under ISO 14971. Section 6 carries product verification and validation, splitting into preclinical evaluation and clinical evaluation.
The Annex II file sits alongside the Annex III post-market surveillance plan, which the EUDAMED Post-Market Surveillance module ingests once that module is declared functional. The Notified Body assesses every section against the corresponding regulatory requirement; the PRRC under Article 15(3) signs the file off on behalf of the manufacturer. MDCG 2019-13 covers the Notified Body sampling pattern that determines how much of the file is reviewed in each conformity assessment cycle. An adjacent academic mapping by Atmaca and colleagues (2026, Nature) classifies Annex II content into requirement categories rather than EUDAMED data fields and is therefore complementary to, not overlapping with, the field-level mapping below.
What EUDAMED records about your device, and where Annex II content lands
EUDAMED is built from six modules. Four are mandatory as of 28 May 2026: the Actor module, the UDI / Devices module, the Notified Bodies & Certificates module, and the Market Surveillance module. The Vigilance and Post-Market Surveillance module and the Clinical Investigations & Performance Studies module are not yet declared functional; the EC’s roadmap targets later 2026 for the Vigilance and PMS module, with a separate Commission decision required before mandatory use begins.
Annex II content lands in three places. The UDI / Devices module holds the bulk of it. Every Basic UDI-DI record carries device name, risk class, EMDN code, applicable legislation, and a set of labelling flags that come from Annex II Section 2. Every UDI-DI record beneath it carries the model number, variant designation, and the unit-of-trade detail per commercial configuration.
The Notified Bodies & Certificates module holds the certificate evidence the Notified Body issues. Annex II Section 4 (GSPR conformity) and Annex II Section 6 (clinical evaluation) do not populate dedicated EUDAMED fields directly; they populate the certificate the Notified Body uploads, which the manufacturer references on the device record by certificate number.
The Post-Market Surveillance module, once declared functional, will ingest Annex III content rather than Annex II Section 5. The Vigilance module will hold incident reports triggered by the risk management file but is also not yet mandatory.
The EUDAMED data dictionary, published through the EUDAMED Information Centre, is the source of truth for the field list. Field counts vary by device class, by module, and by whether the submission is single-variant or multi-variant; the dictionary itself is the right reference for the count specific to a given submission rather than a fixed number quoted in a third-party article.
Section-by-section mapping
Each Annex II section maps to a specific EUDAMED destination, and most of the destinations sit in either the UDI / Devices module or the Notified Bodies & Certificates module. The subsections below name the source document where each Annex II area typically lives in the manufacturer’s file, the EUDAMED module the content lands in, and whether the mapping is direct (auto-matched against the data dictionary) or indirect (manual review by the PRRC).
3.1 Device description and variants → EUDAMED Device and UDI modules
Annex II Section 1 holds device name (trade and commercial), intended purpose, device class, variants and accessories, and device identifiers. It maps to most of the load-bearing fields on the EUDAMED Basic UDI-DI record: device trade name, risk class (the EUDAMED enumeration, not a national abbreviation), EMDN code, applicable legislation (MDR, MDD, AIMDD, IVDR, IVDD), and the Basic UDI-DI itself. UDI-DI records beneath the Basic UDI-DI carry model designation per variant. The grouping decision (which variants share a Basic UDI-DI) follows Annex VI part C and MDCG 2018-1 Rev. 4.
3.2 Information supplied by the manufacturer (IFU, label) → EUDAMED labelling indicators
Annex II Section 2 holds the IFU, the label content, and the IFU language list. It maps to the EUDAMED structured labelling flags on the Basic UDI-DI record: single-use, sterile, contains-medicinal-substance, latex, CMR / endocrine-disruptor presence, warnings, and the structured language list (EUDAMED records language coverage as a structured field, not free text). Each flag is a declared value on the IFU or label and a direct mapping to the corresponding EUDAMED field.
3.3 GSPR conformity (Annex II Section 4) → EUDAMED Certificate module evidence
Annex II Section 4 does not populate a dedicated EUDAMED field. It populates the certificate evidence the Notified Body issues, which the manufacturer references on the device record by certificate number. The Notified Bodies & Certificates module holds the certificate metadata (certificate number, issuing Notified Body identifier, scope, validity). For Class I devices without a Notified Body certificate, the GSPR conformity matrix stays in the technical file and is not surfaced in EUDAMED.
3.4 Benefit-risk analysis and risk management (Annex II Section 5) → indirect, via PMS and vigilance
Annex II Section 5 does not map to a discrete EUDAMED field. The risk management file underpins PMS triggers (severity, frequency, mitigation effectiveness) that surface, once the relevant modules are functional, in the Vigilance module as incident reports and in the PMS module as plan execution and PMCF outputs. The benefit-risk analysis itself stays in the technical file. This is a no-direct-field row on the mapping table.
3.5 Clinical evaluation (Annex II Section 6) → EUDAMED Certificate evidence and SSCP upload
Annex II Section 6 maps to two EUDAMED destinations. The clinical evaluation report (CER) supports the Notified Body certificate, which the manufacturer references on the device record by certificate number. For implantable and Class III devices, the Summary of Safety and Clinical Performance (SSCP) is itself a EUDAMED-uploaded document attached to the device record. The SSCP is the patient-facing summary the public reads through the EUDAMED interface; the CER stays in the technical file.
3.6 Post-Market Surveillance plan (Annex III) → EUDAMED PMS module
Annex III sits alongside Annex II and is not part of it, but the PMS plan content (frequency of review, PMCF triggers, complaint-handling cadence) is the input to the EUDAMED PMS module once it is declared functional. Until then, PMS reporting runs through national channels. When the module activates, the PMS plan and the periodic safety update reports populate EUDAMED entries linked to the Basic UDI-DI record.
The master reference table
| MDR Annex II clause | Source document | EUDAMED module | EUDAMED field(s) | Auto-matched or manual review | Mismatch risk |
|---|---|---|---|---|---|
| §1 Device description (name, intended purpose) | IFU, DoC, technical file | UDI / Devices | Device trade name, intended-purpose text | Auto-matched on structured fields; manual review on free-text intended purpose | Trade name vs internal naming drift |
| §1 Device class | DoC, classification rationale | UDI / Devices | Risk class (EUDAMED enum) | Auto-matched from DoC | National-abbreviation values rejected |
| §1 EMDN code | Annex II classification rationale | UDI / Devices | EMDN code | Auto-matched on most devices; manual review on novel EMDN candidates | EMDN refreshed by EC; deprecated codes fail |
| §1 Variants and accessories | Technical file, label set | UDI / Devices | Basic UDI-DI grouping; UDI-DI per variant | Manual review on grouping decisions | Basic UDI-DI split too coarsely or too finely |
| §2 IFU labelling flags | IFU, label | UDI / Devices | Single-use, sterile, latex, CMR, warnings | Auto-matched on declared values | Free-text IFU clauses misread |
| §2 IFU language coverage | IFU language list | UDI / Devices | Structured language list | Auto-matched from declared coverage | Free-text language list rejected; must be structured |
| §3 Design and manufacturing | Technical file, supplier list | (not in EUDAMED) | None | Not in scope | None: technical file holds this |
| §4 GSPR conformity | GSPR matrix, Notified Body certificate | Notified Bodies & Certificates | Linked certificate reference | Auto-matched once certificate is uploaded by NB | Stale certificate number on device record |
| §5 Benefit-risk and risk management | Risk management file | (indirect via PMS / Vigilance) | None directly | No direct field | None: feeds vigilance reports when modules functional |
| §6 Clinical evaluation, CER | Clinical evaluation report | Notified Bodies & Certificates | Linked certificate reference | Auto-matched via certificate link | Stale certificate or scope mismatch |
| §6 SSCP (implantable / Class III) | SSCP document | UDI / Devices | SSCP file upload, language coverage | Manual review on language coverage | Missing SSCP for Class III; wrong language list |
| Annex III PMS plan | PMS plan | PMS module (when functional) | PMS plan entries, PMCF triggers | Not yet mandatory | Module not yet declared functional |
Two Annex II areas do not populate a dedicated EUDAMED field directly: Section 3 design and manufacturing information (held in the technical file, never surfaced in EUDAMED) and Section 5 benefit-risk and risk management (feeds the Vigilance and PMS modules indirectly, once those modules are functional). If a mapping table or third-party explainer suggests a Section 5 EUDAMED field exists today, treat the claim with caution.
Worked example: a Class IIa multi-variant device
A Class IIa orthopaedic instrument is supplied in three trim sizes, packaged sterile, single-use, with one IFU covering all three sizes and a label set localised into 24 EU languages. The Annex II to EUDAMED mapping for this device looks like this:
- One Basic UDI-DI covers the three trim sizes because the three sizes share intended purpose, risk class, design family, and the same Notified Body certificate (Annex VI part C and MDCG 2018-1 Rev. 4).
- Three UDI-DIs sit beneath the Basic UDI-DI, one per trim size, each carrying its own model designation.
- One EMDN code applies across the three variants because the EMDN classifies by device type, not by trim size.
- The Annex II Section 2 labelling flags (sterile, single-use) are declared once on the Basic UDI-DI record.
- The language list field carries the structured list of 24 languages; the IFU itself is not uploaded, only the language coverage is recorded.
- The Notified Body certificate covers the Basic UDI-DI and is referenced once; all three UDI-DIs inherit the certificate reference through the Basic UDI-DI parent record.
The grouping decision (one Basic UDI-DI, three UDI-DIs) is the manual-review hinge for this device. The same device family could be split into three Basic UDI-DIs if the manufacturer treated the sizes as separate design families, but that would imply three separate Notified Body certificates and three separate EMDN reviews. The grouping needs the PRRC’s sign-off and a defensible rationale in the Annex II file.
Where mismatches commonly show up
Three mismatch patterns account for most of the rework on the EUDAMED side after the Annex II file is otherwise complete. Knowing them up front prevents the round trip.
The first is version drift. The Annex II file is revised on the manufacturer’s cadence (often annually); the EUDAMED data dictionary and EMDN are refreshed on the EC’s cadence (irregularly, on EC notice). A device record that validated against the dictionary six months ago can fail current business rules because an EMDN code was deprecated or a labelling enumeration value was renamed. The EC publishes EMDN updates through the EMDN portal; pre-export validation against the current published rules is the only reliable check.
The second is multi-variant grouping. Annex VI part C and MDCG 2018-1 Rev. 4 set the Basic UDI-DI grouping rules: shared intended purpose, shared risk class, shared design family, shared device-type. RA teams disagree on what counts as “shared,” especially across functional equivalents like size variants, trim variants, or sterile / non-sterile pairs. Split too coarsely and the UDI-DI count inflates; split too finely and the Basic UDI-DI count inflates with redundant certificates. Both fail at the EUDAMED submission once the Notified Body certificate scope does not match.
The third is IFU language coverage. The IFU is a free-text document supplied in N languages; EUDAMED records the language list as a structured enumeration field. A manufacturer who maintains the IFU language list as a free-text field in their internal system has to convert it into the structured EUDAMED enumeration before submission. The conversion is mechanical, but the source-of-truth shift catches teams unprepared. A related sub-pattern: terminology drift between the manufacturer’s internal device-naming convention and the EUDAMED trade-name field, where the same device carries different names across the engineering file, the regulatory file, and the EUDAMED record.
Where the PRRC sign-off attaches in this mapping
The PRRC under MDR Article 15(3) ensures that the conformity of the device, the technical documentation and the EUDAMED record are aligned before the manufacturer submits. MDCG 2019-7 documents the PRRC qualification path and the practical scope of the Article 15(3) sign-off.
The PRRC sign-off attaches in three places on the Annex II to EUDAMED mapping. First, the grouping decisions: which variants share a Basic UDI-DI, which Annex II sub-sections apply to each variant, and which EMDN code applies across the family. These are not clerical; the PRRC carries the defensible rationale and documents it in the Annex II file alongside the Notified Body’s assessment. Second, the no-direct-field clauses: the PRRC confirms that Section 4 (GSPR) and Section 5 (risk management) are correctly held in the technical file and the certificate even though no EUDAMED field surfaces them directly. The absence of a EUDAMED field is itself a defensible position the PRRC stands behind. Third, the SSCP for implantable and Class III devices: the PRRC signs off the patient-facing summary as a EUDAMED-uploaded document that is read by the public through the EUDAMED interface.
The clerical carry-over (single-use flag declared on the IFU, sterile flag declared on the label, model number declared on the DoC) does not need PRRC-level decision-making; it needs PRRC-level review. The distinction matters operationally: the PRRC’s time is the constraint, and the mapping table separates what needs the PRRC’s judgment from what needs the PRRC’s signature.
Legacy devices: how Regulation 2024/1860 changes the mapping
A legacy device is an MDD, AIMDD or IVDD device on the EU market under the extended-certificate regime of Regulation (EU) 2023/607 as further amended by Regulation (EU) 2024/1860. MDR Article 120 carries the transition provisions. The Annex II to EUDAMED mapping for legacy devices differs from the new-device path in three respects.
First, the identifier. Legacy devices use an EUDAMED-DI issued by the database itself, not a Basic UDI-DI issued by a UDI agency. The Basic UDI-DI assignment process does not run for legacy devices; the EUDAMED record carries the EUDAMED-DI as the primary key instead.
Second, the Annex II content set. MDCG 2021-25 sets out which Annex II clauses are required for the legacy EUDAMED record and which are held against the original MDD or AIMDD technical file without surfacing in EUDAMED. The labelling flags from Section 2 are required; the GSPR conformity matrix from Section 4 is not, because GSPR is an MDR concept, not an MDD one.
Third, the deadline. New MDR and IVDR device registrations entered EUDAMED on 28 May 2026; legacy devices have until 28 November 2026 under Commission Decision (EU) 2025/2371 and the 12-month transition in MDR Article 123(3). A legacy portfolio that has not yet started the EUDAMED record assembly has roughly six months to prepare the EUDAMED-DI records and link them to the surviving Notified Body certificates. The EUDAMED registration deadlines page covers the date arithmetic and the legal sources; the EUDAMED registration pillar covers the actor record that has to be in place before any device record (legacy or new) is accepted.
How EUDAPrep builds the mapping from your documentation
EUDAPrep takes the Annex II source documents (IFU, label, DoC, technical file, SDS, risk file, SSCP) and produces a candidate EUDAMED record for each Basic UDI-DI and UDI-DI in the manufacturer’s portfolio. The workflow runs in three layers.
The deterministic layer handles fields where the EUDAMED data dictionary admits an exact rule: risk class declared on the DoC maps to the EUDAMED risk-class enumeration; sterile flag declared on the IFU maps to the EUDAMED sterile indicator; language list declared on the IFU maps to the structured language enumeration. These fields are auto-matched against the EC-published data dictionary and the EUDAMED enumeration files.
The structured-assistance layer handles fields where the source document is unstructured text and the data dictionary admits a candidate list. EMDN selection on a novel device family is the canonical case: the source describes the device, and the data dictionary admits one EMDN code from the EC-published nomenclature. EUDAPrep proposes a candidate from the retrieval-augmented list and surfaces the reasoning; the PRRC reviews and accepts, edits, or rejects. The AI-use disclosure is shown anywhere this layer runs, consistent with the AI Act Article 50 disclosure principle.
The manual-review layer handles cases where neither layer produces a confident match: novel EMDN candidates without a high-confidence retrieval result, free-text IFU clauses where multiple EUDAMED flags could apply, multi-variant grouping decisions, and legacy-device transition status calls. These surface in the review wizard as flagged items.
Every candidate value runs through pre-export validation against the EC business rules before XML export. EUDAPrep generates bulk-upload-ready XML; the manufacturer (or the PRRC) downloads the file and uploads it through the EC’s EUDAMED portal. EUDAPrep does not submit to EUDAMED.
When manual review is required vs auto-matched
Auto-matched and manual-review are per-field decisions the data dictionary supports or does not. The mapping table above marks each clause with its default; the per-submission outcome depends on the source documents and the device class.
Auto-matched cases share a property: the source document carries one declared value and the EUDAMED enumeration has one defensible mapping. Risk class declared on the DoC, UDI-DI declared on the label, sterility flag declared on the IFU, language list declared on the IFU. The deterministic layer fires on these and the PRRC reviews the candidate without re-doing the decision.
Manual-review cases share the opposite property: either the source document admits multiple defensible readings, or the EUDAMED enumeration admits multiple candidate codes, or the regulatory context disambiguates a decision the source leaves open. Novel EMDN selection where the device sits across two nomenclature branches is the most common; multi-variant Basic UDI-DI grouping is the second most common; the legacy-device transition status call is the third.
Flagged items appear in the review wizard with the source excerpt, the candidate value, and the alternative candidates. Pre-export validation against the EC business rules runs on the final selected values regardless of which layer produced the candidate; the portfolio cannot be exported as XML while any record fails the rules. The AI-use disclosure shown alongside the structured-assistance layer is consistent with the AI Act Article 50 disclosure principle; the PRRC sign-off under MDR Article 15(3) is the regulatory anchor.