HIPAA Compliant AI Health Apps: How to Verify and Pick One

"HIPAA compliant" appears in a lot of health app marketing copy. It is used by apps that have undergone rigorous independent audits, by apps that have simply read the regulation and believe they comply, and by apps that use the phrase without any meaningful assessment at all. The phrase carries no certification mark, no government registry, and no automatic signal of trustworthiness.

This guide explains what HIPAA compliance actually requires for an AI health app, gives you a concrete verification checklist, identifies the red flags that distinguish legitimate platforms from those that are merely marketing the concept, and covers what happens with health apps that HIPAA does not cover at all.

---

What HIPAA Compliance Actually Requires for an App

HIPAA does not regulate software applications as a category. It regulates covered entities and business associates. Understanding whether an app is meaningfully HIPAA-eligible requires understanding both of these roles.

Covered Entities vs. Business Associates

A covered entity under HIPAA is a healthcare provider that transmits health information electronically, a health plan, or a healthcare clearinghouse. Most AI health apps are not covered entities; they are software products, not providers.

A business associate is any person or organization that creates, receives, maintains, or transmits Protected Health Information (PHI) on behalf of a covered entity. An AI health app that handles your medical records becomes a business associate when it enters a formal contractual relationship (a Business Associate Agreement, or BAA) with a covered entity (such as a hospital or physician group), or when it directly services individuals in a context where the covered entity is responsible for the care.

When an individual consumer directly downloads an app and uses it for personal health management without a covered entity in the chain, HIPAA generally does not apply to that transaction. This gap is significant and is discussed below.

The Business Associate Agreement Requirement

A BAA is a written contract required by 45 CFR 164.504(e) between a covered entity and its business associates. It establishes the permitted and required uses of PHI, prohibits the business associate from using PHI in ways that would violate HIPAA if done by the covered entity, and requires the business associate to report breaches and implement appropriate safeguards.

For an AI health platform to be operating in a HIPAA-compliant capacity for your data, a valid BAA must exist somewhere in the chain: either directly between the platform and a covered entity that is providing services to you, or between the platform and you as an authorized representative of a covered entity. Platforms that offer individual consumers a BAA as part of their service terms are specifically designing their product for HIPAA-eligible use.

As summarized in guidance from Holland & Hart, failure to execute a required BAA can subject covered entities and business associates to civil penalties ranging from $127 to over $1.9 million per violation depending on culpability, which gives legitimate platforms strong financial incentive to be rigorous about their BAA practices.

The Security Rule: Technical Safeguards

The HIPAA Security Rule (45 CFR Parts 160 and 164) establishes national standards for protecting electronic PHI (ePHI). For a health app, the most relevant technical safeguard requirements are:

Encryption at rest. Section 164.312(a)(2)(iv) addresses encryption of stored ePHI. While designated as "addressable" rather than "required," this classification is widely misunderstood. As detailed by HIPAA compliance specialists, encryption is effectively required in practice because: failing to implement it eliminates access to the breach notification safe harbor, and the documentation burden for justifying non-encryption is prohibitive under OCR scrutiny. AES-256 encryption satisfies HHS guidance for rendering PHI "unusable, unreadable, or indecipherable" per NIST standards.

Encryption in transit. Section 164.312(e)(2)(ii) requires encryption of ePHI transmitted over electronic communications networks. TLS 1.3 provides the strongest available transport layer encryption, using AES-256 cipher suites. Applications should be configured to require TLS 1.2 minimum, with TLS 1.3 preferred and older protocol versions disabled.

Access controls. Section 164.312(a)(1) requires procedures for authorizing access to ePHI, assigning unique user identifiers, and implementing automatic logoff mechanisms. Role-Based Access Control (RBAC) implements this by granting data access only to roles that require it for legitimate business purposes.

Audit controls. Section 164.312(b) requires hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Audit logs should capture who accessed what data, when, from where, and what changes were made.

Integrity controls. Section 164.312(c)(1) requires that ePHI is not improperly altered or destroyed.

The Privacy Rule

