HIPAA compliance is not a certification you obtain. It is a set of administrative, physical, and technical safeguards you implement and can evidence. No authority certifies an app as HIPAA compliant. Any vendor selling you a "HIPAA certification" is selling something that does not exist, and that is the first thing to know before you spend money.
This is an engineering guide to what actually has to be in a health application: which safeguards translate into which code and infrastructure decisions, what it adds to a build, and the mistakes that produce breaches. It is written for founders and product teams building patient-facing or provider-facing software. It is not legal advice, and your specific use case should go past healthcare counsel.
First: are you actually covered?
Many health apps are not subject to HIPAA at all, and many teams spend money as though they are.
| Situation | HIPAA applies? |
|---|---|
| App used by a clinic, hospital, or insurer to handle patient data | Yes, you are a business associate |
| You process claims, billing, or clinical records for a provider | Yes |
| Consumer wellness app, user enters their own data, no provider involved | Usually no |
| Consumer app that syncs data to a provider | Yes, at the point it touches the provider |
| You store PHI for a covered entity as a hosting or SaaS vendor | Yes, and you need a BAA |
Two important caveats. First, if HIPAA does not apply, state law frequently does. Washington's My Health My Data Act, Texas, and several EU regimes cover health data outside HIPAA's scope, and some are stricter. Second, the FTC's Health Breach Notification Rule reaches consumer health apps that HIPAA does not. "HIPAA does not apply" is not the same as "no obligations."
Note also what counts as PHI. Health data plus any of 18 identifiers, which includes names, dates, device identifiers, IP addresses, and full-face photographs. A photo of a rash with an EXIF timestamp and device ID is PHI.
The technical safeguards, translated into engineering
Access control
- Unique user identification. No shared accounts, ever, including for clinical staff.
- Role-based access enforced server-side. Roles must map to real clinical functions, not "admin" and "user".
- Minimum necessary access. A billing clerk should not be able to query clinical notes. This is the requirement most commonly failed, because generic RBAC does not express it.
- Automatic logoff after inactivity. Fifteen minutes is the common standard.
- Emergency access procedure, sometimes called break-glass: a documented, heavily logged path for urgent access.
Audit controls
You must record who accessed which patient's record, when, and what they did. Immutable, timestamped, retained six years. This is not optional and it is not application logging.
Practical consequence: every read of PHI is an audited event, not just every write. That is the detail teams miss, and retrofitting read-auditing into a mature application is one of the most expensive changes in this entire domain.
Integrity
PHI must not be improperly altered or destroyed. In practice: append-only clinical records with amendments recorded as new versions rather than overwrites, checksums on stored files, and no hard deletes of clinical data.
Transmission security
TLS 1.2 or higher everywhere, including internal service-to-service traffic. Certificate pinning on mobile. No PHI in URLs, ever, because URLs land in server logs, analytics, and browser history.
Encryption at rest
Technically "addressable" rather than "required" under the Security Rule, which in practice means required, because the alternative is documenting why you chose not to. Encrypt databases, backups, object storage, and mobile device caches. Manage keys in a KMS with documented rotation.
Architecture decisions that follow
- Sign BAAs with every vendor that touches PHI. AWS, GCP, and Azure offer them. So do Twilio, SendGrid, and some analytics vendors. Many do not. No BAA means that vendor cannot touch PHI, regardless of how good their security is.
- Segregate PHI from everything else. A separate schema or database with its own access path makes the audit boundary tractable and reduces the surface you must monitor.
- Keep PHI out of third-party analytics. The most common real-world violation. Session-replay and product analytics tools capture form contents by default. Assume they do and block PHI fields explicitly.
- Design mobile for device loss. No PHI in plain-text local storage, no PHI in screenshots or the app switcher preview, encrypted local cache, remote wipe where feasible.
- Plan de-identification early if you want analytics or model training on this data. Safe Harbor requires removing all 18 identifiers. Retrofitting a de-identified pipeline is painful.
- Be careful with AI features. Sending PHI to a model provider requires a BAA with that provider and appropriate data-processing terms. Most consumer AI APIs do not offer one. If you are building AI into a health product, resolve this before you design the feature, not after. See our AI development services guide.
What compliance adds to a build
| Work item | Added cost | Added time |
|---|---|---|
| Fine-grained RBAC with minimum-necessary rules | $8k–$20k | 2 to 4 wks |
| Read-and-write audit logging with 6-year retention | $10k–$25k | 2 to 4 wks |
| Encryption, KMS, key rotation procedures | $4k–$12k | 1 to 2 wks |
| BAA-compliant infrastructure and vendor review | $3k–$10k | 1 to 2 wks |
| Policies, risk analysis, training, procedures | $6k–$18k | 3 to 5 wks (parallel) |
| Third-party security assessment | $8k–$25k | 2 to 3 wks |
| Total delta | $39k–$110k | 8 to 14 wks |
Rule of thumb: HIPAA adds 30% to 50% to a comparable non-regulated build. Building it in from the start costs roughly a third of retrofitting it, because audit logging and access control are architectural rather than additive.
The formal risk analysis is worth calling out separately. It is an explicit HIPAA requirement, not a nice-to-have, and it is the first document investigators request after an incident.
Seven mistakes that cause breaches
- PHI in analytics or session replay. The most common violation in production health apps.
- PHI in URLs or query parameters. It propagates into logs, referrer headers, and CDN caches.
- Shared accounts for clinical staff. Destroys audit attribution, which invalidates your entire audit trail.
- Production data in staging. Copying the production database to a test environment is a breach the moment it happens.
- No BAA with a vendor already handling PHI. Frequently an email or SMS provider added by marketing.
- Auditing writes but not reads. Most improper access is unauthorised viewing, which is exactly what you failed to record.
- Unencrypted backups. Production is encrypted, the nightly export to object storage is not.
What we have built in this space
HealthiPlate is a nutrition and health tracking app we built on Flutter with Firebase, AWS, and Gemini, tracking 20+ nutrients per meal with personalised, real-time goal insights. It is a consumer wellness product, which places it outside HIPAA's direct scope, and that classification decision was made deliberately in week one rather than assumed. That is the point of the first section of this article: the classification decision changes the architecture, the vendor list, and roughly $40,000 to $110,000 of scope. Make it before you design, not after.
Frequently asked questions
How do you make an app HIPAA compliant?
Implement the required safeguards and be able to evidence them: unique user IDs with role-based access enforced server-side, minimum-necessary restrictions, automatic logoff, immutable audit logs of every PHI read and write retained six years, encryption in transit and at rest, integrity controls, a formal risk analysis, written policies, workforce training, and signed BAAs with every vendor touching PHI.
Is there such a thing as HIPAA certification?
No. No government body or accreditation authority certifies applications as HIPAA compliant. Vendors offering "HIPAA certification" are selling a self-assessment or a third-party attestation of their own methodology, neither of which has legal standing. What matters is whether your safeguards exist and whether you can evidence them during an investigation.
How much does HIPAA compliance add to app development cost?
Typically 30% to 50% of a comparable non-regulated build, or roughly $39,000 to $110,000 in additional work covering fine-grained access control, comprehensive audit logging, encryption and key management, BAA-compliant infrastructure, policies and risk analysis, and a third-party security assessment. Building it in from the start costs about a third of retrofitting it later.
Does HIPAA apply to my wellness app?
Usually not, if users enter their own data and no healthcare provider, insurer, or clearinghouse is involved. However, the FTC Health Breach Notification Rule and state laws such as Washington's My Health My Data Act may still apply, and some of those are stricter than HIPAA. Confirm the classification with counsel before assuming you are unregulated.
Can we use AI features in a HIPAA-covered app?
Yes, but only with a model provider that will sign a BAA and offers appropriate data-processing terms. Most consumer AI APIs will not. The alternatives are a BAA-covered enterprise tier from a major cloud provider, self-hosting a model inside your compliant boundary, or de-identifying data before it leaves. Resolve this before designing the feature.
What is the most common HIPAA violation in software?
PHI leaking into third-party analytics and session-replay tools, which capture form contents by default and typically operate without a BAA. The second most common is auditing writes but not reads, which means the improper access you most need to detect is the one type you never recorded.
Key takeaways
- HIPAA compliance is implemented safeguards plus evidence. Certification does not exist.
- Confirm whether you are covered first. Many wellness apps are not, but state laws and the FTC rule may still apply.
- Every PHI read is an audited event, not just every write. This is the most expensive retrofit.
- No BAA means no PHI, regardless of how secure a vendor is.
- Budget 30% to 50% on top of a comparable build, and design it in rather than adding it later.
Scoping a health product
The classification decision in section one is the cheapest hour you will spend on this and it moves the budget by tens of thousands of dollars in either direction. Describe what your product does and who touches the data and we will send back a written view on whether HIPAA applies, which safeguards follow, which of your intended vendors will sign a BAA, and a cost delta against an unregulated build. If you are outside HIPAA's scope, we will tell you which regime you are actually in instead of quoting you for safeguards you do not need. Related: SOC 2 for SaaS startups, EU AI Act obligations, data protection clauses in your contract, and our healthcare software development service. Primary source: the HHS HIPAA Security Rule guidance.