How to Build a HIPAA-Compliant Patient Portal in the USA: The 2026 Technical Guide

Patient portals are no longer optional for healthcare organizations in the USA. The 21st Century Cures Act, fully enforced since September 2025, mandates that patients can electronically access all of their electronic health information, clinical notes, lab results, medications, imaging reports, care plans, at no cost, without delay, in the format of their choice.

Withholding or delaying access is information blocking, and ONC has enforcement authority with financial penalties.

Before the Cures Act, many patient portals were marketing features, appointment scheduling bolted onto a healthcare website. In 2026, a patient portal is a regulated data access infrastructure. Building one correctly means understanding both the HIPAA compliance layer and the Cures Act interoperability requirements simultaneously.

This guide covers what a compliant patient portal actually requires in 2026, what it costs to build, and where most implementations go wrong.

What Is a HIPAA-Compliant Patient Portal?

A HIPAA-compliant patient portal is a secure, authenticated web and mobile application that gives patients electronic access to their protected health information including clinical notes, lab results, medications, immunizations, appointment records, and billing, while maintaining HIPAA security safeguards (encryption, audit logging, RBAC, MFA) and meeting 21st Century Cures Act information blocking requirements.

Under current enforcement, healthcare organizations cannot restrict access to finalized EHI, charge fees for EHI access, or delay sharing finalized results, even if a provider hasn’t yet reviewed them with the patient.

The Regulatory Framework in 2026

Building a patient portal requires understanding two overlapping regulatory requirements:

• HIPAA (the security and privacy floor): Encryption at rest and in transit, access controls, audit logging, BAAs with vendors, breach notification. These are the baseline requirements for any system handling PHI.
• 21st Century Cures Act / ONC Information Blocking Rules (the access mandate): Healthcare organizations must provide patients with timely, electronic access to their EHI using standardized APIs (FHIR R4). They cannot charge for this access. They cannot block or delay sharing of finalized information except under eight specific defined exceptions (patient safety, preventing harm, privacy protection, etc.).
• The specific requirement that catches organizations off guard: Under the Cures Act, lab results and clinical notes must be released to the patient portal as soon as they are finalized, not after the provider has reviewed them with the patient. This is a deliberate policy choice. The 21st Century Cures Act is explicit: proactive push of finalized EHI is the required approach. Delaying portal posting of labs until after a physician phone call is information blocking.
• HTI-5 (December 2025 proposed rule): HHS released the HTI-5 proposed rule in December 2025, the most significant health IT policy update in years. It proposes removing 50%+ of existing EHR certification criteria to refocus on FHIR-based API access, tightens information blocking enforcement, and explicitly supports AI-powered applications accessing patient data through patient-directed authorization.

The Eight Required Feature Modules

Module 1: Authentication and Identity Management

Patient portals require multi-factor authentication, this is explicit in HIPAA’s technical safeguards and ONC certification requirements. Standard username/password alone is insufficient for PHI-accessing systems.

Implementation: AWS Cognito (HIPAA-eligible with BAA) or Auth0 Healthcare tier (BAA available) with:

• SMS or TOTP (authenticator app) MFA note: SMS MFA is acceptable for patient-facing portals, unlike staff systems where app-based is recommended
• Identity proofing for new patient enrollment (matching patient identity to existing records, NIST IAL2 for higher-assurance portals)
• Session timeout of 15 minutes of inactivity with automatic logoff
• Password policies meeting NIST 800-63B guidelines
• Account recovery without exposing PHI in recovery communications

Module 2: Health Record Access (21st Century Cures Act Core Requirement)

The portal must display all EHI the patient has a right to access under HIPAA, in a usable format, without delay after finalization:

• Clinical notes (physician notes, nursing notes, discharge summaries)
• Lab results with reference ranges
• Medications and prescription history
• Allergies and adverse reactions
• Immunizations
• Vital signs and biometrics
• Diagnoses (problem list, ICD-10 codes)
• Care plans
• Appointment history
• Imaging reports (radiology, pathology)
• Billing records

The FHIR integration requirement: This data comes from the underlying EHR via FHIR R4 APIs. A patient portal that only shows data manually entered into the portal is not compliant with Cures Act requirements, the portal must pull finalized EHI from the EHR system in near real time. This means Epic SMART on FHIR, Cerner FHIR APIs, or Athenahealth FHIR APIs depending on your EHR, plus a FHIR normalization layer if you’re connecting to multiple EHRs. (Full Epic FHIR guide: Blog 4)

Module 3: Secure Messaging

HIPAA-compliant provider-patient messaging. Standard email is not HIPAA compliant, content must be encrypted in transit and at rest, and vendors must sign BAAs.

Implementation options:

• Build using a healthcare messaging API with BAA (Twilio with BAA, AWS SES/SQS configured for HIPAA-eligible services)
• Integrate a purpose-built secure messaging SDK
• Integrate with Epic MyChart messaging via FHIR DocumentReference if the patient is already on Epic

PHI in push notifications: Never. “You have a new message” is acceptable. “Your blood glucose is 340 mg/dL” in a push notification is a HIPAA violation, the notification passes through Apple/Google infrastructure without a BAA. Push notifications trigger the patient to open the authenticated app to see their data.

