Version: MIMIC-IV v3.1. All files match SHA256SUMS.txt and every table's row count matches mimic-iv/buildmimic/postgres/validate.sql.
What I found
14 of the 94,458 rows in icu/icustays have a valid intime but a null outtime and a null los. For every other stay, los matches outtime - intime exactly.
These look like real, completed ICU stays rather than stub rows:
- All 14 have a hospital
dischtime on their admission: 7 in-hospital deaths and 7 discharged alive.
- All 14 have bedside charting in
chartevents after intime, for example between 4 and 147 RASS values per stay.
- They are spread across units: MICU (4), CCU (4), MICU/SICU (2), CVICU (2), SICU (1), Neuro SICU (1).
I have not traced them back through transfers.
To reproduce
SELECT i.stay_id, i.first_careunit, i.intime, i.outtime, i.los,
a.dischtime, a.hospital_expire_flag
FROM mimiciv_icu.icustays i
JOIN mimiciv_hosp.admissions a USING (hadm_id)
WHERE i.outtime IS NULL;
Questions
- Is this expected, for example because the last ICU transfer has no out time in the source system?
- Could
outtime and los be filled from transfers in a future release? If not, could the icustays documentation note that outtime can be null?
Version: MIMIC-IV v3.1. All files match SHA256SUMS.txt and every table's row count matches
mimic-iv/buildmimic/postgres/validate.sql.What I found
14 of the 94,458 rows in
icu/icustayshave a validintimebut a nullouttimeand a nulllos. For every other stay,losmatchesouttime - intimeexactly.These look like real, completed ICU stays rather than stub rows:
dischtimeon their admission: 7 in-hospital deaths and 7 discharged alive.charteventsafterintime, for example between 4 and 147 RASS values per stay.I have not traced them back through
transfers.To reproduce
Questions
outtimeandlosbe filled fromtransfersin a future release? If not, could the icustays documentation note thatouttimecan be null?