> 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.

Asynchronous Telemedicine (Store-and-Forward)

A telemedicine delivery model where patients submit clinical data - images, videos, health records, questionnaires - to a provider, who reviews and responds later without a real-time interaction. Common in dermatology, radiology, and ophthalmology. Builders must ensure: secure encrypted upload, immutable submission timestamp, and audit trail for each provider review event. PHI in transit and at rest must be protected per HIPAA Security Rule.

Audio-Only Visit

A synchronous telemedicine modality using voice call without video, used when patients lack broadband access or video capability. CMS and many state Medicaid programs have temporarily or permanently expanded audio-only coverage. Builders must ensure: call session logging (start/end time, participant IDs), consent capture before session, and call audio is not recorded without explicit patient consent.

BAA (Business Associate Agreement)

A contractual agreement required by HIPAA (45 CFR § 164.504(e)) between a covered entity (telemedicine provider) and any business associate that creates, receives, maintains, or transmits PHI on their behalf. All video platform vendors, cloud hosting providers, EHR vendors, and infrastructure providers handling PHI in a telemedicine platform must have signed BAAs. Absence of a BAA for any PHI-processing vendor is a HIPAA violation.

Break-Glass Access

An emergency override mechanism that allows an authorized clinician to access a patient's record outside normal role-based access controls in an acute emergency situation. For telemedicine, break-glass is needed when the treating provider lacks access to PHI from an emergency session. The system must: require justification, log the access event (break-glass reason, clinician ID, timestamp, records accessed), alert the patient's regular care team, and generate a compliance review flag.

Carrier-Neutral Architecture

A telemedicine platform design that routes media (video/audio) through a carrier-independent signaling and media relay layer, preventing lock-in to a single WebRTC cloud provider. Enables fallback when primary provider is unavailable. The carrier-neutral approach is relevant to HIPAA because the media path must be secured regardless of the underlying carrier, requiring mutual TLS or DTLS-SRTP for all media streams.

Clinical Context Continuity

The ability of a telemedicine session to capture, transmit, and persist all clinically relevant context (patient history, current medications, allergies, recent labs) to the attending clinician before or during the remote session. Builders implement clinical context continuity through secure APIs to the patient's EHR, pre-session data pull with patient consent, and in-session clinical note capture that writes back to the EHR post-session.

Codec Selection

The choice of audio/video compression algorithms (codecs) for telemedicine media streams. Clinically relevant: codec quality affects diagnostic accuracy for visual assessments (dermatology, wound care, ophthalmic screening). VP8, VP9, H.264, and AV1 are common video codecs; Opus is standard for audio. Builders should implement adaptive bitrate streaming to maintain call quality on low-bandwidth connections, with minimum quality thresholds that trigger session degradation warnings.

The system processes for capturing, storing, and tracking patient consent for telemedicine services. HIPAA requires valid patient authorization for certain uses of PHI (45 CFR § 164.508). Many states require explicit written or electronic consent for telemedicine visits separate from in-person consent forms. Builders must: capture consent before first telehealth encounter; store consent with version, timestamp, and patient identity link; implement consent withdrawal workflows; and present consent history in patient records.

Cross-State Licensing

The regulatory requirement that clinicians delivering telemedicine services must be licensed in the state where the patient is physically located at the time of the visit. This creates significant complexity: a provider licensed in State A seeing a patient in State B must have a State B license. Data model implications: the platform must capture patient location at session start, verify provider license in that jurisdiction, and block or warn if provider is unlicensed in the patient's state. The Interstate Medical Licensure Compact (IMLC) allows faster multi-state licensure for qualifying physicians.

DTLS-SRTP

Datagram Transport Layer Security - Secure Real-time Transport Protocol. The encryption protocol stack used to secure WebRTC media streams (audio and video). DTLS establishes the keying material; SRTP encrypts the media payload. This combination provides end-to-end encryption for media in transit, satisfying HIPAA's Technical Safeguard requirement for PHI transmitted over networks. Builders must verify that their WebRTC implementation enables DTLS-SRTP by default and does not offer unencrypted fallback.

E-Prescribing

