Patient Portal Features: The 2026 Guide to What to Build and Why

Most patient portal feature lists read like shopping lists. They name a dozen capabilities, attach a benefit sentence to each, and leave the reader with no way to decide what to fund first. This guide takes a different position. A portal feature earns its place only if it lets a patient finish something without calling the front desk, and it keeps its place only if it survives a security audit, an accessibility review, and the workload it creates for clinicians.

Arkenea has built healthcare software exclusively for 15 years, so the judgments below come from scoping sessions, integration work, and support tickets rather than from a product brochure. We have shipped patient facing applications for physician groups, telehealth providers, home care agencies, and digital health founders. The pattern repeats: portals fail on identity, integration, and follow through far more often than they fail on feature count.

What counts as a patient portal feature in 2026

A patient portal is a secure web or mobile application that gives a patient authenticated access to their own health information and to the transactions that surround their care. A feature is any capability the patient can complete end to end inside that application: viewing a result, sending a message, booking a visit, paying a bill, or granting a caregiver access. Anything that requires the patient to pick up the phone to finish is not a feature, it is a form.

That distinction matters because portal capability is now close to universal while portal usefulness is not. According to ASTP/ONC Data Brief No. 79, published in August 2025, 99% of nonfederal acute care hospitals let patients view health information through a portal, 95% allow viewing clinical notes, and 92% support secure messaging. The differentiation has moved from whether a capability exists to whether a patient can complete the task without help.

The features that matter most, at a glance

Core patient portal features

These are the capabilities a portal cannot omit. Each one is described below in terms of what it must do, what typically breaks, and what the underlying dependency is.

Identity proofing, registration, and login

Registration is where most portals lose patients, and it is also where most feature lists start too late. The portal has to verify that the person creating an account is the person in the chart, which usually means matching demographics against the source system plus a one time code sent to a verified phone or email. Weak matching creates duplicate records and merged charts, which is a patient safety problem long before it is a data problem.

Multi factor authentication is now table stakes for any application holding protected health information, and it should be enforced at enrollment rather than offered as a setting. Account recovery deserves equal attention: a reset flow that ends in a phone call to the front desk cancels out the labor savings the portal was built for. Session handling, device trust, and step up authentication for sensitive actions such as changing a payment method belong in the same design conversation.

When Arkenea built the telehealth and patient engagement platform for Cumberland, the onboarding design carried more weight than any single clinical feature. Branded onboarding with OTP and single sign on options was paired with mandatory profile completion gates for demographics, insurance, and address, so incomplete records could not reach the provider queue. That decision cut the front desk rework that otherwise appears in the first week of every launch.

Health record access built on USCDI

Record access should present structured data, not a rendered document. The United States Core Data for Interoperability defines the data classes and elements that certified health IT must exchange, and it is the practical specification for what a portal ought to display. USCDI has advanced through version 6, published in July 2025, with a draft version 7 released in January 2026.

Certification requirements lag the standard, which is a nuance most feature articles miss. The HTI-1 final rule set USCDI v3 as the certification baseline, with certified systems required to support it by January 1, 2026. If you are scoping a portal against your EHR vendor’s API today, scope against what their certified modules actually expose, not against the newest published version of the standard.

Practically, that means a portal should render problems, medications, allergies, immunizations, vital signs, laboratory results, procedures, care team members, clinical notes, goals, health concerns, and encounter information as discrete, filterable data. Patients should be able to download their record and transmit it to a third party of their choosing. Both capabilities are widely supported at hospitals, with 96% offering download and 84% offering transmission per ASTP Data Brief No. 79.

Test results, released immediately

Immediate release of test results is the single largest behavioral change in portal design over the last five years, and it is still handled badly in most vendor documentation. Under the information blocking regulations, withholding a finalized result from a patient because a clinician has not yet reviewed it is not a neutral workflow choice. It is a practice that has to fit inside one of the defined exceptions or it is potentially information blocking.

The common objection is that patients will be frightened by results they do not understand. The evidence does not support treating that as the default. In a multisite survey of 8,139 patients published in JAMA Network Open in March 2023, 95.7% preferred to receive results immediately even before speaking with a clinician, and among patients who received abnormal results, 95.3% still preferred immediate release. Only 7.5% reported that immediate review increased their worry.

