Closed amaletzk closed 10 months ago
Hi! I just checked the hadm_id 27570734 and 24106521 in the labevents and admissions in MIMIC-IV v2.2, and each of them has a unique subject_id. Moreover, the hadm_id 7034 had a subject_id that ends with 933(not on your list), and hadm_id 6521 has a subject_id that ends with 178(also not on your list).
Also, the rest of the hadm ids from your table are not in the labevents in MIMIC-IV v2.2, but all of them are in admissions, also with unique subject_ids, i.e no two unique subject ids share the same hadm_id.
Are you using a join in your query or how did you get this result, if I may ask?
Hi! Thanks for your quick response.
I grouped the entries in labevents by hadm_id and selected the minimum and maximum subject_id per group. Then I joined the resulting table with admissions and compared the subject_ids thus obtained.
Actually, the changelog of v2.0 mentions
The mechanism for determining patients included in MIMIC was changed. For the most part this has resulted in an improvement, particularly regarding the logic for merging patients who had distinct medical record numbers.
which could be the reason for the differences between v1.0 and v2.2. I'll check it on more recent versions - maybe the issue has been addressed in the meantime :)
Yep, the problem disappeared in v2.0. I'll therefore close this issue.
Prerequisites
Description
I think some of the subject/hadm IDs are inconsistent between tables "admissions" and "labevents" (and maybe others, but I've only checked these two so far).
Specifically, this concerns the following (exhaustive, as far as I can tell) list of hadm_ids:
subject_id_lab refers to the subject_id in "labevents", subject_id_adm to the subject_id in "admissions". Moreover, the two hadm_ids 27570734 and 24106521 are each associated with at least two distinct subject_ids in "labevents".
I've checked this with MIMIC-IV 1.0. The changelog does not mention that the issue has been fixed in a more recent version of MIMIC-IV.