Regulatory labelling & UDI
Where the electronic label lives, what every clinical output has to carry with it, and the question a software team gets wrong more than any other in this area: when a release is a new version of the same device, and when it is a different device.
Overview
Device identification panel is the object. This is everything around it: how a user reaches it, what leaks out of it onto every other screen and every exported document, and how it changes over the life of the product.
The design consequences are larger than they look, because identity is not confined to one screen. A printed report, a PDF in the record, an audit entry and a vigilance form all need to say which software produced what — and by the time anyone asks, the software has moved on.
Regulatory citations here are Standard claims in the sense of Status & limitations — traceable to a published text, paraphrased, and no substitute for it. The design guidance built on top is Reasoned. Whether a given change requires a new UDI-DI, a new conformity assessment, or both is a decision for your quality system and your notified body, not for a design system.
Identity travels
Anything that leaves the product carries the software that made it. A finding without a version is a finding nobody can reproduce.
The boundary is visible
A release that changes what the device is should look different to a user, not only to the technical file.
Reachable when everything is broken
The label is read at the worst moment. It works offline, signed out, and on a phone.
Where it lives
MDR Annex VI Part C §6.5.4 asks for an "easily accessible" screen. In practice that is the difference between a support call that starts with the version and one that starts with four minutes of navigating someone else's settings tree.
| Surface | Carries |
|---|---|
| Device identification panel | Everything. One screen, one route, same place in every deployment. |
| Persistent chrome | Device name and version, small and always present — see Navigation. It is the fastest possible answer to "which version are you on?" |
| Sign-in screen | Name and version at minimum. Reachable before authentication, because the person reporting a fault may not be able to get in. |
| Every exported document | Device name, version, and the identifiers relevant to the output — see below. |
| Every clinical output in the record | The version that produced it, stored with it rather than looked up later. |
| Error and crash screens | Version and build. The screen a user photographs is the screen that most needs it. |
- One route, always the same. If a clinician has to be told where it is, it is not easily accessible.
- Never behind a licence agreement or a marketing page.
- Never modal-only. It should be linkable, printable and exportable.
- Never gated on the network, on a licence check, or on a signed-in session.
Same device, or a different one?
Under MDR Annex VI Part C, a new UDI-DI is required when a modification changes the original performance, the safety or intended use of the software, or the interpretation of data. Changes that do not — security patches, bug fixes, operating efficiency, usability improvements not made for safety reasons — get a new UDI-PI and keep the UDI-DI. MDCG 2018-1 works this through for software; MDCG 2020-3 covers when a change is significant enough to need a new conformity assessment.
The design consequence: the version scheme must make that boundary legible. If a user cannot tell from the version string whether they are on the same regulatory device as last month, neither can the person reading their incident report.
| Change | Normally | Because |
|---|---|---|
| New or modified algorithm | New UDI-DI | Changes performance and the interpretation of data. |
| New intended purpose, or a new population | New UDI-DI | Changes intended use — and almost certainly needs a new conformity assessment. |
| New user interface changing how results are read | New UDI-DI | Changes interpretation of data. This is the one design teams do not expect. |
| New interoperability channel or data source | New UDI-DI | Changes what the device operates on. |
| Security patch | New UDI-PI | No change to performance, safety or interpretation. |
| Bug fix with no safety impact | New UDI-PI | As above — but a fix to a safety-relevant defect may not qualify. |
| Usability improvement not made for safety | New UDI-PI | The qualifier matters: a change made because of a use-related risk is a different case. |
-
14 Aug 20265.0.0 — revised ST measurement algorithm. New UDI-DI. In regulatory terms this is a different device from 4.x.UDI-DI (01)05060XXXXXXXY2 · conformity assessment updated
-
2 Jun 20264.3.1 — security patch and two defect fixes with no effect on analysis. Same UDI-DI, new UDI-PI.UDI-DI (01)05060XXXXXXXXX · UDI-PI (8012)4.3.1
-
4 Mar 20264.3.0 — worklist density option added. Usability, not safety. Same UDI-DI.UDI-DI (01)05060XXXXXXXXX · UDI-PI (8012)4.3.0
The major number moves only when the UDI-DI moves. That is a self-imposed constraint, and it makes a two-part question — "what changed?" and "is this still the same device?" — answerable from the version string alone.
- Bind the major version to the UDI-DI. Nothing requires this, and it costs you the freedom to use major versions for marketing. It buys a version string that answers a regulatory question, which is worth more.
- Tell users when the boundary is crossed, in those terms — not "what's new", but "this is a different device model; here is what changed and why".
- Never reuse a UDI-DI across devices, and never silently repoint one.
- Both identifiers reach the record. A stored result carries the UDI-DI and the UDI-PI that produced it — see below.
- Legacy versions stay identifiable long after they stop running. The record outlives the deployment.
What every output carries
This is where labelling stops being a settings screen and becomes a design constraint on the whole product. Three years from now, somebody will ask what produced a particular finding.
ST elevation V2–V4
Measured 3.1 mm at J+60 ms. Decision support only; confirm against the trace.
Device version and analysis model version are different facts and both are recorded. A device release can change without the model changing, and the reverse.
| Output | Must carry |
|---|---|
| A clinical finding stored in the record | Device name, version, UDI-DI, UDI-PI, and separately the analysis model version. |
| A printed or exported document | The same, in the footer of every page — see Data visualisation on what survives print. |
| An audit entry | Version at the time of the action, stored rather than resolved later. |
| A message to another system | Device identity in the message, so the receiving record is not dependent on yours. |
| A screenshot | Nothing can be required of a screenshot — which is the argument for version being visible in persistent chrome. |
- Stored, never resolved at read time. "Current version" looked up when a record is opened is the version running today, not the one that produced the finding.
- Device version and model version are separate fields. Conflating them makes Model version change impossible to reason about.
- Immutable once written. A migration that rewrites historical version stamps destroys the only record of what produced what.
Instructions for use
For most software the IFU is electronic, under Regulation (EU) 2021/2226, and that carries its own interface obligations rather than merely permitting a PDF link.
- Reachable from the device, from the identification panel and from the product's help route.
- Available offline, or downloadable in advance. An IFU that requires the network is unavailable during the failure it is most needed for.
- Versioned against the software, with earlier revisions retained — a user on 4.3.1 must be able to read the IFU for 4.3.1, not only the current one.
- Paper on request, free of charge, within the period the regulation specifies, and the panel says how to ask.
- In an accepted language for the Member State — see International design.
- Accessible. It is part of the device; a scanned PDF of a typeset booklet is not readable by assistive technology.
States
| State | Rendering |
|---|---|
| Released device | Full panel; version in chrome; identity on every output. |
| Investigational | "Exclusively for clinical investigation" (MDR) or "for performance study only" (IVDR), above everything, and repeated on every export. |
| Pre-release build | Marked unmissably and differently from the released device, so a screenshot cannot be mistaken for one. |
| Crossing a UDI-DI boundary | Announced as a change of device model, not as a changelog entry. |
| Unsupported version | Stated, with what it means. A version past its supported life is a risk the user is entitled to know about. |
| Region without marketing authorisation | The device does not present a CE mark or claims that do not apply where it is being used. |
Who holds each rule
Regulatory labelling is the one page where a required prop has a legal meaning. The panel holds its fields; whether they are correct is yours, and on this page that has consequences no other page has.
| Rule | Held by | Where |
|---|---|---|
| One route, always the same, carrying the mandatory fields | Device identification | The panel cannot be rendered without name, purpose, version, UDI-DI, manufacturer and release date. Asserted: DeviceLabel: intended purpose is present verbatim |
| A missing notified body is stated, not blank | Device identification | The absence renders as words. Asserted: DeviceLabel: no notified body is stated, not left blank |
| Device version and model version are separate fields, in a fixed order | Device identification | The reading order is the component’s. That the model version is also recorded is the log’s. Asserted: DeviceLabel: identification precedes purpose, which precedes manufacturer |
| Both identifiers reach the record, and are stored rather than resolved at read time | Event log | What is written is what stays written. Which identifiers you write is yours. Asserted: EventLog: no entry can be edited, removed or cleared |
| Never behind a licence agreement or a marketing page; never modal-only; never gated on the network | The implementer | Routing and delivery. The panel renders anywhere; putting it somewhere reachable is yours. |
| Bind the major version to the UDI-DI; never reuse a UDI-DI | The implementer | Regulatory practice in your release process. No renderer can check a UDI. |
| Tell users when the boundary is crossed | The implementer | A notification at upgrade time, from your deployment. |
| Legacy versions stay identifiable | The implementer | A property of your build and record keeping. |
| Every value on the panel is correct | The implementer | Every identifier on the device-label page is fabricated. The component guarantees completeness and nothing about correctness — see its table and Known gaps. |
A pattern page has no component underneath it, so a rule stated here is held by whoever builds against it unless a component already holds it. Of these 9 rules, 4 are held by a component this package ships, and 5 are the implementer’s. Four held, five not. This page paraphrases MDR and IVDR and is not legal advice; the rows above are which of its rules a type can hold, not which of them are right.
Do's and don'ts
5.0.0 — revised ST measurement algorithm. New UDI-DI. In regulatory terms this is a different device from 4.x.
The version string answers a regulatory question. A user can tell they are no longer on the device they were assessed against.
4.4.0 — improvements to ST measurement. See release notes.
An algorithm change shipped as a minor version. The UDI-DI moved and nothing a user can see moved with it.
AcuteLine 4.3.1 · UDI-DI (01)05060XXXXXXXXX · UDI-PI (8012)4.3.1 · model v4.2
Stamped on the finding itself, with device version and model version as separate facts. Reproducible in three years.
Generated by AcuteLine
No version, no identifiers. The finding cannot be attributed to a build, which is the first question any investigation asks.
Version 4.3.1 shown in the masthead, on the sign-in screen, and on the error page.
Readable before signing in and after a crash — the two moments someone actually needs it.
Settings → Account → Advanced → About
Four levels deep and behind authentication. "Easily accessible" is a requirement, not an aspiration.
Exclusively for clinical investigation — not for use in routine clinical care.
Top of the panel and repeated on every export, so a printout leaving the study cannot be read as a clinical result.
Investigational use only — in the panel footer, 10 px
The most consequential statement on the screen, set smaller than everything else and absent from exports.
Accessibility
- Version in chrome is text, in the accessible name of the masthead region — not an image, and not revealed on hover.
- Identifiers on outputs are selectable text in exports too. A PDF whose footer is rasterised cannot be copied into a report.
- The investigational statement is announced first in reading order, not placed last and styled prominently.
- Reachable by keyboard from the main navigation in one obvious step.
- Language of the label follows the Member State, while identifiers stay untranslated — see International design.
- Print stylesheet carries the footer identity on every page, not only the first.
- Readable at 320 px without truncating identifiers (SC 1.4.10).
Outcomes of use
What this contributes to, in the terms of Usability & context of use. These are attributes believed to contribute to an outcome; the outcome itself is settled by observing real use in a specified context, not by this page.
- Effectiveness — a finding can be attributed to the exact software that produced it, years later. The measure is how often an investigation can establish the version without asking the manufacturer.
- Efficiency — seconds to answer "which version?", against minutes of navigating a settings tree during a support call.
- Satisfaction — a clinician who can check what the software is licensed to do. The intended purpose statement gets read far more than product teams expect, usually by someone deciding whether they are allowed to rely on it.
Clinical safety notes
Trace these in your risk file (ISO 14971) and usability engineering file (IEC 62366-1). Each bullet says what checks it: a component that holds the rule, a test in your verification file, deployment configuration, post-market surveillance, or a design review where no test can see it. A control checked by nothing is a sentence.
- Version and identifiers stored with every output. (held by Event log) Mitigates: a finding that cannot be attributed to a build during an investigation.
- Device version and model version recorded separately. (held by Device label) Mitigates: two independent change histories collapsed into one.
- Version stamps immutable. (a test in your verification file) Mitigates: a migration rewriting the record of what produced what.
- Major version bound to the UDI-DI. (deployment configuration) Mitigates: a user unable to tell they are no longer on the device they were trained and assessed against.
- UDI-DI boundary announced as a change of device. (a test in your verification file) Mitigates: a substantive change absorbed as a routine update.
- Label reachable offline, signed out, and from error screens. (a test in your verification file) Mitigates: device identity unavailable exactly when an incident is being reported.
- Investigational status stated first and repeated on exports. (a test in your verification file) Mitigates: an investigational output read as a clinical result.
- Pre-release builds marked distinctly. (a test in your verification file) Mitigates: a development build mistaken for the released device.
- IFU versioned and retained. (deployment configuration) Mitigates: a user reading instructions for software they are not running.
- Unsupported versions stated. (a test in your verification file) Mitigates: continued use of a build no longer receiving safety fixes.
Related
- Device identification panel — the component this pattern places.
- Model version change — what a version change does to results already issued, and why the two versions are separate fields.
- Safety configuration — the other place a change to the device is announced to the people it affects.
- Clinician override — post-market surveillance, which version stamps make possible.
- International design — language obligations for label and IFU.
- Status & limitations — how to read the regulatory claims on this page.