Text only version
Back to Double
Worked example · Specialty pharmacy

Helix Specialty PharmacyWinning the prior-authorization fight.

A fictional small specialty pharmacy dispensing high-cost therapies. Its biggest constraint on growth isn't clinical. It's prior authorization. The same engine that worked for a food wholesaler works here, in a regulated setting, starting with the most painful piece: intake.

Stage 0
PA intake
Stage 1
Eligibility & benefits
Stage 2
Clinical criteria
Stage 3
Payer submission
Stage 4
Status & appeals
Stage 5
Unified PA engine
The constraint

Why prior authorization is the place to start.

Specialty drugs almost always require prior authorization, the payer's sign-off before a therapy can be dispensed. For Helix, that one process gates revenue, delays patients, and consumes the staff. Every new referral lands as a pile of unstructured documents, and the clock starts ticking. The faster a PA moves, the faster the patient starts therapy and the faster Helix gets paid. It is, unambiguously, the constraint on growth.

Stage 0 · Start at the front door

Automate prior-authorization intake.

We don't automate all of prior authorization on day one. We start at the narrowest, most painful point: intake. Referrals arrive by fax, portal, phone, and PDF (prescriber notes, lab results, diagnosis codes, insurance cards) in no consistent format. Staff spend hours reading, sorting, and keying before any clinical work begins.

An AI-native intake surface ingests every referral whatever the format, extracts the patient, prescriber, drug, diagnosis, and insurance details, checks for what's missing, and assembles a clean, structured PA case. The clerks stop transcribing and handle only the exceptions the system flags.

The simple view · Intake
Referral arrives (fax, portal, phone, PDF)
AI extracts patient, drug, dx, insurance
Missing-info check, flag exceptions
Clean, structured PA case created
The same referrals, the same staff, minus the manual reading and keying.

That first surface is funded the same way as everywhere: by redirecting the budget for the next intake hire Helix was about to make. Small, rolling investment. The freed staff guide what comes next.

Stages 1–4 · Follow the bottleneck

Then automate prior authorization in general.

Clean intake exposes the next constraint: everything downstream. So the team builds outward, one control surface at a time: eligibility and benefits checks, matching the clinical packet against each payer's criteria, generating and submitting the authorization, tracking status and appeals. Each piece lifts the next bottleneck the moment intake stops being the binding one.

The loop, applied
1
Constraint: intake buries the team
Unstructured referrals delay every PA before clinical work starts.
2
Build: AI intake, then the PA pipeline
Eligibility, criteria match, submission, status, surface by surface.
3
Result: faster approvals, more starts
Shorter turnaround means more patients on therapy and faster revenue.
4
Next constraint: clinical review capacity
Volume rises until the next role becomes the bottleneck. Go again.
In a regulated workflow the loop is the same: lift a constraint, watch it move, build the next surface.
Stage 5 · The payoff

A prior-authorization engine, not five tools.

Built one at a time, the surfaces share a data layer. Once intake, eligibility, criteria, submission, and status all write to the same place, the combined system develops abilities no single step was built for. In a regulated setting, those are exactly the abilities that protect both revenue and patients.

Complex view · The unified PA engine
Referral & PA IntakeEligibility & BenefitsClinical Criteria MatchPayer SubmissionStatus & AppealsPA Data LayerApproval-likelihood scoringPayer-specific routingDenial-pattern learning
Solid arrows are the PA workflow in order; dashed amber links are emergent abilities the combined data layer unlocks.

The accumulated case history lets the engine score approval likelihood before submission, so weak packets get strengthened first. Knowing each payer's behavior enables payer-specific routing, submitting the way each plan actually approves. And every denial feeds denial-pattern learning that pre-empts the next one. None of these were the goal of any single build. They emerged from the combination.

Why the layers compound
Emergent ability
A self-improving PA engine: higher first-pass approval rates and faster time-to-therapy, learning from every case.
Layer 4
PA intake
Every referral turned into a clean, structured case.
Layer 3
Eligibility & benefits
Coverage and requirements resolved up front.
Layer 2
Clinical criteria match
Packets aligned to each payer’s exact rules.
Layer 1
Submission, status & appeals
Authorizations filed and tracked to resolution.
Each surface stands alone. Stacked, they become a system that improves its own approval rate.
The result

More patients on therapy, faster.

Turnaround on a prior authorization drops from days to hours. First-pass approval rates climb because packets go out stronger. The same clinical staff handle far more volume, reviewing exceptions instead of assembling paperwork. Helix takes on more prescribers and more therapies without the PA backlog that used to cap its growth. And, as everywhere, each stage paid for the next.