HIPAA-compliant app development: a practical checklist

An app needs to meet HIPAA when it creates, receives, stores or transmits protected health information (PHI) for a covered entity, or when the app's owner is a covered entity itself. In practice that means a signed business associate agreement, hosting on cloud services covered by one, and Security Rule safeguards (risk analysis, access control, encryption, audit logs) designed into the product from the start.

This is general information, not legal advice. Your counsel should confirm how HIPAA applies to your product.

When does HIPAA apply to an app?

HIPAA applies to two groups. Covered entities are health plans, health care clearinghouses, and health care providers that conduct certain transactions electronically, such as billing insurance. Business associates are people and companies that handle PHI on behalf of a covered entity. HHS explains both definitions and offers a tool to check which you are.

Three common situations for app teams:

• You build for a clinic, hospital or health plan, and the app handles their patients' data. You are a business associate. You sign a business associate agreement (BAA) with them, and your subcontractors that touch PHI sign BAAs with you.
• You are a provider or plan building your own app. You are the covered entity. Every vendor in the data path needs a BAA with you.
• You sell directly to consumers, such as a fitness, diet or symptom tracker that people download themselves. HIPAA often does not apply. The FTC's Health Breach Notification Rule may, along with state privacy laws.

The same product can move between these categories. A consumer app that adds a feature for clinics to view patient data can become a business associate for that feature.

What a BAA does and does not do

A BAA is a contract that sets how PHI may be used and disclosed, and requires the business associate to protect it. It is required, but it is not a security control. Signing one does not make an app safe; it records who is responsible.

Business associates are directly liable for meeting the applicable HIPAA requirements, not only contractually liable. HHS guidance on cloud computing also makes clear that a cloud provider storing encrypted PHI is still a business associate, even if it has no decryption key.

Security Rule safeguards mapped to app decisions

The Security Rule requires administrative, physical and technical safeguards for electronic PHI. It does not name technologies. Some specifications are "required" and others "addressable". HHS's summary of the Security Rule is explicit that addressable does not mean optional: you implement it when reasonable and appropriate, or document why not and use an equivalent measure.

Administrative safeguards

• Risk analysis. Map where PHI enters, lives and leaves your system, then assess threats to each point. This document drives every other decision, and it is often among the first things an investigator or customer asks for.
• Security ownership. Name the person responsible for security.
• Workforce controls. Access granted by role, removed promptly when people leave, and security training for everyone with access.
• Vendor management. A list of every service that touches PHI, each with a BAA.
• Incident response and contingency plans. How you detect, contain and report a breach, and how you restore service and data.

Physical safeguards

For a cloud-hosted app, the provider runs the data centers. Your part is the devices your team uses: encrypted laptops, screen locks, remote wipe, and rules about PHI on personal phones. Also decide how devices and media holding PHI are disposed of.

Technical safeguards

• Hosting. AWS, Microsoft Azure and Google Cloud each offer a BAA that covers a defined list of services. Sign it, and build only on services on that list. A managed service outside that list cannot hold PHI, even in a test environment.
• Encryption. Encrypt PHI in transit (TLS everywhere, including internal service calls) and at rest (databases, object storage, backups, logs). Manage keys through the cloud key service with access limited by role.
• Access control. Unique user IDs, role-based permissions, automatic session timeout, and multi-factor authentication for staff and admin access. Passkeys are a strong option for patients.
• Audit controls. Record who viewed, created, changed or exported PHI, and when. Store the logs where application admins cannot edit them, and review them.
• Integrity. Protect records against improper change: validation, versioning, and checks on data received from other systems.
• Minimum necessary. The Privacy Rule expects you to limit PHI use and disclosure to what a task needs. In an app, that means narrow API responses, role-scoped screens, and no full records in notifications, emails or logs.

Common mistakes in HIPAA app development

Tracking pixels and analytics

This is the gap that is easiest to miss. Analytics, advertising and session-replay scripts send data to their vendors, often including IP addresses, device IDs and the page or screen the user is on.

HHS's Office for Civil Rights published a bulletin on online tracking technologies, first in December 2022 and updated in March 2024. In June 2024 a federal court vacated the part covering certain unauthenticated public web pages. The guidance on logged-in pages and apps remained: tracking technologies there often have access to PHI, and a vendor that receives PHI must be permitted under the Privacy Rule and covered by a BAA.

For app teams, the practical rule: no third-party tracking on logged-in pages or inside the app unless the vendor signs a BAA and the disclosure is permitted. Use analytics tools that will sign a BAA, or self-hosted ones.

Other frequent gaps

• PHI in logs and error reports. Crash reporters and application logs capture request bodies. Scrub them, or send them only to services under a BAA.
• Push notifications and email. Lock-screen text and subject lines can disclose PHI. Keep them generic.
• Non-production data. Copying production PHI into development or staging extends your scope. Use synthetic or de-identified data.
• AI features. Sending PHI to a model provider is a disclosure like any other. Use a provider and service that sign a BAA, and log what goes out.
• Backups and exports. Backups need the same encryption and access limits as production. So do CSV exports that staff download.

What "HIPAA-compliant" can and cannot mean

HHS does not endorse or recognize private "certifications" of Security Rule compliance, and an outside certification does not stop HHS from finding a violation later. Compliance is ongoing and belongs to the organizations that handle PHI.

So "HIPAA-compliant" on a vendor's page can mean only that the product was built to support compliance: it will sign a BAA, and it has the safeguards above. Whether a given deployment meets HIPAA depends on how it is configured and run. When you describe your own app, say what you can show: a current risk analysis, BAAs in place, and the controls that answer each risk. A SOC 2 report or a HITRUST assessment can add independent evidence, but neither is a HIPAA certification.

How the approach differs by company stage

• Startups: one cloud account, a short vendor list and a first enterprise health customer. Get the BAA chain and hosting right before the first pilot, because moving PHI later is costly.
• Growing companies: more integrations with electronic health record systems, more staff with access, and customers asking for security reviews. The work is keeping access reviews, logs and vendor BAAs current as the product grows.
• Enterprises and health systems: many applications, shared identity, formal risk management. The focus is consistent controls across teams and evidence ready for internal audit and regulators.

See how we work with healthcare teams. We sign a Business Associate Agreement for engagements that involve protected health information.

Frequently asked questions

Does my wellness app need to be HIPAA-compliant?

Only if you handle PHI for a covered entity, or you are one. A consumer app people download on their own is often outside HIPAA, but the FTC's Health Breach Notification Rule and state laws may apply.

Is using AWS, Azure or Google Cloud enough to be HIPAA-compliant?

No. The cloud provider's BAA covers its part for specific services. You are still responsible for configuration, access, encryption settings, logging and everything in your application.

Is encryption required under HIPAA?

Encryption is an addressable specification, which means you must use it where reasonable and appropriate or document an equivalent alternative. For a modern cloud app, it is hard to justify not encrypting PHI in transit and at rest.

Can we use Google Analytics or a Meta pixel in a patient app?

Not in a way that sends PHI to the vendor without a permitted basis and a BAA. Many general advertising and analytics tools do not sign BAAs. Check before you use one, and keep those that will not out of logged-in areas.

Who can certify that our app is HIPAA-compliant?

No one, officially. HHS does not recognize private certifications. You can show a risk analysis, BAAs and independent evidence such as a SOC 2 report, but the legal obligation stays with you.