Why this matters
A telehealth platform can look polished in a demo and still fail a HIPAA audit within its first year in production — usually because of a subprocessor nobody asked about, a session link that wasn't tokenized, or a Business Associate Agreement that never got signed before the first patient visit. The 2026 HIPAA Security Rule update adds specific requirements for telehealth session security and remote patient monitoring data, which raises the bar further for anything evaluated before this year. This scorecard walks healthcare organizations and digital health teams through what to verify before signing with a telehealth vendor.
Before you start
- [ ] Confirm you'll request a Business Associate Agreement (BAA) before the first product demo, not after contract signing
- [ ] Identify every subprocessor in the vendor's stack — hosting provider, video infrastructure, transcription/AI services — and confirm each is covered by the BAA
- [ ] Define your session volume and specialty needs (asynchronous visits, remote patient monitoring, group therapy sessions)
- [ ] Decide whether you need EHR integration at launch or can add it later
Compliance and security requirements
| Requirement | What to verify | Red flag |
|---|---|---|
| Business Associate Agreement | BAA explicitly covers the vendor's own subprocessors, especially hosting | Vendor is vague about which subprocessors are covered |
| Encryption | AES-256 (or equivalent) for ePHI at rest; TLS 1.2+ in transit | Vendor can't name a specific encryption standard |
| Access controls | Named, logged, and exportable access records for every user | Shared logins or unlogged admin access |
| Security certifications | HITRUST, ISO 27001, or SOC 2 Type II | No third-party security certification at all |
| Session security | Individually tokenized session links, not static or reusable | Static meeting links that can be shared or reused |
| MFA | Multi-factor authentication enforced for all clinical and admin users | MFA optional or not offered |
Vendor evaluation criteria
- [ ] BAA log — Does the vendor maintain (and can they share) a central BAA log with contract and renewal dates for their own subprocessors?
- [ ] Configuration control — Can you disable public cloud recording and enforce your own tenant-level security settings?
- [ ] Consent workflow — Does the platform capture and store documented patient consent for virtual visits?
- [ ] EHR/EMR integration — Native integration, HL7/FHIR support, or custom integration work required?
- [ ] Uptime and support — What's the SLA for clinical-hours availability, and is support staffed accordingly?
- [ ] Remote patient monitoring data handling — If applicable, how is RPM data secured and does it meet the 2026 Security Rule's specific RPM requirements?
Red flags to watch for
- [ ] Vendor pushes back on signing a BAA or wants to limit its scope
- [ ] No documented incident response plan specific to a telehealth session breach
- [ ] Session recording defaults to "on" with no per-session or per-provider override
- [ ] Vague answers about where PHI is actually hosted (region, subprocessor, data residency)
How to use this
Treat the BAA and encryption rows as pass/fail — a vendor that can't produce a complete BAA covering all subprocessors should be disqualified before you score anything else. For the remaining criteria, weight EHR integration and consent workflow highest if you're replacing an existing clinical system, and weight session security highest if you're launching telehealth for the first time.
How Syslabs helps
Standing up a compliant telehealth deployment usually means more than picking the right vendor — it means building the EHR integration, consent workflows, and access-control layer around it correctly. Syslabs works with healthcare teams on exactly this: running vendor evaluations like this one, then building the custom software and compliance controls that make the resulting deployment audit-ready.