Software as a Medical Device carries a UDI under MDR Article 27, but Annex VI Part C Section 6 of Regulation (EU) 2017/745 sets software-specific rules that diverge from the hardware case. A new UDI-DI is required when a modification changes the original performance, the safety, or the intended use of the software, when it changes the interpretation of data, or when the type of change to the software is major. Minor revisions — bug fixes, usability or operating efficiency improvements, security patches — keep the UDI-DI and trigger a new UDI-PI in the form of an updated software identification. The UDI for software is not printed on a physical label the way hardware UDIs are; Annex VI Part C Section 6.5 requires the UDI to be provided on a readily accessible screen in a clearly readable plain-text format, such as an "about" screen or a start-up screen, and it must also be placed on the physical medium where the software is delivered that way.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • SaMD is in scope for UDI under MDR Article 27 like any other device other than custom-made or investigational.
  • Annex VI Part C Section 6 of the MDR is the software-specific sub-section. Read it directly before assigning a software UDI.
  • A new UDI-DI is triggered by a major software change — one that alters original performance, safety, intended use, or the interpretation of data. Minor revisions keep the UDI-DI and update the UDI-PI.
  • The UDI-PI for software is the software identification (the version identifier). A new version number is a new UDI-PI.
  • The UDI carrier for software is not a barcode on a box. Annex VI Part C Section 6.5 requires the UDI on a readily accessible screen in plain text, and on the physical medium for software delivered physically.
  • The Basic UDI-DI, the UDI-DI, and the software version must be consistent across the "about" screen, the technical documentation, the EUDAMED entry, and the declaration of conformity. MDCG 2019-11 Rev.1 (June 2025) is the authoritative guidance on software changes and their regulatory consequences.

Why software UDI is special

Hardware UDI has a physical anchor. There is a label on a box, a direct marking on a reusable instrument, a lot number printed at the end of a production line. The UDI carrier is a barcode a scanner can read in a hospital stockroom. The obligations in Annex VI Part C Sections 1 to 5 are written around that physical reality.

Software has none of that. There is no box in the common case. There is no lot number because software is not batched the way sterile consumables are batched. There is no serial number because every install of the same version is the same bits. The version of the software is the closest analogue to a production identifier, and the "about" screen is the closest analogue to a label. Annex VI Part C Section 6 exists to map the UDI concept onto this different physical reality without losing the identification and traceability purpose of Article 27.

The result is a set of rules that look similar to hardware UDI in their vocabulary — UDI-DI, UDI-PI, Basic UDI-DI all still apply — but diverge in what triggers a new UDI-DI, what constitutes a UDI-PI, and where the UDI carrier lives. A founder who assigns software UDI using hardware intuition gets caught on all three.

This post is the software-specific reading. For the general UDI orientation, read What is UDI?. For the general UDI-DI and UDI-PI distinction, read UDI-DI vs UDI-PI in practice. For the underlying SaMD qualification and classification, read What is Software as a Medical Device (SaMD)?.

When a new UDI-DI is required for software

The core question in software UDI assignment is the version-change question: does this software change require a new UDI-DI, or only a new UDI-PI?

Annex VI Part C Section 6.2 of Regulation (EU) 2017/745 sets the rule. A new UDI-DI is required whenever there is a modification that changes one of the following: the original performance of the software; the safety of the software; the intended use of the software; the interpretation of data. Beyond those explicit triggers, the Annex also treats a new release that involves a major software revision — in contrast to bug fixes, usability or operating efficiency improvements, security patches, or operating efficiency adjustments — as a major change that requires a new UDI-DI.

The practical reading is that the UDI-DI is tied to the identity of the software as a regulated device, not to the build number of the code. If the intended purpose stays the same, the performance characteristics stay the same, the data interpretation logic stays the same, and the safety profile stays the same, then the UDI-DI stays the same — even if the version number increments and the binary is different.

