TL;DR: Over 60% of patients now expect digital access to their records before they ever walk into a clinic, yet fewer than a third actually use the portals health systems have already built, and 49% of those who do log in less than once a month. The gap isn't a technology problem in the way most teams assume — it's usually a usability failure layered on top of interoperability and compliance requirements that are treated as separate checklists instead of one integrated design constraint.
Why most patient portals underperform
The patient portal market is growing fast — from $6.41 billion in 2025 toward a projected $16.17 billion by 2030 — which tells you demand for digital patient access is real. What it doesn't tell you is that most of the portals already deployed aren't delivering on that demand. Usage numbers consistently lag expectations: adoption sits well below half of eligible patients at most health systems, and the patients who do sign up frequently stop returning after the first login.
This pattern shows up so consistently across health systems that it's worth treating as a design signal rather than a patient-engagement problem to solve with more email reminders. A portal patients don't return to is usually a portal that failed one of three tests: it didn't show them anything useful on the first visit, it required too much friction to get basic answers (appointment status, a lab result, a bill), or it felt disconnected from the actual care relationship — a separate login and separate mental model from the rest of how the patient interacts with the practice.
Building a portal that clears those three tests, while also meeting FHIR interoperability requirements and HIPAA's increasingly specific security mandates, is a genuinely harder design problem than most initial project scoping accounts for. The rest of this piece works through where the friction points actually are.
The interoperability requirement isn't optional anymore
Any patient portal built or procured in 2026 needs to support FHIR — specifically HL7's Fast Healthcare Interoperability Resources Release 4.0.1 (FHIR R4), which has become the foundational standard for API-based health data exchange under the 21st Century Cures Act. The Cures Act requires certified health IT to expose a patient's full electronic health record through an API "without special effort," and includes real information-blocking penalties for health systems that make this artificially difficult.
Adoption data suggests most hospitals have moved on this already: roughly 81% of hospitals now let patients access their health information through third-party apps, and about 70% have that access specifically configured to meet FHIR API specifications. For a mid-market health system or specialty practice still running a portal that predates this shift, the question in 2026 isn't whether to adopt FHIR — it's how quickly you can close the gap before patients (and referring providers) simply route around a system that can't exchange data the way its peers can.
Practically, this means the portal's data layer needs to speak FHIR natively — patient records, appointments, lab results, and clinical notes structured as FHIR resources, exposed through a SMART-on-FHIR-compliant API — rather than FHIR being bolted on as a translation layer over a legacy proprietary data model. The translation-layer approach works in the short term but tends to become the most expensive part of the system to maintain, since every FHIR spec update requires re-mapping rather than being natively supported.
One frequently underestimated implication: the Cures Act's patient-access requirement means patients are entitled to connect their health data to apps of their own choosing, not just your portal. This changes the design goal from "build the app patients will use" to "build the API patients' chosen apps will connect to, and make your own portal good enough that most patients prefer it anyway." A portal architecture that treats the API as a first-class product, not just plumbing behind your own UI, is better positioned for this reality.
HIPAA compliance has gotten more specific, not just stricter
HIPAA and HITECH requirements for patient-facing systems have always included the fundamentals — encryption at rest (AES-256) and in transit (TLS 1.3), role-based access control, immutable audit logging, breach response plans, and signed Business Associate Agreements with every vendor touching patient data. What's changed for 2026 is specificity: updated guidance now calls for annual penetration testing and biannual vulnerability scans as an ongoing program, not a one-time pre-launch check that gets filed away.
This has real architectural implications beyond the security checklist itself. A portal built with an ongoing testing cadence in mind needs:
- A staging environment that mirrors production closely enough for penetration testing to be meaningful, including realistic (but synthetic, never real patient) data volumes and access patterns.
- Role-based access control granular enough to support least-privilege by default — a front-desk staff role shouldn't have the same data visibility as a clinician role, and the portal's admin interface needs to make this distinction easy to configure correctly rather than defaulting to broad access for convenience.
- Audit logging that's genuinely immutable and queryable, not just present — a log nobody can practically search during an incident investigation doesn't satisfy the spirit of the requirement even if it technically exists.
- A documented, tested breach response plan that includes the portal specifically, not just the broader EHR system it connects to — patient portals are a distinct attack surface (public-facing, patient-managed credentials) that deserves its own incident response runbook.
Every third-party service the portal touches — appointment scheduling, secure messaging, a patient-facing chatbot, a payment processor — needs its own signed BAA, and this list grows faster than most project teams expect once a portal starts integrating with best-of-breed point solutions rather than a single vendor's suite.
Designing for the usability problem specifically
Compliance and interoperability get most of the engineering attention in portal projects, which is part of why usability ends up under-invested despite being the actual driver of the adoption numbers cited above. A few design principles consistently separate portals patients return to from portals they abandon after one login:
Front-load the one or two things patients actually come back for. Data across health systems consistently shows the same top use cases driving return visits: checking an appointment, viewing a recent lab result, and messaging a provider. A portal that requires three clicks past a generic dashboard to reach any of these is optimizing for the wrong thing. Surface the most recent relevant item — the next appointment, the most recent result — directly on login.
Treat WCAG 2.1 AA accessibility as a usability requirement, not just a compliance checkbox. Every hospital patient portal now needs to meet this standard, and multi-language support is increasingly expected alongside it — but the deeper point is that accessible design (clear hierarchy, sufficient contrast, keyboard navigability) tends to be better design for every user, not just the subset it's formally required for.
Minimize authentication friction without weakening security. A portal that requires patients to remember a separate, portal-specific password they use once every few months is fighting an uphill battle against normal human forgetting. Passwordless authentication options (magic links, biometric where the device supports it) reduce this friction meaningfully without compromising HIPAA's access-control requirements, since the underlying authentication strength can be maintained or improved relative to password-based login.
Design the mobile experience first, not as a responsive afterthought. Patient portal usage skews heavily mobile, and a desktop-first design that gets awkwardly compressed onto a phone screen is a common, avoidable source of the friction that keeps adoption low.
A realistic build plan
| Phase | Focus | Typical duration |
|---|---|---|
| Discovery | Map top patient use cases, audit existing EHR/data sources, define FHIR resource scope | 2-4 weeks |
| Architecture | FHIR-native data layer, RBAC design, BAA inventory for all integrated vendors | 3-5 weeks |
| Core build | Authentication, dashboard, appointments, results, secure messaging | 8-14 weeks |
| Security hardening | Penetration testing, vulnerability scanning, audit logging validation | 3-4 weeks |
| Launch and adoption | Phased rollout, patient onboarding flow, usage monitoring against the top-use-case metrics | Ongoing |
Total development costs for a full-featured patient portal typically run $50,000 to $400,000+ depending on scope — the wide range mostly reflects how much of the FHIR/EHR integration work is genuinely custom versus building on an existing platform's certified interoperability layer. A portal built on top of a modern, FHIR-native EHR generally costs meaningfully less to integrate than one bridging a legacy system with a custom translation layer, which is worth factoring into the underlying EHR conversation if your portal project is happening alongside a broader systems modernization effort.
Secure messaging: the feature that determines return visits
Of every feature a patient portal can offer, secure messaging between patients and care teams is consistently the one most correlated with repeat usage — more than lab results, more than appointment scheduling. This makes intuitive sense: a patient who gets a timely, useful reply to a portal message forms a habit of checking the portal; a patient who sends a message and hears nothing back for a week learns to call the office instead, and that learned behavior is hard to reverse.
This puts an operational burden on the health system that's easy to underweight during a technology-focused portal project: secure messaging only drives adoption if someone on the care team actually answers messages promptly, and if the routing logic gets messages to the right person without requiring a triage nurse to manually sort every inbound message. A well-built portal supports this with structured message types (medication question, appointment request, billing question, clinical question) that route automatically to the right queue, rather than a single generic inbox that becomes a bottleneck. Building this routing logic well is a genuine design problem — not a checkbox feature — and is worth as much design attention as the FHIR data layer, since it's arguably a bigger determinant of whether the portal gets used at all.
Message response-time expectations also intersect with HIPAA in a way that's easy to miss: secure messaging logs are part of the record and subject to the same audit and retention requirements as clinical documentation, which means the messaging feature needs the same immutable audit logging and access control rigor as the rest of the portal, not a lighter-weight implementation because it "feels" like a simple chat feature.
Vendor platform vs. custom build
Health systems evaluating a new or replacement patient portal generally choose between an EHR vendor's bundled portal module (Epic MyChart, Cerner HealtheLife, and similar) and a custom-built or best-of-breed portal integrated via FHIR APIs. Neither is categorically right — the decision depends heavily on what's actually constraining adoption at a given organization.
A vendor-bundled portal has real advantages: it's already FHIR-compliant by design (since it shares the EHR's data model directly), BAA coverage is simplified because you're dealing with one primary vendor relationship, and ongoing security testing is largely the vendor's responsibility rather than yours. The tradeoff is customization — bundled portals tend to look and behave similarly across every health system using them, which limits how much you can tailor the first-login experience to your specific patient population's top use cases, and feature requests go into a vendor roadmap you don't control.
A custom or best-of-breed portal, built on top of the EHR's FHIR API rather than as a vendor module, trades that constraint for more design freedom at the cost of owning more of the compliance and interoperability burden directly. This tends to be the right call when usability and adoption are the primary problem being solved — a health system that's already tried the bundled portal and seen the adoption numbers described earlier often finds that a purpose-built experience, informed by actual usage data from the first attempt, moves the needle in a way that switching to a different vendor's bundled module usually doesn't.
A middle path worth considering explicitly: building a custom-designed frontend that consumes the EHR vendor's FHIR API directly, rather than either accepting the vendor's bundled UI or building an entirely separate data layer. This captures most of the usability benefit of a custom build while avoiding the cost and ongoing maintenance of a parallel FHIR implementation — though it does mean staying within the boundaries of what the vendor's API actually exposes, which isn't always the full data set a fully custom integration could reach.
Conclusion
A patient portal that succeeds in 2026 treats usability, FHIR interoperability, and HIPAA compliance as one integrated design problem rather than three separate workstreams handed to different teams. The health systems seeing real adoption aren't the ones with the most features — they're the ones that got the first-login experience right, built the FHIR data layer natively instead of bolting it on, and treated security testing as an ongoing program rather than a launch gate.
Syslabs builds patient portals and the FHIR-native integration layers underneath them for healthcare organizations navigating exactly this set of constraints. If your team is scoping a portal project and wants the interoperability and compliance requirements mapped out before the usability design starts — rather than discovered mid-build — that's a conversation worth having at the discovery stage.
Sources
- Keragon, "16 Best Patient Portal Software Solutions for 2026"
- American Institute of Healthcare Compliance, "Privacy Interoperability and Trust in 2026"
- The Health IT Review, "The State of FHIR Adoption in 2026"
- HarmonyHIT, "21st Century Cures Act HL7 FHIR REST API for Legacy Health Data"
- Saigon Technology, "Patient Portal Development: Features, Cost & Step-by-Step Process (2026)"