EUDAMED XML template: the EC files, and how to use them

For the wider context of XML upload as one of three EUDAMED submission methods, see the EUDAMED submission methods overview.

What the EC actually publishes (there is no single template)

Search for a EUDAMED XML template and you will not find a file to download by that name. There is no single Excel sheet, and no single PDF, that carries it. What turns your device data into a file the portal accepts is assembled from a small set of documents the European Commission publishes on its Technical Documentation page, and every one of them is free.

Four things on that page matter for a manufacturer registering devices. A schema that sets the structure of the upload, meaning which fields are required and what each will accept. A set of Excel data dictionaries that name every field and point to the list each value is drawn from. Sample XML files that show a complete, working submission for each device type. And PDFs of the business rules the platform checks on upload. The template you were after is those four used together: a sample that matches your device as the starting point, the dictionary as the field-by-field reference, the schema for the structural check, and the business-rule PDFs for everything the schema cannot see. Which one you open first depends on the route that fits your shop, covered below.

The EUDAMED schema, the data dictionary, and which version you need

The schema and the dictionary answer two different questions. The schema decides the shape of the file: which fields have to be present, what type each one is, and which values the portal will accept in each. The Excel data dictionary is the plain reference beside it. It names every field, marks which are mandatory, and points to the list each coded value comes from. Between them they tell you which columns go into the file and what is allowed in each.

As of this article’s last review, the EC Technical Documentation page names the current schema at v3.0.30, matched to platform release v2.27.0. The number matters for one practical reason: the version your file declares has to match the version the platform is running, or the upload is refused before anything else is checked. Verify it on the Technical Documentation page before any production run, and again whenever you next review your tooling. For the Commission’s own account of how the schema and the business rules divide the work, its data exchange guidelines are the source.

The schema checks structure. Everything that depends on meaning across fields, such as a Basic UDI-DI grouping rule, an EMDN code having to be a terminal (leaf-level) code, or a certificate having to link to the right notified body, lives in the business-rule PDFs, and the platform applies those at upload.

Which EUDAMED XML sample fits your device

The fastest way from a device to register to a working file to adapt is to start from the EC sample that matches your device, not from the schema on its own. The EC’s index of sample files maps each published sample to a scenario, and four scenarios cover most first submissions.

Pick the sample that fits, then treat it as scaffolding: keep the structure, replace the sample values with your own per the data dictionary, and run the pre-upload checks before you send it. The index also lists sample files that show common rejection cases. Those are useful reference for the common EUDAMED rejections and the fixes, but you do not need them to prepare a submission.

One caveat on that fourth row. Legacy devices do not use a Basic UDI-DI and UDI-DI pair. EUDAMED issues a EUDAMED-DI and a EUDAMED-ID in their place, so the record shape differs from the MDR and IVDR samples, and the legacy page linked above carries the mechanics. The rest of this page is written in Basic UDI-DI and UDI-DI terms, which is the right frame for new MDR and IVDR devices.

Four routes to a valid EUDAMED XML file, and which fits your shop

The asset set supports four realistic routes to a working file. Each fits a different mix of device count, engineering capacity, and budget. The matrix below names the inputs so you can see which row is yours.

Route two is where EUDAPrep sits. The other three assume you have already done the upstream work: a clean Excel filled in by hand from your technical files, a data pipeline reading from PLM, or a briefed consultant billing for the reformatting hours. EUDAPrep starts a step earlier, from the source documents you already hold. It reads your technical files, the IFUs, labels, declarations of conformity, safety data sheets and so on; extracts the fields the data dictionary expects; proposes EMDN and other codes from the EC’s published lists for your PRRC to confirm; and runs the pre-upload checks before the file leaves the tool. The work then splits into a few steps: someone uploads the source documents, someone reviews the mapped output and confirms the suggested codes, and someone exports the file and submits it through the EC portal. On a larger team those are a Quality Engineer, the PRRC, and RA; on a smaller one your PRRC or RA can do all of it. The fixed point is that the PRRC reviews and confirms before anything is submitted. Your consultant shifts from hours of document prep to the regulatory judgement you keep them for, which is the line your CFO will want to see.

