Where HIPAA app builds go wrong

What does HIPAA compliant app development actually require?

HIPAA compliant app development requires four layers to hold at once: a Business Associate Agreement signed with every vendor that touches protected health information, technical safeguards written into your own code, administrative controls including a documented risk analysis, and infrastructure controls inherited from a HIPAA eligible host. Three out of four is not compliance. It is a finding waiting to be written up.

There is no HIPAA certificate and no pre-launch inspection. Compliance is a position you have to evidence on the day the Office for Civil Rights asks, which makes the paperwork as load bearing as the code: the risk analysis, the vendor register, access review records, the breach runbook. Teams that schedule those for launch week discover that the evidence was supposed to have been accumulating for months.

That is the environment the app ships into. Hacking or IT incidents caused 81% of all reported breaches that year, and OCR collected $9,944,612 in HIPAA penalties across 2024, of which $7,813,831 came from breach investigations.¹

Which HIPAA app requirements are mandatory, and which are addressable?

The Security Rule splits its technical safeguards (45 CFR 164.312) into required and addressable implementation specifications. Addressable does not mean optional. It means you either implement the control or document why an equivalent alternative is reasonable for your environment. Most teams that skip an addressable control never write that justification, and the justification is what an investigator asks for first.

Encryption sits in the addressable column as the rule reads today. HHS published a Security Rule update proposal on 06-Jan-2025 that would delete the required and addressable distinction entirely and make encryption mandatory, and that proposal has since moved to a long-term agenda targeting Jul-2027. The practical read for anyone building now is to treat encryption as required. If the rule finalises, you re-architect nothing.

Documentation under the Security Rule has to be retained for six years, which is a storage and query design decision rather than a filing decision. An audit log you cannot search across that horizon is not an audit log.

Do you need a BAA with AWS, Firebase or your LLM provider?

Yes, with each of them separately, and the signature is where the work starts rather than where it finishes. AWS, Azure and Google Cloud will sign a Business Associate Agreement and publish a list of HIPAA eligible services. Under the shared responsibility model that covers their half. Session handling, role based access control, audit logging and the data model stay entirely with the app team.

A cloud BAA tells a regulator who is responsible for the hypervisor. It says nothing about who is responsible for your session tokens.

Two failure modes recur. The first is running on a provider that will sign a BAA while using a service outside its HIPAA eligible list, which is easy to do with newer managed features. The second is assuming one agreement covers a chain: analytics SDK, crash reporter, transactional email and SMS delivery, EHR integration middleware, model API. Each needs its own agreement in place before PHI reaches it. Building that vendor register during discovery costs an afternoon; reconstructing it during an investigation costs considerably more, which is why it belongs in the first sprint of any product engineering programme rather than in a pre-launch scramble.

Where does PHI actually leak in a mobile app?

Rarely the database. In a PHI mobile app, the database is the one asset everybody remembers to encrypt. The leaks come from the places health data travels incidentally.

• Application logs. Verbose errors and request or response logging capture identifiers, payload bodies and sometimes whole records in plaintext. Scrub at the logger, not at the aggregator, because by then the data has already crossed a boundary.
• Crash reporting and analytics SDKs. Third party SDKs send breadcrumbs, screen names and user properties off device by default. A screen name such as PatientChart-oncology is identifying in context even with no name attached to it.
• Push notifications. Payloads render on a locked screen and pass through a delivery provider you very likely have no BAA with. Send an opaque identifier and fetch the content inside the authenticated app.
• Device caches and backups. Task switcher screenshots, WebView caches, unencrypted local stores and cloud device backups all persist PHI in places outside your control.
• URLs and query strings. A record identifier in a path lands in proxy logs, referrer headers and browser history, none of which are covered by your encryption story.

None of these appear on a standard compliance checklist, and all of them turn up routinely in security review. A PHI scrubbing rule in the logging middleware plus a strict allowlist for SDK telemetry closes most of the exposure for about a day of engineering.

Is using AI inside a healthcare app a HIPAA violation?

Not by definition. It becomes one when PHI reaches a model provider with no BAA in place, or when a staff member pastes a record into a consumer chatbot. Both are common. In a 2025 survey of healthcare IT leaders, 62% had observed staff using unsanctioned ChatGPT at work while 94% felt confident they would detect AI misuse before it caused a HIPAA violation.⁷ Those two numbers cannot both be true.

