HIPAA compliant app development, planned around where patient data actually goes

What is HIPAA compliant app development?

HIPAA compliant app development is the work of designing, coding and running a mobile or web app so that the protected health information it handles meets the safeguards a HIPAA covered entity or business associate must apply. The phrase describes a way of building, not a badge the app can earn.

That distinction matters because there is no official certificate for it. AWS states plainly on its HIPAA compliance page that there is no HIPAA certification for a cloud provider, and Google Cloud makes the same point: the Department of Health and Human Services recognises no certification for HIPAA compliance. When a vendor tells you an app is “HIPAA certified”, treat that as marketing wording and ask what they actually did.

In practice, the work breaks into four jobs. First, decide which data in the app is PHI and where each piece travels. Second, keep that data inside services whose providers sign a business associate agreement with your organisation. Third, apply the technical safeguards in the HIPAA Security Rule: access control, audit controls, integrity protection, person authentication and transmission security. Fourth, document it so your security officer can fold the app into the organisation's risk analysis.

In HIPAA compliant app development, our part is the engineering and the documentation. Your part, with your counsel and compliance lead, is the policies, training, agreements and final judgement that the whole programme holds together. We say that on every quote because it is how the regulation divides responsibility.

Does my health app need to be HIPAA compliant?

Your app needs HIPAA safeguards when it creates, receives, stores or transmits PHI for a covered entity, meaning a health plan, clearinghouse or a provider that bills electronically, or for a business associate working for one. A consumer app that people download on their own, with no link to their provider, is usually outside HIPAA, though other rules may apply.

Three quick scenarios make the line clearer. A dermatology group commissions an app so its own patients can upload photos and message the clinic: the app handles PHI for a covered entity, so HIPAA applies. A startup sells a remote-monitoring platform to cardiology practices and stores readings on their behalf: the startup is a business associate and carries its own obligations. A mood journal sold directly to consumers, never connected to a provider: HIPAA probably does not apply, but the Federal Trade Commission may.

The FTC's Health Breach Notification Rule covers vendors of personal health records and related entities that sit outside HIPAA. The FTC notes that a breach is not limited to hacking; sharing health data with an ad network without authorisation can count. So even a consumer wellness app needs the same discipline about SDKs and data sharing, just under a different rulebook.

• App built for a provider or health plan, handling their patients' data: HIPAA safeguards apply
• Platform storing health data on behalf of providers: you are likely a business associate
• Direct-to-consumer health app with no provider link: check the FTC rule and state health-privacy laws
• Unsure: ask your counsel before design starts, because the answer changes the architecture

Data-flow mapping: the first step in HIPAA compliant app development

A data-flow map is a diagram and table that traces every piece of PHI from the moment it enters the app to every place it is stored, copied, logged or sent. It is the first thing we deliver, before design mock-ups, because every later decision depends on it.

We build it by walking each user journey screen by screen: sign-up, identity check, booking, intake questions, photo upload, messaging, notifications, results, account deletion. For each screen we record what data appears, whether it identifies a person, which API receives it, where it is stored, who can read it, how long it is kept and whether any third-party code sees it along the way.

On almost every HIPAA compliant app development project, the map surfaces surprises. Crash-reporting tools can capture screen contents or request bodies. Push notifications pass through Apple and Google servers, so their text should never contain a diagnosis or appointment reason. Analytics events named after screens, such as “viewed_hiv_results”, can reveal health information by the event name alone. Customer-support chat widgets may copy messages to a vendor with no BAA.

Your compliance lead reviews and signs off the map, and it becomes a living document: when a feature is added later, the map is updated in the same pull request. For HIPAA compliant app development, this single artefact does more to prevent a breach than any individual security feature, because it shows where the safeguards need to go.

Which AWS and Google Cloud services can hold PHI under a BAA?

On AWS, only services on the HIPAA-eligible list should process or store PHI, inside an account you have designated under the AWS Business Associate Addendum. On Google Cloud, only products on the covered-products list fall under the Google Cloud BAA. Anything outside those lists stays PHI-free.

