Healthcare organizations reported 804 data breaches of 500 records or more to the HHS Office for Civil Rights in 2025, exposing the health records of roughly 138.5 million people. That works out to 2.1 reported breaches a day, and more than 80% of them were hacking incidents rather than lost laptops or misdirected mail. Behind most of those numbers sits software that someone designed, built, and shipped.
Teams starting a healthcare product usually treat HIPAA as paperwork that legal will handle before launch. Then the security questionnaire arrives from the first hospital client, and the answers turn into six months of rework. No authority certifies an app as HIPAA compliant: compliance is a property of the architecture, the vendors, and the process you commit to in the first week of the project. This article covers what HIPAA-compliant app development requires at the code level, in your cloud account, across your vendor contracts, and in the budget, along with the rule change that lands in 2027. If you are scoping a product now, our healthcare software development team runs into these decisions on every build.
HIPAA requirements that apply to an application
The law was written in 1996 for organizations, not for mobile apps, which is why HIPAA-compliant software development begins with interpretation. The requirements read as principles, and translating them into architecture is the work. Before any of it matters, you need to know whether your product falls under HIPAA at all, because a large share of health apps do not.
Protected health information and the apps HIPAA covers
Protected health information is any health data that identifies an individual and is created, received, stored, or transmitted by a covered entity or its business associate. The identifier does not have to be a name: dates of service, device serial numbers, IP addresses, and photographs all count. Both halves have to be present: health information tied to a specific person, held by an organization the law reaches.
Two roles decide your obligations. A covered entity is a healthcare provider, health plan, or clearinghouse. A business associate is any vendor that handles PHI on a covered entity’s behalf, which includes the software house that builds and maintains the app, the cloud provider underneath it, and the SMS gateway sending appointment reminders. If you build for a hospital or an insurer, you are a business associate and HIPAA reaches you directly.
Now the part most guides skip. A fitness tracker, a meditation app, or a symptom diary sold straight to consumers usually sits outside HIPAA, because no covered entity is involved. That does not leave it unregulated. The FTC Health Breach Notification Rule, amended and in force since July 2024, obliges vendors of personal health records to notify users and the FTC after a breach, with civil penalties assessed per violation per day. HHS publishes a decision tool for mobile health app developers that walks through the scope question case by case. Get the determination wrong and HIPAA-compliant app development either eats a year you never needed to spend or fails to start when it should have.
Three safeguard categories, translated into build decisions
The Security Rule groups requirements into administrative, physical, and technical safeguards. Read on their own they sound like policy language. Mapped onto a product, each one turns into a specific deliverable in HIPAA-compliant app development.
| Safeguard category | What the rule asks for | What it means for the build |
|---|---|---|
| Administrative | Risk analysis, workforce training, access management, incident response, contracts with vendors | A documented data flow map, a written access policy that matches the roles in your code, signed BAAs with every vendor touching PHI |
| Physical | Facility access controls, workstation security, device and media disposal | Cloud regions and data centers covered by your provider's BAA, remote wipe for company devices, a policy for test devices holding real data |
| Technical | Access control, audit controls, integrity controls, transmission security | Unique user IDs, automatic logoff, encryption at rest and in transit, append-only audit logs, checksums or versioning on stored records |
Administrative safeguards generate most of the documentation, technical ones most of the engineering, and physical ones mostly resolve into choices about where things run. Teams that skip the administrative column build correct controls they cannot prove to an auditor.
Required versus addressable safeguards, and the 2027 shift
The Security Rule splits technical requirements into required and addressable. Addressable does not mean optional. You either implement the control or document why it is unreasonable in your setting and what you did instead. Encryption of ePHI at rest has sat in that addressable column since 2005, which is how so many organizations ended up with unencrypted databases and a paragraph of justification.
That line is moving. HHS published a proposed overhaul of the Security Rule in the Federal Register on 6 January 2025, removing the addressable category outright. Under the proposal, multi-factor authentication, encryption of ePHI at rest and in transit, network segmentation, a full asset inventory with ePHI data flows, annual penetration testing, vulnerability scanning every six months, and annual compliance audits all become mandatory. Industry pushed back on an estimated $9 billion first-year cost, roughly 5,000 comments landed, and the final rule has slipped from May 2026 to July 2027 on the OMB agenda.
A two-year runway sounds comfortable until you price the alternative. Retrofitting MFA, segmentation, and key management into a live product carrying real patient data is a migration with downtime and a re-validation cycle attached. Building to the proposed requirements today adds a few percent to a HIPAA-compliant app development budget.
The engineering side of HIPAA-compliant app development
Regulation stops at the words "access control" and "encryption". Someone still has to decide which file protection class the iOS app uses, how long a session lasts, and what the audit log writes on each request. This is where HIPAA-compliant app development turns into ordinary, careful engineering with unusually high stakes. HIPAA-compliant mobile app development diverges furthest from the server-side world the rule was written for, because a phone in a patient's pocket breaks assumptions a data center never tested.
Encryption at rest on a phone is weaker than most teams assume
Encryption is the requirement everyone names first and the one most often satisfied in name only. "The operating system encrypts the device" is true and insufficient. On iOS, files written without an explicit protection class default to NSFileProtectionCompleteUntilFirstUserAuthentication, so they stay readable by any process from the first unlock after boot until shutdown. A phone unlocked once in the morning has no file-level protection for the rest of the day. PHI belongs under NSFileProtectionComplete, which reseals data whenever the screen locks, and you have to set it deliberately.
Android needs the same deliberation. Keys belong in the Android Keystore, ideally hardware-backed and gated behind user authentication; files and preferences go through Jetpack Security's EncryptedFile and EncryptedSharedPreferences. A plain SQLite database is not encrypted by anything except full-disk encryption, so local caches of patient records usually call for SQLCipher or an equivalent.
In transit the bar is TLS 1.2 or higher with modern cipher suites, and for a healthcare app it is worth adding certificate pinning so a compromised or corporate-installed root certificate cannot quietly read traffic. Think of full-disk encryption as the lock on the building's front door and file-level protection as the safe in the room. Both matter, and only one of them still works once someone is inside.
Access control, session timeouts, and audit logs
Access control is the part of HIPAA-compliant app development that security reviewers test first, and it has to be enforced where the data lives. Hiding a button in the UI while the API still returns the full record for any authenticated caller is the most common finding in reviews of healthcare products. The "minimum necessary" standard is a server-side filtering rule: a nurse's token returns the fields a nurse is entitled to, and the query itself never selects the rest.
Authentication sits on top of that. Multi-factor is standard practice already and becomes explicit under the proposed rule, while biometrics work best as a convenience gate in front of a token held in the secure enclave or keystore. Automatic logoff is a required specification, typically 10 to 15 minutes of inactivity for clinician-facing tools, longer for patient apps where the trade-off with usability is real.
Audit controls are where products fail investigations. A usable log records who acted, what they did, when, on which record, and from what device or IP, and it is written append-only so nobody can revise history after an incident. HIPAA requires the related documentation to be kept for six years, so plan storage and retention deliberately rather than letting logs roll off after 30 days with the rest of your observability data.
Quiet PHI leaks: notifications, crash logs, and analytics SDKs
The breaches that surprise teams rarely come from broken encryption. They come from PHI taking an unplanned exit through a feature nobody classified as a data path. None of the items below require a bug. They are defaults.
- Push notifications on the lock screen – "Your biopsy results from Dr. Nowak are ready" is a disclosure to anyone glancing at the phone on a desk. Send a content-free notification and load the detail after authentication.
- App switcher snapshots – iOS and Android photograph the screen when an app backgrounds. Obscure the view or blank sensitive screens on
willResignActiveand its Android equivalent. - Clipboard and third-party keyboards – copied record numbers persist and, on iOS, sync across devices through Universal Clipboard; custom keyboards with network access can see everything typed into a field.
- Automatic cloud backups – unless excluded, iOS backs app containers up to iCloud and Android to Google Drive, which moves PHI into a consumer account outside any BAA you signed.
- Crash reporters and analytics SDKs – this is the expensive one. Stack traces routinely carry request payloads, user identifiers, and screen names. Google's BAA covers a defined set of Google Cloud and Workspace products, and Firebase Crashlytics is not among the services offered under it, so a default Firebase setup in a healthcare app quietly ships diagnostics containing PHI to a processor with no agreement in place.
One exercise catches all of them: list every place data can leave the device or the process, then check each exit against your vendor agreements. Run it as a standing item in HIPAA-compliant mobile app development, once before launch and again whenever an SDK is added. Most teams find at least one uncovered path on the first pass, and the crash reporter is usually it.
Infrastructure, vendors, and the BAA chain
Your obligations do not stop at the edge of code you wrote. HIPAA follows PHI wherever it goes, which makes vendor selection as much a part of HIPAA-compliant app development as the architecture diagram. The business associate agreement is the instrument that carries the obligation down the chain, and anyone setting out to build a HIPAA-compliant app on managed services inherits every gap left in one.
The HIPAA-eligible subset of AWS, Azure, and Google Cloud
All three major clouds will sign a BAA, and all three limit it to a named list of services. AWS publishes that list of HIPAA-eligible services, which passed 200 entries in its September 2026 update, along with a clear condition: customers "agree not to use these HIPAA Eligible Services for any purpose or in any manner involving Protected Health Information without first entering into an AWS business associate agreement". The account-level rule is simple. Services outside the list may run in the same account, as long as no ePHI reaches them.
| Layer | Question to settle before the build |
|---|---|
| Compute and containers | Is the runtime on the eligible list, and are instances in a region the BAA covers |
| Database and storage | Encryption with customer-managed keys, backup location, retention policy |
| Queues, jobs, and events | Does a message body carry PHI, and if so is the broker eligible |
| Push notifications | Notification payload content, and whether the push service is under the BAA |
| Monitoring, logging, tracing | Log scrubbing rules, retention, and whether the vendor signs a BAA at all |
| Email, SMS, and video | Eligible product tier, since several vendors offer HIPAA support only on higher plans |
The monitoring row causes the most friction in practice. Observability tools are built to capture everything, PHI included, and the fix is a scrubbing layer at the source rather than a promise to be careful in the code.
Signing BAAs down the whole vendor chain
A BAA obliges a vendor to protect PHI, report breaches to you, and impose equivalent terms on its own subcontractors. You need one with every party that can see the data, and the list is longer than it looks: cloud provider, error tracking, product analytics, transactional email, SMS gateway, video calling, customer support desk, log storage, and any offshore development partner with access to a production database.
Three questions settle most vendor evaluations quickly. Will you sign a BAA, and on which plan? Which of your products does it cover? Where is the data stored and who are your subprocessors? A vendor that answers the first question with a link to a SOC 2 report has answered a different question.
Running HIPAA and GDPR at the same time
Products with users on both sides of the Atlantic get two regimes at once, and they do not align neatly. GDPR grants a right to erasure while HIPAA and state medical record laws require retention measured in years, so a deletion request has to separate a marketing profile from a clinical record. GDPR's lawful basis and data minimization point the same way as HIPAA's minimum necessary standard through different documentation. A data processing agreement is not a BAA, and signing one does not give you the other.
Residency has the longest tail. EU patient data hosted in a US region invites a transfer analysis you will have to defend, while US data hosted in Frankfurt adds latency and, in some hospital procurement processes, questions. Settling it after the first production deployment turns into a data migration. We build to GDPR requirements as a baseline on every healthcare project, so HIPAA-compliant app development for both markets is the normal case on our side.
Process, budget, and partner selection
HIPAA-compliant app development changes the shape of a project more than its total cost. Work moves to the front, testing gets an extra cycle, and a set of recurring obligations continues for as long as the product is live. Budgeting for the build alone is how teams end up unfunded in year two.
HIPAA-compliant app development starts before the first line of code
The security risk analysis opens every HIPAA-compliant app development project, and it is the failure OCR cites most often in its enforcement actions, to the point that the agency runs a dedicated Risk Analysis Initiative targeting it. The analysis produces an inventory of where ePHI lives, moves, and is exposed, with a rated threat and a written mitigation against each point.
- Map the data flows – every screen, endpoint, queue, log, and third party that touches PHI, drawn before architecture is fixed.
- Decide what you genuinely need to store – data you do not hold cannot leak, and dropping two fields sometimes removes a whole system from scope.
- Rate the risks – likelihood and impact for each exposure point, with the mitigation and the residual risk written down.
- Choose the vendors – confirm BAA availability and covered products before anything is wired in, because replacing an SDK after launch means a data migration.
- Write the policies the code will have to match – access roles, retention periods, incident response, and breach notification, so the implementation has a specification to follow.
Two to three weeks of this ahead of development is normal, and it is the cheapest phase of the project to be thorough in.
Compliance overhead in budget and timeline
Compliance adds roughly 15% to 25% to a healthcare build compared with the same feature set without it, which tracks with the ranges in our breakdown of what healthcare software development costs. At our rates of $25 to $60 an hour, the increment usually reads as several weeks of senior time spread across risk analysis, key management, audit logging, the access control layer, and a longer security test cycle.
The recurring costs of HIPAA-compliant app development are the ones that get missed:
- An updated risk analysis whenever the product changes materially, and at least annually once the proposed rule takes effect.
- A penetration test by an external security firm. Priced per engagement, separate from your QA budget, and worth scheduling before a big client asks whether you have one.
- Vulnerability scanning, dependency monitoring, and the patching work that follows.
- Staff training, policy reviews, and the security questionnaires that arrive with each new enterprise client. Answering those well takes senior engineering time, and it repeats with every deal.
Getting it wrong is priced too. Breaches affecting 500 or more people must be reported to HHS and the affected individuals within 60 days. Civil penalties run across four tiers adjusted annually for inflation, from $145 per violation for genuine ignorance up to $2,190,294 per year in the willful neglect tier under the figures published in January 2026. Change Healthcare, still the largest health data breach on record, affected 192.7 million people, and the remediation bill dwarfed any penalty.
Choosing a development partner for a HIPAA project
Ask a prospective partner what they have built under these constraints, then ask how. The useful answers are specific: which cloud services they ran PHI through, how they handled key management, what their audit log records, how they kept crash diagnostics clean. Our healthcare work includes web platforms and backend APIs for a US digital health provider processing patient data, among them the Vheda Health web platform, plus a patient-facing mobile app with over 40 features and eight integrated medical devices for a provider we do not name publicly. We run healthcare infrastructure on AWS in a HIPAA-eligible configuration, handle QA and security-focused code review in house, and bring in specialist firms for penetration testing.
Device-heavy products deserve an extra conversation, since readings arriving over Bluetooth from a patient's home create data paths the Security Rule never anticipated. We wrote separately about connecting medical devices to a healthcare app if that is part of your scope. The partner question is a liability question: under HIPAA a breach caused by your development vendor is still your breach to report, so diligence before signing is the cheapest control you will ever buy. Our questions to ask before hiring an app developer work as a starting checklist for any HIPAA-compliant app development engagement, and the compliance questions sit on top of them.
FAQ
Search results for HIPAA and software throw up the same handful of questions. Short answers to each, with the detail that usually gets left out.
Can an app be HIPAA compliant?
An app can be built and operated so that it meets HIPAA requirements, but no government body or private auditor issues a HIPAA certification. Vendors selling "HIPAA certified" products are describing a third-party assessment against a framework, which is useful evidence and carries no legal status. In HIPAA-compliant app development, compliance belongs to the whole system: the app, the infrastructure, the contracts, and the organization operating it.
How much does it cost to build a HIPAA-compliant app?
HIPAA-compliant app development typically adds 15% to 25% on top of an equivalent non-regulated build, spread across risk analysis, encryption and key management, audit logging, access control, and a longer security testing cycle. For a patient-facing mobile app with a backend, that usually means a mid five-figure increment in dollars, though the total depends far more on feature scope and integrations than on HIPAA itself. Budget separately for the annual line: risk analysis updates, penetration testing, and training.
How can I develop a HIPAA-compliant app?
Sequence matters more than any single control, because the early choices are the expensive ones to reverse. A working order for HIPAA-compliant app development:
- Confirm whether HIPAA applies at all, or whether the FTC Health Breach Notification Rule governs your product instead.
- Run a security risk analysis and map every path PHI takes through the system.
- Pick vendors that will sign a BAA covering the specific products you intend to use.
- Build the technical safeguards into the first release rather than a later hardening sprint.
- Set up the recurring obligations: audits, log retention, breach response, and annual review.
The mistake to avoid is treating step one as a formality. Scope determines the other four, and teams that guess at it usually guess expensively.
Is there an AI app that is HIPAA compliant?
Yes, and in HIPAA-compliant app development the deciding factor is the agreement with the model provider rather than the model itself. The major cloud AI services will cover their inference endpoints under a BAA on the appropriate tier, while consumer chat products generally will not, which makes pasting patient notes into a public assistant a disclosure. Teams that want to avoid the question entirely de-identify data before it reaches the model, using the Safe Harbor method or expert determination, though that limits what clinical features you can offer.
Does a fitness or wellness app need to be HIPAA compliant?
Usually not, as long as it is sold directly to consumers and no covered entity is involved. The moment a clinic, hospital, or health plan uses your app to manage its patients or members, you become a business associate, HIPAA applies in full, and the roadmap turns into HIPAA-compliant app development from that day. Consumer health apps outside HIPAA still answer to the FTC Health Breach Notification Rule and to state laws such as Washington's My Health My Data Act, which allows consumers to sue directly, so the practical exposure is comparable even when HIPAA is absent.
Can a no-code app builder be HIPAA compliant?
Several no-code and low-code platforms offer HIPAA support, and a few will sign a BAA, though almost always on an enterprise plan. Before committing, check three things:
- Whether the BAA covers the hosting, database, file storage, and notification components your build depends on.
- Whether you can control encryption keys, session timeouts, and audit log retention rather than accepting platform defaults.
- What the migration path looks like if you outgrow the platform, since exporting an application is harder than exporting its data.
These platforms fit internal tools and simple patient-facing workflows well. Products with device integrations, complex role models, or EHR connections tend to hit the ceiling early, at which point the work moves to custom HIPAA-compliant software development anyway.
