Designing Patient-Safety Components

After the Redwood theme for Terra was shelved, I moved to Redwood, Oracle’s cross-product design system, where I was one of six building its health components. We worked as a separate group inside the roughly 100-person org.

With Terra, I knew one system cold and worked in its code. Redwood wasn’t a library I consumed; it was a whole design methodology I had to learn. You start from the user’s problem and map it to the Redwood pattern book, and you build a new component or pattern only when existing ones can’t do the job.

Shipping anything in Redwood meant getting it through several peer-reviewed gates. A pattern had to justify the component. The tokens and standards had to be met. And a health component couldn’t assume it was only ever for health: before it shipped, you had to prove a second adopter, name another business group that would need the same thing, and show it would serve them without the clinical assumptions baked in.

I got three through: an AI-generated summary of a patient record, an ID component carrying regulated patient identity items (date of birth, age, birth sex, self-reported pronouns, health ID), and a health-aware timestamp for patient age, counting in hours for neonates, days for young infants, then weeks and months and years as the child grew.

The two I think about most, we designed and never built.

Patient name display is a safety-critical surface. The Joint Commission in the US, and patient-safety frameworks across the UK, EU, Canada, and Australia all treat it that way: the name on a patient header is one of the two identifiers a clinician uses to confirm they’re treating the right person. International patients frequently have multi-part names, three, four, five tokens, handled natively by FHIR’s HumanName element, and Oracle shipped into all those jurisdictions at once.

We designed a context-aware truncator that reflowed the name as the viewport changed, preserving the identifying tokens and collapsing the optional ones across breakpoints. It was a good piece of design, and it solved the problem it was aimed at.

It cleared several gates before the design reviews caught the problem. A clinician pulls the same record up on a hallway workstation, then a bedside tablet, sometimes in the same minute. Our truncator, reflowing to fit each screen, would show that patient’s name two different ways across the two devices. That’s the exact confusion the two-identifier rule exists to prevent: the name has to read the same everywhere, or it stops being a reliable check. A plain ellipsis was dumber and produced the same output every time.

The second one we killed was a gender mismatch notification. Object/Patient ID showed self-reported pronouns alongside birth sex, and we sketched something to flag a mismatch to the provider when intake had captured both. It cleared one gate before the SOGI specialists on the team envisioned the component being used in a cramped exam room.

A patient may have entered their pronouns privately at check-in, and the family member sitting in the exam room with them has no idea the patient uses anything other than the ones they were born with. A mismatch notification on the provider’s screen outs them two ways.

The screen is the obvious one: it’s readable to anyone in line of sight. But even if no one sees the screen, the provider’s demeanor might give it away. A clinician who says nothing different could shift how they engage, the eye contact, considered pauses before they speak. Pronoun data in an EHR is protected health information, and cramped conditions heighten that need for protection.

I’d been in big collaborative rooms before. In most of the places I’d worked, the people in them were a little bit out to get you, and that’s what made the Redwood prospect terrifying: if ten people in a room could be that political, what was a hundred going to be? Turns out, it was just fine. People found holes in my work because they wanted the team to produce the best work possible.