AWS explains that customers accept its standard BAA through AWS Artifact in the management console, and that while any service can run in a HIPAA-designated account, PHI belongs only in eligible services. Google Cloud says its BAA covers its infrastructure and a published list of products, including Firestore, Cloud Run functions, Cloud Storage and Identity Platform. When we checked that list in September 2026, no Firebase-branded product appeared on it, which matters because many app tutorials default to Firebase Analytics, Crashlytics and Cloud Messaging.

Both providers are clear that the agreement does not make your app compliant by itself. Google's page says the customer is responsible for configuring and securing what they build on top of its infrastructure, and AWS describes the same split through its shared responsibility model. The BAA covers the provider's side; encryption settings, IAM roles, logging and network rules are ours to build and yours to approve.

For HIPAA compliant app development, our usual starting architecture is modest: a managed database, object storage with server-side encryption, a key management service, a container or serverless API layer and centralised logs, all in one region you choose. We set it up with infrastructure-as-code in your account, so a reviewer can read exactly how each resource is configured instead of trusting screenshots.

Encryption in transit and at rest for a HIPAA compliant mobile app

Encrypt PHI whenever it moves and wherever it rests: TLS for every network call, encrypted databases and storage buckets on the server, and on the phone either no PHI at all or PHI kept in encrypted storage backed by the device's secure hardware.

The HIPAA Security Rule lists encryption as an “addressable” implementation specification for both stored data and transmitted data. Addressable does not mean optional; it means your organisation must implement it or document why an equivalent measure is reasonable. For a patient app that leaves the building in millions of pockets, we treat encryption as the default and have not yet met a case where skipping it made sense.

Access control, logins and automatic logoff in health apps

Every person who can see PHI needs a unique login, strong authentication and only the permissions their role requires. The app should also log users out after inactivity and give administrators a controlled emergency-access path.

The Security Rule's access-control standard at 45 CFR 164.312(a) lists unique user identification and an emergency access procedure as required, with automatic logoff and encryption as addressable. Person or entity authentication, at 164.312(d), requires verifying that whoever asks for PHI is who they claim to be. In app terms, that becomes a short list of features we build as standard.

• Unique accounts for patients, caregivers, clinicians and admins; no shared staff logins
• Multi-factor authentication for staff, and optional biometric sign-in (Face ID, fingerprint) on top of a real credential for patients
• Role-based permissions checked on the server for every request, not just hidden buttons in the app
• Inactivity timeouts tuned per role, with the app blurring content when sent to the background
• Proxy or caregiver access modelled explicitly, with its own consent record
• A documented break-glass procedure for emergencies, itself logged and reviewed

For identity, we usually pick a managed identity service that appears on your provider's eligible or covered list (Identity Platform is on Google Cloud's) rather than hand-rolled password storage. If your organisation already runs an identity provider for staff, the clinician dashboard can sign in through it.

Audit logs in HIPAA compliant app development: what to record

Record who accessed which PHI, when, from where and what they did, in logs that the people being logged cannot edit. Then make sure someone actually reviews them.

45 CFR 164.312(b) asks for mechanisms that record and examine activity in systems containing electronic PHI, and the administrative safeguards at 164.308 ask organisations to regularly review records such as audit logs and access reports. A log nobody reads satisfies neither the letter nor the purpose.

Our application-level audit trail captures: user ID and role, action (view, create, update, delete, export, share), the record touched, timestamp, device and IP details, and success or failure. It deliberately does not copy the PHI itself into the log line, because a log full of diagnoses becomes a second PHI store to protect. Infrastructure logs, such as AWS CloudTrail or Google Cloud Audit Logs, sit alongside it and record administrative changes to the environment.

Logs go to a separate, write-restricted destination with retention set by your policy. HIPAA's documentation rule at 164.316 requires policies and related records to be kept for six years; how long raw access logs are kept is a decision for your security officer, and we build to whatever period they choose. We also set up a simple monthly report, such as unusual after-hours access or bulk exports, so review takes minutes rather than a forensic project.

