Spine · Clinical operations
Spine is the role-aware design system for Hospital OS. It turns patient safety, permissions, accessibility and clinical workflow into reusable interface standards — one operating language across five teams and every handoff between them.
01 / The problem
One outpatient journey moves through reception, consultation, diagnostics, pharmacy and revenue. Each team has its own software habits, its own vocabulary and its own idea of what “done” means. Every handoff is a chance to lose context, duplicate work or make an unsafe assumption.
A note written in consultation has to mean the same thing in pharmacy, without the pharmacist reading the whole chart.
Reception needs breadth and speed. A clinician needs depth. Building for both by building for neither is the usual outcome.
When the same action looks different in two workspaces, people slow down or guess. In a hospital, guessing has consequences.
02 / Patient identity
Wrong-patient error is the failure mode a clinical system exists to prevent. So the answer to “who am I looking at, and may I act?” is never more than zero clicks away — the identity bar is persistent, unscrollable and identical in all five workspaces.
The bar never scrolls away. Wrong-patient error is the failure mode this system exists to prevent.
Not a field in a panel three clicks deep. It sits beside the name, in red, at every workspace.
Whether you may act is part of who you are looking at, not a separate check.
The same bar renders in reception, consultation, diagnostics, pharmacy and operations. Only the actions beside it change.
03 / Role workspaces
A generic clinical UI serves everybody equally badly. Spine keeps one model and varies three things per role: how much is shown, what can be done, and what is deliberately withheld. Changing the model per role would have produced five products to maintain.
Every workspace renders the same patient object. What changes is density, available actions and permission — never the underlying model.
Hiding information is a design decision with a clinical consequence, so each omission is recorded rather than assumed.
04 / System states
Most design systems document the happy path thoroughly and the rest in a paragraph. In hospital software the exception states are where harm happens, so each one is a first-class pattern with its own rules about what it must say.
Skeleton shaped like the content
Explains why, offers the next action
States what is missing, not just that data is incomplete
Clinical risk surfaced before the action, not after
Names the cause and the recovery path
Says what is safe to do while disconnected
Shows that data exists, and who can unlock it
Restricted is not the same as empty. A clinician who sees nothing assumes nothing exists. A clinician who sees a locked record knows to ask. In a hospital that difference is a safety property, not a nicety.
05 / Privacy, access and audit
A permission model that makes urgent access impossible gets worked around with shared logins — which is worse than what it was protecting against. So break-glass access exists, requires a reason, and is visible in the record afterwards.
06 / Documentation structure
The chapters are not an alphabetical index. They group by what they are for: the shared vocabulary, the parts that make it a hospital rather than a generic product, the obligations that are not negotiable per screen, and the machinery that keeps the system alive after the person who wrote it moves on.
The shared vocabulary everything else is built from
Where the system stops being generic and becomes a hospital
The requirements that are not negotiable per screen
How the system survives the people who wrote it
Documentation that stays true
The reference images are captured from the running application with Playwright, not exported from Figma. Documentation that drifts from the build is worse than none — teams stop trusting it, then stop reading it.
One command regenerates every render at a consistent viewport, so the system’s own documentation cannot quietly go stale.
07 / Governance
Most design systems fail for organisational reasons rather than visual ones. Spine documents contribution, review, ownership and release with the same care as the components.
A team hits a gap and writes the case, with the workflow it blocks
Checked against principles, accessibility and clinical safety
Adopt, adapt an existing pattern, or decline with the reason recorded
States, permissions and content rules written before code
Versioned, with a migration path for what it replaces
Declining a request is a documented outcome, not a silence. A design system that only ever says yes becomes a component dump; one that says no without a reason gets routed around. Both fail the same way — teams stop trusting it and fork.
08 / The system itself
A design system that only exists as a case study is a proposal. This one is built and running — fourteen chapters, five role workspaces and every state documented against the interface that implements them.
Not screenshots of a design file — the deployed documentation site. Jump to a chapter below, or open it full screen.
Loading overview…
Overview — System scope, the OPD journey and who each workspace is for.
09 / Principles
Principle 01
Identity, allergy and consent sit in a persistent bar that never scrolls away, in every workspace. Wrong-patient error is the failure mode a clinical system exists to prevent, so the answer to “who am I looking at?” cannot be more than zero clicks away.
Principle 02
Reception, clinicians, diagnostics, pharmacy and operations see the same underlying object rendered at different depths. Changing the model per role would create five products; changing only the density and permissions keeps one.
Principle 03
A clinician who sees nothing assumes nothing exists. One who sees a locked record knows to ask. Distinguishing absence from denial is a safety property, and it earns its own state rather than collapsing into a blank panel.
Principle 04
Break-glass access is possible, requires a stated reason, and is visible in the record afterwards. A system that makes urgent access impossible gets worked around with shared logins — which is worse than the thing it was protecting against.
Principle 05
Clinical writing is terse for a reason, and terse writing goes wrong in specific ways. Terminology, label structure and multilingual behaviour are documented alongside components, because a correct component with the wrong words is still an unsafe screen.
Principle 06
Contribution, review, ownership and release are documented as carefully as the components. A system that only says yes becomes a component dump; one that says no without a reason gets routed around. Both end in teams forking it.
Scope, honestly
Spine is a portfolio design-system case study and interface prototype built around Hospital OS, a conceptual platform. It is not production medical software and has not been through clinical validation. The demonstration data is fictional. What it is meant to show is how the safety, permission and workflow requirements of a clinical product translate into interface standards a team could actually build against.
Continue exploring
Hospital OS — 11 operational domains and 42 departments, mapped from vendor research before a single screen was drawn.
