Top 10 Healthcare App FeaturesPatients Actually Use in 2026

Nine out of ten people who log in to a patient portal do it to look at a test result. That's the single most useful number I know in healthcare product work, and it comes from the federal government, not from a vendor deck.

I bring it up because the feature lists I see in healthcare app proposals usually look like a restaurant menu. Symptom checker, AI chatbot, gamified wellness, wearables sync, community forum, a dozen more. Almost none of them are ranked. Almost none of them say which ones patients actually open.

So this article does the boring thing. It takes the published federal survey data on what patients do with portals and apps, ranks ten features by it, and says plainly where the data runs out. Along the way it covers the rules that decide what you can build: the 21st Century Cures Act information blocking provisions, the certified FHIR API at 170.315(g)(10), the CMS Patient Access API for payers, and Apple Health Records.

This is a features article, not an agency ranking. If you are choosing a builder, that comparison lives in our ranking of healthcare app development companies.

The usual belief is that a patient app wins on breadth: the more it does, the more people use it. The data says the opposite. Patient use concentrates on a handful of jobs, and those jobs are old and unglamorous.

Think of a grocery store. Most people walk in for milk, bread and eggs, and the store puts them at the back so you walk past everything else. A patient app doesn't get to do that. If results, notes, messages and appointments are more than two taps away, patients stop opening it.

Therefore the right question isn't "what else could we add?" It's "are the four things patients came for fast, correct and obvious?" Everything past that is a second phase that has to earn its budget.

To be clear, I am not against new features. I am against building feature eleven while feature one still loads a PDF that is unreadable on a phone.

The best public source on patient portal use is the Health Information National Trends Survey (HINTS), which the federal health IT office (ASTP/ONC) analyzes in its data briefs. The most recent is Data Brief 77, published in July 2025 using 2024 survey responses.

Its headline numbers: 77% of individuals were offered online access to their medical records by a provider or insurer, and 65% accessed their records or a portal at least once in the past year. The 2022 figure for access was 57%, so that's about an eight point rise in two years.

A few more figures from the same brief shape the ranking below. 57% of people who accessed their records used an app, while 42% used only a website. 59% had more than one portal. 51% accessed a portal on behalf of someone they care for. And people whose provider encouraged them to use the portal accessed it at 87%, against 57% for those who weren't encouraged.

What do people do once they're in? ONC's Quick Stat #69 tracks it. Among people who accessed a portal, 90% viewed test results, 80% viewed clinical notes, 79% messaged providers and 77% made appointments. Downloading information sat at 32% and sending information to a third party at 20%. Those last two match the values in the 2022 brief, so I treat them as the latest available figures rather than new 2024 movement.

The CDC's National Center for Health Statistics asks a different question in the National Health Interview Survey, and its denominator is all adults, not portal users. NCHS Data Brief 482 found that in the second half of 2022, 46.1% of adults used the internet to look up medical test results and 41.5% used it to communicate with a doctor or doctor's office. Different survey, same ordering: results first, messaging right behind.

For telehealth, NCHS reported in Data Brief 445 that 37.0% of adults used telemedicine in 2021. A later NCHS report, covered by HealthDay, put 2022 at 30.1%. NHIS counts phone visits as telemedicine, so this isn't a video-only number.

Four federal rules decide what a patient app can get and when, and one of them is often misdescribed as final. Here is where each stands on September 30, 2026.

The order below is set by published federal usage data where it exists: first the ONC portal-use shares, then the ONC access-method and proxy figures, then the NCHS telehealth figure. Refills and bill pay come last only because I found no federal usage figure for them, not because they don't matter.

Apple Health Records is a part of the Health app on iPhone that downloads a patient's records from supported healthcare institutions and keeps them up to date. It's the best-known example of the "organize my portals" category that ONC found 7% of individuals use.

According to Apple Support, once a patient sets up downloads from a provider, records arrive automatically and appear in categories such as Allergies, Clinical Vitals and Lab Results. Patients can pin lab results, remove an organization and its records, and share chosen categories with third-party apps, either current records only or current and future ones.

Under the hood it's FHIR. Apple's developer documentation says HealthKit reads FHIR records from supported institutions, updates them in the background, and stores each record as a discrete sample such as a single condition, procedure or result. Apps that want to read them must enable the Clinical Health Records capability, write a usage string explaining why, publish a working privacy policy URL, and ask permission for each record type. App Review may reject apps that don't use the data appropriately.