How do you vet third-party SDKs in a health app?

List every library that ships in the app, find out what data each one sends and where, and remove or replace any that could receive PHI without a BAA. Repeat the review whenever a dependency is added or updated.

SDKs are the most common way health apps leak data by accident, which is why SDK review is a standing task in HIPAA compliant app development. A marketing team adds an attribution SDK; a developer drops in a crash reporter; a support team embeds a chat widget. Each can collect device identifiers, screen names or request payloads, and each sends them to a company your organisation has no agreement with.

Our review has three passes. We read the dependency manifests (pubspec, package.json, Podfile, Gradle files) and list every direct and transitive library. We then run the app against a network proxy on test devices and record every outbound domain during each journey. Finally, we compare both lists with the data-flow map and flag any gap. A vendor's own privacy documentation helps, but it describes the SDK's intentions, not what your configuration actually sends.

Decisions follow simple rules. Anything touching PHI either runs on a BAA-covered service or goes. Analytics, if kept at all, lives only on PHI-free screens with neutral event names. Crash reporting is configured to strip request bodies and user identifiers, or replaced with logging into your own cloud. Advertising SDKs do not belong in a patient app, and Apple's guideline 5.1.3 bars using health data for advertising in any case.

Flutter, React Native or native for HIPAA compliant app development?

Any of the three can support HIPAA safeguards; security comes from architecture and configuration, not the UI framework. We usually recommend Flutter or React Native for one shared codebase, adding native modules where a platform security API needs direct access.

Flutter suits apps that want identical screens on iOS and Android and heavy custom UI, such as symptom diaries or rehab exercise trackers. React Native suits teams that already run a React web dashboard and want to share logic and developers across both. Fully native Swift and Kotlin make sense when the app leans hard on device features, such as continuous Bluetooth readings from a medical sensor, or when your in-house team already works natively.

Whichever framework you pick, the security-relevant pieces are the same: platform secure storage (Keychain, Keystore), a vetted HTTP client with strict TLS, an encrypted local database if offline mode is needed, jailbreak and root checks where your risk analysis calls for them, and code obfuscation for release builds. We compare the options in more depth on our Flutter app development and React Native development pages.

For the server side of HIPAA compliant app development we favour boring, well-documented choices: Node.js or Python APIs, PostgreSQL on a managed service, and object storage for files. Unusual databases and new frameworks make security review slower and staff turnover riskier, which is the opposite of what a regulated app needs.

How much does HIPAA compliant app development cost?

With our team, a cross-platform patient app starts at US$600, and the backend, staff dashboard or integrations that hold PHI start at US$900. The biggest cost drivers are how many kinds of PHI the app handles, how many user roles it has, and how many outside systems it connects to.

Quotes for HIPAA compliant app development vary widely across the market, and headline figures hide very different scopes. One quote may include the data-flow map, infrastructure-as-code, audit logging and SDK review; another may deliver screens on a default Firebase setup and leave the compliance work to you. Compare line items, not totals.

• Data types: an appointment app with names and times is simpler than one storing images, lab values or behavioural-health notes
• Roles: patient only, or patient plus caregiver, clinician, front desk and admin, each with different screens and permissions
• Integrations: every EHR, lab, pharmacy, device or scheduling connection adds build and test time
• Offline mode: storing PHI on the phone for use without signal means encrypted local storage and sync conflict handling
• Real-time features: video visits and chat need BAA-covered vendors and more testing
• Review cycles: time your compliance team, counsel or an external pen tester needs is part of the schedule

Running costs are separate and paid by you: cloud usage, vendor subscriptions and store fees. We list them in the quote so the first cloud invoice holds no surprises. For a broader view of outsourcing budgets, see what outsourcing app development costs.

How long does it take to build a HIPAA compliant app?

A focused patient app usually takes six to ten weeks from approved scope to store submission, and a custom backend or staff portal runs six to twelve weeks alongside it. Integrations with outside systems and your own review steps are what stretch a schedule.