That does not mean anxiety is absent, and a well designed portal accounts for it. A Vanderbilt analysis of 968,774 results published in JAMA Network Open in April 2025 found patients repeatedly refreshed the portal while waiting for 25.9% of results, rising to 39.3% for high sensitivity tests. The design response is to set expectations at the point of order, attach plain language interpretation to the result, and give the patient a defined next step rather than an empty inbox.

Secure messaging

Secure messaging is the feature patients value most and the one that creates the most downstream cost. It needs threading, attachments, read receipts, defined response windows, and triage routing that sends refill requests, administrative questions, and clinical concerns to different queues. Without routing, every message lands in a physician inbox regardless of who should answer it.

The volume trend is unambiguous. An analysis of roughly 8 billion encounters across more than 2,000 hospitals and 47,000 clinics, published in JAMA in June 2026, found patient authored portal messages rose 153% between 2020 and 2025, from 0.99 to 2.50 messages per active patient per year. Office visits rose 17% over the same period while telephone encounters fell only 6% to 7%. Messaging added work rather than replacing it.

That finding should change how the feature is scoped. Message templates for common scenarios, structured intake questions before a free text box, auto responses outside business hours, and escalation paths are not conveniences, they are the difference between a sustainable channel and an unmanaged one. Plan the staffing model in the same sprint you plan the interface.

Appointment scheduling and self service changes

Real scheduling means writing to the practice management system against live availability, honoring visit type rules, provider templates, and new versus established patient logic. Read only availability with a request form is a different and much weaker feature, because the patient still waits for a call back. Cancellation and rescheduling matter as much as booking, since a patient who cannot cancel online simply does not show.

Portal scheduling has real but partial uptake. A survey of 3,661 US adults published in Health Affairs Scholar in April 2025 found 34.1% had used a provider portal to schedule an appointment and 19.7% named it their primary scheduling method, against 72.1% who used phone calls. Portal scheduling is a meaningful minority channel, not a replacement for the phone, and staffing plans should reflect that.

Waitlist automation is the underrated companion feature. When a cancellation opens a slot, rules based outreach to eligible waitlisted patients recovers revenue that otherwise disappears, and it does so without adding a phone task. Arkenea’s Cumberland platform paired provider availability and assignment management with automatic closure of appointments after a service level window, which kept the appointment lifecycle from silently stalling.

Prescription refills and electronic prescribing

Refill requests should originate from the patient’s actual medication list, not a free text field, because free text refill requests generate transcription errors and clarification messages. The patient selects a medication, confirms the pharmacy, and sees request status through to transmission. Status visibility is what stops the follow up message asking whether the request went through.

Behind the interface, the portal needs a route to the prescriber queue in the EHR and a pharmacy network connection for transmission. Controlled substances carry additional identity and prescribing requirements that live with the prescriber, not the portal, and should be excluded from patient initiated refill flows. Medication reconciliation quality determines whether this feature helps or generates noise.

Digital intake, registration, and check in

Intake forms are where portals repay their build cost fastest, because they move data entry from staff to patient and from the waiting room to the day before. The requirement is conditional logic that shows only relevant questions, validation that catches insurance and demographic errors at entry, and a write back path so answers land in the chart as discrete data rather than a scanned attachment. A form that produces a PDF a staff member retypes has not automated anything.

Consent capture belongs here too, with versioned consent documents and a durable record of what was signed and when. Practices operating across multiple locations or specialties need form sets that vary by visit type. The Cumberland build used consent gates as a precondition for the visit rather than as a step patients could skip and complete later.

Bill pay, cost estimates, and insurance

Payment features fail when they present a number the patient does not recognize. An itemized statement view, an explanation of what insurance paid, and a payment plan option do more for collection rates than a faster checkout. Eligibility verification and good faith cost estimates before a scheduled service reduce the disputes that follow.

