Device identification panel

The electronic label. For software, the box and the leaflet do not exist — so the information a regulation requires on them has to appear on a screen, and this is the screen. Its content list is set by law rather than by design.

Overview

Physical devices carry their identity on the packaging. Software has no packaging, so MDR Annex VI Part C §6.5.4 requires the UDI to be displayed on an easily accessible screen — an "about" screen, a splash screen, a menu — in a readily readable form. The same requirement appears in IVDR Annex VI Part C.

That turns a labelling obligation into a user-interface obligation, and it is the reason this is a component rather than a paragraph in someone's technical file. It is also the screen most likely to be built last, by whoever had capacity, and never reviewed — which is a poor fate for the one screen a vigilance report is written from.

Anatomy

What it must contain

Article and annex references are to MDR (Regulation (EU) 2017/745) and IVDR (Regulation (EU) 2017/746). Applicability depends on your device; this is the superset most software devices draw from.

MDR and IVDR

The structure is the same and the citations differ. Every reference application in this system is a medical device under MDR; none is an in vitro diagnostic, so the IVDR column below is given for completeness rather than worked through.

Symbols

The system ships black, scalable renderings of the symbols a software device normally needs. They do not theme: a regulatory symbol is used black on a light background, so each renders on its own white plate in light and dark alike — the same reasoning that keeps the alarm palette identical across themes.

Symbols outside the core set

The IVDR use-context symbols, and the two that only a non-manufacturer uses. Each carries its status, because the status is what you have to act on — the picture is the easy part.

• Every symbol carries its text equivalent. Symbols are not self-explanatory to every user, and the text is what assistive technology reads. Each rendering above is role="img" with an aria-label.
• The accompanying value sits with the symbol. A manufacturer symbol without the name and address is decoration; a CE mark without its notified body number is wrong wherever a notified body was involved.
• Symbols are never recoloured — not for brand, not for dark mode, not for emphasis. Black on white, both themes.
• Never scaled below legibility, and never distorted. The CE mark in particular is scaled proportionally or not at all.
• Symbol meanings are explained somewhere reachable, which the IFU normally does. Link to it from the panel.
• Never invent a symbol. Every glyph here traces to ISO 15223-1 or to published MedTech Europe guidance, and says which. Where neither exists, use words.
• A non-harmonised symbol never travels alone where its meaning is safety-relevant. It brings the words with it.

The version has to be true

This sounds trivial and is the most commonly broken rule on the panel. A version string typed into a constant is a claim about the build, maintained by hand, and it drifts the first time a hotfix ships.

• Injected at build time from the build system, never edited by a person.
• Includes a build identifier as well as the marketed version, so a support call can distinguish two builds of "4.3.1".
• Matches what the server is running where the device has a server component. A client showing its own version while the analysis runs on a different one is stating something untrue about the device.
• Survives caching. A stale cached bundle reporting the previous version is a real and common failure.
• Available when the product is degraded. The panel must render when the network is down — it is what someone reads out while reporting that the network is down.
• Change of version is announced where it affects meaning — see Model version change, and Regulatory labelling for when a change needs a new UDI-DI rather than a new UDI-PI.

States

Do's and don'ts

Accessibility

• A real description list. <dl> with <dt>/<dd>, so each identifier is programmatically bound to its label rather than merely beside it.
• Identifiers are selectable text, never an image and never a canvas. This is the field most likely to be needed by copy-and-paste.
• Long identifiers wrap rather than truncate — overflow-wrap, never an ellipsis. A truncated UDI is useless (SC 1.4.10).
• Symbols carry a text equivalent in the accessible name; a symbol with alt="" is a legally required item removed from half the users.
• Reachable without authentication and by keyboard from the product's main navigation — see Navigation.
• Readable at 320 px and at 200% zoom. The panel is frequently read on a phone by someone standing next to a workstation.
• Language. The label and IFU must be in a language accepted by the Member State where the device is made available — see International design. The version and UDI stay untranslated.
• Printable. A regulatory panel that cannot be printed or exported cannot be attached to an incident report.

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 user reporting an incident supplies the correct device, version and identifiers. A vigilance report naming the wrong version is an investigation that starts by being wrong.
• Efficiency — time to find the panel, which should be seconds and is typically minutes of searching a settings tree.
• Satisfaction — knowing what the software is licensed to do. The intended purpose statement is the answer to "am I allowed to rely on this for that?", and clinicians ask it far more often than product teams expect.

Clinical safety notes

• Version injected at build time from the build system. Mitigates: a false statement about which software is running, and an unreproducible incident.
• Client and server versions both shown when they differ. Mitigates: an analysis attributed to the wrong build.
• Identifiers unabbreviated, selectable and wrapping. Mitigates: a mis-transcribed UDI in a vigilance report.
• Basic UDI-DI and UDI-DI shown as distinct fields. Mitigates: two identifiers with different regulatory roles being conflated.
• Intended purpose reproduced verbatim. Mitigates: off-label reliance invited by a UI that claims more than was assessed.
• Panel renders offline and unauthenticated. Mitigates: device identity being unavailable at exactly the moment an incident is being reported.
• Symbol slots empty rather than approximated. Mitigates: a non-conforming label propagated to every adopting product.
• Pre-release builds marked unmissably. Mitigates: a development build mistaken for the released device.
• Investigational statement given top position where it applies. Mitigates: an investigational device used as though placed on the market.

Implementation

$ npx shadcn@latest add https://md.notjustany.tech/r/device-label.json

// The version is a build input, never a literal in source. Wire it from
// your bundler's define/env so a person cannot forget to bump it.
const build = {
  version:   __APP_VERSION__,      // from package.json at build time
  buildId:   __BUILD_ID__,         // commit + timestamp
}

<DeviceLabel
  name="AcuteLine"
  intendedPurpose={INTENDED_PURPOSE}   // verbatim from the technical file
  build={build}
  serverVersion={health?.version}      // mismatch is rendered, not hidden
  udi={{ basicDi: "…", di: "…", pi: "…" }}
  manufacturer={MANUFACTURER}
  notifiedBody="0000"
  symbols={["md", "manufacturer", "udi", "ifu"]}
  ifuHref="/ifu"
/>

// A literal version string is the failure this component exists to prevent.
if (process.env.NODE_ENV === "production" && !__APP_VERSION__) {
  throw new Error("[DeviceLabel] version must be injected at build time.")
}

Related

• Regulatory labelling & UDI — where this panel lives, and when a change needs a new UDI-DI.
• Model version change — what a version change does to results already issued.
• Key–value pair — the label/value/unit rules this panel follows.
• International design — language obligations for label and IFU.
• Status & limitations — how to read the regulatory claims on this page.