Three categories of change reliably trigger a new UDI-DI under Section 6.2:

  • A change to the intended purpose or indication, even if the algorithm is untouched. Intended purpose is the load-bearing concept in MDR Article 2(12), and a change to it is a change to the device identity.
  • A change to the algorithm or the data model that alters the interpretation of data — for example a retrained machine-learning model whose output distribution is materially different, or a rule engine whose thresholds have shifted enough to change the clinical output.
  • A change to the performance or safety claims substantiated in the clinical evaluation, because the claims and the documentation are the regulatory identity of the device.

Changes that typically do not trigger a new UDI-DI, and instead fall into the new-UDI-PI category, are bug fixes that do not alter performance or safety, security patches, cosmetic UI changes, usability improvements that do not change the intended use, and backend infrastructure changes that are transparent to the user and to the clinical function.

MDCG 2019-11 Rev.1 (June 2025) is the authoritative companion to Section 6. Section 3 of the guidance walks through the qualification and classification implications of software changes and is where the grey cases are clarified. If you are in doubt about whether a specific change is major or minor, MDCG 2019-11 Rev.1 is the document that settles it — together with a documented judgment from your Notified Body where one is involved.

Version versus revision — the trigger in practice

The vocabulary startups use for software releases rarely matches the vocabulary the MDR uses. A team that ships three times a day with semantic versioning has a different mental model from a Regulation that speaks of "major revisions" and "new UDI-DI triggers." The translation is what matters.

A workable rule of thumb, consistent with Annex VI Part C Section 6.2 and MDCG 2019-11 Rev.1: treat the leftmost segment of a semantic version (the major number in X.Y.Z) as the candidate for a new UDI-DI, and the middle and right segments (minor and patch) as candidates for a new UDI-PI. This is a rule of thumb, not a binding convention — the Regulation cares about the substance of the change, not about the numbering scheme. A minor-number release that materially changes the data interpretation is a new UDI-DI regardless of how the team numbers it. A major-number release that is purely a rewrite of the backend with no clinical impact is arguably a new UDI-PI. The numbering is a signal; the substance is the rule.

The document the founders need is a software change control procedure inside the QMS that, for every release, records the following: a short description of the change, a classification of the change against the Section 6.2 criteria (performance, safety, intended use, data interpretation, major revision), the resulting decision (new UDI-DI or new UDI-PI), and the signature of the person responsible. That procedure is what the Notified Body will ask to see, and it is what keeps the UDI-DI assignments defensible over time. See Change management for MDR software for the full treatment of the change-control side.

Display in software — the "about" screen requirement

Annex VI Part C Section 6.5 of the MDR specifies how the UDI is provided for software. The UDI must be placed on a readily accessible screen for the user in a clearly readable plain-text format, such as an "about" file or an "included on the start-up screen." The UDI must be provided in a human-readable format and, where the software has a user interface, via an API or other electronic means that allow the UDI to be retrieved.

For software delivered on a physical medium — a USB stick, a DVD, an installation disc — Section 6.3 requires the UDI to be present on each packaging level of the physical medium as well, following the same carrier rules as hardware.

The practical design decision is where in the user interface the UDI is surfaced. The conventional place is an "About" or "Information" screen that is two or three clicks from the main screen, shows the product name, the manufacturer, the Basic UDI-DI, the UDI-DI, the software version as the UDI-PI, the CE mark, the Notified Body number where applicable, and the regulatory classification. This screen is also where MDR Annex I Chapter III labelling elements for software typically live, so there is a natural convergence. Designing the about screen once, correctly, and maintaining it as a first-class UI artefact — not an afterthought — saves repeated rework at every release.

For cloud-delivered software without a traditional install, the same principle applies: the user must be able to retrieve the UDI in a clearly readable plain-text format from the running software. A settings page, a footer link, or a dedicated information screen all satisfy the requirement as long as the content is correct and reachable.

EUDAMED entry for software UDI

