HIPAA-Compliant Patient Portals: Requirements, Software, and Examples

Looking for a HIPAA-compliant patient portal? Here's what HIPAA actually requires of patient portals, which platforms qualify, and how to verify compliance before you buy.

HIPAA-Compliant Patient Portals: Requirements, Software, and Examples

If you’re searching for a HIPAA-compliant patient portal, the marketing copy of every vendor will tell you they have one. Almost none of them define what that means. Some of them are wrong. Picking the wrong platform doesn’t just create a compliance risk — it can put your practice on the wall of shame at HHS.

This guide walks through what a HIPAA-compliant patient portal actually needs to do, which platforms meet the bar, the questions to ask before signing, and where most practices get tripped up. If you want the deeper technical breakdown, our HIPAA-compliant customer portals guide goes spec-by-spec; this article focuses on the patient-portal-specific decisions.

HIPAA-Compliant Patient Portals: Requirements, Software, and Examples — portal dashboard concept

What “HIPAA-Compliant Patient Portal” Actually Means

There’s no government-issued “HIPAA certification” — anyone who claims one is either misusing the term or selling something. A patient portal is HIPAA-compliant when it implements the safeguards required by the HIPAA Security Rule, the practice using it has a signed Business Associate Agreement (BAA) with the vendor, and the way the practice configures and uses it doesn’t introduce new gaps.

All three pieces have to be true. A portal can be technically capable of HIPAA compliance, but if your BAA isn’t signed or your staff is emailing PHI in notification messages, you have a violation regardless of how good the software is.

The Patient Portal Compliance Checklist

A patient portal that’s safe to deploy for protected health information has to handle all of the following. Use this as a vendor-evaluation checklist.

Encryption

  • In transit: TLS 1.2 or higher on every connection — including mobile and API.
  • At rest: AES-256 encryption for the database, file storage, and backups containing PHI.
  • End-to-end: For secure messaging features, ideally end-to-end encryption between patient and provider.

Authentication and identity verification

  • Unique user IDs — every patient, every staff member, no shared accounts.
  • Multi-factor authentication — required for staff, available for patients (and increasingly expected by them too).
  • Identity verification before enrollment — you have to verify the person logging in is actually the patient. The most common methods: in-person credential issuance during a visit, knowledge-based verification, or video verification.

Access controls

  • Role-based access — front desk staff shouldn’t see clinical notes they don’t need; clinicians shouldn’t see billing details they don’t use. The HIPAA “minimum necessary” standard expects this. Our role-based access feature page covers what this looks like in practice.
  • Automatic session timeout — 15 minutes of inactivity is the standard for clinical portals.
  • Emergency access procedure — a documented break-glass process for accessing PHI during emergencies.

Audit logging

Every access to PHI has to be logged: who, what, when, from where, and whether the action succeeded. Logs must be immutable, retained (6 years is standard), and reviewable. If your portal can’t tell you who looked at a specific patient’s record over the last 90 days, your audit controls are insufficient.

Proxy access

Parents need to see their children’s records. Caregivers may need to see their parents’ records. Adolescent privacy rules vary by state. A HIPAA-compliant patient portal supports proxy relationships with proper documentation, age-based access restrictions, and audit logs that distinguish proxy access from direct access.

Business Associate Agreement (BAA)

This is the line most non-compliant “patient portals” fail at. The vendor must sign a BAA with you covering how they’ll protect PHI, what happens in a breach, and that their own subcontractors are bound by HIPAA. A platform that won’t sign a BAA — or only signs one at a much higher pricing tier — is not a HIPAA-compliant patient portal for your purposes. Period.

Breach notification capability

The vendor must be able to detect a breach quickly and notify you within their contractual timeline (typically 30–60 days at most). Your practice is then responsible for notifying patients within 60 days and HHS within 60 days (or immediately for breaches affecting 500+ individuals).

HIPAA-Compliant Patient Portal Software

These are platforms commonly used as HIPAA-compliant patient portals. Always verify current BAA terms and certifications directly with the vendor — these things change.

EHR-integrated patient portals

If you’re already using a major EHR, the integrated patient portal is usually the path of least resistance. The drawback is that EHR-bundled portals often have dated UX and limited customization.

Specialty and small-practice patient portals

  • SimplePractice — Practice management with built-in HIPAA-compliant patient portal. Especially popular in mental health, therapy, and other small clinical practices.
  • TheraNest — Behavioral health practice management with patient portal.
  • Klara — Patient communication platform (messaging, forms, scheduling) that layers on top of an existing EHR. Signs BAAs.
  • Phreesia — Patient intake and engagement platform that integrates with most EHRs and is HIPAA-compliant.
  • Spruce Health — HIPAA-compliant messaging and communication platform for healthcare practices.
  • Mend — Patient engagement and telehealth platform with HIPAA-compliant patient portal capabilities.

