Skip to main content

Implementation Roadmap: Desktop Electron EHR

Version: 1.0
Date: 2026-03-31
Companion: BACKEND_AND_SERVICE_MAP.md, AI_AGENT_BUILD_GUIDE.md

Phase 0 — Repository and tooling​

  • Add apps/ehr-desktop (or name aligned with product) to the monorepo; pnpm-workspace.yaml already includes apps/*.
  • Wire Vite + React + Electron build, lint, and test scripts consistent with repo standards (TESTING_STANDARDS.md).
  • Document env vars and secrets handling (TECHNICAL_REQUIREMENTS.md).

Exit criteria: pnpm build produces dev and packaged artifacts; no secrets in renderer bundle.

Phase 1 — Secure shell and authentication​

  • Main/preload/renderer boundaries per TR-DSK-001–004.
  • OIDC login, token storage (OS secure storage), session refresh.
  • Tenant selection and stale entitlement handling (403 / licensing).

Exit criteria: User can sign in, select tenant, and call a read-only Kong endpoint successfully.

Phase 2 — Local store and outbound queue​

  • SQLite schema + migrations; encryption at rest per policy.
  • Outbox with clientMutationId, statuses, reconciliation.
  • Sync scheduler with backoff and online detection.

Exit criteria: Unit tests for outbox; simulated offline→online replay against mock HTTP.

Phase 3 — UI parity baseline​

  • MUI theme aligned with UI_AND_DESIGN_PARITY.md.
  • Shell layout (navigation, header, connectivity/sync banner) matching ehr-web patterns.
  • Localization: react-intl + @ghasi/i18n keys; RTL + mixed-direction checklist per §4; TR-DSK-070–076.
  • Optional: AI shell entry points behind flags (cloud orchestrator only until local engine approved).

Exit criteria: Visual review checklist passed against ehr-web reference screens; RTL E2E smoke (TR-DSK-075).

Phase 4 — Clinical vertical slices (prioritize by product)​

Suggested order (adjust with product):

  1. Registration — leverages known idempotency patterns.
  2. Patient chart — read model cache + navigation.
  3. Orders — idempotency for creates where implemented.
  4. Scheduling — calendar/agenda rich UI, OS notifications, offline degradation per SPEC.md FR-DSK-015/016 and scheduling module spec.
  5. Additional modules per BACKEND_AND_SERVICE_MAP.md as server APIs mature.

Exit criteria: Each slice has TRACEABILITY_MATRIX.md entries moved from “planned” to verified tests.

Phase 5 — Hardening and operations​

  • Auto-update signing pipeline (TR-DSK-050–051).
  • E2E smoke (Playwright) for critical paths.
  • Performance: large local DB pagination and memory budgets.

Exit criteria: Release checklist complete for pilot deployment.

Dependencies on platform maturity​

  • Server idempotency beyond registration/orders requires coordinated backend work; desktop SHOULD feature-flag writes per module until verified.
  • ehr-web unified outbox is not required for desktop to ship Phase 2–4, but shared domain packages for mutation metadata are encouraged.