Guide

The portal: what to turn on, what to leave off

Summary

A short list is mandatory, not optional: results and notes release, and a working patient-directed API connection, because disabling them risks an information-blocking finding. Everything else — broadcast messaging, appointment self-scheduling, automated recall reminders, bill pay — is a genuine configuration choice. Run a security risk assessment before turning on anything that adds a new way data moves, confirm your vendor's business-associate agreement covers it, and enable features one at a time rather than accepting every default on day one.

By Gale Editorial · Updated 2026-07-27. Every figure cited to a dated source. How we write.

What you don't actually get to turn off

Results release, note release, and a functioning patient-directed API connection aren't portal features you're choosing to enable — they're the information-blocking default, and disabling them to avoid the extra front-desk workload or to "review before release" is exactly the interference the rule targets 1. If your EHR's portal has a setting that suppresses results or notes by default, leaving it on the vendor's factory setting is not a safe assumption; some ship more restrictive than the rule allows.

Check this once explicitly rather than trusting a vendor's default: log in as a test patient, or review the configuration screen directly, and confirm results and notes are actually flowing through, not queued behind a manual release step you'd have to remember to clear.

Run the security assessment before you flip anything else on

Every additional portal feature — messaging, forms, bill pay, scheduling — is a new way protected health information moves, and the Security Rule's risk-analysis requirement applies to each one, scaled to what a solo practice can realistically do, not to a large health system's process 2. ONC and OCR publish a free assessment tool sized for exactly this, and running it once for your full portal configuration, then again whenever you add a feature, is a reasonable cadence for a practice of one.

The safeguards that matter most in practice are the ordinary ones: unique logins for any staff who can see portal messages, a way to log who accessed what, and encryption in transit — all standard in a modern certified EHR, but worth confirming rather than assuming 3.

Confirm the vendor relationship covers what you're turning on

Your EHR vendor is very likely already your business associate for the portal's core functions, but a bolt-on feature — a separate scheduling widget, a third-party bill-pay processor, a add-on messaging tool — may be a different company entirely, and each one that creates, receives, or transmits PHI on your behalf needs its own business associate agreement 4. "It's part of the same portal" isn't the same as "it's covered by the same BAA" if the underlying vendor is different.

Before enabling any add-on feature your EHR markets as a portal upgrade, ask specifically whether it's the same covered entity relationship or a new one, and get the BAA in hand before patient data flows through it, not after.

What's worth negotiating at the contract level

Portal features are frequently tiered in EHR contracts — a basic messaging and results-viewing tier included, with scheduling, forms, and broadcast messaging sold as add-ons — and the contract terms around data portability, termination, and per-feature fees are worth reading before you sign, not after you're locked in 5. This becomes especially relevant if you're mid-negotiation on the ehr migration and can still shape which portal tier you're buying.

Ask specifically what happens to portal message history and patient-uploaded documents if you switch vendors later; some contracts treat that content as exportable EHI, others make it meaningfully harder to retrieve than the clinical record itself.

Secure messaging: the feature worth enabling deliberately

Patient-to-provider secure messaging is usually the single highest-value optional feature for a solo practice — it reduces phone tag and gives you a written record — but it also creates an expectation of response time that a solo clinician needs to set explicitly in the portal's own messaging screen, not just verbally. Some messages you answer through the portal are themselves billable under time-based codes, which the billable message covers in more detail.

Decide your response-time commitment before you enable it, state it in the portal's welcome text, and route anything urgent to a phone call explicitly — a portal message is not the channel for a patient to reach you about an acute concern, and your intake materials should say so.

Recall reminders and broadcast messaging: use with a marketing eye

Automated recall reminders — a message when a patient is due for a follow-up or an annual visit — are a low-risk, high-value feature most solo practices underuse, and recall systems covers the workflow side in depth. Broadcast or newsletter-style portal messages sent to your full patient list sit in different territory: once the content shifts from clinical reminder to something promotional, HIPAA's marketing rule requires the patient's authorization first, with narrow exceptions for face-to-face communication and nominal gifts 6.

