Designing the systems that sit between clinical knowledge and the clinicians who act on it. Three applications. One infrastructure. A protocol lifecycle built from the ground up.
Clinical decision support exists at the intersection of two incompatible demands. Clinicians need guidance that is current, specific, and trustworthy. The organisations that produce and govern clinical protocols need a way to author, version, validate, and deploy that guidance reliably — at scale, across multiple healthcare systems, without creating new risks in the process.
When I came to this work, clinical protocols were being managed through processes that could take months from authoring to deployment. The problem was not that the guidance was wrong — it was that the infrastructure for producing and distributing that guidance was not designed as infrastructure. There was no lifecycle. There was no visibility into state. There was no reliable mechanism for updating what was already in the field.
The most important design work I did here was not on a screen.
CareLogic is not a single product. It is a platform expressed through three distinct applications, each designed for a different kind of user and a different phase of the clinical guidance workflow.
The authoring and knowledge management environment. Where clinical protocols are built, structured, and prepared for validation. The design challenge here was epistemic: how do you give clinical knowledge authors a tool that is both expressive enough to capture the complexity of clinical evidence and structured enough to be machine-deployable? The answer required building a coherent content model before a single interaction could be designed.
The configuration environment for healthcare organisations deploying CareLogic. Different organisations have different clinical contexts, different formularies, different regulatory environments. Settings App is where institutional variation is managed without fragmenting the core protocol. The design challenge: making highly consequential configuration decisions legible to operations teams who are not clinical informaticists.
The most significant design decision in Settings App was the deployment model. We designed for blue-green deployment — the same pattern used in software release engineering — adapted for hospital operational contexts. A new configuration version is prepared and validated in parallel with the current live version, then switched atomically. This meant the design had to make "current" versus "staged" state legible at all times, and had to surface the consequences of committing a switch clearly enough that the person making the decision understood exactly what would change.
An embedded analytics surface, deployed as a Micro Frontend within existing GE products. Clinicians and clinical operations staff can track protocol adherence, surface deviations, and understand how clinical guidance is actually being used in practice. The design challenge was constraint: Micro Frontend architecture means designing within the frame of a host application you don't fully control, for a user who didn't specifically come to use your product.
The most consequential design work in CareLogic was defining the protocol lifecycle — a formal model for how a clinical protocol moves from draft to active use. Before this existed, there was no shared vocabulary for protocol state. "Is this live?" was a question that could mean different things to different people in the same organisation.
Protocol lifecycle states
Each state transition has a defined owner, a set of preconditions, and a visible audit trail. This sounds obvious in retrospect. Before it existed, it wasn't.
One of the hardest design decisions in the lifecycle was the Approver role. We designed a distinct role — separate from both author and validator — for the person who commits a protocol to deployment. After extended review, the Approver role was descoped before launch. The capability was deferred; the decision logic was absorbed into the existing roles. This is a common outcome in complex organisational software: the right architecture gets deferred to the right time.
Outcome
Clinical decision support is, among other things, a trust problem. The clinician using a protocol didn't write it. They can't directly verify the evidence behind it. They are trusting a system — a lifecycle, a governance model, an institution — to have done that work correctly.
That's the same trust problem I think about in AI systems. When a clinician acts on a protocol, when a person acts on an AI recommendation, when a human approves an action proposed by an autonomous agent — in each case, the question is: what has the system done to earn that trust, and how does the human know it?
The protocol lifecycle at CareLogic was my first design for earned trust at infrastructure scale. The Agent-First UX Patterns I developed later are working on the same problem from a different angle.
Key decisions