The first fortnight goes on the data-flow map, the cloud account setup under your BAA and clickable wireframes. Build sprints follow in one- or two-week cycles, each ending with a TestFlight and Google Play internal-testing build you install on your own phone. Security tasks run inside every sprint rather than as a final phase: logging goes in with the first API, not bolted on before launch.

Store review adds time at the end of HIPAA compliant app development. Health apps can receive extra questions from Apple, especially if they use HealthKit, and Google Play asks some health apps to complete a Health apps declaration in Play Console. We prepare privacy policy links, data-safety answers and reviewer demo accounts with synthetic data before submitting, which avoids most back-and-forth.

The parts outside our control are worth planning for: an EHR vendor's API access approval, your legal review of terms and consent text, and any external penetration test you commission. Starting those requests in week one keeps the calendar honest.

What do the App Store and Google Play require from health apps?

Both stores add privacy rules on top of HIPAA. Apple bars using health data for advertising and storing personal health information in iCloud, and requires a privacy policy plus in-app account deletion; Google Play requires disclosures, consent and, for some apps, a Health apps declaration.

Apple's App Review Guidelines section 5.1.3 says apps may not use or disclose health, fitness and medical data, including data from HealthKit and the Clinical Health Records API, for advertising, marketing or data mining other than improving health management or approved research. Section 5.1.1 requires a privacy policy link both in App Store Connect and inside the app, explaining what is collected, how it is used, retention and how users can request deletion. If the app lets people create an account, it must also let them delete that account from within the app.

Google Play's policy asks health apps to disclose clearly how user data is used and obtain affirmative consent, and it announced in April 2024 that some developers must complete a Health apps declaration on the App content page. Apps that make health claims are expected to explain purpose, intended users and risks in plain language.

Account deletion is where store rules and HIPAA meet awkwardly: medical records may need to be retained under your policies or state law even after a patient deletes their app account. We build deletion as “close the account and stop access” with retention handled by your documented policy, and your counsel approves the wording users see.

How to choose a HIPAA compliant app development partner

Choose a team that can explain, in plain words, where your PHI will live, who signs each agreement, how they avoid touching real patient data, and what they hand over at the end. Vague answers on those four points are a stronger signal than any portfolio.

Questions worth asking any candidate, including us:

• Will you produce a data-flow map before design, and can I see a redacted sample?
• Whose cloud account and whose BAA will hold PHI: mine or yours?
• Will your developers ever need access to real patient data? If so, why and under what agreement?
• Which analytics, crash-reporting and messaging SDKs do you plan to include, and what do they send?
• How are audit logs designed, and who reviews them?
• Whose Apple, Google Play and code-hosting accounts will the app live in?
• What happens to your access when the project ends?

Red flags include a promise that the app will be “HIPAA certified”, a plan to host PHI on the developer's own servers without an agreement, test data copied from a real patient export, and advertising SDKs in the dependency list. If you want to compare engagement models more broadly, our guide to outsourcing app development covers contracts, milestones and handover.

HIPAA compliant app development with a team in India: how it works from the US

You meet us on video in your morning, follow progress in your own repository and project board, and pay approved milestones in USD by wire, Wise or PayPal. On health projects the design goal is that our team never needs your patients' data at all.

India runs on IST, UTC+5:30, without daylight saving. A 9 a.m. call in Boston or Atlanta falls in our evening, and Pacific clients typically book the earliest slot of their day. Work continues while you sleep, so feedback given on Tuesday morning is often visible in a Wednesday test build.

Access is set up so your organisation stays in charge. You create the AWS or Google Cloud account, accept the provider's BAA, open the Apple Developer and Google Play Console accounts and the GitHub or GitLab organisation, then invite us with scoped roles. Staging uses generated patient records; production PHI appears only after release, visible to your staff. Contract terms, confidentiality and IP assignment are set out in your written quote, with defaults on our terms page. Invoices are issued from India; your accountant advises on how to book them.

