A telehealth or online health coaching platform has to answer a question most other businesses never face before writing a single line of privacy policy: is this HIPAA, or isn't it? The answer changes almost everything downstream, which documents you need, what a breach notification obligation looks like, and how carefully you have to word the sections on video recording and intake forms. Getting that scoping question wrong in either direction, assuming HIPAA applies when it doesn't or waving it away when it does, is the most common mistake in this category, and it shows up in the policy as either bloated language nobody can act on or gaps that leave real health data underprotected.
Two starting points: HIPAA-covered care vs. non-HIPAA coaching
HIPAA does not cover every business that touches health information. It covers "covered entities," health plans, health care clearinghouses, and health care providers who transmit health information electronically in connection with certain standard transactions, plus their "business associates," the vendors and platforms that create, receive, maintain, or transmit protected health information on a covered entity's behalf. A telehealth platform that hosts video visits for a licensed physician group, and that group bills insurance electronically, is almost always a business associate and needs a signed Business Associate Agreement (BAA) with that provider before any patient data flows through it.
An online health coaching or wellness platform is frequently a different story. If no licensed clinician is diagnosing or treating anyone through the platform, coaching, symptom education, habit tracking, meal planning, and similar services generally fall outside HIPAA's definition of health care, and the platform is not a covered entity or business associate no matter how sensitive the information it collects looks. This is why so many wellness apps state plainly, "we are not a HIPAA covered entity," a true statement that surprises users who assume anything health-related is automatically HIPAA-protected.
The gray zone sits between those two poles: a direct-to-consumer telehealth platform that connects users with licensed providers but does not bill insurance, and where the provider does not otherwise engage in HIPAA standard electronic transactions, can end up genuinely unclear on covered-entity status. That determination depends on the specific business model and the provider's other activities, not just on whether care is delivered, so it is worth confirming with counsel rather than defaulting to either assumption.
What actually changes between the two paths
The practical difference between a HIPAA-covered telehealth policy and a non-HIPAA wellness policy is not cosmetic. It changes which documents exist, who signs them, and which breach notification clock starts ticking if something goes wrong.
HIPAA telehealth vs. non-HIPAA wellness coaching
| HIPAA telehealth | Non-HIPAA coaching | |
|---|---|---|
| Typical trigger | Provider diagnoses or treats on platform | Coaching or education, no diagnosis |
| Governing framework | HIPAA Privacy and Security Rules | FTC Health Breach rule + state law |
| Vendor agreement | Business Associate Agreement (BAA) | Standard vendor DPA, no BAA needed |
| Core disclosure doc | Notice of Privacy Practices | Privacy policy names health data |
| Breach notice rule | HIPAA Breach Notification Rule | FTC Health Breach Notification Rule |
That last row matters more than it looks. The FTC's Health Breach Notification Rule was written for personal health record vendors and was clarified in 2024 to reach health apps and similar consumer-facing technologies that are not HIPAA covered entities but still handle identifiable health information. A wellness platform that assumes "we're not HIPAA, so breach notification doesn't apply to us" is very likely wrong, it is under a different notification rule, not no rule at all.
Disclosing video-session recording
Whether or not HIPAA applies, if the platform records video visits, coaching calls, or check-ins, that recording sits at the intersection of two separate legal requirements that a policy needs to address distinctly. The first is wiretap and eavesdropping law: many states require all-party consent before a conversation can be recorded, not just the one-party consent baseline set by the federal Wiretap Act, so a platform serving users nationwide has to assume the stricter all-party standard applies somewhere in its user base and design consent flows around that, rather than the laxer rule of wherever the company happens to be based. The second is telehealth-specific informed consent, several state medical practice acts require a separate informed consent to the telehealth encounter itself, distinct from consent to being recorded, covering things like the limitations of a remote visit compared to in person care.
The practical fix is the same for both: get explicit, affirmative consent to recording at the start of each session, inside the product itself, not buried only in a privacy policy nobody rereads before every call, and then describe that same practice plainly in the policy so it is auditable after the fact. A privacy policy clause that just says recordings "may occur" without saying who consents, how long recordings are kept, or who can access them is the version that draws scrutiny.
- Sessions may be recorded for quality purposes.
- No mention of consent, storage location, or who can access the recording.
- Video sessions are recorded only when you and your provider both agree at the start of the call.
- Recordings are encrypted, kept 90 days, and used only for your care record, never marketing.
Intake forms collect some of the most sensitive data a business will ever handle
Before a first appointment or coaching session even happens, most telehealth and health coaching platforms run new users through an intake form: medical history, current medications, mental health screening questions, symptoms, sometimes a self-reported diagnosis. This is squarely the kind of data that privacy law treats as a special, higher-protection category rather than ordinary personal information. Under GDPR, health data is a special category under Article 9, requiring explicit consent or another narrow Article 9(2) condition before it can be processed at all. Under the newer wave of US state comprehensive privacy laws, it typically falls inside the "sensitive personal information" or "sensitive data" definition, which usually requires opt-in consent rather than the opt-out standard that applies to ordinary data.
Washington's My Health My Data Act is worth naming specifically because it was written to reach exactly the platforms that assume they are safely outside HIPAA. It defines "consumer health data" broadly enough to cover wellness and coaching information that never touches a licensed provider, requires consent before collecting or sharing it, bans the use of geofencing around health care facilities for advertising or data collection purposes, and creates a private right of action, meaning a consumer, not just a regulator, can sue over a violation. California's Confidentiality of Medical Information Act similarly reaches a wider set of businesses than HIPAA's covered-entity definition, including apps that are not run by licensed providers at all.
For an intake form specifically, the policy needs to name the categories collected in plain language, state the purpose narrowly (delivering the service, not "improving our products" as a catch-all), commit to not selling or sharing that data for advertising, and describe how long it is retained after an account is closed. Vague language here reads the same way a vague recording clause does, as a business that has not actually mapped what it collects.
Building the policy without over-scoping or under-scoping
The FTC's 2026 complaint against Hims & Hers, alleging the telehealth company shared patients' health data with Meta and Snap despite public promises to protect it, is a useful reminder that this is not a theoretical risk category. Regulators are actively watching the gap between what health platforms say in their privacy policy and what their advertising pixels and analytics tags actually do, and the state privacy law landscape that governs health data outside HIPAA keeps expanding, not shrinking.
The right approach is to determine which of the two starting paths above actually applies to your platform, state that determination plainly rather than hedging around it, and then build the recording and intake-form sections with the specific consent, storage, and retention language a reviewer or regulator would look for, rather than generic health-privacy boilerplate copied from a template that assumed a different business model. Our Privacy Policy Generator walks through this scoping question directly and builds the HIPAA-specific or non-HIPAA sensitive-data sections accordingly, so the policy that ships matches what your platform actually does instead of what a generic health-app template assumed it would.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
