Build EUDAMED M2M as an operated data service—not a one-way connector
EUDAMED M2M automates XML exchange between an organisation backend and EUDAMED through eDelivery Access Points and AS4. The implementation still needs governed device data, versioned services, layered validation, Playground and Production onboarding, protected module keys, asynchronous outcome handling, controlled retries, and record-level reconciliation.
Implement EUDAMED M2M as an operated service, not a transport demo
Yarify connects governed device data to the DTX workflow across XML services, Access Point integration, Playground onboarding, message correlation, retries, monitoring, and accepted-state reconciliation.
What the engagement produces
- A readiness and architecture boundary covering data, transport, and ownership
- Implemented message generation, AP integration, response handling, and retries
- Production monitoring, exception workflows, reconciliation, and runbooks
M2M removes manual transport, not data ownership
The official architecture describes automatic exchange between an external backend and EUDAMED. The external system converts data to supported XML, while an eDelivery Access Point uses secure AS4-compliant communication with the EUDAMED Access Point. See the M2M architecture.
That transport does not resolve inconsistent product data or decide missing regulatory facts. RA/QA and product-data owners still approve what should be sent. Engineering owns deterministic mapping, service messages, validation, correlation, observability, and safe reconciliation.
The Commission suggests M2M above 1,000 devices, bulk XML for 100–1,000, and UI entry up to 100. These are indicative tips, not legal thresholds. Frequency, change volume, backend readiness, failure handling, security, and support cost can outweigh the portfolio count. See modes of data input.
Strong fit
High or frequent exchange, stable product-data ownership, a capable backend, repeatable approvals, and a team prepared to operate integration infrastructure.
Weak fit
Low-change portfolios, unresolved source quality, no operational owner, or an expectation that an AP product is the complete data solution.
Prove first
One bounded service, representative data, deterministic XML, failure scenarios, reconciled outcomes, and a runbook accepted by both IT and RA operations.
Readiness is administrative, technical, and operational
Official prerequisites are entry conditions. A reliable production service also needs source-data and operating readiness that can be tested before cutover.
| Readiness area | Ready when | Evidence | Accountable roles |
|---|---|---|---|
| Business justification | Volume, frequency, available resources, database readiness, services, and expected load explain why the AP investment is proportionate. | Playground business-justification document and internal approval | Programme sponsor · RA operations · IT |
| Actor administration | The organisation is an EUDAMED Actor and an active LAA can request and administer Access Point links. | Actor context · LAA ownership · environment-specific access | Local Actor Administrator |
| Access Point strategy | The organisation has chosen an owned or third-party eDelivery-compatible AP and identified its Party ID and support boundary. | Architecture decision · provider agreement where applicable | Enterprise architecture · security · procurement |
| Device-data backend | Approved device data can be assembled into stable canonical records with ownership, change detection, and correlation keys. | Source matrix · data model · mapping · quality baseline | Product data · RA/QA · integration engineering |
| Technical contract | Selected services, operations, compatible XSDs, enumerations, rules, samples, and version behavior are pinned for the release. | Versioned implementation baseline | Integration engineering |
| Operations | Monitoring, acknowledgements, responses, retries, key rotation, incident handling, reconciliation, and audit retention have named owners. | Runbook · alerts · dashboards · support RACI | Platform operations · RA operations |
The official prerequisites require the eDelivery-compatible product or service, Actor, LAA, Party ID, per-module keys, and completed Playground path. Do not schedule Production around an unapproved AP request.
Own the Access Point or use a third party?
The official request flows support both. Choose by control, capability, support model, contractual risk, and total operations—not by a connector demo alone.
A provider-owned or existing AP requires a signed third-party agreement for each environment request. The document confirms the provider relationship; it is not a general endorsement. See the new AP and existing AP workflows.
Whichever model you choose, the Actor needs a clear boundary between provider AP operation, internal backend behavior, security keys, response delivery, incident diagnosis, data ownership, and regulatory approval.
| Decision factor | Owned Access Point | Third-party Access Point |
|---|---|---|
| Infrastructure ownership | Your organisation installs, configures, secures, patches, monitors, and supports the AP. | The provider owns the AP infrastructure; your organisation still owns its EUDAMED Actor obligations and backend integration. |
| EUDAMED request | Request a new AP and identify your organisation as owner. | Request a new provider-owned AP or link to an existing AP using its Party ID, according to the applicable workflow. |
| Agreement evidence | No third-party agreement for AP ownership, but internal legal and operational approval still applies. | A signed third-party agreement is required for each Playground and Production AP access/link request. |
| Technical contact | A technical contact from your organisation manages AP setup and issues. | Official guidance says the technical contact belongs to the organisation that owns the AP. |
| Control and effort | More infrastructure control, paired with direct responsibility for eDelivery and AS4 operation. | Less AP infrastructure to operate internally, paired with provider dependency, service levels, access, and exit planning. |
| Approval claim | Conformance and onboarding still need to be demonstrated. | The official agreement route permits third-party provision; it does not make an unsupported claim that a named vendor is Commission-approved. |
A ten-stage path from justification to operated Production service
Playground is where connectivity and service behavior become test evidence. Production is a separate environment and approval path, not a configuration toggle.
- 01
Confirm fit and scope
Estimate records, update frequency, services, peak load, response volume, latency needs, internal capability, and total operating cost.
Exit evidence · Approved M2M business case and bounded first service
- 02
Establish Actor and LAA readiness
Confirm Actor context, accountable LAA, environment access, legal contact, technical contact, and decision rights.
Exit evidence · Named administrative owners with working access
- 03
Choose the AP model
Select owned versus third-party Access Point, validate eDelivery/AS4 fit, define Party ID ownership, support, security, and contractual boundaries.
Exit evidence · Architecture record and provider evidence
- 04
Build the canonical device service
Extract approved data from ERP, PIM, PLM, spreadsheets, or databases; model device relationships; track changes and approvals.
Exit evidence · Traceable, transport-neutral canonical records
- 05
Implement EUDAMED services
Map selected operations, generate versioned XML, include required addressing and security context, and preserve correlation identifiers.
Exit evidence · Deterministic messages for the selected service baseline
- 06
Validate before transport
Check file integrity, service XSD, entity XSD, enumerations, implementable business rules, references, and intended record state.
Exit evidence · No unresolved release blockers and readable manifest
- 07
Request and configure Playground
Submit the business justification and AP request, complete technical onboarding, configure connectivity, activate the AP, and generate service keys.
Exit evidence · Active Playground AP and protected configuration
- 08
Execute controlled scenarios
Test supported operations, acknowledgements, responses, duplicate prevention, invalid messages, timeouts, retries, partial failure, and reconciliation.
Exit evidence · Signed test evidence and operationally accepted runbook
- 09
Onboard Production
Use successful Playground evidence for the Production request, complete environment-specific agreement/configuration work, and generate Production keys only after activation.
Exit evidence · Active Production AP with separated secrets and endpoints
- 10
Operate and reconcile
Correlate messages and outcomes, monitor queues, classify failures, control retries, reconcile accepted state, rotate keys, and manage technical releases.
Exit evidence · Auditable service ownership and measurable data consistency
Activation and key sequencing matters
The official configuration flow says the AP becomes active after the technical-onboarding steps are completed, and keys can be generated only after activation. Keys are module-specific and are not viewable again after their generation dialog closes. See AP configuration and security-key guidance.
Reference architecture with explicit ownership boundaries
ERP / PIM / PLM → canonical device service → validation and XML adapter → DTX connector → organisation AP / AS4 → EUDAMED AP and backend → acknowledgements and responses → reconciliation.
Source systems
ERP, PIM, PLM, regulatory systems, or databases provide approved facts and stable change events.
Boundary · They should not construct transport envelopes or store raw AP secrets.
Canonical device service
Joins source facts, models Basic UDI-DI/UDI-DI and child relationships, tracks provenance, approvals, and desired state.
Boundary · It remains independent of one EUDAMED service or XSD release.
Validation and XML adapter
Maps current EUDAMED entities and operations, generates XML, runs layered preflight, and creates correlation metadata.
Boundary · It cannot make regulatory decisions or prove live server state.
DTX connector
Builds and interprets supported message patterns, service metadata, addressing, encoded payloads, acknowledgements, and reports.
Boundary · It owns EUDAMED protocol semantics, not business master-data ownership.
Organisation Access Point
Sends and receives through the eDelivery/AS4 boundary using the configured Party ID and environment-specific connectivity.
Boundary · Owned internally or by a third party; provider responsibility must be explicit.
EUDAMED AP and backend
Receives exchanges, applies security/access controls, processes service requests, and constructs acknowledgements or responses.
Boundary · Its actual response is authoritative for processing outcome, not for regulatory compliance.
Reconciliation and operations
Correlates each outcome to the source record, routes exceptions, updates accepted state, monitors queues, and preserves evidence.
Boundary · A transport success never closes a record without outcome reconciliation.
Model exchange as a state machine
The official message guide covers Push, PullRequest, PullResponse, and Acknowledge patterns, service metadata, addressing, and reports. Your internal state must distinguish each step.
Official guidance states that SOAP is used for data exchange, the entire XML message is base64 encoded in the payload, and messages carry service and node addressing information. It also requires the current XSD version in XML messages. See message exchange.
Do not copy example element names or version values into a permanent connector. Generate from the selected current service definition and compatible technical package.
| Lifecycle event | State recorded | Control | Alert condition |
|---|---|---|---|
| Change approved | Desired state recorded against a stable source key | Idempotency key and change version prevent duplicate intent. | Missing owner, ambiguous relationship, or unapproved value |
| Message generated | Payload, operation, service/schema versions, and correlation are frozen | Hash and manifest make the message reproducible. | Validation blocker or incompatible artefact baseline |
| AP accepts transfer | Transport evidence exists; business processing is still pending | Do not mark the device record accepted at this stage. | AS4/connectivity failure, security rejection, or timeout |
| Acknowledgement / report arrives | Message-level result is correlated to the request | Distinguish receipt, processing state, and entity outcomes. | Unknown correlation, duplicate report, or missing expected response |
| Entity outcomes parsed | Accepted and rejected records have distinct next actions | Lock accepted versions; retry only after classifying and resolving failures. | Mixed outcome hidden behind a batch-level status |
| Internal state reconciled | Source system records match the latest confirmed EUDAMED outcome | Preserve every prior attempt and resolution decision. | Accepted EUDAMED state cannot be mapped to one internal record |
Production begins after connectivity works
The durable work is keeping data, messages, keys, technical versions, queues, and accepted state aligned through changes and failures.
- 01
Separate Playground and Production endpoints, Party IDs, configuration, secrets, queues, and evidence.
- 02
Store module-specific security keys in a managed secret store; restrict retrieval, log use, and document regeneration.
- 03
Pin service and XSD compatibility per release and reject messages built with an unintended version.
- 04
Correlate transport, acknowledgement, report, entity outcome, source key, and intended operation end to end.
- 05
Make retries idempotent and reason-specific; never replay an uncertain batch merely because a timer expired.
- 06
Alert separately on connectivity, security, schema, rule, state, response-latency, and reconciliation failures.
- 07
Define maintenance, incident, provider-escalation, and EUDAMED-support paths before Production cutover.
- 08
Measure backlog age, processing outcome, exception ownership, retry count, reconciliation lag, and release version adoption.
What Yarify can implement
Source adapters, canonical data services, EUDAMED XML generators, layered validators, connector orchestration, AP/provider integration, correlation stores, response parsers, idempotent retries, dashboards, exception workflows, reconciliation, and operational runbooks.
What remains accountable human work
The manufacturer and qualified regulatory advisers decide classification, applicability, identifier assignment, and whether product facts are correct and approved. Yarify provides technical implementation, not regulatory advice. Automated exchange and successful processing do not guarantee MDR or IVDR compliance.
Continue with the layer around M2M transport
This page owns EUDAMED transport, onboarding, and operations. Use the related guide for source systems, deep validation, method selection, or migration.
ERP integration
Design source ownership, extraction, change detection, approvals, and status synchronization upstream of M2M transport.
Open guide →XML validator
Implement service/entity XSD, enumeration, business-rule, reference, and response validation as distinct layers.
Open guide →Manual vs XML vs M2M
Check whether full M2M is proportionate before committing to Access Point and operating responsibilities.
Open guide →Data migration
Prepare a legacy portfolio and reconcile initial submissions before treating M2M as routine synchronization.
Open guide →UDI requirements
Inventory approved identifiers, device attributes, relationships, and conditional data before automation.
Open guide →UDI registration automation
Compare M2M with lower automation levels and plan the wider operating model for recurring registrations.
Open guide →Return to the EUDAMED automation hub for the complete decision map.
M2M integration questions
What is required for EUDAMED M2M integration?
Official prerequisites include an eDelivery-compatible product or service, EUDAMED Actor registration, an active LAA, the Access Point Party ID, a security key for each module used, and successful Playground onboarding before Production. A production implementation also needs a capable data backend, current XML contracts, response handling, monitoring, retries, and reconciliation.
Does EUDAMED M2M use AS4?
The official architecture describes a dedicated CEF eDelivery Access Point and secure AS4-compliant communication between the organisation AP and EUDAMED AP. The internal application still needs a connector that handles EUDAMED service and entity data, message correlation, and processing outcomes.
Can a third party provide the Access Point?
Yes. Official onboarding supports provider-owned or existing Access Points and requires a signed third-party agreement for each Playground and Production access/link request. That process supports third-party provision; it does not justify describing an arbitrary named provider as Commission-approved.
When is M2M better than bulk XML upload?
M2M is worth evaluating when volume, update frequency, backend readiness, and the need for automatic exchange justify its infrastructure and support cost. The Commission gives an indicative tip of M2M above 1,000 devices, but that is not a legal threshold. Bulk XML can remain proportionate for periodic batches because only the file transmission stays manual.
Does Playground testing automatically enable Production?
No. Successful Playground onboarding and testing are prerequisites to the Production path, but Production requires its own request and environment-specific configuration and evidence. Secrets, Party IDs, endpoints, queues, and test data should remain separated.
Does a successful M2M exchange guarantee MDR or IVDR compliance?
No. Yarify can implement extraction, mapping, XML validation, messaging, monitoring, and reconciliation. The manufacturer and its qualified regulatory advisers remain responsible for classification, applicability, identifier assignment, and approval of submitted facts. Transport or technical acceptance is not a compliance guarantee.
Primary sources
Reviewed 9 September 2026. EUDAMED environments, help releases, service definitions, XSDs, rules, enumerations, onboarding steps, and security procedures can change. Confirm the live Production and Playground guidance before each implementation release or onboarding action.
EUDAMED Information Centre — M2M prerequisites
Official prerequisites for eDelivery-compatible infrastructure, Actor and LAA setup, Party ID, module security keys, Playground onboarding, and Production access
EUDAMED Playground — M2M data-exchange architecture
Official architecture for external backends, eDelivery Access Points, AS4 communication, EUDAMED services, acknowledgements, and responses
EUDAMED Playground — Request a new Access Point
Official workflow for owned or third-party AP requests, business justification, contacts, service selection, Party ID, and connectivity validation
EUDAMED Playground — Request an existing Access Point
Official workflow for linking an Actor to an existing AP using its Party ID and a signed third-party agreement
EUDAMED Playground — Configure an Access Point
Official technical-onboarding handoff and the condition that an AP becomes usable only after activation
EUDAMED Information Centre — Generate a security key
Official module-specific security-key lifecycle and its use with the sender SRN in EUDAMED security checks
EUDAMED Playground — Message exchange
Official SOAP and encoded XML message structure, Push/Pull/Acknowledge patterns, service access token, node addressing, and schema-version requirement
EUDAMED Information Centre — Service definition
Official scope of service operations, message types, query criteria, security, responses, pagination, and versioning
EUDAMED Information Centre — Current technical documentation
Official catalogue of data dictionaries, rules, enumerations, service definitions, XSDs, samples, onboarding, and third-party templates
EUDAMED Information Centre — Modes of data input
Official indicative portfolio-size guidance for choosing UI, bulk XML, or M2M data exchange