Case study3 of 3
Consolidate Health
Your health history, across every provider, still yours.
Consolidate Health brings a patient's medical records from every provider into one history the patient controls. I led the design of the app that makes that history useful, current and shareable: how records come in, how a person makes sense of them, and how they decide who else can see them.
The patient is the only one present in every system.
Healthcare happens across institutions. A person moves between a primary-care doctor, a specialist, a lab and a pharmacy, and their history accumulates in separate portals, each organised around the institution that created it. The one constant across all of them is the patient, and the patient is the one person none of those systems is organised around.
Consolidate adds a patient-level view above those sources. A specialist's visit and a primary-care prescription sit in the same chronology. A new office can ask to see that combined history, and the patient decides. That gives the product two responsibilities that have to grow together: make fragmented information useful, and make the consequences of combining it understandable. More information in one place makes every access decision weigh more.
Once records arrive, a patient needs three things from them before anything else:
- Is this current?
- What does it mean, in the context of my care?
- Who can see it?
Those three questions gave the product its hierarchy, and this page its shape.
Five words recur across the product. Here is what each one means in Consolidate.
- Provider
- The doctor, clinic or hospital where a patient receives care. The patient's own word for it is the one the app uses first.
- Portal
- The provider's own patient system. Consolidate signs in to it, with the patient, to collect records. One sign-in can cover more than one doctor.
- Connection
- An authorised link to a portal. It can be connecting, connected, syncing or expired, and the app says which.
- Record
- A visit, a lab result, a medication or a document, each with a source and a date, and links to the others it belongs with.
- Access
- What an office may see of the combined history, granted by the patient on request and revocable later. Separate from importing.
Five flows that described the features, not the person.
The client arrived with a Figma file of five flows and a first HTML prototype that reproduced it screen for screen. The flows were a starting point and a set of constraints. My job was to resolve them into a product someone could find their way through: what to show first, which decisions to keep separate, how to explain the system's boundaries, and what should happen when the expected path breaks.
The most important work happened between features. A provider supplying records is not the same as an office reading the combined history. A record being present is not the same as its source still being current. Those distinctions had to survive on every surface of the app.
One loop. Five screens.
The core loop runs from connecting a provider to using the record, then carrying that history into another care relationship. Each step has to justify the next: connecting is work for the patient, an understandable record is the return on it, and sharing gives the collected history another purpose. Home, Records and Doctors are three doors into the same data, so a person can start from a care relationship ("my specialist") or an event ("my last blood test").
- 01Connect a providerDoctors
- 02See what's currentHome
- 03Read a recordRecords
- 04Decide who can see itRequests
- 05Change your mindSharing
Five decisions carried the product.
Each one trades something away. The trade is written under it.
01 Connect a provider · Doctors
Say where the hand-off goes
before it happens.
The patient starts with something familiar: the doctor they see. Underneath that choice is a dependency they have never had to think about, the provider's portal and its authorisation rules. The connection flow bridges the two. Search finds the right source. Before the hand-off, the app names the portal the patient is about to sign in to, explains the two choices they will meet there (how far back to collect, and for how long to keep access), and says they will come back here afterwards. Those choices decide how much history the app can collect and keep current, so the explanation gives them a purpose.
Connecting is also a wait. The app shows which step it is on, lets the patient move on while it works, and brings the result back into the experience. Success says when records will appear.
One more screen before the portal. For the patient who already knows what MyChart will ask, it is a tap they don't need; for everyone else, it is the difference between authorising something and understanding what they authorised.
02 See what's current · Home
Freshness first.
The greeting second.
Putting records in one place creates an expectation that the view is up to date, and that expectation turns misleading the moment one provider's authorisation expires or an import is still running. So freshness is part of the main screen. Home says when records last synced and offers a direct way to check for more. When a connection needs attention, that same line names the problem and the next action.
The app keeps two actions apart that most products blur. Sync checks an active connection for new records. Reconnect takes the patient back through the portal's authorisation. The words match what the system can actually do.
An earlier Home led with a large greeting, the date and summary counts. I cut all three back. For a returning patient, confidence in the information is worth more than another summary of how much information there is; the first screen is quieter for it.
03 Read a record · Records
A flagged result
explains itself.
A combined timeline helps someone find an event across providers. Its value shows up when they can see how that event relates to the rest of their care. Visits, labs, medications and documents each open in full, with links between them: a visit connects its note and plan to the reports and prescriptions that followed; a lab leads back to the appointment where it was discussed. The patient follows the relationships in their care instead of reassembling them across portals.
The flagged lab is where this earns its place. An out-of-range badge creates a question. The detail puts the value beside its reference range, highlights the row, shows its trend across recent draws, and names who has already reviewed it.
The app shows clinical information in context and stops there. It does not interpret a result or offer advice, and every value carries its source. That boundary limits what the screen can say, and it is the reason the screen can be trusted.
04 Decide who can see it · Requests
Importing and sharing
are two different yeses.
Combining records makes a history worth sharing, and raises what is at stake each time the patient shares it. So consent is an ongoing part of the product, not a screen at onboarding. An office requests access; the patient sees who is asking; Accept or Decline records an explicit decision. Active sharing has its own place in the app, so the patient can inspect the result later and stop it when a care relationship changes.
Connecting a provider brings records in. Granting an office access lets it read the combined history. The app never lets one imply the other. Optional research participation is a third, separate decision: choosing to receive invitations is not the same as accepting a study, and the records product stays fully useful to someone who says no to all of it.
Three separate decisions where one consent screen would do. It is more to read, and it is the only way the patient can answer "who can see this?" with any precision.
05 Change your mind · Sharing
Stopping access says
what it cannot undo.
Control has to stay useful after the first yes. The patient can stop an office's access at any time, and the app explains the consequence before it happens. It also states the limit plainly: stopping future access does not remove copies an office has already downloaded.
For a product promising patient control, that sentence is uncomfortable to put on a screen. Leaving it off would make the control look larger than it is, and the app's job is to describe the control it can actually offer.
People judge an app by what it does when something goes wrong.
A unified history is only as honest as its worst connection. Expired access is treated as its own condition, not folded into "error": Home says which provider needs attention and offers Reconnect, and the records already collected stay readable in the meantime. A failed connection is the same moment screen with one step marked, and a way to try again or come back later. An empty Doctors list helps someone begin instead of showing a blank.
The rule across the app: an action has feedback, a wait has an explanation, an error has a next step, and an empty state helps someone start.
The same condition uses the same words everywhere.
Across the app, a source is Connected, Connecting, Syncing or Expired, and a request is Pending or Declined. Those words do as much work as the visual treatments around them, and they are the same in onboarding, in provider management and in sharing. The prototype ties the flows together through shared state, so cross-feature behaviour can be reviewed: accepting a request changes Sharing; a connection the patient walked away from still resolves on Home.
Words
One vocabulary for status, used identically on every screen. Patient-first language on the surface; the system's own terms one tap deeper, when someone wants them.
Colour
A restrained cobalt accent on quiet reading surfaces. Colour marks a decision or a condition, and the records keep the attention.
Motion
Limited, and spent on meaning: the gathering-dot mark expresses consolidation at moments of creation and connection. Nothing else moves for its own sake.
Rules
Feedback for every action, an explanation for every wait, a next step for every error, a way to begin from every empty state. One design for iOS and Android.
A patient product with one model of ownership.
Consolidate brings three capabilities into one experience: collecting a history across providers, reading it with context, and deciding who can see the combined record. My contribution was to make them behave as one product.
What I can claim
The work produced the patient flows, the interaction and visual system, and a working prototype that the team could evaluate and implement against. It turns "all your records" and "you are in control" into specific behaviours. The product went into testing in a clinical setting, with real patient data. Heavy regulation kept that launch smaller than we wanted, and no adoption, task-completion or clinical outcomes were measured at a scale worth reporting, so this page makes no such claim.
What I'd carry forward
The next evidence should come from patients using the whole loop across more than one care relationship: connect a provider, find a record, say how current it is, respond to an access request, change that decision later. The moments that deserve direct observation are the portal hand-off (can people say what they authorised?), the flagged result (can they connect it to its source and context?), and sharing (can they say who has access, what they can see, and what revoking changes?). Over time the signals that matter are successful first connections, time to retrieve a needed record, recovery from expired access, and continued use as providers change. Those are proposed measures, not results.
Connect a doctor, find a record, change your mind.
Tap through the phone, or pick a screen on the left. Connect Dr. Green, watch Home update, open the flagged lab, then accept an office's request and stop it again. Sample data throughout; the clinical text is illustrative.
Prototype Interactive, rebuilt as one system
Next case
Lead product designer