> Disclaimer: This content is for educational and reference purposes for software builders only. It does not constitute medical, legal, financial, or regulatory advice. Consult a qualified professional before making decisions based on this content.

Enforce DTLS-SRTP on All Media Paths - Never Allow Unencrypted Fallback

Rationale: HIPAA's Technical Safeguard for transmission security (45 CFR § 164.312(e)(1)) requires that ePHI transmitted over electronic communications networks be protected from unauthorized access. A telemedicine video session carries audio, video, and potentially text chat - all of which may contain PHI. WebRTC mandates DTLS-SRTP by specification, but misconfigured servers or legacy SDK modes can expose unencrypted TURN relay paths.

Do: Configure WebRTC servers to reject any session establishment that does not successfully complete DTLS handshake. Audit TURN server logs for unencrypted relay attempts. Use only WSS (WebSocket Secure) for signaling - never WS. Apply TLS 1.2+ with strong cipher suites to all TURN/STUN server connections. Run regular TLS configuration scans (testssl.sh or equivalent) on all telemedicine infrastructure.

Do not: Enable "plain RTP" fallback modes, even for debugging or low-bandwidth scenarios. Never use http:// endpoints for any telemedicine-related API. Do not accept self-signed certificates from providers without certificate pinning in clinical settings.

Rationale: State telehealth consent laws require patients to provide informed consent before receiving telemedicine services. Consent captured after session entry, or not captured at all, creates regulatory exposure. Additionally, HIPAA authorization requirements (45 CFR § 164.508) apply to specific uses of PHI including sharing with third-party services integrated in the session (AI transcription, remote specialist consultation).

Do: Present consent forms on a pre-session waiting screen. Store each consent event with: consent version ID (content hash), patient identity token, timestamp (UTC), collection method (click-through, e-signature), IP address, and session ID. Implement consent versioning - if consent text changes, existing patients must re-consent. Provide a clear consent revocation path. Log every consent state change in the audit trail.

Do not: Allow session entry without a confirmed consent record on file. Do not collect consent via email confirmation that cannot be cryptographically linked to the session. Do not combine recording consent with general telehealth consent - these are separate legal requirements in most states.

Implement Cross-State Licensure Verification at Session Pre-Authorization

Rationale: Practicing medicine without a license in the patient's state is a criminal offense in every US state. Telemedicine platforms that allow unlicensed cross-state care create liability for both the provider and the platform. The patient's physical location - not billing address - determines the applicable licensing jurisdiction.

Do: At appointment booking, capture and store the patient's intended state. At session pre-authorization (5-10 minutes before session start), re-verify the patient's current physical state via attestation with fraud controls. Query a license verification service (FSMB DocInfo, IMLC database, direct state medical board API) to confirm the provider has an active license in the patient's state. If verification fails: block session entry, notify the provider with the specific license gap, offer to reschedule with a licensed provider. Log every license verification attempt: timestamp, patient state, provider ID, license states found, and decision.

Do not: Rely on self-reported provider license data without primary source verification. Do not cache license status for more than 24 hours - licenses can be suspended without advance notice. Do not use billing address as a proxy for patient location.

Implement Session State Preservation and Graceful Reconnection

Rationale: Network interruptions during telemedicine sessions are common. An abrupt session drop without state preservation can result in lost clinical notes, incomplete consent records, and frustrated patients - creating both clinical risk and poor user experience. Emergency fallback protocols are a patient safety requirement.

Do: Save clinical notes in progress to the server every 30 seconds (autosave). On disconnection, preserve the session state (connected parties, consent state, recording status, notes drafted) for at least 10 minutes. Implement client-side reconnection with exponential backoff and clear visual countdown. If full reconnection fails, offer automatic fallback to audio-only. If audio fails, trigger an SMS/push notification to the patient with a provider callback number. Log all disconnection events with reason code, duration, and reconnection outcome.

Do not: Design sessions as single-shot connections with no reconnection logic. Do not lose clinical note content on disconnection. Do not rely on browser session storage for clinical note drafts - server-side autosave is required.