Card data handling brings PCI DSS scope into a project that was previously HIPAA only, and the cheapest way to manage that is to keep card data out of your systems entirely through a tokenized processor. Storing card numbers to enable one click payment is rarely worth the audit burden it creates. The Cumberland platform integrated payment collection directly into the appointment record so that clinical and financial status were visible in one place rather than two systems.

Visit summaries, care plans, and education

After visit summaries and care plans give the portal a reason to be opened between appointments. The useful version links each instruction to an action the patient can take in the portal, such as booking the follow up, requesting the refill, or completing the questionnaire. Education content should be tied to the patient’s conditions and reading level rather than presented as a general library.

Features that determine whether anyone uses the portal

The gap between offering a portal and having it used is where most programs quietly underperform. ASTP/ONC Data Brief No. 77, published in July 2025 from 2024 survey data, reports that 77% of individuals were offered online access to their medical record while 65% were offered and accessed it. The features in this section close that gap more reliably than adding another capability to the core set.

Proxy and caregiver access

Proxy access is the most underbuilt feature in the category relative to how many people need it. The same ASTP brief found that access to another person’s online medical record more than doubled, from 24% in 2020 to 51% in 2024. Half of portal households now involve someone managing care for a child, a parent, or a partner.

Building it properly requires a relationship model rather than shared credentials. Each proxy needs their own identity, a documented authorization, a scope of access, an expiry, and an audit trail attributable to them individually. Password sharing between a patient and an adult child is what happens when the feature is missing, and it destroys the audit record you would need in a breach investigation.

Adolescent confidentiality

Pediatric proxy access has an edge case that will surface in your first month live. State law grants minors confidentiality over certain categories of care, which means a parent proxy account cannot expose everything in an adolescent’s chart. The portal needs data segmentation by sensitivity category, age triggered changes to proxy scope, and a defined process for the transition to an independent account.

This is not a feature you can retrofit cheaply, because it touches the data model rather than the interface. Scope it during discovery if your patient population includes anyone under 18, and confirm the specific rules for every state in which you operate.

Mobile first, and specifically smartphone first

App based access has overtaken web only access. The 2024 ASTP data shows 57% of portal users reached their record through an app, up from 38% in 2020, while web only access fell from 60% to 42%. Designing primarily for desktop is now designing for the shrinking half of your users.

There is a sharper reason to prioritize the phone. Pew Research Center reported in January 2026 that 16% of US adults are smartphone dependent, owning a smartphone but having no home broadband, rising to 34% among adults earning under $30,000. For those patients the portal has to work on a phone over a cellular connection or it does not work at all. That argues for small payloads, tolerance for interrupted connections, and no workflows that assume a printer or a desktop file upload.

Multilingual support and plain language

Language access is a compliance obligation as well as an adoption lever. Section 1557 of the Affordable Care Act requires covered entities to provide meaningful access for individuals with limited English proficiency, and the 2024 final rule extends that expectation to health programs delivered through information and communication technology. Translating the interface while leaving clinical content in English satisfies neither the regulation nor the patient.

Plain language matters independently of translation. A study of 536 adults with chronic conditions published in JAMA Network Open in February 2024 found patients with adequate health literacy used the portal about 51% more than those with limited health literacy, independent of race, age, and sex. Reading level is a design variable, not a patient characteristic you have to accept.

Accessibility conformance

Accessibility has moved from good practice to a dated regulatory requirement for most healthcare organizations. The HHS Section 504 final rule published in May 2024 requires recipients of HHS federal financial assistance to conform their websites and mobile applications to WCAG 2.1 Level AA. Recipients of Medicaid and CHIP funds, which covers most hospitals and a large share of physician practices, are inside that scope.

The deadline moved. HHS announced in May 2026 that organizations with 15 or more employees now have until May 11, 2027, and those with fewer than 15 employees until May 10, 2028. Articles still citing May 2026 as binding are out of date. The extension is time to remediate, not a reason to defer scoping.

Notifications that respect the channel

A portal nobody opens produces no value, and notification design determines opening. Push, SMS, and email each carry different privacy constraints, since the notification itself should not disclose clinical information outside the authenticated session. Preference management, quiet hours, and per category controls prevent the alert fatigue that leads patients to disable notifications entirely.

