Switching
Replace the system, not your safety net.
The biggest risk in changing clinical systems isn't the new software — it's the seam. Here is how the seam is managed, in the order it actually happens.
The de-risking sequence
Four phases. Each one reversible.
- 1
Parallel-run — nothing stops
Your current system keeps running while zMed comes up alongside it. The first beds go live on zMed while the rest of the unit charts exactly as before — there is no cliff-edge cutover, and no day where the unit has no system of record.
Typical first live bed: weeks from kickoff.
- 2
Data migration — your record survives
Historical demographics, encounters and reportable records migrate over standard interfaces; live device feeds re-point bed by bed. We agree the migration scope with your team up front — what moves, what is archived read-only, and what stays queryable in the old system until contract end.
Migration scope signed off before the first bed flips.
- 3
Training — by shift, on your unit
Nurses learn on the unit they staff, on real workflows, during their shift pattern — not in a classroom a month before go-live. Charting by exception means most of the old transcription work disappears rather than moving; the training burden is genuinely smaller than the system it replaces.
Super-users certified per shift before their unit cuts over.
- 4
Cutover week — bed by bed, reversible
Units flip in planned groups with command-centre support on site. Every step has a rollback: if a unit needs to revert, the parallel-run system is still there. The audit log records the transition; nothing is lost in the seam.
Rollback path stays available until you retire it.
What this looked like in practice
The sequence flexes to the hospital's appetite: a 28-bed tertiary ICU chose a big-bang go-live — all beds switching together, weeks from kickoff, with training done ahead of the cutover — while a multi-site acute-care network standardised four care settings onto one record without a single unit losing its chart.
Read the case studiesBring us your switching question.
Migration scope, parallel-run length, training load — ask with your unit's specifics on the table.