A hospital-defined standard, digitised. For example, hypertension management.
01 Selected work / CareLogic
Enterprise healthcare · Pre-market
Clinical Decision Support Platform
CareLogic.
Good care,
no matter who’s
on shift.
A no-code platform that lets hospital teams author their own clinical protocols and delivers the right guidance to the bedside, in real time, so good care reaches the patient no matter who's on shift.
The project where I learned that the most important design work isn't on a screen.Protocol update cycle6 months
Designed targetMinutes
System model Everything reduces to “if this, then that”
NDA-safe architecture view
One clinical standard.
Four machine-readable layers.
Assessment, medication and labs, running alongside each other.
Conditions on patient data, grouped with AND / OR.
The guidance, surfaced only when a rule fires.
Three applications express this model: Decision Studio (author) · Settings (configure) · Micro Frontend (deliver).
01
The stakes
Raising
the floor.
The premise of clinical decision support is uncomfortable but true: the quality of care a patient receives depends on which clinician happens to be on shift.
Some are excellent; some are exhausted, mid-double, three patients behind. CDS exists to narrow that gap, so the care that matters reaches the patient no matter who's delivering it.
The care that is important is often not delivered, and the care that is delivered is often not important.
That's the mission: not to replace clinical judgment, but to raise the floor beneath it. The goal is to lift the people who are struggling without insulting the people who aren't.
01.1 / The bottleneck
The problem was a six-month gap.
Updating a clinical protocol traditionally took up to six months. A hospital decides to change a care pathway; the vendor codes the change; the change ships in a software release. In the meantime, patients are treated on the old protocol. The bottleneck wasn't medicine. It was the software in the middle.
The fix was to decentralise authoring: let hospitals update their own protocols. But the people who own clinical protocols are clinicians and informaticists, not developers, so it had to be a no-code tool. And it had to be flexible enough to sit inside any product and produce the right guidance for any patient, clinician, or condition.
6 moProtocol update cycle, before
MinutesUpdate cycle, after
3Applications, one platform
No-codeClinicians author directly
02
The mental model
The platform
as a theatre.
The clearest way I found to explain the whole system is as a theatrical performance. Every part of the platform has a counterpart on a stage.
The prompter is the key role. It doesn't perform, and it doesn't take over the scene. It waits, watches the script against what's happening on stage, and speaks only when the actor needs the line.
That one idea—an attentive prompter working quietly, one per patient—shaped almost every interaction decision that followed.
03
The architecture
UX led the
architecture.
The most consequential design decision was not an interface. It was the decomposition of the system into three applications.
That decomposition came from UX, then was agreed with product and engineering. It was the first time on this platform that product and design defined the architecture together, rather than design receiving it.
A single application would have been simpler to build. It would also have been the wrong answer. The author, administrator and clinician each have different mental models, access and stakes. Forcing them through one surface would have made all three worse. The architecture was a design output.
Clinical teams digitise approved protocols with no code.
BuildOperations teams enable protocols by hospital and care unit.
GovernClinicians receive guidance inside the product already in use.
ActApplication 01 / Author
Decision Studio.
Where clinical teams build their protocols, with no code.
The hard problem was epistemic: give a clinician a tool expressive enough to capture real clinical logic, yet structured enough that the output is machine-deployable. Underneath, every protocol resolves to the same shape: workflows of rules, and rules of conditions and actions. If this, then that.
Output first.
I designed the clinician-facing output cards before anything else—heading, critical message, scheduled and unscheduled tasks, completion values—then reverse-engineered the authoring tool to produce exactly those. The author's tool was shaped by the reader's need, not the other way around.
Grouping over ranking.
When two rules fire at once, authors don't write boolean expressions. They select conditions and group them, and the system handles the logic. It blocks combinations that are logically impossible, but does not judge whether a protocol makes clinical sense.
Studio is an open authoring tool, not a medical device. Clinical authority sits with the approved source protocol, not the software.
Application 02 / Configure
Settings.
Configuration and governance for consequential systems.
Where hospitals are onboarded, protocols are enabled per care unit, and display order is set. Less visible than Studio, equally complex: the design problem is making consequential configuration legible to operations staff who are not clinical informaticists. This is also where one of the more interesting decisions lived: there is no sign-off step, and that was deliberate.
Active protocols › Configure protocols › Set display order
Subscriptions
Drag to set the display order for protocols with display set to “On”.
OrderProtocolTypeDisplay
⠿ 1Hemorrhage CMQCCCustomOn
⠿ 2Hypertension CMQCCStandardOn
⠿ 3Labour ManagementStandardOn
⠿ 4Maternal Sepsis Evaluation CMQCCStandardOn
Application 03 / Deliver
The bedside.
A micro frontend embedded in the clinical product already in use.
The guidance itself: a panel inside the host product, reserving a section of the screen for stacked, scrollable cards. The behaviour of those cards carried most of the interaction design.
The users don't see anything unless there is something going wrong with the patient.
Silent until actionable. While the patient is normal, the card shows nothing. Blood pressure normal → nothing. Blood pressure elevated → “recheck in 15 minutes.” The clinician is shown output, never the running logic.
Compliance, not dismissal. Cards persist until acted on; a missed timed task shows as overdue. They are read-only: the clinician documents in the EMR, and CDS reflects that—a one-way relationship by design.
Alerts are authored, not invented. Severity is defined inside the approved protocol, not chosen on the fly; an alert can override card ordering, jump to the top, and escalate when a follow-up rule fires. The software only provides the primitives.
Clinical outputCondition → authored guidance
BP is in range. The prompter stays silent.
A rule fired. A timed task appears and persists until done.
Authored severity. Escalates medium → high if unmet.
04
Constraints & governance
The honest
compromise.
The rules engine is reactive: it processes only when a new value arrives.
It can't go and fetch a value on its own; it can't decide to check a patient's weight. So a protocol can't simply ask a question. It has to wait for the answer to walk in.
We worked around it with pre-checks that gate when a protocol triggers, and with actions that fire on flow-start to pull the data a protocol will need up front. It works. But it's a workaround.
The cleaner design—an engine that can reach for what it needs—was out of reach within the platform's constraints. Naming that honestly is part of designing inside real systems.
04.1 / Protocol lifecycleMake
Make
“is this live?”
answerable.
A protocol moves through a defined set of states, each with an owner and an audit trail.
Authored in Decision Studio. Not visible to clinical users.
Code-level correctness: open threads, paused flows, action-less rules.
The hospital tests it against its own patient context, not a generic simulator.
In review. Any edit drops the protocol back to Draft.
Released and running in the live clinical workflow.
Decision removed
An earlier architecture had a formal sign-off before publishing. We removed it once we recognised the task: source protocols are already authority-approved documents being faithfully digitised. The job is accurate recreation and validation, not re-approval. A sign-off would have been governance theatre—a ceremony implying authority the software did not have and the situation did not need.
05
Rigour
When a mistake
is a patient outcome.
Coming from startups, the biggest shift was learning that design is not the only thing that exists, and that good-looking screens are nowhere near enough.
You have to design workflows. You have to design the architecture.
You cannot cut corners on rigour. With a life at stake, the work includes use-related risk analysis—UFMEAs and design-FMEAs—that decides what gets tested by what carries patient risk.
The Studio authoring tool itself isn't classified as a medical device, so regulatory-grade usability sits with the consuming product. But I still ran formative testing on whether clinicians could author a correct protocol.
The single biggest fix was unglamorous and telling: the labels were too technical. The hardest part of a no-code tool is the words.
06 What it is designed to change
Claims bounded by current status
Months
to minutes.
The protocol-update cycle the platform is built to collapse, from a vendor-coded release to a hospital editing its own protocol.
In active development and internal validation. No deployed outcomes or metrics are claimed here.
07 / The through-lineTrust is
Trust is
a system property.
Clinical decision support is, underneath everything, a trust problem. The clinician acting on a protocol didn't write it and can't directly verify the evidence behind it. They're trusting a system—a lifecycle, governance model and institution—to have done that work correctly, and to speak up only when it matters.
That is the same problem I now work on with AI. When a clinician acts on a protocol, when a person acts on a model's recommendation, when a human approves an action proposed by an autonomous agent, the question is the same: what has the system done to earn that trust, and how does the human know?
The prompter that waits for the right moment, and the lifecycle that makes “is this safe to use?” answerable, were my first designs for earned trust at infrastructure scale. The Agent-First UX Patterns I work on now are the same question, aimed at a new kind of actor.
Next case study
