Virtual Care Service — Service Overview
Status: populated Owner: TBD Last updated: 2026-04-18 Companion: Service Template · 03 platform-services · 02 DDD
1. Purpose
The virtual-care-service enables telehealth consultations on the Ghasi eHealth platform. It owns the full session lifecycle for both synchronous video visits and asynchronous (store-and-forward) visits: creation → scheduling → waiting room → active → end → documentation. It manages consent capture, bandwidth-adaptive fallback, recording consent and metadata, multi-participant waiting room, FHIR Encounter creation on session end, and integration with scheduling, billing, and communication services.
The normative video backend is self-hosted Jitsi Meet with Ghasi branding. Provider-agnostic adapter architecture supports alternative backends (Mediasoup, Zoom, Webex, Teams). Designed for intermittent connectivity (Afghanistan reference: 3G/2G, ~1 Mbps realistic) with explicit video → audio-only → async-text fallback chain.
This is a licensed add-on module (TELEMED-VC).
2. Bounded Context
| Aspect | Value |
|---|---|
| DDD context | Virtual Care (telehealth session lifecycle) |
| Source of truth for | VirtualSession records, session participants, tenant virtual-care config, consent capture |
| NOT source of truth for | Clinical Encounter content (owned by patient-chart-service), appointment records (owned by scheduling-service), messaging threads (owned by communication-service), recording files (stored in document-service) |
3. Responsibilities
| # | Responsibility |
|---|---|
| R1 | Session CRUD: create, list, get |
| R2 | Session lifecycle FSM: scheduled → waiting → active → ended / cancelled / failed |
| R3 | Waiting room: join tokens (HMAC-signed), admit/remove participants |
| R4 | Consent capture: telehealth consent + recording consent (separate gates) before session |
| R5 | Bandwidth fallback: video → audio-only → async text at configurable thresholds |
| R6 | Multi-participant sessions: provider, patient, interpreter, observer roles |
| R7 | Jitsi Meet integration: room provisioning, tenant branding, JWT auth |
| R8 | Recording: metadata tracking; Jibri reference; patient consent required |
| R9 | FHIR Encounter creation on session end (via FHIR Gateway) |
| R10 | Billing event emission on chargeable session end |
| R11 | AI-assisted documentation: STT + session summary drafts via ai-gateway-service (HITL required) |
| R12 | Tenant virtual-care configuration management |
| R13 | Async store-and-forward visit support for offline-authored content |
4. Non-Responsibilities
| Non-responsibility | Owned by |
|---|---|
| Appointment scheduling | scheduling-service |
| Messaging thread content | communication-service |
| Clinical note writing | patient-chart-service |
| Recording file storage | document-service |
| Payment processing | billing-service |
| Patient notifications | communication-service |
| IRB / telemedicine regulatory compliance | MoPH / legal |
5. Upstream / Downstream Dependencies
6. Key Architectural Decisions
| Decision | Choice | Rationale |
|---|---|---|
| Default video backend | Self-hosted Jitsi Meet | No commercial lock-in; data sovereignty; MoPH infrastructure |
| Join token auth | HMAC-signed token (HS256 per tenant JWT secret in KMS) | Stateless; short-lived (15 min default); no Keycloak dependency on token validation path |
| Session–Encounter mapping | 1:1 — Encounter created on session end | FHIR R4; clinical record of telehealth visit lives in patient-chart-service |
| Bandwidth fallback | Configurable thresholds; video→audio-only→async text | Afghanistan 3G/2G context; patient must not be silently dropped |
| Recording consent | Separate from telehealth consent; required before Jibri activation | Privacy requirement; each consent is a distinct act |
| Event ordering | NATS subject key = sessionId | Ordered delivery per session; consumers can rely on lifecycle event sequence |
| Async visit (store-and-forward) | Clinical content authored offline and submitted when connectivity restored | Afghanistan offline context |
7. Client Surfaces
| Surface | Notes |
|---|---|
| Web clinical shell | Full clinician session controls |
| Patient portal web | Join link from appointment notification |
Patient mobile (apps/ehr-patient-mobile) | React Native; push + deep link for join |
Desktop (apps/ehr-desktop) | Electron; embedded Meet + screen share |
8. Source Reconciliation
Primary source: services/virtual-care-service/_sources/virtual-care/ (single module). Legacy module ID TELEMED-VC preserved in FR column. Note: the source SPEC.md references a deprecated migration to digital-communication service — this documentation set treats virtual-care-service as the canonical standalone service per the platform service catalog assignment. Event domain virtual_care per NAMING.md (replaces legacy VIRTUAL_CARE.* NATS prefix convention).