Case study · Digital health · Vietnam

One patient record for high blood pressure care

In Vietnam, many people with high blood pressure do not get it under control. A health worker takes a reading at a market or a pharmacy, and then nobody follows up. HeartDaily is a mobile app and a clinic dashboard that use one patient record. Each reading has a person responsible for it and a next step.

Try the interactive demo Read the case study
Role
Product designer, end to end
Timeline
About 18 months, independent project
Scope
Research, flows, screens, design system, build direction
Surfaces
Mobile web app and clinic dashboard
Status
Live. No real patients yet. No clinician has tried the dashboard.

How I worked

Independent project, built with AI help: AI summarised research, drafted layouts and wrote front-end code from my specifications. Every read, clinical choice and design decision below is mine. More on this at the end.

  1. Read the care pathway. I used public documents and survey data and found three gaps. I did not interview anyone.
  2. Chose the clinical rules. I used the Vietnamese thresholds. The app never diagnoses.
  3. Cut what failed. Reading monitor photos with OCR did not work, so I removed it.
  4. Built five roles and tested. Five people tried the app. Four changes came out of it.
  5. Merged the components. I replaced separate sets of buttons and badges with one shared set.
  6. Simplified the screens. I removed clutter and changed how the dashboard uses colour.
01

What goes wrong after the first reading

High blood pressure has no symptoms, so people often stop going to care. In 2020, 28.3% of Vietnamese adults aged 25 to 64 had hypertension (national STEPS surveys). I read public documents and survey data on the care pathway and found three gaps.

After diagnosis, in one Ho Chi Minh City programme
  • Confirmed hypertensive17,114
  • Treated12,87275.2% of confirmed
  • Blood pressure controlled6,56838.4% of confirmed

The programme screened 121,273 adults aged 40 and over. Controlled means below 140/90. Source: Scientific Reports, 2022.

Each gap led to one decision.

Gap 1The reading is lost

Health workers screen people at markets and pharmacies. The number stays on paper.

DecisionSave it to the person's record

A health worker creates the record on the spot and saves the reading there.

Gap 2Nobody tracks the referral

Nobody can see if the patient reached the clinic, started treatment or came back.

DecisionSend it to a nurse automatically

The record links to the local health station. A reading that needs attention goes to a nurse there.

Gap 3It depends on one worker

Community health workers are paid by projects. When the funding ends, follow-up ends.

DecisionLet a family member take over

They use their own phone. The record stays linked to the station.

02

One record, five roles

The record belongs to the patient. Each role sees and does only what it needs. Choose a role to see its screen.

Nurse and Doctor work in this clinic dashboard. The three roles below use the mobile app.

Health worker (mobile app)

Registers a person, takes the first reading and refers them to the clinic when needed.

Screen: list of screened people.

The screens run in your browser from the product's own code. The people and readings are made up.

How a reading reaches the doctor, and the plan reaches the patient

  1. ScreenA health worker screens and registers a person.
  2. SaveThe reading is saved to that person's record.
  3. QueueIf it needs attention, it goes to the nurse's queue.
  4. ExamineThe doctor opens the record and examines the patient.
  5. RemindThe medicines and the follow-up appointment appear on the patient's phone as reminders.
Each referral is tracked from pending to attended Patients who do not respond to treatment are flagged

Four ways a reading arrives, one record

A reading can be taken by the patient, by a caregiver, by a health worker or at the clinic. All four write to the same record, and each reading keeps its source, because the source changes what a number means.

Identity

One ID that a health worker can type or scan

Problem
Four kinds of people need to point at the same person. A person screened in a new place should not get a second record.
Choice
The HD-ID is the initials, the birth day and month, and the last four digits of the phone number. A health worker can type it. A caregiver can scan it as a QR code. Spaces and dots are ignored, so a typed ID and a scanned one find the same person.
Cost
The ID holds part of a birthday and part of a phone number, so it is not a secret. That is why scanning it never links anyone by itself: the patient still has to accept (Decision 4).
The QR code a caregiver scans. The code here is a placeholder pattern; the app draws a real one.
03

