Get in touch

Case study 4 of 5 · Decided by accountability

Four specialty programs on one routing architecture

I put four specialty-care programs (Surgery, Everyday Urgent Care, Behavioral Health, and Oncology Care) on one shared system instead of four custom ones, so nurses and navigators worked from the same facts and every case had a named owner.

Transcarent care navigation app — public app store visual

Context

High-acuity specialty cases (Surgery, Oncology, Behavioral Health) were stalling in exception queues, limiting how fast programs could deploy across employer partners. The challenge was scaling four clinical domains at once — each with different protocols, benefit structures, and partner integrations — without building four separate products. 1 BusinessWire

The decision

I built one shared system instead of a product per program: routing rules that assigned every case to a clinical role, so all four programs ran on one architecture. I stated the trade up front: slower to build, faster to scale.

A product per program Not chosen

Four builds, one per specialty, each carrying its own protocols, benefit structures, and partner integrations. Ships the first program soonest, but no one has to agree across clinical teams on who owns a case.

One shared decision infrastructure Chosen

A unified member record and role-based routing under all four programs. Slower to stand up, and forces four clinical teams to agree on who is responsible for a case at each step.

Stated at the time as a trade: slower to build, faster to scale. Four programs launched on one shared architecture, and routing delays stopped being the primary bottleneck.

Four programs, one routing architecture
ProgramAcuity and protocolPartner integrationWhat the shared routing decides
Surgery High-acuity; its own protocols, benefit structure, and compliance requirements — Which clinical role owns the case, and when an exception escalates
Oncology High-acuity; its own protocols, benefit structure, and compliance requirements Healthwise clinical content in CancerCare v1; second opinions handed to the nurse line through the vendor Consumer Medical Which clinical role owns the case, and when an exception escalates
Behavioral Health High-acuity; its own protocols, benefit structure, and compliance requirements — Which clinical role owns the case, and when an exception escalates
Everyday Urgent Care Everyday acuity, unlike the three above; its own protocols, benefit structure, and compliance requirements — Which clinical role owns the case, and when an exception escalates
The routing column is identical in every row: one rule set, tied to clinical accountability, served all four programs.

What happened

I designed shared member records and tied routing rules to clinical roles, with exception handling and escalation behind them. I also led the Cancer & Decision Support pod, which shipped CancerCare v1: a symptom-checking triage tool with Healthwise content and an in-app second-opinion flow that handed off automatically to the nurse line through Consumer Medical. It inferred a care pathway from reported symptoms for adults and children, and every path ended with a named clinical role, not with the tool; dashboards showed exceptions as they happened.

Four specialty-care programs launched on shared infrastructure. Routing-related delays dropped as a primary bottleneck, and the gap between the best and worst service lines narrowed.

× the owning role High-acuity case Surgery, Oncology, Behavioral Health Exception queue where the case stalls
Specialty cases at Transcarent before routing was tied to clinical accountability. Cases stalled because no rule said whose case each one now was, not because there were too many of them. The same path after the change is below.
High-acuity case Surgery, Oncology, Behavioral Health Routing rule tied to a clinical role Named clinical role accountable for this case
After: the same case, with a named owner at every decision point. The rule makes no clinical decision; it assigns the case to a clinical role. One architecture then carried all four programs.
Surgery high-acuity own protocols Oncology high-acuity own protocols Behavioral Health high-acuity own protocols Urgent care everyday own protocols four programs, one architecture Shared routing role-based routing rules tied to clinical accountability every case assigned to a named clinical role Unified member record nurse and navigator working from the same facts Behind it exception handling · escalation protocols · real-time exception dashboards
The shared decision architecture, drawn from the case study rather than from a surviving document: four programs with four sets of protocols enter one routing layer, and the layer’s job is to assign the case to a clinical role. The alternative on the table was four products, one per lane. The record beneath is what let a nurse and a navigator see the same case.

What I’d keep

One system can carry many programs once every decision point has a named owner. Assigning that owner is the architecture.

It is the Epic escalation path at a larger scale: there, one route for regulatory changes; here, a route for every case in four programs. I carried the pattern into Andwise as a founder, and learned there that a product good enough to be adopted still does not settle who will pay for it.

Sources

1 Oncology Care launch

Transcarent launched Oncology Care during this specialty-care product period.

The launch announcement, on BusinessWire.

BusinessWire archived refuses automated checks

The four-program launch on shared infrastructure, the drop in routing delays, and the narrowing between the best- and worst-performing service lines all come from my records; Transcarent has published none of them. The source above covers the public Oncology Care launch only.

Revised