What a Patient-Facing Health App Has to Get Right

Health software is held to a standard other consumer apps are not, and the standard is not really technical. People will forgive a plain interface. They will not forgive the feeling that their medical information is being handled carelessly, and that feeling forms in the first few screens.

We built the patient and doctor apps for a second-opinion service, HSA Second Opinion, where patients share a history and receive a considered answer from a specialist. What follows is the set of questions that mattered most, and they are not the ones that appear in a feature list.

Start with what you will not collect

The instinct in a first version is to capture everything, because storage is cheap and someone might want it later. In health software that instinct inverts: every field you store is something you must protect, justify, show on request and eventually delete.

So the first design session is subtraction. Does the clinician need a full history, or the relevant part? Does the app need a date of birth, or an age range? Does a photograph need to be kept after it has been reviewed, and if so for how long, and who decided? A field removed at this stage is a liability that never exists.

This is also the cheapest moment to do it. Retrofitting data minimisation onto a system already holding patient records means migrating live clinical data, which is slow and nerve-wracking in a way that deleting a form field is not.

Consent that means something

A checkbox agreeing to a policy nobody read is consent in the legal sense and worthless in the design sense. What patients actually want to know is narrower and more immediate: who will see this, for what, and can I change my mind.

Answering that at the point of sharing, in a sentence, does more for adoption than any amount of reassurance on a landing page. It also forces a useful internal argument, because teams often discover they cannot answer who will see it without inventing a rule on the spot. Better to discover that before launch.

Design for the worst moment, not the demo

Most health apps are demonstrated to healthy people in a meeting. They are used by someone anxious, possibly in pain, possibly reading something frightening on a phone at night.

That changes concrete decisions. Results should not arrive as a bare notification with no context and no way to ask a question. Clinical language needs a plain-English companion rather than a glossary somewhere else. Anything irreversible needs to be hard to do by accident. Text has to survive being scaled up, because a worried person using large type is a normal user, not an edge case.

Accessibility work belongs in this section rather than in a compliance checklist. In health software, the people who need larger text, higher contrast and screen-reader support are disproportionately your actual audience.

Messaging is a product, not a library

Patient-to-clinician messaging looks like a solved problem, and dropping in a chat component takes an afternoon. The hard parts are everything around it.

• What happens to a message sent at 2am when nobody is on duty, and does the patient know that before sending it
• What the app does when someone describes an emergency in a channel that is not for emergencies
• Whether a conversation belongs to a clinician or to the service, when that clinician leaves
• Whether messages form part of the medical record, and who decided that
• What a notification is allowed to say on a lock screen that someone else may see

That last one catches nearly everyone. A notification preview showing a clinical subject line on a shared phone is a privacy failure that no amount of encryption prevents.

Where regulation actually sits

Health data is regulated differently in every market, and the rules depend on where your patients are rather than where your company is. Whether your product is treated as a medical device, what retention periods apply, and what you must be able to produce on request are questions for people qualified to answer them in your jurisdiction.

What a development team owes you is not a compliance opinion. It is an architecture that can satisfy one: knowing where every piece of patient data lives, being able to export or delete one person's records without a hand-written script, and keeping a record of who accessed what. Those three make almost any future obligation achievable, and their absence makes all of them expensive.

It is worth being direct about what this means commercially. A team that tells you a product is compliant is overreaching, because compliance is a judgement about your service in your market, not a property of software. A team that tells you the system can produce everything an adviser would ask for is describing something it can actually deliver, and that is the commitment worth having in writing.