NotJustAnyMed.Tech Design System
Start

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.

Draft · v0.1 Design input — not a device
What kind of thing this is

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.

Two obligations, often confused

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.

LayerOrigin
Component architecture shadcn/ui — its token contract and its copy-in model, with Tailwind. Not its dependencies: no Radix, no cva, no clsx. This row said “Radix primitives … the actual technical foundation” while the registry page said “None at runtime. Not clsx, not tailwind-merge, not Radix.” Every interactive behaviour here is hand-written, which is why the interaction gate kept finding behaviours that were published and absent.
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.

ClassMeansExamplesWhat 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 · every “the component holds this” row, through the assertion it names · what a component does under a keyboard, and what its accessibility tree says Nothing — run npm run check, check:interaction and check:visual to reproduce. All seven gates run in CI on every change, and every rule and assertion in them was negative-tested against an injected violation when it was written.
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.
The most important line on this page

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. Where a bullet says (the component), the behaviour is Computed — a named assertion proves the component does it — and the mitigation is still Reasoned: that the behaviour reduces the hazard is an argument, not a measurement.

What is actually verified

Everything here is machine-checked in CI on every change by seven gates, and each gate’s report is retained for 90 days as design-control evidence. The list is longer than it was, and it is still a list of things a machine can see.

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, and a component that provably does what its page says has still never been used.

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.

Moved

Validation roadmap — thirty-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

