Prepare EUDAMED UDI registration data before choosing the submission method
Start by selecting the applicable device route and current dataset. Then assemble the correct Actor context, approved Basic UDI-DI and UDI-DI relationships, device attributes, controlled values, packaging, certificate and market relationships where applicable, source evidence, owners, and validation rules. Software can expose gaps and transform approved facts; it cannot make regulatory decisions.
Turn the approved UDI requirements into a submission-ready dataset
Yarify can inventory source fields, model identifiers and relationships, implement current validation rules, expose missing dependencies, and prepare the technical handoff to manual entry, bulk XML, or M2M.
What the engagement produces
- A route-specific requirements, ownership, and evidence inventory
- A canonical device model with approved controlled-value mappings
- A validated dataset and explicit handoff to the selected submission method
The requirement is a governed dataset, not merely filled cells
The Commission states that regulation devices require a unique Basic UDI-DI and UDI-DI and that a Basic UDI-DI cannot be registered without a UDI-DI. The user selects the connected Actor context. See the official registration starting point.
The detailed dataset depends on device route and characteristics. Official resources distinguish MDR, IVDR, and legacy datasets, while the registration guide separates identification, certificate information where applicable, characteristics, device information, and package details. Start with the applicable current source, not a copied universal spreadsheet.
For each field or relationship, record the authoritative source, accountable owner, evidence, transformation, controlled-value mapping, dependency, validation outcome, and intended operation. That makes manual entry, bulk XML, or M2M auditable from the same approved facts.
Model the hierarchy
Keep Actor, Basic UDI-DI, UDI-DI, Package UDI-DI, and internal record keys explicit and stable.
Select approved facts
Use the applicable current data dictionary and accountable sources; do not derive regulatory meaning from labels.
Preserve evidence
Connect each transformed value and relationship to its source, approval, validation baseline, and outcome.
Four selections before building the checklist
These decisions determine which fields, relationships, technical artefacts, and operations apply. They need accountable regulatory and operational ownership.
| Selection question | Examples | Required evidence | Technical use | Boundary |
|---|---|---|---|---|
| Which device route applies? | MDR regulation device · IVDR regulation device · legacy device · system/procedure pack · applicable special device route | Approved regulatory applicability decision and source documentation | Selects the correct source checklist, dictionary, schema, rules, and registration workflow. | Software must not infer the route from a product name or risk-class-like label. |
| Which Actor submits or owns the record? | Manufacturer or system/procedure-pack producer context and registered Actor identity | EUDAMED Actor record, SRN/context where applicable, and accountable user ownership | Routes records, permissions, upload queues, M2M addressing, and audit evidence. | An ERP company, legal entity, plant, or brand is not automatically the EUDAMED Actor. |
| Which official artefact baseline applies? | UDI/Device dictionary · common/module rules · enumerations · compatible service/entity XSDs · samples | Downloaded artefact versions, retrieval date, and compatibility record | Defines target meaning, types, cardinality, controlled values, and preflight checks. | A historic spreadsheet template is not proof of the current target contract. |
| What operation is intended? | Initial registration · add related device · update/new version · applicable status or relationship operation | Approved desired-state change and last reconciled EUDAMED state | Prevents a valid payload from requesting the wrong action or replaying accepted work. | Operation support and state constraints come from the current service/workflow guidance. |
UDI registration preparation checklist
“Collect” describes the data domain, not a fixed XML element list. Confirm exact attributes, cardinalities, controlled values, and rules in the current official artefacts.
| Data domain | Collect | Technical validation | Evidence | Applicability note |
|---|---|---|---|---|
| Actor and account prerequisites | Correct Actor context, authorised users and roles, environment access, and named owners for submission and administration. | The record resolves to one intended Actor and the required workflow can be performed in the target environment. | Actor record · access check · owner/RACI · environment | Always establish before preparing a submission workflow. |
| Basic UDI-DI identification | Approved Basic UDI-DI, issuing-entity context, legislation/device route, and stable internal product-family key. | Format using the selected issuing context, internal uniqueness, and the intended link to at least one UDI-DI. | UDI assignment record · approved family master · source owner | Required for regulation devices; legacy and special routes use their applicable identifier model. |
| Basic UDI-DI core information | The approved family-level regulatory facts required by the selected current dataset, with language/effective-version context where applicable. | Required and conditional attributes, controlled values, source consistency, and no conflicting repeats across child devices. | Approved technical/regulatory record · field-level provenance | Exact fields depend on MDR/IVDR, device context, and current official data artefacts. |
| Certificate relationships | Applicable certificate identifiers, types, notified-body context, relationship to Basic UDI-DI, and current status/effective evidence. | Reference resolution, allowed relationship, active state assumptions, and applicable dependency rules. | Approved certificate record · relationship owner · source version | Only where the selected device route and characteristics require certificate information. |
| UDI-DI identification | Approved UDI-DI, issuing context, stable device/source key, and its Basic UDI-DI relationship. | Identifier preservation as text, internal uniqueness, format context, and exactly the intended family link. | UDI assignment/master record · product crosswalk | Required together with Basic UDI-DI for regulation devices according to the official registration start page. |
| UDI-DI characteristics | Approved characteristics required or conditionally requested by the applicable device dataset. | Types, formats, controlled values, cross-field dependencies, and consistency with the approved Basic UDI-DI data. | Approved regulatory/product source · mapping specification | Varies by device and dataset; do not use one universal column list. |
| Device information | Applicable names/models, nomenclature, product and regulatory attributes, status/effective information, and other current dataset facts. | Required languages/formats where applicable, EMDN source, enumerations, conditions, and owner approval. | Regulatory record · PIM/ERP/PLM source · EMDN selection evidence | The Commission states EMDN is used for EUDAMED device registration; the detailed dataset remains context-specific. |
| Packaging and identifier hierarchy | Applicable Package UDI-DIs, levels, quantities, parent-child keys, and effective source data. | No orphan, duplicate, or circular relationships; cardinality and controlled values match current artefacts. | Packaging master · approved identifier record · relationship map | Higher Package UDI-DIs apply where the device has those package formats. |
| Market information | Applicable market facts and controlled values from the approved regulatory source, separated from commercial sales availability. | Current enumeration mapping, completeness, relationship to the correct device, and applicable date/state logic. | Market approval record · accountable owner · source version | Depends on the selected dataset, device context, and intended operation. |
| Conditional and cross-record dependencies | Trigger values, dependent fields, related records, prior accepted identifiers/state, and the responsible decision owner. | Implementable common/module business rules, relationship graph, operation order, and unresolved exceptions. | Rule baseline · source fields · exception/resolution record | Evaluate after the dataset route is selected; conditional does not mean optional when the trigger applies. |
| Submission and reconciliation controls | Intended operation, approval, source version, generated payload/entry manifest, correlation, response, and record outcome. | No stale desired state, duplicate operation, unresolved blocker, or accepted record left unreconciled internally. | Release manifest · response log · accepted-state ledger | Needed for reliable manual, bulk, and M2M operations, with method-specific evidence. |
The official catalogue separates data meaning, structure, controlled values, and rules. At review time, the live catalogue identified platform 2.27.0 and XSD 3.0.30. Record versions or retrieval dates and re-check them before production use.
Technical requirements are not regulatory decisions
The software boundary should be obvious in every gap report. Detection and enforcement can be automated; a missing judgement cannot.
| Situation | Technical action | Regulatory decision |
|---|---|---|
| Risk class is blank or conflicts across sources | Detect the gap, show all source values and dependent checks, block release, and route it to the RA/QA owner. | Determine and approve the applicable classification. |
| A local label does not match a controlled list | Check the versioned mapping set and report the unmapped source value with its target field. | Approve which current controlled value correctly represents the device fact. |
| Certificate data may be required | Evaluate configured dependency rules, verify reference structure, and report missing or unresolved evidence. | Decide applicability and approve the correct certificate relationship. |
| Two UDI-DIs appear to share a product family | Validate stable joins, identifier uniqueness, and consistency of repeated family-level facts. | Approve whether they belong under the same Basic UDI-DI based on the applicable criteria. |
| A current EUDAMED field has no internal source | Add it to the gap register with target meaning, condition, owner, and blocking effect. | Provide or approve the fact, or determine that it does not apply. |
Certificate information is explicitly conditional
The official UDI/Devices guide presents certificate information as applicable in certain registration paths, and the Commission maintains an annex for device certificate information. Implement the approved applicability decision and current dependency rules; do not assume every record needs a certificate or that no record does.
Assign owners before the first completeness report
A missing field with no owner is not an engineering backlog item. Route regulatory decisions, source corrections, technical defects, and operational exceptions differently.
| Role | Owns | Evidence |
|---|---|---|
| Local Actor Administrator | Actor/user administration and applicable environment or M2M access | Access and administration record |
| Regulatory data owner | Approved identifiers, classification, applicability, device facts, and conditional decisions | Approved source and decision trail |
| Product / master-data owner | ERP/PIM/PLM source quality, stable keys, packaging, and governed corrections | Source version and change record |
| Certificate / quality owner | Applicable certificate identity, relationship, status, and evidence | Structured certificate source |
| Integration engineering | Mappings, transformations, XML/service versions, technical validation, and traceability | Versioned code/config and test report |
| Submission operations | Release checks, authenticated action where required, result triage, and correction control | Submission and response log |
| Reconciliation owner | Accepted-state ledger, source-system status, exception aging, and safe retry decision | Record-level reconciliation report |
Eight stages from requirements selection to accepted state
Requirements work does not end when XML is generated or a form is submitted. The intended and accepted record states must reconcile.
- 01
Select
Confirm device route, Actor, intended operation, and current official dataset/technical baseline.
Exit · Scoped checklist with applicability owner
- 02
Inventory
Map required data domains to source systems, evidence, stable identifiers, and accountable owners.
Exit · Source and ownership matrix
- 03
Profile
Measure missing values, conflicts, duplicates, invalid formats, unresolvable joins, and stale records.
Exit · Completeness and quality report
- 04
Normalize
Build explicit Basic UDI-DI, UDI-DI, package, certificate, market, and other applicable relationships.
Exit · Canonical target-ready dataset
- 05
Map
Apply approved formats and controlled-value translations while preserving source and rule provenance.
Exit · Versioned field mapping
- 06
Validate
Check types, required/conditional data, enumerations, relationships, XSDs where relevant, and implementable rules.
Exit · Owned exception register
- 07
Approve
Have accountable reviewers confirm the facts and intended operation; freeze the approved source version.
Exit · Releaseable desired state
- 08
Submit and reconcile
Use UI, bulk XML, or M2M; capture each outcome, correct failures through governance, and align internal state.
Exit · Confirmed accepted-state ledger
Acceptance criteria for a submission-ready dataset
“Ready” means the scoped dataset is owned, evidenced, internally consistent, validated against its recorded baseline, and approved for an intended operation.
- 01
The applicable device route and current official dataset baseline are documented and approved.
- 02
Every planned record resolves to the correct Actor and one stable internal source key.
- 03
Regulation devices have approved Basic UDI-DI and UDI-DI values with an explicit relationship.
- 04
Every target data domain has a source, accountable owner, transformation policy, and evidence path.
- 05
Conditional fields show their trigger and owner; no missing regulatory fact is replaced by a convenience default.
- 06
Package, certificate, market, and other applicable child/reference records have valid, non-ambiguous relationships.
- 07
Technical artefact and controlled-value versions are recorded for the preparation run.
- 08
Reviewers can compare source facts, transformed values, intended operation, and validation result without reading raw XML.
- 09
Submission evidence and record outcomes can be reconciled to the approved source version.
What Yarify can implement
Source inventories, field/owner mapping, canonical device models, completeness reports, controlled-value mappings, dependency checks, exception worklists, approval flows, XML generation, technical validation, submission manifests, and response reconciliation.
What Yarify does not decide
Classification, applicability, identifier assignment, certificate applicability, and the truth and approval of device facts remain with the manufacturer and qualified regulatory advisers. Technical completeness or acceptance does not guarantee MDR or IVDR compliance.
Continue from requirements into the right workflow
This page owns the data inventory and preparation boundary. The related guides own recurring automation, transformation, validation, submission, dates, or migration.
UDI automation
Turn a governed requirements dataset into a repeatable recurring registration workflow.
Open guide →Excel to XML
Map approved workbook fields, controlled values, and repeated structures into XML-ready records.
Open guide →XML validator
Implement layered schema, enumeration, business-rule, reference, and response checks.
Open guide →Bulk XML upload
Prepare, approve, upload, and reconcile structured device-data batches.
Open guide →2026 deadlines
Check the mandatory-use and transition dates that shape preparation timing.
Open guide →Data migration
Discover, cleanse, normalize, validate, submit, and reconcile an existing portfolio.
Open guide →Return to the EUDAMED automation hub for the complete cluster map.
UDI requirements questions
What data is required for EUDAMED UDI registration?
The applicable data depends on whether the record is an MDR or IVDR regulation device, legacy device, system/procedure pack, or another supported route and on the device context. Official registration material separates Basic UDI-DI identification and core information, certificate information where applicable, UDI-DI identification and characteristics, device information, and package details. Use the current official dataset, dictionary, rules, and workflow rather than one universal checklist.
Are Basic UDI-DI and UDI-DI both required?
For regulation devices, the official registration start page says each device must have a unique Basic UDI-DI and a unique UDI-DI, and a Basic UDI-DI cannot be registered without a UDI-DI. Legacy devices use the applicable EUDAMED DI/EUDAMED ID model described by official guidance.
Is certificate information always required?
No universal claim should be made. The official user guide labels the certificate stage as applicable in certain cases, and the Commission publishes an annex covering when certificate information is provided based on device properties. Have the manufacturer or qualified regulatory adviser determine applicability, then technically validate the approved relationship.
Is there one fixed list of EUDAMED required fields?
Not across every device route and context. Select the applicable current dataset and use its data dictionary, XSD where relevant, enumerations, and business rules. Record the versions or retrieval date because the technical baseline can change.
Can software decide a missing classification or applicability value?
No. Software can detect that a value is absent, inconsistent, unmapped, or activates a dependency. Classification, applicability, identifier assignment, and approval of device facts remain regulatory decisions owned by the manufacturer and qualified advisers.
Does a complete technical checklist guarantee MDR or IVDR compliance?
No. Yarify can map approved facts, detect gaps, model relationships, apply controlled transformations, generate XML, and implement technical validation. Completeness against a configured technical baseline and successful submission do not guarantee regulatory compliance or the truth of the supplied facts.
Primary sources
Reviewed 9 September 2026. Dataset files, data dictionaries, schemas, rules, enumerations, help workflows, and device-specific applicability can change. Retrieve the current official material and record its version or review date before final mapping and submission.
European Commission — UDI/Device registration
Official module status, MDR/IVDR and legacy-device dataset resources, EMDN information, and registration guidance
EUDAMED Information Centre — Register Regulation Devices
Official starting conditions for regulation-device registration, Actor context, and the requirement for both Basic UDI-DI and UDI-DI
EUDAMED Information Centre — Categorisation of devices
Official definitions and relationships for Basic UDI-DI, UDI-DI, Package UDI-DI, EUDAMED DI/ID, legacy devices, and Master UDI-DI
European Commission — UDI/Devices user guide
Official registration workflow covering Basic UDI-DI identification, certificate information where applicable, UDI-DI data, device information, and package details
EUDAMED Information Centre — Annex on device certificate information
Official reference for cases in which certificate information is provided during regulation-device registration
EUDAMED Information Centre — Technical-documentation guide
Official separation of XSDs, XML samples, service definitions, business rules, enumerations, and data dictionaries
EUDAMED Information Centre — Current technical documentation
Official current catalogue of module data dictionaries, rules, enumerations, service definitions, XSDs, XML samples, and compatibility notes