ASF Standards · Telemedicine · Standard 1
Standard 1 — Technology Platform Reliability & Security
Criteria in this standard
1.1 — A Signed, Executed Business Associate Agreement Genuinely Exists
1.2 — Encryption Meets Current Technical Standards, Not Assumed Adequate
1.3 — Consumer-Grade Video Platforms Are Never Used for Clinical Sessions
1.4 — Multi-Factor Authentication and Access Controls Are Genuinely Enforced
1.5 — Connection Failure During a Session Has a Defined, Practiced Recovery Process
1.2 — Encryption Meets Current Technical Standards, Not Assumed Adequate
1.3 — Consumer-Grade Video Platforms Are Never Used for Clinical Sessions
1.4 — Multi-Factor Authentication and Access Controls Are Genuinely Enforced
1.5 — Connection Failure During a Session Has a Defined, Practiced Recovery Process
1.1
A Signed, Executed Business Associate Agreement Genuinely Exists
Non-Negotiable
Every telemedicine platform and technology vendor handling patient information has a genuinely signed, executed Business Associate Agreement in place — not merely the availability of one, and not an assumption that selecting a healthcare-tier platform alone constitutes compliance.
In plain terms: Every technology vendor that touches patient data — the video platform, the record system, the scheduling tool — has a signed, executed agreement covering data protection. Signed, not just 'we have one somewhere.'
| Facility category | Crisis | Transition | Small | Standard |
|---|---|---|---|---|
| Applicability | Full | Full | Full | Full |
Why this matters
When a telemedicine service uses a video platform, that platform's servers see the consultation. When it uses a cloud record system, that vendor holds the records. Each is a data processor handling health information, and in most jurisdictions the law requires a written agreement defining what they may do, how they protect it, and what happens on breach (a Business Associate Agreement under HIPAA; a Data Processing Agreement under GDPR). A vendor without one is a vendor with no obligations. 'They said they were compliant' is not an agreement. The document must be signed by both parties, current, and on file.
What good looks like
- A genuinely signed, executed agreement exists for every relevant vendor.
- Execution genuinely occurred before any clinical session.
- Coverage genuinely extends to every vendor touching patient information.
Common failure modes
- An agreement is available from the vendor but was never actually executed.
- Sessions occurred before execution was genuinely completed.
- Coverage is limited to the primary platform, missing other vendors handling patient information.
Worked example
In practice
A 12-clinician telemedicine service using a video platform, a cloud EHR, and a third-party scheduling tool.
BeforeThe video platform was on a consumer subscription with terms of service accepted by clicking. The EHR vendor had sent a BAA that was never signed. The scheduling tool had no agreement at all. When a patient asked for the data protection terms, nobody could produce them.
ActionThe service listed every vendor handling patient data. For each, a signed data processing agreement was obtained or the vendor was replaced: the video platform was switched to a healthcare tier with a signed BAA; the EHR BAA was countersigned and filed; the scheduling tool was replaced with one that would sign. A register of agreements with expiry dates is maintained by the compliance lead and reviewed annually.
AfterThe Monitor reviewed the vendor register and three signed, executed agreements. Verified.
If you are starting from zero — do this first
- List every system or service that sees patient data.
- For each, find the signed agreement. If you cannot, you do not have one.
- Get one signed or replace the vendor.
- Keep a register with review dates.
The most common mistake: Accepting a vendor's 'we're compliant' as an agreement — an agreement is a signed document.
Self-assessment questions
1. Is there a genuinely signed, executed Business Associate Agreement with every platform and vendor handling patient information? — Real, executed agreement by both parties, not availability alone.
Evidence: Executed BAA documentation
Evidence: Executed BAA documentation
2. Was the agreement genuinely signed before any clinical session occurred, not after the fact? — Real, prior execution, not a retroactive formality.
Evidence: N/A — tested directly
Evidence: N/A — tested directly
3. Does coverage genuinely extend to every vendor touching patient information — video, messaging, storage — not just the primary platform? — Complete, genuine coverage across every relevant vendor, not the main platform alone.
Evidence: Vendor BAA inventory
Evidence: Vendor BAA inventory
Common reasons for a PARTIAL answer
- 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.
- 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.
- Execution happened but isn't documented in a way that's genuinely easy to verify later.
Implementation plan
| When | What |
|---|---|
| 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. |
How the Monitor verifies this
| Method | What | Detail |
|---|---|---|
| DOCUMENT | BAA execution review | Reviews the actual signed agreement for genuine execution by both parties. |
| DOCUMENT | Timing review | Reviews whether execution genuinely preceded clinical session use. |
| DOCUMENT | Vendor inventory review | Reviews whether every vendor handling patient information has a genuine, executed agreement. |
Supervisor tips
- 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.
Evidence base
[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.
ASF training courses on GMJ Academy →
Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.
1.2
Encryption Meets Current Technical Standards, Not Assumed Adequate
Non-Negotiable
Video, audio, and data transmission genuinely meet current, specific encryption standards — end-to-end encryption for live sessions, strong transport encryption for signaling, encryption at rest for stored records — not assumed adequate from general platform reputation without genuine, specific verification.
In plain terms: Video, audio, and data are encrypted to current recognised standards — and the service can name the standard and show it is met, not just assume 'it's secure.'
| Facility category | Crisis | Transition | Small | Standard |
|---|---|---|---|---|
| Applicability | Full | Full | Full | Full |
Why this matters
A consultation about a patient's HIV status, mental illness, or pregnancy that travels the internet unencrypted can be intercepted. A record stored without encryption is readable by anyone who obtains the disk. Encryption standards are specific: TLS 1.2 or higher for data in transit, AES-256 for data at rest, end-to-end encryption for video where available. The service must know which standards its platforms meet — from the vendor's documentation, not from marketing — and must verify that encryption is actually configured and enabled, not merely available.
What good looks like
- Live session encryption is genuinely end-to-end and specifically verified.
- Transport encryption genuinely meets current standards.
- Data at rest is genuinely, verifiably encrypted.
Common failure modes
- Encryption is assumed adequate from general platform reputation, not specifically verified.
- Transport security doesn't genuinely meet current standards.
- Stored data lacks genuine, verified encryption.
Worked example
In practice
A 15-clinician telemedicine service that described its platform as 'fully secure.'
BeforeNobody could say what encryption the video platform used. The EHR was encrypted at rest but the backup was not. Clinicians sometimes emailed patient documents from personal accounts. 'Secure' was an assumption, not a verified state.
ActionThe compliance lead obtained the technical security documentation from each vendor and confirmed: video platform — end-to-end encrypted, TLS 1.3; EHR — AES-256 at rest, TLS 1.2 in transit; backup — moved to an encrypted service. A policy prohibited patient data in personal email; an encrypted messaging channel was provided. An annual security review by an external consultant was contracted.
AfterThe Monitor reviewed the vendor security documentation, the backup configuration, the email policy, and the external review report. Verified.
If you are starting from zero — do this first
- Ask each vendor for their technical security documentation, in writing.
- Confirm the encryption standard for data in transit and at rest.
- Check the backup — is it encrypted?
- Ban patient data in personal email.
The most common mistake: Believing a platform is secure because it says 'secure' on the website.
Self-assessment questions
1. Is live session encryption genuinely end-to-end, specifically verified, not assumed from general platform reputation? — Real, specific, verified encryption, not general trust in the platform's reputation.
Evidence: Encryption specification documentation
Evidence: Encryption specification documentation
2. Does signaling and API transmission genuinely meet current transport encryption standards? — Specific, verified technical compliance, not a general assumption of security.
Evidence: N/A — tested directly
Evidence: N/A — tested directly
3. Is data genuinely encrypted at rest for any stored records, not only during active transmission? — Real, verified encryption for stored data specifically, not protection limited to live transmission alone.
Evidence: Data-at-rest encryption verification
Evidence: Data-at-rest encryption verification
Common reasons for a PARTIAL answer
- 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.
- 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.
- Specifications meet current standards but haven't been reviewed since a relevant standard was updated.
Implementation plan
| When | What |
|---|---|
| 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. |
How the Monitor verifies this
| Method | What | Detail |
|---|---|---|
| DOCUMENT | Encryption specification review | Reviews the platform's actual, documented encryption specifications against current standards. |
| DOCUMENT | Transport security review | Reviews signaling and API transmission encryption for genuine, current compliance. |
| DOCUMENT | At-rest encryption review | Reviews encryption verification for stored records specifically. |
Supervisor tips
- 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.
Evidence base
[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.
ASF training courses on GMJ Academy →
Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.
1.3
Consumer-Grade Video Platforms Are Never Used for Clinical Sessions
Non-Negotiable
Clinical telemedicine sessions never occur on consumer-grade video platforms — standard FaceTime, consumer Zoom, standard Google Meet, Skype — regardless of convenience or a provider's personal familiarity with these tools, since none genuinely offer the Business Associate Agreement this whole standard depends on.
In plain terms: Clinical sessions never happen on consumer FaceTime, WhatsApp, standard Zoom, or similar — only on platforms designed and contracted for healthcare.
| Facility category | Crisis | Transition | Small | Standard |
|---|---|---|---|---|
| Applicability | Full | Full | Full | Full |
Why this matters
Consumer video apps are convenient and clinicians reach for them — especially when the healthcare platform is slow or the patient is not set up. But consumer platforms have no data processing agreement, may store or analyse content, may not be encrypted end to end, and give the provider no control over where data goes. A single consultation on WhatsApp is a breach. Emergency exceptions in a crisis may be tolerated by regulators; routine use is not. The rule is absolute and staff must know it: clinical sessions on the healthcare platform only.
What good looks like
- Clinical sessions genuinely never occur on consumer-grade platforms.
- All providers are specifically, confidently aware of approved platforms.
- A defined fallback process prevents ad hoc consumer platform use during difficulty.
Common failure modes
- Consumer platforms are used occasionally for convenience or familiarity.
- Providers are uncertain which platforms are genuinely approved.
- No defined fallback exists, risking ad hoc consumer platform use under pressure.
Worked example
In practice
A 10-clinician telemedicine service where clinicians used a mix of platforms.
BeforeThe service had a healthcare video platform, but clinicians often used WhatsApp or FaceTime because patients found them easier. Nobody tracked which platform was used. Several hundred consultations had occurred on consumer apps.
ActionA written policy: clinical sessions only on the contracted healthcare platform; no exceptions except documented emergencies. Patients receive a set-up guide and a pre-visit tech check by an assistant. Clinicians' consumer messaging apps were removed from work devices. Session logs from the healthcare platform are reconciled against the appointment schedule monthly; any appointment without a platform session is investigated.
AfterThe Monitor reviewed the policy, the reconciliation for three months (100% of sessions on the platform), and interviewed a clinician who described the pre-visit tech check. Verified.
If you are starting from zero — do this first
- Ask each clinician what platforms they have used for patient sessions in the last month.
- Write the rule: healthcare platform only.
- Give patients a set-up guide and a tech check before their first visit.
- Reconcile platform sessions against appointments monthly.
The most common mistake: Using WhatsApp because the patient couldn't work the proper platform — the fix is helping the patient, not breaching their data.
Self-assessment questions
1. Are clinical sessions genuinely never conducted on consumer-grade video platforms lacking a Business Associate Agreement? — A firm, absolute exclusion, not an occasional exception for convenience.
Evidence: Approved platform list documentation
Evidence: Approved platform list documentation
2. Are all providers specifically aware of which platforms are genuinely approved, not assuming familiar consumer tools are acceptable? — Real, specific awareness across all providers, not an assumption of general understanding.
Evidence: Provider platform training record
Evidence: Provider platform training record
3. Is there a specific process preventing an ad hoc fallback to a consumer platform during a technical difficulty? — A real, defined alternative, not defaulting to a familiar but non-compliant tool under pressure.
Evidence: Technical difficulty fallback protocol
Evidence: Technical difficulty fallback protocol
Common reasons for a PARTIAL answer
- 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.
- The approved platform list is documented but not proactively reinforced through periodic training. — Documentation alone doesn't guarantee genuine, sustained awareness without periodic reinforcement.
- A fallback protocol exists but hasn't been specifically tested through a real technical difficulty scenario.
Implementation plan
| When | What |
|---|---|
| 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. |
How the Monitor verifies this
| Method | What | Detail |
|---|---|---|
| DOCUMENT | Approved platform documentation review | Reviews the specific, documented list of genuinely approved platforms. |
| ASK | Provider awareness interview | Asks a provider to confirm which platforms are genuinely approved for clinical use. |
| DOCUMENT | Fallback protocol review | Reviews the defined fallback process preventing ad hoc consumer platform use during technical difficulty. |
Supervisor tips
- 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.
Evidence base
[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.
ASF training courses on GMJ Academy →
Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.
1.4
Multi-Factor Authentication and Access Controls Are Genuinely Enforced
Non-Negotiable
Multi-factor authentication and role-based access controls are genuinely, consistently enforced for every provider accessing patient information — not optional, not bypassed for convenience, and not limited to some providers while others access the system through a single-factor login.
In plain terms: Every clinician and staff member logs in with multi-factor authentication and can only see what their role needs — enforced by the system, not by trust.
| Facility category | Crisis | Transition | Small | Standard |
|---|---|---|---|---|
| Applicability | Full | Full | Full | Full |
Why this matters
A password alone is compromised by phishing, reuse, or a stolen laptop. Multi-factor authentication — a code, an app, a key — stops most account takeovers. Role-based access means the scheduler cannot read clinical notes and the clinician cannot see billing. 'Enforced' means the system requires it: MFA cannot be disabled by the user; access is granted by role and reviewed when roles change; leavers lose access the day they leave. A service where MFA is 'recommended' has a service where half the accounts do not use it.
What good looks like
- Multi-factor authentication is genuinely, consistently enforced for every provider.
- Role-based access controls genuinely limit access to actual role requirements.
- Session timeouts are genuinely enforced, not disabled for convenience.
Common failure modes
- Multi-factor authentication is optional or inconsistently enforced.
- Access controls don't genuinely limit provider access based on actual role.
- Session timeouts are disabled or extended indefinitely.
Worked example
In practice
A 14-clinician telemedicine service with MFA available but optional.
BeforeMFA was available on the EHR but enabled by about 40% of users. All staff had the same access level. Two former clinicians still had active accounts eight months after leaving. A phishing attack had compromised one clinician's password; no patient data was accessed only by luck.
ActionMFA was enforced at the system level for all accounts. Role-based access was configured: clinician, nurse, scheduler, billing, admin. An access review is done quarterly and on any role change. A leaver checklist removes access on the last day. Login anomalies (new device, unusual location) trigger an alert to the compliance lead.
AfterThe Monitor reviewed the MFA enforcement setting, the role matrix, the quarterly access review, and the leaver checklist. Attempted login without MFA was blocked. Verified.
If you are starting from zero — do this first
- Check: is MFA enforced or optional? Optional means half your accounts are unprotected.
- Enforce it today.
- List who has access to what. Remove anything not needed for their role.
- Check whether anyone who left still has an account.
The most common mistake: Making MFA available but not mandatory — the users who skip it are the ones who get phished.
Self-assessment questions
1. Is multi-factor authentication genuinely, consistently enforced for every provider accessing patient information? — Real, consistent enforcement across every provider, not optional or bypassed for some.
Evidence: MFA enforcement record
Evidence: MFA enforcement record
2. Are role-based access controls genuinely limiting each provider's access to what their actual role requires? — Real, specific role-based limitation, not broad access granted regardless of actual need.
Evidence: Access control configuration documentation
Evidence: Access control configuration documentation
3. Are session timeouts genuinely enforced, not disabled or extended indefinitely for convenience? — Real, enforced timeout settings, not convenience overriding genuine security practice.
Evidence: Session timeout configuration
Evidence: Session timeout configuration
Common reasons for a PARTIAL answer
- 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.
- 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.
- Timeouts are enforced but set to an interval long enough to provide limited real protective value.
Implementation plan
| When | What |
|---|---|
| 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. |
How the Monitor verifies this
| Method | What | Detail |
|---|---|---|
| DOCUMENT | MFA enforcement review | Reviews configuration for genuine, consistent multi-factor authentication enforcement. |
| DOCUMENT | Access control review | Reviews role-based access configuration for genuine, appropriate limitation. |
| DOCUMENT | Session timeout review | Reviews session timeout configuration for genuine enforcement. |
Supervisor tips
- 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.
Evidence base
[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.
ASF training courses on GMJ Academy →
Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.
1.5
Connection Failure During a Session Has a Defined, Practiced Recovery Process
Core
A genuine, defined process exists for a connection failure during an active clinical session — a specific reconnection protocol, a defined alternative contact method — not improvised in the moment, with the patient left uncertain whether or how care will continue.
In plain terms: When a video connection drops mid-session, there is a defined, rehearsed process — who calls whom, on what number, within what time — not a scramble.
| Facility category | Crisis | Transition | Small | Standard |
|---|---|---|---|---|
| Applicability | N/A | Full | Adapted | Full |
Why this matters
The connection fails while a patient is describing chest pain, or crying, or mid-way through a medication change. What happens in the next 60 seconds matters. A defined process: the provider phones the patient on the verified number within two minutes; if no answer, tries the emergency contact; if the patient was in distress, escalates per the emergency protocol; documents the interruption. The patient is told the process at the start of care so they know to expect the call. A service without this leaves patients in the void and providers improvising.
What good looks like
- A genuine, specific recovery process exists for connection failure.
- Patients are genuinely aware of an alternative contact method in advance.
- The recovery process has genuinely been tested, not only described in policy.
Common failure modes
- No specific process exists beyond general hope the connection will be restored.
- Patients have no advance awareness of an alternative contact method.
- The process exists only in writing, never tested.
Worked example
In practice
A 12-clinician telemedicine service with frequent connection problems in rural areas.
BeforeWhen connections dropped, providers waited for the patient to reconnect, sometimes for ten minutes. If the patient did not, the session was marked 'incomplete.' A patient who had been describing suicidal thoughts lost connection and was not contacted for two hours.
ActionA connection failure protocol was written: provider phones the patient's verified number within 2 minutes; if no answer, phones again at 5 minutes and tries the emergency contact at 10; if the patient was in clinical distress at the time of the drop, the emergency protocol (4.2) activates immediately; every interruption is documented with the recovery steps. Patients receive the protocol at intake. Providers rehearse it quarterly.
AfterThe Monitor reviewed the protocol, patient intake materials, 15 documented interruptions with recovery steps, and rehearsal records. Verified.
If you are starting from zero — do this first
- Ask three clinicians what they do when the connection drops. Compare the answers.
- Write a protocol with time limits: 2 minutes, 5 minutes, 10 minutes.
- Verify every patient's phone number at intake.
- Tell patients what to expect.
The most common mistake: Waiting for the patient to reconnect — the patient who is in trouble is the one who cannot.
Self-assessment questions
1. Does a genuine, specific process exist for reconnecting after a connection failure during a session? — A real, defined protocol, not improvisation in the moment.
Evidence: Connection failure recovery protocol
Evidence: Connection failure recovery protocol
2. Is there a defined alternative contact method the patient genuinely knows about in advance? — Real, advance patient awareness of an alternative contact method, not left to guess during the disruption.
Evidence: N/A — tested directly
Evidence: N/A — tested directly
3. Has this recovery process genuinely been practiced or tested, not only described in policy? — Real, tested practice, not a protocol that exists only on paper.
Evidence: Recovery process testing record
Evidence: Recovery process testing record
Common reasons for a PARTIAL answer
- 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.
- 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.
- The process is described in policy but hasn't been genuinely tested against a real or simulated failure.
Implementation plan
| When | What |
|---|---|
| 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. |
How the Monitor verifies this
| Method | What | Detail |
|---|---|---|
| DOCUMENT | Recovery protocol review | Reviews the specific, defined connection failure recovery process. |
| ASK | Patient awareness interview | Asks a patient whether they know what to do if a session connection fails. |
| DOCUMENT | Testing record review | Reviews evidence the recovery process has genuinely been tested, not only described. |
Supervisor tips
- 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.
Evidence base
[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.
ASF training courses on GMJ Academy →
Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.