Enforce MFA for All Provider Accounts Accessing PHI

Rationale: Credential compromise is the leading cause of healthcare data breaches. Telemedicine provider accounts have access to patient PHI, prescription capabilities, and clinical records - making them high-value targets. HIPAA's Technical Safeguard for unique user identification (45 CFR § 164.312(a)(2)(i)) requires individual credentials; MFA significantly reduces compromise risk from phishing and password reuse.

Do: Enforce MFA at login for all provider accounts - no exceptions for "convenience" or legacy tools. Prefer authenticator apps (TOTP) or hardware keys (FIDO2/WebAuthn) over SMS OTP for provider accounts. Implement step-up authentication for high-risk actions: prescribing controlled substances, exporting patient records, accessing recordings. Enforce session timeout after 15-30 minutes of inactivity. Log all authentication events (success, failure, MFA type used) in the audit trail.

Do not: Allow providers to disable MFA via account settings. Do not use SMS OTP as the sole second factor for accounts with prescription capabilities - SIM-swap attacks make SMS OTP unreliable for high-assurance contexts. Never allow shared provider login credentials.

Use Short-Lived, Scope-Bound Tokens for Session Authorization

Rationale: Telemedicine sessions involve multiple participants (patient, provider, interpreter, specialist) with different permission scopes. A long-lived or over-permissioned token creates risk: a leaked patient session link could allow unauthorized PHI access, or a provider could access sessions outside their authorized scope. Token design is a security-critical architectural decision.

Do: Issue session-scoped JWTs at session entry with: patient ID, provider ID, session ID, authorized scopes (can-prescribe, can-record, can-invite-specialist), session expiry (1 hour maximum), and issued-at timestamp. Validate tokens on every API call. Implement token refresh with sliding expiry for active sessions. Invalidate session tokens immediately at session end or patient revocation. Store token issuance and revocation events in the audit trail.

Do not: Issue tokens with no expiry or multi-day expiry for telemedicine sessions. Do not embed PHI in JWT payloads - use opaque identifiers and look up PHI server-side. Do not reuse session tokens across different patients or visits.

Encrypt All PHI at Rest with AES-256 and Separate Key Management

Rationale: HIPAA designates encryption at rest as an addressable specification that is universally considered reasonable and appropriate for telemedicine. Session recordings, encounter notes, patient-submitted images, and consent records all constitute PHI - unencrypted data at rest in a breach is automatically a reportable HIPAA violation.

Do: Encrypt all PHI-containing objects (database rows, file storage objects, backups) with AES-256. Use customer-managed encryption keys (CMEK) via a cloud KMS or HSM. Rotate encryption keys annually. Store keys separately from the encrypted data they protect. Audit key access events. For cloud object storage (session recordings), enable server-side encryption with CMEK and Object Lock (WORM) for immutable retention.

Do not: Store unencrypted PHI in any persistence layer - including development and staging environments. Do not store encryption keys in the same database or environment as the encrypted data. Do not disable encryption for "performance" reasons.

Build Tamper-Evident Audit Logs for All PHI Access and Session Events

Rationale: HIPAA requires hardware, software, and procedural mechanisms to record and examine activity in information systems containing ePHI (45 CFR § 164.312(b)). In telemedicine, the audit trail must capture not just data access but session lifecycle events (consent given, session started, recording enabled, prescription issued) because these are clinically and legally significant. Audit logs are the primary evidence in HIPAA investigations and litigation.

Do: Log every session lifecycle event: session created, patient joined, provider joined, consent given, recording started/stopped, prescription issued, session ended. Log every PHI access: who accessed what record, at what time, for what purpose (session vs. administrative review vs. audit). Write all logs to an append-only, tamper-evident store separate from the application database. Retain logs for at least 6 years. Alert on anomalous patterns: bulk exports, after-hours access, access from new geographic locations.

