Playbook, healthtech app
The identity check is against the record, not against an email address
A health account is not a login sitting on top of a shopping basket. The identity behind it was checked once against a record that now holds consultations, medicines and readings, so getting back in is deliberately harder than it is anywhere else. The person writing is usually locked out of something they need this week rather than something they wanted to browse.
Why this is not the general answer
The handling pattern for account access problems holds across every trade. What follows is the part that does not.
- Everything since sign up has been bound to the identity that was verified then, so changing a phone number or an email is a re-verification rather than a settings change, and the person who has already changed both is the hard case.
- Being locked out is a continuity problem rather than an inconvenience, because the medicines list, the consultation history and the reminders all sit behind the same door, and somebody who cannot reach them may be days away from needing them.
- An account created by a parent commonly transfers to the young person at a published age, so access disappearing on a birthday is the policy working rather than a fault, and no family finds that out until the morning it happens.
- Confirming that an address or a number belongs to an account would confirm that a named person uses a health service, so the refusal here is not caution about support, it is the entire point of the process.
How it arrives
- i changed my phone number and cant get past the verification
- my daughters account stopped working on her birthday
- how do i prove who i am to get back into the app
- i need my medication list and i am locked out
- can you unlock my account i have a consultation booked
- why is signing in harder than it used to be
What has to be indexed for this to work
| The identity standard for opening and for restoring an account | What was checked at sign up, what has to be checked again to restore access, and how long each route takes. The reason it is stricter belongs in the same paragraph as the steps, because read on its own the process looks like obstruction. |
|---|---|
| How verified contact details are changed | The route for a new number or a new address, what happens when both have changed at once, and what somebody does when the old one is gone for good. That last case is the one that actually arrives and it is almost never written down. |
| The age at which an account set up by a parent transfers | The published age, what happens on the day, what the parent keeps and what they lose, and how the young person completes their own check. Publish it before it bites a family, since it always arrives as a fault report. |
| What is behind the account, listed plainly | Medicines, consultation history, readings from a connected device, documents. Somebody deciding whether to chase this today or next week is weighing exactly that list, and it is worth writing so they can weigh it properly. |
The reply
Restoring access here means proving identity again rather than resetting a setting, because the account is tied to a record, and the routes are set out on our account security page [1]. If your number or your email has changed there is a separate route for that, including the case where the old one is no longer reachable [2]. An account a parent set up transfers to the young person at the age published there. I cannot see accounts, verify anybody or unlock anything, so leave your name, an email you can read and a short message and it goes to the team. If you are locked out and something about your health cannot wait, please contact your own doctor or the emergency services rather than waiting on this.
It gives the reason the process is heavy in the same sentence as the process, since somebody who feels obstructed argues instead of reading. The changed contact route is volunteered because that is the version that actually turns up. The last line moves anything time critical off a chat window without asking the person to describe what is wrong.
Where it stops
The trigger. The visitor asks for an account to be unlocked, asks whether an address or a number is on file, or says they are locked out with a consultation or a medicine review coming up.
I cannot verify anybody, look up an account or restore access, and I am not able to say whether an address is on file. Leave your name, an email you can receive mail at and what has happened, and it goes to the team. If this is about medicine you are due to take, please contact your own doctor now rather than waiting for a reply.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never confirm or deny that an email address, a phone number or a named person is attached to an account, because on a health product that is a disclosure about somebody's care.
- Never say access has been restored, an identity accepted or a check passed, since nothing typed here reaches an account.
- Never suggest signing up again on a different address as a way round a lockout, because it separates a person from the record built under the first one.
- Never advise anybody about their medicines or their symptoms while they are locked out, whatever the access question was.
Questions
- Could it unlock an account if we connected it to our systems?
- No. It reads the documents you give it and writes nowhere, and the check this process exists to perform is precisely the one a chat box cannot do, which is establishing who is typing. What it removes is the message that only ever wanted to know which route to use.
- The age transfer generates angry messages. What should it say?
- The age, what happens on the day, and how the young person completes their own check, all from your published page. A parent whose access has vanished assumes something has broken, and reading that it was scheduled turns a complaint into a task.
- Somebody insists they are the account holder. Does that soften anything?
- No, and the wording should not move at all. A refusal that bends under a convincing claim is not a refusal, and the thing being protected here is another person's health information. Route it quickly instead, so somebody who can actually verify sees it.
Keep reading
- Everything for a healthtech appHealth data is a special category and clinical claims carry device rules. What a healthtech assistant answers for patients, and for buyers.
- Handling account access problems in generalLocked out, wrong email, a colleague who left, no admin remaining. Identity cannot be checked in a widget, so explain, collect, hand over.
- The reset email arrives and the sign in still failsRecovery codes, a second step and the phone the app trusts. Why nobody in a chat window can reissue a way in, and what can be explained.
- The plan price is not the price of being seenConsultation allowances, the plan that has none, and the medicine priced somewhere else. Publishing a health price so nobody is surprised twice.
- The person seen and the person billed are often not the sameThe receipt someone claims back on, the invoice that goes to an employer, and why neither of them should state a clinical reason.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.