The EUDAMED side of software UDI is unchanged from hardware in its structure. The manufacturer submits the Basic UDI-DI and the UDI-DI, together with the Annex VI Part B data elements, to the UDI database inside EUDAMED under MDR Article 29. Commission Implementing Regulation (EU) 2021/2078 governs the detailed operation of the database.

Two things are specific to software in the EUDAMED entry. First, the software version that functions as the UDI-PI does not flow into EUDAMED as an individual entry — like hardware UDI-PIs, it lives in the running software and in the manufacturer's change-control records, not in the database. The database holds the UDI-DI; the running software holds the UDI-PI. Second, the device data elements submitted for a SaMD entry must correctly reflect that the device is software — the nomenclature (EMDN), the device type, and the applicable Annex VI Part B fields for software-specific information must all be accurate.

When a new UDI-DI is issued because a software change crosses the Section 6.2 threshold, a new EUDAMED record is created for that new UDI-DI. The old UDI-DI record is not deleted — it remains, representing the prior version of the device, and the new record represents the new version. The manufacturer maintains both. For founders used to overwriting records in a database this is counterintuitive; the UDI database is an append-only regulatory ledger by design.

See Device registration in EUDAMED for the full submission workflow and EUDAMED status in 2026 for the current module availability.

Common mistakes

A handful of mistakes appear on almost every first software UDI project.

Treating every release as a new UDI-DI. A team that ships weekly cannot practically issue a new UDI-DI every Friday. The Section 6.2 trigger is about substance — performance, safety, intended use, data interpretation, or a major revision — not about the fact of a release. Most releases are new UDI-PIs.

Treating no release as a new UDI-DI. The opposite mistake. A team that never re-issues a UDI-DI because "it is the same product" will eventually ship a version whose intended use, performance, or data interpretation has quietly drifted far enough from the original that the UDI-DI is out of date. The change-control procedure is the defence against this.

Forgetting the "about" screen. Section 6.5 is explicit that the UDI must appear on a readily accessible screen. A software product that ships without a UDI surfaced in the UI is non-compliant on the label side of the obligation, even if the UDI is correctly entered into EUDAMED.

Putting the Basic UDI-DI on the label instead of in the documentation. As in the hardware case, the Basic UDI-DI lives in the documentation, the declaration of conformity, the certificate, and the EUDAMED entry — not on the label or in the visible about screen as "the UDI." What is surfaced on the screen is the UDI-DI plus the software identification as UDI-PI.

Using the build number as the software identification. Internal build numbers are usually unsuitable as the UDI-PI because they change too often and are not meaningful to users or to regulators. The UDI-PI should be the externally visible version identifier that the change-control procedure links to a specific, documented release.

Ignoring MDCG 2019-11 Rev.1 on change classification. The June 2025 revision is the definitive guidance on when a software change crosses into a new device identity. A team that has not read it is guessing.

The Subtract to Ship angle

Software UDI is a clean application of the Subtract to Ship framework for MDR because the work that survives subtraction is precisely what Annex VI Part C Section 6 and MDCG 2019-11 Rev.1 require — nothing more.

The real work is: decide Basic UDI-DI grouping for the software family; assign a UDI-DI under the chosen issuing entity's rules; design an "about" screen that surfaces the Basic UDI-DI, the UDI-DI, and the software version as UDI-PI in a readily accessible plain-text format; write a software change control procedure that classifies every release against Section 6.2; submit the Basic UDI-DI and UDI-DI to EUDAMED with Annex VI Part B data; and maintain both records as releases evolve.

Everything else — parallel version tracking systems that mirror git history for no regulatory reason, speculative UDI-PI schemes that go beyond what the issuing entity requires, custom databases that replicate EUDAMED fields for no reason — is a candidate for removal. If a proposed activity does not trace to Article 27 or Annex VI Part C Section 6, it comes out.