The electronic transmission of prescriptions from prescribing clinicians to pharmacies. For telemedicine, e-prescribing capabilities must comply with DEA regulations for controlled substances (21 CFR Part 1311) which require two-factor identity proofing at registration, two-factor authentication at time of prescription, and an auditable log of all EPCS (electronic prescribing of controlled substances) events. Non-controlled substance e-prescribing follows state e-prescribing laws.

Emergency Fallback Protocol

The procedures and system design for handling technical failures during a telemedicine session - audio degradation, dropped connections, platform outages. Builders must implement: automated reconnection attempts with countdown display, graceful session suspension with state preservation, alternative contact methods (phone callback, SMS), and post-failure session resumption that restores clinical context. Emergency fallback data must be retained for post-incident review.

Encounter Record

The structured clinical record generated from a telemedicine encounter, equivalent to a clinical note from an in-person visit. Must capture: session date/time, provider identity, patient identity, chief complaint, clinical assessment, plan, prescriptions, referrals, and follow-up instructions. The encounter record must be accessible to the patient, stored in compliance with applicable state medical records retention laws, and available for continuity of care data exchange (e.g., FHIR API export).

End-to-End Encryption (E2EE)

Encryption where only the communicating endpoints (patient and provider) hold the decryption keys - the platform intermediary cannot decrypt the content. E2EE for telemedicine video is technically complex because it conflicts with server-side features like recording, transcription, and AI analysis. HIPAA does not mandate E2EE specifically, but requires PHI to be protected from unauthorized access. Selective E2EE with key escrow for compliance recording is an emerging architecture pattern.

FHIR (Fast Healthcare Interoperability Resources)

An HL7 standard for healthcare data exchange via RESTful APIs. For telemedicine builders, FHIR R4 is the most relevant version. The 21st Century Cures Act mandates FHIR-based patient data access via certified EHR APIs. Telemedicine platforms should implement: FHIR API read access for pre-session patient data pull (medications, allergies, conditions), FHIR write-back for encounter records, and SMART on FHIR authorization for OAuth2-based patient app integrations.

Identity Assurance Level (IAL)

NIST SP 800-63A defines three Identity Assurance Levels for digital identity verification: IAL1 (self-asserted, no identity proofing), IAL2 (remote identity proofing with document verification), IAL3 (in-person or supervised remote identity proofing). For telemedicine prescribing controlled substances (EPCS), DEA requires IAL2+ identity proofing at registration. General telemedicine visits typically use IAL1 with multi-factor authentication.

IMLC (Interstate Medical Licensure Compact)

An agreement between participating US states enabling qualified physicians to obtain practice privileges in multiple states through a streamlined process. By 2024, 40+ states have joined IMLC. For telemedicine platform builders, IMLC membership is relevant to the cross-state licensure verification workflow - IMLC member states can be verified through the IMLC database rather than individual state medical boards.

Media Server

A WebRTC selective forwarding unit (SFU) or multipoint control unit (MCU) that routes or mixes media streams between participants. For telemedicine with 2+ participants (patient, provider, specialist, interpreter), an SFU or MCU is required. The media server sits in the media path and therefore handles PHI - it must be deployed in a HIPAA-compliant environment with a BAA from the media server vendor or hosting provider.

Multi-Factor Authentication (MFA)

An authentication mechanism requiring two or more verification factors from distinct categories: something you know (password), something you have (authenticator app, hardware token), something you are (biometric). HIPAA's Technical Safeguard requires unique user identification (45 CFR § 164.312(a)(2)(i)) and does not explicitly mandate MFA, but MFA is widely recognized as a reasonable and appropriate safeguard for PHI access. For telemedicine, MFA must be enforced for provider login; patient MFA is strongly recommended.

No-Show and Late-Cancellation Handling

Business and technical processes for managing appointment non-attendance. Builders must: implement automated reminders (SMS, email, push) with configurable lead times; enforce a session entry hold period for late patients; capture "no-show" disposition in the encounter record; trigger billing-side no-show fee workflows if applicable; and retain scheduling records in compliance with applicable retention requirements.

Patient Portal

