Care Bridge
The company's first patient-facing app, and the design work that anchored a $25M RFP win.
The Stakes
Incarcerated patients requested care on paper forms, and once a request left their hands, they had no idea whether anyone had seen it. Nurses, already stretched thin, had to triage free-form notes with no structure. The client wanted a digital version, and it was tied to an RFP we couldn't afford to lose.
If we got it wrong, we'd lose the client and the contract, and staff would go back to paper. The job was to take the paper process and make it better without adding burden on either side.
How might we increase patient autonomy without increasing clinical burden or exposing unnecessary information?
What I Owned
Product and UX: Strategy and UX/UI end to end, from concept through delivery.
Requirements: User stories and acceptance criteria with product, engineering, and clinical stakeholders.
MVP scope: What shipped first and what waited.
Care Bridge was built on the Fusion Design System, but it was the first mobile app for a very different user than our web apps serve. I extended the system with larger touch targets, icons alongside labels, and built-in guidance for patients who aren't comfortable with technology.
Constraints
No direct patient testing: I triangulated instead: nursing feedback, prototype reviews with clinical stakeholders, and the paper workflows patients already used. I stayed explicit about what I could validate and what remained an assumption.
Free text was non-negotiable: The client wanted requests to feel like the forms patients already knew.
A wide range of access needs: Low digital literacy, vision impairment, language barriers, and varying reading levels.
Decision 01
Guardrails Around Free Text, Not Instead of It
I pushed back on open free text because nurses needed structure to triage quickly. When it was clear free text was staying, I stopped fighting it and designed around it. Patients first choose a request type, then a subtype, then describe the issue in their own words. Behind the scenes, AI scans each request for combinations of keywords and checks them against the patient's profile, flagging the ones that may need urgent attention. I designed how those flags surface on the triage side, so nurses see priority requests first and can still change the status, urgency, or category themselves. Patients keep the familiar open format, and nurses get every request already sorted and flagged.
One small detail mattered a lot for patients who aren't comfortable with technology: if a request fails to send, the form says so plainly and keeps everything they typed, so nobody has to start over.
Decision 02
Let the System Flag Urgency, Not the Patient
Asking patients to rate their own urgency would have been unreliable. Instead, the system uses what it already knows. Business rules flag certain combinations of request details. AI scans the free text for specific language, like explicit wording or concerning phrases paired with the request. And each request is checked against the patient's profile. A patient with a history of cardiac episodes, on medication, who reports chest pain is flagged as urgent and jumps to the top of the nurse's queue.
AI here is part of the product, not just my process: it surfaces signals a busy nurse might miss and reorders the queue, while the nurse decides what happens next.
Decision 03
One-Way Updates Instead of Messaging
Patients needed to know their request was received, but two-way messaging was a trap. Unlimited messages would cause alert fatigue and pull staff into more manual work. Capping messages could leave a patient unable to report something serious, which was a safety risk. So I left patient messaging out of the MVP. Nurses review AI-flagged requests first and send status updates from the triage side, which appear in the patient's portal, and anything that needs a real conversation happens in person. Deciding who can see what, and why, turned out to be a UX decision rather than a permissions setting.
Outcome
The first patient-facing product in the company's history, and the design work that anchored a competitive RFP win worth $25M in new revenue.
What I took from this
Access is part of the architecture, not a compliance step at the end.
Simple interfaces can require complex reasoning. Removing information means understanding which information actually matters.
Constraints change research methods, not the responsibility to validate. When direct access isn't available, assumptions need to become explicit.
When a constraint is non-negotiable, the work becomes designing guardrails around it rather than arguing against it.
Next project
↑ Back to top