GapConsequence
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.
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.
The AI and imaging pattern rules have no field evidence The imaging and composed-text pages are argued from the EU AI Act and from first principles. Article 14 gives them a Standard-class spine — a person must be able to understand the limits, resist automation bias, interpret the output, decline it and stop it — but everything about how to achieve that on screen is Reasoned. No clinician has used any of it.
Source binding is asserted to work, not measured Composed output requires every clinically material assertion to bind to a source in one action, and withholds anything unbindable. Whether readers activate those bindings under time pressure, and whether an omission notice changes what they go and check, is measurable and has not been measured here. Both are on the roadmap.
The generative and imaging patterns now have a component under them, and it holds the shape, not the truth Composed text makes a sentence without a source, a self-citation, an “author”, an overall score and a partial document unwritable through its props. Spatial finding holds the words beside an image: the address in the reader’s units, marks off by default behind a control that cannot be labelled “explain”, nothing-marked scoped and never “normal”, and navigation as the only recordable act. Between them, fourteen pattern rows moved from “the implementer” to a cited assertion. What neither can hold is whether a binding is true or a mark is right; that stays with the composer and the detector, and the pixels stay with a viewer this package does not ship.
Attention is deliberately not measured, and that is a bet Editing the draft rejects forced scrolling, per-section confirmations and dwell timers on the grounds that they manufacture an audit trail nobody earned. The counter-argument — that the friction catches real errors and the objection is only to the record it produces — is plausible and untested. If it turns out to be right, this rule is wrong.
Serially autonomous software is not covered at all Multi-step agentic action has little published human-factors literature and no harmonised standard, so the register carries it as held rather than guessing. That is an honest position and still a gap: software of this kind is being built, and this system has nothing to say to anyone building it.
The registry has never had a consumer The 44 items behind the install commands typecheck under strict, are render-tested in Node, and are now driven in a real browser by the interaction gate — which is how several of them were found not to do what their page claimed. What remains untested is everything about use: no touch device, no screen reader, no gloved hand, nothing read right-to-left by a person, and no application other than the harness. Treat it as a reference implementation of the rules, not as a validated library.
The published code samples described a library that was never built Thirteen of twenty-nine component pages documented an API that does not exist: shadcn's compound form on Dialog and Tabs, an invented SpinBox and Slider, a CompareIcon in a system with no icons, and on six pages a runtime throw presented as a guarantee the component makes. All rewritten against the real signatures, and the registry gate now refuses any example naming a component the registry does not export, a prop it does not take, a union member its type does not declare, or an import that does not resolve. What it cannot check is whether the example means what the prose beside it says.
What a component enforces is now separated from what it asks of you, on every page that ships one A rule stated on a component page reads as a rule the component enforces, and on most pages that was false — usually in the safety-critical half. All 37 pages that ship a component now carry the split, and the documentation gate holds the number as a floor. Search cannot impose a minimum query length, stop results reordering, or prevent fuzzy matching on an identifier. Alert banner cannot re-assert, escalate or rate-limit, which is most of what IEC 60601-1-8 turns on. Radio cannot stop a clinical question being pre-answered. Device identification guarantees the panel is complete and nothing about whether it is correct. Every row claiming “the component” now cites the assertion that proves it, by name and visibly, and the registry gate refuses both a citation that does not resolve and a claim that cites nothing. Writing those assertions found one row that was simply false: Text field said the component turns off browser autofill on identifier fields, and it sets no autocomplete at all. That row now says you. Seven more cited an assertion that resolved without testing the row, and were rewired to ones that do. What no gate can check is still the same thing: whether a cited assertion tests what its row claims. The first 131 citations were read against their rows as a batch; the 155 written since were written with their rows. Twelve did not test them — a dialog claiming an inert background cited an assertion about focus entry; a toolbar claiming its separators are not focusable cited one about roles and labels. Nineteen assertions were written to replace them, three of which needed a browser: a route change really moving focus, the document title really following the view, and a tooltip really having no timeout of its own. A word-overlap heuristic was tried as a gate and rejected — it flags 35 of 131 and most are correct citations in different vocabulary, so it would train a reader to skim it. This one is read, not checked.
The event log exists now, and almost nothing about it is enforceable here Toast queue, alert banner and acknowledge & escalate each rested a safety argument on a durable record that had no component. There is one now — Event log — and it is append-only by the shape of its props: no onEdit, no onDelete, no onClear. But five of its ten rules are the reader’s, and they are the five that matter: whether your storage permits an update to a recorded event, whether the record is complete, whether the times are in one zone, whether the order is real, and whether anything is tamper-evident. A rendering cannot make a record trustworthy. It can only avoid misrepresenting one.
Every pattern page says which component holds each rule, and 184 of 316 are held by nobody A pattern page has no component under it. Each of its rules is either held by a component this package ships, or is the implementer’s, and until now none of the 29 pages said which. They all do: 131 rules are held by a component and cite the assertion that proves it, one is deployment configuration, and 184 are the implementer’s — including re-assertion, escalation and rate on Acknowledge, every rule about mode and the stop on Therapy, and every word of what an autonomous result says to the least expert reader in the system. The tables are a checklist for a manufacturer building against a pattern, and the count is the honest size of what the package does not do for them.
A rule written on one page does not reach the others it applies to Every gate checks whether a page agrees with itself and with the code. None can ask whether an argument made in one place should have changed something in another. Date & time picker rejected “leave blank if unknown” on the grounds that a blank records nothing about why it is blank — an argument about blanks, not about dates — while Text field went on printing that exact hint in its own demonstration. It was found by reading the two pages against each other, which is not a process. Assume there are others.
The component API is asserted to prevent misuse, not observed to Several types exist to make a prohibited thing unexpressible — no max on Badge, no alarm tone on ToastQueue, no bulk acknowledgement anywhere. Whether that actually stops a team under deadline pressure, or whether they simply stop using the component, is an empirical question nobody has asked.
Printing is newly specified and untested on paper Seventeen pages argued that something "survives a printout" while no print stylesheet existed. One now does, and Printed output states what a printed clinical document must carry. None of it has been run through an actual printer, and paper size, driver and duplex behaviour are exactly where print rules fail.
Interaction coverage is narrow, not absent check-interaction.mjs drives a browser and asserts 120 behaviours the other gates cannot reach — focus on open, arrow traversal, Escape and focus return, outside-click dismissal, the confirmation delay, keyboard parity on a tooltip, wrong-patient wiring on search, a filter tag removing only itself, a pager stopping at its ends, an alarm acknowledgement taking its control away, a time recorded as unknown staying unknown. It covers 22 of the 59 components; the rest either have no handlers to drive or hold only aria-current, which the render gate asserts. Twenty-six of the 120 read Chromium’s accessibility tree through its debugging protocol rather than the DOM — the computed role, name, description and states, which is what a screen reader receives rather than what the code wrote. The first run found that the dialog’s “inert background”, claimed on its page three times and held by the component in its guarantees table, was aria-modal and nothing else: the control that opened it was still in the tree. It is inert now. Everything else transient is still asserted in prose only, and no gate exercises a real screen reader, a touch surface or a gloved hand — the tree is what one would receive, not what one would say.
Iconography is out of scope Text glyphs stand in for a real icon set. Icon metaphor testing has not been done.
Two components were adapted before they were scrutinised Accordion and Progress were first written by following another system's page structure, which imported one of its omissions: a hand-built accordion whose collapsed content the browser's find-in-page cannot reach. That is now fixed and the construction is native <details>, but the episode is the gap: adapting a good system uncritically inherits its blind spots, and nothing in the seven gates detects a missing idea.
Safety notes were audited bullet by bullet, once Every clinical safety note on a component page — 216 bullets on 40 pages — now says who holds it, judged one at a time against the guarantees table and the code. The audit found two components doing the opposite of what their own safety notes listed as a risk control: the tab strip selected on arrow under a bullet that said manual activation, and the patient search set no autofill guard under a bullet that said no browser autofill. Both are fixed and asserted. The gate now refuses a bullet with no holder, which stops the next one arriving unjudged; it cannot tell whether the judgment was right. The 29 pattern pages had the same pass with a different question — every bullet there is the implementer’s, so each of the 264 now says what checks it: a component that holds the rule (validated against the page’s own guarantees table), a test in the verification file, deployment configuration, post-market surveillance, or a design review no test can see. 45 are held by a component, 187 are tests, 21 are design review, 7 are configuration and 4 are surveillance. The gate refuses an untagged bullet on either page type. What it cannot do is confirm the test exists in anyone’s file.
A page split leaves its old names behind in the links Five pages were split into eleven a fortnight ago, and the prose kept pointing at the old ones: fourteen links still read “List & tree”, “Badge & pagination”, “Menu & popover” or “Skeleton & pending value”, and five named a different page than the one they opened — three saying “Progress” while pointing at Skeleton and Pending value, one saying “breadcrumb” while pointing at Navigation, one saying “Navigation” while pointing at Side navigation. Every link in this system resolved the whole time; the words above the href were the stale part, and no gate read those. One does now: link text that is exactly the title of a different page fails the build. Paraphrase is untouched, because the rule only fires when the words name another real page.
Every component was re-read line by line, and fifty defects were in the code or its pages All 45 source files were read against their pages, and every behavioural finding was proven by an assertion that failed against the code before anything changed. The serious ones were clinical. Numeric input’s steppers stepped from a refused entry: with 40 mL/h committed and 250 typed into a 1–99 setting, Decrease committed 99. Stepping an observation pulled a recorded 250 to 100, and 0.2 + 0.1 committed 0.30000000000000004. Date & time picker stored a time with no precision when typed into before one was chosen, and of six precisions it offered, four recorded facts nobody entered. Clearing a patient search left the last patients clickable under an empty box. Radios without a shared name took two answers to a yes/no question. Then the accessibility claims: units missing from the names of dose and weight fields, focus thrown to the top of the document after acknowledging an alarm or removing a filter, a toast that never left a busy screen, a tooltip that deleted its field’s hint, every route change announced twice. And the pages: sixteen props tables documented 56 props that do not exist — a richer, primitive-library API the components were never built to — including a dialog variant whose decide mode, built with this component, would make Escape choose an option on a question with no safe default. The registry gate now refuses a props-table row that names no real prop, and a shipped file whose header names another page. The test files were outside the type-checker until this pass, so three guards calling themselves compile-time checks were checking nothing; they are type-checked now. The gap this pass first left open — the interaction harness loaded no stylesheet, so nothing about layout in the components themselves had been observed — is closed: the harness now compiles the components’ classes with Tailwind and the token values shadcn add writes, and measures. The first measurements found an alarm under a dialog’s scrim and inert while it was open, a mixed checkbox drawn as an empty one, and a 16 px button, and confirmed the tooltip gap that had been fixed on reasoning alone. Contrast inside the components is now measured in both themes. Colour as perceived, and anything a person would call legible, are still not measured.
Keyboard claims were read against the code, once Every accessibility, safety and guarantees bullet on a component page that names a key or a keyboard behaviour was listed beside the code it describes. Six did not match. Three described a construction that does not ship — a spinbutton with arrow stepping, a combobox with a listbox, a heading wrapping a button — and now describe what does, with the reason. Three described behaviour the component lacked and now has: the tree had role="tree" and a button in every item with no traversal behind it; the menu’s type-ahead read no printable key; the pager removed its end controls from the keyboard with a native attribute under a bullet that said aria-disabled with a reason. The tabs episode a day earlier was the fourth. All are driven in a browser now. The scan is a script in the scratchpad, not a gate: it finds bullets that mention keys, and a person still reads them against the code.
Rendered right-to-left; not yet read right-to-left Every page now renders under dir="rtl" through the visual gate’s --rtl mode, with the direction proved to have taken before anything is measured: 600 renders, nothing overflowing, nothing clipped, every pair meeting its ratio, in CI on every change. That is the first time this system has been rendered right-to-left at all. It proves the layout does not break mirrored. It does not prove the layout mirrors: the physical inset declarations that remain in the stylesheet position overlays, and an overlay on the wrong edge overflows nothing. Closing that needs a reader of a right-to-left language at a screen, which no gate replaces.
The visual gate cannot see most of what a person can check-visual.mjs renders 100 pages at three widths in both themes and checks overflow, clipping, rendered contrast and navigation state. It says nothing about whether a layout is legible, whether an alarm draws the eye, or whether a screen makes sense — and it had to be corrected five times before its own output was worth reading. Treat a green run as the absence of four specific defects, not as evidence of quality.
No internationalisation testing with a person The 35 % expansion budget is asserted, not tested: no page has been rendered with translated strings. Right-to-left has been rendered by the gate and read by nobody — see the row above.
Audio alarm signals are specified and have never been heard Auditory alarm signals now sets the rules and says on its first screen not to implement a sound from it. No signal has been generated, measured or listened to; every gate here is silent.
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 Every one of the seven reference applications has a context profile 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:

  1. 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.
  2. 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.
  3. Substantiate every Convention figure — touch targets, type floor, expansion budget — for your device, users and displays.
  4. 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.
  5. Perform clinical evaluation under MDR Article 61 and Annex XIV, or performance evaluation under IVDR. Separate from usability validation, and equally non-transferable.
  6. Version-pin what you adopt. Components are copied into your repository — record the version, and re-assess on update.
  7. 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, a library whose every enforced rule names the assertion that proves it, 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.

StandardKindHow it is used here
IEC 60601-1-8Assessable Alarm priorities and their mandated hues. Governed tokens; enforced in CI.
WCAG 2.2 AAAssessable Contrast, focus, non-text contrast, reflow. Measured, not asserted.
IEC 62366-1Assessable Named as the destination for usability engineering work. This system does not perform it.
ISO 14971Assessable Named as the destination for risk management. This system does not perform it.
ISO 9241-11:2018Framework Vocabulary and structure only. It has no requirements and cannot be conformed to.
ISO 9241-210 / -220Framework 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.

Do

"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.

Don't

"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.

Do

Cite the Verified claims — contrast ratios, theme parity, hue separation, and the named assertion behind any “the component” row — with the CI report attached.

These are computed, reproducible and dated. They are the only claims here that come with machine-checkable evidence, and the second kind proves a behaviour, not that the behaviour helps.

Don't

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.

Do

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.

Don't

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.

NotJustAnyMed.Tech Design System · Status & limitations · v0.1
Reference applications named in this system are fictional; all patient data shown is fabricated.