A secure online interface providing patients direct access to their health information - visit summaries, lab results, prescription history, and telemedicine scheduling. For telemedicine, the portal is typically the patient-side session entry point. Security requirements: MFA-protected login, session timeout after inactivity, encrypted connection, and audit logging of PHI access. ONC's Information Blocking rules (21st Century Cures Act) prohibit unreasonable patient portal access restrictions.

PHI (Protected Health Information)

Any individually identifiable health information created, received, maintained, or transmitted by a HIPAA-covered entity or business associate. For telemedicine, PHI includes: video/audio session content, encounter notes, prescriptions, diagnoses, patient-provided health history, device sensor data, chat messages containing health information, and session metadata (appointment time, provider name) when linked to a patient. All PHI must be encrypted in transit and at rest and access-controlled per HIPAA.

Prescription Drug Monitoring Program (PDMP)

State-mandated electronic databases that track controlled substance prescriptions dispensed within the state. For telemedicine providers prescribing controlled substances, PDMP checks are often required by state law before prescribing. Builders should implement PDMP query APIs (most states use PMPInterConnect for interstate queries) and record the query result and any alerts in the encounter record.

Ryan Haight Act

The Ryan Haight Online Pharmacy Consumer Protection Act of 2008 (Public Law 110-425) prohibits the prescription of controlled substances via the internet without a prior in-person medical evaluation - with limited exceptions. Key exceptions: DEA-registered telemedicine platforms, VA providers, public health emergencies (the COVID-19 pandemic extended an exception under public health emergency authority). Builders must implement a controlled substance prescribing gate that enforces the in-person evaluation requirement unless a documented exception applies.

Session Recording

Capture of video/audio session content for clinical, legal, or quality assurance purposes. Critical compliance requirements: explicit patient consent must be obtained before recording; recordings are PHI and must be stored encrypted with access controls; retention period must align with state medical records law (typically 7-10 years); patients have the right to access recordings as part of their medical record; and recording consent must be revocable (patient can request recording stop or deletion per state law).

SIP (Session Initiation Protocol)

A signaling protocol for establishing, modifying, and terminating real-time communication sessions. Used in enterprise telephony and some telemedicine platforms alongside or instead of WebRTC. SIP-based telemedicine requires TLS transport for signaling (SIP/TLS) and SRTP for media encryption. SIP trunk connections handling PHI must be covered by BAAs with the SIP trunk provider.

SMART on FHIR

An open standard combining FHIR for healthcare data with OAuth2/OIDC for authorization. Enables telemedicine apps to request specific patient data from EHR systems with patient authorization. Builders use SMART on FHIR launch protocol for: provider-context launches from EHR workflows, patient-facing app authorization, and cross-organization data sharing with granular scope control (e.g., read:patient, read:medication, write:encounter).

Synchronous Telemedicine

Real-time interactive telemedicine where patient and provider communicate live via video, audio, or chat. The most common modality for primary care, urgent care, and specialist consults. System requirements: low-latency encrypted media, session state management, concurrent clinical note capture, and reliable session reconnection. All real-time session content is PHI and subject to HIPAA and state telemedicine laws.

Telehealth vs Telemedicine

Telehealth is the broader term encompassing all health-related services delivered at a distance, including non-clinical services (health education, remote monitoring, administrative services). Telemedicine refers specifically to clinical services delivered remotely - diagnosis, treatment, prescribing. The distinction matters for builders because: telemedicine triggers physician licensing requirements, HIPAA Business Associate obligations, and clinical record-keeping duties that pure telehealth education platforms may not face.

Token-Based Session Authentication

Using short-lived, signed tokens (JWT, session token) to authenticate session participants - patient and provider - at session entry. For telemedicine, token validation at session start must: verify patient identity matches the scheduled appointment, verify provider license in patient's state, confirm consent is on file, and set session-scoped permissions (e.g., recording consent state, prescription capability). Tokens must expire; long-lived tokens on telemedicine platforms are a security vulnerability.

WebRTC (Web Real-Time Communication)

