Validate EUDAMED XML beyond a green XSD result
A useful EUDAMED XML validator separates file integrity, service-schema structure, entity-schema structure, enumerations, cross-field business rules, record references and actual processing responses. Each failure must point back to the source record and the technical baseline that produced it—not end as an isolated parser message.
Find the source record behind an EUDAMED XML failure
Yarify implements validation that goes beyond well-formed XML: compatible XSDs, controlled values, dependencies, references, service semantics, and processing responses—reported in terms the responsible data owner can act on.
What the engagement produces
- A versioned validation baseline for the applicable service and entity
- Layered failures tied to XML paths, source fields, and related records
- Actionable correction reports and regression tests for future releases
“Valid” is not one yes-or-no property
The Commission states that XML must be validated against the provided DTX service and entity-model XSDs. It also publishes business rules, enumerations, service definitions and data dictionaries as separate artefacts. See the official data-exchange guidance and technical-documentation guide.
Therefore, well-formed XML can fail an XSD; XSD-valid XML can carry an unsupported controlled value; a payload that passes both can conflict with a conditional rule, reference or existing record state. Successful transport can still return mixed record outcomes.
A validator should report exactly which layer passed, failed or was not evaluated. “EUDAMED-valid” is too broad unless the statement names the artefact versions, rules covered and whether an actual processing response was reconciled.
Pre-generation
Check source identifiers, required ownership, controlled mappings, cardinality and graph relationships before XML hides the source context.
Pre-submission
Parse the file and validate the compatible service XSD, entity XSD, enumerations and locally implementable rules.
Post-submission
Correlate EUDAMED responses to each source record, separate accepted and rejected outcomes, then reconcile internal state.
Seven validation layers, each with a narrower claim
Keep the results separate. Combining them into one status makes a parser pass look equivalent to a processed and reconciled record.
| Layer | Question | Input | Detects | Does not prove | Evidence |
|---|---|---|---|---|---|
| 1 · File integrity | Can the intended bytes be reproduced and parsed? | Frozen XML file, checksum, encoding and generator run | Truncation, wrong file, malformed markup, encoding problems and unexpected generator output. | That elements follow an EUDAMED schema or that any device value is allowed. | Checksum · parser result · generation manifest |
| 2 · Service XSD | Does the message envelope match the selected service contract? | Compatible DTX service schema and intended operation | Namespace, element-order, type, cardinality and envelope-structure violations. | That the embedded device entity or operation semantics are correct. | Schema version · XPath · validator message |
| 3 · Entity-model XSD | Does the submitted entity use the supported model structure? | Compatible UDI/Device entity schema | Invalid entity elements, types, ordering and repeated-record structure. | That controlled values, conditional combinations or references will be accepted. | Entity schema version · entity key · XML path |
| 4 · Enumerations | Are limited-choice fields using current accepted values? | Applicable official enumeration baseline | Internal labels, retired values, misspellings and values from the wrong controlled list. | That the selected value is the correct regulatory decision for the device. | Mapping set · source value · target value |
| 5 · Business rules | Do fields and relationships satisfy implementable constraints? | Applicable common and module business-rule baseline | Missing conditional fields, prohibited combinations, cross-field conflicts and some relationship failures. | That every server-side rule or external-state dependency has been reproduced locally. | Rule reference · trigger fields · affected source key |
| 6 · Reference and state | Do identifiers and intended operations align with known state? | Governed master data, prior accepted results and reference snapshots | Duplicate keys, orphan relationships, unresolved references, stale versions and create/update conflicts known internally. | That EUDAMED has not changed since the last synchronized state. | Reference snapshot · prior response · reconciliation result |
| 7 · EUDAMED processing | What did EUDAMED accept, reject or return? | Actual processing response and correlation context | Server-evaluated constraints, permissions, live references, version state and record outcomes. | Regulatory correctness or that internal systems now match the accepted state. | Request / response correlation · record outcome · timestamp |
The official service-definition guide shows why validation cannot stop at entity fields: service operations also carry message-pattern, query, security, response, pagination and versioning semantics.
Error catalogue: diagnose by layer before repairing
These are failure classes, not invented EUDAMED error codes. Store the exact official response when one exists and map it to an internal diagnostic category.
| Failure | Layer | Probable cause | Detection | Suggested remediation | Likely owner |
|---|---|---|---|---|---|
| Parser cannot read the file | File integrity / XML syntax | Malformed element, unescaped character, invalid encoding or incomplete output. | Strict parser before any schema validation. | Block the file, map the location to the source value or serializer, correct the generator and reproduce the complete run. | Integration engineering |
| Namespace or root element is rejected | Service XSD | Wrong service schema, incompatible version or a hand-built envelope. | Validate against the pinned service XSD selected for the operation. | Confirm current compatibility guidance, update the generator configuration and regenerate; do not patch the XML manually. | Integration engineering |
| Element is missing, repeated or out of sequence | Entity-model XSD | Canonical cardinality or serializer ordering does not match the active entity model. | Entity XSD validation with XML path and source-key context. | Correct the canonical model or serialization rule and rerun the whole record transformation. | Data / integration engineering |
| A code is outside the accepted list | Enumeration | Unmapped local label, retired value or mapping set from another release. | Versioned lookup against the applicable enumeration. | Return the original value to its data owner, approve a target mapping and preserve the mapping decision. | Data owner with RA/QA approval |
| A field becomes required or prohibited | Cross-field business rule | A trigger value and its dependent attributes were validated independently. | Rules engine reports the trigger, dependency and source fields together. | Obtain or correct the approved source fact; never insert a convenience default to satisfy the rule. | RA/QA data owner |
| A child or referenced record cannot be resolved | Relationship / reference | Missing stable key, duplicate identifier, wrong submission order or stale master data. | Graph integrity and reference checks against the release snapshot. | Repair the source relationship, reconcile prerequisite records and regenerate only after identity is unambiguous. | Data owner and integration engineering |
| Create or update conflicts with current record state | Service operation / state | The source system has stale identifiers, version or prior-result status. | Compare the intended operation with the last accepted state and actual response. | Reconcile EUDAMED state, select the correct supported operation and preserve the superseded attempt. | Operations and integration engineering |
| File transfer succeeds but records have mixed outcomes | EUDAMED processing | Batch-level status is being mistaken for record-level acceptance. | Parse outcomes and correlate each result to the internal source key. | Lock accepted records, route rejected records by cause and build a controlled correction set instead of replaying the batch blindly. | Submission operations |
Design the error report for the person who must fix the source
Raw validator output is engineering evidence, not an operational worklist. Enrich it without changing the original message.
runId / fileHash
Identifies the exact generated artefact and validation run.
sourceSystem / sourceKey
Returns the issue to the record its owner recognises.
entity / operation
States what the generator intended to submit.
layer / artefactVersion
Separates parser, schema, enumeration, rule and response failures.
xmlPath / sourcePath
Connects the target location to workbook cell or system field.
ruleReference / message
Preserves the official or local check without inventing an error code.
offendingValue
Shows the exact source and transformed values under review.
severity / releaseGate
Makes the pass, warning or blocker effect explicit.
owner / suggestedAction
Routes technical repairs and regulatory data decisions differently.
status / resolutionEvidence
Prevents a dismissed or corrected issue from disappearing without trace.
Illustrative machine-readable finding
This is an internal report shape, not an EUDAMED response or official error code. It preserves the original message and adds source traceability and workflow fields.
{
"runId": "VAL-[internal id]",
"sourceKey": "[device source key]",
"layer": "enumeration",
"artifactVersion": "[reviewed baseline]",
"sourcePath": "Devices!R42C11",
"xmlPath": "[generated entity path]",
"originalMessage": "[exact validator text]",
"offendingValue": "[source / target value]",
"releaseGate": "block",
"owner": "regulatory-data-owner",
"status": "open"
}A validator needs a regression portfolio, not one clean sample
Re-run the suite when a schema, mapping, rule, enumeration or generator version changes. Keep synthetic fixtures free of production-sensitive data.
| Fixture | Purpose | Expected diagnostic behaviour |
|---|---|---|
| Known-good sample | Proves the selected schemas and baseline can produce a releaseable result. | No blockers; expected informational evidence only. |
| Malformed XML | Tests parser isolation before schema checks. | One syntax blocker with useful line/path context. |
| Wrong service version | Exercises namespace and compatibility controls. | Service-schema blocker, not a misleading device-field error. |
| Invalid controlled value | Tests enumeration mapping and source traceability. | Original and transformed values routed to the mapping owner. |
| Missing conditional field | Tests cross-field rules and regulatory ownership. | Trigger plus dependency shown; no generated default. |
| Orphan child record | Tests graph integrity before XML generation. | Source keys identify both the missing parent and child. |
| Mixed batch result | Tests response correlation and safe retry boundaries. | Accepted records lock; only resolved failures enter a correction set. |
Release gate
A run is releaseable only when the intended artefact versions were used, every required layer executed, no blocker remains, warnings have named owners, record counts reconcile and the readable manifest matches the file hash. Acceptance after submission is a later gate, not evidence that preflight was unnecessary.
What Yarify can implement
Versioned schema runners, controlled-list checks, rules engines, source-to-XML traceability, response parsers, exception routing, regression fixtures, release gates and reconciliation dashboards for bulk XML or M2M workflows. Coverage should be explicit: which services, entities, artefact versions and rule families are evaluated.
What validation cannot decide
A technical pass does not determine classification, applicability, identifier assignment or whether an approved product fact is true. Those decisions remain with the manufacturer and its qualified regulatory advisers. Neither XML validation nor successful submission guarantees MDR or IVDR compliance.
Put validation inside the workflow that generates and submits the data
This page owns validation layers and diagnostic design. Follow the relevant guide for source transformation, transport or portfolio operations.
Bulk XML upload
Place validation inside the complete generation, approval, upload and reconciliation process.
Open guide →Excel to XML
Map source cells and repeated spreadsheet structures before a validator sees XML.
Open guide →M2M integration
Apply validation to automated DTX exchange, asynchronous results, retries and monitoring.
Open guide →ERP integration
Trace validation failures back to governed product-data fields and source owners.
Open guide →UDI requirements
Separate technical completeness checks from manufacturer-owned regulatory decisions.
Open guide →Data migration
Use validation gates across profiling, cleansing, trial loads and portfolio reconciliation.
Open guide →Return to the EUDAMED automation hub for the complete method and implementation map.
XML validation questions
What should a EUDAMED XML validator check?
At minimum: file integrity and XML syntax, the compatible DTX service XSD, the applicable entity-model XSD, controlled enumerations, implementable business rules, internal relationships and known reference state. Actual EUDAMED responses form a separate processing layer and must be reconciled by record.
Does XSD-valid mean EUDAMED-valid?
No. The Commission publishes XSDs, business rules, enumerations, service definitions and data dictionaries as separate artefacts. XSD validation checks permitted XML structure and types; it does not by itself establish controlled-value correctness, cross-field consistency, live reference state or regulatory correctness.
Can every EUDAMED rule be checked before submission?
Do not assume so. Many published constraints can be implemented locally, but acceptance can also depend on permissions, current server state, external references, operation semantics and the active release. A validator should state which rules it covers and treat the actual processing response as its own layer.
Should a validator fix invalid XML automatically?
It can safely apply approved deterministic transformations in the generation pipeline, but it should not guess an unknown controlled value, classification, applicability decision or missing product fact. Regulatory data gaps need an accountable owner and preserved resolution evidence.
Do EUDAMED error codes stay stable across releases?
This guide does not assume they do and does not fabricate codes. Store the exact returned message, response context, service and artefact versions, then classify it internally by validation layer so operations remain understandable when technical releases change.
Does technical validation guarantee MDR or IVDR compliance?
No. Yarify can implement schemas, controlled-value checks, rules, traceability, response parsing and reconciliation. The manufacturer and its qualified regulatory advisers remain responsible for classification, applicability and the truth and approval of submitted data.
Primary sources
Reviewed 9 September 2026. The live catalogue identified platform 2.27.0 with XSD 3.0.30. Re-check the selected service, entity model, dictionaries, schemas, samples, rules, enumerations and compatibility notes before every production validation release.
EUDAMED Information Centre — Guidelines on Data Exchange
Official requirement to validate XML against the provided DTX service and entity-model XSDs, and the distinction between bulk upload and M2M
EUDAMED Information Centre — Technical-documentation guide
Official explanation of the separate roles of XSDs, XML samples, service definitions, business rules, enumerations and data dictionaries
EUDAMED Information Centre — Current technical documentation
Official download catalogue for module data dictionaries, rules, enumerations, service definitions, XSDs and XML samples; reviewed at platform 2.27.0 and XSD 3.0.30
EUDAMED Information Centre — Service definition
Official description of message patterns, operations, query criteria, security rules, responses, pagination and versioning capabilities
European Commission — UDI/Device registration
Official UDI/Device module status and links to current device datasets, EMDN information and registration guidance