When people talk about HIPAA compliance in telehealth, the conversation almost always starts and ends with the video visit. “Is the platform encrypted?” “Did we sign a BAA?” Those are necessary questions, but they’re not where most organizations get burned.
From a health and employee benefits systems perspective, the bigger exposure usually shows up after the visit, when telehealth data starts moving through the benefits ecosystem: the health plan or TPA, PBM, care navigation, wellness and incentives, benefits administration, support teams, and employer reporting. That downstream movement creates what I think of as the post-visit blast radius.
Plainly: telehealth compliance is an integration governance problem disguised as a platform problem.
The “post-visit blast radius” most teams underestimate
A telehealth visit isn’t just a video connection. It produces clinical and operational artifacts that can easily become PHI in the wrong place.
- Visit notes and summaries
- Diagnoses and problem lists
- Prescriptions (including controlled substances, where applicable)
- Lab orders and results
- Referrals
- Chat transcripts, images, and attachments
- Appointment metadata that can be sensitive depending on context
Then those artifacts get routed into other systems, often automatically and often invisibly to the employer or HR team that sponsors the benefit.
- EHRs (sometimes multiple)
- Payer and claims workflows
- Care navigation and advocacy tools
- Benefits administration and eligibility feeds
- Wellness and incentive platforms
- Call center CRM and ticketing tools
- Messaging and reminder services (email/SMS/voice)
Every handoff is a chance to violate the HIPAA basics: minimum necessary, access controls, auditability, and appropriate vendor obligations.
Start here
Create a telehealth PHI data flow map and label every destination in one of three lanes:
- HIPAA lane: Covered Entities and Business Associates that are designed and contracted to handle PHI
- Plan sponsor lane: employer plan administration functions with strict limits and guardrails
- Red lane: tools that should not touch PHI (for example, generic marketing analytics or non-HIPAA support chat)
Simple? Yes. But it’s the difference between “we think we’re compliant” and “we can prove we’re compliant.”
BAAs don’t solve the subcontractor problem
A common trap: “We have a BAA with the telehealth vendor, so we’re covered.” The catch is that telehealth vendors almost always rely on other vendors behind the scenes, and those subcontractors may also touch PHI. HIPAA treats those subcontractors as business associates in their own right: any subcontractor that creates, receives, maintains, or transmits PHI on the vendor’s behalf needs its own written agreement with the same restrictions flowing down (45 CFR 164.504(e)).
- Scheduling and intake tools
- SMS and email notification vendors
- E-fax services
- AI transcription or scribe tools
- Support ticketing systems
- Analytics stacks and data warehouses
If PHI flows to a subcontractor that isn’t properly covered and controlled, you can end up with a compliance gap even when your core vendor contract looks fine.
Practical procurement controls
Require your telehealth vendor to provide (and keep current) a list of:
- All subcontractors that create, receive, maintain, or transmit PHI
- What data elements are shared and why (your minimum necessary justification)
- Security assurance evidence (SOC 2 Type II or comparable controls)
- Breach notification commitments and timelines
If you need a clean internal way to document this, treat it like a “PHI supply chain” inventory tied to your vendor management process.
The most common employer-sponsored telehealth HIPAA failure: accidental plan sponsor access
Employer-sponsored telehealth lives in a tricky place. Employers want reporting on utilization, engagement, and outcomes, and vendors want to be helpful. That’s exactly how sensitive disclosures happen. HIPAA’s plan sponsor rules draw the line here: a group health plan may disclose PHI to the employer only for plan administration functions, and only after the plan documents are amended and the employer certifies it will not use the information for employment decisions or other benefit plans (45 CFR 164.504(f)).
The trouble starts when an employer receives information that is identifiable, re-identifiable, or reveals care categories that employees reasonably expect to stay private.
- HR receiving a list of which employees used telehealth
- Reporting that makes behavioral health usage obvious by small group size
- Department-by-department dashboards that allow re-identification
- Incentives structured in a way that reveal treatment details (“completed therapy visit”)
How to keep reporting useful without crossing the line
- Use de-identified reporting where possible and apply small-cell suppression (for example, don’t report categories with fewer than 11 participants)
- Limit employer reporting to operational metrics that don’t expose care details
- Enforce role-based access for any legitimate plan administration workflows
- Train account teams not to fulfill ad hoc “just send me the list” requests
“De-identified” is a defined HIPAA standard with two accepted methods: the Safe Harbor method (stripping the 18 listed identifiers) or an expert determination that re-identification risk is very small. Small-cell suppression protects a report, but it does not by itself make a dataset de-identified under HIPAA.
This is one of the few areas where good intentions create outsized risk, because the disclosure often happens casually, not maliciously.
Chat, async visits, and images deserve the same HIPAA rigor as video
Video hogs the spotlight. Async features quietly create long-lived PHI stores: chat transcripts, photo uploads, attachments, and message histories. Those are easy to overexpose internally and hard to clean up later.
Controls that actually matter
- Set clear retention rules for transcripts and attachments, and confirm they’re technically enforced
- Use tight role-based access so non-clinical support can’t see clinical details unless truly necessary
- Maintain audit logs for access to transcripts, images, and attachments (not just the “encounter” record)
Identity proofing: where HIPAA and fraud prevention overlap
Telehealth increases the risk of inappropriate access: shared devices, password reuse, dependents logging in, and remote clinical teams working across locations. HIPAA expects you to protect against unauthorized access, not just external hackers.
- Use multi-factor authentication for portals that display visit summaries, labs, or prescriptions
- Apply step-up authentication for higher-risk services (for example, controlled substances or sensitive care types)
- Implement timeouts and session controls to reduce exposure on shared or unattended devices
- Build clear workflows for dependents and guardians (minors can introduce additional privacy complexity)
Minimum necessary breaks at the integration layer
In practice, “minimum necessary” tends to fail when systems integrate. APIs and data feeds can make it easy to ship more data than the receiving system needs, especially when eligibility, incentives, navigation, and reporting are tied together.
A solid approach is to separate “operational events” from “clinical detail.” In many cases, downstream systems only need to know that an event occurred, not the diagnosis, note, or transcript.
How to design for minimum necessary
- Whitelist data fields by integration (send only what the destination truly needs)
- Split “visit occurred” confirmation from clinical payloads
- Be careful with incentive verification so it rewards a preventive action without revealing sensitive details downstream
Don’t let tracking pixels create a PHI leak
One of the most overlooked telehealth risks is analytics leakage, especially when marketing and member experiences share tooling. Tracking pixels, URL parameters, and event tags can unintentionally expose sensitive context. FTC orders against GoodRx ($1.5 million) and BetterHelp ($7.8 million) for feeding health data to advertising platforms show how routine this failure is. A 2024 federal court ruling narrowed OCR’s related guidance on public, unauthenticated pages, but the position on authenticated areas such as patient portals and member dashboards is unchanged.
- Keep third-party tracking off authenticated and PHI-adjacent pages
- Separate marketing sites from member/patient experiences
- Periodically audit telemetry to confirm nothing sensitive is flowing to analytics tools
When a telehealth tool isn’t covered by HIPAA
Not every tool in the post-visit chain is a HIPAA covered entity or business associate. Some telehealth and wellness apps sit outside HIPAA entirely, which is the gap the Federal Trade Commission moved to close. In 2024 the FTC finalized updates to its Health Breach Notification Rule, making clear that vendors of personal health records and similar apps not covered by HIPAA must notify consumers, the FTC, and in some cases the media when unsecured health data is breached. For a benefits team, the practical step is to confirm each vendor’s status before assuming a BAA is the right control. If a vendor is not HIPAA-regulated, ask what it discloses under the FTC rule and treat any sharing of health data with advertisers as a red flag. The FTC has already penalized health platforms for that exact behavior.
What “audit-ready” telehealth HIPAA compliance actually looks like
HIPAA compliance becomes real when you can show how your organization operationalizes it through policies, controls, logs, and oversight.
Administrative safeguards
- Telehealth-specific risk analysis (not just a generic HIPAA template)
- Incident response playbooks for telehealth scenarios (wrong-recipient messages, exposed recordings, lost devices)
- Role-based training for clinical, support, implementation, and customer success teams
Technical safeguards
- Encryption in transit and at rest
- Strong audit logging with periodic review
- Anomaly detection for unusual access or bulk exports
- Recording disabled by default unless there’s a documented need and appropriate consent
Under the current Security Rule, encryption and multi-factor authentication are addressable specifications rather than absolute requirements. HHS’s proposed Security Rule update would make them explicit, but that proposal remains pending, with final action now expected in 2027. Treat the proposal as a preview of enforcement expectations, not current law.
Physical safeguards
- Remote workforce standards for privacy (workspace, screen visibility, headset use)
- Endpoint encryption, patching, and device management for clinical staff
The governance move most teams miss: one accountable PHI owner
Telehealth sits at the intersection of HR, IT, the health plan/TPA, and a growing vendor stack. Compliance often fails because nobody owns the end-to-end PHI flow.
Assign a single accountable leader (or governance function) to own the telehealth PHI map, vendor/subcontractor oversight, employer reporting rules, and change management whenever new features or integrations are introduced.
Bottom line
If you're after telehealth HIPAA compliance that holds up in the real world, stop treating it like a checkbox on a video platform. Treat telehealth like a PHI supply chain: map it, minimize it, govern it, and prove it.
If you want to pressure-test your current approach, start with one internal exercise: list every place telehealth data lands after the visit. The gaps tend to reveal themselves quickly once you see the full ecosystem on one page.