Here is an uncomfortable fact about our own market: for almost every operational problem a healthcare organization has, an app already exists. Online booking, reminders, digital intake, eReferrals, AI scribes, fax management, recall tracking — mature products, many of them good, some of them publicly funded. If apps fixed operations, Canadian healthcare would be fixed.
Instead, organizations own more software than ever and run no better. Most groups we meet are paying for tools they never fully adopted — bought in a burst of optimism, configured halfway, used by the two people who championed them, and quietly routed around by everyone else. The problem the app was bought for is still there. It just costs a subscription now.
Apps solve tasks. Organizations fail at operating models.
An app automates a task: send the reminder, route the fax, draft the note. But the failures that actually cost an organization — capacity that leaks across sites, a staffing model built by accretion, three clinics running three versions of the same process, an AI decision stalled for a year — are not tasks. They are properties of the operating model: who owns what, how work flows between people, what gets measured, what happens when it breaks.
No app can decide which of your twelve problems is the constraint. No app can resolve which site’s habits become the group standard, redesign a role, carry a privacy review, or make adoption someone’s actual job. Software configures the task layer. Someone still has to design the layer above it — and in most healthcare organizations, nobody ever formally has.
When you genuinely don’t need a consultant
Candor cuts both ways, so: if your problem is one task, in one workflow, owned by one person — buy the app. A single clinic drowning in appointment reminders needs a reminder tool and an afternoon, not an engagement. Part of our first conversation is telling you which app that is, by name, and stepping aside. A consultancy that can’t say “you don’t need us” can’t be trusted saying “you do.”
When you do
You need consulting when the problem lives betweenthings: between sites that run differently, between a tool and the team that won’t adopt it, between a funded program and forty member clinics, between an AI mandate and a governance framework that doesn’t exist yet. Between-things problems are diagnosis problems, design problems, and change problems. They have no vendor, because there is no product to sell for them — which is exactly why they persist while the app shelf grows.
The tell is repetition. If you have bought a tool for the same problem twice, the problem was never the tool. If the improvement worked at one site and died at the second, the problem is not the sites. If the pilot impressed everyone and stalled anyway, the technology was never what you were missing.
What the work actually looks like
It looks like an Operating Review before any recommendation: where the organization loses time, capacity, and money, quantified in its own numbers. Then a design your teams helped shape, so it survives contact with them. Then delivery — including, yes, apps and automation, chosen vendor-neutrally, adopted deliberately, measured at 90 days. Then transfer, so the capability stays and the consultant leaves.
The apps are usually in the answer. They are almost never the answer. That difference is the whole discipline — and it is why the problem you bought software for three years ago is still on your leadership agenda this quarter.
— Himanshu, for TOSC · July 2026