At 11:14 on a Sunday night, a patient sends your portal a message: "I'm on day 4 of the antibiotics for pneumonia and I still feel awful — should I keep taking them?" Nobody reads it until Monday at 9:40. By then it sits in a shared inbox alongside a refill request, two scheduling changes, and a message from an adult daughter asking about her father's chest X-ray. This article is about what your practice does with those messages — routing, retention, access rights, vendor contracts, and the front-desk safeguards that keep one inbox from becoming a breach report. It is an operations post, not a clinical one.

What a Single Portal Message Actually Creates

Operators tend to treat portal messages as email. They aren't. One message about a course of antibiotics for pneumonia typically generates at least three durable artifacts, each with different obligations attached.

  • The message thread itself, which usually lands in the chart or a message queue linked to the chart.
  • An audit log entry recording who opened it, when, and from what account.
  • A vendor-side copy — in the portal module's database, in a notification relay, and sometimes in an email or SMS alert that says "You have a new message from Dr. ___."

That third artifact is the one practices forget. The alert notification is often routed through a different system than the portal, and it is often the one that leaks context. "New result from Pulmonology" in a text preview on a lock screen is a disclosure your policy should have decided about in advance.

Is a Patient Portal Message Part of the Designated Record Set?

Usually, yes. Under 45 CFR 164.501, the designated record set includes medical and billing records used in whole or in part by or for a covered entity to make decisions about individuals. If a clinician read a patient's portal message about their antibiotics for pneumonia and adjusted a plan, changed a follow-up interval, or ordered imaging based on it, that message was used to make a decision about that individual. It belongs in the record set, and it is subject to the right of access.

Practical consequences for your practice:

  • If a patient requests "my complete record," your production must include portal message threads unless you have a documented reason to exclude them.
  • Amendment requests under 164.526 can reach message content.
  • Your retention schedule must cover the messaging module — not just the chart notes.
  • If you migrate portals, message history has to migrate with it or be exported and preserved.

HHS has published detailed guidance on the individual right of access, including format, fees, and the 30-day timeline, at hhs.gov's right of access page. Read the section on "form and format" before your next portal RFP, not after.

Routing Rules Your Front Desk Can Actually Follow

The failure mode is not malice. It's a shared inbox with no triage tiers, staffed by whoever has a free minute. Write four tiers and post them at the desk.

Tier 1 — Administrative

Scheduling, address changes, insurance updates, billing questions. Front desk handles end to end. No clinical content is authored by non-clinical staff, ever. If a scheduling message drifts into symptoms, it gets reclassified, not answered.

Tier 2 — Clinical content

Anything describing symptoms, medication effects, or treatment questions — including the classic "my antibiotics for pneumonia are making me nauseous." Front desk forwards without commentary, tags it clinical, and logs the forward time. Staff never write "keep taking them" or "that's normal." That is practicing medicine from the front desk, and it is also the sentence that shows up in a deposition.

Tier 3 — Records requests in disguise

"Can you send my chest imaging to my new doctor?" is a records request, and the 30-day access clock starts on receipt — not on the day someone notices it. Assign one named person to sweep the portal inbox daily for these and log them in the same tracker you use for faxed and mailed requests.

Tier 4 — Urgent or after-hours

Your portal is not a triage line, and your banner text should say so in plain language. Decide who checks the queue on weekends, whether that's zero coverage with a clear notice or a designated coverage rotation, and document the answer. The compliance failure is not the choice you make — it's having no written choice at all.

The Vendor Chain Behind One Message Thread

Map it once and the risk becomes obvious. A pneumonia follow-up exchange commonly touches:

  1. The portal or patient engagement module (often, but not always, the EHR vendor).
  2. The SMS or email notification relay that tells the patient a message is waiting.
  3. The after-hours answering or nurse-line service that receives overflow.
  4. The e-prescribing network, if a prescription change results.
  5. A translation or interpretation vendor, if the thread is handled in another language.
  6. Cloud backup and any archiving service holding message history.

Every one of those is a business associate. Every one needs a signed agreement in place before PHI moves, and the agreement needs to say something specific about breach notification timing, subcontractors, and what happens to your data at termination. If your BAA folder has gaps — the interpretation vendor you started using in March, the texting reminder tool a manager signed up for with a credit card — you can close them the same week. The six-step Business Associate Agreement generator produces a signature-ready BAA with PDF and DOCX export as a one-time purchase, which is faster than routing a redline through counsel for a $40/month reminder tool.

One more vendor question worth asking in writing: does the notification relay store message content, or only a "you have a message" trigger? The answer changes your risk analysis and it changes what a vendor breach would mean for you.

