HealthTech UX
A woman gets a text saying her results are ready. She opens the app on the bus, signs in twice because the session expired, and reads a page written for the doctor who ordered the test.
Learn on the move: press play and turn your commute, walk or drive into time that grows your design career.
Listen to the full HealthTech UX course on DesignPath
One line says a value is outside the reference range. Nothing on the screen says whether that is serious, what happens next, or who she can ask. She spends the rest of the journey searching the term on her phone.
No part of that screen was broken. It was written by people who understood it, for a reader who is frightened and has no medical training.
What This Domain Changes
Two facts drive the whole module.
The reader is rarely at their best.They may be in pain, medicated, exhausted from caring for somebody else, or scared by what they just read. Stress narrows attention and shortens working memory, so a screen that asks somebody to hold three things in their head gets two of them.
Not understanding has a physical cost.The 2003 US National Assessment of Adult Literacy, still the most cited survey of its kind, found that 12% of adults had proficient health literacy. Among adults over 60, 71% had difficulty with printed health material. Those readers are not an edge case in a health product. They are a large part of who opens it.
So the patterns you know still apply and their stakes move. Error Messages owns wording and placement; here the mistake can reach a body. Accessibility owns WCAG; here it decides whether the person the product exists for can use it at all.
Anatomy of a Health Account
Consumer products assume one account belongs to one person who reads everything in it. Health products inherit that assumption from their frameworks and it is wrong in three separate ways.
Naming the parts is what lets you see which assumption your product is making without noticing.
Four Kinds of Person
The patient.The person the record is about. They may or may not be the one using the software.
The clinician.Reads and writes the record as part of their work, at speed, between appointments. Their screens are a different product from the patient's and are usually designed by nobody.
The proxy.A parent, an adult child, a partner, a legal guardian. Acting for the patient with some level of permission, and in most products doing it through a shared password because no other route exists.
The administrator.Reception, scheduling, billing. Sees appointments and identifiers but has no business seeing clinical detail, and a product with one permission level gives it to them anyway.
Five Kinds of Record
The word "health data" hides five things with different rules and different screens.
Identity and demographics.Name, date of birth, identifiers. Sensitive because it links everything else.
Appointments.Time, place, department. The department name alone can disclose a diagnosis, which is why an appointment title on a lock screen is a leak.
Results.Measurements against a reference range, arriving asynchronously, often before anybody has explained them.
Medications.The record with a direct physical consequence, and the one where a display mistake becomes a dosing mistake.
Notes and correspondence.Written clinician to clinician, in clinical language, and increasingly visible to patients who were not the intended reader.
Three Levels of Sensitivity
Within those records, three tiers behave differently and people expect them to.
Routine.A flu vaccination, a blood pressure reading. Most patients share these without concern.
Protected by default.Anything a person would not volunteer: a diagnosis, a prescription, a referral.
Restricted.Mental health, sexual health, substance use, terminations, gender care. These are the categories people most often want to withhold from a specific family member rather than from the system. They are the reason proxy access has to be granular.
What the Anatomy Tells You to Build
Put the three lists together and the requirements fall out.
A role on the account rather than a single user. A record type on every item, so permissions can be set per type instead of per screen. And a sensitivity tier, so the restricted categories can be excluded from a proxy's view, from notification previews and from any export, in one rule rather than in forty places.
A product without those three fields will implement each privacy request as a special case, and will miss one.
Pro tip: Open your data model and check whether an item knows its record type and its sensitivity tier. If it does not, every privacy feature you build afterwards will be a list of exceptions somebody has to maintain by hand.
