DOCSEARCHbyAlgolia
Submit Docs

eICU Collaborative Research Database Code Repository

repository·main·Indexed 19 days ago

https://github.com/mit-lcp/eicu-code

A community-driven repository for sharing and reusing code to analyze the eICU Collaborative Research Database. It provides tools and workflows for downloading data from PhysioNet and building the database using DuckDB or PostgreSQL, as well as instructions for accessing and navigating public demo data via SQLite.

Tokens
61.2K
Snippets
117
Records
221
Agent score
64%

What's inside eicu-code

  1. Overview of the eICU Collaborative Research Database Code Repository

    main
    The eICU Collaborative Research Database Code Repository serves as a central hub for the research community to share, refine, and reuse code used for analyzing the eICU Collaborative Research Database. The primary goal is to promote collaborative research and ensure study reproducibility by sharing data processing and analysis code.

  2. Overview of the respiratoryCare table

    main

    The respiratoryCare table contains clinical information related to respiratory care for patients in the eICU-CRD.

    Key Data Included:

    • Historical sequences of respiratory records.
    • Airway details: type, size, and position.
    • Cuff pressure.
    • Ventilator (vent) details: start/end dates/times, pressure limits, and apnea parameters.

    Relational Mapping:

    • The table links to the PATIENT table via the patientUnitStayID foreign key.

  3. Introduction to eICU database capabilities

    main

    The eICU database is a structured research database containing complex clinical data. Users can perform the following core tasks:

    • Metadata Extraction: Obtain information about database objects such as tables and views.
    • Basic Querying: Perform operations on single tables, including counting rows and filtering results using subsets.
    • Data Joining: Combine multiple tables using 'joins' to extract relational information.
    • View Utilization: Use pre-defined database 'views' to extract high-level, aggregated information.

  5. Important considerations for vitalPeriodic data

    main

    When using the vitalPeriodic table, keep the following caveats in mind:

    1. Unvalidated Data: The values represent 5-minute medians from bedside monitors and are considered unvalidated. This means the data has not been verified by a clinician and may contain noise or artifacts that do not reflect the true patient state.
    2. SaO2 vs. Arterial Blood Gas: The saO2 column contains oxygen measurements captured via vital sign monitors (SpO2). It should not be treated as arterial blood gas (ABG) measurements.

  6. Understand the nurseAssessment table

    main

    The nurseAssessment table (Nursing Assessment Flowsheet) is used to document patient assessment data, including pain, psychosocial status, neurologic, cardiovascular, respiratory, oral/GI/GU, skin, and other nursing-specific metrics.

    To link assessment data to a specific patient, join this table with the PATIENT table using the patientUnitStayID column.

  7. Understand the apacheApsVar table purpose and context

    main

    The apacheApsVar table contains the variables used to calculate the Acute Physiology Score (APS) III for patients. APS-III is used to summarize patient severity of illness upon ICU admission as part of the APACHE (Acute Physiology Age Chronic Health Evaluation) system.

    Key Concepts:

    • APS Points: Assigned based on the "Worst" values (the degree of physiologic derangement) exhibited during the APACHE Day.
    • APACHE Day: The specific time period in which clinical variables are used in the algorithms.
    • Relationship to other tables:
      • Links to the PATIENT table via patientUnitStayID.
      • Related to APACHEPATIENTRESULT and APACHEPREDVAR.
      • The apachePatientResult table contains two rows per patientUnitStayId: one for APACHE IV and one for APACHE IVa.

  8. Understand the carePlanEOL table

    main

    The carePlanEOL table contains documentation relating to end-of-life (EOL) care and discussions within the eICU-CRD. It is primarily used to track intraprofessional communication regarding code status, prognosis, family/healthcare proxy, and end-of-life discussions.

    Key Relationships:

    • Link to the PATIENT table via the patientUnitStayID column.

  9. Understand GCS scoring in apacheApsVar

    main

    The Glasgow Coma Scale (GCS) components in the apacheApsVar table are used to determine neurologic status. The "worst" GCS is defined as the assessment resulting in the lowest total score.

    • eyes: Range 1 to 4.
    • motor: Range 1 to 6.
    • verbal: Range 1 to 5.
    • meds: If meds is set to 1 (indicating "unable to score due to meds"), the eyes, motor, and verbal fields are set to 0.

    Total GCS scores range from 3 (worst) to 15 (best).

  10. Analyze pastHistory data structure and organ systems

    main

    Data in the pastHistory table includes date/time offsets, note types, root paths (e.g., notes/Progress Notes/Past History/...), picklist values, and text descriptions.

    Data entry fields are organized by the following organ systems:

    • Neurologic
    • Cardiovascular
    • Pulmonary
    • Gastrointestinal
    • Infectious Disease
    • Hematology/Oncology
    • Endocrine
    • Rheumatic

  11. Important considerations for physicalExam data

    main

    When working with physical exam data, keep the following in mind:

    • Data Entry: Data is entered directly into eCareManager.
    • Data Availability: Physical exam choices include Not Performed, Performed-Free Text, and Performed-Structured. Note that free text sections are not included in the research database.
    • Structured Data: The Performed-Structured option provides pick list selections and specific text entry boxes.
    • Vital Signs: For values such as heart rate, blood pressure, temperature, respiratory rate, and O2 sat, the table includes both the current values and the 24-hour range.