Build echo features table

[tbepler]

For each patient, features of interest for filtering and stratification/modeling:

• Inpatient/outpatient echo features
• ICU echo features
• Time relative to ICU admission
• ICU sepsis at time of echo
• Which drugs (pressors/inotropes) was the patient given
• Amount of fluids patient was given
• Age at time of echo
• Comorbidities: obesity, alchohol abuse
• On mechanical ventilation during echo, what type
• Labs: creatinine, troponin, lactate, etc. (see labs of interest) [time of echo, at 24, 48, ... hours]
• Renal function, on dialysis, etc.

[yhtgrace]

As of the current commit, echo_icustay now only assigns echos an icustay_id and filters for echos to which an icustay_id can be assigned. echo_filter is where variables relevant to filtering (like intime to echo, whether or not the patient was on vasopressors etc.) are computed. I think this is where the final logic for inclusion/exclusion criteria would eventually go. Finally, I have begun to compile features from the feature masterlist in echo_features, which in theory would just use the icustay_id from the filtered list to get all the features.

A nice side-effect of having the echo_icustay table separate is that d_prescriptions_vaso etc. can filter against (and depend on) echo_icustay, while echo_filter can then depend on d_prescriptions_vaso and echo_icustay.

[mnxu]

Thanks for the update Grace!

I still think that we should assign tasks so nothing is left out. How
about we put our names next to categories or specific items in the Features
list? For example, I can own fluid related queries: plus additional
categories of features.

• Total IV fluids volume (ml) per day of ICU stay and on the day of the echo
• Total body balance (TBB), Ins, Outs, per day of ICU and on the day of
  echo

We should then give some though on how to link all the different categories
of features, such as apply "echo_filter" ...

Minnan

On Mon, Nov 7, 2016 at 4:07 PM, yhtgrace notifications@github.com wrote:

As of the current commit, echo_icustay now only assigns echos an
icustay_id and filters for echos to which an icustay_id can be assigned.
echo_filter is where variables relevant to filtering (like intime to
echo, whether or not the patient was on vasopressors etc.) are computed.
Finally, I have begun to compile features from the feature masterlist in
echo_features.

A nice side-effect of having the echo_icustay table separate is that
d_prescriptions_vaso etc. can filter against (and depend on) echo_icustay,
while echo_filter can then depend on d_prescriptions_vaso and echo_icustay.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA7KpKHKz7_PGxk2z7MIRPO_W3psOR8Cks5q75MegaJpZM4Kh1RO
.

[yhtgrace]

Sure, we could mark it in the google docs? Alternatively, it might be easier to migrate the list to a spreadsheet so that we can keep track of who owns a feature, as well as which table/script it is in. What do you think?

Re compiling the data, I'm thinking of the following workflow:

• echo_icustay assigns icustay_ids to each echo
• echo_filter_vars calculates variables used for filtering echos (time, on pressors, heart-related diagnoses, age)
• echo_filter applies the actual filters, including restricting one echo/patient

Then, we make our own tables for features that make sense to be grouped together (for example, demographics, all fluid-related items etc.) from the masterlist, and finally, have one script that puts all those features together in a single table, say echo_features.

[mnxu]

Great!

I have added transferred the feature list to the same spread sheet document
as before, named 'echosepsis', in the 'FeatureList' tab.

Minnan

On Tue, Nov 8, 2016 at 10:13 PM, yhtgrace notifications@github.com wrote:

Sure. Let's just mark it in the google docs? It might be easier to migrate
the list to a spreadsheet so that we can keep track of who owns a feature,
as well as which table/script it is in. What do you think?

Re compiling the data, I'm thinking of the following workflow:

• echo_icustay assigns icustay_ids to each echo
• echo_filter_vars calculates variables used for filtering echos
  (time, on pressors, heart-related diagnoses, age)
• echo_filter applies the actual filters, including restricting one
  echo/patient

Then, we make our own tables for features that make sense to be grouped
together (for example, demographics, all fluid-related items etc.) from the
masterlist, and finally, have one script that puts all those features
together in a single table, say echo_features.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA7KpFyTRIS4Q9RQd2uCmxUKadIpERcAks5q8TpIgaJpZM4Kh1RO
.

[yhtgrace]

I've committed an initial implementation of echo_filter_vars and echo_filtered. echo_filter_vars now includes variables (in addition to intime_to_echo):

• ps_vaso, which is true if that icustay_id is associated with the list of vasopressors from d_prescriptions_vaso. The d_prescriptions_vaso table is built programmatically in the script of the same name.
• diag_xc, which is true if that hadm_id is associated with the list of exclusion diagnoses from d_diagnoses_xc_annot. The d_diagnoses_xc_annot table is built from the annotated csv on google docs in the script of the same name.

The total number of unique subject_ids where the patient was on a vasopressor (ps_vaso is true) but did not have one of the diagnoses from the exclusion list (diag_xc is false) is 2277. Note that the time filter has not been applied to get this count. Also, I have not yet implemented the logic for getting the most recent ICU stay, but the total number of unique subject_ids effectively caps the total unique echos we currently have with these filters defined. Finally, I still need to verify the count in Python, since some of the sql I used is potentially sketchy.