Healthcare App Features: What to Build, and the HIPAA Rules That Decide How
Every other guide starts with a feature list. In healthcare, one question decides what you are allowed to build at all.
Every other guide to healthcare app features opens with a list. That is the wrong place to start, because one question decides what you are allowed to build, who you may build it with, and what it costs: does your app create, receive, maintain or transmit electronic Protected Health Information? If it does, it is a regulated build, and the platform, the contracts and the controls all change. This guide covers the features a provider app actually needs, in build order, and puts the compliance constraint next to each one rather than in a footnote. It also says plainly which plans can and cannot handle patient data, including our own. It is not legal or compliance advice, and every decision here should be checked with your compliance officer. Ready to build? See the HIPAA-eligible plan.
What This Guide Covers
- Does your app touch ePHI at all
- HIPAA in the terms that affect the build
- Intake, scheduling and the portal
- Telehealth, messaging and monitoring
- What it costs and which plan qualifies
- The features that add risk, not value
Read this before you build: apps handling ePHI must not be deployed on ordinary plans. With Appy Pie AI, HIPAA features and Business Associate Agreements are available only under the Enterprise Healthcare Plan. Ask every vendor the same question and get the answer in writing.
Get Started FreeTL;DR Quick Summary
In healthcare, the feature list is the second question. The first is whether your app creates, receives, maintains or transmits electronic Protected Health Information, because that decides whether this is an ordinary build or a regulated one. If it is regulated, three things from HIPAA shape it: the Security Rule requires administrative, physical and technical safeguards; every vendor touching PHI needs a signed Business Associate Agreement, which HHS describes as satisfactory assurances in the form of a contract, and under which a business associate is directly liable; and compliance is shared, so no platform can hand it to you. On that footing the build order is patient intake, appointment scheduling with reminders, the patient portal, then secure messaging once you know who answers it, with telehealth, medication features, remote monitoring and clinician tools following. Be strict about eligibility, including with us: Appy Pie AI HIPAA features and BAAs are available only under the Enterprise Healthcare Plan, and ePHI apps must not be deployed on Basic, Gold, Platinum, Team or Company plans.
See the HIPAA-Eligible Plan →Table of Contents
Jump to any section: the ePHI question that comes before any feature, HIPAA in the terms that affect your build, patient intake, appointment scheduling and reminders, the patient portal, telehealth and video consultation, secure messaging, prescriptions and adherence, wearables and remote monitoring, the clinician-facing half everyone forgets, what it costs and which plan actually qualifies, and the features that add risk without value, plus an FAQ.
- The Question That Comes Before Any Feature
- HIPAA in the Terms That Actually Affect Your Build
- Patient Intake and Registration
- Appointment Scheduling and Reminders
- The Patient Portal: Records, Results and History
- Telehealth and Video Consultation
- Secure Messaging
- Prescriptions and Medication Adherence
- Wearables and Remote Monitoring
- The Half Everyone Forgets: Clinician-Facing Features
- What It Costs, and Which Plan You Actually Need
- Features That Add Risk Without Value
- Frequently Asked Questions
The Question That Comes Before Any Feature
Every other guide on this topic opens with a feature list. That is the wrong place to start, because in healthcare one question decides what you are allowed to build, who you may build it with, and what it will cost.
Does your app create, receive, maintain or transmit electronic Protected Health Information? Answer that first. Everything below reads differently depending on the answer.
What counts as ePHI
Health information that identifies an individual, held or moved electronically. A name attached to an appointment with a named clinic. A test result. A medication list. A message about a symptom. A photograph of a wound. It is broader than people expect, and it is rarely just the obvious clinical record.
What generally does not count: genuinely anonymous content, general health education with no individual attached, a fitness tracker you built for consumers that never touches a provider’s records. The moment a covered entity is involved, or an individual becomes identifiable, treat it as ePHI.
Two apps, two completely different projects
A wellness or education app that touches no ePHI is an ordinary app build. You can use ordinary tools, ordinary plans and ordinary timelines.
An app that touches ePHI is a regulated build. It needs an eligible platform, a signed agreement with every vendor in the chain, and controls you can evidence. Same feature list on the surface, completely different underneath, and confusing the two is the single most expensive error in this category.
A necessary disclaimer, meant sincerely
This guide is written for people planning a build. It is not legal or compliance advice, and it cannot be, because compliance depends on your organisation, your data and your jurisdiction. Every decision below should be checked with your compliance officer or counsel before live patient data touches anything.
HIPAA in the Terms That Actually Affect Your Build
You do not need to read the regulation end to end. You do need three things it says, because they change what you build and who you can build it with.
1. The Security Rule tells you what to implement
In the Department of Health and Human Services’ own words, the Security Rule “requires implementation of appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of electronic protected health information.” It sits at 45 CFR Part 160 and Subparts A and C of Part 164.
Read that as a checklist with three columns. Technical is the part developers think of: encryption, access control, audit logging, integrity checks. Physical covers where the servers live and who can reach them. Administrative covers your policies, training and risk analysis. Only the first column is bought with a platform. The other two are yours.
2. The BAA is a contract, not a checkbox
This is the part most feature articles skip entirely. HHS states that the rules permit a covered entity to disclose PHI to a business associate only where it obtains “satisfactory assurances, in the form of a contract or other written arrangement”, which is the Business Associate Agreement, and that a business associate is “directly liable” for certain provisions.
Practically: every vendor that touches PHI on your behalf needs a signed BAA. Your app platform, your hosting, your SMS gateway, your analytics, your error tracker. An analytics SDK quietly collecting screen names inside a patient portal is a real and common breach path. Inventory every vendor in the chain before launch, not after.
3. Compliance is shared, and no vendor can hand it to you
A platform can provide eligible infrastructure, encryption, audit controls and a signed BAA. It cannot conduct your risk analysis, train your workforce, configure your access permissions or write your policies. As our own healthcare page puts it: no vendor can independently make an organisation compliant.
Treat any tool marketed as making you “HIPAA compliant” out of the box with suspicion. The honest claim is HIPAA-eligible infrastructure plus a BAA, with the rest resting on you.
Patient Intake and Registration
The highest-value feature in most provider apps, because it removes the clipboard and the re-keying behind it.
What it replaces
Paper forms filled in a waiting room, then typed into a system by a staff member who was doing something else. Digital intake collects the same information before arrival, validates it as it is entered, and lands it where it needs to be. The saving is staff time and transcription errors, both of which are measurable.
What good intake does
Saves progress, because nobody completes a long medical history in one sitting on a phone. Pre-fills what you already know for returning patients, since asking a regular for their address annually erodes trust. Handles insurance capture with a camera rather than typing. Supports a parent or carer completing forms on someone else’s behalf, which is a large share of real use.
The compliance note that applies from here on
Intake is the first feature that touches ePHI, so it is the first that carries the constraint: it must be built on an eligible platform under a signed BAA. That is not a formality you can add later, because the data arrives the moment the feature goes live.
Appointment Scheduling and Reminders
The feature with the clearest return, because a missed appointment is an empty slot nobody can resell at short notice.
Booking that reflects real availability
Scheduling is only useful if it knows the truth: which clinician, which location, which appointment type, and how long each takes. A generic slot picker that ignores appointment duration produces a diary that looks full and runs late all day. If your practice management system is the source of truth, the app has to read from and write to it rather than keeping a parallel calendar.
Reminders, and the detail that matters
A reminder is the single highest-return notification in healthcare. Two things make it work: enough notice to rearrange, and one-tap rescheduling or cancellation. A reminder with no easy way to cancel converts a would-be cancellation into a no-show, which is worse for you than the cancellation would have been.
Be careful what a notification says
This is where healthcare differs sharply from other categories. A lock-screen preview reading “Your oncology appointment is tomorrow” discloses health information to anyone glancing at the phone. Keep the notification content generic, put the detail behind authentication, and make that the default rather than a setting people have to find. Our guide to how push notifications work covers the mechanics; the restraint is specific to this industry.
The Patient Portal: Records, Results and History
The feature patients ask for most, and the one most likely to disappoint them.
What the benchmark tells you
These are the apps this category is measured against, with figures from Apple’s own App Store data checked while writing this guide.
| App | Rating | Ratings | What it is |
|---|---|---|---|
| Zocdoc | 4.88 | 174,944 | Find and book a doctor |
| Doximity | 4.82 | 197,315 | Clinician-facing |
| Teladoc Health | 4.79 | 729,559 | Virtual care |
| MyChart (Epic) | 4.60 | 705,518 | Patient portal |
Note which one is last. MyChart is ranked #1 in Medical on the App Store, and it is the lowest rated of the four. The category leader is the app patients like least. Portals are hard, because they surface clinical data written for clinicians, to patients, without context. That gap is the opportunity for a provider building their own front door.
Results need context, not just data
A lab value released to a patient with no explanation generates anxiety and a phone call. Show the reference range. Say plainly whether a result is in range. Where a result is significant, make sure the release timing and the clinician’s message are coordinated rather than leaving someone to read bad news alone at 11pm.
Access and identity are the hard part
Proxy access for a parent, a carer or an adult child managing a parent’s care is a large fraction of real portal use and is routinely under-built. Access must be provable, revocable and logged, because the audit trail is a Security Rule expectation and the first thing anyone asks for after an incident.
Telehealth and Video Consultation
The feature everyone asks for. Worth building well, and worth being clear-eyed about what it involves.
The video call is the easy part
The consultation itself is a solved problem. What surrounds it is not: identity verification before the call, a waiting room the clinician controls, the ability to bring in an interpreter or family member, sharing a document or image mid-call, and writing the encounter back into the record afterwards. Teams that budget for the video and not the workflow ship something clinicians quietly stop using.
Your video vendor is a business associate
A consultation is ePHI in transit. That means your video provider needs a BAA like every other vendor in the chain, and a consumer video tool without one is not an option however convenient it is. Check this before you design the feature, because it constrains which providers you can use.
Regulatory scope beyond HIPAA
Telehealth carries rules HIPAA does not cover: where the clinician is licensed relative to where the patient is sitting, what may be prescribed remotely, and how the encounter is billed. These vary by state and they change. They are outside the scope of this guide and firmly inside the scope of your compliance team, but they belong on the project plan from week one rather than appearing during launch.
Secure Messaging
The feature that most reduces phone volume, and the one most likely to overwhelm a team that has not planned for it.
Why it exists
Patients want to ask a short question without a phone queue or an appointment. Staff want those questions in one place, attached to the record, rather than scattered across voicemail and personal email. Done properly, secure messaging is the highest-satisfaction feature in a provider app.
Set expectations in the interface, not the FAQ
Two things must be visible where someone is typing: how long a reply usually takes, and what to do in an emergency. A message channel that feels instant but is answered in two working days is actively dangerous if someone uses it for chest pain. State the response window on the compose screen and put emergency instructions beside it.
Staffing decides whether this works
Message volume is real clinical work and someone has to be assigned to it. Practices that launch messaging without allocating time end up with a backlog, frustrated patients and clinicians answering messages at home. Decide who owns the queue before you build it, exactly as with any channel you cannot staff.
Prescriptions and Medication Adherence
Useful, genuinely valuable to patients, and an area to build conservatively.
What is safe and useful
A current medication list the patient can see. Refill requests routed to the right place. Reminders to take a dose, which is the feature with real evidence behind it for chronic conditions. Pharmacy details and collection status. None of that requires you to make clinical decisions.
Where to stop
Do not build interaction checking, dosage calculation or anything that behaves like clinical decision support unless you know exactly what you are taking on. Software that influences treatment decisions can fall under medical device regulation, and that is a different project with a different budget, timeline and evidence burden. If the feature would change what a clinician does, get regulatory advice before writing it, not after.
Reminders that survive contact with real life
People take medication at inconsistent times, skip doses, travel and change prescriptions. A reminder system that cannot be snoozed, edited or paused gets muted within a week, at which point it is worse than nothing because everyone assumes it is working.
Wearables and Remote Monitoring
The most oversold feature in healthcare apps, and genuinely transformative in the narrow cases where it fits.
Where it earns its place
Defined conditions with a defined response: blood glucose, blood pressure, weight in heart failure, post-operative recovery checks. What these share is a clinical protocol that says what happens when a number crosses a threshold. The feature works because somebody acts on it.
Where it fails
Collecting data nobody has agreed to monitor. If you stream heart rate into a provider’s system with no protocol, you have created a duty to look at it and no process for doing so, which is a clinical risk rather than a product feature. Decide who reviews the data, how often, and what happens out of hours, before you collect any of it.
The practical constraints
Consumer wearable data is not clinical-grade and should not be presented as though it were. Integrations break when the manufacturer changes an API. And this data is ePHI once it is attached to an identifiable patient in your system, with everything that implies for storage, retention and your BAA chain.
The Half Everyone Forgets: Clinician-Facing Features
Most healthcare app guides describe only the patient side. A large share of successful healthcare software is used by staff, and if clinicians will not use it, the patient side does not matter.
What clinicians actually need
A schedule they can read at a glance between patients. Secure messaging with colleagues, not only with patients. Fast access to the information needed before walking into a room. Anything that reduces documentation time, which is the profession’s most consistent complaint.
The design constraint is time, not screen size
A clinician is using this between appointments, often standing, often interrupted. Every extra tap is real. Features that assume a calm user with two free hands do not survive contact with a clinic, and this is where well-designed consumer patterns transfer badly.
Adoption is the whole battle
Staff-facing healthcare software has a long history of being mandated and worked around. The tools that succeed remove a task rather than adding one. If your app gives a clinician something new to fill in without taking something away, plan for it to be resented. The same lesson applies as with point-of-sale integration in restaurant apps: a tool that does not fit the workflow gets bypassed within a fortnight.
What It Costs, and Which Plan You Actually Need
Two costs matter here. One is the build. The other is eligibility, and it is the one that catches people out.
Eligibility comes first, and it applies to us too
Being direct about our own product, because this is the part a marketing page would rather gloss: an app handling ePHI cannot be built on an ordinary Appy Pie AI plan. Our healthcare page states it plainly. HIPAA features, segregated healthcare infrastructure and Business Associate Agreements are available only under the Enterprise Healthcare Plan, and applications handling ePHI must not be deployed on the Basic, Gold, Platinum, Team or Company plans.
The same question applies to every vendor you are considering. Ask which plan or tier is HIPAA-eligible, whether a BAA is included or an upgrade, and get the answer in writing before you build anything. A platform that will not sign a BAA cannot host ePHI, whatever its feature list says.
What drives the build cost
Integration, mostly. A standalone app with intake and scheduling is a modest project. The same app reading and writing to an electronic health record is a different order of work, and that single decision moves the budget more than any feature on this page. Telehealth adds a video vendor. Remote monitoring adds device integrations that need maintaining.
The recurring costs people forget
Two platform fees apply to any app on the stores: the Apple Developer Program at $99 a year and Google Play at a $25 one-time registration fee. Then the healthcare-specific ones: an eligible hosting tier, your video vendor, security testing, and the internal time for risk analysis and workforce training, which is real work even though no invoice arrives for it. Our guide to what building an app costs covers the general picture.
Features That Add Risk Without Value
In most categories a bad feature wastes money. Here it can create clinical or regulatory exposure, so the list matters more than usual.
Leave these out
Symptom checkers and any AI triage you have not validated. If it influences whether someone seeks care, you have built something closer to a medical device than an app feature. Interaction or dosage calculators, for the same reason. Analytics SDKs inside authenticated areas, which is a routine and entirely avoidable way to leak PHI to a third party with no BAA. Social or community features that let patients identify one another. Detailed health information in push notifications, which discloses to anyone near the screen. Any chat channel you cannot staff, which in healthcare is not merely rude but unsafe.
Build in this order
Settle the ePHI question and your platform eligibility. Then intake, then scheduling with reminders, then the portal, then messaging once you know who will answer it. Telehealth, monitoring and clinician tools follow, each with its own compliance review. Test the whole authenticated path on real devices before any live patient data goes near it, using our testing guide as a starting point.
The honest caveat
If your app would only publish opening hours, services and contact details, it touches no ePHI and needs none of this. A fast website will serve you better and can ship next week. The same question, framed generally, is in our guide to web apps versus native apps. Knowing which project you are on is the most valuable decision on this page.
Do this
- Answer the ePHI question before anything else
- Get a signed BAA from every vendor touching PHI
- Keep push notification content generic
- Show reference ranges beside any released result
- Assign the message queue before launching it
- Define who reviews monitoring data, and when
Avoid this
- Assuming a platform makes you compliant
- Analytics SDKs inside authenticated areas
- Symptom checkers or triage you have not validated
- Interaction or dosage calculators
- Health details on the lock screen
- A chat channel nobody is staffed to answer
Build a Healthcare App on HIPAA-Eligible Infrastructure
Patient intake, scheduling, portals and secure messaging, on infrastructure with AES-256 encryption, audit controls and a Business Associate Agreement under the Enterprise Healthcare Plan.
See the Enterprise Healthcare Plan Or check whether you need an appFrequently Asked Questions
What features should a healthcare app have?
For a provider app, build in this order: patient intake and registration, appointment scheduling with reminders, a patient portal for records and results, and secure messaging once you have decided who answers it. Telehealth, medication features, remote monitoring and clinician-facing tools follow. Every one of those touches ePHI, so platform eligibility and a signed BAA come before any of them.
Does my healthcare app need to be HIPAA compliant?
It depends on whether it creates, receives, maintains or transmits electronic Protected Health Information. A general wellness or education app that never touches identifiable health data linked to a covered entity usually does not. Anything handling patient records, appointments with a named clinic, results, or clinical messages does. When in doubt, treat it as ePHI and ask your compliance officer.
What is a BAA and do I need one?
A Business Associate Agreement is a contract with any vendor that handles PHI on your behalf. HHS states that a covered entity may disclose PHI to a business associate only where it obtains satisfactory assurances, in the form of a contract or other written arrangement, that the information will be safeguarded, and that a business associate is directly liable for certain provisions. In practice you need one with your app platform, your hosting, and any SMS, analytics or error-tracking service that could see PHI.
Can I build a HIPAA compliant app without coding?
You can build a healthcare app on a no-code platform, provided you use a plan that is HIPAA-eligible and the vendor will execute a BAA. This is important and often missed: with Appy Pie AI, HIPAA features and BAAs are available only under the Enterprise Healthcare Plan, and apps handling ePHI must not be deployed on the Basic, Gold, Platinum, Team or Company plans. Ask any vendor the same question and get the answer in writing.
Does using a HIPAA compliant platform make my app compliant?
No, and any vendor implying otherwise is overselling. A platform can provide eligible infrastructure, encryption, audit controls and a signed BAA. It cannot conduct your risk analysis, train your workforce, configure your access permissions or write your policies. Compliance is shared, and the administrative and physical safeguards in the Security Rule are largely your organisation’s responsibility.
How much does it cost to develop a healthcare app?
The biggest driver is integration rather than features. A standalone app with intake and scheduling is a modest project; the same app reading and writing to an electronic health record is a different order of work. On top of the build, expect an eligible hosting tier, a video vendor if you offer telehealth, security testing, and the Apple Developer Program at $99 a year plus Google Play’s $25 one-time fee.
What are the three types of HIPAA safeguards?
Administrative, physical and technical. HHS states the Security Rule requires appropriate administrative, physical and technical safeguards to ensure the confidentiality, integrity and availability of electronic protected health information. A platform mainly helps with the technical column, encryption, access control and audit logs, and partly with physical through its hosting. The administrative column, policies, training and risk analysis, is yours.
Can I send appointment reminders by push notification?
Yes, but keep the content generic. A lock-screen preview naming a specialty or condition discloses health information to anyone who can see the phone. Send a neutral reminder, put the detail behind authentication, and make that the default rather than an option people have to find. Always include an easy way to reschedule or cancel.
Should my healthcare app include a symptom checker?
Be very cautious. Software that influences whether someone seeks care, or that suggests a diagnosis or dosage, can fall under medical device regulation, which brings a different evidence and approval burden. Unless you are prepared for that, leave symptom checking, triage and dosage calculation out and focus on features that move information rather than make clinical judgements.
Do wearables and remote monitoring belong in a healthcare app?
Only where there is a clinical protocol behind them. Monitoring works when a defined condition has a defined response: someone reviews the readings and something happens when a threshold is crossed. Collecting data nobody has agreed to monitor creates a duty to look at it with no process for doing so, which is a clinical risk rather than a feature. Decide who reviews it and when before collecting anything.
Settle Eligibility, Then Build Four Features
Answer the ePHI question, confirm your platform is eligible and get the BAA signed. Then build intake, scheduling with reminders, the portal, and messaging once you know who will answer it. Everything else follows with its own compliance review. If your app would only carry opening hours and contact details, it touches no ePHI and needs none of this, and a website will serve you better. If it does touch patient data, the Enterprise Healthcare Plan is where that work has to happen, and your compliance officer should confirm the fit before any live data moves.
See the HIPAA-Eligible Plan →Healthcare Apps, on Eligible Infrastructure
AES-256 encryption, TLS 1.2+ in transit, access logging and audit controls, with a Business Associate Agreement executed under the Enterprise Healthcare Plan.
See the Enterprise Healthcare PlanSOC 2 Type II | ISO 27001 | BAA execution | 10M+ apps & sites built since 2016
Aasif Khan
Head of SEO and Growth Marketing Lead at Appy Pie AI with 17+ years in digital marketing, AI-powered optimization, and scalable growth strategies.
Abhinav Girdhar
Founder and CEO of Appy Pie AI. Builder of one of the world’s largest no-code and AI platforms, with 10M+ apps and websites created.