MIT-LCP / MIT-LCP/mimic-code

Question about the number of patients in the oxygen_delivery table

Open
#1,570 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Jupyter Notebook
Stars
3.4k
Forks
1.7k
PR merge metrics
No merged PRs in 30d

Description

Prerequisites
Description

Hello,

We have observed that certain patients exhibit results in the chartevents table with itemid = 226732, but these results are absent in the oxygen_delivery table. One example is stay_id = 30813912.

Upon analyzing line 86 of the oxygen_delivery table, we discovered that placing the condition "where ce.rn = 1" here only includes patients present in the ce_stg2 table. Consequently, data for patients existing in the o2 table but not in the ce_stg2 table is missing.

Our solution is to remove this line of code and create a new table, ce_stg3. Do you have any suggestions for a better solution?

Thank you!

Daonan Chen & Zhou Zhou

, ce_stg2 AS ( select ce.subject_id , ce.stay_id , ce.charttime , itemid , value , valuenum , valueuom -- retain only 1 row per charttime -- prioritizing the last documented value -- primarily used to subselect o2 flows , ROW_NUMBER() OVER (PARTITION BY subject_id, charttime, itemid ORDER BY storetime DESC) as rn FROM ce_stg1 ce ) , ce_stg3 AS ( SELECT * FROM ce_stg2 WHERE rn = 1 )

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the oxygen_delivery query at line 86 and trace how ce_stg1, ce_stg2, and the rn filter are used. Compare stay_id 30813912 and itemid 226732 across chartevents, ce_stg2, and the oxygen source data. Done means the query's intended row-selection behavior is clarified and the missing patient records are handled consistently.

Written by the indexing model from the issue text.

Assessment

Tech stack
sql
Domain
databases
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.