Oracle Health Health Design System Desktop EHR 20+ Teams

EHR Data Presentation
Consistency Initiative

Building one consistent way to show patient data across the Oracle Health EHR, from overview pages to detailed records, for every clinical role and care setting.

Role
Principal UX Designer
Platform
The Electronic Health Record
Deliverables
Taxonomy · Components · Governance
EHR data consistency hero image

Oracle Health needed a new visual language built for complex healthcare workflows.

Building the patient chart required moving fast: experiment, implement, validate, iterate.

Oracle Health needed to build a dedicated system, purpose-built for clinical workflows.

The intent was to build a clinical products need now, fold back into Redwood later.

I owned lists, cards, and tables, the primary data surface in every clinical workflow.

Collaborated across other principal designers and design directors to ensure system-wide consistency.

Different data.
A consistent way to show it.

Product teams across Oracle Health: Providers, Specialties, Schedulers, Billing, Pharmacy, were all displaying lists and data in differing patterns.

Building the patient chart required moving fast: experiment, implement, validate, iterate.

Oracle Health needed to build a dedicated system, purpose-built for clinical workflows.

The intent was to build a clinical products need now, fold back into Redwood later.

I owned lists, cards, and tables, the primary data surface in every clinical workflow.

Collaborated across other principal designers and design directors to ensure system-wide consistency.

Figma and Storybook List Components

No assigned teams. No developement partners. We found them ourselves.

Direction was to built it fast but had no cross functional team assignments.

No development partners at the start.

I identified pilot teams, initiated relationships and earned participation.

Ran office hours and working session.

We looked at their designs and documentation together.

Mapped use cases to find where real alignment was possible.

Lists were the primary way information was being presented across all teams.

Figma and Storybook List Components

A scalable, responsive list built for every clinical context.

Lists were universal in surfacing data surface across all views.

Flexible enough to fit every use case.

Consistent enough to create coherence.

Gave every team a clear answer to "what about my edge case?"

Figma and Storybook List Components

One list item. Designed to hold every clinical data type.

Audited designs across product teams, heard intent, understood real needs.

Mapped item data into categories: ex: What, Where, When, Why, How, and Status.

Defined the sockets of the list item with a flexible structure every team could populate.

Validated the new pattern back across teams for feedback.

Validated with clinical SMEs.

Got it built.

Figma and Storybook List Components

The list item as a clinical
decision surface.

Every list item has a defined space for contextual insight.

Insights surface inline data relevant to that item. No drill-in required.

When AI detects a signal, it surfaces the insight and suggests an action.

The user clicks the AI icon they can take action. Prescribe medications, adjust a dose, or perform a freeform a command.

The decision happens in the list. The workflow never stops.

Figma and Storybook List Components

DesignOI had cross team ownership

Pilot Teams PMs Engineering Leadership Clinicians
WORKING GROUP

Pilot teams as proof

Ran office hours and working sessions with 5 pilot teams. Listened to specific needs to build a shared pattern.
Fostered advocates not compliance.

LEADERSHIP REVIEW GATE

Review sign-off

Presented the contextual model lists and cards through formal design review processes. Led with clinical consistency and reduced design debt.

CHAMPION MODEL

Peer-to-peer scaling

Trained design system champions within each product team. Adoption spread through designers and engineers who'd seen it work — not through a mandate from above.

Instant adoption with ~12 teams.
Many more to follow.

All teams, ~12, feeding the Patient Chart adopted immediately.

Estimated twice that would begin adoption.

Adoption spread peer-to-peer through design system champions.

Shared ownership across all list types: Informational, Scheduling, Task, and Object.

~12 teams
Adopted at launch. More in the pipeline.
"Patient Chart Unblocked."
The primary pattern in the healthcare suite delivered.
Figma and Storybook List Components

What held, what grew, and what's next.

What worked

Running the audit before proposing anything created shared ownership of the problem. Teams came to us, not the other way around.
Having physicians in every phase meant the work was grounded in clinical reality from the start, not patched in at the end.
Drawing a clear line (content is yours, structure is ours) gave teams real ownership while protecting consistency where it mattered.
The anti-pattern library was the most effective cross-team tool we produced. Written clinical rationale lands differently than verbal pushback.

What's next

Role-based personalization at the component level: the tier framework needs to move from fixed defaults to dynamic configuration as EHR personalization develops.
AI-generated data will introduce new types and formats the governance model needs to handle alongside traditional structured EHR data.
A formal accessibility audit of data presentation components, particularly charts and tables at high density, against WCAG 2.1 AA standards.
Let's talk about your
next big idea.

I'm currently open to new design leadership roles. Whether you're building something ambitious or improving what you already have, I'd love to connect.

Get in touch