An open browser standard enabling real-time peer-to-peer or server-mediated audio, video, and data communication without plugins. The primary protocol stack for modern web-based telemedicine. Key security elements: DTLS-SRTP for media encryption, ICE for NAT traversal, and HTTPS/WSS for signaling. For telemedicine builders: disable HTTP fallback, enforce DTLS-SRTP, use TURN servers deployed in HIPAA-compliant infrastructure, and log all ICE connectivity events for session audit trails.

Workflow Integration

The integration of telemedicine sessions into existing clinical workflows - EHR scheduling, care team notifications, billing, and follow-up care coordination. Builders implement workflow integration through: EHR launch APIs (SMART on FHIR, HL7 FHIR workflows), automated encounter note push-back to EHR, billing code generation from encounter data, and care team notification webhooks for session outcomes (prescription issued, referral placed, follow-up scheduled).

Adaptive Bitrate (ABR)

A streaming technique that dynamically adjusts video and audio quality based on available network bandwidth. For telemedicine, ABR is a patient safety feature: degrading gracefully to audio-only (rather than dropping the session) preserves clinical continuity when network conditions deteriorate. Builders implement ABR by setting minimum quality thresholds, configuring WebRTC codec bitrate constraints, and monitoring packet loss / jitter statistics to trigger quality transitions.

Ambient Clinical Intelligence (ACI)

AI systems that passively capture and structure clinical data from telemedicine sessions - ambient transcription, automated note generation, diagnosis suggestion. ACI tools that process session audio or video handle PHI and require: HIPAA BAA with the ACI vendor, explicit patient consent for AI processing of session content, provider review and sign-off on AI-generated notes before they enter the clinical record, and a bias monitoring program for diagnostic suggestion features.

Audit Trail

A time-ordered, append-only log of all events involving PHI access and modification within a telemedicine platform. HIPAA requires hardware, software, and procedural mechanisms to record and examine activity in information systems containing ePHI (45 CFR § 164.312(b)). For telemedicine, the audit trail must capture: session lifecycle events (session start/end, consent given, recording enabled), all PHI reads and writes (who accessed what record at what time), authentication events (login, MFA, failed attempts), and administrative events (permission changes, user provisioning).

Care Coordination Protocol

Structured clinical and technical procedures for managing patient care across multiple providers or settings via telemedicine. For builders, care coordination requires: secure messaging between care team members, shared access to encounter notes with role-based permissions, referral workflow integration (FHIR ServiceRequest resource), follow-up scheduling triggers based on encounter outcomes, and audit trails for all cross-provider data sharing. PHI shared across organizations requires BAAs with each receiving organization.

Digital Health Equity

The principle that telemedicine platform design must not systematically exclude patients based on device access, internet connectivity, literacy, or disability status. Builders implement digital health equity by: supporting audio-only fallback for low-bandwidth environments, providing accessible UI (WCAG 2.1 AA), offering SMS-based session initiation for patients without smartphones, providing translated consent forms for non-English speakers, and testing the platform with assistive technologies before release.

HIPAA Minimum Necessary Standard

The HIPAA Privacy Rule principle (45 CFR § 164.502(b)) requiring that PHI disclosures be limited to the minimum information necessary to accomplish the intended purpose. In telemedicine system design, this means: APIs should return only the specific PHI fields needed for the task; clinicians should see only the records relevant to the current session; bulk export APIs should require explicit justification; and FHIR resource scopes should be as narrow as the use case allows.

ICE (Interactive Connectivity Establishment)

A framework for establishing peer-to-peer UDP or TCP connections through NAT firewalls in WebRTC. ICE gathers candidates from local interfaces, STUN servers, and TURN relays to find the optimal media path. For telemedicine builders: STUN/TURN servers in the media path handle PHI and must be deployed in HIPAA-compliant infrastructure; ICE connection failures should be logged with candidate type and error code for session debugging; and TURN relay fallback capacity must be sized for peak concurrent session load.

Minimum Viable Fallback

The lowest-fidelity communication modality a telemedicine platform will offer before abandoning a session: typically a provider-initiated phone callback to the patient's number on file. The minimum viable fallback exists as a patient safety guarantee - no matter what technology fails, the provider must be able to reach the patient. Builders must store a validated patient callback number at scheduling time, trigger fallback automatically after reconnection attempts are exhausted, and log fallback events for post-incident analysis.