Making patient registry access less dependent on email

Overview

Patient and caregiver participation is foundational to rare-disease registries. But standard authentication assumes every participant owns a personal email address, can access it consistently, understands email verification, and will keep the same address over time. For patients, caregivers, proxies, older users, and shared households, that assumption quietly becomes an access barrier — and in a registry, losing access means losing the data contribution.

Discovery

The main risk was not forgetting a password — it was losing access to the identity channel itself

Mapping the current state showed the failure modes clustered somewhere unexpected. Not the login form: the channel behind it. No personal email. A shared family address. An inbox the participant can't reach. A caregiver relationship that changed. A phone number that moved.

That reframed the question. Not “how do we remove email from the login screen” but “how do we help participants establish, recover, and maintain access without relying on one fragile channel?”

Inclusive access

Alternative access needed to feel first-class, not like an exception path

The design risk in accessibility work is building a second-class route: a smaller link, a longer form, a flow that signals you're doing something unusual. An email-less participant is a normal participant in this product, and the entry experience had to say so.

The security-sensitive specifics stay out of a public case study, but the interaction requirements don't: clear labels, explaining what's needed before it's asked for, never revealing whether an account exists, safe handling of failed attempts, visible retry and lockout states, and a support path that doesn't dead-end.

Two routes

The participant shouldn't have to know which kind of account they have

Asking someone to self-identify as email-less at the moment they're locked out is both a usability failure and a disclosure risk. A single recovery entry point resolves the route behind the scenes.

An email-managed account gets a reset link and a plain description of what happens next. An email-less account is routed to the site coordinator, who is already a trusted party in the registry relationship — with a shared CAPTCHA step placed after valid-format input and before submission, so bot traffic can't use either path to probe for accounts.

Recovery

Recovery needed to restore access without exposing whether an account exists

Recovery is where inclusive design and security pull against each other hardest. The helpful message — “no patient exists with this identifier” — is exactly the message that confirms a registry participant to whoever typed it. In a rare-disease registry, that confirmation is itself sensitive information.

So the copy stays neutral regardless of outcome: if the information matches an eligible account, the next step becomes available. Less satisfying to read, and the only defensible option.

The failure states are the design work here. A happy-path recovery flow is a form; a recovery system is the set of answers to what happens when it doesn't work.

Patient profile

One page had to answer whether this person can actually get in

A coordinator chasing an access problem was previously assembling the answer from three places: the patient record for who this is, the account system for how they sign in, and the survey schedule for what they're missing while locked out. Those are one question in practice — can this participant participate — so they became one page.

The summaries deliberately stay separate rather than merging into a single status. Patient summary is the clinical identity, account summary is the access mechanism, and survey follow-up is the consequence of access failing. A participant can be clinically active, registration complete, and still unable to log in — and if the page collapsed those, that combination would be invisible.

Two details carry most of the argument. The account card refuses to leave anything blank — email reads No email registered, credential type reads Username + Passphrase, access type reads Site-managed — because an empty field in an access audit is indistinguishable from one nobody filled in. And the site action card turns a failure state into an assignment: action type, required action, the reason it is needed, a due date, and a task status, with reissue offered both there and in the account card it describes.

Account as a separate object

A patient record and a login are different things, and the product had to admit it

The original model assumed creating a participant created their account. That works until a participant is enrolled by a coordinator at a clinic visit, has no email, and won't be given credentials until someone can hand them over in person.

Separating the two means a patient can exist in the registry, contributing data through site-managed entry, before any account exists — and it means account state has somewhere to live that isn't the patient's clinical status.

Deactivating access and withdrawing a participant are also kept apart. Someone can lose their login and remain enrolled; conflating the two would let an account problem look like a clinical event in the data.

Coordinator side

Removing email as the recovery channel moves the work to a person — so that person needed real tooling

An email-less access model only works if someone can act on it. Site coordinators became the recovery channel, which meant the patient management table had to answer a question it previously couldn't: what state is this person's account actually in?

Account status was separated from patient status. A participant can be clinically active while their account is locked, pending first login, or awaiting a password reset — and conflating the two hides exactly the cases that need attention.

Each notification names the situation and the next action — a temporary password that expired unused, a participant who never completed first login, an account locked after failed attempts. Status alone would have left the coordinator to work out what it meant.

Reissue

Handing over a credential in person needed the same rigour as sending one by email

When a coordinator issues a temporary password, the credential exists outside the system for a moment — spoken, written down, or printed. That gap is where the design has to be strict.

Verification comes first, the password is shown once and never again, expiry is stated twice, and the coordinator has to explicitly acknowledge that they will share it through the site's approved process. The friction is deliberate: it's the step that keeps an offline handoff auditable.

Relationship management

Patient access could change when responsibility changed between caregiver, proxy, and participant

This is the part that makes registry identity genuinely different from consumer authentication. A caregiver may manage access for a dependent who later becomes legally able to manage their own records — a transition that is emotionally significant and, in a clinical context, consequential.

Account ownership isn't fixed to one person for the life of the account. The design had to hold caregiver-managed access, participant independence, revoked proxy access, and multiple authorized caregivers, with a supported path for confirming a new ownership model.

Accessibility here isn't a checklist item — it's the premise. These flows are used by people under stress, sometimes in a clinical setting, often not by choice. Plain-language instructions, visible labels, screen-reader-compatible status messages, no reliance on colour alone, time-limit warnings, and no memory-heavy security prompts.

Reflection

Outcome