When practices build their own

Larger health systems and digital health companies sometimes build custom patient portals on top of their EHR via FHIR APIs. This gives full control of UX but shifts the entire HIPAA compliance burden onto the building team. Our build vs. buy guide walks through when this makes sense.

Vendor Questions Before You Sign

Before signing with any “HIPAA-compliant patient portal” vendor, get written answers to these:

  1. Will you sign a BAA at the tier we’re buying? (Some vendors only sign BAAs at higher-priced tiers — this is a deal-breaker if you’re on a lower tier.)
  2. Where is patient data stored? (Region, cloud provider, data center certifications.)
  3. What encryption is used in transit and at rest?
  4. Can we see your SOC 2 Type II report? (Most reputable vendors will share this under NDA.)
  5. What’s your breach notification timeline?
  6. Do you support automatic session timeout, configurable per organization?
  7. Can audit logs be exported on demand?
  8. What happens to our data if we cancel? (You should be able to export or have it permanently destroyed.)
  9. Have you had any breaches in the last three years? What changed afterward?
  10. Do you carry cyber liability insurance?

If a vendor stumbles on more than two of these, that’s your answer.

”HIPAA Compliant Portal” vs. “HIPAA Compliant Patient Portal”

People search for both. The distinction matters more than it sounds.

  • A HIPAA-compliant portal (or HIPAA-compliant client portal) is the general category — any portal handling PHI for any use case, including provider-to-payer portals, B2B portals between covered entities, document exchange portals, and so on. Our HIPAA compliance guide covers this broader scope.
  • A HIPAA-compliant patient portal is the specific subcategory aimed at patient self-service: viewing records, scheduling appointments, refilling prescriptions, paying bills, and messaging providers. The technical requirements overlap heavily; the patient-portal version adds proxy access, identity verification before enrollment, 21st Century Cures Act information-access requirements, and patient-friendly UX expectations.

If your use case is patients accessing their own records, you need the second. If you’re a healthcare business sharing PHI in some other workflow, you may only need the first.

Common Mistakes That Make a Portal Non-Compliant

The portal itself can be perfect and your practice can still create a violation. The most common ways this happens:

Sending PHI in notification emails

A notification that says “Your cholesterol result came back at 210 mg/dL — please call us” is a HIPAA violation, because that email isn’t HIPAA-compliant infrastructure. The correct pattern: a generic notification (“You have a new test result available”) with a link that requires portal login to view the actual data.

Sharing patient logins between family members

Some practices issue a single login per household. This violates the unique-user-identification requirement and breaks audit logging. Every patient needs their own account; proxy access handles family relationships explicitly.

Allowing staff to bypass MFA

If MFA is “optional for staff,” staff will skip it, and one phished password creates a breach. MFA must be required for any user with administrative access.

Using a free or consumer-tier service for “just this one thing”

A practice that uses Google Forms for patient intake or Dropbox for sharing records with a specialist — without the HIPAA-eligible tier and a signed BAA — has a violation regardless of the patient portal’s compliance.

Skipping the risk analysis

HIPAA requires a documented risk analysis. If you can’t produce one when OCR comes asking, you have a violation independent of any actual breach. Do the risk analysis. Update it annually. Update it again after material changes.

Does the Patient Portal Comply With HIPAA Regulations? — How to Verify

If you’re already using a portal and need to confirm it’s actually compliant, run through this verification list:

  1. Locate your signed BAA with the vendor. If you can’t find one, ask the vendor for a copy. If they can’t produce one, you have a problem.
  2. Request the vendor’s most recent SOC 2 Type II report and HIPAA compliance attestation.
  3. Run a test access log query — pick a patient, ask the portal to show every access to that patient’s record in the last 90 days. If it can’t, your audit controls are insufficient.
  4. Test session timeout — log in, walk away, come back in 20 minutes. You should be logged out.
  5. Review staff access — list every staff account and verify role assignments match the minimum-necessary standard.
  6. Check notification content — read the last 50 portal-generated emails to patients. None of them should contain PHI in the email body.

If any of these fail, prioritize fixing them before anything else.

Frequently Asked Questions

Are patient portals HIPAA compliant?

Reputable patient portal software is capable of HIPAA compliance — but compliance is a property of the deployment, not just the software. A patient portal is HIPAA-compliant when (1) the software implements the required safeguards, (2) the practice has a signed BAA with the vendor, and (3) the practice configures and uses it without introducing gaps. See the full compliance checklist in this article.

Does HIPAA apply to dentistry?

Yes. Dental practices are Covered Entities under HIPAA if they transmit health information electronically (which essentially all modern dental practices do — for insurance claims, EHR communications, etc.). Dental practices need HIPAA-compliant patient portals just as medical practices do, with the same BAA, encryption, audit logging, and access control requirements.