HIPAA Requirements for Video Telehealth Platforms

Most providers treat telehealth compliance as a single decision: pick a decent video platform, and the rest sorts itself out. That assumption is wrong, and it's the reason practices drift out of compliance without ever noticing the drift. Compliance actually runs across four distinct layers, and a gap in any one of them creates exposure no matter how well the other three get handled.

Layer one is the video platform: its technical safeguards, its BAA status, its encryption, its access controls. Layer two is the patient's physical environment during the call. Could a family member or coworker overhear a diagnosis, and has the provider given documented guidance on finding a private room before the session starts? Layer three is the provider's own workspace, often a home office running on a shared household laptop. That machine needs its own encryption, its own screen lock, and login credentials that belong to nobody but the provider using it. Layer four is recording handling: does a recording of the session exist, did the patient give explicit consent to it, and does that file live in a HIPAA-compliant system with encryption at rest, rather than in someone's personal cloud photo backup.

Most compliance failures trace back to scope, not ignorance. A practice pours real effort into locking down the video platform, feels good about the progress, and never circles back to check where last Tuesday's recording landed, including whether it reached someone's personal photo backup app. Fixing one layer and calling the job finished is the mistake to avoid. All four layers need ongoing attention, or the other three stop mattering.

Business Associate Agreements: the contractual requirement that disqualifies most consumer platforms

Any vendor that transmits, processes, or stores PHI on a provider's behalf has to sign a contract spelling out its responsibilities for that data. That's a legal floor, not a nice-to-have, and HHS guidance at telehealth.hhs.gov states it without hedging: covered providers must use vendors willing to enter into HIPAA BAAs for their video communication products.

A valid BAA has to spell out the permitted and required uses of PHI, bar the vendor from using that data for anything outside those uses, and require the vendor to put safeguards in place to protect it. It has to require breach notification to the covered entity within 60 days of discovery. It has to say what happens to the data once the relationship ends (return it or destroy it), and it has to guarantee HHS can pull relevant records during a compliance investigation.

Encryption does not substitute for a BAA, and that mix-up trips up more practices than any other single error. A vendor whose servers keep persistent access to ePHI counts as a business associate no matter how well that data gets encrypted in transit or at rest. Encryption lowers risk. It doesn't touch the vendor's legal status, and it doesn't remove the requirement for a signed agreement.

The other common mistake: assuming a click-through on a vendor's terms of service counts as agreeing to a BAA. It usually doesn't. Plenty of vendors bury their BAA language deep in general terms, or require a separate opt-in step that practitioners never complete because nobody told them it existed. If a vendor refuses to sign a BAA, or claims one isn't necessary for a given use case, that platform is off the table for anything touching PHI. No feature list changes that math.

The obligation doesn't stop at the video call. Secure messaging tools, remote patient monitoring vendors, cloud storage providers, EHR systems: any vendor touching PHI anywhere in the telehealth workflow needs its own signed BAA. Treating the video platform as the only piece that matters leaves the rest of the stack wide open.

Technical safeguards: what encryption, access controls, and audit logging require

HIPAA's Security Rule breaks technical safeguards into five standards, and a platform has to meet all five, not just whichever ones look good on a sales page: access control, audit controls, integrity, person or entity authentication, and transmission security.

Encryption gets the most attention, but the standard is exact. Data at rest needs AES-256. Data in transit needs TLS 1.2 or higher. Video sessions need end-to-end encryption, so that only the provider and the patient, nobody sitting on the vendor's infrastructure in between, can get at what's being said. That covers the video and audio streams themselves, any chat messages exchanged mid-session, and any files transferred during the call.

Access control gets more demanding than most practices expect going in. Shared logins are out. Every user needs a unique ID, role-based access has to be running so front-desk staff see only what their role calls for, and multi-factor authentication, a password paired with a biometric check or a mobile token, is required. Emergency access needs its own documented workflow for the rare case someone needs an override. Virtual waiting rooms and meeting locks keep uninvited participants from wandering into a session, and sessions need to time out automatically after a stretch of inactivity.

Audit controls call for logging that's thorough and unchangeable at once: a record of who accessed what, and when, that nobody can quietly edit after the fact. Collecting the logs isn't the finish line, either. Someone has to actually review them on a set schedule, and any session or clinical data being retained needs secure storage sitting behind that logging.

On the provider's end, the same device rules from the home-office layer apply again: screen lock, device encryption, a login that belongs to exactly one person.

Most consumer apps fail the moment you run them against this bar. Standard Zoom, FaceTime, free Google Meet, Skype, WhatsApp: none of them offer a BAA on their free or standard consumer tiers, and several store data or track behavior in ways that miss the safeguards above. That is a checklist item, not an opinion, and it stands on the safeguards described above. It's a checklist, and these platforms don't clear it.

Which platforms are confirmed HIPAA-compliant

Compliance status varies platform by platform, and often tier by tier within the same platform, which is exactly where providers get caught out. Picking the wrong tier of the right platform means the BAA a practice thinks it has doesn't exist.

Zoom for Healthcare requires a paid plan that includes BAA eligibility. The consumer or free tier doesn't qualify, no BAA gets offered on it, and the qualifying healthcare tier gives AES-256 encryption, virtual waiting rooms, and EHR integrations with systems like Epic and Cerner. SimplePractice Telehealth integrates with the SimplePractice EHR and offers a BAA. Teladoc and Amwell, both enterprise telehealth platforms, offer BAAs. VSee is built for low-bandwidth environments, which matters for rural clinics and mobile health units working off unreliable connections. Several other purpose-built clinical video platforms offer comparable combinations of encryption, audit trails, and EHR integration. Microsoft Teams qualifies for a BAA only on paid Microsoft 365 Business and Enterprise plans (Business Basic, Standard, Premium, E3, or E5); standard Teams outside those plans doesn't qualify. Healthie also offers a BAA.

