The blank box: why your patient portal inbox was designed to overflow

Between 2020 and 2025, the number of messages patients sent through patient portals increased by 153%. That growth comes with real benefits. Portal communication has been linked to improved patient satisfaction, medication adherence, disease self-management, and preventive care. But as messaging has become a routine part of care, clinicians and staff have also had to absorb a growing volume of work on the other end. And we haven’t made that work any easier by giving patients a blank box without helping them provide the information their care teams need.

Earlier this month, James H. Stein, MD, a preventive cardiologist at the University of Wisconsin, published a short guide for patients titled “How to Write a Patient Portal Message Your Health Care Team Can Act On Quickly.” [Full disclosure: Dr. Stein used to be my cardiologist!] He gives good advice. Put the problem in the subject line (“Chest pain,” not “Question”). Describe the symptom, rate it from one to 10, say when it started and whether it is getting better or worse, and ask one question per message. He recommends skipping the apology; as he puts it, “apologies and preamble make a message longer, slower to read, and slower to act on.” If the problem is new chest pain or fainting, don’t message at all; call the office or 911.

In the article’s comments, a fellow physician pointed out that the template “would be a very useful macro to automatically display on any patient-facing portal message screen.” He is right, and the observation is more critical than he probably intended. A cardiologist with decades of experience taking patient calls has written the specification for a message composer, and the only place he could publish it was a newsletter … because nobody has built the composer. Meanwhile, we’ve spent five years grousing about what comes out of the blank box. We’ve argued about who should answer those messages and whether to bill for them. The message itself is the one part of the problem nobody has tried to redesign. #Uhoh

Why the patient portal is an intake channel without an intake

When you call 911, the operator does not wait to see how well you tell the story. Dispatch centers run processing protocols. Is the patient breathing? Is the patient conscious? How old is the patient? The caller doesn’t need to know what matters to a paramedic because the protocol knows. The patient portal is the rare high-stakes intake channel that assumes the sender (the patient) already knows what the receiver (the clinician) needs.

It didn’t have to be that way. On my third day working at EHR vendor Epic, I found a sheet of paper taped to a restroom door: “Toilet overflowed. Helpdesk ticket submitted.” The ticketing system behind that note was homegrown, ugly, and better designed than any patient portal I have used since (I wrote about it a few years ago). It let you give as much or as little information as you had, with the questions that usually helped printed right there, and a note that blanks were fine and someone would follow up. If you filed a laptop problem that was really an email problem, a human quietly re-categorized it rather than bouncing it back. And you could see where your ticket sat and who had it.

Three rules, then: Guide, forgive the miscategorization, and show the status. The typical portal message screen follows none of these rules.

What flows through the blank box is mostly work the patient shouldn’t be doing. When Kaiser Permanente oncologists reviewed a random sample of 500 patient message threads, only 26.8% required an oncologist; 38% could have gone to a nurse, 28% to a medical assistant, and 2.4% belonged in an emergency department. Every message was addressed to the oncologist, and nothing about the composer could tell them apart until a human opened each one.

How the blank box can create inequities in patient message triage

In August, researchers at Mass General Brigham (MGB) published an analysis in JAMA Network Open of 3.6 million patient-initiated medical advice threads sent to primary care clinicians over three years. Most of the practices triage through a shared pool, where a nurse or medical assistant decides whether the message reaches the physician it was addressed to. Black patients were 11.6% less likely than white patients to get a response from their physician, with similar gaps for Hispanic patients, Medicaid patients, and patients with only a high school education. What patients were asking about explained almost none of that gap. How they wrote explained about half of it: 48% of the gap for Black patients and 60% for patients with only a high school education.

The specific features are worth knowing. Opening with the physician’s last name was associated with a five-point higher chance of a physician reply and a first name with eight. Messages of 25 words or fewer lost about nine points. The word “please” cost about two points. Patients from historically marginalized groups wrote shorter messages, used less punctuation, and were less likely to greet the physician by name. The study is cross-sectional and from one system, and the authors don’t claim causation. But the mechanism they describe is one every chief medical informatics officer will recognize: A triage nurse with seconds per message and no structure to lean on reacts to the only signal available, which is how fluently the message was written.

Now think about this information relative to Dr. Stein’s advice. He tells patients to drop the preamble and get to the point. The data say the greeting is worth five points, and brevity is penalized. Both are right, and that, my friend, is the indictment. Style decides triage only because the box offers nothing else to triage on. The MGB authors reach the same conclusion in their discussion, suggesting that “modifications to portal interfaces could aid patients in structuring their messages and standardize writing style.” A structured composer is an equity intervention; too bad it doesn’t exist yet.

Why AI belongs on the patient’s side of the message

Stanford’s early evaluation of AI-drafted replies enrolled 162 primary care and gastroenterology clinicians for five weeks. They started from the draft 20% of the time, and the audit logs showed no change in reply, read, or write times. Task-load and exhaustion scores did improve, and the authors offer the fairest reading: “switching from writing to editing may be less cognitively taxing despite taking the same amount of time.” A one-year study at Groningen measured savings of about 15 seconds per message, and NYU built a model to identify alarming messages in a nurse pool, which resulted in after-hours messages being read 21 minutes sooner.

These are real gains. But every one of them operates after the message has been written, sent, and routed to the wrong person. The drafted reply saves a physician seconds on a message a nurse could have handled, and the prioritization model finds the chest-pain message after it has been sitting in a pool. The signature generative-AI investment of the last three years reads the output of a box that nobody designed because it’s just a box.

The exception is instructive. A Vanderbilt team built a large language model whose job is to interrupt the patient before the message is sent. It recognizes an emergency and tells the patient to call rather than continue typing. On 1,020 real messages, it caught 98% of emergencies, with one false alarm per five flags. It is retrospective and not yet deployed, but it is the only design here that puts the model where the problem starts.

Five ways to redesign the patient portal message

The internal Epic help desk taught me to guide, not gate. Required fields produce garbage, because a patient who doesn’t know the answer will type something to get past the stop sign, whereas optional prompts produce signal instead. What can we do?

1. Replace the blank box with Dr. Stein’s prompts as optional fields for any message about a new or changed symptom: what, where, how bad from one to 10, since when, better or worse, and the one question you want answered. Leave a field blank, and the system says, in plain language, that someone may need to call you to get more information.
2. Let the composer do the routing. The patient picks a reason, the system picks the queue, and when the patient picks wrong, a nurse re-categorizes without bouncing the message back. A reason field would not have sorted the clinical questions, but it could have routed refills, forms, and scheduling away from the physician before anyone read them.
3. Allow the one interruption that should be an interruption. A red-flag detector at composition, of the kind Vanderbilt tested, could tell the patient describing crushing chest pain to call now, in place of the gray disclaimer nobody reads.
4. Move the language model to the patient’s side of the box. A model that asks, “When did this start?” before the patient hits send removes a round trip and standardizes the exact style features that MGB found driving the triage gap. This is speculation; the MGB authors suggest it, but I can find no published confirmation.
5. Show the patient where the message is: received, with the nurse, or with Dr. Smith. The internal Epic help desk did this in the early 2000s. I don’t have a study showing it reduces duplicate messages, but I would take that bet.

Over-structure the form, and you get the mirror image of the MGB finding, a screen that demands fluency and re-creates the gap it was meant to close. That is why the guardrail matters more than any single field.

Dr. Stein wrote his guide because, after decades of taking patient calls, he knows what the person on the other end needs and knows the portal will never ask. The measure of a well-designed composer is that his post becomes unnecessary.

The patient shouldn’t have to learn what a cardiologist wants to know. The box should ask.