April 2026 — Patient Flow Analysis

Where patients are getting stuck, where the funnel is leaking, and what the data actually means once CRM hygiene is accounted for.

1. The headline finding

2. The April funnel

Counts of leads that ever reached each case stage (via CaseStageHistory.toStage). Drop column = % retention vs the previous step.

3. What we actually care about — life after KYP

99 leads got KYP'd. Here is where each ended up, and the post-KYP retention.

The post-KYP funnel, stage by stage

Where each post-KYP patient ended up — by current case stage

4. The 32 patients stuck at PREAUTH_COMPLETE

Of 45 leads with approved pre-auths, 32 never had a CRM stage advance to INITIATED/ADMITTED. Breakdown of what's actually going on:

The 5 LOST after approval — recoverable revenue?

The 5 still-SALES with approved pre-auth — needs follow-up

The 22 already-COMPLETED with stuck stage — CRM hygiene

5. BD performance

Per-BD breakdown of April leads: how many were assigned, how many were touched in the CRM at all, how many got KYP'd, and how many got admitted.

High-volume BDs — these are where the real bottleneck lives

Top performers by engagement %

Zero-touch BDs (likely inactive accounts — verify before action)

6. The two priorities

Appendix A — Drill-down queries

Why did the 5 LOST-after-approval patients walk away?

SELECT "leadRef", "patientName", "treatment", "lostReason", "lostAt"
FROM "Lead"
WHERE id IN (
  SELECT id FROM "Lead"
  WHERE "leadEntryDate" >= '2026-04-01' AND "leadEntryDate" < '2026-05-01'
    AND "pipelineStage" = 'LOST'
    AND "caseStage" = 'PREAUTH_COMPLETE'
);

The 47 patients stuck at hospitals-suggested with no pre-auth (Priority 3)

WITH ever AS (SELECT DISTINCT "leadId", "toStage" FROM "CaseStageHistory")
SELECT l."leadRef", l."patientName", l."treatment", l."hospitalName",
       u.name AS bd, l."followUpDate",
       EXTRACT(DAY FROM NOW() - h."changedAt")::int AS days_at_hosp_suggested
FROM "Lead" l
JOIN "User" u ON u.id = l."bdId"
JOIN "CaseStageHistory" h ON h."leadId" = l.id AND h."toStage" = 'HOSPITALS_SUGGESTED'
WHERE l."leadEntryDate" >= '2026-04-01' AND l."leadEntryDate" < '2026-05-01'
  AND l."pipelineStage" NOT IN ('COMPLETED', 'LOST')
  AND l."caseStage" = 'HOSPITALS_SUGGESTED'
  AND NOT EXISTS (SELECT 1 FROM ever WHERE "leadId" = l.id AND "toStage" = 'PREAUTH_RAISED')
ORDER BY days_at_hosp_suggested DESC;

BD activity status — confirm which zero-touch BDs are actually inactive

SELECT u.name, u.email, u.role, u."isActive", u."employeeStatus",
       COUNT(l.id) AS april_leads
FROM "User" u
LEFT JOIN "Lead" l ON l."bdId" = u.id
  AND l."leadEntryDate" >= '2026-04-01' AND l."leadEntryDate" < '2026-05-01'
WHERE u.id IN (
  SELECT DISTINCT "bdId" FROM "Lead"
  WHERE "leadEntryDate" >= '2026-04-01' AND "leadEntryDate" < '2026-05-01'
)
GROUP BY u.id, u.name, u.email, u.role, u."isActive", u."employeeStatus"
ORDER BY april_leads DESC;

Adjust column names to match the actual User model — isActive/employeeStatus are best guesses.

Daily LOST-marking pattern — bulk dumping or genuine triage?

SELECT DATE_TRUNC('day', "lostAt")::date AS lost_day,
       COUNT(*) AS marked_lost,
       COUNT(DISTINCT "bdId") AS distinct_bds
FROM "Lead"
WHERE "leadEntryDate" >= '2026-04-01' AND "leadEntryDate" < '2026-05-01'
  AND "pipelineStage" = 'LOST' AND "lostAt" IS NOT NULL
GROUP BY 1 ORDER BY 1;

Backfill query — fix the 22 stuck-stage COMPLETED patients

-- Sanity check first; do NOT run blindly
SELECT id, "leadRef", "patientName", "pipelineStage", "caseStage"
FROM "Lead"
WHERE "leadEntryDate" >= '2026-04-01' AND "leadEntryDate" < '2026-05-01'
  AND "pipelineStage" = 'COMPLETED'
  AND "caseStage" IN ('PREAUTH_COMPLETE', 'HOSPITALS_SUGGESTED', 'PREAUTH_RAISED');

-- Then, after review, advance to DISCHARGED:
-- UPDATE "Lead" SET "caseStage" = 'DISCHARGED'
-- WHERE id IN (...);
-- And insert backfilled CaseStageHistory rows for audit trail.

Appendix B — Method notes

• Cohort definition: Lead.leadEntryDate in [2026-04-01, 2026-05-01). This is the canonical "when the lead was received" field per the Prisma schema.
• Funnel counts use CaseStageHistory.toStage with DISTINCT leadId — i.e. how many leads ever passed through that stage, not how many are currently in it.
• "Touched" = lead has at least one row in CaseStageHistory. Untouched leads are the ones whose case stage was never advanced from NEW_LEAD.
• Days in stage = NOW() − most recent CaseStageHistory.changedAt, falling back to Lead.createdDate when no history exists.
• "Real" admission estimate combines CRM-recorded admissions (13) with COMPLETED-but-stage-stuck cases (22). Some of the 13 may be inside the 22, so the upper bound of unique completions is ~35 and the lower bound is 22. Treat as a range, not a point estimate.