How to Build a HIPAA Compliant App in 2026: An Engineering Guide

First: does HIPAA apply to your app?

Health data alone doesn't trigger HIPAA. Who you are and who you work for does. Three questions decide it:

1. Are you a covered entity? Healthcare providers that bill electronically, health plans and clearinghouses are.
2. Do you handle PHI on behalf of one? Then you are a business associate, with direct obligations under HIPAA.
3. Is the data identifiable? Properly de-identified data is not PHI.

The answers put you in one of four positions:

One more thing to clear up early: there is no HIPAA certification. HHS doesn't certify apps or vendors. Compliance is a set of safeguards, documents and agreements you keep up over time, and anyone selling a "HIPAA certified" badge is selling a third-party opinion.

How to build a HIPAA compliant app, step by step

Nine steps. The first three are paperwork that shapes the code, so they start in week one.

1. Map every PHI flowDraw where health data enters, where it is stored, who sees it and where it leaves: the EHR, a lab, a pharmacy, an email. Mark every vendor on the diagram. This map is the input for everything else.
2. Run a security risk analysisThe Security Rule requires one. List the threats to each flow, how likely they are and how bad they would be, and decide how you'll reduce each risk. Repeat it when the system changes, and at least once a year.
3. Sign BAAs before any PHI movesCloud, database, email, SMS, video, support desk, error tracking, AI APIs. If a vendor won't sign, it doesn't get PHI. Plan for higher plan tiers: many vendors only sign on business or enterprise plans.
4. Design access controlUnique accounts for every person, MFA for staff, roles with the minimum access each job needs, an emergency access procedure, and automatic logoff after inactivity.
5. Build audit logging into the first featureEvery read, create, update and delete of PHI records who, what, when and from where. Write logs to an append-only store that app admins can't edit.
6. Encrypt and back upTLS for every connection, encryption at rest for databases, files and backups, keys in a managed key service. Restore a backup to a clean environment before launch and write down how long it took.
7. Seal the leaksCheck push notifications, logs, analytics events, crash reports, emails and support tickets for PHI. This is where most real-world exposures happen. More below.
8. Write the policies and train the teamAccess reviews, incident response, device rules, workforce training and sanctions. Keep them short enough that people read them, and keep the records for six years, as HIPAA's documentation rule requires.
9. Test, then prove itRun a penetration test on the apps and the API, fix the findings, and keep the report. Hospital customers will ask for it, along with your risk analysis summary.

The Security Rule, translated into engineering

The Security Rule groups its safeguards into administrative, physical and technical. Some are "required" and some "addressable", which means you implement them or document why an equivalent measure is reasonable. In practice, teams building new apps implement nearly all of them.

HHS proposed an update to the Security Rule in January 2025 that would make most safeguards mandatory, including encryption and MFA. Whatever its final form, a new app should be built as if it applies.

What you rent under a BAA and what you build

You can rent most of the infrastructure from vendors that sign BAAs. Signing the BAA doesn't make you compliant: you still configure and use the service correctly.

Where PHI leaks in real apps

Breaches in health apps rarely start with a hacker breaking encryption. They start with data going somewhere nobody thought about. Check each of these:

• Push notifications. Apple's and Google's push services aren't covered by your BAAs, and the text shows on locked screens. Send "You have a new message", never a diagnosis, drug or test name.
• Application logs. A debug line that prints a request body puts PHI into your logging service. Log IDs, scrub payloads, and make sure the logging vendor signs a BAA anyway.
• Analytics and ad SDKs. HHS guidance on tracking technologies and FTC enforcement against health apps both point the same way: pixels and SDKs that send health details or screen names to third parties are a disclosure. Event names like "viewed_hiv_results" count.
• Crash reports. They capture screen state and sometimes memory. Configure scrubbing, or use a reporting service under a BAA.
• Email and SMS. Links to the app are fine; results in the body are not, unless the patient asked for it and you documented the request.
• The device itself. PHI cached unencrypted, sensitive screens visible in the app switcher, tokens in plain preferences. Use the Keychain or Keystore and blur sensitive screens.
• Developer and test environments. Copies of production data on laptops or in staging. Use synthetic data outside production.

Building a HIPAA-compliant AI healthcare app

AI features add new places for PHI to land: prompts, outputs, embeddings, fine-tuning sets and evaluation logs. The rules don't change, the surface does.

• BAA for the exact service. Several major AI and cloud providers sign BAAs for selected API products and configurations, often with zero data retention. Consumer chat apps are not covered.
• Treat AI data as PHI. Vector databases, prompt logs and model outputs get the same access control, encryption and audit logging as your main database.
• Minimum necessary. Send the model only the fields the task needs. A summary of today's visit doesn't need the patient's address.
• Human review for clinical content. Generated notes, letters or triage suggestions need a clinician's sign-off. If the AI diagnoses or recommends treatment, FDA device rules may apply. Our guide on how to build a medical app covers that question.

Breach notification: plan it before you need it

If unsecured PHI is exposed, the HIPAA Breach Notification Rule sets the clock. Covered entities notify affected individuals without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more people also go to HHS and, when 500 or more residents of a state are affected, to the media. Smaller breaches are reported to HHS yearly. Business associates notify the covered entity.

Encryption that meets HHS guidance is your best protection here: data rendered unreadable to unauthorized people is generally not "unsecured", so a lost encrypted laptop is usually not a reportable breach. Consumer apps under the FTC rule have their own notification duties to users, the FTC and, for larger breaches, the media.

For the app team, that means an incident runbook, logs good enough to tell who was affected, and a named person who decides.

What goes into the first version

A compliant MVP doesn't need every enterprise control. It needs the ones that are hard to add later.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Retail · Startup700+stores aggregatedMobile application for Grocery shops→Food delivery3.5 moto MVP launchOptimizing and controlling delivery for a Pizzeria Chain→EdTech4 moto a full iOS app on the App StoreA mobile app to develop brain functions→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Timeline and budget at a glance

The yearly figure covers BAA-tier hosting and vendors, an annual risk assessment and a penetration test, on top of the usual 15–20% of the build for maintenance. See the healthcare app development cost guide for the full breakdown, and the telemedicine app development cost guide if your product includes virtual visits.

Mistakes that cost the most later

• Picking vendors before checking BAAs. Replacing an analytics, email or auth provider after launch means a migration. Ask about the BAA in the first sales call.
• Using services the BAA doesn't list. Cloud BAAs cover specific services. A new managed service turned on by a developer may not be one of them.
• Audit logs left for the week before the first hospital deal. Retrofitting logging touches every endpoint, and you can't reconstruct who saw what last year.
• Health details in analytics events. Screen names and event names are data too. Rename them before they leave the app.
• Backups never restored. A backup you haven't restored is a guess. Test it, time it, write it down.
• "HIPAA certified" on the website. There is no such certification, and hospital security teams know it. Describe your safeguards instead.

HIPAA readiness checklist

Tick what is already true for your app. It shows how far you are from handling real patient data.

FAQ

Where Gilzor fits

We build healthcare web and mobile apps, backends and integrations, and run QA and app audits. For a US blood testing laboratory, our team built native apps for patients, doctors and phlebotomists and worked with US attorneys on HIPAA authorization and the EULA. We don't claim a HIPAA certification, because none exists; we design the safeguards in from the first sprint. We work from Poland and Cyprus, with a few shared hours a day with the US East Coast.

Send us your PHI flow, even a rough sketch, and your current vendor list. We'll mark where the data goes, which agreements are missing and which safeguards belong in the first version.