Skip to main content

Solutions · Healthcare

Data Science Regression

Predict how many days a patient stayed

Model the expected length of stay for every hospital encounter — demographics, admission type and source, discharge disposition, diagnosis and procedure counts, labs, diabetes medications, and prior-year visit history — then compare actual stays against it to find where care ran long, short, or off-pattern.

Data Science Langsat Team 8 min read
447,362
Bed-days across the encounters in this dataset
52.8%
Of bed-days come from emergency admissions
Longer stays at 9 diagnoses vs 1–2

The problem

For each encounter in the encounters table, predict `time_in_hospital` — the number of days the patient stayed — from the encounter's clinical and administrative record: patient demographics, admission type and source, discharge disposition, counts of lab procedures, procedures, medications and diagnoses, the primary and secondary diagnosis codes, glucose and A1C results, the diabetes medication columns, and the patient's prior-year outpatient, emergency and inpatient visit counts. The output is an expected length of stay per encounter, so actual stays can be measured against it.

See the model in action

This is the trained regression model. Every encounter gets an expected length of stay in days — the benchmark that actual stays are then measured against.

Live model — expected length of stay (days)

Trained on Langsat

Open in Langsat ↗

Ask a question in plain English

You ask

“Estimate bed needs based on average length of stay by patient characteristics”

Age bandEncountersShare of bed-days
[70-80)26,06826.8%
[60-70)22,48322.0%
[80-90)17,19718.5%

Those three bands account for roughly two-thirds of all bed-days. Cut the same total by admission type instead and emergency admissions alone drive 52.8% of bed-days across 53,990 encounters.

Explore the bed-capacity dashboard

The same result, as an auto-generated dashboard you can share with a link — no login required for viewers.

Shared dashboard — bed capacity planning

Auto-generated · read-only share link

Open in Langsat ↗

What this model is for

Length of stay looks like a clinical number. It behaves like an operational one — it’s the multiplier that turns admissions into bed-days, and bed-days are what a hospital actually runs out of.

This model gives every completed encounter an expected length of stay from its full record. The point isn’t to guess the future; it’s to have something to measure the past against. This stay took six days — given this patient’s age, admission route, diagnosis count and medication load, what would we have expected?

That question has three payoffs.

1. Where your bed-days actually go

Before any prediction, the encounter data alone tells you where capacity is committed. Across this dataset that’s 447,362 bed-days, arriving as 278.8 admissions on an average day, with stays reaching 11 days at the 95th percentile.

That demand is concentrated, not spread:

  • Age. The 70–80 band alone is 26,068 encounters and 26.8% of all bed-days. Add 60–70 (22.0%) and 80–90 (18.5%) and roughly two-thirds of your capacity sits in three bands.
  • Admission route. Emergency is 53,990 encounters and 52.8% of bed-days; urgent adds 19.0%, elective 18.2%. Only that last slice is schedulable — most of your bed-day load arrives unannounced.
  • Complexity. Encounters with 9 diagnoses average 5.0 days; those with 1–2 average 2.3–2.6. Same bed, twice the occupancy.
  • Sex. Female encounters account for 54.8% of bed-days, male 45.2%.

Beds are not the constraint. Bed-days are — and length of stay is the only lever that moves them without building.

2. Actual versus expected

This is what the model is for. With an expected value on every encounter, the stays worth attention are the ones that diverge from it — not simply the longest ones, which you already know about.

A stay of nine days is unremarkable for a complex nephrology patient and extraordinary for a routine elective admission. Ranking by raw duration surfaces the first group; ranking by variance against expectation surfaces the second — the encounters where something happened that the record doesn’t explain.

3. What the variance review actually revealed

Run that comparison on this model and the first finding is about the model itself.

Across the 20 encounters with the highest expected stays, the estimates ran from 2.45 to 2.54 days — a spread of about two hours — while their actual stays ranged from 1 to 9 days. The largest gaps in both directions:

EncounterSpecialtyExpectedActual
69758880Nephrology, 50–60 M2.479.0
9355023050–60 F · 9 diagnoses2.478.0
158449128Family/GP, 50–60 M · 23 medications2.467.0
76150356Nephrology, 70–80 M2.511.0
151694280Emergency/Trauma, 50–60 F2.461.0

Read honestly, that’s a model whose estimates are near-constant at the top end. When expected values barely move, sorting by variance is close to sorting by actual duration — so this version is a coarse benchmark, not a reliable way to single out an unexplained long stay. The concentration of nephrology cases and 17–23-medication regimens in the large-gap group is the clue for what to add: specialty and polypharmacy signals the current feature set isn’t capturing.

