The Patient Portal Nobody Uses: Why Logins Kill Adoption and What Works Instead

Every clinic has a patient portal and almost no clinic has patients who use it. The vendor's report says hundreds of accounts were created; the front desk says patients still phone to ask when their appointment is. Both are true, and the gap between them is the login. Patients describe it plainly: a password for every clinic they attend, an app for each one, a card demanded before anything works, and nothing inside worth the effort. A patient portal that opens from a link with no login is the reverse of that design, and this post explains why it works when the login model does not.

How the portal became the thing nobody uses

The portal was built from the clinic's point of view: a secure place where the patient can see their information, so the clinic can stop sending it. Security meant an account, an account meant a password, and the password meant an email to verify, a username to remember, a reset flow, and, as portals moved to apps, a download. Each step was reasonable. Together they built a wall between a patient who wanted to know one thing and the one thing.

Then the portal was measured by accounts created, which rewarded clinics for forcing sign-up at check-in, which produced thousands of accounts that were logged into once, by a receptionist, on a tablet.

What patients actually say

Read any patient-side discussion and three complaints repeat.

"Another password." Patients attend several clinics, each with its own portal, and describe logging in fifty times a year across them, resetting passwords on the day of the appointment, and eventually phoning instead.

"Another app." A download, a notification permission, an update, for an app opened twice a year. Patients decline, and the clinic's messages then fall back to a letter.

"Give us your card first." Some platforms ask for payment details before the portal does anything, which practitioners describe as the point their clients refused to continue.

And underneath all three: "there was nothing in it." A portal that shows the appointment the patient already has, with no way to change it, no letter yet, no result yet, is a portal with no reason to return.

What works instead

The design that gets used reverses each decision.

A link, not a login

The portal opens from a secure link in the message the patient already received: the booking confirmation, the reminder, the results-ready notice. On text, WhatsApp or email. No password, no app. The link is signed, single-purpose and expiring; the message carries no clinical detail; and views the clinic considers sensitive can ask for a one-time code sent to the same phone. It is the model banks and airlines use, for the same reason: a security measure that is used protects something, and one that is bypassed by phoning reception protects nothing.

One thing to do

Each message brings the patient to one task. Confirm or move the appointment. Complete the form. Read the letter. Pay the invoice. The portal is there behind it, with the rest, but the patient was brought for one reason and can do it in two taps. Portals built as destinations are visited by nobody; portals reached as the next step of a message are used by almost everyone the message reached.

Content that is actually there

The link goes out when there is something behind it. A results-ready message when the result is ready. A letter notice when the letter is on the record. A form link when a form is due. The patient learns that opening the link is worth it, which is the only adoption strategy that has ever worked.

Nothing asked for that is not needed

No card unless the clinic requires one for that appointment type, and then at the moment it is needed, with the reason stated. No registration beyond what the booking already captured. No notification permission for an app that does not exist.

Patients who want a login can have one

None of this removes the account for patients who want it: a parent managing three children's appointments, a patient with a long condition who checks results often. They can set a password and come back directly. The point is that nobody is forced to, and the clinic's messages do not depend on it.

Measuring it honestly

Replace the accounts-created number with three per message type:

Message	Measure
Reminder with confirm and reschedule	Share confirmed or moved from the link
Form link	Share completed before the visit
Letter or result notice	Share opened within two days

Those are adoption. They also tell the clinic which messages are landing and which are not, per channel, which is operational information, not a vanity report.

A note for clinics mid-contract

If your current portal is the login kind, you do not have to wait for a platform change to apply the principles. Send the portal link in the reminder rather than expecting patients to find it. Stop forcing sign-up at check-in. Send messages only when there is something behind them. Measure opens and completions. The numbers will move, and they will tell you how much the login itself is costing when you next choose software.

One patient, one visit, from the phone

Follow one patient through a visit to see the difference. Tuesday evening, a text from the clinic: an appointment on Friday at ten, with Confirm and Change buttons and a line saying a short form is waiting. One tap confirms. A second tap opens the form on the phone, six minutes, done, with the consent signed at the end. Thursday, a reminder with the address and a link to what to bring. Friday, the visit. Monday, a message that a letter is ready; the link opens it, no password asked, and a one-time code arrives because the clinic set letters to require one. The following week, an invoice link, paid in two taps.

At no point did the patient create an account, remember a password or install anything. At every point the clinic knew whether the message was opened and the task done. That is a portal with adoption, and it has no login screen.

Objections clinics raise

"Our patients are older." Older patients are the group most likely to be defeated by a password and most likely to open a text from a number they recognize. The link model is built for them.

"Our compliance team wants logins." Ask what the login is protecting against, and compare it with a signed, expiring, single-purpose link with no clinical detail in the message and a one-time code on sensitive views. Most teams, shown the two side by side, prefer the model that patients actually use, because a portal that drives patients to phone reception with their date of birth is the less secure one.

"We already have a portal in our EHR." Keep it for the patients who use it. Send the link-based one from the reminder for everyone else, and compare the open rates after a month.

How Capra does it

The patient portal opens from a secure link in the confirmation, the reminder or the notice, on text, WhatsApp or email, with no password and no app; one task per message with the rest behind it; letters, results, forms, invoices and a message thread with the clinic; a one-time code where the clinic wants it; and reporting on opened and completed per message type. The patient engagement page covers the messages the link rides on, the intake forms page covers the form flow, and a demo will show the portal from a patient's phone.