Skip to main content

Scheduling Service — Migration Plan

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

1. Migration Scenarios​

Scenario A: Greenfield deployment​

  1. Run DB migrations.
  2. Configure tenant schedules via POST /v1/schedules.
  3. Generate slots via POST /v1/slots or availability pattern expansion.
  4. Configure holiday exceptions via POST /v1/schedules/:id/exceptions.
  5. Begin booking.

Scenario B: Migration from legacy scheduling module​

StepAction
1Export legacy appointments to JSON (id, patientId, providerId, locationId, startAt, endAt, status, reason)
2Map legacy statuses to FHIR vocabulary (scheduled→booked, completed→fulfilled, etc.)
3Create corresponding Schedule and Slot records first
4Import appointments via bulk-insert migration script (not public API); link to slots
5Verify appointment-slot linkage consistency
6Validate appointment counts and status distributions against legacy system

Scenario C: HL7 SIU feed cutover​

  1. Enable SIU adapter in interop-service pointing to scheduling-service.
  2. Run parallel mode (1 week): compare SIU-imported vs legacy-imported appointments.
  3. Verify no double-booking from dual-write period.
  4. Cut over live traffic.

2. Rollback Plan​

  • Schema: Drizzle down migrations per step.
  • Data: Migration imports use import_batch_id column; truncate by batch on rollback.
  • HL7 feed: Disable adapter in interop-service.