UX Design in Healthcare: Navigating HIPAA and Payer Complexity

Why healthcare UX is its own discipline

UX design in healthcare sits at the intersection of three forces that don't normally meet in consumer products: federal regulation (HIPAA, CMS, Section 508), clinical workflow complexity (claims, prior auth, utilization management, case notes), and a member base that spans every age, language, ability, and bandwidth. A flow that feels "minor friction" in a consumer app becomes a HIPAA incident, a denied claim, or an inaccessible benefit in a payer platform.

After 11+ years designing for Elevance Health, Carelon, and Sydney Health — products serving 12M+ members — the pattern I keep coming back to is this: regulation isn't the enemy of good UX, it's the brief. The teams that ship the best healthcare experiences treat HIPAA, WCAG 2.2 AA, and CMS rules as design constraints, not legal afterthoughts.

HIPAA as a design constraint

HIPAA's Privacy and Security Rules govern any UI that touches Protected Health Information (PHI). For designers, that translates into concrete patterns:

• Minimum necessary on every screen. Default to masking SSNs, DOBs, member IDs, and diagnosis codes. Reveal on explicit user action, not on hover.
• Session and idle timeouts that warn first. A 15-minute idle timeout is industry standard; pair it with a 60-second modal warning so users can extend without losing in-progress work.
• Audit-friendly states. Every PHI view, edit, and export should produce a clear, designed confirmation — not a silent background log. Auditors will ask, and so will members.
• Safe-by-default sharing. Copy-to-clipboard, screenshots, and "send to" actions on PHI screens need confirmation steps and clear scope ("This will share name + DOB only").

Medicare, Medicaid, and the payer audience

Medicare and Medicaid members aren't a single persona. Medicare skews 65+, often on low-bandwidth connections, frequently using assistive tech or a caregiver's device. Medicaid spans every age but over-indexes on mobile-only households, limited data plans, and English-as-second-language users. Commercial members are closer to consumer UX expectations but still inherit the regulatory surface.

Practical implications I've validated repeatedly in research:

• Mobile-first is not optional for Medicaid. Design the smallest viable screen first, then expand. A flow that requires a desktop is a flow that excludes a real cohort of members.
• Plain language beats clever copy. Aim for a 6th–8th grade reading level on member-facing screens. Replace "explanation of benefits" with "what your plan paid"; replace "prior authorization" with "approval before your visit".
• Caregiver workflows are first-class. Authorized representative flows — adding a spouse, child, or care manager — deserve the same polish as the member's own journey.

WCAG 2.2 AA: the floor, not the ceiling

Section 508 requires WCAG 2.x AA for federal-touching healthcare products, which covers nearly every payer platform. The new 2.2 success criteria (Focus Not Obscured, Target Size 24×24, Dragging Movements, Consistent Help, Redundant Entry, Accessible Authentication) tend to be where existing design systems fall short.

When I rebuilt the Elevance Enterprise Design System (eDS), the decisions that moved the accessibility needle most were:

• Token-level contrast guarantees. Color tokens carry their own AA/AAA contrast metadata; designers literally can't pick a non-compliant pair in Figma.
• Focus rings owned by the system. 3px outset focus rings on every interactive token, regardless of brand theme. Brands can change hue but not visibility.
• 24×24 minimum target on touch. Components ship with built-in tap padding so the visible affordance can stay small while the target stays compliant.
• Auth without memory. Replace knowledge-based challenges (CAPTCHA, security questions) with email/SMS magic links or passkeys to satisfy Accessible Authentication.

Enterprise payer patterns that actually scale

Payer organisations typically run 5–15 sister brands on shared infrastructure. The temptation is to fork — one design system per brand, one component library per app. It collapses under its own weight inside 18 months. The pattern that holds up:

1. Brand-agnostic primitives. Button, Input, Card know nothing about brand. They consume tokens.
2. Token layers, not theme overrides. Three layers: primitive (raw values), semantic (intent), brand (mapping). A new brand is a JSON file, not a fork.
3. 1:1 Figma ↔ code parity. If a variant exists in Figma but not in code (or vice versa), it doesn't exist. Storybook is the contract.
4. Governance as a product. Contribution model, proposal templates, deprecation calendar, monthly office hours. Treat it like an OSS project with paying customers.

Walkthrough of the system in production: Enterprise Design System case study →

AI in healthcare UX: opportunity and exposure

LLMs are now showing up in claims auditing, prior auth triage, care navigation, and member support. They are also the fastest path to a HIPAA incident if shipped without UX guardrails. The patterns I built into Auditor Workbench that have held up in production:

• AI as a co-pilot, never an autopilot. Recommend, don't decide. Every AI-suggested action requires a human accept/edit step that's logged.
• Confidence as a first-class UI primitive. Show why the model suggested something, with citations to the source document. Never a bare answer.
• PHI redaction at the prompt boundary. Strip member identifiers before they reach the model; reattach in the UI layer after the response.
• Fallback to checklist on low confidence. When the model isn't sure, fall back to the guided 13-step audit, not a blank screen.

A starter checklist for healthcare UX teams

• PHI is masked by default; reveal requires explicit action.
• Every flow has a documented Medicare and Medicaid persona walkthrough.
• Idle timeouts warn 60 seconds before logout.
• Components meet WCAG 2.2 AA out of the box, not via opt-in.
• Plain-language copy reviewed for ≤8th grade reading level.
• Caregiver / authorised representative paths are designed, not bolted on.
• AI features ship with confidence indicators, citations, and a human approval step.
• Mobile-first prototypes, validated on low-end Android.

Where to go next

If you're scaling a healthcare design org, the highest-leverage investment is almost always the design system and its governance model. The second is research operations with real Medicare and Medicaid members — not proxy panels.

More on how I've shipped these patterns at enterprise scale in the case studies.