daily fluid balance implementation

[aegis301]

Several users already seem to have spoken about an implementation of fluid balance as a concept in mimic-code. This is a first kickoff for such an implementation on a daily fluid balance. Looking forward to your input!

[aegis301]

I noticed that I included too much values in the query, essentially including different units like mg and IE in the result. I fixed that to only include ml as unit of volume into the query. As state by the documentation on mimiciv_icu.inputevents in cases where there is an medication in mg and a volume these should be recorded both under the same orderid. E.g. 1000mg of Vancomycine in 100ml NaCl, there should be rows for both of them. By this query, I should be able to exclude the Vancomycine while keeping the NaCl bolus as is.

[Chessing234]

thanks for kicking this off — daily fluid balance is genuinely missing and worth having. i ran through the three scripts and there are some correctness problems that need sorting before this is usable.

placement first. all three files land in mimic-iv/concepts_postgres/measurement/, but that folder is generated: 65 of the 67 sql files in it carry the "AUTOMATICALLY GENERATED. DO NOT EDIT IT DIRECTLY" header, the only hand-written ones being postgres-make-concepts.sql and postgres-concept-index.sql. concepts are authored as bigquery in mimic-iv/concepts/ and transpiled to the postgres and duckdb folders, so as it stands these would be wiped by the next regeneration, and there are no duckdb copies or entries in postgres-make-concepts.sql, so nothing builds them.

the proration in daily_fluid_in doesn't compute what the comment implies:

amount / EXTRACT(EPOCH FROM (endtime - starttime)) / 3600 * (24 - EXTRACT(HOUR FROM starttime))

EPOCH is in seconds, so amount / epoch is already ml per second; dividing by 3600 again gives ml per second-hour rather than an hourly rate. for an hourly rate you want amount * 3600 / epoch. as written the result is smaller than intended by a factor of 3600^2.

the bigger issue is that a multi-day infusion only ever produces one row, keyed on CAST(starttime AS DATE). the 24 - EXTRACT(HOUR FROM starttime) term attributes the first day's share and nothing generates rows for the following days, so for a three-day infusion days two and three simply don't exist in the output — and EXTRACT(HOUR ...) drops the minutes too. this is the part that needs a generate_series over the spanned dates rather than a single row. the WITH RECURSIVE is declared but there's no recursive term, which i suspect is a leftover from an earlier attempt at exactly that.

daily_fluid_balance joins with LEFT JOIN from the input side, so any day with output but no ml-labelled input is dropped entirely rather than showing a negative balance — that wants a full outer join with coalesce on both sides and on the date key.

smaller ones: daily_fluid_out sums value with no valueuom filter while the input side filters amountuom = 'ml', so the two sides aren't guaranteed to be in the same units; and both use calendar dates rather than icu-day offsets from intime, which differs from how the other first-day/hourly concepts in the repo slice time — worth stating as a deliberate choice if it is one.

happy to look again once it's restructured against the bigquery source.