MIT-LCP / eicu-code

Code and website related to the eICU Collaborative Research Database
https://eicu-crd.mit.edu
MIT License
320 stars 219 forks source link

The proportion of patients with hemorrhagic shock in the eicu database is far less than other databases #174

Closed xujiameng closed 3 years ago

xujiameng commented 3 years ago

Hello, I am screening patients with shock in mimiciii, EICU, amsterdamumcdb, these three databases. However, problems were encountered when examining patients with hemorrhagic shock. The following contains some data mining results.

  1. Screen the target patients who are admitted to the hospital due to trauma, and limit the length and age of hospitalization. There are 3098 icustay_id in the mimiciii, accounting for about 1/20 of the total (3098: 61532); 1163 admissionid in the amsterdamumcdb, accounting for about 1/20 of the total (1163: 23106); 11195 patientunitstayid in the eicu, which accounts for about 1/18 of the total (11195: 200859).

  2. Screen the patients who have experienced shock symptoms among the above. There are 1067 icustay_id in the mimiciii database, accounting for about 1/3 of the total (1067:3098); 414 admissionid in amsterdamumcdb, accounting for about 1/3 of the total (414:1163); There are 3149 patientunitstayid in the eicu database, About 1/3 of the total (3149:11195).

So far, the rules of target patient data in the three databases are basically consistent. However, when selecting patients with hemorrhagic shock, the performance of the EICU database is not consistent with the other two.

  1. Screening of patients admitted to the hospital due to trauma, within 5 hours after the onset of shock symptoms, the patient received a blood transfusion. In the mimiciii database, there are 293 icustay_id, accounting for about 1/4 of the total (293:1067); in admissionid , there are 106 people, accounting for about 1/4 of the total (106:414); while, there are only 444 patientunitstayid in the eicu database, accounting for about 1/7 of the total (444: 3149). If calculated according to the law, it seems that there should be about 800 person-times.

I used the following conditions when screening blood transfusion information

"Where intakeoutput.cellpath ilike'%blood%' and cellpath not ilike'%|output%' and cellpath not ilike'Cryoprecipitate' ".

This is similar to the content used in the process of screening MIMICIII and amsterdamumcdb database, including "Fresh Frozen Plasma", "Platelets", "(P)RBC", "Transfuse" and other information

I'm not sure if I missed some of the query content, and I am eager to answer.

xujiameng commented 3 years ago

I hope someone can answer this question, which has greatly delayed the progress of the data mining project. Looking forward to the answers of alistairewj or others.

obadawi commented 3 years ago

