What can nurse triage software actually fix in Canadian health care?

It cannot create clinicians. It can reduce misrouted demand and give back the hours lost to documentation. Those are the two honest claims.

Starting from what is not true

The health technology market has a credibility problem, and it is largely self-inflicted. Products are sold against outcomes they do not control - eliminating wait times, fixing access, transforming care - and buyers who have been through two or three of these procurements have learned to discount everything.

So it is worth starting from the negative claims, because they are the ones that make the positive claims believable.

Triage software does not create clinicians. The Canadian access problem is substantially a workforce and facilities problem, operating on training pipelines measured in years and capital projects measured in the same. Nothing deployed as software shortens those pipelines.

Triage software does not diagnose or treat. Its output is a routing decision - what level and urgency of care is appropriate, and where the person should go - and that boundary is not a marketing nicety. It is what keeps the product in one regulatory category rather than a much heavier one.

And triage software does not make the system uniform. Each province and territory determines which services it considers medically necessary and will cover, and delivery and the regulation of providers are provincial responsibilities [3]. A product cannot route around federalism.

The first real mechanism: misrouted demand

Here is where a genuine effect lives.

At the moment a person decides where to seek care, they are making a judgement with poor information under stress. Two errors are possible. They can present somewhere more intensive than the situation calls for, or they can delay when delay is the wrong choice. Both are costly, in different currencies.

The first error adds to queues that CIHI measures directly - its wait-times work spans primary care, home and community care, emergency care, inpatient and rehabilitation services, and priority procedures [1]. Every avoidable emergency department presentation lengthens the emergency-care wait for the people whose situation genuinely required that department.

The second error is the one that matters more and gets discussed less. Its cost is clinical, not administrative, and it does not appear in a wait-time statistic at all.

What a trained nurse working from validated protocols contributes is a better answer to that specific question than the person can produce alone at nine in the evening. The effect on the system is a smaller share of demand landing in the wrong setting, in both directions. That is bounded, measurable, and worth paying for - and it is a much smaller claim than "we reduce wait times".

The second real mechanism: giving back clinician hours

The other honest claim is about supply, and it is the only supply lever software actually has.

A clinician's shift is divided between patient contact and everything else - documentation, transcription, re-entering information that already exists in another system, chasing records across organizational boundaries. The non-contact fraction is substantial and it is not clinically productive.

Software that reduces that fraction produces more patient-facing hours from the staff already employed. It is a modest capacity increase and it is real, and critically it can be delivered inside a budget cycle rather than a training pipeline.

This is also where the interoperability work pays for itself. Much of the re-entry burden exists because systems cannot exchange data cleanly, so a person becomes the integration layer. Structured exchange removes the human from that loop, which is why standards work is not a back-office concern - it converts directly into clinical hours.

The third thing people expect, and why it is not on the list

The claim most often requested in this category is cost reduction, and it is deliberately absent above. The reason is that in a publicly funded system the saving does not accrue where the spending happens. A platform paid for by one organization may produce its benefit in a different organization's emergency department, or in a provincial budget line nobody in the room controls. The effect can be real and still be impossible for the purchaser to book.

That is a structural feature of the system, not a weakness in the product, and pretending otherwise produces business cases that fall apart under scrutiny. The defensible version states where the benefit lands and who captures it, and lets the buyer decide whether that alignment works for them. It is a less exciting slide and it survives the second meeting.

A related expectation worth naming is volume: the assumption that a triage service succeeds by handling more calls. It succeeds by handling them correctly, and those are not the same target. A system tuned to maximise throughput will drift toward faster answers, and in this domain the fast answer and the right answer are not reliably the same one.

Why the statute already framed this correctly

Section 3 of the Canada Health Act commits to facilitating reasonable access to health services without financial or other barriers [2]. Canada has been far more successful against the financial barrier than against the other kind.

That leftover clause is the honest description of the market a Canadian triage platform operates in. The remaining barrier is not price - it is time, availability and the difficulty of knowing where to go. Software can move some of that. It should say so in exactly those terms, and no larger ones.

What good looks like structurally

Three properties separate a platform that helps from one that merely demonstrates well.

It is provincially correct. Routing advice is only useful if the services it names exist where the caller lives [3]. This is unglamorous reference-data work and it is most of the difference between a demo and a deployment.

Its uncertainty is visible. The system must be able to say that it cannot answer, and that state has to look different from a reassuring answer. In clinical software the dangerous failure is silence where a flag belonged - the case that returns nothing and is indistinguishable, on screen, from the case that returned an all-clear.

Its accountability is modelled. Under New Brunswick's PHIA, a custodian is an organization that collects, maintains or uses personal health information for providing or assisting in the provision of care, or for planning and management of the health care system, while an agent acts for the custodian's purposes and not for the agent's own [4]. A platform should be able to demonstrate which role it occupies, and FHIR's Security and Privacy module - Security, Consent, Provenance and AuditEvent [5] - is where that demonstration lives technically rather than in a policy document.

How to evaluate any vendor, including this one

Ask which of the two mechanisms a claim rests on. If a stated benefit cannot be decomposed into reduced misrouting or reduced documentation burden, ask what else is supposed to produce it. Ask how the unanswerable case is handled. Ask which province's statute the product was designed against, and what happens at the next provincial border.

MapleTriage is being built in Moncton, New Brunswick against those two claims rather than larger ones. It is in development, working with select healthcare partners, and not generally available. In this category a premature claim is not a marketing error - so the version worth publishing is the one that survives being checked.

By Joel Gathercole · Published 2026-08-30