If you run a clinic group, a home-care business or a company that serves health plans, a new app can save your staff hours and give patients a better experience. It also brings a question your lawyer will ask on day one: does the app have to meet HIPAA? HIPAA compliant app development starts with answering that honestly, then building the safeguards in from the first sprint rather than adding them before launch.
This guide is written for the owner who signs off the project, not the engineer. It is general information as of April 2026, not legal advice. Have your healthcare counsel confirm how the rules apply to you.
Step one: does HIPAA apply to your app at all?
HIPAA applies to "covered entities" (health care providers that bill electronically, health plans and clearinghouses) and to their "business associates": anyone who creates, receives, maintains or transmits protected health information on their behalf.
The deciding question is who the app works for. HHS guidance for app developers puts it plainly: if you only offer services directly to consumers, and not on behalf of a provider, health plan or clearinghouse, you are not likely to be subject to HIPAA as either a covered entity or a business associate.
Your situation | HIPAA likely applies? | What else to check |
|---|---|---|
A clinic's own patient app for bookings, records or messages | Yes. The clinic is a covered entity and its developers and hosts are business associates | State privacy laws |
An app you build and sell to providers or health plans, holding their patients' data | Yes. You are their business associate | Each customer's contract terms |
A wellness or tracking app sold straight to consumers, with no provider involved | Probably not | The FTC Health Breach Notification Rule and the FTC Act |
A consumer app that receives a patient's records at the patient's own request | Usually not, once the data is in the app | FTC rules and your own privacy promises |
"Not HIPAA" does not mean "no rules." In April 2024 the FTC finalized changes to its Health Breach Notification Rule that make clear it covers health apps and similar technologies outside HIPAA, including breaches caused by unauthorized sharing of data, not only hacks.
The paperwork that comes before the code
Business associate agreements
Every outside party that handles protected health information for you needs a business associate agreement (BAA). That usually includes your development partner, your cloud host, and any service that stores or processes the data: messaging, email, analytics, backups, AI services.
Before you approve any third-party service in the app, ask one question: will this vendor sign a BAA for this use? If not, the service shouldn't touch patient data.
A risk analysis
The HIPAA Security Rule expects a documented assessment of the risks to electronic health information and the measures you take against them. For a new app, this belongs in the design phase. It shapes decisions about where data lives, who can see it and what gets logged.
Safeguards to require in HIPAA compliant app development
The Security Rule describes outcomes more than specific technology. In practice, these are the safeguards a well-built healthcare app should have. Ask your development partner how each one will be handled, and ask to see it working.
Access by role. A receptionist, a nurse and a billing clerk see different things. Every user has their own login.
Strong sign-in. Multi-factor authentication for staff, and automatic logout on shared devices.
Encryption of data in transit and at rest, including backups and data cached on phones.
Audit logs showing who viewed or changed which record, and when, kept where users can't edit them.
Minimum necessary data. The app collects and shows only what each task needs. Less data held means less to lose.
No health data in the wrong places: not in push notification text, not in crash reports, not in third-party analytics or advertising tools.
Backups and recovery that are tested, with a known time to restore.
A release process where security fixes ship quickly and no change goes live without review.
Build and test without real patient data
Developers rarely need real patient records to build or test an app. Ask for a setup where development and testing run on made-up data that looks realistic, and real data lives only in the production system.
That one decision shrinks your risk a great deal. Fewer people and fewer systems ever touch protected health information, so there are fewer places for it to leak and fewer agreements to manage. When someone does need to look at production, for example to fix a fault a patient reported, that access should be requested, approved by a named person on your side, time-limited and logged.
Changes on the horizon
In December 2024 HHS proposed the first major update to the Security Rule in years. The proposal would, among other things, require encryption of electronic health information at rest and in transit and multi-factor authentication (each with limited exceptions), a written technology asset inventory and network map, vulnerability scans at least every six months and penetration tests at least once a year.
As of this writing the update is still a proposal, not final law. Building to it anyway is sensible. Most of it is good practice, and an app designed to meet it won't need rework if and when it becomes binding.
If something goes wrong
Plan the breach response before launch. Under the HIPAA Breach Notification Rule, covered entities must notify affected individuals without unreasonable delay and no later than 60 days after discovering a breach. Breaches affecting more than 500 residents of a state or jurisdiction also require notice to prominent local media, and breaches of 500 or more people must be reported to HHS within the same window.
Your app and your partner's contract should support that: logs good enough to tell who was affected, a named contact, and an agreed time within which your developer tells you about an incident.
Questions to ask a development partner
Will you sign a BAA, and do you have BAAs with the services you plan to use?
Where will the data live, and in whose cloud account? (It should be yours.)
Who on your team can reach production data, and how is that access logged?
How do you keep health data out of notifications, logs and analytics?
How do you test security before each release?
What happens to the code, data and access if we stop working together?
Be careful with any vendor that calls itself "HIPAA certified." HHS states that it does not endorse or recognize private certifications for the Security Rule. Compliance is something your organization does and documents, every day the app runs.
Frequently asked questions
Can an offshore team build a HIPAA compliant app?
HIPAA doesn't prohibit it. What matters is the BAA, the safeguards and how access is controlled. A common setup keeps all patient data in your own US-hosted cloud account, with developers working on test data and production access limited, logged and approved by you. Some health plans and government contracts add their own location rules, so check yours.
Is a HIPAA compliant app more expensive to build?
It costs more than an app with no safeguards, mainly in design, testing and documentation. It costs far less than adding the safeguards after launch, which often means reworking how data is stored and shared.
Do mobile apps and web apps follow different rules?
The rules are the same. The risks differ: phones get lost, cache data and send notifications to lock screens, so mobile apps need extra care with what is stored on the device and shown without a login.
Can we use AI features with patient data?
Only through services that will sign a BAA for that use and handle data under its terms. Treat an AI service like any other vendor that touches protected health information.
Where to start with HIPAA compliant app development
Our team builds mobile apps and web applications for operations-heavy firms, including healthcare businesses, with code and data in your own accounts and every release approved by you. If you're planning a healthcare app and want a second opinion on scope and safeguards, book a 30-minute call with a founder. Bring your counsel's questions too.