And, like (g)(10), it's read-only. Apple states that clinical records can't be shared or saved by apps. So Health Records helps with feature 7 and part of feature 1. It doesn't book appointments, send messages or request refills.

For a practice, the practical point is simple. If your EHR supports patient access through its certified API, patients can often connect Apple Health Records without you building anything. Your app's job is to do what Health Records can't.

Consider a multi-provider practice with 10,000 active patients, deciding which features to fund first. This is a scenario, not a client, and the arithmetic uses only the federal shares above.

If the practice's patients behave like the 2024 national sample, about 6,500 of them (65%) will use a portal in a year. Of those, about 5,850 will view results (90%), 5,135 will message (79%) and 5,005 will book online (77%). About 3,700 will use an app (57% of 6,500). And about 5,100 people (51% of 10,000, applying the national share loosely) may be logging in on someone else's behalf.

Now compare that with a feature most proposals love, like a symptom checker. There's no federal usage figure for it at all. Maybe it does well. But the practice can see exactly how many people touch results and messaging, and can't see that for the checker.

So the math reduces to a simple multiplier. Messaging reaches about 5,100 patients; the unknown feature reaches some unknown number. Unless someone brings evidence that the unknown feature beats 5,100, fix messaging first. That's the whole method.

Then the encouragement figure. ONC found 87% of encouraged patients used their portal against 57% of those not encouraged. That's a 30 point gap that costs no code at all: staff telling patients at checkout, and a text link after the visit. I'd do that before building anything.

Two of our case studies touch these features directly, and I'll describe only what the case studies say.

For the Wisdom Tooth Clinic in Miami, an oral surgery practice, we built online booking with intake screening, emergency booking, confirmations and email preferences, plus a staff portal with a day view, bookings and call transcript review. Booking works through signed offer tokens so the voice agent can't book a time that doesn't exist, and intake red flags for things like anticoagulants are checked in plain code rather than left to a model. The case study documents the HIPAA setup: Supabase with its HIPAA add-on, Vercel and OpenAI under BAAs, and PHI scanning in CI.

For Clinique CGSA, a medical psychology clinic, we built a HIPAA-compliant scheduling system for patient bookings and an internal mobile app for its team.

Both are features 4 and 5 on the list above. Neither case study reports patient usage rates, so I don't quote any. The broader picture of how we approach healthcare work is on our healthcare industry page.

Two facts you should know before any call. We sign a business associate agreement with every healthcare client, and we hold no SOC 2, ISO 27001 or HITRUST certification. If your procurement needs SOC 2 from the builder, we won't pass that step, and I'd rather you knew now. Our approach to hosting under a BAA is in the HIPAA hosting guide.

Several popular features are missing from the ten because I found no neutral usage data for them, not because they're bad ideas. A ranking built on evidence has to leave out what the evidence doesn't cover, and say so.

Symptom checkers and AI chat.They show up in almost every proposal I read. No federal survey I found measures how many patients use them, and the numbers that circulate come from the companies selling them. There's also a regulatory question: depending on what the tool says, it can drift toward being a medical device. If you want one, scope it narrowly, route anything clinical to a human, and measure it yourself before calling it a success.

Wearable and device sync.Pulling steps, heart rate or glucose readings into an app is easy to demo and hard to use clinically. Someone has to look at the data, decide what counts as a problem and respond. Without that workflow, it's a chart nobody reads. Remote monitoring programs are a real thing, but they're a service line, not an app feature.

Community forums and gamification.Badges and streaks work in fitness apps. In a patient app, they sit awkwardly next to a cancer result. I'd leave them out of a general patient app entirely.

Digital intake and forms.This one nearly made the list. Filling in history, consent and insurance details before the visit saves front desk time, and it's part of what we built for the Wisdom Tooth Clinic. I left it off only because I found no federal usage figure to rank it against the others. If your front desk spends its mornings re-typing clipboards, it may be your number one.

Every one of the ten features depends on four basics that patients never name but always notice: sign-in, accessibility, language and trust. Get these wrong and the ranking doesn't matter.

Sign-in. ONC found 59% of people have more than one portal. Each has its own username and password, and many patients forget which is which. Biometric sign-in on the phone, a sane password reset, and a clear message when an account is locked prevent a large share of support calls. Proxy access lives here too: the caregiver needs their own identity, not a borrowed one.

