The patient portal is a marketing artifact.
The patient portal is the most-marketed and least-used piece of consumer-facing infrastructure in healthcare.
I have a portal account at four health systems. I check none of them more than twice a year, and the checks are reactive — somebody told me a lab result was posted, or a referral was supposed to come through, or the billing department flagged a charge. The portals do not pull me back in. They have no editorial voice, no useful summary, no integration across the four systems that hold pieces of my care, and no signal that my visits actually changed anything. They are file cabinets. They are file cabinets the institution put online and decided to call infrastructure.
The marketing claim is the opposite of this. Every health-system communications team has a patient-portal-as-empowerment paragraph in the boilerplate, and every IT vendor selling into that team has a patient-portal-as-engagement-driver pitch deck. The claim is that the portal gives the patient a single coherent view of their care, plus the ability to message the care team, plus self-scheduling, plus prescription refills, plus access to bills and outcomes. The claim describes a product that does not exist at any of the four systems I am a patient at, and as far as I can tell does not exist at any of the systems my friends and family are patients at either.
The gap between the marketed product and the lived product is not a UI problem. It is a structural problem about who the portal is built for.
The portal is built for the institution. The institution wants the patient to see the appointment confirmations, the post-visit summaries, the lab results that have been deemed safe to release without provider mediation, the bills, and the messages the institution wants to send. The patient wants something different: a current view of what is going on in their care, an ability to ask questions and get answers without booking a visit, and a sense that the system holding the data has any awareness of them as a person rather than as an account number. The two design targets are not the same target, and when the institution is the one paying for the portal and the patient is the one using it, the institution wins every design tradeoff. Every release. Every release cycle.
The result is a product that the institution describes as patient-facing and the patient experiences as institution-facing-with-a-login.
A small but useful test of this is the messaging feature. Every portal ships with one. Every portal has a different policy on what messages get answered, by whom, and on what timeline. Most have a default policy of "we will respond within three business days" that is operationalized as "we will respond within three to ten business days, and the response may not answer your question, and a response that requires clinical judgment may simply tell you to schedule an appointment." The messaging feature is not a way to get a question answered. It is a routing surface that funnels the patient back into the visit-scheduling workflow that the institution already had.
The patient learns this within the first or second message and adjusts. They stop sending messages. They stop opening the portal to check whether a message was answered. They use the portal as a one-way bulletin board for the things the institution is required to publish, and they use the phone or the in-person visit for anything that matters.
The one health system in 2024 that came close to building the portal the marketing implies was a regional integrated network in the upper Midwest that I am not going to name because the example will date. Their portal had three things the others did not. A messaging system that committed to a same-day response from a clinical-team-member by name, with the institutional support to make that commitment real. A summary view that synthesized the most recent encounters across primary, specialty, and lab visits into a single page that read like a briefing document rather than a list of files. A self-scheduling layer for the appointments where self-scheduling was clinically appropriate, with explicit institutional clarity on the categories where it was not. The product was not magic. It was the patient's view of the patient's care, designed by people who treated the patient's view as the design target.
What that system got right was not the technology. The technology stack was unremarkable. What they got right was the institutional decision to commit clinical staff time to the portal-as-channel, with the staffing model and the workflow integration that made the commitment durable. The portal worked because the institution had decided the portal was a real channel of care, not a marketing veneer over the file cabinet. The other systems describe the portal as engagement infrastructure and staff it as compliance infrastructure, and the gap between those two is the gap that the patient feels.
The diagnostic, for the operator considering whether to invest in their own portal, is to look at the staffing model. If the messaging feature is staffed by clinical-team members on a real shift, with response-time commitments tracked as quality metrics, the portal might be a real channel. If the messaging feature is routed to a triage queue staffed by nursing administrative time on a best-effort basis, the portal is a file cabinet with a marketing budget. The technology layer cannot fix the staffing decision. The staffing decision is the product.
I cancelled three of my four portal accounts in 2024. The fourth I keep because the prescription-refill workflow is genuinely better than calling the pharmacy. Even there, the rest of the portal is unused. The prescription workflow is the one feature where the institution and the patient share a design target, which is why it works.
The marketing case for the patient portal will continue. The vendor pitch decks will keep promising engagement, empowerment, and a single coherent view. The patients will keep not using them. The systems that decide to build the portal as a real channel of care will be visible because the patients in those systems will use it, and the engagement metrics will not need to be massaged. The systems that do not will keep reporting login counts and pretending the count is the metric.
The login count is not the metric. The metric is whether the patient comes back without being prompted. By that metric most portals are not infrastructure. They are filing.
—TJ