What could go wrong

I tested each flow from start to finish and found these risks. The table shows what stops each one now, and what I have not proven.

A dangerous reading, step by step

1. The patiententers a reading of 180/110 or higher. The app shows the emergency screen with a Call 115 button.
2. The caregivergets an alert with a Call 115 button. With no caregiver, the health worker and ward staff are told.
3. The dashboardshows the case at the top, marked New, until staff open it. Staff then contact the patient or update the case.

Three levels of alert, and only one interrupts

If every reading warns, people stop reading the warnings. So the app handles each reading at one of three levels.

Only a crisis interrupts the person and tells anyone else.

A low number is not always a fine one

My first version saved a reading like 85/55 with no advice, because it was above the emergency line. A low number can mean a person is unwell. Now the app asks about symptoms first. If there are any, it opens the emergency screen and tells the caregiver or the station. If there are none, it says to rest and measure again.

It asks about symptoms
If there are none

The risks I found, and what stops each one

RiskHow I found itWhat stops itNot proven
A dangerous reading reaches nobody.A patient with a low reading and symptoms was told to get care. No one else was told.Crisis readings go to the caregiver. If there is none, they go to the health worker and ward staff.Built and checked in code. Never run on live data.
The screen says people were told when they were not.The crisis endpoint had a stray bracket and returned an error. The app ignored the error, so the screen said the family was told while no message was sent.I fixed the endpoint. The emergency screen now opens with a neutral note and the Call 115 button at once. It says people were told only after the server confirms. If the request fails or times out, the note stays neutral.Tested with a stand-in server for success, error and timeout. Not tested against the live server.
A low reading is saved as if it were fine.The Low label starts below 90/60 but the emergency line is below 70/40. A reading like 85/55 fell in the gap and was saved with no advice.A low reading asks about symptoms first. Symptoms lead to the emergency screen.The 70/40 line is my own choice and needs clinical review.
An emergency is listed as routine work.The intake screen put readings that were already taken in the "measure next" queue. I caught this on the day it shipped.Emergencies have their own card with only Contact and Update.No staff have used it.
An alert that is still true disappears.I reviewed every alert on the dashboard and in the app.Alerts that were acted on stay dismissed. Alerts that are still true hide for the session and return on reload.Not measured with real alert volume.
A typing mistake links a stranger.I watched a tester link a family member. One wrong digit could link the wrong person.A link works only after the patient accepts it.A link stays pending if the patient never opens the app.
04

Five design decisions

Each decision has the problem, what I chose, and what it costs.

Decision 1 · Patient app

Say less on the Home screen

Problem
My first Home screen showed the change since the last reading (+12). Testers found it alarming.
Choice
Use words: "Higher than last time". Show one place on a risk scale and one next action. The target number stays hidden until tapped.
Cost
The patient sees less detail. The exact numbers are in the clinic dashboard.
A high reading
An improving reading
Decision 2 · Wording

Use two sets of words for one reading

Problem
The medical label "pre-hypertension" makes older patients think they already have the disease.
Choice
Patients see "Slightly high" (Hơi cao). Nurses see "Pre-HTN" (Tiền THA). Every reading also keeps its source, and the line depends on it, using the Vietnamese consensus: 135/85 at home, 140/90 in clinic, emergency from 180/110. So 138/88 is Hypertension at home and Slightly high in a clinic. I did not use the US 130/80 line. The app never diagnoses.
Cost
If a patient repeats "slightly high" to a nurse who is thinking "Pre-HTN", the two sides can sound like they disagree about the same reading. I chose the words each reader understands and kept the source and number visible on both screens so a mismatch is easy to check.
The same readings, with each reader's label.
The same reading, taken in two places.
Decision 3 · Clinic dashboard

Make urgent cases easy to find

