HIPAA Compliance for Telehealth

The Notification of Enforcement Discretion for telehealth ended on May 11, 2023. That's not news anymore, but the compliance gap it revealed still exists in most telehealth practices I review. During the enforcement discretion period, OCR allowed covered entities to use non-HIPAA-compliant communication platforms for telehealth without penalty. That window closed, and providers needed to implement proper HIPAA compliance controls for every telehealth platform, device, and transmission method they use.

The challenge is that telehealth's attack surface is fundamentally different from traditional clinical settings. You're moving protected health information through consumer-grade networks, into patient homes with uncertain security postures, and relying on platforms built for general communication rather than healthcare. The HIPAA Security Rule didn't change, but the environment in which you're applying it did.

I've worked with enough telehealth providers to see the patterns. Most have addressed the obvious items—platform selection, maybe a Business Associate Agreement with their video vendor. But transmission security in transit, device management, documentation of risk decisions, and the entire home-environment variable are being treated as edge cases when they're actually core compliance requirements.

The Platform BAA Is Just the Starting Point

Every telehealth platform that transmits, stores, or processes PHI must have a signed Business Associate Agreement in place. This isn't optional, and it's not satisfied by a vendor's assurance that they're "HIPAA compliant." If the platform has access to PHI in any form, they're a business associate under the rule, and you need a BAA that meets the regulatory standard.

The problem is that most providers think getting the BAA signed is the finish line. It's not. The BAA establishes a legal relationship and shifts certain obligations to the vendor, but it doesn't eliminate your responsibility to assess the platform's actual security capabilities. I've reviewed dozens of telehealth BAAs that were signed without any technical review of encryption standards, access controls, or audit logging. The covered entity assumes that because the vendor offered a BAA, they must be doing everything correctly.

That assumption is dangerous. A BAA is a contract, not a certification. You still need to understand what encryption the platform uses in transit and at rest, how authentication is managed, whether session timeouts are enforced, and how access logs are maintained. These are technical controls that should inform your risk assessment and platform selection, not afterthoughts.

What to Review Before You Sign

Before you execute a BAA with any telehealth vendor, get their security documentation. Ask for:

• Details on encryption protocols used for video, audio, and chat transmission
• How they handle PHI at rest—whether recordings, transcripts, or session metadata are encrypted
• Authentication mechanisms and whether they support multi-factor authentication for provider accounts
• How they manage session security, including timeouts and reconnection protocols
• Audit logging capabilities and how long logs are retained
• Their breach notification process and timeline
• Evidence of third-party security assessments, such as SOC 2 Type II reports or HITRUST certification

If the vendor can't provide clear answers to these questions, that's a red flag. The existence of a Business Associate Agreement doesn't compensate for weak technical controls or opacity about how they're actually securing PHI.

The Consumer Platform Problem

During the enforcement discretion period, OCR permitted the use of everyday communication tools—FaceTime, Zoom's free tier, Skype, Google Meet—for telehealth visits. That flexibility ended. Using a consumer-grade platform without a BAA and without appropriate safeguards is now a violation.

Some providers never transitioned away. I still encounter practices using standard Zoom accounts or Microsoft Teams without healthcare-specific BAAs, assuming that because these platforms offer encryption, they're sufficient. They're not. Consumer versions of these platforms typically don't meet the access control, audit logging, or agreement requirements that HIPAA mandates. The healthcare editions exist for a reason.

If you're still using a consumer platform, transition to a healthcare-specific solution with a proper BAA. If you've already made that transition, audit your configuration to ensure the security settings are actually enabled and enforced across all provider accounts.

Transmission Security Isn't Just About the Video Feed

The HIPAA Security Rule requires transmission security for all electronic PHI. Most telehealth compliance efforts focus on the video platform itself, but PHI moves through more channels than the live video feed. Screen sharing during a visit, file uploads for patient documents, chat functions for sharing instructions or prescription details, and email follow-ups all represent transmission of PHI. Each channel needs to be secured.