Minimum Necessary Inside a Shared Inbox

Shared portal inboxes quietly defeat role-based access. If eight staff accounts can open every clinical thread, your access controls exist on paper only.

Three fixes that don't require new software:

  • Split the queue. Most portals support at least an administrative pool and a clinical pool. Use both. Front desk sees Tier 1; clinical staff see Tier 2.
  • Kill generic logins. One shared "frontdesk" account makes your audit log worthless. If you cannot attribute an access to a person, you cannot investigate a complaint or a snooping allegation.
  • Review the log quarterly. Pull thirty days of message-access events, spot-check ten, and document that you looked. NIST's SP 800-66 Revision 2 maps Security Rule requirements to practical safeguards and is a reasonable backbone for that review.

Proxy Access: The Caregiver Problem in Follow-Up Care

Recovery from a serious respiratory illness often runs through a caregiver — an adult child, a spouse, a home health aide. That caregiver will message the portal. Sometimes from the patient's own account.

Your policy needs answers to four questions, written down:

  • How does someone get proxy access, and what documentation do you require?
  • Does proxy access expire, and who reviews it?
  • What does a proxy see — full chart, or a limited view?
  • What happens when a proxy relationship ends (divorce, a teen aging into adult privacy rules, a revoked power of attorney)?

Personal representative rules under HIPAA are narrower than most front-desk staff assume. HHS's guidance on personal representatives is short enough to include in your onboarding packet. Add one line to your desk script: "I can confirm you're listed as an authorized contact — let me check that before we go further." Staff need permission to pause. Give it to them in writing.

Texting, Unencrypted Email, and What Patients Are Allowed to Request

Patients may ask you to communicate by unencrypted email or text. Under 45 CFR 164.522(b), individuals can request confidential communications by alternative means, and HHS's access guidance makes clear that a covered entity may honor an individual's request for unsecured email after warning them of the risk. The requirement is the warning and the documentation — not refusal.

Build it as a workflow, not a judgment call:

  1. Patient requests texts or plain email.
  2. Staff deliver a scripted risk statement and note it in the chart.
  3. Preference is recorded in a structured field, not a sticky note.
  4. Content sent by that channel stays minimal — appointment logistics, "a message is waiting," no diagnosis detail by default.

That last item is your own policy choice, and it's a good one. The patient's right to receive communications a certain way does not obligate you to broadcast clinical detail into a channel you don't control.

Result Release Timing and Information Blocking

Follow-up after a course of antibiotics for pneumonia frequently involves repeat imaging or labs, which means results land in the portal — often before the clinician has reviewed them. Practices sometimes respond by adding manual delays across the board.

Be careful. Under the information blocking rules, delaying or restricting access to electronic health information can constitute interference unless an exception applies, and exceptions are specific and documented. The practical guidance and exception descriptions live at healthit.gov's information blocking resource. Blanket delay policies with no documented basis are the pattern that draws complaints.

What works instead: a written release policy, per result type, with the reasoning recorded, plus a same-day workflow for clinician outreach on findings that warrant a phone call. That's a process design problem, and it belongs to you, not to your vendor's default settings.

When a Message Goes to the Wrong Person

The most common portal incident is not a hacker. It's a message sent to the wrong patient record, or to a proxy whose access should have been terminated. Treat it as a potential breach and run the four-factor risk assessment under 164.402: nature and extent of the PHI, who received it, whether it was actually acquired or viewed, and the extent to which risk has been mitigated.

Document the assessment even when you conclude notification isn't required — especially then. Log small incidents as you go so the annual reporting deadline for breaches affecting fewer than 500 individuals doesn't turn into a January scramble. Your incident log should capture date discovered, date occurred, records involved, assessment outcome, and corrective action.

A Six-Item Policy Checklist to Adopt This Quarter

  1. Written triage tiers posted at the desk, with named owners and response targets in business hours.
  2. A daily inbox sweep for records requests, feeding the same tracker as paper requests.
  3. Role-split queues and individual logins, with a quarterly audit-log spot check.
  4. A proxy access procedure covering grant, review, and termination.
  5. A documented alternative-communications workflow with a scripted risk statement.
  6. A current BAA for every system that touches message content or notifications, including the ones a manager signed up for without telling you.

Start with the sixth item, because it's the one you can finish today. Pull your vendor list, mark the gaps, and generate the missing agreements through the BAA wizard — one-time purchase, signature-ready, no subscription to manage. If your broader documentation set is also overdue, automated risk analysis and policy generation covers the rest. Then go rewrite the triage tiers, because your Sunday-night inbox is filling up right now.