How to build a HIPAA compliant app
An engineering checklist for apps that handle PHI: which infrastructure you can use, the Security Rule's technical safeguards in product terms, and the places PHI leaks in most codebases.
On this page
How to build a HIPAA compliant app at a glance
Building a HIPAA compliant app means meeting the Security Rule's safeguards in your product and infrastructure, not adding a badge. In practice: use only services covered by your vendors' BAAs; give every user a unique login with strong authentication; encrypt ePHI in transit and at rest where reasonable and appropriate (encryption is addressable); log access to ePHI without writing PHI into general logs; back up and test restores; and support deleting or returning customer data. Add a documented risk analysis, policies, and BAAs with covered-entity customers and qualifying vendors.
| Applies when | Your app handles PHI as a covered entity or business associate |
|---|---|
| Infrastructure | Only BAA-covered services from cloud, email, AI and support vendors |
| Technical safeguards | Access control, audit controls, integrity, authentication, transmission security (164.312) |
| Encryption | Addressable in the rule; in practice expected in transit and at rest |
| Often missed | PHI in logs, error trackers, analytics and test environments |
| Not available | HIPAA certification for an app |
First make sure HIPAA applies — the health app startup page covers that. If it does, the Security Rule’s safeguards become product requirements. The rule is technology-neutral and scaled to your risk; the checklist below is how most teams translate it.
1. Infrastructure under BAAs
Cloud providers’ BAAs cover named services only. Before you use a database, queue, storage bucket, email service or AI model with PHI, confirm it is on the vendor’s covered list and the BAA is signed. Compare HIPAA hosting and AI and LLM tools.
2. Technical safeguards in product terms
| Security Rule (164.312) | In your product |
|---|---|
| Access control — unique user IDs (required), automatic logoff, encryption (addressable) | One account per person, role-based permissions, session timeouts |
| Audit controls (required) | Record who viewed, changed or exported ePHI; keep the logs protected |
| Integrity | Prevent and detect improper changes — validation, checksums, change history |
| Person or entity authentication (required) | Strong sign-in; we recommend MFA for clinician and admin users |
| Transmission security | TLS everywhere, including internal services and webhooks |
See access control, audit controls and encryption.
3. Where PHI leaks
These are the places teams most often find PHI they didn’t plan for:
- Application logs, error trackers and APM traces that capture request bodies.
- Product analytics and session replay — see online tracking.
- Push notifications and email subjects that show health details.
- Support tickets, screenshots and screen-sharing tools.
- Development, staging and test environments loaded with production data.
- Prompts and responses sent to AI APIs outside BAA-covered endpoints.
4. Backups, recovery and deletion
The contingency plan standard requires data backup, disaster recovery and emergency-mode operation plans (164.308(a)(7)). Test restores. When a customer leaves, your BAA will require you to return or destroy their PHI where feasible (164.504(e)(2)(ii)(J)) — build export and deletion in from the start.
5. The paperwork that goes with the code
A documented risk analysis, written policies, workforce training and BAAs with customers and vendors. Customers will check these through security questionnaires.
Next steps
- HIPAA for health app startups →Scenario
- HIPAA for SaaS companies that are business associates →Scenario
- HIPAA hosting and cloud platforms →Tool
- AI tools and LLMs →Tool
- Encryption of ePHI →Requirement
- Access control and sign-in →Requirement
- Audit controls and activity logs →Requirement
- Security risk analysis →Requirement
- Business associate agreements (BAAs) →Requirement
- De-identification →Requirement
Frequently asked questions
Is there a HIPAA certification for apps?
No. HHS does not certify software. You show compliance through your risk analysis, safeguards, policies and BAAs; customers may also ask for SOC 2 or HITRUST reports.
Can we use real patient data in development or testing?
HIPAA doesn't forbid it, but every environment holding PHI then needs the same safeguards and BAA coverage. We recommend synthetic or de-identified data outside production.
Do mobile apps need to encrypt data on the device?
Encryption is addressable, so you decide based on your risk analysis — but lost phones are a common breach cause, and properly encrypted data is not 'unsecured PHI' for breach notification. We recommend it.