Automate EUDAMED UDI and device registration
Reliable automation starts before XML. It collects approved data from Excel, ERP, PIM, PLM or internal databases, models Basic UDI-DI and UDI-DI relationships, validates the data, routes exceptions to accountable owners, then prepares bulk XML or sends approved changes through M2M. The final step is reconciliation: recording what EUDAMED accepted or rejected.
Replace recurring registration work with a controlled EUDAMED operating workflow
Yarify implements the reusable path from approved product facts to validation, submission preparation, processing outcomes, and future updates. Start with the recurring bottleneck rather than committing immediately to full M2M.
What the engagement produces
- A measured current-state workload and prioritized automation boundary
- Reusable mapping, validation, exception, and approval components
- A bulk XML or M2M path with processing-result reconciliation
What the manual registration workflow actually repeats
The UDI/Device module has been mandatory since 28 May 2026. The Commission states that manufacturers submit UDI/device information for devices placed on the EU market and links the current datasets from its UDI/Device registration page.
For a regulation device, the official workflow begins in the actor context and requires both a unique Basic UDI-DI and a unique UDI-DI. A Basic UDI-DI cannot be registered without a UDI-DI. Multiple UDI-DIs may refer to one Basic UDI-DI. See the registration guidance and identifier concepts.
The exact fields and conditional steps depend on the device, legislation, class and entered characteristics. The workflow below is therefore a technical operating model, not a universal regulatory checklist.
| Workflow stage | Typical manual action | Safe automation opportunity |
|---|---|---|
| Select the actor context | Sign in through EU Login and enter the manufacturer or system/procedure-pack producer account connected to the user. | Verify that the source record carries the correct actor identifier and route it to the correct submission queue before entry starts. |
| Identify the Basic UDI-DI | Choose the applicable legislation and issuing entity, then enter the Basic UDI-DI and its core information. | Validate format, uniqueness assumptions, ownership and the relationship between the source product family and its Basic UDI-DI. |
| Add certificate information when applicable | Complete the certificate step shown by EUDAMED for the device's entered class and characteristics. | Resolve approved certificate references and flag missing or inconsistent links for regulatory review without deciding applicability in software. |
| Enter the UDI-DI and device attributes | Provide identification, characteristics, device information, market data and other conditional values requested by the workflow. | Map internal values, populate repeated approved data, enforce controlled lists and evaluate cross-field completeness. |
| Build packaging relationships | Add applicable higher-level package identifiers and quantities while preserving the hierarchy. | Generate child records from structured packaging data and prevent duplicate, circular or orphaned relationships. |
| Review, submit and follow the state | Confirm the record, submit it and inspect subsequent state, notifications or processing errors. | Produce a review diff, capture the submitted version and reconcile accepted and rejected outcomes with the internal record. |
At scale, correction and reconciliation dominate data entry
The repetition index below is simple arithmetic using 100 records as the baseline. It is not a time or cost estimate and does not assume that every UDI-DI has its own Basic UDI-DI.
| Portfolio size | Record repetition | Likely operational pressure | Common failure pattern | Useful automation |
|---|---|---|---|---|
| 100 devices | 1× baseline | Manual entry may remain proportionate, but copy/paste and inconsistent preparation already create correction work. | One misunderstood controlled value or dependency can be repeated across the full set. | Structured collection, completeness checks and a generated review worklist. |
| 500 devices | 5× the 100-device baseline | Batch ownership, shared attributes, packaging data and exception queues become harder to manage in the UI alone. | Corrections are applied inconsistently across related records or lost between workbook versions. | Canonical mapping, reusable transformations, layered validation and bulk XML preparation. |
| 1,000+ devices | 10×+ the 100-device baseline | Submission is no longer the only problem; ongoing change detection and status reconciliation become operational systems. | Internal and EUDAMED states drift, creating duplicate updates, stale versions and unclear ownership. | System-connected generation with governed approvals; assess M2M when update frequency and readiness justify it. |
Official volume guidance is indicative
The Commission suggests the UI for up to 100 devices, bulk upload for 100–1,000 and M2M above 1,000. These bands help frame a conversation; they are not legal thresholds or a substitute for architecture assessment. Update frequency, source-data quality, approval complexity and operational capacity also matter. See the official modes-of-input guidance.
Five useful automation levels
Full M2M is not the only meaningful outcome. Many manufacturers gain most of the control by automating collection, mapping and validation while retaining a deliberate human release step. The Commission describes XML upload as semi-automated and M2M as automatic backend exchange in its data-exchange guidance.
| Automation level | Input | Output | Human control retained | Best fit |
|---|---|---|---|---|
| Governed manual preparation | Approved records collected in a controlled template | A complete review pack for manual UI entry | Entry and submission in EUDAMED | Small or low-change portfolios |
| Pre-submission validation | Excel, CSV or database exports | Field-level completeness, mapping and dependency report | Resolve exceptions and enter approved values | Teams keeping the UI but reducing preventable errors |
| Generated bulk XML | Normalized device data from spreadsheets or business systems | Versioned, validated EUDAMED XML packages | A permitted user uploads files and reviews results | Recurring batches without full M2M infrastructure |
| System-connected bulk workflow | ERP, PIM, PLM or an internal product-data service | Approved XML batches plus response and reconciliation worklists | Release approval and UI upload | Larger portfolios that still want controlled manual transmission |
| End-to-end M2M exchange | A governed backend and approved change events | Automatic messages, acknowledgements and status updates | Data approval, exception ownership and operations | High-volume or high-frequency programmes able to support DTX |
Example EUDAMED registration automation architecture
Separate the internal device model from the submission channel. This makes bulk XML a viable first release without preventing a later M2M implementation.
Source adapters
Excel · CSV · ERP · PIM · PLM · custom database
Extract values with source identifiers and change timestamps; do not erase provenance during import.
Canonical UDI model
Actor · Basic UDI-DI · UDI-DI · packaging · certificates · market data
Represent shared and one-to-many data once, then generate channel-specific structures from it.
Mapping and validation
Transformations · enumerations · dependencies · XSD · business rules
Version mappings against the applicable EUDAMED technical release and return errors to the owning source field.
Human approval boundary
Regulatory review · data-owner confirmation · release decision
Software proposes and tests; accountable users approve facts and regulatory decisions before submission.
Submission adapter
Manual worklist · bulk XML · M2M connector
Keep transport replaceable so a manufacturer can mature from UI or bulk upload to M2M without remapping every source.
Response reconciliation
Correlation · record outcome · accepted version · exception queue
Store what was sent, what EUDAMED returned and which internal state is now authoritative for the next change.
Validation is layered
Syntax and XSD checks do not replace enumerations, data dependencies, reference checks or EUDAMED business rules. The official documentation publishes these as distinct artefacts. See the technical catalogue.
Bulk XML retains a user step
Manufacturers can automate preparation and validation while a permitted EUDAMED user performs the upload. Official training identifies the required actor and Confirmer profile for device bulk upload. See the Devices training material.
M2M changes transport
M2M removes the routine upload action, but it adds onboarding, messaging, security and production-support responsibilities. It still needs the same governed source data and validation boundary.
Practical scenario: 650 UDI-DIs across three source systems
This is a synthetic implementation example, not a customer claim or regulatory recommendation.
Starting state
The ERP owns model numbers and commercial lifecycle state; the PIM owns names, packaging and market information; an RA workbook owns Basic UDI-DI grouping, class, EMDN and certificate references. None is a complete EUDAMED record.
First release
Source adapters join records on governed identifiers. A canonical model represents Basic UDI-DI groups, their UDI-DIs and packaging children. Validation returns an exception workbook with source system, record key, field, failed rule and responsible owner. Approved batches are generated as bulk XML for manual upload.
Operating state
Each run is versioned. The team can reproduce the source snapshot, mapping version, validation result, approval and submitted payload. EUDAMED outcomes are reconciled by record rather than recorded as one batch-level “uploaded” checkbox. If change frequency later justifies M2M, the transmission adapter changes while the source and control layers remain.
A controlled implementation sequence
Start with a representative cohort and explicit acceptance criteria. A large “convert everything” run hides mapping decisions until they are expensive to reverse.
Discover the real portfolio
Inventory regulation and legacy-device populations, source systems, identifier ownership, update frequency, user roles and existing submission history.
Profile representative data
Select difficult records—not only the cleanest ones—and measure missing values, repeated groups, conflicting codes and uncertain ownership.
Define the canonical model
Model Basic UDI-DI and UDI-DI relationships, packaging, certificates and conditional collections independently of the source layout.
Implement mappings and rules
Make every transformation traceable from source value to target field and return validation errors in language the owning team can resolve.
Pilot one bounded cohort
Run a representative subset through the chosen submission path, capture responses and update the mapping and exception process before scaling.
Operate and reconcile
Add release controls, audit logs, status monitoring, schema-version ownership and a runbook for failed or partial processing.
Acceptance criteria for a useful first release
- Every generated target value traces back to a source or approved transformation.
- Validation errors identify the record, field, rule and resolution owner.
- Basic UDI-DI, UDI-DI and packaging relationships survive round-trip review.
- The active EUDAMED schema and rule versions are recorded with each run.
- Submitted payloads and processing outcomes can be reproduced and audited.
- Regulatory approval remains an explicit human action rather than an inferred software state.
Use the deeper guide for the implementation detail
This page owns the automation operating model. The pages below own the mechanics of transformation, transport, validation and migration.
Excel to EUDAMED XML
For spreadsheet structures, column mapping, transformations and missing-data detection.
Open guide →Bulk XML upload
For file requirements, upload operations, processing responses and common failures.
Open guide →XML and business-rule validation
For the technical difference between XML syntax, XSD, enumerations and EUDAMED rules.
Open guide →ERP, PIM and PLM integration
For source-of-truth ownership, change detection and ongoing synchronization.
Open guide →M2M integration
For Access Point architecture, AS4/eDelivery, Playground onboarding and production operations.
Open guide →EUDAMED data migration
For a bounded portfolio conversion from legacy files and systems into a reconciled dataset.
Open guide →Need the overall orientation first? Return to the EUDAMED automation hub.
UDI automation questions
How can EUDAMED UDI registration be automated?
Start by extracting approved data into a canonical model, mapping internal values to current EUDAMED structures, validating completeness and dependencies, and placing a human approval boundary before submission. The final channel can remain manual UI entry, use generated bulk XML, or use M2M. Automation should also capture processing outcomes and reconcile them with the internal record.
Does every manufacturer need M2M integration?
No. The Commission's indicative guidance points to the UI for up to 100 devices, bulk upload for 100–1,000 and M2M above 1,000, but these are not legal thresholds. A stable large portfolio may be suited to bulk XML, while a smaller portfolio with frequent changes may justify a stronger integration. Readiness and operating cost matter alongside volume.
Can EUDAMED registration automation use Excel as the source?
Yes, when the workbook is treated as a governed input rather than assumed to be submission-ready. The implementation needs explicit column mapping, controlled-value transformations, support for one-to-many structures, missing-data checks and a way to return errors to the correct row and field.
Can the same automation support bulk XML now and M2M later?
Yes, if the canonical data model, validation engine and approval workflow are kept separate from the transmission adapter. Bulk upload and M2M both use EUDAMED XML conditions, while M2M adds connectivity, security, onboarding and asynchronous operations.
What should happen after a submission is sent?
The system should retain the payload and correlation data, capture record-level outcomes, update the accepted internal state, route errors to an owner and prevent an unresolved failure from being treated as a successful registration. Submission without reconciliation is only partial automation.
Does technical validation guarantee MDR or IVDR compliance?
No. Technical validation can identify missing values, invalid structures, unsupported controlled values and rule conflicts. It cannot decide classification, applicability or whether the approved source facts satisfy every regulatory obligation. Yarify provides software implementation, not regulatory conclusions or a compliance guarantee.
Primary sources
Reviewed 9 September 2026. Re-check active XSDs, enumerations, business rules, service definitions and module release notes before each production implementation.
European Commission — EUDAMED overview
Official module status, including mandatory use of the UDI/Device module since 28 May 2026
European Commission — UDI/Device registration
Official device-registration overview and links to current MDR, IVDR and legacy-device datasets and guidance
EUDAMED Information Centre — Register Regulation Devices
Official starting point for regulation-device registration, actor selection and the Basic UDI-DI/UDI-DI relationship
EUDAMED Information Centre — Categorisation of devices
Official explanation of Basic UDI-DI, UDI-DI, package UDI-DI and legacy-device identifiers
EUDAMED Information Centre — Guidelines on Data Exchange
Official distinction between manual UI entry, semi-automated XML upload and automatic M2M exchange
EUDAMED Information Centre — Modes of data input
Official indicative device-volume bands for UI, bulk XML and M2M selection
EUDAMED Information Centre — Technical documentation
Official catalogue of XSDs, XML samples, service definitions, business rules, enumerations and data dictionaries
European Commission — Devices module training material
Official bulk-upload prerequisites and the technical artefacts manufacturers should use when preparing device XML