Reality Check — Where do you stand on software UDI?

  1. For your SaMD product, do you know the Basic UDI-DI and the current UDI-DI, and are they consistent with the technical documentation and the declaration of conformity?
  2. Does your user interface surface the UDI on a readily accessible screen in plain-text format, as required by Annex VI Part C Section 6.5?
  3. Is the software version displayed on that screen the same identifier that functions as the UDI-PI in your change-control records?
  4. Do you have a written change-control procedure that, for every release, classifies the change against the Section 6.2 criteria and records the new-UDI-DI-or-new-UDI-PI decision?
  5. Have you read MDCG 2019-11 Rev.1 (June 2025) and applied its guidance on software changes to your own release history?
  6. If your software is delivered on a physical medium, is the UDI also present on the packaging of the medium under Section 6.3?
  7. When you issued a new UDI-DI, did you create a new EUDAMED record rather than overwriting the old one?
  8. Are the Basic UDI-DI and UDI-DI on your certificate, declaration of conformity, and EUDAMED entry all identical?

If you cannot answer five or more of these cleanly, software UDI is not yet a solved workstream.

Frequently Asked Questions

When does a software change require a new UDI-DI under the MDR? When the change alters the original performance, the safety, the intended use, or the interpretation of data, or constitutes a major software revision rather than a bug fix, usability improvement, security patch, or operating efficiency adjustment. The rule is in Annex VI Part C Section 6.2 of Regulation (EU) 2017/745 and is interpreted in MDCG 2019-11 Rev.1.

Is the software version the UDI-PI? Yes. For SaMD the UDI-PI takes the form of a software identification — in practice the externally visible software version identifier that the manufacturer's change-control procedure links to a specific release. Annex VI Part C Section 6 names software identification as the applicable PI element for software.

Where does the UDI appear on a software product? On a readily accessible screen in the user interface in a clearly readable plain-text format — typically an "about" screen or a start-up screen — as required by Annex VI Part C Section 6.5. For software delivered on a physical medium, the UDI also appears on the packaging of that medium.

Does the Basic UDI-DI appear on the about screen? It can, and many implementations display it alongside the UDI-DI and the software version. Regulatorily, the Basic UDI-DI belongs in the technical documentation, on the declaration of conformity, on the certificate, and in EUDAMED. Showing it on the about screen is a helpful consistency measure but is not the formal label-side obligation.

Do we submit every software version to EUDAMED? No. EUDAMED holds the Basic UDI-DI and the UDI-DI with Annex VI Part B data. The software version as UDI-PI lives in the running software and in the manufacturer's internal records. When a change crosses the Section 6.2 threshold into a new UDI-DI, a new EUDAMED record is created.

What about cloud SaaS without a traditional install? The same obligations apply. The user must be able to retrieve the UDI in plain-text format from the running software — a settings page, a footer, or a dedicated information screen satisfies Section 6.5 as long as the content is correct and reachable. The change-control procedure and the EUDAMED record are unchanged.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 27 (Unique Device Identification system) and Annex VI Part C Section 6 (UDI rules specific to software, including Section 6.2 on when a new UDI-DI is required, Section 6.3 on software delivered on a physical medium, and Section 6.5 on the display of the UDI on a readily accessible screen). Official Journal L 117, 5.5.2017.
  2. MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. First published October 2019; Revision 1, June 2025. Authoritative interpretation of software change classification and regulatory consequences.
  3. Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021 laying down rules for the application of Regulation (EU) 2017/745 of the European Parliament and of the Council as regards the European Database on Medical Devices (Eudamed). OJ L 426, 29.11.2021.

This post is part of the EUDAMED, UDI and Registration category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The pillar post for this cluster is What is EUDAMED?. For questions about how the software-specific UDI rules in Annex VI Part C Section 6 apply to your particular release cadence and deployment model, read this post alongside What is Software as a Medical Device (SaMD)? and MDCG 2019-11 Rev.1.