Advanced patient portal features

Telehealth inside the portal

Telehealth belongs inside the portal rather than beside it, because a separate video link means a separate login, a separate support path, and a separate record. The integrated version reuses the portal’s identity, consent, scheduling, and payment components, and writes the encounter back to the chart. Virtual waiting rooms, device checks before the visit, and a fallback to audio when bandwidth fails are what separate a working feature from a demo.

Arkenea’s Cumberland platform ran an interactive chat to video consultation workflow with role based portals for admin, provider, and front desk staff alongside the patient application. The operational lesson from that build was that the staff facing side of telehealth determines whether the patient side works. Provider availability management, appointment status tracking, and time bound invitation links for staff access carried as much weight as the video session itself.

Patient generated health data and connected devices

Device integration is worth building when a clinical workflow consumes the data, and worth skipping when it does not. Weight, blood pressure, glucose, and activity streams from consumer devices are useful for chronic condition programs and largely decorative elsewhere. The design question is not whether you can ingest the data but who reviews it, on what cadence, and with what liability if a reading is missed.

In building MiPHR, a chronic disease and diabetes risk application, Arkenea integrated smart device connectivity with the USDA food database, QR code scanning for calorie capture, and biometric authentication through face and fingerprint recognition. The feature that made the data clinically useful was the least glamorous one: eFax integration that pushed a monthly report to the patient’s provider automatically. Patient generated data creates value at the moment it reaches a clinician, not at the moment it is collected.

Artificial intelligence in the portal

The realistic near term applications are message triage, draft reply generation for staff review, and plain language explanation of results and instructions. Each of these keeps a human in the decision path, which is the correct posture for a patient facing clinical channel. Autonomous clinical advice through a portal chatbot is a different risk category and should not be scoped casually.

Certification rules now touch this area directly. HTI-1 established transparency requirements for predictive decision support interventions in certified health IT, and Section 1557 requires covered entities to identify and mitigate discrimination risk from patient care decision support tools. If your portal surfaces a model output that influences care, you inherit documentation obligations that a generic chatbot deployment does not anticipate.

Analytics that inform the roadmap

Portal analytics should measure task completion, not page views. The questions worth instrumenting are how many patients start registration and finish it, how many message threads resolve without a phone call, how many scheduling attempts end in a booked appointment, and where each of those funnels drops. Aggregate login counts tell you nothing actionable.

The integration layer that makes features work

Every feature above is a thin interface over an integration. This is the section most feature articles omit, and it is the one that determines project cost and timeline more than any design decision.

FHIR R4, US Core, and SMART on FHIR

HL7 FHIR Release 4.0.1 is the required standard for the standardized API certification criterion at 45 CFR 170.315(g)(10), together with the US Core Implementation Guide and SMART App Launch framework. In practice this means any EHR certified under that criterion exposes a patient facing FHIR API you can build against, with OAuth 2.0 authorization and scoped access.

Two details save projects. First, certification currently references US Core STU 6.1.0 while HL7 has published later versions, so the resources available in your target EHR may be narrower than the current standard suggests. Second, the SMART App Launch guide distinguishes EHR launch from standalone launch, and a portal that authenticates patients directly needs the standalone pattern plus refresh token handling for persistent access.

FHIR read access is well supported. FHIR write access is not uniformly supported, which is why scheduling, refill requests, and intake write back often still depend on vendor specific APIs or HL7 v2 interfaces rather than pure FHIR. Assume a hybrid integration until a sandbox proves otherwise.

HL7 v2 interfaces and the interface engine

Laboratory results, admission and discharge events, and orders still move over HL7 v2 in most environments. An interface engine sits between the portal and those feeds, handling message transformation, acknowledgment, retries, and error queues. Budget for the engine, the interface build per feed, and the ongoing cost of the source system vendor’s interface fees, which are frequently the largest surprise line item in a portal project.

Pharmacy, payment, and eligibility connections