For the CFO, the comparison is not the tool price alone. It is the tool cost plus the review hours your PRRC and consultant still put in, set against a full from-scratch engagement. And because EUDAPrep re-syncs to the EC’s current files when they change, keeping your file on the version the platform accepts is not a standing job for your team, the way it is on the hand-assembled and in-house routes.

Which route fits is mostly a question of device count and how often your devices change. Route one suits a small portfolio in stable categories. Route three earns its build cost when devices update often enough that re-running the conversion by hand costs more than automating it. Route four takes the job off your desk and pays a consultancy to run it. The public version of this question tends to get reduced to build it yourself or type it in by hand, which skips the two routes in the middle where most manufacturers actually land.

Where a route uses AI to pull fields out of your documents, treat the extraction as assistance for review, not a decision the tool makes for you. The AI proposes, the PRRC reviews and confirms, and you keep the regulatory responsibility. A pipeline that uses AI in its extraction step works the same way.

EUDAMED XML file limits: 300 devices per file, one-to-one pairing, and status transitions

Three limits decide whether a file that looks right on your screen actually uploads, and none of them show up in the schema.

The first is the limit of 300 Basic UDI-DI and UDI-DI pairs per file. A manual upload cannot exceed 300 pairs, so a larger portfolio is split across several files and uploaded in sequence. The split is operational, not regulatory; nothing requires a particular grouping, but the file has to respect the ceiling.

The second is how the manual upload pairs identifiers. A Basic UDI-DI normally groups several UDI-DIs, and that one-to-many relationship is the standard model. The manual upload takes them one pair at a time, so adding further UDI-DIs under an existing Basic UDI-DI runs through a different service path rather than the manual upload. How a Basic UDI-DI groups your UDI-DIs sets out the model underneath it.

The third is the move from Submitted to Registered for Class III and Class IIb implantable devices. A device that needs a Notified Body certificate opens in Submitted status and becomes Registered only once the notified body is linked. If the certificate is not yet published in the Notified Bodies module, the device stays in Submitted. That is a process gate, not a fault in your file; the file uploaded correctly.

Before you upload: two checks, where the paid tools sit, and who does what

Two checks catch most rejections before the file leaves your shop. The structural check runs the file against the EC schema and catches the mechanical faults: a missing required field, a value the schema does not allow, a malformed file. The business-rule check runs the file against the EC business rules and catches what the schema cannot see, such as an EMDN code that is not a terminal (leaf-level) code, or a certificate reference that does not resolve back to the notified body that issued it.

One more check only EUDAMED runs, and it happens after the upload rather than during it: the platform’s own response. Structural rejections come back pointing at the field that failed; business-rule rejections come back as codes and do not always name the field. EUDAMED accepts the valid records and rejects the invalid ones in the same file, so a mixed file can land partly. The common EUDAMED rejections and the fixes covers what to do when that happens.

Every asset on the Technical Documentation page is free, and the upload itself carries no fee. Paid Excel templates and paid converters sell the mapping and conversion layer, sometimes with a check that runs the schema and business rules locally rather than at upload. Managed-service handoffs sell someone else running the cycle for you. The free EC assets are the floor under all four routes.

EUDAPrep runs both checks on the file before it exports: structure against the EC’s current schema, and every published business rule against the fields it has mapped. Anything EUDAMED would have rejected comes back as a review flag inside the tool for the PRRC to clear. The check is deterministic, not a guess. It also keeps a per-submission record: the source documents it read, the values and codes it mapped, and the validation results, so there is something concrete behind each file when someone later asks how it was prepared.

The roles below are the fullest split. On a smaller team one person covers more than one, and the PRRC review is the part that does not move.