Status & limitations
What in this system has been verified, what is convention, what is argument, and what is fiction — so you can tell which is which before relying on any of it.
A design system is not a medical device, and cannot itself be clinically validated. Clinical evaluation and usability validation are properties of a finished device in its intended use, established by its manufacturer. No design system, component library or style guide can hold them on a manufacturer's behalf — not this one, and not any of the large enterprise systems either.
That is not a shortcoming to apologise for; it is how the regulation works. A manufacturer adopting this system must perform usability engineering under IEC 62366-1 and clinical evaluation under MDR Article 61 or IVDR Article 56 exactly as they would with any other design input. What this system can do is give that work a documented, reasoned and partly machine-verified starting point — shortening it, never replacing it.
Clinical evaluation (MDR Art. 61 and Annex XIV) establishes clinical safety, performance and benefit–risk for the device. Usability validation (summative evaluation under IEC 62366-1, satisfying MDR Annex I Chapter I §5 on use error) establishes that intended users can operate it safely in the intended environment. They are different activities with different evidence, and "clinically validated" is often used loosely to mean either. Both remain the manufacturer's, and neither is transferable between products.
Provenance
What this system is and is not derived from, stated plainly so the question does not have to be reconstructed later.
| Layer | Origin |
|---|---|
| Component architecture | shadcn/ui — Radix primitives, Tailwind, copy-in source distribution. The actual technical foundation. |
| Alarm priorities and hues | IEC 60601-1-8 directly. Red / yellow / cyan and the high / medium / low scheme come from the standard, not from any vendor's interpretation of it. |
| Accessibility thresholds | WCAG 2.2, with every ratio computed rather than asserted. |
| Vocabulary and structure | ISO 9241-11:2018 for usability, context of use and use error; ISO 9241-210/-220 for the human-centred design framing. |
| Brand | NotJustAnyMed.Tech — teal, cream, Fraunces and Inter, bound to the shadcn token contract. |
| Documentation architecture | The overview → principles → anatomy → variants → best-practices page shape is a convention shared across enterprise clinical design systems. Convergent structure, independently written content. |
| Written guidance and examples | Original. All prose, rules, worked examples, waveforms and every reference application were written for this system. No third-party design system's documentation, tokens or components were copied or adapted. |
No claim is made or implied that this system inherits validation, evidence or regulatory status from any other organisation's design system. Validation does not transfer between products, and a borrowed claim would not survive the first question a reviewer asks.
How to read a claim
Every assertion in this system falls into one of five classes. They are written in the same tone and carry very different weight.
| Class | Means | Examples | What you must do |
|---|---|---|---|
| Computed | Calculated and machine-checked. Reproducible on demand. | All contrast ratios · the ΔE separation between brand coral and IEC red · every colour ramp step · every cross-reference and class name in these pages | Nothing — run npm run check to reproduce. Both gates have been
negative-tested against injected violations of every class they claim to detect. |
| Standard | Traceable to a published standard. | IEC 60601-1-8 alarm priorities and hues · WCAG 2.2 thresholds · ISO 9241-11 vocabulary | Verify against the current edition. This system paraphrases; it is not a substitute. |
| Convention | Widely used figures from ergonomics and industry practice, reproduced here without primary sourcing. | 10 mm / 12 mm touch targets · 12 px type floor · 35 % translation expansion · motion durations · viewing-distance bands | Substantiate for your own device. These are starting points, not validated thresholds. |
| Reasoned | Design rationale reached by argument. Defensible, unevidenced. | Alarms are never modals · no bulk acknowledge · confidence is never the default sort · withhold a score outside validated scope · symmetric agree/disagree | Treat as a hypothesis to test, and as an input to your hazard analysis — not its output. |
| Fiction | Invented for illustration. | Every reference application and everything about them · all patient names, MRNs, timings and values · all ECG waveforms · reference ranges in examples | Never reuse as clinical content. The waveforms are synthetic and not of diagnostic quality. |
Every Clinical safety notes entry — every "Mitigates: wrong-patient selection" — is a Reasoned claim. It is a design rationale explaining why a behaviour exists. It is not the output of a hazard analysis, has no severity or probability attached, and does not discharge any obligation under ISO 14971. Use them as candidate hazards and candidate controls to feed into your own risk process.
What is actually verified
A short list, deliberately. Everything here is machine-checked in CI on every change, and the report is retained for 90 days as design-control evidence.
- Contrast. 40 token pairs measured against documented minimums, in both themes, including control boundaries and focus indicators against every surface they can sit on.
- Alarm token integrity. The IEC hues are identical in light and dark, are declared in exactly one place, and cannot be overridden by a theme, a customer skin or a hard-coded literal.
- Source-of-truth sync. The shipped stylesheet provably matches
tokens/tokens.json. - Markup integrity. Every page validates; no broken links, no duplicate ids, no unlabelled inputs, no table header without a scope, no dangling ARIA reference.
Note what is not on that list: whether any of it helps a clinician. Contrast compliance is a necessary condition for legibility, not a demonstration of it.
Validation roadmap
Every Reasoned claim above is testable, and each has a study design with a stated falsifying result. That plan now lives on its own page so it can be sent as a single link.
Validation roadmap — twenty-nine claims, their study designs, what would prove each one wrong, and the order in which running them would move the most. No studies have been completed.
Known gaps
| Gap | Consequence |
|---|---|
| No clinician has reviewed or used any screen here | Several Reasoned rules may be wrong in ways only practice reveals. This is the gap most worth closing first, and the one a manufacturer closes for their own device anyway. |
| No formative or summative usability evaluation | No measured effectiveness, efficiency or satisfaction data exists. See Usability & context of use. |
| Maintenance and service screens are still undesigned | Alarm rule configuration is now covered by Safety configuration, but device commissioning, calibration records and service mode are not. They carry the same deployment-wide blast radius and none of the same attention. |
| Regulatory labelling guidance is not legal advice | Device identification panel and Regulatory labelling & UDI paraphrase MDR and IVDR to derive design rules. No regulatory professional has reviewed them, no notified body has commented, and the citations are to texts that are amended. Verify every one against the current consolidated regulation. |
| Iconography is out of scope | Text glyphs stand in for a real icon set. Icon metaphor testing has not been done. |
| No internationalisation testing | The 35 % expansion budget is asserted, not tested. No RTL rendering has been checked. |
| Audio alarm design is referenced but not specified | IEC 60601-1-8 covers auditory signals in detail; this system covers only the visual half. |
| Charts are specified but untested with clinicians | Data visualisation now sets axis, comparability and aggregation rules, and they are Reasoned claims. Whether a fixed axis actually changes what a clinician perceives has not been measured. |
| No lay-user comprehension testing | Lay & patient-facing design now sets the register, the numeracy rules and the measures. Every one of them is a Reasoned claim: whether a lay reader understands a result, a limit or an instruction to seek help is measurable, and has not been measured here. |
| The home and personal-device context is asserted, not specified | Five of the six reference applications have context profiles written from reasoning rather than observation. The home context — a phone, in bed, one-handed, by a user who may be cognitively impaired at the moment of use — is the least evidenced of them and the one carrying the highest per-event hazard. |
What the manufacturer must still do
Adopting this system changes where your usability engineering work starts, not whether you do it. Under MDR or IVDR the following remain entirely yours:
- Write your own context of use. Replace AcuteLine's specified users, goals and environment with yours. Nothing here transfers unexamined to a different context — which is the same reason no other design system's validation would transfer to you either.
- Run your own use-related risk analysis under ISO 14971, integrated with the usability engineering process. The safety notes here are candidate hazards and candidate controls; you derive the real ones, with severity and probability.
- Substantiate every Convention figure — touch targets, type floor, expansion budget — for your device, users and displays.
- Do formative evaluation early with representative users in a representative environment, then summative evaluation per IEC 62366-1, satisfying MDR Annex I Chapter I §5 on risks related to use error.
- Perform clinical evaluation under MDR Article 61 and Annex XIV, or performance evaluation under IVDR. Separate from usability validation, and equally non-transferable.
- Version-pin what you adopt. Components are copied into your repository — record the version, and re-assess on update.
- Get clinical review of every piece of copy. The alert wording here is illustrative and has not been reviewed by a cardiologist.
What you inherit instead of validation: a documented rationale for each decision, contrast evidence you can reproduce in CI and cite directly, and an alarm layer that already follows IEC 60601-1-8 rather than one you have to retrofit. That is a head start on the file, not a substitute for it.
Standards referenced
Two different kinds of reference appear throughout, and the pills distinguish them.
| Standard | Kind | How it is used here |
|---|---|---|
| IEC 60601-1-8 | Assessable | Alarm priorities and their mandated hues. Governed tokens; enforced in CI. |
| WCAG 2.2 AA | Assessable | Contrast, focus, non-text contrast, reflow. Measured, not asserted. |
| IEC 62366-1 | Assessable | Named as the destination for usability engineering work. This system does not perform it. |
| ISO 14971 | Assessable | Named as the destination for risk management. This system does not perform it. |
| ISO 9241-11:2018 | Framework | Vocabulary and structure only. It has no requirements and cannot be conformed to. |
| ISO 9241-210 / -220 | Framework | Human-centred design process context. Referenced, not applied. |
Where this system says a component is "IEC 60601-1-8 aligned", that means its colours and priority levels follow the standard's scheme. It does not mean the component, or any product built with it, has been assessed for conformity. Conformity is a property of a finished device in its intended use, assessed by you.
Authorship and how to challenge it
This system was drafted rapidly as a design and teaching exercise, not by a multidisciplinary team over a product cycle. It has one author's judgement in it and no clinical co-author. That is worth knowing when a page states something with confidence.
If a rule here looks wrong to you and you have clinical or human-factors experience, it probably is wrong and should be changed. The Reasoned class is the one to attack first.
Do's and don'ts
These are about how to describe this system in your own documentation — the place where an overstatement is most likely to survive into a regulatory submission.
"Our alarm colours and priority levels follow the IEC 60601-1-8 scheme, as implemented by the NotJustAnyMed.Tech design system. Conformity assessment for our device is documented in § X."
Separates the design convention from the conformity claim. Both are true, and a reviewer can check each one independently.
"Our interface is IEC 60601-1-8 compliant because it uses a compliant design system."
Compliance is a property of a finished device in its intended use. A design system cannot transfer it, and no design system can grant it.
Cite the Verified claims — contrast ratios, theme parity, hue separation — with the CI report attached.
These are computed, reproducible and dated. They are the only claims here that come with machine-checkable evidence.
Cite the Reasoned claims as though they were evidence.
They are argued design positions with a stated rationale. That is useful input to your risk file, not a substitute for your own evaluation.
Read this page before the component pages, and read it again before quoting one of them.
Every page in this system states rules with confidence. This page is the one that says how much of that confidence is earned, and by what.
Treat the absence of a known gap as evidence there is none.
The gaps listed above are the ones the author found. A single-author system with no clinical co-author has gaps nobody has looked for yet.
Related
- Validation roadmap — what would move a claim from Reasoned to Evaluated, and what would not.
- Using the system — the split between what the system provides and what stays your responsibility.
- Contributing — how to challenge a rule, and what a proposal has to contain.
- Usability & context of use — why an outcome of use cannot be asserted by a design system.
- Tokens & governance — the checks behind every Verified claim on this page.