Case study 4 of 5 · Decided by accountability

High-complexity cases in Surgery, Oncology, and Behavioral Health were stalling in exception queues.

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.

My part: Director of Product, Care Experiences — an early product hire

Designed the shared routing architecture that assigns each case to a clinical role across four specialty programs.
Led product strategy and cross-functional delivery for the programs, managing two product managers.
The call: One routing architecture tied to clinical accountability for four specialty programs.
Turned down: Four separate products, the default.
Result: Four programs launched on shared infrastructure. Slower to build, faster to scale.

Four specialty programs on one routing architecture · Kanav Jain · kanav.net

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 assigns each 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.

Context

The stalled cases limited how fast programs could deploy across employer partners. I had to scale four clinical domains at once, each with different protocols, benefit structures, and partner integrations, without building four separate products. 1

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 never makes the clinical teams agree 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
Program	Complexity and protocol	Partner integration	What the shared routing decides
Surgery	High-complexity; its own protocols, benefit structure, and compliance requirements	—	Which clinical role owns the case, and when an exception escalates
Oncology	High-complexity; its own protocols, benefit structure, and compliance requirements	Healthwise clinical content in CancerCare v1; second opinions handed to the nurse line through the vendor ConsumerMedical	Which clinical role owns the case, and when an exception escalates
Behavioral Health	High-complexity; its own protocols, benefit structure, and compliance requirements	—	Which clinical role owns the case, and when an exception escalates
Everyday Urgent Care	Lower-complexity, 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 ConsumerMedical. 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 delays stopped being the primary bottleneck, and the gap between the best and worst service lines narrowed.

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.

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.

What I’d keep

One system can carry many programs once every decision point has a named owner.

Shared routing 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 physicians sign up for still does not settle who will pay for it.

Next step

Advisory and fractional product leadership for healthcare and AI ventures. I partner with technical founders to take complex clinical systems through review, unblock patient adoption, and build products that last.

Get in touch

Sources

1 Oncology Care launch

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

The launch announcement, on BusinessWire.

BusinessWire archived 12 January 2023 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 9 October 2026