BOLO Insights & Legal Updates

A Health App Is Not Automatically HIPAA-Covered: What Digital Health Businesses Must Check in 2026

BOLO Health Law, LLC | November 1, 2026 | Technology, AI, Data Privacy, and Healthcare Compliance

A founder launches a symptom tracker, a wellness marketplace, a fertility journal, or a connected-device dashboard. The product collects information that consumers reasonably regard as deeply private. The company responds with a familiar claim: “We are HIPAA compliant.” That language may be inaccurate, incomplete, or both. Some products are regulated by HIPAA; others are not. Some products that fall outside HIPAA nevertheless face substantial obligations under federal and state consumer protection and health-data laws.

For digital health companies, the right first question is not which badge to place on a website. It is who holds the data, whose behalf they are acting on, how the information moves, and what promises have been made about privacy. Once those facts are mapped, the legal analysis becomes more reliable. A modern privacy program cannot be built solely by copying a hospital’s notice of privacy practices or purchasing a standard business associate agreement.

HIPAA applies to defined entities and relationships

The HIPAA Privacy and Security Rules regulate covered entities and their business associates in connection with protected health information. Covered entities generally include health plans, healthcare clearinghouses, and healthcare providers that conduct specified electronic transactions. A vendor may be a business associate when it performs covered functions or services involving protected health information for or on behalf of a covered entity.

The fact that an application records blood pressure, sleep, symptoms, medications, or menstrual health information does not by itself make the app developer a HIPAA covered entity. Conversely, a software business cannot avoid HIPAA simply by calling itself a technology company if it is in fact serving a covered provider as a business associate. The contract, services, data flows, and actual operations matter more than marketing labels.

A patient-directed app can present a different relationship

The U.S. Department of Health and Human Services has explained that when an individual directs a covered entity to send electronic protected health information to an independent app that is neither a covered entity nor a business associate, HIPAA generally does not regulate the app’s subsequent uses of the information. That differs from an app furnished by or for a healthcare provider as part of patient services, where a business-associate relationship may exist.

A product can have more than one data flow. One customer may sync data independently; another clinic may license the platform to deliver care. Those arrangements may create different obligations inside the same company. A business should diagram each product integration rather than describe all user information as covered or uncovered by a single rule.

Outside HIPAA does not mean outside the law

Companies handling consumer health information may still be subject to Section 5 of the FTC Act, the Federal Trade Commission’s Health Breach Notification Rule, state privacy laws, contract duties, and other sector-specific requirements. Statements about encryption, sale of data, tracking, deletion, and third-party sharing should match actual practices. A privacy policy that promises something the engineering team cannot deliver is a risk even if HIPAA does not apply.

The FTC and HHS have published joint guidance encouraging companies to be transparent about health information handling. It is dangerous to bury material data practices in confusing terms and then rely on a broad consent checkbox. Meaningful consent depends on what the consumer actually understands and what the product actually does. A company should be able to identify every material recipient or category of recipient of health-related data.

Understand the FTC Health Breach Notification Rule

The Health Breach Notification Rule, 16 C.F.R. Part 318, applies to qualifying vendors of personal health records, personal-health-record-related entities, and certain third-party service providers. The updated rule clarified its reach to health apps and connected devices. Coverage requires an analysis of definitions, including whether a qualifying electronic personal health record has the technical capacity to draw information from multiple sources and is managed, shared, or controlled by or primarily for the individual.

When a covered entity experiences a qualifying breach of unsecured individually identifiable health information, the rule can require notice to affected people, the FTC, and in some cases the media. The meaning of breach is not confined to a hacker breaking into a database: certain unauthorized disclosures can matter. Do not assume an incident is outside the rule because the IT team found no malware.

The 2026 FTC policy-statement withdrawal is not a repeal

In September 2026, the FTC announced withdrawal of its 2021 policy statement concerning health apps and connected devices. The Commission explained that the 2024 amendments had addressed the same subject through rulemaking and made the older policy statement unnecessary. The withdrawal did not itself repeal the 2024 amended Health Breach Notification Rule.

This distinction is important for businesses reading headlines or older compliance blogs. An opinion about a policy statement is not the same as the text of a binding regulation. A compliance analysis should start with the current rule, applicable agency guidance, and the actual product architecture. A company that removes its notification processes because it heard “the FTC rolled back health-app rules” would be relying on an oversimplification.

