Technology Platform Reliability & Security

MANDATORY

5 criteria

ALL YES Standard likely met. ANY PARTIAL Improvement plan required. ANY NO Blocks accreditation until resolved.

REFERENCES

1. [1] Every telehealth platform used for clinical sessions must provide a signed Business Associate Agreement, executed by both parties before any clinical sessions are conducted, distinct from the common misconception that selecting a healthcare-tier platform alone constitutes compliance.

Many providers genuinely believe that choosing a platform marketed as healthcare-appropriate is itself sufficient, but the agreement must actually be signed by both parties before any clinical session occurs — the real legal and practical protection exists only once execution has genuinely happened, not from the platform's marketing category alone.

1 The primary video platform has a genuine, executed agreement but a secondary messaging tool doesn't.

Every vendor genuinely touching patient information carries the same real requirement.

2 Agreements are executed but not periodically reconfirmed as still current and active.

An agreement's real protective value depends on it remaining genuinely current, not assumed indefinitely valid.

3 Execution happened but isn't documented in a way that's genuinely easy to verify later.

Genuine, accessible documentation is what makes verification reliable when it's actually needed.

Week 1 Inventory every vendor genuinely handling patient information across the full technology stack.

Week 2 Confirm genuine execution of agreements for every identified vendor.

Week 3 Address any vendor relationship lacking genuine, executed coverage.

Ongoing Periodically reconfirm agreements remain current and active.

Ask to see the actual, signed agreement document, not a vendor's general compliance marketing.

A real, specific, signed document is the evidence of genuine execution, not assumed compliance.

Ask about coverage for a secondary tool, like messaging or file storage, not just the primary video platform.

This is where genuine coverage gaps most commonly hide.

ALL YES Standard likely met. ANY PARTIAL Improvement plan required. ANY NO Blocks accreditation until resolved.

REFERENCES

1. [2] Telehealth security requires end-to-end encryption for real-time sessions, transport layer security of at least TLS 1.2 for signaling and APIs, and AES-256 encryption for data at rest, with these specific technical standards, not general platform reputation, constituting genuine compliance.

Encryption requirements are specific and technical, not a general assurance of "security," and a platform's real protective value depends on genuinely meeting these specific standards — a facility that hasn't actually verified this, relying instead on general platform trust, has no real way of knowing whether patient information is genuinely protected in transit and at rest.

1 Live session encryption is genuinely verified but stored recording encryption hasn't been specifically checked.

Every stage where patient information exists deserves the same genuine verification, not live transmission alone.

2 Encryption specifications are documented but haven't been independently verified through actual testing.

Documentation alone doesn't confirm genuine, real-world implementation without independent verification.

3 Specifications meet current standards but haven't been reviewed since a relevant standard was updated.

Encryption standards genuinely evolve, and compliance should track current, not historical, requirements.

Week 1 Review current encryption specifications against genuine, current technical standards.

Week 2 Verify encryption for stored records specifically, not live transmission alone.

Week 3 Independently test or verify documented encryption claims.

Ongoing Review encryption compliance as technical standards evolve.

Ask for the platform's actual, specific encryption specification document, not a general security assurance.

A specific, real document reveals genuine, verifiable compliance, not assumed adequacy.

Ask specifically about encryption for stored session recordings, not just live transmission.

This is where genuine verification is most commonly incomplete.

ALL YES Standard likely met. ANY PARTIAL Improvement plan required. ANY NO Blocks accreditation until resolved.

REFERENCES

1. [3] Consumer video platforms including standard FaceTime, consumer Zoom, standard Google Meet, and Skype are explicitly identified as non-compliant for clinical telehealth use because they do not offer Business Associate Agreements, with temporary pandemic-era enforcement waivers for such platforms having since expired.

Temporary allowances for consumer platforms during the COVID-19 public health emergency have genuinely expired, and consumer platforms don't offer Business Associate Agreements at all — meaning a session conducted on one of these platforms is fundamentally outside this whole document's security framework, regardless of how the actual conversation goes.

1 Awareness is strong among full-time providers but less consistent among occasional or covering providers.