A recall message ("you're due for your annual visit") is operational, not marketing, and doesn't need special authorization. A practice update styled like the newsletter — new services, a request for referrals or reviews — crosses into content that needs a closer look before you send it broadly.

A reasonable default for a solo behavioral health or primary practice

Enable results and notes release (non-negotiable), secure messaging with a stated response-time policy, and self-scheduling if your calendar tool supports it — that combination covers most of what patients actually use a portal for without adding features you don't have staff to monitor. Hold off on forms, bill pay, and broadcast messaging until the core three are running smoothly and you've done the risk assessment for each addition.

Revisit the configuration annually alongside your normal security risk assessment rather than only when a vendor update changes a default — portal settings drift, and a feature you disabled two years ago for a good reason can silently re-enable itself in an update.

Common questions

A fully disabled portal is very likely an information-blocking problem if your certified EHR is capable of running one — the rule doesn't require a portal to exist from nothing, but if your system has the capability, refusing to activate it functions as obstruction rather than a neutral choice. If you have a specific, documented reason a portal isn't feasible, that's a narrower question than simply preferring not to run one.

No blanket consent requirement exists feature-by-feature the way it does for marketing communications, but your Notice of Privacy Practices should describe how you use the portal generally, and any feature that adds a new use of PHI beyond treatment, payment, or operations is worth a specific look rather than an assumption that general treatment consent covers it.

Yes, with the same access controls you'd apply to any staff handling PHI — a unique login, role-based permissions limiting what they can see or send, and clarity on what they can answer directly versus what needs to route to you. Document that arrangement in your risk assessment rather than treating it as an informal habit.

It's a genuinely useful feature for patient-supplied paper and outside records, letting patients send documents directly instead of mailing or faxing them, but confirm the upload feature routes into a location you actually review — an upload folder nobody checks is worse than not offering the feature at all.

Run your practice on Gale

The software is free. Gale earns one flat 3.5% all-in per paid transaction — only on transactions that actually pay. No subscription, no setup fee, no network cut.

Start or manage a practice →

References

  1. 1.Office of the National Coordinator / ASTP (2026). Information Blocking. HealthIT.gov. linkThat disabling default results release, note release, or patient-directed API access in a portal risks an information-blocking finding absent a documented exception.
  2. 2.Office of the National Coordinator / ASTP (2026). Security Risk Assessment Tool. HealthIT.gov. linkThat ONC/OCR publish a free risk-assessment tool sized for small practices, used here for assessing each new portal feature before enabling it.
  3. 3.HHS Office for Civil Rights (2026). Summary of the HIPAA Security Rule. U.S. Department of Health and Human Services. linkThat the Security Rule requires safeguards scaled to practice size, anchored in a risk analysis, for each channel through which PHI moves.
  4. 4.HHS Office for Civil Rights (2026). Business Associates. U.S. Department of Health and Human Services. linkThat any vendor creating, receiving, or transmitting PHI through an add-on portal feature is a business associate requiring its own BAA, distinct from your core EHR vendor's agreement.
  5. 5.Office of the National Coordinator (2016). EHR Contracts Untangled: Selecting Wisely, Negotiating Terms, and Understanding the Fine Print. HealthIT.gov (ONC). linkONC's guidance on negotiating EHR contract terms, used here for portal feature tiering, per-feature fees, and data portability of portal content.
  6. 6.HHS Office for Civil Rights (2026). Marketing. U.S. Department of Health and Human Services. linkThat HIPAA requires patient authorization before using PHI for marketing, with narrow exceptions, distinguishing operational recall reminders from promotional broadcast messaging sent through the portal.

https://www.gale.care/for-providers/cde-portal-configuration · 6 sources. Competitor details are cited to dated public sources and maintained as they change; figures are estimates, not commitments. Synthetic demonstration.

Findability, by specialty

How practices like yours get found in local search and AI answers — the honest playbook, per specialty.

SEO for private practices · SEO for AI search / answer engines (all verticals)