Accessibility.Patients include people with low vision, tremors, limited reading ability and older phones. Large tap targets, text that scales, screen reader labels and results written in plain language aren't polish. They decide whether the people who most need the app can use it at all.

Language.If a practice serves patients in Spanish, the app should too, including notifications and error messages. A translated home screen with English messages behind it is worse than no translation, because it sets an expectation it can't meet.

Trust.Patients should be able to see which apps have access to their records, revoke that access and understand what the practice does with their data. That's partly HIPAA and partly common sense. Every vendor in the chain that touches protected health information needs a business associate agreement, and that includes hosting, messaging, analytics and any AI service. Analytics tools are the usual surprise: a tracking pixel on a logged-in page can send health information somewhere it shouldn't go.

None of this shows up in a feature grid. All of it shows up in reviews.

The write path breaks first, almost every time. Reading data through the certified API works across vendors because certification forces it to. Writing a booking, a message or a refill request back into the EHR depends on the vendor, and that's where timelines slip.

• Write access: the booking or refill works in the demo and fails against production because the vendor interface needs a separate agreement or fee. Signal: no written confirmation of write access before build starts.
• Messaging inbox: patients send, nobody answers in the promised window. Signal: no named owner for triage, no after-hours rule.
• Proxy access: families share logins because proxy setup is buried or manual. Signal: support tickets about locked accounts from caregivers.
• Results release: patients see abnormal results with no context and flood the phones. Signal: call spikes after lab batches post.
• Duplicate portals: patients already have the EHR vendor app and your app, and use neither well. Signal: app downloads flat while portal use rises.
• Third-party app access: a patient's chosen app is blocked by a well-meaning security setting. Signal: patient complaints; information blocking exposure.

Is the worst case survivable? Yes, if you sequence it. Start with read-only features that the certified API supports, prove patients use them, then add writes one at a time with the vendor agreement in hand. The downside of that order is a slower launch. The downside of the other order is a finished app that can't save a booking. Those API contracts and integrations are the work of API development, and they deserve their own line in the budget.

The biggest red flag is a proposal that doesn't say which features read and which write. That single line tells you whether the builder understands healthcare integration.

• No read versus write split, or a claim that FHIR alone handles booking and messaging.
• Usage or ROI statistics with no named source, or a vendor's own adoption number presented as industry fact.
• HTI-5 described as final law.
• Proxy access missing, or handled by shared credentials.
• No mention of a business associate agreement with the builder and every hosting or AI vendor that touches PHI.
• A claim of SOC 2 or HITRUST you can't verify with a report.
• A long feature list with no ranking and no reason for the order.
• No plan for who answers messages and how fast.

One more. If someone quotes you a statistic about what percentage of patients "want" a feature, ask for the survey. Preference surveys and usage surveys measure different things, and vendor-run ones are rarely published with a method.

Several things I looked for aren't in the public data, and I would rather say so than fill the gap.

• Refill and bill pay usage: I found no current federal figure in the ONC or NCHS briefs I reviewed. Their rank reflects missing data, not low use.
• Reminder use: no federal figure found; treated as part of scheduling.
• Telehealth after 2022: a 27% figure for 2023 circulates, but I could not reach a primary NCHS source for it, so I don't print it.
• Download and transmit shares: the 32% and 20% in ONC's Quick Stat match 2022 values, so they may not reflect 2024 behavior.
• Apple Health Records coverage: no current institution count from an Apple page.
• Information blocking enforcement details from 2026: reported in trade coverage, not confirmed on an HHS page I could fetch.
• HTI-5: proposed, not final, as of September 30, 2026. Its final shape could change the certification picture.

I also refused vendor-published portal adoption and ROI numbers. They may be right for that vendor's customers, but they aren't neutral evidence about patients in general.

Start with what you already have. Most practices can improve the big four without writing code.

1. 1.Open your own portal on a phone as a patient. Time how long it takes to find the latest test result, send a message and book a visit. Anything over two taps is your first project.
2. 2.Ask your EHR vendor, in writing, which patient actions can be written back into the record through an interface you can use, and at what cost. That answer sets the budget for features 3, 4 and 9.
3. 3.Add one sentence to checkout: an invitation to use the portal. ONC's data shows encouraged patients used portals at 87% against 57%.

Then decide what to build. Time to get to work.