Add documentation for Bed Availability Prediction query

[sonzsara]

No description provided.

[Copilot]

Pull request overview

Adds a new markdown documentation page for an internal “Bed Availability Prediction” query, describing purpose, parameters, and the SQL used to forecast ward-level bed occupancy over the next 7 days.

Changes:

• Added Internal/Prediction/bed_availability_prediction.md documenting the forecast query, including purpose, parameters, notes, and SQL.
• Introduced Metabase parameters (admission_multiplier, turnover_multiplier, bottleneck_threshold) and explanatory notes for tuning.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

Internal/Prediction/bed_availability_prediction.md:18

• The note is inaccurate: bottleneck_threshold alone controls when a ward/day is flagged. Setting admission_multiplier and turnover_multiplier to 1 does not make the threshold behave like 100%.

> **Note:** `bottleneck_threshold` is a **fraction**, so enter `0.90`, not `90`. If all three variables are set to `1`, the threshold is effectively `100%`, meaning nothing will flag until a ward is completely full — set it to `0.9` (or your desired fraction) instead.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

Internal/Prediction/bed_availability_prediction.md:18

• The note about bottleneck_threshold is inaccurate: the threshold is controlled only by bottleneck_threshold (not by the admission/turnover multipliers). Setting multipliers to 1 does not make the threshold effectively 100%; only setting bottleneck_threshold to 1 would do that.

> **Note:** `bottleneck_threshold` is a **fraction**, so enter `0.90`, not `90`. If all three variables are set to `1`, the threshold is effectively `100%`, meaning nothing will flag until a ward is completely full — set it to `0.9` (or your desired fraction) instead.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

Internal/Prediction/bed_availability_prediction.md:18

• The note incorrectly implies that setting admission_multiplier/turnover_multiplier to 1 changes the bottleneck threshold. The threshold depends only on bottleneck_threshold; multipliers only affect the forecasted occupancy numerator.

> **Note:** `bottleneck_threshold` is a **fraction**, so enter `0.90`, not `90`. If all three variables are set to `1`, the threshold is effectively `100%`, meaning nothing will flag until a ward is completely full — set it to `0.9` (or your desired fraction) instead.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

Internal/Prediction/bed_availability_prediction.md:18

• The note incorrectly implies the bottleneck behavior depends on all three variables being set to 1. The flagging threshold depends only on bottleneck_threshold; setting multipliers to 1 does not make the threshold "effectively 100%".

> **Note:** `bottleneck_threshold` is a **fraction**, so enter `0.90`, not `90`. If all three variables are set to `1`, the threshold is effectively `100%`, meaning nothing will flag until a ward is completely full — set it to `0.9` (or your desired fraction) instead.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (3)

Internal/Prediction/bed_availability_prediction.md:18

• This note incorrectly implies that setting admission/turnover multipliers to 1 changes the effective bottleneck threshold. The threshold is controlled only by bottleneck_threshold; multipliers affect the predicted occupancy, not what fraction is considered a bottleneck.

> **Note:** `bottleneck_threshold` is a **fraction**, so enter `0.90`, not `90`. If all three variables are set to `1`, the threshold is effectively `100%`, meaning nothing will flag until a ward is completely full — set it to `0.9` (or your desired fraction) instead.

Internal/Prediction/bed_availability_prediction.md:174

• The Notes section claims the output includes a multi-day trend and is ordered by “forecast day”, but this query returns a single prediction_for timestamp (NOW() + 24 hours) per floor/ward and orders only by floor and ward. The note should match the actual result shape/order.

- **Tunable variables:** See the Parameters table above.
  - `admission_multiplier` and `turnover_multiplier` scale the historical daily averages to reflect expected surges/slowdowns.
  - `bottleneck_threshold` is compared against the *fraction* `(occupied_beds + cum_net_flow) / total_beds`, so it must be entered as a decimal fraction (e.g. `0.90` for 90%), not a whole number.
- Results are ordered by floor, then ward, then forecast day — giving a 7-day trend per ward.

Internal/Prediction/bed_availability_prediction.md:8

• The purpose text implies the query flags wards that will cross the threshold at any point over the next 24 hours, but the SQL only computes a single end-of-window forecast (NOW() + 24h) and flags based on that final predicted_occupied. This is misleading for consumers who expect intra-day bottleneck detection.

This issue also appears on line 171 of the same file.

Forecasts bed occupancy for each floor/ward over the next 24 hours by combining current occupancy with historical (365-day) day-of-week admission and discharge patterns. Applies tunable multipliers to account for known surges or slowdowns, and flags any ward/day projected to cross an occupancy threshold as a `BOTTLENECK RISK`.