The HIPAA Privacy Rule governs the uses and disclosures of PHI. For an AI health app, this translates to: PHI may only be used for purposes that the individual has authorized, or that are otherwise permitted (treatment, payment, operations). A platform that claims HIPAA compliance but sells or shares user health data with third parties for advertising, research without consent, or other commercial purposes is violating the Privacy Rule, regardless of its security controls.

The Breach Notification Rule

Under 45 CFR Part 164 Subpart D, covered entities and business associates must notify affected individuals, HHS, and in cases of 500+ affected individuals, prominent media outlets, when unsecured PHI is breached. Notification to affected individuals must occur without unreasonable delay and no later than 60 calendar days after discovery. A HIPAA-compliant app must have a documented breach response process with these timelines built in.

---

The Verification Checklist

Before trusting a health AI app with your medical records or ongoing health data, ask or verify the following:

Item	What to Look For
BAA availability	Does the platform offer a signed BAA? Can individuals request one, or is it only available to enterprise clients?
Encryption at rest	AES-256 minimum. Ask for documentation or look for NIST/FIPS compliance statements.
Encryption in transit	TLS 1.3 preferred, TLS 1.2 minimum. Older versions (TLS 1.0, 1.1) should be disabled.
Audit logging	Are logs generated for all data access events? Are they available to you as the data subject?
Access controls	Does the platform use RBAC to limit who within their organization can access your data?
Data residency	Where are servers located? Are there data processing agreements for any non-US storage?
Breach notification SLA	What is the documented timeline for notifying you of a breach? The HIPAA requirement is 60 days maximum.
Privacy policy clarity	Does it explicitly prohibit using your health data for advertising or sale to third parties?
Independent audit	Has the platform undergone a HITRUST, SOC 2 Type II, or equivalent third-party security assessment?

---

What the BAA Process Actually Looks Like in Practice

When we were building the infrastructure for Vidaya, I went through the BAA process with four potential data vendors. Two of them had actual BAA templates, standard documents their legal teams had prepared, with defined PHI handling obligations, breach timelines, and subprocessor disclosures. That process took maybe two weeks.

The other two did not have BAA templates at all. Both said some version of "we can work something out" when asked. One offered to draft custom language. One suggested we schedule a call with their general counsel.

I disqualified both immediately. Not because I doubt those teams mean well. It is that the absence of a standard BAA template tells you something specific: the platform was not designed with HIPAA-eligible use as a core requirement. It was designed for something else, and HIPAA compliance is being improvised after the fact. Improvised legal infrastructure around protected health information is not something I am willing to accept, and neither should you.

This experience is the reason "Do you have a standard BAA template available for review before I commit?" is now the first question I ask any health data vendor.

---

Red Flags

Vague Privacy Policy Language

Phrases like "we take your privacy seriously" and "we do not sell your data to third parties" without specific definitions of what constitutes third-party data sharing are not meaningful protections. Look for explicit enumeration of permitted uses and a contractual commitment to the limitations.

No Published BAA Template

A legitimate HIPAA-eligible platform will have a BAA template available for review before you commit. Platforms that say "we can discuss a BAA with enterprise customers" but have no standard consumer BAA process are not designed for HIPAA-eligible use at the individual level.

"We Follow HIPAA" Without Proof

Self-attestation of HIPAA compliance without documentation, third-party audit reports, or a willingness to sign a BAA should be treated with skepticism. HIPAA compliance is not a certification that can be independently verified through a public registry; it depends entirely on the platform's internal practices and contractual commitments.

Free Services with No Business Model

If a health app is free and you cannot identify how it generates revenue, the data you provide is likely the product. Consumer health data is commercially valuable, and platforms without sustainable revenue from subscriptions or legitimate B2B arrangements have structural incentives to monetize user data.

---

How to Request a BAA: Template Language

If you represent an organization or are asking as an individual in a professional capacity, here is sample language to initiate the process:

"We are interested in using [Platform Name] to process protected health information as defined under 45 CFR 160.103. Before proceeding, we require a signed Business Associate Agreement that meets the requirements of 45 CFR 164.504(e). Please provide your standard BAA template for review, or confirm whether your platform is designed to operate in a HIPAA-eligible capacity for [individual users / enterprise clients]."

---

What HIPAA Does NOT Cover: The Consumer Gap

The most important thing to understand about HIPAA and consumer health apps is the coverage gap: HIPAA does not apply to apps that are not operating as business associates of a covered entity. If you download a wellness app, a fitness tracker companion, or a general-purpose AI chatbot and enter your health data, HIPAA's protections do not follow that data.

This gap is substantial. The FTC's Health Breach Notification Rule (HBNR), updated in April 2024 with an effective date of July 29, 2024, fills part of this space for non-HIPAA consumer health apps. The updated rule, which took effect in July 2024, requires vendors of personal health records and related entities not covered by HIPAA to notify individuals and the FTC when there is an unauthorized acquisition of health information, including unauthorized disclosures to advertising platforms. The rule covers health apps, fitness trackers, and other direct-to-consumer health technologies.

Key differences between HIPAA and the FTC HBNR:

• The HBNR applies to a breach after the fact and requires notification. HIPAA also mandates prospective security standards.
• HBNR penalties are enforced by the FTC, not HHS. Maximum civil penalties differ.
• HBNR does not require a BAA or prescribe specific encryption standards.
• HBNR covers "any unauthorized disclosure" including sharing data with advertising platforms, broader in some respects than HIPAA's breach definition.

For robust prospective protection, HIPAA-eligible platforms with signed BAAs remain the appropriate standard. The FTC HBNR is a floor, not a ceiling.

---

Frequently Asked Questions

Is any AI health app truly HIPAA compliant? An app itself cannot be HIPAA compliant: only a covered entity or business associate can comply with HIPAA through their practices, contracts, and technical safeguards. The meaningful question is: does this platform operate as a business associate, execute BAAs, and implement Security Rule technical safeguards? Legitimate platforms will answer yes to all three and provide documentation.

Do I need a BAA for personal use? If you are an individual consumer (not a covered entity or operating as one), HIPAA's BAA requirement technically does not apply to your personal use. But platforms that offer BAAs to individuals are voluntarily committing to HIPAA-grade data handling practices, which is meaningful even if not legally required. It is a signal of how seriously the platform takes its privacy obligations.

What does AES-256 encryption actually mean? AES-256 (Advanced Encryption Standard with 256-bit keys) is the encryption algorithm recommended by NIST for protecting sensitive data at rest. HHS guidance points to NIST standards for rendering PHI "unusable, unreadable, or indecipherable." Platforms using AES-256 with proper key management qualify for the HIPAA breach notification safe harbor if encrypted data is compromised but the keys are not.

What is TLS and why does the version matter? Transport Layer Security (TLS) encrypts data transmitted over networks. TLS 1.0 and 1.1 have known vulnerabilities and should not be used. TLS 1.2 is the current minimum acceptable standard. TLS 1.3 is the strongest version, offering improved performance and security. Any health app handling PHI in transit should use TLS 1.2 at minimum.

What should I do if a health app I use has a data breach? Under the updated FTC Health Breach Notification Rule (effective July 2024), non-HIPAA health apps must notify you of breaches involving your health information without unreasonable delay and no later than 60 days after discovery. If you receive such a notice, change your password, enable multifactor authentication, monitor for any downstream misuse of the specific data exposed, and consider whether the platform's security posture warrants continued use.

How does Vidaya handle my data? Vidaya's Vaya Chat is built on HIPAA-eligible infrastructure with AES-256 encryption at rest, TLS 1.3 in transit, audit logging, and RBAC. BAA execution is available for qualifying users. Health data is never used for advertising or sold to third parties. Plans start at $10 per month or $89 per year at vidaya.ai.

---

Related reading:

• Sharing Medical Records With AI: What's Safe in 2026
• Health Data Privacy Overview
• Apple Health Data Explained
• Longevity Protocols

---