Telemedicine App Development

Healthcare providers, digital health companies, and specialty care networks building telemedicine platforms need engineering teams who understand both the real-time infrastructure of video consultation and the clinical data standards that govern every record the platform creates. Scrums.com provides dedicated software engineering teams for telemedicine platform development, deploying production-ready systems with HIPAA-compliant session architecture, HL7 FHIR integration, and the append-only clinical record model that regulatory audits require.

Video Consultation Infrastructure and Session Architecture

Telemedicine platforms manage a session lifecycle that spans scheduling, waiting room, live consultation, and post-session clinical documentation. Each phase produces auditable records that must be linked to the patient's encounter.

Sessions use a telehealth_sessions table: session_id, appointment_id, patient_id, clinician_id, session_type (CONSULTATION | FOLLOW_UP | TRIAGE | URGENT_CARE | MENTAL_HEALTH | CHRONIC_DISEASE_REVIEW), status machine (SCHEDULED / WAITING_ROOM / ACTIVE / COMPLETED | ABANDONED | NO_SHOW), scheduled_at, initiated_at, ended_at, and duration_seconds computed on close. Every status transition writes a session_events row: no status field is ever updated in place.

Video infrastructure is abstracted through a video_provider_adapter interface (Twilio, Daily.co, Vonage, Zoom for Healthcare). The adapter creates a provider room, returns a room_id and participant tokens, which are stored in a video_session_map table: session_id, provider, provider_room_id, patient_token, clinician_token, token_expires_at. Tokens are short-lived with a configurable TTL. Switching providers requires only a new adapter: no schema changes.

Session recording consent is handled through a session_consent_records table: session_id, patient_id, consent_type (RECORDING | DATA_PROCESSING | TELEHEALTH_TERMS), consented_at, consent_method (IN_APP_CLICK | VERBAL_CONFIRMED_BY_CLINICIAN), and ip_address. Consent is required before the patient token is issued; the token generation check validates consent record existence before proceeding.

Technical quality events (packet loss, bitrate drops, participant disconnects) are written to session_quality_events: session_id, participant_id, event_type, severity, timestamp, metadata (JSONB). Quality event data drives post-session SLA tracking and infrastructure health monitoring, not clinical records.

Appointment Scheduling, Provider Availability, and Waiting Room Management

Telemedicine scheduling requires availability management for clinicians across multiple specialties, time zones, and visit types, with real-time slot inventory to prevent overbooking.

Provider availability is stored in a provider_availability table: clinician_id, day_of_week (0-6), start_time, end_time, visit_types_allowed (JSONB array), max_concurrent_sessions. Availability overrides (holidays, one-off blocks) write to provider_availability_overrides with start_datetime, end_datetime, reason. The schedulable_slots view materialises available slots from base availability minus existing appointments minus overrides.

Slot booking uses SELECT ... FOR UPDATE on the slot record to prevent double-booking under concurrent requests. On booking, a telehealth_appointments row is written: appointment_id, clinician_id, patient_id, slot_start, slot_end, visit_type, and a status machine (SCHEDULED / CONFIRMED / CHECKED_IN / COMPLETED | CANCELLED | NO_SHOW). Each status change writes an appointment_events row.

Waiting room management uses a waiting_room_entries table: session_id, patient_id, joined_at, clinician_notified_at, and queue position derived from joined_at order. When a patient joins before the clinician, a clinician_notification event fires via the notification_adapter. Queue position and estimated wait time are pushed to the patient via WebSocket from a queue_status view refreshed on each new entry.

No-show logic uses a no_show_policy config table: (visit_type, grace_period_minutes, action [CANCEL | CONVERT_TO_ASYNC | HOLD]). After the grace period with no patient join, the session_events log records a NO_SHOW_TRIGGERED event and the configured action fires. Repeat no-shows write to patient_no_show_log; patients exceeding a configurable threshold trigger a care coordinator review task.

Telemedicine apps like these are built and delivered by dedicated engineering teams through our mobile app development service.