Problem
My first dashboard used a Kanban board, which hid which patient was most urgent. Solid red, amber and green on every row made urgent cases hard to find.
Choice
A list sorted by urgency, then waiting time. There is no "next patient" button, because emergencies are not taken in order. Solid colour is only for what needs action now. The emergency list shows as one line marked New until someone opens it.
Cost
The doctor chooses each patient. I aimed this at alert fatigue, when staff ignore alerts because there are too many. I have not measured it, and no clinician has used it. In one study, clinicians acted on about 6 in 10 alerts for high home readings (source).
The queue, grouped by severity.
Outlines for every reading. Solid colour only to act.
Colour contrast numbers

This page reads each value from the live design file and works out the ratio in your browser. The bright teal in the last row has too little contrast for text, so it is used only for decoration.

Brand colours · white text on each step

Contrast of the real text and fill pairs

PairSampleRatioWCAG AA
Decision 4 · Privacy

Ask the patient before linking a family member

Problem
To link a family member, a caregiver typed a phone number. One wrong digit could link a stranger to the patient's blood pressure history. I saw this while watching a tester.
Choice
The link starts only after the patient accepts it. Declining does not tell the caregiver. QR scanning reduces typing.
Cost
One more step for the family. The link stays pending if the patient never opens the app.
The three steps of a family link.
Decision 5 · Safety note

Teach once, then get out of the way

Problem
One high reading does not mean a person has high blood pressure. A person who sees no note may think they are fine. A person who sees a warning on every reading stops reading it.
Choice
The first slightly high or high readings carry a short plain note: one reading is not enough, keep measuring. The note stops after three days in a row or seven readings. It never says the person has the disease.
Cost
After seven readings the note is gone, even if the numbers stay high. When the week's average stays high, a card on Home tells the person to see a clinic so a doctor can confirm.
The note under a first high reading.

What I decided not to build

Reading monitor photos with OCR

The Tesseract tool read about 17% of displays correctly. An on-device model also failed on seven-segment displays. Typing three numbers stays the main way.

A patient database on the health worker's phone

A lost phone would expose many records under Decree 13. Offline use is limited to saving a patient's own readings.

A default blood pressure target

A default could look like the doctor chose it. The record compares nothing until the doctor sets a target.

A FHIR export

No health record system partner needs it yet. A read-only export is the first step if one does.

A native app

The reasons for one are gone. A thin wrapper can cover devices where the web app fails.

05

Built for older people on cheap phones

The people I designed for are often older, new to health apps, and on an entry-level Android with a weak connection. I wrote down the worst realistic phone and designed for that one, not for mine.

Access 1 · Language

Speak to people the way Vietnamese does

Problem
Vietnamese has no neutral "you". The word depends on age, gender and relationship. A generic word can sound cold or rude to an older person.
Choice
The app picks the form of address from the person's age and gender (bạn, anh, chị, chú, cô, bác, ông or bà) and uses it in the Home greeting and in reminders. With no age known, it says "Bạn". In English it uses the first name only.
Cost
The age bands are my own choice and I have not tested them with enough people. A wrong guess is the risk.
The same greeting, chosen by age and gender.
Access 2 · First visit

Let people try before they sign up

Problem
A sign-up form asks a lot of someone who is not sure the app is worth their time. My first welcome screen asked for a name before the person had done anything.
Choice
One line about what the app does and two buttons: try a measurement, or log in. A guest can take a reading with no account. The app asks for a name once, after the first reading. A phone that already had an account goes straight to log in.
Cost
A guest gets less. There is no history across days until they register.
The first screen on a new phone.

Four ways in, whatever the phone

Installing a web app fails on some older phones, so there is always another way in.

Way inWhat it needsNote
Open the link or scan the QR codeA current browser on any phoneNothing to install. This always works.
Install as a web appAndroid 11 or newer, Google Play services and an updated ChromeIt failed to install on one older phone, so I do not rely on it.
Android package (about 1.4 MB)Android 8.0 or newerOpens the same app in the phone's own web view. It works on that older phone.
iPhoneiOS 16.4 or newerAlerts need the app added to the Home Screen first.

