> ## Documentation Index > Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt > Use this file to discover all available pages before exploring further. # Telehealth Documentation & Compliance — User Guide > Clinician workflow: consent capture, pre-session safety checklist, jurisdiction handling, connectivity logging, and progress-note linkage. ## Overview CL-24 is the **clinical compliance layer** for telehealth. It sits next to (not on top of) PM-13, which still owns the vendor session, the durable join URL, and the platform credentials. CL-24 adds: * Per-patient **telehealth consent** with annual renewal, two consent types, and audit-immutable revocation. * A **pre-session safety checklist** that can either warn or block the start of a session. * **Connectivity issue logging** mid-session for QA and payer audits. * A **jurisdiction-mismatch banner** when the patient state and provider state diverge. * A clean **link from the progress note** (CL-04) back to the CL-24 session record. You will see CL-24 surface in three places: * The **TelehealthConsentBadge** on the patient chart sidebar and on the PM-13 appointment form. * A **TelehealthSafetyChecklistSheet** that opens when you start a telehealth session. * New **Sessions** and **Compliance** pages under `/cl/telehealth/...`. > CL-24 never publishes telehealth billing modifiers. PM-07 continues to read modality, patient location, and provider location from the finalized progress note (CL-04). CL-24 only writes the **per-session compliance record**. *** ## Capturing telehealth consent Telehealth consent is captured **per patient**, not per session. Two consent types exist: | Consent type | When required | | -------------------- | ---------------------------------------------------------------------------------------------------------------------- | | `telehealth_general` | Any telehealth modality (video, audio-only, store-forward, remote monitoring). | | `audio_only` | Optional — only useful when a jurisdiction requires distinct audio-only language even though a general consent exists. | ### Inheritance rule (canonical) The single CL-24 rule for telehealth-consent inheritance — also enforced by `useStartTelehealthSession` and `cl_telehealth_consent_is_valid`: * **`telehealth_general` satisfies an audio-only session start.** A patient with valid general telehealth consent can be scheduled for audio-only without a separate `audio_only` row. * **`audio_only` does NOT satisfy a video / general telehealth session start.** A patient with only `audio_only` consent must be re-consented before video can be scheduled. So `audio_only` is the *narrower* consent type; `telehealth_general` is the *broader* type that covers audio-only too. ### How to capture 1. Open the patient's chart and look at the **Telehealth Consent** badge in the sidebar. 2. Click the badge → **Capture consent** → select the consent type. 3. Choose the consent method: * **Written** (paper, attach scan reference) * **Verbal attested** (clinician attests verbal consent) * **Electronic signature** (PF-33 e-signature integration if available; the dialog degrades gracefully if PF-33 is offline) 4. Confirm the consent language version (your org's current AZ template or US federal template is the default). 5. Save. The dialog writes a row to `cl_telehealth_consents` and publishes `cl_telehealth_consent_captured` to PF-10 for the patient-portal receipt. By default `expires_at = consented_at + 365 days` (org-configurable via `telehealth_consent_validity_days`). ### Cross-link * For the **PM-13** scheduling and session-launch workflow, see [PM-13 Telehealth User Guide](/pm/telehealth-user-guide). * For the underlying **progress-note** schema, see [CL-04 Progress Notes](/cl/progress-notes). *** ## Pre-session safety checklist When the **safety-checklist-required** flag is on, the **Start session** button opens the `TelehealthSafetyChecklistSheet` before the PM-13 join URL becomes available. Three items are **required**; one is optional. | Item | Required? | Why | | ------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Patient current location verified** | ✅ | The patient may have moved since intake. Telehealth across state lines without provider licensure in the *patient's current* state can violate scope-of-practice. ARS 13-3005 and analogous statutes also require accurate location for recording-notice law. | | **Local emergency number captured** | ✅ | If the patient becomes unsafe mid-session, the clinician must be able to direct local 911 / mobile crisis to the **patient's** location, not the provider's. Joint Commission CAMBHC NPSG.15.01.01 expects this for remote risk-bearing sessions. | | **Disconnect protocol acknowledged** | ✅ | The clinician confirms they have reviewed the agreed-upon plan if the call drops mid-session — phone fallback number, support person to call, when to escalate. Reduces lethality risk for crisis-vulnerable patients. | | **Support person on site** | Optional | Captures whether a non-clinical adult is present (e.g., parent for a minor session, family member for a Memory Care patient). Recorded on `support_person_on_site` + `support_person_name`. | When you submit, `safety_checklist_completed_at` is stamped, the database CHECK constraint `chk_cl_telehealth_safety_complete` verifies the three required fields are all true / non-null, and `cl_telehealth_session_safety_completed` is published so PM-13 knows it is safe to release the join URL. If the safety-checklist flag is set to **warn-only**, you'll see an inline warning instead of a hard block, and the session can still start. *** ## Logging connectivity issues mid-session If the call drops, the video freezes for >30 seconds, you switch to audio-only because video failed, or any other technically-meaningful event occurs, log it from the **session detail page**: 1. Open **CL → Telehealth → Sessions** and select the active session. 2. Click **Log connectivity issue**. 3. Select the issue type (`call_drop`, `video_freeze`, `switched_to_audio`, `other`), enter a brief note, and submit. Each entry is appended to `cl_telehealth_sessions.connectivity_issues` (a JSONB array) with a UTC timestamp and the logger's profile ID. Entries are immutable. They render on the session detail timeline and are pulled into payer-audit exports for AHCCCS CBHSG and CCBHC v2 reviews. > **Do not** delete a connectivity-issue entry. If something was logged in error, add a corrective entry rather than amending the prior one. *** ## Jurisdiction mismatch banner — what to do When the session is opened, CL-24 compares: * `patient_state` on the session (or, if blank, the patient's chart-of-record state) * `provider_state` on the session (or, if blank, the clinician's profile state) * The org's licensed-states list If the patient state and provider state differ, **or** the patient state is not in the org's licensed-states list, the `JurisdictionMismatchBanner` renders at the top of the session detail page. | Outcome | Action | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Banner says **"Out-of-state — verify licensure"** | Confirm you hold a license (or a recognized interjurisdictional compact such as PSYPACT) for the patient's current state. Document the basis in the session note. | | Banner says **"Recording-notice law differs"** | Confirm whether the patient's state is a two-party-consent state (AZ included under ARS 13-3005). Provide the recording notice required by the *patient's* state, not the provider's. | | Banner says **"Patient state unknown"** | Stop and verify with the patient. Update the session record. Re-evaluate the banner. | The banner is informational. CL-24 does **not** auto-block on jurisdiction; the clinician's professional judgment governs. *** ## Linking a progress note to a CL-24 session The CL-04 progress-note form auto-links to the CL-24 session in two ways: * **From an active session:** When you start documenting from `/cl/telehealth/sessions/:sessionId`, the **Create progress note** action carries the `session_id` forward. The note is saved with `cl_telehealth_sessions.progress_note_id` populated. * **From a chart:** In the progress-note picker, the "Link to telehealth session" dropdown lists today's sessions for that chart. Pick one to link. When the note is **finalized**, the existing `clinical_note_finalized` event (CL-04 → PM-07) fires with `is_telehealth`, `telehealth_modality`, `patient_location`, `provider_location`. **CL-24 does not republish this** — the billing pathway is unchanged. > If you forget to link the note at finalize time, an admin can backfill `progress_note_id` retrospectively (admin-only, with audit). See the admin guide. *** ## Revoking consent Patients can revoke telehealth consent at any time. 1. Open the patient's chart → **Telehealth Consent** badge → **View consent history**. 2. Locate the active consent row and click **Revoke**. 3. Enter a revocation reason (free-text). Submit. The system stamps `revoked_at = now()` and publishes `cl_telehealth_consent_revoked` (PF-10 routes notification to the clinician and to PM-13 so future join URLs are blocked for the chart). ### Immutability Once `revoked_at` is set, **non-admin** users cannot clear it. The `cl_enforce_consent_revocation_immutability` trigger raises an exception, even on a direct UPDATE. This is intentional: revocation is a clinical-legal event and audit immutability is a Joint Commission CAMBHC and AHCCCS requirement. If a revocation was entered in error and you need it reversed, request an admin override (see the [admin guide](/cl/telehealth-documentation-admin-guide#admin-override-for-revoked_at-immutability)). The admin override is logged. To re-establish consent for the same patient after a legitimate revocation, capture a **new** consent row. The system does not edit the revoked row — it adds a new active row alongside it. *** ## FAQ **Q: I started a session before the safety checklist sheet appeared. What happened?** A: The `telehealth_block_session_without_safety_checklist` flag is probably set to warn-only in your org. You'll see an inline warning instead of a blocking sheet. Capture the checklist on the session detail page before finalizing the note. **Q: The Telehealth Consent badge says "Expiring in 12 days." Will the session be blocked?** A: Not yet. The badge turns amber within 30 days of expiry and red after expiry. The consent-block flag only fires once the consent has actually expired or is revoked. Capture a renewal at the next visit. **Q: PM-13 says the patient hasn't joined yet but my session detail page says the safety checklist is done. Is something wrong?** A: No. The CL-24 safety checklist is a **pre-flight** record. PM-13 still tracks the actual session lifecycle (scheduled → active → completed) based on join timestamps from the vendor. **Q: Can I document the connectivity issue after the session ends?** A: Yes, retrospectively, on the session detail page. The session does not have to be `active`. We recommend logging within the same business day so the entry stays accurate. *** ## See also * [Telehealth Documentation — Admin Guide](/cl/telehealth-documentation-admin-guide) * [PM-13 Telehealth User Guide](/pm/telehealth-user-guide) * [CL-PM Telehealth Integration Contract](/architecture/integrations/CL-PM-TELEHEALTH) * [CL-24 Integration Contract](/architecture/integrations/telehealth-documentation-compliance-integration) * [Progress Notes (CL-04)](/cl/progress-notes)