e-Prescribing, Clinical Documentation, and Asynchronous Care

Telemedicine platforms that issue prescriptions must enforce the same clinical decision support and PDMP reporting requirements as in-person pharmacy systems, with the additional constraint that prescribing happens at the close of a remote session.

e-Prescribing uses an outbound_prescription_messages table with adapter-based routing (Surescripts, NHSEPS, HL7 FHIR). Prescriptions issued during a telehealth session carry session_id as a foreign key: every prescription is traceable to the encounter that generated it. Controlled substance prescriptions are subject to DEA requirements (Ryan Haight Act in the US): the DEA_exempt_encounter_type flag on the session must be set (or a prior in-person visit confirmed) before a Schedule II+ prescription is routed. Attempted controlled substance prescriptions that fail DEA eligibility checks write to controlled_substance_block_events with reason code: these events cannot be suppressed.

Clinical documentation uses a session_notes table: session_id, authored_by, note_type (SUBJECTIVE | OBJECTIVE | ASSESSMENT | PLAN | FOLLOW_UP), note_text (encrypted at rest), authored_at, and a status machine (DRAFT / FINAL / AMENDED). Amendments add a new note row with amended_from referencing the original: original notes are never deleted or modified. SOAP components are stored as separate rows per note_type and assembled by the SOAP view at read time.

Diagnosis codes (ICD-10/ICD-11) recorded during the session write to session_diagnoses: session_id, condition_code, condition_description, diagnosis_status (PRIMARY | SECONDARY | DIFFERENTIAL), clinician_id, diagnosed_at. These rows are append-only; status changes write new rows with reference to the prior row.

Asynchronous care uses a patient_submissions table: submission_type (QUESTIONNAIRE | PHOTO | DEVICE_READING | SYMPTOM_LOG), content_reference (S3 object key), submitted_at, and a review_workflow (PENDING / IN_REVIEW / RESPONDED | ESCALATED | EXPIRED). Response SLA is enforced by a background job against response_sla_config per submission_type, generating sla_breach_events when breached. All submissions and responses link to encounter_id: they are never floating records.

HIPAA Compliance, EHR Integration, and Multi-Specialty Architecture

Telemedicine platforms handling PHI must enforce HIPAA's Security Rule across access controls, audit controls, and transmission security. These are architectural requirements, not compliance checkboxes.

Access controls follow the minimum necessary standard through row-level security: clinicians can only query patient records where they have an active care relationship (care_team_members or an active telehealth_appointments row). Break-glass emergency access writes a break_glass_events row with accessor_id, patient_id, reason, and access_purpose: this event automatically creates a Privacy Officer review task and cannot be suppressed.

Transmission security uses TLS 1.2+ for all API traffic. Session tokens are short-lived JWTs (configurable TTL, default 15 minutes) with refresh token rotation: each refresh invalidates the previous refresh token, tracked in token_rotation_log. Video participant tokens are single-use with session-scope audience claims. API keys for provider integrations are stored encrypted at rest with key rotation managed through KMS.

The audit_log table records every data access event with accessor_id, access_type (VIEW | EXPORT | PRINT | SHARE), resource_type, resource_id, accessed_at, and ip_address. Audit log rows are append-only. The audit_log_integrity_chain table stores a rolling HMAC per batch of records, enabling tamper detection. This satisfies HIPAA §164.312(b) audit control requirements.

EHR integration uses the adapter-based fhir_resource_cache (FHIR R4) and hl7_message_log (HL7 v2 ADT/ORU/ORM). Encounter summaries post back to the EHR as FHIR Encounter and Composition resources via fhir_outbound_queue with retry and delivery confirmation. New EHR systems require only a new adapter: no schema changes.

Multi-specialty architecture keeps specialty-specific rules in config, not code: specialty_visit_types defines allowed visit types per specialty; specialty_documentation_templates defines required note fields per specialty; specialty_prescribing_rules defines formulary restrictions per specialty. A psychiatry deployment and an urgent care deployment share the same schema: the specialty_config tables control the difference.