HIPAA-Compliant Mobile App Development: 2026 Guide
Updated October 2026 by the Cliffex team.
HIPAA-compliant mobile app development means building an app that handles electronic protected health information (ePHI) with the safeguards the HIPAA Security Rule requires, then running it under signed business associate agreements (BAAs) on hosting that supports them. No app is “HIPAA certified”: HHS does not recognize any private certification, so compliance depends on how the app is built, hosted, contracted and operated. A development team can build the technical safeguards; the organization that owns the app remains responsible for its policies, risk analysis and agreements.
Does your health app need to follow HIPAA?
HIPAA applies to covered entities (health plans, healthcare clearinghouses and most healthcare providers) and to their business associates. A business associate is a person or company that performs work for a covered entity involving access to protected health information, including a subcontractor that creates, receives, maintains or transmits that information for another business associate (HHS, sample BAA provisions).
In practice:
- Apps used by or for a clinic, hospital or insurer (patient portals, telehealth, remote monitoring that feeds a provider’s records, clinical trial tools) are usually in scope.
- Consumer apps that people use on their own, such as a fitness tracker or a period tracker with no provider relationship, are often outside HIPAA. They may instead fall under the FTC’s Health Breach Notification Rule, which the FTC says “applies to health apps and similar technologies not covered by HIPAA” (FTC, April 2024).
- Apps that only process properly de-identified data are outside the Security Rule, because de-identified information is not protected health information (HHS cloud computing guidance).
Whether your product is in scope is a legal question. Settle it with healthcare counsel before you write a requirements document, because the answer changes the hosting, vendor and budget decisions that follow.
HIPAA Security Rule technical safeguards, explained
The Security Rule has three groups of safeguards: administrative, physical and technical. The technical safeguards in 45 CFR § 164.312 are the ones software has to implement directly. Each standard is mandatory. Some implementation specifications are marked “required” and others “addressable”. HHS explains that addressable does not mean optional: the organization must implement it where it is reasonable and appropriate, or document why not and adopt an equivalent measure if one is reasonable (HHS Security Rule summary).
| Standard (§ 164.312) | What the regulation asks for | How it shows up in an app |
|---|---|---|
| Access control | Unique user identification (required), emergency access procedure (required), automatic logoff (addressable), encryption and decryption (addressable) | Individual accounts for every user, role-based permissions, session timeouts, a documented break-glass process, encryption of stored ePHI |
| Audit controls | Mechanisms that record and examine activity in systems containing ePHI | Tamper-resistant logs of who viewed, created, changed or exported each record |
| Integrity | Protect ePHI from improper alteration or destruction; mechanism to authenticate ePHI (addressable) | Server-side validation, checksums or signed records, versioned data and backups |
| Person or entity authentication | Verify that whoever seeks access is who they claim to be | Strong passwords, multi-factor authentication, secure token handling, biometric unlock on the device |
| Transmission security | Integrity controls and encryption for ePHI sent over networks (both addressable) | TLS for every API call, no ePHI in push notification text, URLs or analytics events |
The Security Rule also requires an accurate and thorough risk analysis of threats to the confidentiality, integrity and availability of ePHI, and HHS says this analysis drives which security measures are reasonable and appropriate (HHS). That is an administrative safeguard owned by the client organization, though the development team should supply the system documentation it needs.
A proposed update to the Security Rule was published in the Federal Register on 6 January 2025 (Federal Register). As of October 2026 no final rule has been published, and the federal regulatory agenda now points to July 2027 at the earliest (Fierce Healthcare), so the current text of § 164.312 still applies. The proposal would tighten several requirements, so we design new apps with encryption and multi-factor authentication from the start.
Business associate agreements: who signs what
Under HIPAA, a covered entity must have a written contract with each business associate. HHS lists what it must contain, including the permitted uses and disclosures of the information, a requirement to implement Security Rule safeguards for ePHI and a duty to report unauthorized uses and breaches (HHS). For a typical health app, the chain looks like this:
- The clinic or health plan (covered entity) signs a BAA with the company that operates the app.
- The app company signs BAAs with every vendor that stores or processes ePHI for it: cloud hosting, database, email or SMS provider, video provider for telehealth, error logging.
- If a development partner will access production ePHI (for example, to debug live data), that partner needs a BAA too. Many teams avoid this by working only with test data and de-identified copies. Cliffex signs a BAA whenever our work involves ePHI.
Breaches carry deadlines. A business associate must notify the covered entity without unreasonable delay and no later than 60 days after discovering a breach, and covered entities must notify affected individuals within the same 60-day limit (HHS Breach Notification Rule). Your audit logs and incident process determine whether you can meet them.
Hosting: choosing a cloud provider that signs a BAA
HHS guidance says a cloud service provider that creates, receives, maintains or transmits ePHI for you is a business associate, and that “lacking an encryption key does not exempt a CSP from business associate status” (HHS). Encrypting everything does not remove the need for a BAA with your host.
| Provider | BAA available? | What to check |
|---|---|---|
| AWS | Yes, a standard Business Associate Addendum accepted through AWS Artifact | PHI may only be processed in the HIPAA-eligible services listed in the BAA (AWS) |
| Google Cloud | Yes | Use only products on Google’s covered-products list; Google states you remain responsible for evaluating your own compliance (Google Cloud) |
| Microsoft Azure | Yes, included by default through the Product Terms and Data Protection Addendum | Microsoft states a BAA does not by itself make your solution compliant (Microsoft) |
Two practical warnings. First, a BAA covers specific services, so a convenient tool from the same vendor may sit outside it. Firebase, for example, did not appear on Google Cloud’s HIPAA covered-products list when we checked in October 2026. Second, AWS states plainly that “there is no HIPAA certification” for a cloud provider (AWS), and the same is true for app developers. HHS says it “does not endorse or otherwise recognize private organizations’ ‘certifications'” for the Security Rule (HHS FAQ). Treat any vendor that claims to be “HIPAA certified” with caution.
What an app team can and cannot guarantee
A competent HIPAA app developer can deliver the technical side: encrypted storage and transport, access control and audit logging, secure authentication, hosting configured inside BAA-covered services, and documentation of how ePHI flows through the system. Mobile-specific work matters here too. The OWASP MASVS is a useful checklist for secure on-device storage, network security and platform permissions.
A development team cannot make your organization compliant on its own. These items belong to you:
- The risk analysis and risk management plan
- Workforce training, access approvals and sanctions policies
- BAAs with your customers and vendors
- Breach response and notification decisions
- Ongoing configuration, patching and log review after launch
When you evaluate HIPAA-compliant app development services, ask each vendor how they keep real ePHI out of development and test environments, which third-party SDKs the app will include, and how they document safeguards for your risk analysis.
Integrations and features that shape the build
Most healthcare apps exchange data with an electronic health record system. HL7 FHIR, “a standard for exchanging healthcare information electronically” (HL7), is the usual starting point, though each EHR vendor has its own access process and approval timeline. Plan for that early.
Features that often need extra care:
- Push notifications: keep the message generic (“You have a new message”) and show details only after login.
- Analytics and crash reporting: many popular SDKs are not covered by a BAA, so strip identifiers or choose covered tools.
- Telehealth video and messaging: use a provider that will sign a BAA.
- File uploads: store documents and images in encrypted, access-controlled storage with signed, expiring links.
- Offline mode: encrypt cached data on the device and wipe it on logout.
Cost and timeline for a HIPAA-ready app
Healthcare apps start from $4,000, like all our apps. A focused first version, such as appointment booking with reminders or a simple patient portal, usually fits our Starter tier ($4,000–$10,000, 4–6 weeks). Apps with several roles and integrations such as EHR connections or insurance checks usually fall into our Business tier ($10,000–$20,000, 6–12 weeks), and multi-location platforms or AI assistants into Advanced ($20,000+, 12–16+ weeks, scoped individually). Safeguards such as audit logging, role design and BAA-covered hosting are part of the scope from the first version, and your written proposal lists the ones included. Try the app cost calculator for a range based on your idea.
Every project includes 30 days of post-launch support. After that, maintenance is billed hourly at $25–$49/hr depending on complexity: you describe the need, we send an estimate and work starts after approval. Hosting and BAA-covered third-party services are billed separately by those providers. See our pricing and the app cost guide for more detail.
How Cliffex can help
We build healthcare web and mobile apps with the technical safeguards your compliance team specifies, on hosting chosen with your team that can be covered by a BAA (for example AWS or Google Cloud). We sign a BAA with you whenever our work involves ePHI, and we hand over full source code and IP. We built a doctor-appointment platform with patient, doctor and admin apps and maintained it for more than six years, and an AI patient assistant for dental practices running on OpenAI under a signed BAA, with a phone assistant on Twilio. Compliance itself depends on your policies, agreements and hosting, and we work alongside your compliance advisers on those. See our healthcare app development service. Examples of our healthcare work include an AI-driven SaaS platform for healthcare providers and technology for conducting clinical trials. To discuss your project, send us a request.
Frequently asked questions
What makes a mobile app HIPAA compliant?
An app supports HIPAA compliance when it implements the Security Rule’s technical safeguards (access control, audit controls, integrity, authentication and transmission security), runs on BAA-covered hosting, and is operated under the organization’s risk analysis, policies and business associate agreements. The code alone cannot make it compliant.
Is there a HIPAA certification for app developers?
No. HHS does not endorse or recognize private HIPAA certifications. When choosing a HIPAA app developer, look for experience with healthcare projects, a clear approach to safeguards and willingness to sign a BAA if they will touch real ePHI.
Does my app developer need to sign a BAA?
Only if the developer creates, receives, maintains or transmits ePHI on your behalf, for example by accessing production data. A team that works only with test or de-identified data typically does not need one, but confirm this with your counsel. Cliffex signs a BAA whenever our work involves ePHI.
Can I use Firebase for a HIPAA-compliant app?
Check Google’s current HIPAA covered-products list before you decide. In October 2026 Firebase was not on it, so we use BAA-covered Google Cloud or AWS services for any component that stores or processes ePHI.
How long does HIPAA-compliant mobile app development take?
Most projects take 6 to 16 weeks, depending on features, roles and integrations. EHR integrations and vendor approvals can add time outside the development schedule.