In my experience, the file upload and chat features are the least-reviewed components of a telehealth workflow. Providers will ensure that the video connection is encrypted, but they won't check whether a patient uploading a photo of a rash or a scanned lab result is using an encrypted upload path. They won't verify that chat transcripts are stored securely or whether they're automatically purged after the session ends.

These aren't hypothetical gaps. I've seen telehealth platforms where the video was encrypted end-to-end, but the chat function logged messages to an unencrypted database accessible to the platform vendor's support team. The BAA covered the video service, but the chat function was treated as a general-purpose feature with no special PHI protections.

Email and Scheduling Tools

Email is another transmission vector that gets overlooked. Appointment confirmations, pre-visit instructions, and post-visit summaries are often sent via standard email without encryption. If those messages contain PHI—appointment times linked to diagnoses, treatment instructions, or billing codes—they need to be secured.

The HIPAA Security Rule doesn't mandate encryption for all email, but it requires a risk assessment to determine whether encryption is necessary based on the content and risk. For telehealth, where email is a routine part of the patient communication workflow, encryption should be the default. Use a secure patient portal, encrypted email solutions, or limit email content to the minimum necessary information without including PHI.

Scheduling tools are similar. Many telehealth platforms integrate with third-party scheduling systems. If the scheduler has access to patient names, contact information, appointment reasons, or provider notes, it's handling PHI and needs a BAA and appropriate security controls. Don't assume that because the scheduling tool is separate from the video platform, it's out of scope.

The Home Environment Is Now Part of Your Compliance Perimeter

Traditional clinical settings give you control over the physical and network environment. You can enforce device policies, segment networks, control who has physical access to workstations, and monitor network traffic. Telehealth moves that perimeter to the patient's home and the provider's home if they're conducting visits remotely. You lose most of that control.

From the provider side, you need to ensure that clinicians working from home are using secure devices, connecting through secure networks, and following the same access controls they would in the office. That means issuing or managing provider devices, prohibiting use of personal laptops or tablets for telehealth unless they meet your security standards, and requiring VPN use or other secure connection methods if the provider is on a home network.

I see two common failures here. The first is allowing providers to use personal devices without any endpoint management or security baseline. The provider's home laptop becomes a telehealth workstation, but it's also used for personal browsing, family members have access to it, and there's no encryption, no antivirus, no patch management. That's a violation waiting to happen.

The second failure is assuming that because the provider is on their home network, it's automatically private and secure. Home networks are not controlled environments. Weak passwords, outdated router firmware, and shared access with other household members all create risk. Require providers to use organizational VPNs or other secure connection methods, and provide guidance on basic home network security practices.

The Patient Side Is Harder

You have even less control over the patient's environment. You can't dictate what device they use, what network they connect through, or who else is in the room during the visit. But you still have obligations to address those risks.

Start with patient education. Provide clear instructions before the visit about using a private space, avoiding public Wi-Fi, and ensuring that others aren't listening in. You can't enforce this, but you can document that you've advised the patient and obtained their acknowledgment. That's part of your risk mitigation strategy.

For the device and network side, your platform should support encryption that protects the transmission regardless of the patient's device or network security posture. End-to-end encryption ensures that even if the patient is on an unsecured network, the PHI in transit is protected. This is a platform requirement, not something you can address after the fact.

Finally, consider the visual and audio environment. Patients may be in shared living spaces, using devices with screens visible to others, or using speakerphone in areas where conversations can be overheard. Your pre-visit instructions should address this, and your policies should document that you've informed patients of these risks and their responsibility to secure their own environment where possible.

Device Management and Endpoint Security

If your providers are using organizational devices—laptops, tablets, or smartphones issued by the practice or health system—you have the ability to enforce security controls. Encryption, antivirus, patch management, remote wipe capabilities, and screen lock policies should all be in place. These are the same controls you'd enforce for any device accessing your electronic health record system, and they apply equally to telehealth endpoints.

