EUDAMED Registration for SaMD: UDI Obligations and What SaMD Manufacturers Need to Do

EUDAMED and SaMD — the part that surprises people

Most MDR compliance content about EUDAMED focuses on hardware devices: physical labels, packaging, UDI carriers. Software developers often assume this is someone else's problem. It isn't. EUDAMED registration and UDI obligations apply to standalone software classified as a medical device under MDR, and the practical implementation has quirks that hardware guidance doesn't address.

The good news is that the core obligations are the same. Every SaMD that is placed on the EU market needs to be registered in EUDAMED. Every SaMD needs a UDI — a Unique Device Identifier — assigned according to the UDI system rules. What makes software different is how those obligations play out in practice when there is no physical product, no packaging barcode, and version updates happen frequently.

Understanding the UDI structure for SaMD

The UDI system has two components: the UDI-DI (Device Identifier) and the UDI-PI (Production Identifier).

The UDI-DI identifies the device model. For software, a new UDI-DI is required whenever there is a significant change to the software that could affect its safety, performance, or intended use. This is a design change, not a version number — minor bug fixes typically don't require a new UDI-DI, but a change that affects the clinical algorithm, the intended purpose, or the software's core functionality does.

The UDI-PI for software typically includes the software version number and, where relevant, the date of release. This is the element that distinguishes one release from another within the same device model.

The Basic UDI-DI sits above both: it identifies the device at the device group level — the same Basic UDI-DI applies across all versions and configurations of a device that share the same intended purpose and risk class. The Basic UDI-DI is what you register in EUDAMED and what appears in your EU Declaration of Conformity and your certificate.

Who assigns the UDI — and how

UDIs are assigned by manufacturers. You don't apply to a regulator for a UDI — you register with one of the designated UDI issuing entities and use their system to generate your UDI. The three issuing entities accepted under MDR are GS1, HIBCC, and ICCBBA. For software, GS1 is the most commonly used because its system is designed to handle software-specific identifiers.

Once you have a UDI-DI assigned, you register it in EUDAMED. The registration includes detailed device data: device description, intended purpose, risk class, applicable standards, clinical information, and UDI data. This data becomes publicly visible in EUDAMED (the public-facing portion) and forms part of the traceability infrastructure for the EU medical device market.

The labelling question for software

Physical medical devices carry the UDI on their label and/or packaging. For standalone software, there is no physical label. MDR and the MDCG guidance on UDI address this: for standalone software, the UDI must appear in the software itself — typically in the "about" screen, the software's electronic IFU, or the user interface in a location accessible to users.

One thing to plan for: if your software is distributed through an app store, the UDI placement still applies. The fact that Apple App Store or Google Play governs the distribution doesn't exempt the software from UDI display requirements. Build the UDI display into the software, not the store listing.

For software delivered as a service (SaaS/cloud-based SaMD), the UDI should appear in the application interface and be documented in the electronic IFU. The version component of the UDI-PI should reflect the current deployed version of the service.

What EUDAMED registration actually requires

Registering in EUDAMED involves two separate workflows that are often confused:

Manufacturer/authorised representative registration — before you can register any device, the manufacturer (or its EU authorised representative, if the manufacturer is established outside the EU) must be registered in EUDAMED as an economic operator. This registration provides the SRN (Single Registration Number), which is a prerequisite for device registration.

Device registration — once the manufacturer is registered, each device must be registered in EUDAMED using the UDI-DI. The registration includes the full set of device data required by Article 29 and Annex VI Part B. For SaMD, this includes the software version or version range, the intended purpose, the risk classification with supporting analysis, and the applicable conformity assessment route.

The device registration must be complete and accurate before the device is placed on the market. It's not a post-market formality.

Version management — the practical challenge for SaMD

This is where SaMD diverges most from hardware in EUDAMED practice. Hardware device versions are relatively infrequent events. Software updates can happen monthly or more frequently.

The practical approach most SaMD manufacturers use:

Minor updates (bug fixes, performance improvements, no change to clinical functionality): update the UDI-PI to reflect the new version, update the device registration in EUDAMED if required. No new UDI-DI needed.

Significant changes (algorithm changes, new clinical functionality, change to intended use or patient population): assign a new UDI-DI, create a new device registration in EUDAMED, and update your technical documentation, clinical evaluation, and Declaration of Conformity accordingly.

Define your criteria for "significant change" explicitly in your change management procedure. This is a documented decision you need to make, not something to assess ad hoc with each release.

MDCG guidance on UDI for software

MDCG 2019-2 is the primary guidance on UDI assignment for software. It was updated and clarified in subsequent documents. The guidance confirms the approach described above — new UDI-DI on significant change, UDI-PI tracking the version — and provides additional worked examples for common software scenarios.

One clarification in the guidance that catches teams: if your SaMD is part of a hardware device system (e.g., software delivered as part of an instrument), the UDI assignment may differ from standalone software. Check whether your software qualifies as standalone SaMD or as software that is an accessory to or integral part of a hardware device before applying the standalone software UDI rules.