Attackers are moving on the same curve. 16% of breaches in 2025 involved attackers using AI, and among organisations that suffered an AI related security incident, 97% lacked proper AI access controls.³

Three rules keep an AI feature inside the line. Sign a BAA with the model provider specifically, because a cloud BAA does not extend to a connected model API even when both sit with the same vendor. De-identify before the call wherever the feature allows it, by stripping the 18 identifiers rather than trusting a prompt instruction to behave. And log every model call as a PHI access event, with actor, purpose and payload class, so the audit trail survives the question of what the model saw. That governance design belongs in the same backlog as the feature, not in a later phase of AI consulting work.

What if your app is not a covered entity?

Then HIPAA may genuinely not apply, and a second regulator steps in. The updated FTC Health Breach Notification Rule took effect on 29-Jul-2024 and reaches consumer health, fitness and wellness apps that sit outside HIPAA jurisdiction. It has teeth. The FTC fined GoodRx $1.5 million on 01-Feb-2023 in its first action under the rule, for sharing user health data with Facebook and Google without consent.⁵ BetterHelp was required to pay $7.8 million to consumers for sharing mental health data with third parties for advertising retargeting without proper consent.⁶

This matters more each year because more products drift into the category. The mHealth apps market was valued at $40.65 billion in 2025 and is projected to reach $113.2 billion by 2034, an 11.80% compound annual growth rate.⁸ Plenty of that growth comes from teams who did not set out to build a regulated product. If the app collects health data and shares any signal with an ad platform, the consent and disclosure review is not optional, whatever the HIPAA analysis says.

What does HIPAA compliant app development cost, and what does a breach cost?

Published cost ranges for these builds span an order of magnitude, which makes them nearly useless without a scope definition. The more answerable question is which line items are additive to a normal product build, because those are the ones that get left out of the estimate.

The recurring cost is the one that gets missed. Compliance is an annual operating expense, not a project line, and the annual portion tends to be a meaningful fraction of the original build once testing, log retention, access reviews and vendor renewals are counted.

Against that, the downside case. The average healthcare data breach cost $7.42 million in 2025, down from $9.77 million in 2024 and $10.93 million in 2023, though healthcare has still been the costliest industry for fifteen consecutive years.³

Detection is where the money goes. Healthcare organisations stay in the dark longer than any other sector, and the gap is not marginal.

That gap is an argument for audit logging you can actually query. A team that can answer which records were accessed, by whom and when, closes an incident in days rather than months, and the notification scope shrinks with it.

Ransom economics moved sharply in the other direction. Average demands against healthcare providers fell 91% to $343,000 in 2025 from $4 million in 2024, and the average payment fell to $150,000 from $1.47 million.⁴ Smaller demands are not good news on their own. They point to higher volume attacks aimed at smaller providers and vendors, which is precisely where a single under-secured app sits.

How to build a HIPAA compliant app, in order

The sequence matters more than the checklist, because several of these decisions are cheap in week one and expensive in month nine.

1. Draw the PHI boundary first. List every field, every service that reads it and every place it leaves your system. Anything outside the boundary should be provably de-identified rather than assumed to be.
2. Run the risk analysis before the architecture is fixed. It is a Security Rule obligation and, done early, it is also the cheapest design review you will get.
3. Sign BAAs before integration. Not before launch. A vendor that will not sign is a vendor you have to design around, and finding that out late reopens the architecture.
4. Build audit logging as a product feature. Give it a schema, an owner and a query interface. Retrofitting it after an incident is not possible.
5. Scrub PHI at the source of every log and telemetry stream. Logger middleware, SDK allowlists, opaque push payloads, no identifiers in URLs.
6. Test independently, then again after material change. Penetration testing plus a refreshed risk analysis whenever the data model or a vendor changes.

Retrofitting an existing app is possible, and the honest framing is that the cost tracks how far PHI has already spread. If it lives in one service behind one auth layer, the work is contained. If identifiers are in logs, analytics, notification payloads and three third party tools, the data flow rework will look a lot like a rebuild. Telehealth products carry an extra layer here, because video sessions, waiting rooms and scheduling metadata all count; our primer on what telehealth covers maps that surface area. If you want a second opinion on a PHI boundary before it hardens into code, start a conversation.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.