Module 4: Appointment Scheduling

Online appointment booking: view available slots, schedule new appointments, reschedule, cancel. Automated reminders via SMS/email (Twilio with BAA, reminder content must not include PHI, appointment time and practice name are acceptable; diagnosis or procedure is not).

Integration requirement: Appointment scheduling must write back to the EHR’s scheduling system, not maintain a separate calendar. Epic FHIR Slot and Appointment resources for Epic-connected organizations; Athenahealth scheduling APIs for ambulatory practices.

Module 5: Bill Payment and Financial Transparency

HIPAA-compliant online payment: view outstanding balances, itemized statements, copay collection, payment plan setup.

Compliance note: Stripe Healthcare (BAA available) is the standard for HIPAA-compliant payment processing. Standard Stripe without the healthcare configuration and signed BAA is not compliant for PHI-adjacent payment flows. Financial records containing procedure codes and diagnosis codes are PHI, the payment interface touching these records requires full HIPAA compliance treatment.

Module 6: Prescription Refill Requests

Patient-initiated refill requests routed to the provider. For medication refills: display current medication list, allow patient to request refill, route to provider inbox for approval, transmit to pharmacy via Surescripts e-prescribing.

Module 7: Patient-Directed Data Sharing (SMART on FHIR / USCDI)

The Cures Act explicitly requires that patients can authorize third-party applications to access their EHI. Your portal must support SMART on FHIR authorization flows that allow patients to connect their health data to apps of their choice, fitness trackers, care management apps, second-opinion services, research platforms.

Implementation: Implement an OAuth 2.0 authorization server with SMART on FHIR scopes. When a patient authorizes a third-party app, the app receives an access token scoped to that patient’s FHIR resources. This is not optional compliance, it is a core Cures Act interoperability requirement.

Module 8: Audit Logging and Compliance Infrastructure

Every patient action, every record view, every message sent, every appointment scheduled, every download of EHI, must be logged with user ID, timestamp, action type, and resource accessed. Logs retained for 6 years, stored in a tamper-proof system (AWS CloudTrail), and protected from modification.

Patient access logs are particularly important under the Cures Act: if a compliance question arises about information sharing, the audit trail demonstrates exactly what data was accessed and when.

What a Patient Portal Costs to Build

The range is driven primarily by EHR integration complexity. A patient portal that connects to a single Athenahealth practice is a $60,000 project. A portal connecting to Epic across 20 hospital sites with bidirectional scheduling write-back and SMART on FHIR authorization is a multi-year enterprise program.

The Top Mistakes That Create Information Blocking Liability

• Delaying lab results “pending physician review.” Under the Cures Act, finalized lab results must appear in the portal immediately upon finalization. Holding them until after a provider phone call is information blocking.
• Charging fees for portal access. Zero cost to the patient for EHI access is an explicit Cures Act requirement. Subscription fees for “premium portal features” are a legal gray area; fees for basic EHI access are not.
• Building a portal that only shows manually entered data. Portal data must come from the EHR in near real time via FHIR APIs. A portal showing a manually updated problem list rather than the live EHR problem list does not meet Cures Act requirements.
• Blocking access to clinical notes. The OpenNotes provisions of the Cures Act require that all finalized clinical notes, physician notes, nursing notes, therapy notes be available to patients. The exception is mental health notes in states with specific carve-outs, but even these are narrowing.
• No SMART on FHIR patient authorization capability. A portal that doesn’t allow patients to authorize third-party apps to access their data is not Cures Act compliant.

Author: Mayank Pratap | Co-Founder, EngineerBabu | Google AI Accelerator 2024 · CMMI Level 5

FAQ

• Is a patient portal required by law in the USA?

Not technically mandated for all organizations, but the 21st Century Cures Act requires healthcare organizations to provide patients with electronic access to their EHI via standardized APIs. The most practical and operationally efficient way to meet this requirement is a patient portal. Organizations providing EHI only on written request are technically compliant but operationally burdened and at higher risk of information blocking complaints.

• Can I charge patients to access their records through a portal?

No. The Cures Act prohibits charging fees for patient access to their own EHI. Portal access must be free to patients.

• Do I have to show lab results immediately in the portal?

Yes. Under the Cures Act, finalized EHI including lab results and clinical notes must be released to the patient portal upon finalization, without delay. Holding results pending physician review is information blocking under current enforcement guidelines.

• What is SMART on FHIR and why does a patient portal need it?

SMART on FHIR is the authorization framework that allows patients to connect third-party applications to their health data. Cures Act compliance requires supporting patient-directed data sharing via standardized APIs. Your portal must implement an OAuth 2.0 authorization server with SMART on FHIR scopes.

• How much does patient portal development cost in the USA?

Basic portal (appointments, messaging, bill pay): $30,000–$60,000. Full Cures Act compliant portal with FHIR EHR integration: $60,000–$150,000. Multi-organization portal with SMART on FHIR: $150,000–$350,000. Enterprise Epic-connected portal: $300,000–$1M+.