Who to call after a hospital discharge

How the list is built

• Death and hospice discharges are dropped: those patients can't come back, and keeping them lifts AUROC to 0.679 for the wrong reason.
• Race and gender aren't features; they're kept for the subgroup checks. As features they don't help (24.7% on the list).
• LACE is approximate here: the extract has three diagnosis codes and counts emergency visits over a year, not six months.

Why each patient is on the list

Every call comes with the three things that raised its score most, from exact TreeSHAP, in words a care coordinator would use; CI checks the code descriptions against the table that ships with the UCI download. Prior inpatient stays lead for 61% of the list and the discharge disposition for 37%. A reason explains the score, not the patient.

Score a patient

The model's trees run in your browser and match LightGBM's own scores; the tests check 300 held-out rows. Anything not on the form is held at its median or most common value.

How far to trust it

Against the prior-stays rule the list reaches 4.4 points more of the readmissions (95% interval +2.7 to +6.0), 101 more patients who came back. XGBoost ties LightGBM (24.8% against 25.0%); LightGBM ships because it led on validation; the held-out split played no part in choosing it.

The probabilities said the list would hold 539 readmissions, and it held 569. Every tenth of predicted risk is within 1.6 points of what happened.

The list has a blind spot: 41% of readmissions were patients with no visit in the year before, and they're 833 of its 1,710 misses. 78% of the list had a prior inpatient stay, against 33% of all discharges. The model finds people with a history; it misses people the record says little about.

What I'd do next: evaluate the 943 readmissions among patients with no visit in the prior year as a group of their own, and check how well the features the model still has for them (diagnoses, length of stay, labs, medications, discharge disposition, age) separate those who come back from those who don't. If they separate them poorly, I'd look for data the extract doesn't have, such as admission dates or notes, before assuming a more complex model would help. I haven't run this subgroup study.

What I checked

Simulated shifts

The extract has no admission dates, so I shift the held-out set on purpose and check what the monitoring catches. The first two shifts resample real encounters with their real outcomes.

Calibration slips most for the older population (523 expected on the list, 585 observed). Blanking diagnoses fires no PSI alert, the largest being 0.028 against a threshold of 0.2; only the missing-value check catches it, so monitoring needs both.

Who the list reaches

The list reaches 31.1% of readmissions under 50, 26.7% at 50 to 69 and 21.5% at 70 and over. The 417 encounters with no race recorded get 2 of their 31 readmissions on the list: too few to conclude much from, and the group I'd watch.

Choices I tested

I retrained LightGBM with one decision changed at a time. The two scored on the same held-out split, class weights and race and gender as features, both land below the model as built.

As a service

POST /score returns calibrated risk, whether the encounter makes the call list at the configured capacity, and its three reasons. On one core it answers 71.7 single-encounter requests a second (p95 18.7 ms) and scores about 515 encounters a second in batches of 100, most of that time on exact TreeSHAP. No request failed.

Run it yourself

make install    # the package and dev tools
make run        # download (checked against its SHA-256), train, evaluate
make test       # lint, tests, and the browser scorer against a fresh export
make loadtest   # the service on one core, the load generator on the other
make export     # trees, calibration, capacity curves and the call list for this page

On every push, CI downloads the extract, retrains with the locked libraries, and fails if AUROC, AUPRC or Brier move by more than 0.002, or recall at 10% by more than 0.005, from the committed results.

Numbers on this page are from the code at commit d7a05c6, run on 2026-10-21 with LightGBM 4.7.0 and XGBoost 3.4.1. Every table readmit run writes is in RESULTS.md.