AI Medical Data Consent Flow

Sina, Altibbi's AI health assistant, became capable of reading medical facts out of ordinary messages — age, gender, symptoms, chronic conditions, medications. Someone types my doctor said I have high blood pressure, what helps bring it down and the system now knows they have a chronic condition.

The design question is not how to store that. It is whether the product is allowed to.

Role: Product designer — owned the confirmation flow across chat and the medical profile.

Context

A medical profile makes everything downstream better. Consultations start with history instead of questions, recommendations account for existing conditions, and the assistant stops asking things the user has already said.

Profiles are also the least-completed screen in almost every health product. Nobody opens an app to fill in a form about their illnesses.

Extraction solves the completeness problem and creates a different one. The information was volunteered inside a conversation, for the purpose of that conversation. Filing it permanently is a second thing, and the user has not agreed to it.

They told the assistant something. They did not hand over a record.

The constraint

The brief asked for clear, trustworthy and low-friction — without interrupting the chat.

Those pull against each other. Real consent needs attention, and attention is exactly what an interruption takes. Anything modal stops a person mid-question about their own blood pressure to handle a data-management task they did not ask for.

What I designed

The prompt lives inside the conversation, under the answer. Sina answers the question first. Then, below a divider, it says what it noticed and asks: I see you mentioned a chronic condition. Do you want to add it to your medical file? The extracted value is listed plainly underneath — high blood pressure — with Add to medical file and Edit.

Answering first matters. A product that interrupts to collect data before helping has revealed which of the two it cares about.

Nothing enters the record unless the user says so — and nothing is thrown away either. No pre-ticked box, no save-with-undo. Ignoring the prompt is a valid answer and the most common one: scroll past, keep talking, and the record stays untouched.

But the extraction does not vanish. It surfaces as a pending card in the medical profile, where the user can confirm or edit it whenever they are actually thinking about their health rather than mid-question about their blood pressure. Chat is a bad place to make a filing decision. The profile is the right place, and the pending card is how a decision gets moved there instead of forced or lost.

One item at a time, as it appears. Extraction happens continuously, so batching in chat would mean a queue of decisions arriving at once. A single item, at the moment it comes up, in the context that produced it, is a decision the user can actually make — and the ones they skip collect quietly in the profile rather than piling up in the conversation.

Confirming collapses the prompt. The button is replaced by a small confirmation linking to the profile, and Edit stays available. The conversation continues below it.

The profile says where the data came from. The section is headed medical information extracted from your conversations with Sina — not presented as if the user typed it. Each entry carries Confirm and Edit, so an extracted value stays provisional until the user affirms it, and the profile can distinguish between what it inferred and what it was told.

Auto-save is a toggle the user owns. For people who want extraction without being asked every time, standing consent is available and reversible — in the profile, next to the data it governs, not buried in settings.

Everything is Arabic-native RTL: reading order, the divider that separates Sina's answer from Sina's request, and the placement of the primary action.

The decision I would defend

Opt-in over opt-out, on a screen where opt-out would obviously perform better.

Auto-saving with an undo affordance is the industry norm, and it would have filled profiles faster. It also converts did not notice into agreed, which is not consent, and it does it with chronic illness data. In a product whose users are worried about their health and often not technical, quietly building a medical record out of half-remembered mentions is the kind of thing that is fine until the day it is not.

The pending card is what makes opt-in affordable. The usual argument against asking permission is that most people ignore the question and the data is lost — so you take it by default and offer an undo nobody uses. Deferring instead of discarding removes that tradeoff: the user is asked once, cheaply, in context, and if they do not answer, the question waits somewhere they will see it again.

The auto-save toggle is the other half. Anyone who wants extraction without being asked can grant standing consent deliberately, and withdraw it the same way.

Reflection

The information is extracted, and extraction is imperfect. Someone typing my father has diabetes is describing their father, not themselves.

The flow handles that with Edit, which puts the correction burden on a user who may not read carefully — the same user the opt-in default exists to protect. And a pending card that is never confirmed is still a system holding an inference about someone's health; deferring the decision is better than taking it, but it is not the same as not making one.

If I revisited this, I would look at confidence: a value the system is unsure about should ask differently from one quoted verbatim, rather than every extraction arriving with equal certainty. Pending items probably need an expiry too — a question nobody has answered in six months has been answered.