Mobile device management (MDM) or endpoint management platforms make this enforceable. You can require encryption, push security updates, enforce password policies, and remotely lock or wipe devices if they're lost or if a provider leaves the organization. If you're not managing telehealth devices this way, you're accepting risk that's entirely avoidable.

The harder question is bring-your-own-device (BYOD) scenarios. Some smaller practices allow providers to use personal devices for telehealth to avoid the cost of issuing organizational hardware. This is risky, but if you're going to permit it, you need to enforce minimum security standards through MDM, containerization, or virtual desktop solutions that isolate the telehealth session from the rest of the device.

Virtual Desktop Infrastructure as a Control

One approach I've seen work well for practices with remote providers is requiring all telehealth sessions to occur through a virtual desktop infrastructure (VDI) or remote desktop environment. The provider connects to a managed, secure desktop hosted by the organization, and the telehealth platform runs in that environment. The provider's personal device is just a thin client, and PHI never resides on the local device.

This doesn't eliminate all risk—you still need to secure the connection, authenticate the user, and ensure the VDI environment itself is hardened—but it significantly reduces the endpoint security burden and gives you centralized control over the telehealth application environment.

Documentation and Risk Analysis

The HIPAA Security Rule requires a risk analysis that identifies threats to ePHI and implements safeguards to reduce those risks to a reasonable and appropriate level. Telehealth introduces specific risks that need to be documented and addressed in your analysis: transmission over public or home networks, use of home environments, reliance on third-party platforms, and variable patient endpoint security.

Your risk analysis should identify each of these areas, assess the likelihood and impact of potential threats, and document what safeguards you've implemented. For risks you can't fully eliminate—like the patient's use of an unsecured home network—document what you've done to mitigate the risk and why your approach is reasonable given the operational context of telehealth.

This isn't about achieving perfect security. It's about demonstrating that you've identified the risks, made informed decisions about how to address them, and implemented controls that are appropriate for your environment. If you get audited or face a complaint, OCR will expect to see this documentation. If you can't show that you assessed the telehealth-specific risks and made deliberate decisions about safeguards, you're exposed.

Policies and Procedures for Telehealth

Your HIPAA policies and procedures need to cover telehealth explicitly. Don't assume that your existing policies for electronic PHI and access controls are sufficient. Telehealth has its own operational patterns, and your policies should address them.

At minimum, you need policies that cover:

• Platform selection criteria and BAA requirements
• Provider device security standards and acceptable use
• Transmission security requirements for all PHI channels
• Patient instructions and informed consent for telehealth risks
• Access controls and authentication for telehealth sessions
• Session recording policies, including consent, retention, and access
• Incident response procedures for telehealth-specific breaches, such as unauthorized access to a session or exposure during a home visit

These policies should be documented, enforced, and reviewed regularly. They should also be part of your workforce training program. Providers and administrative staff need to understand the telehealth-specific compliance requirements, not just the general HIPAA principles.

What Enforcement Looks Like Now

OCR's enforcement discretion for telehealth ended more than two years ago, and enforcement actions are resuming. The pattern I'm seeing is that OCR is treating telehealth compliance the same way they treat any other ePHI transmission scenario. If you're using non-compliant platforms, failing to obtain BAAs, or neglecting transmission security, those are violations subject to the same penalties as any other HIPAA breach.

The enforcement actions that have been made public since the discretion period ended show a focus on a few specific areas: lack of BAAs with telehealth vendors, use of consumer-grade platforms without appropriate safeguards, and failure to conduct risk assessments that include telehealth. These aren't edge cases. They're foundational compliance requirements that too many organizations skipped during the enforcement discretion window and never went back to address.

The other enforcement pattern worth noting is that breaches involving telehealth are being scrutinized for both the technical failure and the organizational response. If a telehealth session is accessed by an unauthorized individual, OCR will look at whether you had proper access controls in place, whether you documented the risk, whether you trained your workforce, and how quickly and appropriately you responded to the breach. The technical failure is just the starting point.

