Choosing HIPAA-Compliant Video Platforms After Telehealth Flexibilities

The mistake I keep seeing is simple: teams still evaluate telehealth video like it is a feature demo, when the real decision is a compliance and workflow decision. During the waiver period, a lot of vendors got a pass because everyone was trying to keep care moving. That shortcut is over. If your platform cannot show a proper BAA, clean security controls, sensible identity handling, and an implementation path that fits your clinical operations, it is not a serious option.

I build in this space, and I have watched supposedly solid video products fail on things nobody puts on the first slide deck. Consent logging lives in one place, encounter notes in another, and the support team cannot explain where session metadata is stored. Or the vendor says it is HIPAA-ready, then hands you a boilerplate security summary with no answers on encryption at rest, sub-processors, or administrative access. That is not readiness. That is marketing.

End of flexibilities does not mean telehealth is harder to deliver. It means the excuses are gone. If you run a compliance-conscious health system, you need a vendor that can survive three conversations at once: legal, security, and clinical operations. Plenty of products can survive one. Very few survive all three without hand-waving.

Here is where teams get tripped up. They often start with the wrong filter: Does it have video? That is the least interesting question. Video is table stakes. The real question is whether the platform can operate as part of a controlled clinical environment.

For me, that breaks into five concrete checks:

• Business Associate Agreement: Not whether the vendor says they support HIPAA, but whether they will sign a BAA for the exact services you are buying, with no carve-out that excludes the pieces clinicians will use.
• Authentication and access control: Can you enforce the identity model you need, including SSO, role-based access, and named user accountability where required?
• Encryption and key management: Can the vendor explain how data is protected in transit and at rest, and what happens to session artifacts after the visit ends?
• Auditability: Can your team prove who accessed what, when, and from where if a privacy inquiry lands on your desk six months later?
• Workflow fit: Does the platform work inside your scheduling, intake, consent, and documentation flow, or does it create a second shadow workflow clinicians will ignore?

That last one matters more than most vendors admit. I have seen elegant security programs fail because the platform made clinicians do too much manual work. When the process gets awkward, people route around it. They start texting links, reusing meeting rooms, or creating generic joins that look convenient and destroy accountability. Security breaks fastest when workflow is clunky.

AST has spent enough time inside health systems to know the pattern. We have seen telehealth rollouts where the vendor security questionnaire looked fine on paper, but the moment we asked for evidence, the answers got vague. We have also seen the opposite: a vendor with a smaller feature set but a much cleaner compliance posture and a much better implementation discipline. I will take the second one every time.

That is because HIPAA-compliant video selection is not just about avoiding breach risk. It is about making a supportable system. When your help desk, privacy team, and clinical ops team all need to troubleshoot the same encounter, the product has to produce usable truth. If the platform hides logs, fragments data, or makes support depend on one vendor admin with magical access, you will regret the purchase later.

AST’s practical view: if the vendor cannot explain the control plane, I assume it does not exist. Good platforms make governance legible. Bad platforms make governance somebody else’s problem.

There is another friction point teams underestimate. Once you move out of waiver-era thinking, procurement gets less tolerant of loose language. Phrases like secure enough or industry standard protections do not carry you through review. You need details that a security analyst can verify and a compliance officer can file. That means named controls, actual logs, documented retention, documented support boundaries, and a contract that does not conflict with your policy set.

We have also learned not to overvalue flashy patient experience features in the selection phase. Virtual backgrounds, custom lobby music, and clever branding do not matter if the platform cannot hold up under access review. The best patient experience in the world does not fix a weak BAA or sloppy admin defaults. I would rather have a plain room with clean controls than a slick interface wrapped around risk.

If you are building an evaluation process this week, do it in the order below. Not because it is elegant. Because it prevents wasted time.

1. Start with legal and privacy gates Confirm the vendor will sign a BAA for the exact configuration you want. Review retention, support access, subcontractors, and breach notification terms before anyone opens a trial account.
2. Map the workflow you actually need Decide how patients join, how clinicians launch, how interpreters or caregivers participate, and how the visit is documented. If the workflow requires a second system of record, note that up front.
3. Test identity and access control Validate SSO, RBAC, user deprovisioning, guest access, and whether a patient or family member can join without punching holes in your governance model.
4. Inspect the evidence trail Ask for audit logs, administrative activity records, and examples of how the vendor supports investigations. If the answer is a screenshot instead of structured export, keep digging.
5. Run a real clinical pilot Include one high-friction specialty, one standard follow-up visit, and one support scenario. The point is not to prove the tool works once. It is to see how it fails under ordinary pressure.
6. Decide who owns operations after go-live Build the support model now: help desk, security, compliance, and clinical operations. If ownership is fuzzy, the platform will drift fast.

How AST handles this: when we evaluate telehealth interoperability inside a health system, we do not treat video as a standalone app. We place it inside the broader care journey, then validate the handoffs with scheduling, identity, documentation, and support. That is where most products either become deployable or fall apart.

One more thing I disagree with: the idea that post-waiver telehealth selection is about choosing the most famous platform. Brand recognition does not buy you a clean implementation. I have seen big-name tools get stuck because they could not align with enterprise identity, could not satisfy the documentation chain, or pushed too much responsibility onto clinicians. The vendor you know is not always the vendor you can govern.

If you need a useful mental model, think of the selection process in three layers:

• Layer 1: Compliance fit Can the vendor meet HIPAA expectations with a BAA, security controls, and support procedures that hold up under scrutiny?
• Layer 2: Clinical workflow fit Can clinicians and patients actually use it without creating side channels and workarounds?
• Layer 3: Integration fit Does it connect to your EHR, scheduling, identity, and reporting stack without turning your IT team into permanent middleware?

If any one of those layers is weak, the whole selection is weak. That is the part teams forget after the crisis phase ends. They remember the urgency of access, but not the discipline needed to keep access defensible.

For health systems that already live inside Epic, Oracle Health, athenahealth, or a homegrown stack, the right platform is the one that reduces friction without diluting control. That is exactly why we keep pushing teams to look beyond the demo room and into the operating model. The tool is not the solution. The governed workflow is the solution.

The end of telehealth flexibilities did not kill virtual care. It killed the habit of treating video as a casual utility. That is a good thing. If we want telehealth to stay inside the ordinary care model, we need platforms that can be governed like every other clinical system.

At AST, that is how we approach telehealth interoperability: not as a shiny add-on, but as part of the same controlled environment that holds everything else together. If the platform cannot be explained to security, privacy, and operations in the same meeting, it is not ready.