Many founders realize the need for HIPAA-compliant app development only after a developer provides a quote that omits it, or when a hospital partner asks for a signed BAA before moving forward. This guide aims to help you avoid those surprises.
HIPAA compliance is not something you can just add at the end. It shapes your database design, vendor selection, AI features, and internal processes. Building it in from the beginning is much cheaper than fixing it later.
We have built HIPAA-compliant mobile apps for funded health tech startups, such as the infectious disease diagnostics platform with an AI bot for physicians for the US startup. We have also worked with mental health platforms dealing with PHI. This guide explains what compliance really involves, what it costs, and how to ask the right questions when talking to a development service provider.
If your app combines fitness and clinical data, check out our guide to fitness and wellness app development for a wider view of the architecture.
What HIPAA Compliance Means for a Mobile App in 2026
HIPAA, which stands for the Health Insurance Portability and Accountability Act, applies to any app that creates, receives, stores, or sends Protected Health Information (PHI) for a covered entity or business associate. If your app handles data that can identify someone and relates to their health, healthcare, or payment for healthcare, it falls under HIPAA.
HIPAA-compliant app development requires adherence to three rules:
The Privacy Rule governs how PHI can be used and disclosed. It sets the minimum necessary standard — your app should collect and display only the PHI required to perform its function. It also defines patient rights: access to their data, the right to amendment, and the right to an accounting of disclosures.
The Security Rule focuses on electronic PHI (ePHI) and requires covered entities and business associates to set up administrative, physical, and technical safeguards. For a mobile app, this means using encryption, access controls, audit logging, and automatic logoff. We cover these in detail in the next section.
The Breach Notification Rule requires you to notify affected individuals, the Secretary of HHS, and, in some cases, the media if unsecured PHI is breached. For mobile apps, this means you need incident detection, a clear response plan, and a way to track which records were affected and when.
A quick note on scope: HIPAA applies to covered entities, such as healthcare providers, health plans, and healthcare clearinghouses, as well as their business associates. If your app is a consumer wellness product that does not connect to a covered entity or handle clinical data, you may not be directly affected. However, if you are building for hospitals, insurers, or clinical workflows, or if users can enter diagnosis codes, medication lists, or lab results, you should assume HIPAA applies.
Technical Safeguards Required for HIPAA-Compliant App Development
The Security Rule lists both required and addressable technical safeguards. Required safeguards are mandatory. Addressable safeguards mean you must either implement them or document why you have a suitable alternative. In most cases, you should implement addressable safeguards too.
Encryption
All ePHI must be encrypted both at rest and in transit. In transit means using TLS 1.2 or higher for all API calls, with no exceptions and no HTTP fallback. At rest means using AES-256 encryption for any database, file storage, or local device storage that holds PHI, including backups. Local storage on iOS (Keychain, encrypted Core Data) and Android (EncryptedSharedPreferences, encrypted Room database) must be set up properly, since the default settings are not enough.
Audit Logging
Every time someone accesses PHI, you must log who accessed it, when, from which device, and what they did. Logs must be unchangeable, so users and standard admin roles cannot modify or delete them. You should keep logs for at least six years. Your system should use a separate, append-only logging service rather than relying on application logs in a general-purpose database.
Access Controls
Role-based access control (RBAC) is required. Each user role should only have the permissions needed for their job. Multi-factor authentication (MFA) is not required by HIPAA, but it is a best practice and is often expected by enterprise clients and cyber insurance providers. Session tokens should be limited in scope, set to expire, and revocable.
Automatic Logoff
Apps with PHI must automatically end sessions after a set period of inactivity. No specific timeout is required; decide based on a risk assessment. For clinical apps, 5 to 15 minutes is common. Users should have to log in again before seeing sensitive data after a session ends.
Device Controls
You need the ability to remotely wipe PHI from lost or stolen devices. For mobile apps, this usually means PHI is not stored locally and is retrieved from the server only during an authenticated session, or that local storage can be disabled remotely. For enterprise use, you may need to integrate with mobile device management (MDM) systems.
The BAA Chain: Who Needs One, With Whom
A Business Associate Agreement (BAA) is a legally required contract between a covered entity and any vendor that handles PHI on the covered entity's behalf. If you're building a HIPAA-compliant app, you are a business associate of your client — and you need a BAA with them. But the chain doesn't stop there.
Every service your app uses that touches PHI also needs a BAA with you. This includes:
- Cloud infrastructure (AWS, Google Cloud, Azure — all offer HIPAA-eligible services and BAAs, but you must opt into HIPAA-eligible configurations)
- Database services (RDS, Cloud SQL, Firestore in HIPAA-eligible configurations)
- Analytics platforms (most standard analytics tools like Google Analytics, Mixpanel, and Amplitude are NOT HIPAA-eligible, you need healthcare-specific alternatives or to exclude PHI from analytics entirely)
- Push notification services (standard FCM and APNs are not HIPAA-eligible — PHI should not appear in notification payloads)
- AI/LLM providers (OpenAI offers a BAA under its Enterprise tier; standard API access is not covered)
- Error monitoring (Sentry, Datadog — check HIPAA eligibility and ensure PHI is scrubbed from error payloads)
In practice, your usual tech stack will almost always need to be reviewed and partly replaced with a HIPAA-compliant app. Services that work well for consumer apps may not meet HIPAA requirements. Plan for the audit and possible changes to your stack early on.
As part of our healthtech CTO as a Service, we help clients navigate the BAA chain by mapping every data flow to identify which vendors handle PHI and which agreements are required.
Common Architectural Mistakes That Break HIPAA Compliance
Most compliance failures in mobile apps do not result from ignorance. Instead, they result from using standard development practices that are fine for non-PHI apps but violate HIPAA rules.
Logging PHI in application logs. Stack traces, debug logs, and error-monitoring payloads often include request/response bodies. If those bodies contain PHI, you've created an uncontrolled PHI disclosure. PHI must be scrubbed from all general-purpose logging before it reaches any logging service.
Storing PHI in analytics events. User behaviour analytics is valuable, but standard analytics platforms are not HIPAA-eligible. Sending user IDs linked to health data, diagnostic codes, or medication information to non-BAA analytics vendors is a violation. Either use HIPAA-eligible analytics or architect your analytics to exclude PHI entirely.
PHI in push notification payloads is a problem. Notification content is handled by Apple and Google, and neither has a BAA with you. PHI should never be included in a notification payload. Instead, use a generic message that asks the user to open the app to see the details.
Unencrypted local storage is risky. Storing PHI in unencrypted local storage for performance is a common shortcut, but it creates compliance issues. If a device is lost or jailbroken, the cached PHI can be accessed. Either avoid storing PHI locally or use encrypted storage that fits the platform.
Using the same database tables for PHI and non-PHI data is a mistake. Mixing them makes it harder to set the right controls, track access, and prove compliance. It is best to keep PHI in separate tables or databases with stronger controls.
Using a standard LLM API without a BAA is a violation. Sending PHI to an AI model through an API without a BAA breaks compliance. This is a common mistake when teams add AI features without updating their compliance approach.
AI Features in HIPAA Apps: What's Allowed, What's Not, What Needs Explicit Consent
AI is now central to healthtech product development, and the HIPAA implications are significant. The core question is always: does the AI feature process PHI, and if so, does every service in the processing chain have a BAA?
What's allowed: AI features that process PHI are permitted in HIPAA-compliant app development, provided the AI provider has executed a BAA and operates in a HIPAA-eligible environment. OpenAI's Enterprise tier includes a BAA. AWS Bedrock and Google Cloud's Vertex AI are HIPAA-eligible. Azure OpenAI Service is HIPAA-eligible under a Microsoft BAA.
What's not allowed: Using standard consumer AI APIs (OpenAI standard, Claude.ai consumer, standard Gemini API) to process PHI without a BAA. Training AI models on PHI without appropriate authorization or de-identification. Sharing PHI with AI vendors who use customer data for model training without a BAA that restricts this.
What needs explicit consent: Any use of PHI beyond the minimum necessary for the app's stated purpose requires patient authorization under the Privacy Rule. If your AI feature uses a patient's health history to generate insights beyond direct care, that may require explicit authorization. AI-generated clinical decision support that influences treatment decisions may also trigger additional FDA guidance on Software as a Medical Device (SaMD).
For on of our previous project, the AI diagnostic bot processed physician queries alongside patient infectious disease data. The architecture routed all PHI through HIPAA-eligible infrastructure with a full BAA chain, and the AI outputs were explicitly framed as decision support — not diagnosis — to maintain the appropriate regulatory position.
Cost Breakdown: HIPAA Compliance Add-On to Development Cost
Developing a HIPAA-compliant app costs about 30 to 60 percent more than building a standard mobile app. The exact amount depends on the complexity of the PHI scope and the compliance of your current setup. The table below lists common compliance-related extra costs by area.
|
Compliance area |
What it adds to development |
Typical cost add-on |
|
Encryption at rest & in transit |
AES-256 storage, TLS 1.2+ for all API calls |
$3,000– $6,000 |
|
Audit logging |
Immutable access logs, log retention policy, log export |
$4,000– $8,000 |
|
Access controls & RBAC |
Role-based permissions, MFA, session management |
$5,000– $10,000 |
|
Automatic logoff |
Configurable session timeout, re-auth on sensitive actions |
$1,000– $2,000 |
|
BAA management |
Legal review, vendor vetting, BAA with each sub-processor |
$2,000– $5,000 (legal) |
|
Breach notification system |
Incident detection, 60-day notification workflow, documentation |
$3,000– $6,000 |
|
Security risk assessment |
Documented RA, remediation plan, annual review process |
$4,000– $8,000 |
|
Penetration testing |
Third-party pentest pre-launch, remediation |
$5,000– $15,000 |
|
Total compliance add-on |
On top of standard development cost |
$27,000– $60,000 |
These figures are add-ons to the standard development cost, not the total project cost. A V1 HIPAA-compliant mobile app typically ranges from $90,000–$260,000 all-in, depending on feature scope and platform targets.
Retrofitting compliance into an app that was not built for it usually costs 40 to 80 percent of the original build cost. It is much cheaper to include compliance from the beginning.
Ongoing compliance costs, such as annual risk assessments, penetration testing, BAA reviews, and incident response planning, usually range from$15,000 to$30,000 per year for a mid-sized healthtech product.
How to Brief a Development Service Provider: 8 Questions to Ask
When you are choosing a HIPAA-compliant app development company, the questions you ask show how prepared you are, just as their answers show how capable they are. Here are eight important questions to ask:
- Are you willing to sign BAAs with us? A developer who hesitates is a significant risk.
- Which cloud infrastructure do you use for PHI, and is it HIPAA-eligible? Accept: AWS HIPAA-eligible services, Google Cloud HIPAA-eligible services, Azure. Question any answer that involves non-enterprise tiers.
- How do you handle PHI in your logging and error monitoring? The answer should include PHI scrubbing before sending logs to any external service.
- What's your approach to the BAA chain for third-party services? They should be able to map data flows and identify which vendors need BAAs.
- Have you worked with AI features in a HIPAA context? If yes, which LLM providers did you use, and how did you handle the BAA?
- Do you conduct or coordinate security risk assessments? HIPAA requires a documented risk assessment. A capable partner should either provide this or coordinate it.
- Can you provide references from HIPAA-regulated clients? Not required, but a meaningful signal.
- How do you handle the handover of compliance documentation? At the end of an engagement, you should receive documented evidence of the compliance controls implemented.
Our healthtech security and compliance page covers our specific approach to these questions and the documentation we provide at project close.
HIPAA vs GDPR vs UK-GDPR: When You Need All Three
If you're building for a US healthtech client but your team is in the UK or the EU, or if your app serves patients in multiple jurisdictions, you may need to comply with HIPAA, GDPR, and UK-GDPR simultaneously. These frameworks overlap but are not identical.
HIPAA applies when you handle PHI on behalf of a US covered entity. It's entity-specific and data-type-specific, not geography-based for the individual user.
GDPR applies when you process personal data of individuals in the EU, regardless of where your company is based. Health data is a special category under GDPR, subject to stricter rules and requiring explicit consent or another specific lawful basis.
UK-GDPR is the post-Brexit UK equivalent of GDPR. If you're a UK-based company (as we are) processing health data of UK individuals, UK-GDPR applies. For most practical purposes, UK-GDPR and GDPR requirements align closely.
Where the frameworks conflict or overlap, the stricter requirement generally governs. Some key differences:
- Consent: HIPAA uses authorization for uses beyond treatment, payment, and operations. GDPR requires explicit consent (or another legal basis) for processing special category data. GDPR's consent standard is stricter.
- Data subject rights: GDPR provides broader rights — the right to erasure, the right to portability, and the right to object to processing. HIPAA's patient rights are more limited. A HIPAA-compliant app serving EU users may need GDPR-specific workflows.
- Data transfers: Moving PHI from the EU to the US requires a lawful transfer mechanism under GDPR (Standard Contractual Clauses or an adequacy decision). HIPAA doesn't address cross-border transfers.
For UK-based healthtech startups building for the US market managing all three frameworks simultaneously is the default.
FAQ
Does my fitness app need to be HIPAA compliant?
Not always. HIPAA applies if your app handles PHI for a covered entity. A consumer fitness app that tracks steps and workouts for individual users, without connecting to a healthcare provider or insurer, is usually not covered by HIPAA. However, if your app connects to EHR systems, is used by clinicians, or processes insurance data, HIPAA applies. When you are unsure, assume HIPAA applies and design for it, since this is much cheaper than making changes later. See our fitness app development guide for more details.
What's the difference between HIPAA-eligible and HIPAA-compliant infrastructure?
HIPAA-eligible means the provider offers a BAA and has set up their service to support compliance, but you are responsible for using it correctly. For example, AWS offers HIPAA-eligible services, but if you store PHI in a non-eligible service, like standard S3 without the right controls, or if you set things up incorrectly, you are not compliant. HIPAA-compliant infrastructure means using eligible services, setting them up correctly, and having a signed BAA.
Can I use ChatGPT or Claude in a HIPAA-compliant app?
You can use OpenAI's API with a BAA (available under Enterprise agreements) in a HIPAA-eligible configuration. Standard consumer ChatGPT and standard API access without a BAA are not appropriate for PHI. Anthropic's Claude is available via API, and enterprise agreements with appropriate BAAs are possible — check current terms directly with Anthropic. The key question is always: does PHI reach the model, and is there a BAA in place?
How long does it take to build a HIPAA-compliant mobile app?
A HIPAA-compliant MVP typically takes 12–18 weeks, compared to 8–14 weeks for a standard MVP. The additional time accounts for compliance architecture design, BAA chain setup, audit logging implementation, security risk assessment, and penetration testing. A full V1 for a HIPAA-compliant app development project typically runs 20–28 weeks.
Do we need a BAA with our development agency?
Yes, if the development agency has access to real PHI during development or testing. If you're using synthetic or de-identified test data throughout development and only real PHI enters the system post-launch, the BAA requirement during development is less clear, but a prudent agency will offer one anyway. We sign BAAs with all our HIPAA-scoped clients as standard.
We're a UK company building for US clients, do we need HIPAA?
Yes. HIPAA applies based on what data you handle and who your clients are, not where you're based. If you're a business associate of a US-covered entity and handle their patients' PHI, you need a BAA and must meet the Security Rule requirements, regardless of your company's location. You'll also likely need to satisfy GDPR or UK-GDPR for your own processing activities.
Building a HIPAA-aware healthtech product? See our Health & Sport portfolio, our security and compliance approach, or explore our CTO-as-a-Service for healthtech startups.