Two data-quality findings fell out of the same review for free: 8 of the top 20 encounters had no specialty recorded, and one encounter coded to paediatrics carries a 10–20 age band worth re-checking at source. Neither is a modelling problem, and neither would have surfaced without something to compare against.

Why it’s worth solving

A hospital can’t buy more beds this quarter. It can only change how long each one stays occupied — which makes length of stay one of the few levers that moves capacity, cost and patient experience together.

The scale is the argument. A bed-day is among the most expensive units in healthcare, and at 447,362 of them in this dataset alone, even a fractional change in average stay frees hundreds of bed-days — capacity you’d otherwise have to build, staff, or turn away.

But the deeper value is having a defensible expectation at all. Without one, “this stay was too long” is an opinion, and every review meeting relitigates it. With one, the conversation starts from a number derived from comparable encounters, and attention goes to the cases that genuinely deviate rather than the ones that merely look big.

Ranked by duration, you find your sickest patients. Ranked by variance, you find your surprises.

That’s also why the honest read of section 3 matters. A benchmark you haven’t validated is worse than none, because it lends false authority to whatever it happens to output. Being able to see — quickly, on your own data — that this version compresses toward the middle is the useful outcome: it tells you exactly what to fix before anyone plans a ward around it.

How Langsat builds this

This is a Data Science project with a regression target: time_in_hospital, in days.

  1. Point Langsat at your encounters table — plus the tables around it: patients, diagnoses, medications, prior visits. You don’t pre-join them.
  2. Train on the relationships, not a flattened table. Prior-year admissions, diagnosis mix and medication changes all inform the expected value, so the signal manual flattening discards is kept.
  3. Read the regression metrics before you trust it. Langsat reports error in the model’s own units — days — and you can compare expected against actual across the whole set, which is precisely how the compression above becomes visible rather than invisible.
  4. Iterate on the features the variance points to. Here that means specialty and polypharmacy; retraining without post-discharge fields such as discharge disposition would additionally turn this into an admission-time predictor.
  5. Serve it and ask in plain English. Every encounter gets a live expected value through the prediction API, and questions like “estimate bed needs by patient characteristics” return a dashboard you can share with the bed-management team by link.

The whole thing runs on Langsat’s secure cloud — your data isolated to your account, encrypted in transit and at rest, and never used to train models for anyone else.

Try it yourself

Every trained model gets a REST endpoint. Change the inputs below and run it against the live model.

Try the model

Change the inputs and run a real prediction.

live model

Patient encounter

28 further features (diagnosis codes, lab counts, and the full diabetes-medication panel) are sent unchanged.

Result

recorded

expected stay

1.54 days

prediction
1.5352409261973652
task_type
regression
mode
inductive
version_label
v1

A real response from this model, recorded on 2026-08-04. The model ID is redacted — the demo proxy resolves it server-side. `probability` is null because this is a regression task, not a classification.

FAQ

Frequently asked questions

Is length-of-stay prediction regression or classification?

Regression — the model outputs a continuous number of days rather than a category. That matters for planning, because days sum into bed-days, which is the unit capacity is actually measured in.

Can this predict length of stay at admission, before the stay happens?

Not as trained here. This model uses the full encounter record, including discharge disposition — a field that isn't known until the patient leaves. That makes it an expected-length-of-stay benchmark for looking back at completed encounters, not a day-one forecast. If you want an admission-time predictor, train the same task on admission-time features only (demographics, admission type and source, prior-year visit counts) and leave the post-discharge fields out.

How accurate is it?

On this dataset, not accurate enough to call an individual long stay. Across the 20 encounters with the highest expected stays, the model's estimates spanned just 2.45 to 2.54 days while the actual stays ranged from 1 to 9 — it compresses toward the middle instead of separating the extremes. Treat the output as a coarse benchmark, review the variance before relying on it, and see the retraining notes below.

What data does it need?

One encounters table with the clinical and administrative fields above. Related tables — patients, diagnoses, medications, prior visits — can be linked in as-is; you don't pre-join them.

Where does the patient data live?

On Langsat's secure cloud — hosted in Singapore by default, with US or EU hosting available on request. Your data is isolated to your account, encrypted in transit and at rest, never used to train models for anyone else, and you can delete it at any time. Handling protected health information is your call to make under your own compliance program; talk to us about your requirements before uploading PHI.

Build this on your own data

Point Langsat at your data, pick the task, and train a real model — no feature engineering, no infrastructure to run. Your data stays private: isolated to your account and encrypted in transit and at rest.