EUDAMED automation and integration for device manufacturers
Yarify builds the mapping, validation, XML, bulk-upload, and M2M integration layers that connect approved data in Excel, ERP, PIM, PLM, or internal databases to EUDAMED. The result is a repeatable workflow with visible exceptions and record-level reconciliation—not another one-off export.
One accountable implementation path from source data to accepted state
Start with the failure or bottleneck you have now. Yarify can deliver one bounded layer or connect the complete workflow; every engagement keeps source ownership, validation evidence, and EUDAMED outcomes visible.
Workbook and portfolio conversion
- Problem
- Device data is held in Excel, CSV, or inconsistent legacy exports that do not preserve EUDAMED relationships.
- Delivered outcome
- A governed source model, approved field mapping, exception report, and traceable XML-ready dataset.
Bulk XML preparation and validation
- Problem
- Teams can assemble records, but uploads fail late or cannot be reconciled to individual source rows.
- Delivered outcome
- Versioned XML packages, layered preflight results, correction workflows, and record-level processing evidence.
ERP, PIM, and PLM integration
- Problem
- Approved device facts are split across business systems with unclear ownership and incompatible structures.
- Delivered outcome
- Source adapters, a canonical device model, governed synchronization, approval controls, and reconciliation.
M2M exchange and production operations
- Problem
- High-volume or frequently changing portfolios have outgrown manual transmission and exception handling.
- Delivered outcome
- A production-ready DTX workflow covering the data layer, Access Point integration, responses, retries, and monitoring.
Not sure which route fits? Send the current data location, approximate volume, change frequency, and known submission problem. The first assessment is about choosing the smallest useful implementation—not selling the most complex option.
Discuss your EUDAMED workflowBegin with evidence, then build the smallest complete path
You do not need a perfect master-data programme before the first conversation. A difficult but representative sample gives both teams something concrete to test.
Assess a representative sample
Review the actual source structure, device population, data ownership, update frequency, known failures, and intended submission route.
Define a testable implementation boundary
Agree the records, mappings, validation layers, exceptions, environments, deliverables, and acceptance evidence before development begins.
Build and prove the workflow
Implement the smallest complete path, test difficult records, show source-to-result traceability, and extend only after the pilot is accepted.
EUDAMED is one system with six connected modules
EUDAMED is the European Commission IT system established under the MDR and IVDR to collect and process information about medical devices. The Commission lists six connected modules plus a public website. See the official EUDAMED overview.
Commission Decision (EU) 2025/2371 confirmed the functionality of four electronic systems. Actor Registration, UDI/Device Registration, Notified Bodies and Certificates, and Market Surveillance became mandatory on 28 May 2026. The decision and its scope are available in EUR-Lex.
Market Surveillance is mandatory for competent authorities and the Commission. The manufacturer-facing automation problem addressed here is primarily the preparation and maintenance of UDI/device data, together with the actor and certificate references on which that data depends. The clinical investigations/performance studies and vigilance/post-market surveillance modules are not treated as already available production automation targets.
| Module | Status on 9 September 2026 | Why it matters to device-data work |
|---|---|---|
| Actor Registration | Mandatory since 28 May 2026 | Provides the actor context and identifiers used by downstream workflows |
| UDI/Device Registration | Mandatory since 28 May 2026 | Holds UDI and device information submitted by manufacturers |
| Notified Bodies and Certificates | Mandatory since 28 May 2026 | Supplies certificate relationships relevant to applicable device records |
| Market Surveillance | Mandatory since 28 May 2026 | Used by competent authorities and the European Commission |
| Vigilance and post-market surveillance | In development | Do not design a production submission claim around unreleased functionality |
| Clinical investigations and performance studies | Under analysis | Treat future integration details as version-dependent until officially released |
The difficult part is the data lifecycle, not the final click
Registration becomes a software problem when approved facts are distributed across files and systems, expressed in local terminology, or maintained without a reliable link to the EUDAMED record.
Inventory the source data
Identify which fields live in regulatory files, Excel, ERP, PIM, PLM, certificate records or local databases—and who owns each value.
Model device relationships
Keep actor, Basic UDI-DI, UDI-DI, packaging, certificate and market information connected without flattening one-to-many records into ambiguous cells.
Map controlled values
Translate internal codes into the current EUDAMED enumerations while retaining the source value and mapping decision for review.
Validate before submission
Check completeness, data types, XSD structure, controlled lists, cross-field dependencies and applicable business rules before a user or integration sends data.
Generate the submission
Create the correct XML service and entity structure for bulk upload or M2M instead of treating XML as a formatted spreadsheet export.
Reconcile the outcome
Capture acknowledgements and record-level results, route exceptions to an owner and keep the internal state aligned with the accepted EUDAMED state.
The Commission publishes XSDs, XML samples, service definitions, business rules, enumerations and data dictionaries as separate technical artefacts. A durable implementation versions its mappings and tests against the applicable release instead of treating one sample XML file as the complete specification. See the official technical-documentation catalogue.
Manual UI, bulk XML and M2M solve different operating problems
The Commission defines three input methods. UI entry is manual. XML upload is semi-automated because software may generate the file but a user still transmits it. M2M sends XML automatically between an external backend and EUDAMED. The official data-exchange guidance also warns that M2M may be too costly where volume or transmission frequency is low.
| Method | Automation | Human step | Setup | Best fit | Main limitation |
|---|---|---|---|---|---|
| EUDAMED user interface | Manual entry and confirmation | A user enters and submits each record | Lowest technical setup | Small, stable portfolios and infrequent changes | Repetitive work and manual consistency checks grow with volume |
| Bulk XML upload | Automated preparation; manual transmission | A permitted user uploads the generated XML through EUDAMED | Mapping, XML generation and validation | Periodic batches from structured spreadsheets or business systems | The upload and response-handling workflow still needs an operator |
| M2M data exchange | Backend-to-backend exchange | People govern data and exceptions rather than each transmission | Highest: connector, Access Point, security, testing and operations | High volume, frequent updates or an established product-data backend | Can be disproportionate when volume and submission frequency are low |
Use device count as a prompt, not a rule
The Commission offers an indicative tip: use the UI for up to 100 devices, bulk upload for 100–1,000 and M2M for more than 1,000. These are not regulatory thresholds. A 300-device portfolio with weekly updates may justify more automation than a stable portfolio of 1,200 records. Data quality, change frequency, internal-system readiness and support capacity belong in the decision. See the official modes-of-input guidance.
Start from the manufacturer situation, not a software label
The matrix below is an implementation starting point. It does not determine regulatory applicability or replace a review of the current EUDAMED documentation.
| Situation | Operational signal | Technical starting point | Go deeper |
|---|---|---|---|
| A small portfolio changes rarely | Up to roughly 100 devices; data already approved and easy to find | Manual UI with a governed preparation checklist | Compare all three methods → |
| Hundreds of devices are maintained in Excel | Repeated fields, inconsistent labels and periodic registration batches | Normalize the workbook, validate it and generate bulk XML | Excel to XML → |
| A prepared XML file is rejected | Schema, enumeration, dependency or service-level errors are unclear | Run a layered validation and preserve a field-level error report | XML validator → |
| Product data is split across ERP, PIM and PLM | No single export contains all approved regulatory and product attributes | Define ownership and a canonical device-data model before choosing transport | ERP integration → |
| Thousands of devices change frequently | Continuous updates, a capable backend and recurring reconciliation work | Assess whether full M2M is proportionate and operationally supportable | M2M integration → |
| A legacy portfolio must be registered | Multiple source formats, duplicate values and incomplete ownership | Run a controlled migration with exceptions, acceptance criteria and reconciliation | Data migration → |
One reusable data pipeline, three possible submission paths
Transport should be replaceable. The source mapping, canonical data, validation evidence and reconciliation log remain useful whether the organisation begins with bulk XML and later moves to M2M.
Source systems
Excel · CSV · ERP · PIM · PLM · databases
Canonical device model
Stable internal entities, identifiers, ownership and relationships
Validation and approval
Completeness · transformations · XSD · enumerations · business rules
Submission adapter
UI worklist · bulk XML package · M2M connector
EUDAMED processing
Authenticated submission and platform-side validation
Reconciliation
Responses · accepted state · exceptions · audit evidence
For M2M
The Commission lists an eDelivery-compatible product or service, Actor registration, an LAA user, Party ID, module-specific security keys and completed Playground onboarding among the prerequisites. These are added to the data pipeline; they do not replace it. See the official M2M prerequisites.
For UDI/device data
Use the current MDR, IVDR and legacy-device datasets and module documentation as the factual baseline. The Commission links these resources from its UDI/Device registration page. Regulatory classification and applicability decisions must be supplied by the manufacturer or its qualified adviser.
Continue with the guide that owns your next question
Each page below has a separate search intent and implementation boundary. This hub stays at decision level; the linked guides carry the field mappings, error examples, onboarding steps and migration detail.
UDI registration automation
Choose an automation level for recurring Basic UDI-DI, UDI-DI and device-data work.
Open guide →Bulk XML upload
Prepare, validate, upload and reconcile structured EUDAMED XML batches.
Open guide →Excel to XML
Turn spreadsheet rows, controlled values and repeated data into structured payloads.
Open guide →XML and business-rule validation
Separate syntax, XSD, enumeration, dependency and EUDAMED business-rule failures.
Open guide →M2M integration
Plan DTX architecture, Access Point connectivity, onboarding and asynchronous processing.
Open guide →ERP, PIM and PLM integration
Create a governed path from internal source systems to submissions and status updates.
Open guide →Manual vs XML vs M2M
Compare setup cost, recurring effort, volume, change frequency and operating model.
Open guide →UDI registration requirements
Build a practical inventory of prerequisites, identifiers, attributes and dependencies.
Open guide →2026 deadlines
Check the current mandatory-use dates and the scope of transitional milestones.
Open guide →Device-data migration
Move a portfolio from spreadsheets or legacy systems into a normalized, testable dataset.
Open guide →What Yarify can—and cannot—take responsibility for
Technical implementation
- Data discovery and field mapping
- Canonical device-data models
- Completeness, XSD and rule validation
- XML generation and upload preparation
- ERP/PIM/PLM and M2M integration
- Migration, response handling and reconciliation
Regulatory accountability
Yarify is not a regulatory consultancy. We do not determine device classification, decide whether an obligation applies, approve product claims or guarantee MDR/IVDR compliance. The manufacturer and its qualified advisers own those decisions and the truth of submitted data; our role is to make the approved data controlled, testable and exchangeable.
EUDAMED automation questions
What can be automated in a EUDAMED device-data workflow?
Software can extract data from Excel, ERP, PIM, PLM or databases; map fields and controlled values; detect missing dependencies; generate XML; run XSD and business-rule checks; prepare bulk uploads; support M2M exchange; and reconcile processing results. Regulatory decisions such as device classification and the approval of submitted facts still require accountable human ownership.
Is bulk XML upload fully automated?
No. The European Commission describes XML upload as semi-automated: XML generation can be automated, but a user still uploads or downloads the file through the EUDAMED interface. M2M is the option designed for automatic exchange between an external backend and EUDAMED.
When should a manufacturer consider EUDAMED M2M?
The Commission gives an indicative tip of UI entry up to 100 devices, bulk upload for 100–1,000 and M2M above 1,000. Those are not legal thresholds. Change frequency, internal-system readiness, exception volume, security, infrastructure and support cost also determine whether M2M is proportionate.
Can an Excel file be converted directly into EUDAMED XML?
It can be a source, but reliable conversion usually needs an explicit mapping layer. A flat row may need to become several related entities, local labels may need controlled-value mappings, repeated data may need child structures, and conditional fields must be checked before XML generation.
Does XSD-valid XML guarantee acceptance by EUDAMED?
No. XSD validation checks the permitted XML structure and data types. EUDAMED publishes business rules, enumerations, service definitions and data dictionaries separately, so a structurally valid file can still conflict with a controlled value, dependency, reference, version or service rule.
Does Yarify provide regulatory advice or guarantee MDR/IVDR compliance?
No. Yarify implements software for data mapping, validation, XML generation, integration, migration and reconciliation. The manufacturer and its qualified regulatory advisers remain responsible for classification, applicability, regulatory interpretation and approval of the data submitted.
Primary sources
Reviewed 9 September 2026. EUDAMED technical artefacts and module status can change; verify the active documentation again before implementation or publication updates.
European Commission — EUDAMED overview
Official status of the six EUDAMED modules, the four modules mandatory since 28 May 2026, and the remaining modules under development
Commission Decision (EU) 2025/2371
Binding notice confirming the functionality of the Actor, UDI/Device, Notified Bodies and Certificates, and Market Surveillance electronic systems
European Commission — UDI/Device registration
Official UDI/Device module status, device-data resources, EMDN information and links for regulation and legacy devices
EUDAMED Information Centre — Guidelines on Data Exchange
Official distinction between manual UI entry, semi-automated XML upload and automatic M2M data exchange
EUDAMED Information Centre — Modes of data input
Official indicative device-volume bands for considering the UI, bulk XML upload or M2M exchange
EUDAMED Information Centre — Technical documentation
Official catalogue of DTX XSDs, XML samples, service definitions, business rules, enumerations and data dictionaries
EUDAMED Information Centre — M2M prerequisites
Official prerequisites for eDelivery, Actor and LAA setup, Party ID, module security keys and Playground onboarding