The Qmatic Alternative built for patient flow

Qmatic’s strength is the physical service journey: tickets, kiosks, signage and counters, refined over decades across banks, government offices and hospitals. TSB starts from a different assumption — that in healthcare the journey begins at home, on a phone, days before anyone reaches a counter.

That is why TSB’s patient flow management platform treats booking, intake and queuing as one flow: modality-aware scheduling for MRI, CT and X-ray, draw and drop-off workflows for diagnostic labs, digital intake completed before arrival, and cancelled slots refilled automatically from a waitlist. On site, self check-in kiosks and the virtual patient queue replace the paper ticket with a place patients can hold from anywhere in the building — or the parking lot.

Downstream, flow analytics tie waits to clinical resources — rooms, chairs, technologists — rather than to generic counters. Across 69 active outpatient sites in British Columbia, the platform has booked more than four million appointments for 820,000 patients since 2018.

Qmatic estates are often long-lived, with years of branch configuration and hardware investment. A realistic switchover respects that and runs site by site, never as a big-bang cutover:

• Service & branch mapping. Qmatic branches, service points and queue rules are mapped into TSB’s model. Long-lived estates usually carry years of accumulated service-type sprawl; this is the natural moment to prune it.
• Hardware reuse. TSB runs in a browser, so touch kiosks, tablets and digital-signage screens can usually be repointed rather than replaced. Dedicated ticket printers are generally retired, since TSB issues a queue place from the kiosk or the patient’s phone instead of a paper ticket — keep them running during parallel operation for patients who expect a ticket.
• Integrations. Anything wired into the Qmatic platform — EHR, LIS or RIS feeds, websites, appointment confirmations — is re-pointed to TSB’s API. This and the privacy review are typically the longest poles in the timeline, especially if the outgoing system was on-premises.
• Historical data. Export Qmatic reporting before decommissioning — wait times, volumes, service-level history. TSB does not need it to operate; it becomes the “before” baseline you measure the switch against.
• Parallel running. Sites move one at a time, with old and new systems live at different locations, so no site loses queuing mid-transition. Front-desk retraining is typically hours per site.

What typically goes wrong: treating the migration as a hardware project rather than a workflow project, and starting network and security approvals too late. Both are avoidable with early scoping.