Prescription transmission runs through a pharmacy network rather than direct pharmacy connections. Payments run through a processor that keeps card data out of your environment. Eligibility and benefit checks run through a clearinghouse. Each of these is a contract and a certification process, not just an API key, and each has a lead time that belongs in the project plan rather than the final sprint.

Identity federation

If your organization already runs an identity provider, federating portal login through SAML 2.0 or OpenID Connect avoids maintaining a second credential store. For multi entity organizations it also solves the problem of a patient who is seen at two affiliated practices and expects one login. Single sign on across entities is an identity architecture decision, not a portal setting.

Compliance as architecture, not a checkbox

Compliance failures in portals are rarely the result of not knowing the rules. They come from treating the rules as a review gate at the end rather than as constraints on the data model at the start.

HIPAA in the design, not the documentation

The HIPAA Security Rule requires administrative, physical, and technical safeguards, and the technical ones map directly to portal architecture. Access control means role based permissions enforced server side, not hidden interface elements. Audit controls mean an immutable log of every access to protected health information, including proxy access, retained and reviewable. Transmission security means TLS for data in motion and strong encryption for data at rest.

The risk is concentrated where the data sits, not where patients tap. The HHS Office for Civil Rights Annual Report to Congress for 2024 recorded 663 breaches affecting 500 or more individuals, with hacking and IT incidents causing 81% of them and 99% of affected individuals. Network servers accounted for 63% of large breaches and 98% of affected individuals, while electronic medical records accounted for 3%. Server hardening, key management, and segmentation deserve more attention than the login screen.

Information blocking

The information blocking regulations at 45 CFR Part 171 prohibit practices likely to interfere with access, exchange, or use of electronic health information, subject to ten defined exceptions. Compliance began April 5, 2021, and the definition expanded from a limited data set to the full electronic health information definition on October 6, 2022. Portal design choices such as delaying result release, restricting note visibility, or making record export difficult sit squarely inside this rule.

The consequences are now specific. Health IT developers and health information networks face civil money penalties of up to $1 million per violation. HHS finalized disincentives for health care providers effective July 31, 2024: hospitals lose three quarters of their annual market basket increase, MIPS eligible clinicians receive a zero in the Promoting Interoperability category, and accountable care organization participation can be denied for at least a year.

Enforcement posture has shifted as well. HHS announced expanded enforcement resources in September 2025, and ASTP reports it has received 2,563 submissions through its information blocking portal, of which 2,450 represent possible claims. Designing result release rules without documenting which exception applies is an unfunded liability.

Payer APIs and what they mean for portals

The CMS Interoperability and Prior Authorization final rule (CMS-0057-F) requires impacted payers to implement a Patient Access API, a Provider Access API, a Payer to Payer API, and a Prior Authorization API by January 1, 2027, and to return prior authorization decisions within 72 hours for expedited requests and seven calendar days for standard ones. The CMS fact sheet sets out the scope. For provider side portals this is an opportunity rather than an obligation, since patient authorized payer data can fill the coverage and claims gaps a provider portal cannot see on its own.

A note on regulatory direction

The certification program is contracting rather than expanding. HHS withdrew the non finalized HTI-2 proposals in December 2025, and a proposed rule, HTI-5, would remove 34 of 60 certification criteria. That proposal was still pending as of early 2026. Statutory obligations such as information blocking are unaffected by certification changes, which is the distinction to hold on to when planning a multi year roadmap.

The cost clinicians pay for portal features

Portal feature discussions usually price the build and ignore the operating burden. That is the wrong way around, because the operating burden recurs annually while the build happens once.

Inbox time is the clearest measure. A study of 115 primary care physicians across 48 clinics published in the Journal of General Internal Medicine in May 2024 found physicians spent about 40 minutes in the EHR inbox per eight hour scheduled day. Notably, common efficiency tools such as message triage, custom quick actions, and message pools showed no significant association with reduced inbox time in that analysis. Tooling alone does not solve a volume problem.

Billing for asynchronous messages is not the answer either, at least not at current utilization. Research published in Health Affairs Scholar in April 2024 found that online digital evaluation and management services in traditional Medicare, billed under CPT 99421 to 99423, settled at roughly 90 monthly encounters per 100,000 beneficiaries after an early pandemic peak. They represented 0.05% of Medicare evaluation and management services in 2022, and only 0.8% of beneficiaries receiving those services were billed for one.

