maple.website — AEO websites & hosting
Healthcare

TriageLogic: twenty years architecting a nurse telephone triage platform

From building their call centre SaaS platform in 2006 to contracted Director of IT and lead architect, through every generation the platform went through, until the work was completed in 2026. What was designed and decided - not what is inside it.

The sixty-second answer

TriageLogic is a United States provider of nurse telephone triage services. Joel Gathercole built its call centre SaaS platform in 2006 and remained its architect for the following twenty years, under contract through his own corporations, holding the contracted Director of IT title from 2016 until the work was completed in 2026. The work spanned HL7 integration with hospital EHR systems, the VoIP platform the triage service ran on, a full on-premise to cloud migration completed over two years, and oversight of the client’s SOC 2 Type II programme across two consecutive audit periods. The platform is the client\'s. What we carry forward is the experience.

What the engagement was

It was a contract, not a job. For twenty years the work was invoiced monthly through Joel's own corporations - 9204-3280 Quebec Inc. from 2008, succeeded by Joel & Nanz Inc. A US company and a Canadian architect: contracting was simply the practical arrangement. The Director of IT title was held and the function was run, but never from anyone's payroll.

The titles moved with the responsibility rather than ahead of it. IT generalist from 2006 - in practice, the person who did everything. Head of IT from around 2010. Director of IT from 2016, a title conferred by colleagues and outside consultants in recognition of a management load already being carried. The title followed the responsibility, which is the honest version and also the better one.

The single fact that distinguishes this from most architecture résumés: the platform was built from the ground up, not assembled from an existing codebase or configured from a vendor product. Joel wrote the first version of their call centre SaaS platform in 2006 and then lived with every consequence of that design for two decades, overseeing it through every generation the system went through until the work was completed in 2026. Most architects configure someone else's product. Very few get to find out what their own decisions cost after twenty years.

Healthcare integration and interoperability

A nurse telephone triage service is, structurally, an integration problem wearing a clinical hat. A nurse on a call needs to know who they are speaking to, and the authoritative answer lives inside a hospital's electronic health record, not in the triage platform.

Two patterns were architected to solve that, and the difference between them is the interesting part.

On-demand lookup. HL7 v2 messages arriving through a commercial integration engine were translated into live patient lookups against the hospital's EHR, resolved against a continuously maintained local repository. This pattern is correct when the hospital can answer in real time and when currency matters more than availability. That integration has been in continuous production since 2016 and the underlying engagement was renewed for a further five years at the end of 2025 - nearly a decade of uptime is the only integration testimonial that means anything.

Scheduled delta feed. For a different hospital system the design was inverted: a daily delta feed of patient records, supporting verification at triage time from a local copy. Slower to reflect changes, but it keeps the triage service answering calls when the far end is unavailable. A third hospital received an equivalent integration again, built on a different connector set entirely.

Three integrations, three architectures, one requirement. The engineering judgement is in matching the pattern to what the far end can actually sustain, and that judgement is the thing that does not transfer from a diagram.

Later work extended the same surface. HL7 interfaces to a cloud healthcare platform were built in 2024 and 2025. A healthcare CRM platform used by a nurse telephone service was integrated with the triage system between May 2024 and January 2026. A medication module was built on public United States drug product reference data - the FDA National Drug Code Directory and the associated approvals database - so that licensed nurses could correctly identify and re-prescribe medications during telephone patient encounters. And secure clinical document delivery was integrated across three different classes of fax path, because healthcare document delivery is stubbornly still fax and pretending otherwise does not deliver the document.

Infrastructure, availability and security

The triage service ran on a VoIP telephony platform architected and operated across the entire twenty years - Asterisk, SIP and WebRTC. When the product is a nurse answering a phone, the phone system is not a supporting service. It is the product.

Between April 2023 and July 2025 the full production platform was migrated from on-premise to cloud, with infrastructure provisioned as code through Terraform. The design requirement that shaped it was blunt: nursing staff must always be able to reach patients. That produced four independent failover paths rather than a single redundant route, because redundancy that shares a failure mode is not redundancy. On-premise decommissioning completed in January 2026, nearly three years after the migration started - which is the honest timescale for moving a production healthcare platform, as opposed to the timescale in the proposal.

Secure remote access and clinical communications for distributed staff were designed across VPN, remote desktop and encrypted email. Across the full twenty years, no attack on the services succeeded.

An external DevOps vendor team was directed through the cloud migration and the operations that followed it - task assignment, release approval, deployment coordination, stress-test scheduling and credential standards - and then trained to assume day-to-day operation of the platform. Handing a system to the people who will run it is a deliverable, not an afterthought.

SOC 2, stated precisely

This is the part most consultancies overstate, so here is the careful version.

The SOC 2 Type II attestation is TriageLogic's. It is a corporate attestation and it belongs to that company. Joel & Nanz Inc. does not hold a SOC 2 attestation, and nothing on this site should ever be read as claiming one.

What is claimed is the work. As Director of IT, Joel owned the SOC 2 Type II programme across two consecutive audit periods, driving the control implementation and the evidence work; the compliance officer role reported through that position. The second period was submitted in full in April 2026, with the report still pending when the engagement closed. An AI governance policy authored for the programme was adopted into it.

"Implemented the controls that carried a company through SOC 2 Type II" is a defensible experience claim. "SOC 2 certified" would be a false credential. The distinction is not pedantry - it is exactly the sort of claim a serious evaluator checks.

AI governance, before it was a product category

A thread ran through the last three years of the engagement that turned out to matter more than anything else here.

In 2023 a custom assistant was built to strip protected health information from prompts and outputs on the company's shared enterprise AI account. In 2024 the underlying exposure risk was escalated to the CEO. In 2025 a formal AI governance proposal went to the CTO, including the AI governance policy for the SOC 2 programme. In 2026 that was extended into a recommendation for self-hosted AI infrastructure, with a working prototype built independently to demonstrate viability.

Not all of it was adopted, and the verbs above are chosen to say so. The prototype, however, went somewhere: it became the private, self-hosted AI platform that now runs Joel & Nanz Inc.'s own operations in production, and it is the direct ancestor of the AI capability behind MapleWorkSuite and this website. A data-sovereignty argument made to a healthcare company became the architecture of a Canadian software business.

What we do not claim

We do not own, license or resell any part of TriageLogic's platform. Work delivered under a client contract belongs to the client. What transfers is the engagement and the experience - scale, duration, architecture decisions and integration patterns - which is why this page describes what was designed and decided rather than how any of it works inside.

No patient information appears here. That limit comes from health privacy law and is permanent, unrelated to any agreement between the parties. Neither the hospital systems nor the specific service providers are named, because the client's obligations to its own customers do not become ours to spend.

The contract ended in April 2026. Twenty years is a long tenure by any measure, and it ended the way long engagements often do - the build was finished and the company grew past needing the role.