Every health system, clinic network, and digital health startup eventually faces the same question: should we build a patient portal, extend the one we have, or replace it entirely? Patient portal development is no longer about checking a Meaningful Use box. Patients expect to view records, message their care team, schedule visits, pay bills, and manage family members' health from a single login, preferably on a phone. The challenge is delivering all of that without burying clinical staff in unstructured messages and support tickets. This guide covers what a modern portal must include, where integration decisions shape the entire build, how to sequence an MVP, and which metrics tell you whether the portal is actually working.
What a patient portal should include before you call it "done"
A portal that only shows lab results is a PDF viewer with a login page. A portal patients will use repeatedly needs to cover the full loop of access, communication, action, and payment.
Identity, accounts, and proxy access
Account creation should support identity proofing that satisfies your compliance requirements without forcing patients to call a help desk. That means email or phone verification, knowledge-based authentication or ID document upload, and MFA from day one. Proxy and caregiver access deserves its own design track. According to ONC data, proxy portal access more than doubled from 24% in 2020 to 51% in 2024. Parents managing pediatric records, adult children coordinating elder care, and legal guardians all need granular consent controls that map to your state's privacy rules.
Medical record access
Patients should be able to view lab results, clinical notes, medication lists, allergies, immunizations, visit summaries, and downloadable documents. Nearly all U.S. hospitals now enable patients to view health information electronically (99%) and download it (96%). Clinical notes access is at 95%. If your portal does not surface notes, you are behind the baseline.
Secure messaging
Messaging is the feature patients use most and the one that creates the most operational risk. Build it with routing rules, topic categorization, and service-level expectations visible to the patient. A message about a medication refill should not land in the same queue as a billing question.
Scheduling, intake, and reminders
Online scheduling with cancellation, waitlist, pre-visit digital intake forms, and automated reminders reduces no-shows and front-desk call volume. This is where write-back to your practice management system matters most.
Billing and payments
Patients expect to see balances, view statements, set up payment plans, and pay online. Insurance eligibility checks and cost estimates before a visit are increasingly expected, though they require deeper integration with your RCM stack.
Prescription and refill requests
Where clinically and legally appropriate, refill requests through the portal reduce phone volume and give pharmacists a structured data trail.
Accessibility and mobile-first design
App-based access to online medical records increased from 38% in 2020 to 57% in 2024. A responsive web portal is the minimum. A native mobile app is increasingly the primary access point. Both need WCAG 2.1 AA compliance, language support, and thoughtful UI/UX design that accounts for older adults, low-literacy users, and screen reader compatibility.
EHR integration is the real scope of patient portal software development
The portal itself is an experience layer. The hard work is connecting it to the systems that hold the data and execute the workflows: EHR/EMR, practice management, revenue cycle, lab information systems, pharmacy, identity providers, and analytics platforms.
FHIR, SMART, and IPA
FHIR R4 is the standard for patient-facing data access. The HL7 International Patient Access (IPA) specification describes how an application acting on behalf of a patient can read conditions, medications, immunizations, allergies, vitals, lab results, clinical notes, and documents from a clinical system using a FHIR R4 API. The current IPA version is read-only, though implementations may provide write access. SMART App Launch handles the OAuth2-based authorization flow.
For a deeper comparison of integration approaches, see our guide on EHR integration: HL7 vs FHIR vs vendor APIs.
HL7 v2 still matters
Many hospital systems still send ADT, order, and result messages over HL7 v2 interfaces. Your integration engine (Mirth, Rhapsody, or a cloud-native equivalent) will likely need to handle both FHIR and v2 feeds for years.
CMS Patient Access API
If your organization is a CMS-impacted payer, or you are building a portal that aggregates payer data, the CMS Patient Access API requires making claims, encounter, and clinical data available through a FHIR-based API. This regulation is shaping patient expectations even for provider-side portals: patients increasingly expect all their data in one place. Yet only 7% of individuals used a portal organizing app to combine records, which signals both a gap and an opportunity.
Read-only vs. write-back decisions
Lab results, clinical notes, and medication lists are safer as read-only FHIR pulls. Scheduling, intake forms, patient-generated health data, and message threads require write-back governance: validation rules, conflict resolution, and clear ownership of what happens when a patient submits data that contradicts the record.
Security architecture
HIPAA compliance is the floor, not the ceiling. Your portal needs end-to-end encryption in transit and at rest, role-based access control, session timeout policies, audit trails for every data access event, and breach notification workflows. MFA should be required, not optional.
We saw a related pattern with RAE Health, a healthcare platform that combines a patient-facing mobile app, caregiver and provider visibility tools, and a web clinical portal with analytics. The project took over 24 months and exceeded $200,000 in development cost, in large part because different systems needed to integrate and no data gaps had been identified early. The lesson is that the portal architecture has to serve patient experience and clinical action at the same time. If clinicians cannot see what patients submit, or if patient-generated data creates noise without workflow routing, adoption stalls on both sides.
A practical build plan: from MVP to rollout
Patient portal app development benefits from a phased approach that limits support burden while proving value early. Here is a sequence that works for most provider organizations and healthtech teams building custom software.
Phase 1: Discovery and workflow mapping (4-6 weeks)
- Interview clinical staff, front desk, billing, IT, and a sample of patients.
- Map current patient touchpoints: calls, faxes, in-person check-in, third-party apps.
- Identify which EHR/PMS/RCM systems hold the data the portal needs.
- Document consent, proxy, and identity verification requirements by state and payer.
Phase 2: Data inventory and integration design (3-5 weeks)
- Catalog available APIs, FHIR endpoints, HL7 v2 feeds, and vendor SDK options.
- Decide which data is read-only and which requires write-back.
- Select or configure an integration engine.
- Define audit logging and data retention policies.
Phase 3: MVP build (10-16 weeks)
- Scope: patient login with MFA, profile management, appointment viewing and scheduling, medical record access (labs, notes, medications, allergies), secure messaging with topic routing, push/email notifications, and a basic admin dashboard for staff.
- Skip advanced features like payment plans, complex proxy trees, and patient-generated data import for the MVP.
Phase 4: UX testing with real users (3-4 weeks)
- Test with patients across age groups, literacy levels, languages, device types, and accessibility needs.
- Test with clinical staff to validate message routing, notification volume, and admin workflows.
- Iterate on onboarding flow, navigation, and error states.
Phase 5: Security and compliance review (2-3 weeks)
- Penetration testing, vulnerability scanning, HIPAA risk assessment.
- Verify audit trail completeness and breach notification readiness.
- Review BAAs with all third-party services.
Phase 6: Pilot with one department or location (4-8 weeks)
- Choose a department with high patient volume and a willing clinical champion.
- Train front desk and clinical staff on how to introduce the portal during visits.
- Monitor support tickets, failed logins, message volume, and staff feedback daily.
Phase 7: Rollout with training and monitoring
- Expand to additional departments and locations based on pilot learnings.
- Provide provider scripts for encouraging portal use during visits.
- Build support playbooks for common patient issues.
- Set up dashboards for adoption and operational metrics.
Provider encouragement is not a soft recommendation. ONC data shows that 87% of individuals who were encouraged by their provider accessed their portal, compared to 57% of those who were not encouraged. Encouraged users also viewed test results and clinical notes at significantly higher rates (92% vs. 78% for test results, 82% vs. 57% for clinical notes). Staff training and scripting belong in the rollout plan, not as an afterthought.
Adoption metrics providers should track after launch
A portal is not successful because it exists. It is successful when patients use it for self-service, staff workload shifts from phone calls to structured digital interactions, and care gaps close faster. Track these categories:
Registration and activation
- Eligible patients invited vs. accounts created.
- Activation rate (first login after registration).
- Repeat login rate at 7, 30, and 90 days.
- Drop-off points in the onboarding flow.
Feature usage
- Records viewed: labs, notes, medications, immunizations.
- Appointments scheduled, rescheduled, or canceled online.
- Bills viewed and payments completed.
- Refill requests submitted.
- Secure messages sent, by topic category.
Messaging operations
- Message volume by routed owner (nurse, provider, billing, front desk).
- Average response time and backlog depth.
- Unresolved thread count.
- After-hours message volume and clinician burden.
Proxy and mobile access
- Proxy account creation and usage rate.
- Mobile app vs. web access split.
- App store ratings and crash rates if you ship a native app.
Operational impact
- Phone call volume trends (measure carefully; not all call deflection is safe).
- No-show and late cancellation rate changes.
- Support tickets related to the portal.
- Failed login and password reset frequency.
Equity and segmentation
- Segment all metrics by age, language, location, payer, clinic, and accessibility needs.
- Identify populations with low activation and design targeted outreach.
Clinician workload
- Track whether messaging volume is replacing phone calls or adding net new work.
- Monitor unresolved threads and after-hours burden as leading indicators of staff burnout.
A successful portal is not "more messages." It is better self-service, clear routing, and measurable reductions in manual work for both patients and staff.
Build, buy, or customize?
The right approach depends on your EHR ecosystem, your differentiation needs, and your operational readiness.
Buy when the EHR-native portal is enough
Use this path when your EHR vendor's portal covers the workflows your patients need, branding and UX customization are acceptable, and your IT team's capacity is limited. Most major EHR vendors offer portals that meet baseline regulatory requirements.
Customize when the default portal is close
Choose this path when the EHR portal is close but needs workflow extensions, specialty-specific modules, better UX, or dashboard capabilities that the vendor does not offer. This often involves SMART on FHIR apps or middleware layers.
Build when the portal is part of the product
Choose this path when the portal is your product (as in a digital health startup), when multi-system data aggregation is central to the value proposition, when you serve specialty workflows that no off-the-shelf portal handles, or when white-label control matters for your brand. A ground-up build requires a team experienced in healthcare software development and a realistic timeline of 6 to 18 months depending on scope.
Do not build until access and ownership are clear
Pause the project if your organization has not resolved EHR API access, data governance, or operational ownership of the portal. A custom portal on top of a locked-down EHR with no FHIR endpoints is an expensive dead end.
Regardless of the path, 81% of hospitals now enable app access through APIs in the EHR, and 70% enable FHIR-based app access. The integration surface is wider than it was five years ago. The question is less "can we connect?" and more "what do we do with the connection?"
