Remote Patient Care — Practitioner Desktop
Clinician-facing Windows client — same native spine as the bedside cart.
Highlights
- Shipped a second WiX MSI variant from the shared Windows codebase — kept buildable, signable, and releasable alongside the cart variant
- Redesigned window flow and screen navigation around remote practitioner sessions rather than bedside kiosk use
- Sustained the shared IPC/maintenance/Zoom-SDK backbone so divergence stayed at the App layer, not the foundation
- Maintained installer, auto-update, and branding pipelines for the practitioner distribution
Problem
The practitioner side of the same remote-care product needed a Windows client too — but for a clinician at their desk, not a kiosk on wheels. The cheap path was to fork the cart codebase and let the two distributions drift. The expensive path was to maintain two parallel codebases. Neither was acceptable; what was needed was one codebase, two MSIs, and a clean line between what’s shared and what’s per-distribution.
Approach
The native backbone — IPC, maintenance service, Zoom SDK interop, install/update pipeline — is shared verbatim between the cart and practitioner builds. Divergence sits at the App layer: window flow, screen navigation, and operator workflows are rebuilt around clinician-led sessions instead of bedside kiosk lockdown. A second WiX v4 MSI variant ships from the shared build, signed and branded for the practitioner distribution. The discipline that keeps this honest: any change to the foundation has to land in both MSIs at the same time, and any divergence has to be justified at the App layer, not smuggled into the foundation.