Connect ERP data to EUDAMED without pretending the ERP owns every fact
EUDAMED ERP integration is an ownership and synchronization problem before it is a transport problem. A governed layer must join ERP, PIM, PLM, regulatory, quality, packaging, and market data into traceable device records; validate and approve changes; prepare bulk XML or M2M input; and reconcile every EUDAMED outcome back to internal state.
Connect the systems that own device data to one governed EUDAMED workflow
Yarify designs and implements the source adapters, canonical model, validation controls, approval boundary, submission handoff, and reconciliation needed when no single ERP, PIM, PLM, or regulatory system holds the complete record.
What the engagement produces
- A source-of-truth and ownership map for each required data domain
- Repeatable extraction, transformation, validation, and approval services
- Bulk XML or M2M handoff with accepted-state reconciliation
One device record usually crosses several systems
The official model distinguishes Basic UDI-DI, UDI-DI, and higher Package UDI-DI relationships. A Basic UDI-DI can connect to multiple UDI-DIs. Those identities do not necessarily align one-to-one with an ERP material, sellable SKU, PIM variant, PLM part, or document folder. See the device categorisation guide.
ERP often owns operational product and packaging data; PIM owns market-facing attributes; PLM owns engineering relationships; a regulatory system owns approved identifiers, classification, certificates, and market decisions. The integration must state which source wins for each field and what happens when sources disagree.
Keep EUDAMED transport downstream of that decision. The same approved canonical record can feed a manual review package, bulk XML, or M2M without embedding Access Point concerns in the ERP adapter.
Read source facts
Capture stable keys, versions, effective dates, provenance, and deletions without treating every source change as submission intent.
Build approved desired state
Resolve ownership, joins, controlled values, conditional fields, conflicts, and approval before selecting an EUDAMED operation.
Close the feedback loop
Map every processing outcome to its source record, preserve accepted versions, and expose actionable status upstream.
Source-of-truth matrix: assign authority field by field
This is an implementation blueprint, not a universal ownership assignment. Replace each likely source with the accountable system and role in your organisation.
| Data domain | Likely authoritative source | Accountable owner | Canonical rule | Downstream use | Conflict policy |
|---|---|---|---|---|---|
| Actor and organisation identifiers | Regulatory master data / EUDAMED administration record | LAA · RA operations | Reference the approved Actor identity; never infer it from sales-company or plant names. | Submission context, access control, addressing, and audit evidence | Block when the transaction company and EUDAMED Actor cannot be resolved explicitly. |
| Basic UDI-DI and product-family facts | Regulatory information system / approved technical record | RA/QA product owner | Model family identity once and link one or many UDI-DIs through stable keys. | Basic UDI-DI entity and device-family relationships | Regulatory approved record wins; surface ERP or PIM differences for correction. |
| UDI-DI and item identity | Regulatory master plus ERP/PIM cross-reference | UDI owner · master-data team | Preserve identifiers as text and maintain a governed crosswalk to sellable item or material keys. | Device record, package relationships, reconciliation key | Block duplicates, reused identifiers, or a many-to-one crosswalk without an approved model. |
| Commercial names and product attributes | PIM / ERP material master | Product master-data owner | Select the approved attribute and locale/version; do not treat every ERP description as regulatory-ready. | Applicable UDI/device attributes | Route disagreements between PIM, ERP, and approved regulatory text to a named owner. |
| Classification and regulatory attributes | Regulatory system / approved technical documentation | Qualified RA/QA decision-maker | Consume approved decisions as data; integration logic must not derive classification or applicability. | Conditional fields, controlled values, and validation rules | No default. Missing or ambiguous regulatory values block the affected record. |
| Certificates and notified-body references | Regulatory / quality document system | RA/QA certificate owner | Store structured references with effective dates and approved device relationships. | Applicable certificate references and dependency checks | Do not parse identity from filenames when a governed reference is unavailable. |
| Packaging hierarchy and quantities | ERP / packaging master / PIM | Packaging and master-data owner | Represent parent-child levels explicitly rather than package_1/package_2 columns. | Package UDI-DI child records where applicable | Block orphan, circular, duplicate, or effective-date-inconsistent package relationships. |
| Market information | ERP sales views / regulatory market approvals | Market RA owner · commercial master data | Separate commercial availability from regulatory approval and map controlled values deliberately. | Applicable market-information structures | Require the approved regulatory source when sales and regulatory scopes differ. |
| Submission and accepted state | Integration ledger populated from EUDAMED outcomes | Submission operations · integration platform | Store intended operation, correlation, payload version, response, entity outcome, and last reconciled state. | Retry decision, source-system status, audit trail, and next change | Actual EUDAMED processing outcome wins; investigate any unmapped or contradictory internal status. |
Confirm applicable target entities and attributes from the current official artefacts. The catalogue reviewed here identified platform 2.27.0 and XSD 3.0.30; source ownership should outlive either technical version.
Choose source adapters by change semantics
“Real time” is not automatically better. The adapter must prove what changed, when, under which version, and whether the change represents approved regulatory intent.
Scheduled export
- Fits when
- A stable ERP/PIM extract is available and changes can be processed in controlled windows.
- Design control
- Freeze the file, checksum it, stage records by stable keys, produce a delta, and preserve the exact source snapshot.
- Primary risk
- Late changes, row-order identity, and reprocessing the same file without idempotency.
API pull
- Fits when
- Source APIs expose authoritative records, versions, filters, and relationships predictably.
- Design control
- Use watermark or version-based extraction, pagination controls, bounded retries, and immutable raw snapshots.
- Primary risk
- Missing updates because timestamps, deletion semantics, or pagination behavior are misunderstood.
Event-driven change
- Fits when
- Product master data emits durable, ordered, replayable domain events after approval.
- Design control
- Consume events into desired state, deduplicate by event ID, join dependent domains, and wait for regulatory approval gates.
- Primary risk
- Sending partial state before all required domains or approvals have arrived.
Database change capture
- Fits when
- A supported CDC mechanism is available and the source schema contract is governed.
- Design control
- Translate low-level changes into business records, retain schema versions, and handle backfills and deletes explicitly.
- Primary risk
- Treating storage-level changes as approved business intent or coupling tightly to internal tables.
Curated regulatory workspace
- Fits when
- Required facts remain split across systems and a reviewer must resolve gaps before release.
- Design control
- Pre-fill from sources, expose provenance and differences, collect only approved overrides, and write back status—not silent master-data changes.
- Primary risk
- Creating another uncontrolled master system with values that cannot be reconciled upstream.
Nine stages from source discovery to synchronized operations
Keep source adapters, canonical rules, EUDAMED target mappings, and transport adapters independently versioned. A change in one layer should not force an uncontrolled rewrite of all four.
- 01
Discover
Inventory ERP, PIM, PLM, regulatory, quality, packaging, market, and legacy sources; document owners, keys, interfaces, and release timing.
Output · Source-system and ownership map
- 02
Profile
Measure completeness, duplicates, type drift, conflicting values, relationship gaps, change history, and extract reproducibility.
Output · Data-quality baseline and exception taxonomy
- 03
Model
Define transport-neutral canonical entities for Actors, Basic UDI-DI groups, devices, packages, references, markets, approvals, and submission state.
Output · Canonical device model and stable key strategy
- 04
Map
Assign each canonical field an authoritative source, owner, transformation, controlled-value set, dependency, null policy, and target meaning.
Output · Versioned field and ownership specification
- 05
Extract and detect change
Implement the selected batch, API, event, or CDC adapters and produce reproducible snapshots plus meaningful desired-state deltas.
Output · Idempotent source ingestion and change ledger
- 06
Validate and approve
Run source, relationship, controlled-value, conditional, and target-contract checks; route regulatory data decisions to accountable reviewers.
Output · Releaseable records and owned exception queue
- 07
Prepare submission
Generate reviewable bulk XML packages or hand approved desired state to the M2M service adapter, preserving operation and correlation context.
Output · Transport-specific payload and release manifest
- 08
Reconcile
Parse processing outcomes by record, lock accepted versions, route rejections, and update a submission ledger before any retry.
Output · Confirmed EUDAMED state and correction worklist
- 09
Synchronize and operate
Expose accepted and exception status to source owners, monitor lag and failures, manage version changes, and preserve the full audit trail.
Output · Measured operating service and support runbook
Transport stays replaceable
Official guidance separates semi-automated XML upload from automatic M2M backend exchange. Build both behind the approved desired-state boundary. Bulk XML retains a manual upload; M2M adds eDelivery, AP, security, onboarding, and automated message operations. See data-exchange guidance.
A synchronization state model prevents blind retries
One “sent” flag cannot describe source observation, regulatory approval, transport, EUDAMED processing, or internal reconciliation.
| State | Meaning | Allowed next action | Guardrail |
|---|---|---|---|
| Observed | A source snapshot or change has been captured with its version and provenance. | Normalize or supersede before processing | No EUDAMED intent exists yet. |
| Normalized | Source values resolve into the canonical model with stable relationships. | Validate or return source-structure exceptions | Normalization does not imply regulatory approval. |
| Needs decision | A missing, conflicting, or conditional fact requires an accountable owner. | Resolve with evidence or explicitly withdraw | No guessed defaults and no silent source precedence. |
| Approved desired state | The intended device data and operation are approved for a defined baseline. | Generate and release a payload | Any relevant source change invalidates or reopens approval. |
| Submitted / processing | The payload crossed the bulk or M2M boundary and awaits definitive entity outcomes. | Correlate response; do not assume acceptance | Transport success is not record acceptance. |
| Accepted | The EUDAMED outcome confirms the intended record operation was accepted. | Reconcile source status and monitor later changes | Store the accepted version, response evidence, and timestamp. |
| Rejected / exception | A technical, data, permission, reference, or state problem prevented the intended outcome. | Classify, resolve, reapprove where needed, and create a controlled retry | Never overwrite or blindly replay the failed attempt. |
System examples without a fictional universal connector
SAP, Dynamics, Odoo, PIM, PLM, and custom systems can all provide data. Their actual interfaces and ownership models must be discovered in the deployed version and configuration.
SAP or Dynamics ERP
Material/item identity, organisation views, commercial attributes, packaging, and operational effective dates.
Adapter · Use supported APIs, events, middleware, or governed extracts available in the actual product/version and deployment.
Caveat · An ERP item is not automatically one EUDAMED device, and an ERP company is not automatically the submitting Actor.
Odoo or custom ERP
Product records, internal codes, packaging, commercial status, and custom regulatory extensions.
Adapter · Prefer stable APIs or versioned exports; isolate custom fields behind a source adapter and contract tests.
Caveat · Custom modules vary by installation, so a universal EUDAMED connector cannot assume one schema.
PIM / PLM
Product descriptions, structured attributes, variants, engineering relationships, and lifecycle data.
Adapter · Extract approved versions and preserve locale, revision, variant, and relationship context.
Caveat · Engineering or marketing approval is not necessarily regulatory approval for submission.
Regulatory information system
Basic UDI-DI, UDI-DI governance, classification, certificates, market decisions, and approved regulatory attributes.
Adapter · Consume approved structured facts with decision evidence and effective state; avoid scraping rendered documents.
Caveat · The integration transports decisions but does not replace qualified regulatory judgement.
Acceptance criteria for a useful first integration
Pilot a representative product family with package relationships, conflicting sources, a controlled-value mapping, a rejection, and a corrected resubmission—not only a clean happy path.
- 01
Every canonical field has one explicit authoritative-source rule, accountable owner, and conflict policy.
- 02
Actor, Basic UDI-DI, UDI-DI, package, and internal item identities use stable crosswalks rather than display-name matching.
- 03
A source snapshot and change can be replayed without producing a duplicate intended operation.
- 04
Regulatory values are consumed only after approval; the integration never derives classification or applicability.
- 05
Controlled values and target contracts are versioned independently from source-system adapters.
- 06
Bulk XML and M2M are replaceable transport strategies downstream of the same canonical desired state.
- 07
Every response maps to the intended source record and updates accepted state only after entity-level reconciliation.
- 08
Operators can distinguish source, mapping, validation, transport, permission, processing, and reconciliation failures.
What Yarify can implement
Source adapters, identity crosswalks, canonical device services, versioned mappings, approval workflows, controlled-value management, validation, bulk XML/M2M handoff, response parsing, status APIs, exception worklists, reconciliation ledgers, dashboards, and runbooks.
What remains regulatory
The manufacturer and qualified regulatory advisers decide classification, applicability, identifier assignment, source approval, and whether product facts are correct. Yarify implements the technical flow; system integration or successful submission does not guarantee MDR or IVDR compliance.
Continue with the transport or data workflow you need
This page owns internal source-system design and synchronization. These guides own M2M transport, bulk upload, deep validation, spreadsheet conversion, or initial migration.
M2M integration
Implement DTX service messaging, eDelivery/AS4, Access Point onboarding, security keys, and automated response operations.
Open guide →Bulk XML upload
Use a controlled semi-automated release when generated ERP data does not need unattended transport.
Open guide →XML validator
Separate source, schema, enumeration, business-rule, reference, and processing-response failures.
Open guide →Excel to XML
Handle governed spreadsheet sources and tabular-to-hierarchical transformations within the same canonical model.
Open guide →Data migration
Run initial multi-source discovery, cleansing, exception management, submission, and reconciliation as a bounded programme.
Open guide →UDI registration automation
Choose the broader automation level and operating model for recurring device registrations.
Open guide →Return to the EUDAMED automation hub for the complete implementation map.
ERP integration questions
Can an ERP connect directly to EUDAMED?
An ERP can be a source, but a dependable implementation usually needs a canonical device-data and control layer between the ERP and EUDAMED. It resolves Actor and device identities, joins regulatory and product data, maps controlled values, enforces approval, generates bulk XML or M2M input, and reconciles outcomes. Direct point-to-point mapping tends to embed EUDAMED versions and regulatory assumptions inside the ERP adapter.
Is ERP integration the same as EUDAMED M2M?
No. ERP integration owns source extraction, master-data identity, field ownership, approvals, change detection, and returning status. M2M owns automatic EUDAMED transport, Access Point and AS4 connectivity, onboarding, security, messages, and asynchronous processing. An ERP integration can feed either bulk XML or M2M.
Which system should be the source of truth?
There is rarely one answer for the whole dataset. ERP may own item and packaging data, PIM commercial attributes, PLM engineering relationships, and a regulatory system classification, identifiers, certificates, and market decisions. Define authority field by field, with an accountable owner and conflict policy, then build a canonical record from those approved sources.
Is there a universal SAP, Dynamics, or Odoo EUDAMED connector?
A reusable adapter may accelerate extraction, but deployments, modules, custom fields, approval processes, identifiers, and source ownership differ. The official EUDAMED data artefacts are also versioned. Treat vendor examples as integration patterns, not proof that one connector can understand every source model or regulatory decision.
Should EUDAMED responses be written back to the ERP?
Expose useful accepted, pending, and exception status to the people operating the product record, but keep the full request/response and reconciliation ledger in the integration domain. A write-back must not overwrite authoritative product facts or reduce a mixed record outcome to one batch flag.
Does EUDAMED ERP integration guarantee MDR or IVDR compliance?
No. Yarify can implement source adapters, mappings, validation, workflow, XML generation, transport integration, and reconciliation. The manufacturer and qualified regulatory advisers remain responsible for classification, applicability, identifier assignment, and approval of the submitted facts.
Primary sources
Reviewed 9 September 2026. The current catalogue identified platform 2.27.0 and XSD 3.0.30. Data dictionaries, schemas, rules, enumerations, service definitions, source-system APIs, and ownership can all change; version each boundary and revalidate it before production release.
European Commission — UDI/Device registration
Official module status, MDR/IVDR and legacy-device dataset resources, EMDN information, and current registration guidance
EUDAMED Information Centre — Categorisation of devices
Official model concepts for Basic UDI-DI, UDI-DI, Package UDI-DI, legacy identifiers, and their relationships
EUDAMED Information Centre — Technical-documentation guide
Official explanation of the roles of XSDs, XML samples, service definitions, business rules, enumerations, and data dictionaries
EUDAMED Information Centre — Current technical documentation
Official catalogue of current module data dictionaries, rules, enumerations, service definitions, XSDs, XML samples, and version compatibility
EUDAMED Information Centre — Guidelines on Data Exchange
Official distinction between manual UI entry, semi-automated XML upload, and automatic M2M exchange, including backend-readiness considerations
EUDAMED Information Centre — M2M prerequisites
Official administrative, Access Point, security-key, and Playground prerequisites for automatic backend exchange