Breach Notification for Telehealth Incidents

If a telehealth session is compromised—an unauthorized individual gains access, a recording is exposed, or PHI is transmitted insecurely and intercepted—you have the same breach notification obligations as any other HIPAA incident. You need to assess whether the incident constitutes a breach under the rule, notify affected individuals if required, report to OCR if it affects 500 or more individuals, and document your investigation and response.

The challenge with telehealth breaches is that they often involve ambiguous scenarios. A patient's family member overhears a session—is that a breach? A provider conducts a visit from a coffee shop on public Wi-Fi—does that trigger notification obligations if no actual unauthorized access occurred? These scenarios require analysis, and the answers depend on the specific facts and your security posture at the time.

The key is documentation. If an incident occurs, document what happened, who was affected, what PHI was involved, what your risk assessment concluded, and what steps you took to mitigate future risk. If you determine that notification isn't required, document why. If you notify, document when and how. This creates a record that demonstrates you took the incident seriously and followed a structured process.

Session Recordings and Retention

Many telehealth platforms allow session recordings for clinical documentation or quality assurance purposes. If you're recording sessions, you're creating and storing PHI, and all the usual HIPAA safeguards apply. You need patient consent to record, secure storage for the recordings, access controls that limit who can view them, retention schedules that define how long they're kept, and secure disposal when they're no longer needed.

The pattern I see is that practices enable recording without thinking through the full lifecycle. The recording feature is turned on because it's useful for documentation, but no one defines where the recordings are stored, who can access them, whether they're encrypted, or how long they're retained. Then two years later, someone realizes there are hundreds of unmanaged session recordings sitting in a cloud storage bucket with no access controls and no deletion policy.

If you record sessions, document the purpose, obtain patient consent, define the retention period, and ensure the storage environment meets your security standards. If you don't need to record sessions, disable the feature entirely. The safest data is data you don't create.

Third-Party Access to Recordings

If your telehealth platform stores recordings, the vendor has access to PHI, and the BAA needs to address that explicitly. Some platforms use recordings for their own analytics, quality improvement, or AI training. If the vendor is using your session data for any purpose beyond providing the telehealth service, that needs to be disclosed in the BAA, and you need to assess whether it's permissible under HIPAA's minimum necessary standard and your own data use policies.

I've reviewed telehealth BAAs that gave the vendor broad rights to use de-identified session data for product development. That may be acceptable if the de-identification process is robust and meets the HIPAA standard, but it's something you should evaluate, not accept on faith. Ask the vendor how they de-identify the data, what elements are retained, and how they ensure re-identification isn't possible.

What Leadership Needs to Understand

Telehealth isn't a temporary pandemic workaround anymore. It's a permanent part of healthcare delivery, and HIPAA compliance for telehealth is now a standard operational requirement. Leadership needs to stop treating telehealth compliance as an IT issue and start recognizing it as a business and regulatory risk that requires investment, policy development, and ongoing oversight.

That means budgeting for compliant platforms, not just defaulting to the cheapest option. It means enforcing device security standards for remote providers, even if that requires purchasing organizational hardware. It means conducting regular risk assessments that include telehealth-specific threats and updating your policies as the operational environment changes.

The organizations that are getting this right are the ones that treated the end of the enforcement discretion period as a compliance deadline, not a suggestion. They audited their telehealth workflows, identified gaps, implemented proper BAAs, secured transmission channels, and documented their risk decisions. The organizations that are still exposed are the ones that assumed compliance would somehow take care of itself or that enforcement wouldn't resume in earnest.

HIPAA compliance for telehealth isn't complicated, but it does require deliberate effort. The regulatory expectations are clear, the technical controls are well-established, and the risks are manageable if you address them systematically. What's not acceptable is continuing to operate telehealth programs as if the enforcement discretion period never ended and hoping that OCR won't notice. They will, and the penalties for willful neglect are steep.