The first two weeks follow a set rhythm. Days one and two: you share the idea, workflows and any existing code; we reply with questions and then an itemised quote. Week one after approval: kickoff call, the draft data-flow map and a list of the accounts and agreements you need to set up. Week two: the reviewed map, cloud environment skeleton, first wireframes and a TestFlight build showing navigation, even if screens are still placeholders. We do not offer on-site visits, hardware installation or legal advice.

Ownership, handover and maintenance of a HIPAA compliant app

You own the code, the cloud account, the store listings and the data from day one, and at handover you receive the documentation needed to run, audit and extend the app without us.

The handover pack contains the current data-flow map, architecture diagram, infrastructure-as-code repository, SDK inventory with the reason each library is present, role and permission matrix, audit-log field list, runbooks for deployment and key rotation, and a list of every vendor holding PHI with the agreement each requires. When you confirm the transition, we remove our access and you can verify the removal in your own audit logs.

Maintenance after HIPAA compliant app development is more than bug fixes. Apple and Google ship major OS releases every year, dependencies publish security patches, certificates expire and store policies change. The Breach Notification Rule at 45 CFR 164.404 gives covered entities no more than 60 calendar days after discovering a breach to notify affected individuals, so a clear incident runbook and working logs are part of upkeep, not an extra.

Fixes are free for two months after launch. After that, care plans start at US$120/mo and include monthly dependency and SDK review, OS-compatibility testing, log-review support and store-policy checks. You can equally move upkeep to an in-house team using the handover pack.

Worked example: a hypothetical remote-monitoring app for a cardiology group in Ohio

Picture a four-physician cardiology group in Columbus that wants patients recovering from heart procedures to log blood pressure and symptoms daily, with nurses alerted when readings cross thresholds. This is an illustrative scenario, not a past client.

The data-flow map lists readings, symptom notes, medication check-ins and patient identity as PHI, plus one less obvious item: the reminder notification. The team decides reminders will say “Time for today's check-in” and nothing more. Readings arrive from a Bluetooth cuff through Apple HealthKit and Android Health Connect, so the map notes that health data from those APIs cannot be used for anything but care under Apple's rules.

The group creates an AWS account, accepts the BAA through AWS Artifact and invites us. We build a Flutter app, an API on HIPAA-eligible services, an encrypted PostgreSQL database and a nurse dashboard where threshold alerts land. Nurses sign in with MFA; every chart view and every alert acknowledgement lands in the audit log. The original plan included a popular analytics SDK; the review drops it, and the practice counts engagement from its own database instead.

Scope-wise, the app starts from US$600, the dashboard and backend from US$900, and the group's compliance officer and outside counsel review the map, consent text and incident runbook before release. The group's security consultant runs a penetration test on the staging build, and fixes land before patients are invited. After launch, the nurses' first request is a weekly summary per patient, which goes through the same map-first process.

HIPAA compliant app development checklist before release

Run through this list with your compliance lead before submitting to the stores. Every “no” is either fixed or documented with a reason your counsel accepts.

• Data-flow map is current and signed off, including every SDK and outbound domain
• PHI is stored and processed only in services covered by your cloud provider's BAA
• Separate BAAs are in place with any video, messaging, email or SMS vendor that handles PHI
• TLS on every endpoint; encryption at rest for databases, files and backups; keys in a managed KMS
• No PHI in push notification text, URLs, analytics event names or log lines
• Unique accounts, MFA for staff, server-side role checks and inactivity timeouts
• Application audit trail plus cloud audit logs, with a named reviewer and schedule
• Local health data excluded from device backups and iCloud
• Privacy policy linked in the store listing and in the app; in-app account deletion works
• Store privacy answers match what the SDK review found
• Incident response runbook tested, including who decides on breach notification
• Production access restricted to your staff; developer access reviewed and minimised

If the app has a marketing website that California visitors use, the same discipline applies to its trackers under state privacy law; our page on building a CCPA compliant website explains opt-out links and Global Privacy Control.