As a supplementary system for managing patients, some systems do not use automated interfaces for bringing in I/O data ( https://eicu-crd.mit.edu/eicutables/intakeoutput/) and may not invest the time to manually chart in the system. It may be worth evaluating patterns for each ICU or facility which will likely show that some ICUs never/virtually never chart this data for any patient.

On Thu, Apr 15, 2021 at 3:27 AM 佳盟 @.***> wrote:

Hello, I am screening patients with shock in mimiciii, EICU, amsterdamumcdb, these three databases. However, problems were encountered when examining patients with hemorrhagic shock. The following contains some data mining results.

1.

Screen the target patients who are admitted to the hospital due to trauma, and limit the length and age of hospitalization. There are 3098 icustay_id in the mimiciii, accounting for about 1/20 of the total (3098: 61532); 1163 admissionid in the amsterdamumcdb, accounting for about 1/20 of the total (1163: 23106); 11195 patientunitstayid in the eicu, which accounts for about 1/18 of the total (11195: 200859). 2.

Screen the patients who have experienced shock symptoms among the above. There are 1067 icustay_id in the mimiciii database, accounting for about 1/3 of the total (1067:3098); 414 admissionid in amsterdamumcdb, accounting for about 1/3 of the total (414:1163); There are 3149 patientunitstayid in the eicu database, About 1/3 of the total (3149:11195).

So far, the rules of target patient data in the three databases are basically consistent. However, when selecting patients with hemorrhagic shock, the performance of the EICU database is not consistent with the other two.

  1. Screening of patients admitted to the hospital due to trauma, within 5 hours after the onset of shock symptoms, the patient received a blood transfusion. In the mimiciii database, there are 293 icustay_id, accounting for about 1/4 of the total (293:1067); in admissionid , there are 106 people, accounting for about 1/4 of the total (106:414); while, there are only 444 patientunitstayid in the eicu database, accounting for about 1/7 of the total (444: 3149). If calculated according to the law, it seems that there should be about 800 person-times.

I used the following conditions when screening blood transfusion information

"Where intakeoutput.cellpath ilike'%blood%' and cellpath not ilike'%|output%' and cellpath not ilike'Cryoprecipitate' ".

This is similar to the content used in the process of screening MIMICIII and amsterdamumcdb database, including "Fresh Frozen Plasma", "Platelets", "(P)RBC", "Transfuse" and other information

I'm not sure if I missed some of the query content, and I am eager to answer.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MIT-LCP/eicu-code/issues/174, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6USVHWR3SOMK265H6Y63TTI2IN7ANCNFSM4264G37Q .

xujiameng commented 3 years ago

As a supplementary system for managing patients, some systems do not use automated interfaces for bringing in I/O data ( https://eicu-crd.mit.edu/eicutables/intakeoutput/) and may not invest the time to manually chart in the system. It may be worth evaluating patterns for each ICU or facility which will likely show that some ICUs never/virtually never chart this data for any patient. On Thu, Apr 15, 2021 at 3:27 AM 佳盟 @.***> wrote: Hello, I am screening patients with shock in mimiciii, EICU, amsterdamumcdb, these three databases. However, problems were encountered when examining patients with hemorrhagic shock. The following contains some data mining results. 1. Screen the target patients who are admitted to the hospital due to trauma, and limit the length and age of hospitalization. There are 3098 icustay_id in the mimiciii, accounting for about 1/20 of the total (3098: 61532); 1163 admissionid in the amsterdamumcdb, accounting for about 1/20 of the total (1163: 23106); 11195 patientunitstayid in the eicu, which accounts for about 1/18 of the total (11195: 200859). 2. Screen the patients who have experienced shock symptoms among the above. There are 1067 icustay_id in the mimiciii database, accounting for about 1/3 of the total (1067:3098); 414 admissionid in amsterdamumcdb, accounting for about 1/3 of the total (414:1163); There are 3149 patientunitstayid in the eicu database, About 1/3 of the total (3149:11195). So far, the rules of target patient data in the three databases are basically consistent. However, when selecting patients with hemorrhagic shock, the performance of the EICU database is not consistent with the other two. 1. Screening of patients admitted to the hospital due to trauma, within 5 hours after the onset of shock symptoms, the patient received a blood transfusion. In the mimiciii database, there are 293 icustay_id, accounting for about 1/4 of the total (293:1067); in admissionid , there are 106 people, accounting for about 1/4 of the total (106:414); while, there are only 444 patientunitstayid in the eicu database, accounting for about 1/7 of the total (444: 3149). If calculated according to the law, it seems that there should be about 800 person-times. I used the following conditions when screening blood transfusion information "Where intakeoutput.cellpath ilike'%blood%' and cellpath not ilike'%|output%' and cellpath not ilike'Cryoprecipitate' ". This is similar to the content used in the process of screening MIMICIII and amsterdamumcdb database, including "Fresh Frozen Plasma", "Platelets", "(P)RBC", "Transfuse" and other information I'm not sure if I missed some of the query content, and I am eager to answer. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#174>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6USVHWR3SOMK265H6Y63TTI2IN7ANCNFSM4264G37Q .

Thank you for your reply, but I still need to confirm one point: can I understand that this is a separate problem in the EICU database? Because the proportion of patients with hemorrhagic shock in the other two databases is the same, but different from the EICU database. If the problem is universal, the proportion of this type of patients in the three databases should be similar.

jraffa commented 3 years ago

Yes, eICU is a multicenter database, and there is some variation in data collection. The difference you observe may be real, or may be simply that some hospitals don't collect that information and all their patients appear not to exhibit the characteristics you are trying to determine, regardless of the truth.

As @obadawi mentioned, there may be some hospitals where the proportion of patients with your criteria is zero or near zero.

I would first look the the prevalence by hospitalid. If you end up with a cluster of hospitals with roughly the same proportion as in MIMIC and another cluster of hospitals near 0%, it would be appropriate to remove the cluster of hospitals near zero,. With smaller hospitals it gets a little tricky, but focus on the larger hospitals to start.

xujiameng commented 3 years ago

Thanks for the reply of @obadawi and @jraffa , I decided to attribute the low proportion of patients with hemorrhagic shock to the fact that some data were not recorded according to your suggestions. I will also mention this in the relevant reports.

Thank you again for your help