MIT-LCP / MIT-LCP/mimic-code

WARDIDs and transfers within the ICU

Open
#607 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

I would really like to do a study that looks at the destination of patients after they leave ICU. I'm a bit confused looking at the transfers table and would like some help if possible:

To illustrate with one hospital stay:

mimic=> select icustay_id, eventtype, prev_careunit, curr_careunit, prev_wardid, curr_wardid from transfers where hadm_id = 155897;

 icustay_id | eventtype | prev_careunit | curr_careunit | prev_wardid | curr_wardid

 249202 | admit     |               | MICU          |             |          52

        | transfer  | MICU          |               |          52 |          32

 249202 | transfer  |               | MICU          |          32 |          52

        | transfer  | MICU          |               |          52 |          32

 249202 | transfer  |               | MICU          |          32 |          23

        | discharge | MICU          |               |          23 |

This example brings about my first question: this particular patient has the same icustay_id throughout, but they appear to be transferred out of an ICU area twice? How does this work?

I noted some things regarding WARDIDs on your website:

  • "Note that the grouping of physical locations in the hospital database is referred to as a ward. Though in practice ICUs are not referred to as wards, the hospital database technically tracks ICUs as “wards with an ICU cost center”. As a result, each ICU is associated with a WARDID, but not every WARDID is an ICU."
  • "The care unit is defined based upon the ward: if the ward is an ICU cost center, then the care unit defines the type of ICU. If the ward is not an ICU then in most cases the care unit is null."

I ran some quick queries:

mimic=> select count(distinct prev_wardid) from transfers;
count

53

mimic=> select count(distinct prev_wardid) from transfers where prev_careunit is null;
count

42

mimic=> select count(distinct curr_wardid) from transfers where curr_careunit is null;
count

40

mimic=> select count(distinct prev_wardid) from transfers where prev_careunit is not null;
count

19

mimic=> select count(distinct curr_wardid) from transfers where curr_careunit is not null;
count

19

To me this means that there are 53 different wards, of which 53-42=11 are always associated with an ICU cost center. A further 19-11=8 may or may not be associated with an ICU cost center (this seems slightly at odds with the second quote on there - are these patients outliers of full ICU centers?), and 53-19=34 are reliably not (ordinary wards I presume).

A classification problem with 53 output classes will be too many. I was wondering if you had any further information regarding the grouping of these wards? Particularly wards 55, 2, 45, 17, 40, 31, 18, 3, 4, 54, 24 and 36. It would be fantastic if you could tell me what these are.

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 transfers table and the cited WARDID and care-unit definitions, then reproduce the example for hadm_id 155897 and the provided ward counts. A useful result would document why ICU transfers can share an icustay_id and explain the grouping or identities of the listed wards; no repository file or test is identified.

Written by the indexing model from the issue text.

Assessment

Tech stack
sql
Domain
databases
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.