Convert Excel to EUDAMED XML without flattening the device model
Excel and CSV can supply EUDAMED device data, but dependable conversion is not a direct row-to-tag export. The workflow must preserve identifiers as text, model Basic UDI-DI and UDI-DI relationships, expand repeated records, map approved controlled values, expose conditional gaps and validate the result against the current technical baseline.
Need working EUDAMED XML from your actual workbook?
Yarify turns a representative Excel or CSV export into a governed conversion workflow. We map the real source fields, preserve device relationships, route unresolved values to owners, generate the applicable XML, and provide evidence a reviewer can follow.
What the engagement produces
- A source profile and approved field-by-field mapping specification
- A repeatable converter with explicit controlled-value and relationship rules
- Generated XML, layered validation results, and a traceability manifest
A spreadsheet is a source interface, not the EUDAMED data model
Official EUDAMED material treats the Basic UDI-DI as a product-family access key and the UDI-DI as the identifier of a specific device. A Basic UDI-DI references at least one UDI-DI, and multiple UDI-DIs can share the same Basic UDI-DI. Higher package identifiers may add more child relationships. See the official device categorisation guide.
A single workbook row rarely expresses that graph cleanly. Teams often repeat family data on every row, encode packages in numbered columns, combine values in one cell or rely on row order as identity. Direct serialization preserves those ambiguities instead of resolving them.
The useful intermediate layer is a canonical device dataset: stable keys, explicit parent-child relationships, versioned value maps and field-level provenance. Only approved, internally consistent records move from that layer to XML.
Workbook evidence
Preserve sheet, row, column, cell value, workbook version and source owner. Formula results without their frozen values are not a reproducible release input.
Canonical records
Resolve identifiers, families, devices and child collections before generation. Unknown values remain visible exceptions, never empty tags or guessed defaults.
Versioned XML
Generate the compatible service and entity structure from releaseable records, then validate each technical layer and package the results for review and upload.
A workbook shape that makes relationships reviewable
This is an internal conversion pattern, not an official EUDAMED template. Confirm every target field, cardinality and dependency against the current data dictionary, XSD, enumerations and business rules.
| Sheet / table | Record grain | Stable joins | Why it exists |
|---|---|---|---|
| Devices | One row per internal device / UDI-DI source record | device_source_key · basic_group_key · source version | Holds scalar source values and stable joins, without repeating child collections in numbered columns. |
| Basic UDI-DI groups | One row per approved product-family identifier | basic_group_key · Basic UDI-DI | Separates family-level facts from device-level facts and supports many UDI-DIs under one Basic UDI-DI. |
| Packages | One row per device and package level | device_source_key · package_source_key · parent key | Represents a repeatable package hierarchy instead of package_1, package_2 and package_3 columns. |
| Markets / references | One row per device and related market or reference record | device_source_key · relation type · relation key | Preserves one-to-many relationships and makes duplicates or orphaned references visible before XML generation. |
| Controlled-value maps | One row per source system, source value and target code | mapping set · source value · effective version | Makes local-to-EUDAMED translations reviewable and prevents an unknown label from being silently guessed. |
| Exceptions | One row per failed source field, relationship or rule | run id · source key · field / rule | Returns actionable errors to data owners while preserving the original workbook value and transformation evidence. |
The test: can a row be identified after it moves?
Sorting, filtering, inserting a row or renaming a product must not change identity. Assign durable source keys and use them across devices, family groups and child sheets. Row number and display name are useful reviewer context, but they are weak database keys.
Field mapping is the conversion contract
The Commission publishes data dictionaries separately from XSDs, rules and enumerations. That separation matters: a mapping must capture business meaning, XML structure, controlled values and dependencies rather than one target column name. See the official artefact guide.
Mapping decisions to version
- Source workbook, sheet and cell path
- Canonical entity and attribute
- Target entity / attribute meaning
- Data type and cardinality
- Transformation and null handling
- Controlled-value mapping set
- Cross-field and relationship dependencies
- Owner, approval and validation outcome
| Spreadsheet source | Canonical field | EUDAMED concept | Transformation | Controlled value | Dependency / boundary | Validation result |
|---|---|---|---|---|---|---|
| product_family_id | basicUdiGroup.sourceKey | Basic UDI-DI entity relationship | Join the device row to one approved family record; never derive the identifier from a product-name match. | Not applicable | Every regulation-device record must resolve to the intended Basic UDI-DI group. | PASS / ORPHAN GROUP / DUPLICATE KEY |
| basic_udi_di | basicUdiGroup.identifier | Basic UDI-DI identifier | Trim presentation whitespace only, retain the original value, and validate with the selected issuing-entity context. | Issuing-entity context is governed separately | Must be approved by the manufacturer; software must not manufacture a missing regulatory identifier. | PASS / MISSING / FORMAT REVIEW |
| udi_di | device.identifier | UDI-DI identifier | Preserve leading characters and treat the value as an identifier, not a spreadsheet number. | Not a free-text normalization target | Must remain linked to its Basic UDI-DI record and be unique in the staged dataset. | PASS / DUPLICATE / FAMILY LINK MISSING |
| emdn_label + emdn_code | device.emdnCode | EMDN field selected from the active dictionary | Use the approved code as the submitted value; retain the workbook label for reviewer context and detect code/label disagreement. | Compare with the current EMDN source used by the project | Selection and regulatory suitability remain with the manufacturer or qualified adviser. | PASS / UNKNOWN CODE / LABEL CONFLICT |
| risk_class_local | device.regulatoryClass | Applicable device classification attribute | Translate only through an approved, versioned lookup; send an unmapped or ambiguous value to regulatory ownership. | Map local label to the active enumeration | Can activate other conditional data requirements; conversion does not decide classification. | PASS / UNMAPPED / OWNER REVIEW |
| package_rows | device.packages[] | Package identifier relationship | Join child rows by stable keys, order the hierarchy deterministically, and reject missing or circular parents. | Map any applicable package-level codes separately | The official model allows higher package identifiers where applicable; cardinality comes from the active XSD and dictionary. | PASS / ORPHAN / CYCLE / DUPLICATE |
| market_columns or market_rows | device.marketRecords[] | Applicable market-information structure | Unpivot repeated columns or join child rows into distinct records, retaining the source cell for traceability. | Normalize country or market values with a reviewed lookup | Required fields and allowed combinations must come from the current target artefacts. | PASS / UNKNOWN VALUE / INCOMPLETE CHILD |
| certificate_reference | device.certificateRefs[] | Certificate relationship where applicable | Split only by an agreed source convention, normalize reference formatting without changing identity, and resolve against governed reference data. | Relationship type may require a controlled mapping | Applicability is a regulatory decision; unresolved references must block release rather than be omitted silently. | PASS / UNRESOLVED / APPLICABILITY REVIEW |
These rows demonstrate mapping disciplines, not current XML element names. For production, select the applicable UDI/Device dataset and download the live artefacts from the official technical-documentation catalogue. At review time, the catalogue identified platform 2.27.0 and XSD 3.0.30; both are mutable release information.
Four transformations a converter must make explicit
A useful converter documents how a source value changed and why. It does not hide interpretation inside a cell formula or a one-off script.
Split a combined cell without losing provenance
- Workbook pattern
- "ABC-001 | Acme family | rev 4"
- Canonical result
- identifier = ABC-001 · family label = Acme family · source revision = 4
- Required control
- Define the delimiter contract, reject extra or missing segments, and retain the original cell beside the parsed values. Do not infer meaning from column position alone.
Map a local label to a controlled value
- Workbook pattern
- risk_class_local = "Class II A"
- Canonical result
- regulatoryClass = [approved current target code]
- Required control
- The mapping is versioned and approved. Unknown spelling, punctuation or source-system values become exceptions; the converter does not choose the regulatory class.
Turn repeated columns into child records
- Workbook pattern
- package_1_id · package_1_qty · package_2_id · package_2_qty
- Canonical result
- packages[] = [{ sourceKey, parentKey, identifier, quantity }, …]
- Required control
- Validate stable keys, positive quantities, uniqueness and parent-child relationships before target serialization. The example is conceptual, not EUDAMED XML syntax.
Detect conditional gaps before XML exists
- Workbook pattern
- A triggering approved attribute is present; its dependent source field is blank
- Canonical result
- exception = { trigger, missingField, sourceKey, owner, severity }
- Required control
- Implement the dependency from the reviewed business-rule baseline and show the reviewer why the value is needed. Never fill a regulatory fact with a default.
From workbook to controlled XML package
Generation happens late. Profiling, specification and normalization prevent source-data problems from becoming opaque XML errors.
| Stage | Input | Engineering action | Evidence |
|---|---|---|---|
| Profile | Representative Excel / CSV export | Measure blanks, duplicates, type drift, formula cells, merged values, unstable identifiers and repeated-column patterns. | Source profile and risk register |
| Specify | Current official artefacts plus approved business meaning | Define field ownership, target entity, cardinality, transformation, controlled-value map, dependencies and acceptance result. | Versioned mapping specification |
| Stage | Frozen workbook and mapping version | Read cells as source evidence, preserve identifiers as text, join child tables and produce a normalized canonical dataset. | Reproducible staged records |
| Transform | Canonical source values | Apply deterministic parsing, formatting and approved lookup rules while recording input, output and rule version. | Field-level transformation log |
| Preflight | Transformed canonical dataset | Check identifiers, joins, cardinality, controlled values, completeness and pre-implementable cross-field dependencies. | Owner-routed exception report |
| Generate | Approved, releaseable records | Serialize the selected service and entity structure using the compatible current XSD baseline. | XML plus generation manifest |
| Validate | Generated XML | Run XML syntax, XSD, enumeration and applicable business-rule checks as distinct layers. | Layered validation report |
| Handover | Validated XML and approved run | Package the file, readable record manifest, artefact versions and unresolved non-blocking notes for the upload owner. | Controlled bulk-upload package |
Conversion stops here
A validated file and its traceability package are the output. The authenticated bulk upload and processing lifecycle belong to the bulk XML workflow.
Validation is layered
XML syntax and XSD checks do not replace enumeration, dependency, relationship or existing-state checks. The validator guide owns that deeper problem.
M2M is a separate decision
The same normalized data can later feed M2M, but automatic transport adds Access Point, security, onboarding and operational responsibilities beyond spreadsheet conversion.
Acceptance criteria for a conversion pilot
Start with a representative sample that includes repeated structures, awkward values and known gaps—not only the cleanest ten rows.
- 01Every generated record resolves to one stable source key and frozen workbook version.
- 02Every submitted value is traceable to a source cell, approved lookup or documented transformation rule.
- 03Identifiers are preserved as text, including leading characters and significant formatting.
- 04One-to-many data is represented as explicit child records with valid, non-circular relationships.
- 05Unknown controlled values and unresolved conditional fields are blocked or explicitly owned; none are silently defaulted.
- 06The generated file passes XML syntax and the compatible active XSDs, with semantic checks reported separately.
- 07The run records the data dictionary, mapping, enumeration, business-rule, service and XSD baselines used.
- 08A reviewer can compare source facts, transformed values and intended records without reading raw XML.
What Yarify can implement
Workbook profilers, repeatable import pipelines, canonical device models, mapping workbenches, approved lookup tables, dependency checks, XML serializers, validation reports and reviewer-facing traceability manifests. A pilot should use a representative, suitably protected export and named data owners for unresolved values.
What remains regulatory
Device classification, regulatory applicability, identifier assignment, the correctness of product facts and approval to submit remain with the manufacturer and its qualified regulatory advisers. Software can flag a missing or inconsistent value; it cannot make that judgement or guarantee MDR or IVDR compliance.
Continue with the workflow stage you actually own
This page owns tabular-to-hierarchical transformation. Use the deeper guides for submission, validation, requirements, ongoing integration or a full migration programme.
Bulk XML upload
Take the generated file through approval, authenticated upload, response handling and record-level reconciliation.
Open guide →XML validator
Go deeper into syntax, XSD, enumerations, cross-field rules, references and processing failures.
Open guide →UDI registration requirements
Inventory the approved prerequisites, identifiers, attributes and dependencies before mapping starts.
Open guide →Data migration
Plan a multi-source portfolio programme with cleansing, exceptions, submissions and final reconciliation.
Open guide →ERP integration
Replace periodic workbook exports with governed extraction and synchronization from operational systems.
Open guide →UDI registration automation
Place spreadsheet conversion within the broader maturity path from structured collection to M2M operations.
Open guide →Return to the EUDAMED automation hub for an overview of manual entry, bulk XML, M2M, integration and migration options.
Excel conversion questions
Can Excel be converted directly into EUDAMED XML?
Excel or CSV can be the source, but a robust conversion needs an explicit mapping and staging layer. Spreadsheet rows are flat, while device records can include family relationships, packages, markets, references, controlled values and conditional dependencies. The converter should normalize those structures before it serializes XML.
Is there one official EUDAMED Excel template for every device dataset?
This page does not claim one. The Commission publishes separate, versioned data dictionaries, XSDs, XML samples, enumerations and business rules. The applicable dataset varies by device and regulatory context, so an internal workbook design must be verified against the current official artefacts and the manufacturer's approved data.
How should Basic UDI-DI and UDI-DI values be represented?
Keep them as identifiers and use stable keys to represent the relationship. Official EUDAMED guidance explains that a Basic UDI-DI references at least one UDI-DI and multiple UDI-DIs can reference the same Basic UDI-DI. Avoid family joins based only on product names or spreadsheet row order.
What happens when a source value does not match an EUDAMED enumeration?
Return an exception containing the source record, field, original value, expected mapping set and owner. A controlled-value map can translate approved local codes, but the software should not guess an unknown value or silently replace it with a default.
Does generating valid XML submit the data to EUDAMED?
No. XML conversion prepares a file. Bulk upload remains a semi-automated method in which an authorised user transmits the file through EUDAMED. Automatic backend exchange is a separate M2M implementation. Both workflows also need processing-result reconciliation.
Does Yarify decide regulatory values or guarantee compliance?
No. Yarify can implement data extraction, mapping, controlled transformations, gap detection, XML generation and technical validation. The manufacturer and its qualified regulatory advisers remain responsible for classification, applicability, identifier assignment and approval of the submitted facts. Technical conversion does not guarantee MDR or IVDR compliance.
Primary sources
Reviewed 9 September 2026. The live technical catalogue was published 24 July 2026 and identified platform 2.27.0 with XSD 3.0.30. These artefacts are mutable: re-check the applicable dataset, dictionary, schemas, samples, rules, enumerations and compatibility notes before production use.
European Commission — UDI/Device registration
Official module status, UDI/device dataset resources, EMDN information and the mandatory-use date
EUDAMED Information Centre — Categorisation of devices
Official explanation of Basic UDI-DI, UDI-DI, Package UDI-DI, legacy identifiers and their relationships
EUDAMED Information Centre — Register Regulation Devices
Official registration starting point confirming the Basic UDI-DI and UDI-DI relationship for regulation devices
EUDAMED Information Centre — Guidelines on Data Exchange
Official distinction between individual UI entry, semi-automated XML upload and automatic M2M exchange
EUDAMED Information Centre — Technical-documentation guide
Official explanation of the different roles played by 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