Skip to main content

Virtual Care Service — Migration Plan

Status: populated Owner: TBD Last updated: 2026-04-18 Companion: Service Template

1. Legacy Context​

The _sources/virtual-care/ module was originally scoped under the Ghasi EHR digital-communication service. The source SPEC.md references a migration path to a unified digital-communication service (ADR-0047). This documentation set retains virtual-care-service as a standalone service per the platform service catalog, with a clean separation of concerns. Session lifecycle and telehealth consent are owned here; messaging threads and notifications are owned by communication-service.

2. Migration from Legacy digital-communication​

Phase 0 — Schema Bootstrap (S0)​

  • Create virtual_care PostgreSQL database (isolated)
  • Run Drizzle ORM migrations for all tables
  • Bootstrap NATS stream VIRTUAL_CARE
  • Deploy service in shadow mode alongside legacy digital-communication

Phase 1 — Session Data Migration (S1)​

StepAction
1.1Export VirtualSession records from legacy digital-communication DB
1.2Map videoBackend field (default jitsi for all historical records)
1.3Migrate TenantVirtualCareConfig records; re-encrypt credentials in KMS
1.4Backfill SessionParticipant rows from historical audit logs
1.5All historical sessions loaded with status: ended or status: cancelled

Phase 2 — Jitsi Meet Migration (S2)​

StepAction
2.1Deploy branded Jitsi Meet instance (standalone, not bundled with EHR)
2.2Test JWT authentication with virtual-care-service
2.3Run parallel sessions (legacy + new service) for 2 weeks
2.4Validate Encounter creation, billing events, audit trail

Phase 3 — Consent Record Migration (S3)​

StepAction
3.1Export telehealth consent records from legacy patient-portal module
3.2Import into access-policy service (consent records owned there)
3.3Verify consent check integration between virtual-care-service and access-policy

Phase 4 — Traffic Cutover (S4)​

  • Update Kong routing to forward /api/v1/virtual-care/* to new service
  • Legacy digital-communication virtual session endpoints return 301 redirect
  • Monitor for 2 weeks; decommission legacy endpoints after stability confirmed

3. Tenant Onboarding (New Tenants)​

New tenants provisioned after Phase 4 cutover:

  1. Admin calls PUT /api/v1/virtual-care/config with Jitsi server URL and branding
  2. Admin calls POST /api/v1/virtual-care/config/test-connection to verify
  3. Module enabled via platform admin licensing API
  4. First session test conducted and Encounter creation verified

4. Rollback Plan​

  • Phases 0–3 are additive; legacy service remains running
  • Phase 4 Kong routing change is reversible within same deployment window
  • Legacy service decommission is gated on 2-week stability window

5. Data Validation Checklist​

  • All historical session records imported with correct status
  • Tenant configs migrated; test connection passing for all tenants
  • FHIR Encounters exist for all migrated ended sessions (or confirmed pre-FHIR era)
  • Consent records accessible via access-policy for all migrated tenants
  • Billing events verified for recently migrated sessions