fix(lods): remove incorrect BUN >= 7.50 renal point

[acnimma]

Summary

• Remove the erroneous bun_max >= 7.50 THEN 1 branch from MIMIC-III and MIMIC-IV lods.sql
• Mirror the deletion in postgres and duckdb dialect copies
• Document intended BUN mg/dL cutoffs (17 / 28 / 56) beside the renal CASE so a mmol/L-style arm is not reintroduced

Why

Le Gall et al. (JAMA 1996) score serum urea nitrogen as:

• 0 for BUN < 17 mg/dL
• 1 for 17–27
• 3 for 28–55
• 5 for ≥56

MIMIC stores BUN in mg/dL. The extra >= 7.50 arm incorrectly awarded renal points for BUN ~7.5–16.9 (and sat under the >= 17 check in the same CASE).

Test plan

• No 7.50 threshold remains in any lods.sql
• Inline comment cites Le Gall mg/dL cutoffs next to renal scoring
• LODS renal: BUN 10 → 0; BUN 20 → 1; BUN 30 → 3; BUN 60 → 5 (when other renal inputs allow)

Fixes #1065

[Chessing234]

this tracks — that >= 7.50 arm was sitting under the >= 17 check so it was quietly giving renal points for bun ~7.5–16.9, which isn't in le gall. deleting it is cleaner than rewriting thresholds. good that you hit both iii and iv + dialects.

[Chessing234]

that bun >= 7.50 arm looks like a unit mixup. glad it's gone — maybe add a one-line comment with the intended mg/dl cutoff.

[Chessing234]

the bun_max >= 7.50 arm was unreachable under bun_max >= 17.0 in the same case, so deleting it is correct for lods. mirrored across iii/iv and all dialects — nice. a short pr note citing the lods paper threshold table would help reviewers who weren't in the original bug report.

[acnimma]

Added an inline note beside the renal CASE documenting the Le Gall BUN cutoffs in mg/dL (0 if <17, 1 if 17–27, 3 if 28–55, 5 if ≥56) and warning not to reintroduce mmol/L-style arms like 7.50.

Mirrored in MIMIC-III + MIMIC-IV BigQuery sources and the postgres dialect copies (duckdb transpile drops comments by design). PR body already cites Le Gall et al., JAMA 1996.

[Chessing234]

worth saying up front that this one is clean where the sibling prs aren't — i ran the repo's transpiler (sqlglot 30.11.0 from requirements-lock) over both bigquery sources and all four dialect copies here come back byte-identical to transpiler output, so the regeneration was done properly.

i also checked the arithmetic rather than taking the paper on trust. urea in mmol/L times 2.8 gives BUN in mg/dL, so Le Gall's 6.0 / 10.0 / 20.0 mmol/L cutoffs land on 16.8 / 28 / 56 mg/dL — which is exactly the 17 / 28 / 56 already in the query. that leaves 7.50 with no basis at either scale, and since it sits below the >= 17.0 arm it only ever fired for BUN 7.5–16.9 mg/dL, i.e. an entirely normal BUN scoring a renal point. so i agree the arm is wrong and should go.

what i'd want before this lands is the evidence. this silently lowers LODS for a population, and anyone reproducing previously published numbers off this concept will see a shift, so the pr should say how big it is. the arm was only reachable when creatinine_max < 1.20 and urineoutput was between 750 and 10000 as well, and that combination is common — could you run it on the demo and report how many icustay_ids change their renal component and their total lods? if it turns out to be nothing in the demo, say that too and note it's a correctness fix rather than a data-visible one.

one observation, not something to fix here — mimic-iii/concepts/severityscores/saps.sql:201 still has when bun_max >= 7.50 then 1, and mlods.sql carries the same line commented out. i'm deliberately not asking you to touch those in this pr, but the note you've added says not to reintroduce mmol/L-style thresholds while an identical one survives two files over, so it may be worth a line pointing at saps rather than leaving the next reader to find it.

last small thing: in both postgres copies the transpiler attaches your new comment to the end of the cardiovascular CASE (END AS cardiovascular, /* renal */ /* BUN cutoffs are mg/dL ... */) rather than to the renal one. that's transpiler comment placement, not your doing, but since the comment exists specifically to stop someone reinstating the arm, putting it inside the renal CASE in the bigquery source would make it land where it's needed.