The design implication is direct. Build features that let patients resolve questions without generating a message, such as visible result interpretation, refill status, and appointment self service. Every message the interface makes unnecessary is worth more than every message the interface makes easier to send.

Build or buy: how to decide

Most organizations should start with the portal bundled with their EHR. It is included in a contract you already have, it integrates with no interface work, and it covers the core feature set adequately. The reasons to build something custom are specific and testable.

Usability alone can justify a custom build, and it is more common than the table suggests. Arkenea built a custom EHR for Hamilton Physical Therapy, an eight location practice in Montana, because the off the shelf system’s documentation workflow was consuming clinician time that should have gone to patients. The custom system integrated with the billing software already in place, ran on cloud infrastructure for scale, and reduced documentation time enough to affect the practice’s topline. The same reasoning applies to patient facing software when the vendor interface is the reason patients call instead of clicking.

There is a third option worth naming. A custom patient experience layer built on the EHR’s FHIR API keeps the system of record where it is while giving you control of the interface, the branding, and the workflows. It costs less than a full custom portal and avoids the data migration and record keeping obligations of replacing the EHR.

What a patient portal costs and how long it takes

Published figures for this vary by an order of magnitude, largely because nobody defines what is inside the estimate. The ranges below reflect what Arkenea sees in engagements for US healthcare organizations, priced as discrete scopes rather than a single number. They assume HIPAA aligned infrastructure, documented security controls, and integration with a certified EHR.

Three cost drivers move these numbers more than anything else. Interface fees charged by the incumbent EHR vendor can add tens of thousands before a single line of your code runs. The number of distinct source systems compounds cost roughly linearly. Accessibility and language requirements identified after design is complete cost several times what they cost when specified at the start.

Assumptions about patient portals that the evidence does not support

Several beliefs circulate in portal planning discussions that current data contradicts. Naming them explicitly saves money.

“Patients should not see results before their doctor calls”

The survey evidence cited earlier found 95.7% of patients preferred immediate access, including 95.3% of those who received abnormal results. The regulatory position points the same way. The defensible design releases immediately and invests in interpretation, rather than withholding and hoping the call happens quickly.

“A portal will cut our phone volume”

The 2026 JAMA analysis found telephone encounters fell only 6% to 7% between 2020 and 2025 while portal messages rose 153%. Portals redistribute contact rather than eliminating it. Model the message queue as new work with a staffing cost, not as a phone call that disappeared.

“More features means more adoption”

The ASTP data shows 77% of individuals were offered access while 65% accessed it, and the strongest single correlate of use was not feature count. Among individuals whose provider encouraged portal use, 87% accessed it, compared with 57% of those not encouraged. Enrollment and encouragement workflows outperform additional features at the margin.

“One portal per organization is enough”

Patients do not experience your portal in isolation. The 2024 ASTP data shows 59% of individuals who accessed records online had more than one portal, and only 7% used an aggregating application. Export, third party transmission, and standards based API access are features that reduce fragmentation for the patient even though they send data away from you.

“Responsive web design covers mobile”

Responsive design covers screen size. It does not cover intermittent cellular connectivity, biometric login, push notifications, or the 16% of adults who have no home broadband at all. Whether that gap justifies a native application is a real question, but it should be answered deliberately rather than assumed away.

“HIPAA compliance means the portal is compliant”

HIPAA governs privacy and security. It does not address information blocking, which sits under the 21st Century Cures Act, nor accessibility, which sits under Section 504 and Section 1557, nor payer API obligations under CMS rules. A portal can be fully HIPAA compliant and still be out of compliance in three other directions.

Measuring whether your portal features are working

Feature lists are easy to audit and hard to evaluate. These measures tell you whether the features are doing work, and each one points to a specific fix when it underperforms.

Segmenting by age, language, and payer is the measure most programs skip and the one that most often changes the roadmap. A portal with strong aggregate numbers and a 20 point gap between English and Spanish speaking patients has a translation problem, not an adoption problem.