Map information from collection to deletion

Prepare a data-flow inventory for the product. Identify the data subject, source, device, API, application database, analytics provider, customer support system, cloud service, advertising tool, and eventual deletion or archival path. Note whether information is linked to identifiers that could identify a person, including device identifiers or persistent online IDs.

Companies should know whether data used for algorithm training, product improvement, fraud detection, marketing, and support are handled differently. If a data set is called de-identified, analyze whether the applicable legal standard is actually satisfied. Pseudonymization and removal of a displayed name do not necessarily make information anonymous. The inventory should record which vendor can access the information and for what purpose.

Analytics and advertising deserve their own review

A product team may install analytics software for an entirely sensible reason: understanding where users abandon an onboarding screen. But health-related events, page titles, form fields, and personal identifiers may travel to tracking vendors in ways that are difficult to detect from the front end. For HIPAA-regulated entities, HHS has published specific guidance about tracking technologies. Independent health apps may face FTC Act and other obligations even when HIPAA does not govern the transaction.

Review the actual payloads and vendor configuration. Do not limit the assessment to a list of approved tools. The same analytics vendor can receive innocuous page-view data from one screen and sensitive health-related data from another. Marketing and engineering should have a documented approval procedure for new trackers and new uses of customer information.

Draft a contract that matches the relationship

A business associate agreement should not be used as a generic privacy warranty for every digital health relationship. If the parties are within HIPAA’s business-associate framework, the agreement must address appropriate regulatory elements and allocation of responsibilities. If they are not, they may still need a robust data protection agreement that addresses permitted uses, security, incident notice, vendor subprocessors, retention, deletion, and audit rights.

For a company offering both consumer and provider-facing products, separate contracting pathways can be essential. An organization that inadvertently blends consumer data with provider records may struggle to honor deletion requests or enforce different rules. The agreement should match technical reality and establish which party must respond to individual requests, investigations, and security incidents.

Prepare for incidents before one happens

A breach plan should identify who declares an incident, isolates systems, collects logs, retains forensic specialists, notifies legal counsel, and evaluates reporting obligations. Preserve the first alert, evidence of unauthorized acquisition or disclosure, affected data types, number of potentially affected users, and mitigation steps. Do not select a notification timeline by memory; determine which law applies and when the clock starts under that law.

For covered entities under the FTC’s health breach rule, notification timing differs depending on the type of recipient and scale of the breach. For HIPAA covered entities, a different regulatory framework applies. State laws, contractual promises, and cross-border issues may add obligations. Coordinated legal and technical response reduces contradictory statements and accidental destruction of evidence.

Privacy needs to appear in product governance

A credible health-tech compliance program uses review gates before new products, integrations, ad campaigns, AI features, or vendor relationships go live. A product manager should be able to explain what data is collected and why; an engineer should be able to confirm where it goes; and legal counsel should be able to evaluate the resulting obligations. The right answer may be to minimize collection, change default settings, obtain clearer consent, or decline to share certain information.

Schedule periodic reviews when products change, not just once a year. A practice that was compliant when the app launched may be materially different after adding wearable synchronization, AI summaries, or new advertising pixels. Privacy is a feature of operations, not a one-time policy-writing project.

A practical founder’s starting checklist

Ask five questions: Who is our customer? For whom do we act? What data do we actually collect and disclose? Which laws apply to each product workflow? Can our systems perform what our terms and privacy policy promise? Then review security agreements, incident response, and user communications. Those answers establish a foundation for due diligence, clinical partnerships, fundraising, and honest consumer trust.

Request counsel. BOLO Health Law advises healthcare businesses and technology companies on digital health contracting, privacy, regulatory classification, vendor agreements, and operational compliance. Arrange a consultation at BOLO Health Law.

This article supplies general legal information as of November 1, 2026. It does not determine whether any specific product is HIPAA regulated or covered by the FTC’s Health Breach Notification Rule. An attorney-client relationship requires an accepted engagement.

Sources and further reading

Need counsel for the facts behind the issue?

General legal education cannot assess the records, contract terms, procedural posture or deadlines in your own matter. BOLO reviews select matters involving healthcare providers, regulated businesses and individuals, subject to conflicts, scope and jurisdiction.

Read how BOLO researches and reviews legal content. Do not send confidential records through public inquiry forms. Contact alone does not establish representation or extend any deadline.