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.
Years of acquisitions left Oracle Health with a fragmented experience. Same data, different behavior, depending on where you were in the product. Teams weren't failing, they were building without a shared foundation.
The Health Design System team's job was to fix that. Creating a shared framework for displaying patient data that was clinically accurate, easy to adopt, and built to last. As the principal UX designer on the team, my work included collaborating with physicians, coordinating across teams, specifying components, running design critiques, and mentoring other designers.
At the center of this work was a physician advisory group involved in every phase. Nothing was final until practicing clinicians had reviewed and confirmed it.
A clinician who cannot instantly scan and interpret data is a clinician who pauses, double-checks, and sometimes misses what matters.
An audit across product teams found three problems. Each was manageable on its own, but together they actively worked against the people using the system.
The framework wasn't theoretical. It shipped as patient-facing components used across Oracle Health's clinical product suite. Three screens show the system working end to end: the patient context view, the medications list, and the problems list, all governed by the same severity and hierarchy rules.
The patient context view anchors the experience. The center panel surfaces an AI-generated clinical brief: the things a physician needs before walking in the room. The Priority Actions panel on the right translates that information into time-bucketed tasks: what needs to happen today, this week, within two weeks. Information on the left. Context in the center. Action on the right.
The medications list applies the severity system directly. Warfarin surfaces as High risk with a red diamond: INR 3.2 supratherapeutic, action needed. Metformin is flagged Non-adherent in amber. Metoprolol carries a Recent change badge. Rows without alerts show a dash. The center column is the severity zone, always the same position, always the same encoding, regardless of which clinician is reading it or which module they're in.
The problems list uses the same three-column anatomy. Atrial fibrillation: High risk, anticoagulation ongoing, INR supratherapeutic. Hypertension: Above target, current regimen inadequate. Fall risk: High risk, anticoagulation and polypharmacy. Resolved problems are present but muted, the history is never hidden, just visually subordinate to what's active. The component is the same. The data domain is different.
Before any component could surface a clinical alert, the team needed a shared definition of what each severity level meant, what behavior it required, and what teams could and could not do with it.
Five tiers govern every alert across the system. Critical: immediate risk to patient safety, requires action now, not dismissible. Urgent: elevated risk requiring action within the encounter. Advisory: notable condition warranting awareness, timing at clinical discretion. Informational: contextual support, no immediate action required. Ambient: passive context or AI-surfaced insight.
The usage rules are non-negotiable. Critical alerts require explicit acknowledgment before dismissal. Every acknowledgment is logged with full audit metadata. Teams cannot create severity levels outside this system, cannot repurpose severity colors for decorative use, and cannot override the schema-driven tier without logging the change.
This document was the governance artifact teams received before contributing any alert-bearing component. Violations were flagged as governance exceptions, not design preferences.
Before building any components, the team needed to answer a core question: what is the right way to show each type of clinical data, and when?
| Type | When to use it |
|---|---|
| List | Items share membership or sequence but don't need to be compared. Use when presence alone is what matters: problem list, allergy list, surgical history. |
| Card | A discrete entity the clinician might act on or navigate to. Use when identity, priority, or next action is the point: patient summary, active alert, pending order. |
| Table | Values only make sense relative to others in the same set. Use when comparison across rows or columns is the task: lab panel, medication list, order queue. |
| Chart | Data describes change over time or deviation from normal. Use when the pattern matters more than the individual value: vital trend, lab trajectory, glucose over shift. |
Every data field was assigned a visibility tier: what data is always shown, shown by default, or available on request. Each assignment required physician sign-off before it was final. Tiers were then mapped across different roles and care settings to set the defaults for shared components.
The role distinction mattered because care is a team effort. A physician reviewing morning labs needs different things than a nurse managing medications for the same patient. Showing both the same data in the same way doesn't serve either of them.
Building the right components was the easy part. Getting them actually used was the real job.
The hardest governance decision was drawing the line between what teams could change and what they couldn't. Every request for more flexibility was weighed against one question: would this hurt consistency for clinicians?
Teams were owners of their data and their copy. The design system team was the owner of the visual and behavioral contract.
Every component shipped with anatomy docs, a full state inventory, a configuration guide, and an anti-pattern library with clinical rationale behind each constraint.
Design system work has a built-in tension. The teams you are asking to adopt new components are the same teams whose work you are replacing.
Pattern audit findings were shared with teams before any component proposals were made, creating shared ownership of the problem before the design system team had any asks.
Physician input did not refine the system at the margins. It changed it substantively.
A physician advisory group from multiple specialties and care settings was part of every phase, not just brought in at the end. No tier assignment, form decision, or behavioral specification was considered stable until at least two physicians with relevant clinical experience had reviewed it. Physicians were in the room from discovery through component review.
| Phase | Input sought | What changed |
|---|---|---|
| Discovery | Confirmation that observed inconsistencies created real workflow friction | Elevated scope from cosmetic to clinical-safety initiative |
| Data hierarchy | Tier assignment review for every data field in scope | 32% of proposed tier assignments were revised |
| Taxonomy | Validation of form-to-context mapping for clinical workflows | Chart form scoped more narrowly; card permitted in specific medication workflows |
| Component review | Evaluation of prototype components against real clinical tasks | Alert banner dismiss redesigned with role-based permissions |
| Anti-pattern library | Review of proposed anti-patterns for clinical accuracy | Three anti-patterns added based on physician-identified failure modes |
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