A sequencing approach that works

Ordering matters as much as selection, because early features determine whether patients return for later ones. The sequence below reflects how Arkenea phases portal engagements.

1. Identity, registration, and account recovery, built to work on a phone without staff assistance
2. Record access and test results, released immediately with plain language interpretation
3. Digital intake and consent, with structured write back into the chart
4. Scheduling against live availability, including cancellation and rescheduling
5. Secure messaging, launched only once triage routing and staffing are defined
6. Refills, bill pay, and estimates
7. Proxy and caregiver access with a proper relationship model
8. Telehealth, device integration, and analytics driven refinement

Messaging appears fifth deliberately. It is the feature patients ask for first and the one most likely to damage the program if it launches without a staffing model behind it.

Frequently asked questions

What are the essential features of a patient portal?

The essential set is identity proofing and secure login, health record access structured to USCDI data classes, immediate test result release, secure messaging with triage routing, appointment scheduling against live availability, prescription refill requests, digital intake and consent, and online bill pay. Everything beyond that set is valuable but conditional on the care model. A portal missing any of the eight will generate phone calls that cancel out its benefit.

How much does it cost to build a custom patient portal?

A core portal with identity, record access, results, messaging, scheduling, and forms typically runs $90,000 to $160,000 over 4 to 6 months, with integration to a single EHR adding $40,000 to $90,000. Telehealth, native mobile applications, and payments are separately scoped. Annual operating cost generally runs 15% to 25% of the build cost, covering hosting, monitoring, security maintenance, and support.

How long does patient portal development take?

A focused portal covering the core feature set reaches production in 4 to 6 months when a single EHR integration is in scope and the source system vendor cooperates on interface access. Multiple source systems, telehealth, and native applications extend that to 9 to 14 months. Interface approval from the incumbent EHR vendor is the most common cause of schedule slip, so it belongs at the front of the plan.

Should we build a portal or use the one from our EHR?

Use the EHR portal unless you have a specific reason not to. The reasons that hold up are multiple EHRs producing multiple patient logins, a care model the vendor product does not represent, patient experience being the product itself, or a regulatory or program requirement your vendor will not prioritize. A custom experience layer built on the EHR’s FHIR API is often the middle path.

Is a patient portal required by law?

No statute requires a portal by name. However, the information blocking regulations require that patients be able to access their electronic health information without unreasonable interference, and Medicare programs tie payment adjustments to providing that access. A portal is the standard mechanism for meeting those obligations, which makes it effectively mandatory for most organizations.

What is the difference between an integrated and a standalone portal?

An integrated portal ships with the EHR and reads and writes to it natively, with no interface work required. A standalone portal is a separate application connected through APIs and interfaces, which allows a unified experience across multiple source systems and full control of the interface. Integrated portals cost less and constrain more, and the tradeoff is usually decided by how many source systems you have.

Can a patient portal integrate with more than one EHR?

Yes, and this is one of the strongest justifications for a custom build. It requires a normalization layer that maps each source system’s data into a common model, along with patient identity matching across systems so one person is not represented as several. The complexity is in the identity matching and the terminology mapping rather than in the connections themselves.

What makes patients actually use a portal?

Provider encouragement is the strongest documented correlate: 87% of individuals encouraged by their provider accessed the portal compared with 57% of those who were not. After that, completion of the first task without friction matters most, which points at registration, mobile performance, and result presentation. Feature breadth affects retention far less than the first successful interaction does.

Where to start

If you are evaluating portal features, resist the temptation to score vendors on capability checklists, because nearly every product will claim nearly every feature. Test instead whether a patient can complete registration, read a result, book a visit, and send a message on a phone without calling anyone. The products differ enormously on that test and barely at all on the checklist.

If you are building, budget for the integration layer and the compliance architecture before the interface, and sequence messaging after you have a staffing model for it. Arkenea has spent 15 years working only in healthcare software, and the engagements that succeed are the ones where the scoping conversation covers identity, interfaces, and audit before it covers screens. That order is the whole difference between a portal patients use and a portal you have to explain.