About 2 GB of memory is enough. 4 GB or more feels smooth.

When the connection drops

Works offline

Saving your own reading

The phone keeps the reading and sends it when the connection returns, so a dropout never loses a reading.

Needs a connection, on purpose

Finding and registering people

I chose not to copy the patient list onto a health worker's phone. A lost phone would expose many records.

06

Using this in another country

HeartDaily is built for Vietnam. The problems and the design carry over: one record per patient, an automatic handoff to a nurse, a list sorted by urgency, and solid colour only for urgent actions. The rules and the law do not.

What changesVietnam (built)EUAustralia
Reading thresholdsVietnamese consensus: 135/85 at home, 140/90 in clinicSet from the local guidelineSet from the local guideline
Privacy lawDecree 13GDPRPrivacy Act 1988
Emergency number115112000
Link to health recordsNot builtLikely needed (FHIR). Not built.Likely needed (FHIR). Not built.
Medical device rulesNot assessedNot assessedNot assessed

Not tested: nobody outside Vietnam has used HeartDaily.

Likely scope: the app never diagnoses, but alert thresholds plus emergency escalation can still put it inside the EU and Australian definitions of software as a medical device. That classification needs a regulatory review before any launch outside Vietnam.

07

Testing with five people

Five people tried the app: three aged 50 and over, and two younger caregivers. There was no formal protocol. I gave them tasks such as "log a reading" and watched where they hesitated. No nurse or doctor has tried the dashboard.

Change 1

Show direction, not a number

Testers read "+12 since last time" as alarming.

+12 since last time→Higher than last time

Change 2

Use words people understand

A medical label meant nothing to patients, or sounded like a diagnosis.

Pre-HTN→Slightly high

Change 3

Ask before linking

One wrong digit could link a stranger.

Type a number, linked→Patient accepts, then linked

Change 4

Let people make text bigger

The text was too small to read.

One fixed size→Size the user chooses

Three of the four changes were about understanding, not layout. This test shows whether screens are usable. It does not show whether people keep taking readings or control their blood pressure.

Other checks: automated accessibility tests on the app screens, a colour contrast check that must pass before each release, and a security review of the live product. I reviewed each finding, approved the fixes and revoked an exposed API key.

08

What went wrong and what is not proven

Changed after I got it wrong

  • Kanban board. Replaced by a list sorted by urgency, because the board hid urgency.
  • Emergency readings in the "measure next" queue. Moved to their own card.
  • Language switch with two options. Replaced within hours by one button that names the other language.
  • Three "fresher" colour designs. Not used.
  • Low readings saved with no advice. The app now asks about symptoms first.
  • A welcome screen that asked for a name first. Replaced by one line and two buttons.

Not proven yet

  • Outcomes. There are no real patients yet. A pilot would measure adherence and referral completion.
  • The dashboard. No nurse or doctor has used it. The clinic-side decisions are my reasoning, not clinician feedback.
  • The alert path. It is built and checked in code but has never run on live data.
  • The 70/40 low-pressure line. It is my own choice and needs clinical review.
  • The emergency screen's "told" line. It now waits for the server's answer. I tested it with a stand-in server, not the live one.
  • The form of address. The age bands are my own and untested.

Next: sessions with a nurse and a doctor on the dashboard, then a pilot at one health station that measures referral completion and time to follow-up. A clinician will review the thresholds first.

Independent project, built with AI help. This is not client work and no company backs it. I used AI to summarise research, draft layouts and write front-end code from my specifications. Every design decision is mine. It uses no confidential material from any earlier employer or client, and its research uses public sources only.

More

InteractiveLive demoEnter a reading and watch it reach the caregiver and the dashboard. Design systemStyle guideColours, components and patterns, built from the real files. ProductOpen the appThe patient and caregiver app, running on a real database.