Every provider conducting a clinical session carries the same real responsibility for platform compliance.

2 The approved platform list is documented but not proactively reinforced through periodic training.

Documentation alone doesn't guarantee genuine, sustained awareness without periodic reinforcement.

3 A fallback protocol exists but hasn't been specifically tested through a real technical difficulty scenario.

An untested protocol may not hold up reliably under genuine, real-time pressure.

Week 1 Review current platform use for any instance of consumer-grade platform reliance.

Week 2 Establish and document the specific, genuinely approved platform list.

Week 3 Train all providers, including covering or occasional staff, on approved platforms.

Ongoing Test the technical difficulty fallback protocol periodically.

Ask a provider directly whether they've ever used a consumer platform for convenience.

A direct question often surfaces informal practice a policy review wouldn't catch.

Ask what a provider would do if the approved platform failed mid-session.

A specific, confident answer reveals a genuine fallback process, not improvisation toward a familiar consumer tool.

ALL YES Standard likely met. ANY PARTIAL Improvement plan required. ANY NO Blocks accreditation until resolved.

REFERENCES

1. [4] Administrative controls including role-based access controls, multi-factor authentication, and session timeouts are established as essential technical safeguards for telehealth systems handling sensitive health information, reflected in health data security frameworks recognized across many countries' privacy and data protection regulation.

A single compromised password provides real, complete access to patient information without a second, genuine authentication factor in place, and access controls that exist in policy but aren't actually, consistently enforced provide no more real protection than having no access controls at all.

1 MFA is enforced for primary provider accounts but not for administrative or support staff accessing the same system.

Every account genuinely accessing patient information carries the same real security requirement.

2 Access controls exist but haven't been reviewed to confirm they genuinely match current provider roles.

Role-based access needs genuine, periodic reconfirmation as roles and staffing change.

3 Timeouts are enforced but set to an interval long enough to provide limited real protective value.

A genuinely protective timeout interval balances real security against reasonable convenience, not convenience alone.

Week 1 Review current authentication and access control configuration for genuine, consistent enforcement.

Week 2 Extend multi-factor authentication to every account accessing patient information.

Week 3 Reconfirm role-based access controls genuinely match current provider roles.

Ongoing Audit authentication and access control enforcement periodically.

Ask to see the actual current authentication configuration, not a general assurance of MFA use.

A specific, real configuration reveals genuine enforcement, not assumed compliance.

Ask an administrative staff member whether they use multi-factor authentication for their own access.

This reveals whether genuine enforcement extends beyond primary provider accounts.

ALL YES Standard likely met. ANY PARTIAL Improvement plan required. ANY NO Requires improvement plan.

REFERENCES

1. [5] Security depends on the full system, not the software alone, establishing that operational resilience — including defined processes for technical failure during a clinical session — is a genuine component of telehealth platform reliability, distinct from encryption and access control alone.

A connection failure during a session is a genuine, foreseeable technical reality, and a patient left with a frozen or disconnected screen, uncertain whether to wait or how to reach their provider, experiences a real disruption to their care — a defined, practiced recovery process is what prevents a technical failure from also becoming a care continuity failure.

1 A recovery process exists for provider-side awareness but isn't proactively communicated to patients in advance.

A process patients don't know about provides limited real reassurance during an actual disruption.

2 An alternative contact method exists but isn't consistently the same across different providers.

Consistent, genuine patient awareness depends on a reliable, predictable alternative method.

3 The process is described in policy but hasn't been genuinely tested against a real or simulated failure.

An untested process may not function reliably when a genuine connection failure actually occurs.

Week 1 Review current connection failure response for a genuine, specific defined process.

Week 2 Establish and communicate a consistent alternative contact method to patients in advance.

Week 3 Test the recovery process against a simulated connection failure.

Ongoing Confirm patient awareness of the recovery process periodically.

Ask a patient what they would do if their session connection failed mid-appointment.

A confident, specific answer reveals genuine, communicated awareness, not an assumed process.

Ask staff to describe the last time this recovery process was genuinely tested.

A specific, real example reveals genuine practice, not a protocol that exists only on paper.