Do not: Write audit logs to the same database table as clinical records. Do not allow application service accounts to delete or modify audit records. Do not log PHI field values in audit entries accessible to general staff - log record IDs and access events only.

Implement PDMP Query Integration Before Controlled Substance Prescribing

Rationale: Many US states legally require prescribers to check the Prescription Drug Monitoring Program database before prescribing Schedule II-V controlled substances. Failure to check can result in professional license sanctions and civil liability. Telemedicine platforms that support e-prescribing of controlled substances must integrate PDMP queries into the prescribing workflow.

Do: Integrate with your state's PDMP and PMPInterConnect for interstate queries at the point of prescribing. Display the PDMP result to the provider before the prescription is finalized. Record in the encounter note: PDMP queried (yes/no), query timestamp, and provider attestation of review. Implement a configurable gate that blocks prescribing until PDMP review is acknowledged. Support multi-state PDMP queries for patients who may have recently moved.

Do not: Allow controlled substance prescriptions to be issued without PDMP query attestation in states where queries are required. Do not cache PDMP results for re-use across separate prescribing events - query fresh at each encounter.

Design the Data Model for Multi-State Licensing and Session Jurisdiction

Rationale: Telemedicine's cross-state nature creates a complex licensing data model problem. The jurisdictional state - the patient's physical location - is not always known at appointment booking and must be verified at session time. The data model must support: provider multi-state license records, session-time jurisdiction capture, and license verification event logging.

Do: Maintain a provider_licenses table with state, license number, license type, active status, expiration date, and last verification timestamp. Implement a session_jurisdiction record capturing: patient_state (from attestation), provider_id, license_verification_id, verification_timestamp. Track license verification events separately from session records for audit purposes. Implement alerts for expiring licenses (90-day advance warning). Use state FIPS codes (not state names) as canonical identifiers to avoid normalization issues.

Do not: Store only one license per provider. Do not use patient billing address as session jurisdiction - it must be physical location at time of visit. Do not skip re-verification at session time even if licensure was verified at booking.

Implement Accessible, Low-Bandwidth Fallback Modes

Rationale: Telemedicine patients disproportionately include elderly patients, rural populations, and individuals with disabilities - groups with above-average rates of limited internet access or assistive technology use. ADA requires "effective communication" accommodation; HIPAA doesn't require accessibility per se, but building inaccessible telemedicine violates healthcare equity obligations.

Do: Implement adaptive bitrate video that degrades gracefully on low bandwidth (minimum viable: audio-only with shared video frame). Provide audio-only mode that activates automatically when bandwidth falls below threshold. Build for WCAG 2.1 AA: keyboard navigation, screen reader compatibility, color contrast ≥ 4.5:1, closed captioning support. Test with assistive technologies (NVDA, JAWS, VoiceOver) before release. Implement timeout warnings accessible to screen readers.

Do not: Build video-only session flows with no audio fallback. Do not use color alone to communicate status (use icons + text). Do not require JavaScript for consent capture - ensure consent forms work with screen readers.

Sanitize PHI from Application Logs and Error Traces

Rationale: Application logs and error traces frequently contain PHI - patient names, diagnoses, device identifiers - injected by logging frameworks that capture request/response bodies or exception stack traces. Log files in telemedicine platforms are a high-frequency source of PHI exposure and are often stored in less-secure infrastructure than clinical databases.

Do: Implement a structured logging schema with a PHI exclusion list: never log patient name, date of birth, diagnosis codes, prescription data, or appointment details in plain text. Use opaque IDs (patient_id, session_id) in logs, not names or identifiers. Apply a log sanitizer middleware that scrubs known PHI patterns (SSN regex, MRN formats, name+DOB combinations) before writing to any log destination. Include "PHI in logs" as a mandatory item in pre-release security checklists.

Do not: Log full request/response bodies from telemedicine API endpoints. Do not enable verbose debug logging in production telemedicine systems without a time-limited window and automatic revert. Do not route application logs to third-party log aggregation services without verifying BAA coverage.