On the other side of the line: the free consumer tier of Zoom offers no BAA. FaceTime never offered one, and Apple hasn't changed that since the COVID waiver expired. Free or standard consumer-tier Google Meet doesn't qualify, though a BAA becomes available on any paid Google Workspace plan starting at Business Starter. Consumer Skype gets no BAA from Microsoft, though Skype for Business may fall under a BAA through qualifying Microsoft 365 enterprise plans. WhatsApp has never been HIPAA compliant: no BAA, no required audit controls, no access controls meeting the standard.

None of this comes down to marketing copy or a badge on a vendor's homepage. Compliance gets decided by the safeguards actually running and the contracts actually signed, and the only way to know for certain is to confirm a signed BAA sits in place before the first patient session, not after someone mentions one might be needed.

Administrative safeguards: the documentation and training requirements that technology cannot replace

Even with the right platform and a signed BAA, a practice isn't compliant until the paperwork side gets handled, and no software fixes this part for you.

A documented risk analysis is mandatory, and it has to cover every telehealth platform and workflow in use. It has to identify and assess risk to PHI across all four layers described above, and it has to get updated whenever a new vendor enters the workflow. Writing the risk analysis once and filing it away is itself one of the most common findings in enforcement actions; plenty of practices still treat it as a box to check rather than a living document.

Policies and procedures need to exist in writing: how telehealth consent gets documented, why a given platform was chosen, when recording is allowed and how consent for it gets captured, what security standard a provider's home office has to meet, and what the escalation steps are if a breach happens.

Patient consent carries its own layer of complexity. HIPAA requires the standard Notice of Privacy Practices acknowledgment, but many states add independent telehealth consent requirements on top of that federal floor. CMS separately requires documented patient consent for Medicare telehealth services. Good practice means written or electronic informed consent covering the nature of telehealth, its limitations, privacy considerations, the patient's right to withdraw, what happens if the technology fails mid-session, and emergency protocols. Mental health and substance abuse telehealth carries additional federal confidentiality rules stacked on top of everything else.

Workforce training has to be specific to count for anything. Generic HIPAA training that never mentions the platforms actually in use, or the policies actually adopted, doesn't satisfy the requirement. Every workforce member touching a telehealth workflow needs training built around the privacy and security risks of that particular workflow.

State law stacks another layer on top of the federal floor. Nevada's SB 370 imposes its own consent, notice, and security duties, along with geofencing restrictions. California's AB 352 requires segmentation and access limits for sensitive services and restricts disclosures across state lines. Connecticut bars geofencing within 1,750 feet of mental health or reproductive and sexual health facilities. Because the patient's physical location at the time of service decides which state's licensure and privacy rules apply, a provider treating patients across state lines is juggling more than one rulebook at once, sometimes without realizing it.

What OCR is enforcing and what it keeps finding

OCR launched a HIPAA risk analysis enforcement initiative in 2023, and it's still running. OCR resolved 21 settlements and civil monetary penalties in 2025, the second-highest annual total on record, collecting $8,330,066, reporting from metricstream.com shows. Incomplete or missing risk analysis was the most commonly cited deficiency.

OCR is mainly catching organizations that did a risk analysis, filed the report, and then did nothing about it. It's catching organizations that did one, filed the report, and then did nothing about it, letting the same vulnerability sit there unaddressed until something finally exploits it. That's a different failure than ignorance. It's closer to inertia, and it's the exact failure OCR's current enforcement posture is built to catch.

Most of the major settlements OCR announced across 2024 and 2025 cite inadequate risk analysis as a central failure, though some settlements address other compliance deficiencies as well. The scale behind these numbers is significant on its own: clearwatersecurity.com reports that large HIPAA breaches affected more than 286 million individuals in 2024, and in 2025, 76% of large breaches traced back to hacking and IT incidents. The financial exposure runs well past whatever OCR levies directly, too. The average healthcare data breach now costs $7.42 million, the highest figure of any industry for the 14th consecutive year, myabt.com reports.

OCR's posture heading into 2026 makes one thing clear: it wants active, continuous risk management, not a document signed once and forgotten in a drawer. A signed BAA and a properly configured platform aren't enough on their own if a practice can't produce an updated risk analysis covering its actual telehealth workflows.

AI tools in the telehealth stack: the BAA and configuration requirements providers are missing

Because AI tools have quietly worked their way into the telehealth workflow, appearing in note-taking, transcription, and clinical documentation, the compliance gap runs wider here than anywhere else in the stack. Most practices have no idea how wide.

Consumer tiers of AI tools generally come with no BAA attached, and providers should verify BAA availability before using any such tool in a clinical workflow. Pasting a patient note into a chatbot that lacks a signed BAA risks an impermissible PHI disclosure, and it happens constantly because it doesn't register as a disclosure to the person doing it. It just feels like using a tool to save ten minutes.

Enterprise-grade configurations change the picture, but only partway. Azure OpenAI, for instance, can be set up for HIPAA-regulated use. A signed BAA alone doesn't guarantee that setup got done correctly, though. Providers bringing AI tools into a telehealth workflow need to confirm, in writing, what the vendor's BAA actually covers, how the specific deployment is configured, and where the data that tool generates ends up living once the session ends. Skipping that confirmation step can leave a practice looking compliant on paper for its video platform while leaking PHI through the AI tool running right next to it.