From c720f84d476411ed8862b1fff4ba192e3e54f63b Mon Sep 17 00:00:00 2001 From: Dana Moukheiber Date: Wed, 27 Sep 2023 14:42:26 -0400 Subject: [PATCH] minor edits --- content/en/docs/mimic-nw/_index.md | 8 ++++---- content/en/docs/mimic-nw/modules/hosp/_index.md | 6 ++++-- content/en/docs/mimic-nw/modules/hosp/admissions.md | 4 ++-- .../en/docs/mimic-nw/modules/hosp/d_icd_diagnoses.md | 8 ++++---- .../en/docs/mimic-nw/modules/hosp/diagnoses_icd.md | 2 +- content/en/docs/mimic-nw/modules/hosp/emar.md | 12 ++++++------ content/en/docs/mimic-nw/modules/hosp/patients.md | 6 +++--- .../en/docs/mimic-nw/modules/hosp/prescriptions.md | 8 ++++---- content/en/docs/mimic-nw/modules/icu/_index.md | 6 ++++-- content/en/docs/mimic-nw/modules/icu/chartevents.md | 4 ++-- content/en/docs/mimic-nw/modules/icu/d_items.md | 9 +++++---- content/en/docs/mimic-nw/modules/icu/icustays.md | 6 +++--- .../en/docs/mimic-nw/modules/icu/procedureevents.md | 12 ++++++------ 13 files changed, 48 insertions(+), 43 deletions(-) diff --git a/content/en/docs/mimic-nw/_index.md b/content/en/docs/mimic-nw/_index.md index 810c2036..ebcfa035 100644 --- a/content/en/docs/mimic-nw/_index.md +++ b/content/en/docs/mimic-nw/_index.md @@ -8,7 +8,7 @@ cascade: _target: path: "/**" --- -MIMIC-Fed is a large, freely available federated COVID-rich ICU database comprising deidentified health-related data from Beth Israel Deaconess Medical Center (BIDMC) and Northwestern Memorial Health Center (NHMC) from 2020 to 2022. The federated database adopts a similar data structure as MIMIC-IV v2.2. +MIMIC-Fed is a large, freely available federated COVID-rich ICU database comprising deidentified health-related data from Beth Israel Deaconess Medical Center (BIDMC) and Northwestern Memorial Health Center (NHMC) from 2020 to 2022, capturing the evolving distribution shifts in data over this critical time period. The federated database adopts a similar data structure as MIMIC-IV v2.2. Notably, Northwestern Memorial Health Center (NHMC) uses the Epic electronic medical records (EMR) system. To make the EMR data available for research and quality assurance, the NM EMR systems transfer selected data into a relational Enterprise Data Warehouse (NM EDW). @@ -18,7 +18,7 @@ The NM EDW also includes auxiliary tables not directly related to patient care, MIMIC-Fed is currently organized into two distinct modules to highlight the source of the data: -- [hosp](/docs/mimic-nw/modules/hosp/) - Hospital level data including patients, admissions, labs, ICD diagnoses for billing purposes, prescriptions, and electronic medication administration records. -- [icu](/docs/mimic-nw/modules/icu/) - ICU level data including icu stays, procedure events, chartevents (vital signs). +- [HOSP](/docs/mimic-nw/modules/hosp/) - Federated hospital level data including patients, admissions, labs, ICD diagnoses for billing purposes, prescriptions, and electronic medication administration records. +- [ICU](/docs/mimic-nw/modules/icu/) - Federated ICU level data including icu stays, procedure events, chartevents (vital signs). -The tables structures adopted to align with MIMIC's data structure for each module are detailed in the respective sections. \ No newline at end of file +The tables structures adopted to align with MIMIC's data structure for each module are detailed in the respective sections. Additionally, we have incorporated COVID-related concepts and standard terminologies (LOINC, RxNorm, SNOMED, ICD-9/10) and derived mappings (for drug administration) into the dataset. This integration not only facilitates current federation efforts, but also facilities interoperability, allowing for seamless data exchange and collaboration across healthcare systems. diff --git a/content/en/docs/mimic-nw/modules/hosp/_index.md b/content/en/docs/mimic-nw/modules/hosp/_index.md index f36bd30e..72b0129f 100644 --- a/content/en/docs/mimic-nw/modules/hosp/_index.md +++ b/content/en/docs/mimic-nw/modules/hosp/_index.md @@ -4,9 +4,11 @@ linkTitle: "Hosp" date: 2023-09-18 weight: 20 description: > - The Hosp module comprises data sourced from the comprehensive Electronic Health Record (EHR) systems of both BIDMC and NMHC hospitals. Information covered includes patient and admission information, laboratory measurements, billed diagnoses, prescriptions, and electronic medication administration records. + The Hosp module comprises data sourced from the comprehensive Electronic Health Record (EHR) systems of both BIDMC and NHMC hospitals. Information covered includes patient and admission information, laboratory measurements, billed diagnoses, medication orders, and electronic medication administration records. --- -The hosp module contains data derived from the hospital wide EHR. These measurements are predominantly recorded during the hospital stay, though some tables include data from outside the hospital as well (e.g. outpatient laboratory tests in labevents). Information includes patient and admission details (patients, admissions), laboratory measurements (labevents, d_labitems), hospital billing information (diagnoses_icd, d_icd_diagnoses), medication prescription (prescriptions), and electronic medication administration records (emar). +The HOSP module contains data derived from the hospital wide EHR of BIDMC and NHMC. These measurements are predominantly recorded during the hospital stay, though some tables include data from outside the hospital as well (e.g. outpatient laboratory tests in *labevents*). + +Information includes patient and admission details (*patients*, *admissions*), laboratory measurements (*labevents*, *d_labitems*), hospital billing information (*diagnoses_icd*, *d_icd_diagnoses*), medication orders (*prescriptions*), and electronic medication administration records (*emar*). diff --git a/content/en/docs/mimic-nw/modules/hosp/admissions.md b/content/en/docs/mimic-nw/modules/hosp/admissions.md index a36a107e..9b61789b 100644 --- a/content/en/docs/mimic-nw/modules/hosp/admissions.md +++ b/content/en/docs/mimic-nw/modules/hosp/admissions.md @@ -44,7 +44,7 @@ The *admissions* table defines all hospitalizations in the database. Hospitaliza ### `hadm_id` -Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the PATIENTS table using `subject_id`. +Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the *patients* table using `subject_id`. ### `admittime` @@ -142,4 +142,4 @@ The date and time at which the patient was discharged from the emergency departm ### `hospital_expire_flag` -This is a binary flag which indicates whether the patient died within the given hospitalization. `1` indicates death in the hospital as noted in the `dod` column as part of the patient table, and `0` indicates survival to hospital discharge. +This is a binary flag which indicates whether the patient died within the given hospitalization. `1` indicates death in the hospital as noted in the `dod` column as part of the *patient* table, and `0` indicates survival to hospital discharge. diff --git a/content/en/docs/mimic-nw/modules/hosp/d_icd_diagnoses.md b/content/en/docs/mimic-nw/modules/hosp/d_icd_diagnoses.md index edd6e912..29ee9f4a 100644 --- a/content/en/docs/mimic-nw/modules/hosp/d_icd_diagnoses.md +++ b/content/en/docs/mimic-nw/modules/hosp/d_icd_diagnoses.md @@ -42,11 +42,11 @@ ICD-11 became the official [WHO standard](https://www.who.int/standards/classifi ### `long_title` -The `long_title` provides a description of the ICD code. For example, the ICD-10 code U07.1 has `long_title` "COVID-19 (confirmed by laboratory testing)". +The `long_title` provides a description of the ICD code. For example, the ICD-10 code U07.1 has a `long_title` of 'COVID-19 (confirmed by laboratory testing)'. In the tables below, we provide ICD-10 codes related to covid or long covid. -ICD-10 COVID markers terminologies: +Terminologies related to COVID markers in the ICD-10: | icd_code | long_title | | -------- | -------------------------------------------------------- | @@ -56,13 +56,13 @@ ICD-10 COVID markers terminologies: | J12.81 | Pneumonia due to SARS-associated coronavirus | -ICD-10 Long COVID markers terminologies: +Terminologies for Long COVID markers in ICD-10: | icd_code | long_title | | -------- | ---------------------------------------------- | | U09.9 | Post COVID-19 condition, unspecified | -ICD-10 Other COVID related terminologies: +Terminologies related to other COVID aspects in ICD-10: | icd_code | long_title | |----------|-----------------------------------------------------------------------------------------------------------| diff --git a/content/en/docs/mimic-nw/modules/hosp/diagnoses_icd.md b/content/en/docs/mimic-nw/modules/hosp/diagnoses_icd.md index c4c680cc..066aeada 100644 --- a/content/en/docs/mimic-nw/modules/hosp/diagnoses_icd.md +++ b/content/en/docs/mimic-nw/modules/hosp/diagnoses_icd.md @@ -31,7 +31,7 @@ Name | Postgres data type ### `hadm_id` -Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the PATIENTS table using `subject_id`. +Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the *patients* table using `subject_id`. ### `icd_code` diff --git a/content/en/docs/mimic-nw/modules/hosp/emar.md b/content/en/docs/mimic-nw/modules/hosp/emar.md index b566c293..02a80792 100644 --- a/content/en/docs/mimic-nw/modules/hosp/emar.md +++ b/content/en/docs/mimic-nw/modules/hosp/emar.md @@ -9,7 +9,7 @@ description: > ## *emar* -The EMAR table is used to record administrations of a given medicine to an individual patient. +The *emar* table is used to record administrations of a given medicine to an individual patient. Records in this table are populated by bedside nursing staff scanning barcodes associated with the medicine and the patient. ## Links to @@ -18,10 +18,10 @@ Records in this table are populated by bedside nursing staff scanning barcodes a ## Important considerations -* In the clinical process, a doctor prescribes the medication, a pharmacist fills the prescription, and a nurse administers it through the electronic Medication Administration Record (eMAR). Therefore, it is important to note that not all 'eMAR pharmacy_id’ entries should necessarily appear in the prescription table. +* In the clinical process, a doctor prescribes the medication, a pharmacist fills the prescription, and a nurse administers it through the electronic Medication Administration Record (eMAR). Therefore, it is important to note that not all 'eMAR pharmacy_id’ entries should necessarily appear in the *prescription* table. * It's possible for discrepancies to occur in the transition from left to right in this process, where a wrong prescription might be detected and corrected by the pharmacist before the medication is filled. * Similarly, many prescriptions don’t have a corresponding eMAR entry, usually because the prescription is intended for outpatient use following discharge. -* It is typical for one prescription to have multiple eMAR entries; for example, a medication order “BID for 7 days” would be expected to have 14 eMAR entries. +* It is typical for one prescription to have multiple eMAR entries; for example, a medication order 'BID for 7 days' would be expected to have 14 eMAR entries. ## Table columns @@ -44,11 +44,11 @@ Name | Postgres data type ### `hadm_id` -Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the PATIENTS table using `subject_id`. +Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the *patients* table using `subject_id`. ### `emar_id`, `emar_seq` -Identifiers for the eMAR table. `emar_id` is a unique identifier for each order made in eMAR. `emar_seq` is a consecutive integer which numbers eMAR orders chronologically. `emar_id` is composed of `subject_id` and `emar_seq` in the following pattern: '`subject_id`-`emar_seq`'. +Identifiers for the *emar* table. `emar_id` is a unique identifier for each order made in eMAR. `emar_seq` is a consecutive integer which numbers eMAR orders chronologically. `emar_id` is composed of `subject_id` and `emar_seq` in the following pattern: '`subject_id`-`emar_seq`'. ### `charttime` @@ -69,4 +69,4 @@ If present, the time at which the administration was scheduled. ### `storetime` -The time at which the administration was documented in the eMAR table. +The time at which the administration was documented in the *emar* table. diff --git a/content/en/docs/mimic-nw/modules/hosp/patients.md b/content/en/docs/mimic-nw/modules/hosp/patients.md index 3daa8aaf..0b53056d 100644 --- a/content/en/docs/mimic-nw/modules/hosp/patients.md +++ b/content/en/docs/mimic-nw/modules/hosp/patients.md @@ -27,7 +27,7 @@ Name | Postgres data type ### `gender` -The patient's administrative `gender`, sourced from the NW EDW and stored in the patient table, is represented as follows: F (Female), M (Male). +The patient's administrative `gender`, sourced from the NW EDW and stored in the *patient* table, is represented as follows: F (Female), M (Male). ### `anchor_age` @@ -35,14 +35,14 @@ The patient's administrative `gender`, sourced from the NW EDW and stored in the This ensures that the statistical anonymity of a patient is maintained and that the data shared complies with the [HIPPA](https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html) standards, specifically: -"(C) All elements of dates (except year) for dates that are directly related to an individual, including birth date, admission date, discharge date, death date, and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older." +'(C) All elements of dates (except year) for dates that are directly related to an individual, including birth date, admission date, discharge date, death date, and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older.' ### `anchor_year`, `anchor_year` is the shifted year based on the patient's shifted earliest admission date. ### `anchor_year_group` -`anchor_year_group` is the sequence of three years including the the year in which a patient was admitted. For example, if a patient was admitted in 2020, 2021, or 2022, the `anchor_year_group` will be "2020-2022." +`anchor_year_group` is the sequence of three years including the the year in which a patient was admitted. For example, if a patient was admitted in 2020, 2021, or 2022, the `anchor_year_group` will be '2020-2022'. ### `dod` diff --git a/content/en/docs/mimic-nw/modules/hosp/prescriptions.md b/content/en/docs/mimic-nw/modules/hosp/prescriptions.md index b2aa7686..24dcfe70 100644 --- a/content/en/docs/mimic-nw/modules/hosp/prescriptions.md +++ b/content/en/docs/mimic-nw/modules/hosp/prescriptions.md @@ -56,7 +56,7 @@ Name | Postgres data type ### `hadm_id` -Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the PATIENTS table using `subject_id`. +Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The *admissions* table can be linked to the *patients* table using `subject_id`. ### `pharmacy_id` @@ -104,13 +104,13 @@ The amount of the medication which is contained in a single formulary dose. ### `form_unit_disp` -The unit of measurement used for the formulary dosage. Examples include “mg”, “Units”, “mL”, “mEq”, “tablet”, “mcg/min”, “mcg/kg/hr”, etc. +The unit of measurement used for the formulary dosage. Examples include 'mg', 'Units', 'mL', 'mEq', 'tablet', 'mcg/min', 'mcg/kg/hr', etc. ### `doses_per_24_hrs` -The number of doses per 24 hours for which the medication is to be given. A daily dose would result in `doses_per_24_hrs`: 1, bidaily (BID) or twice a day would be 2, and so on. Within NHMC, if the medication order couldn’t be converted to doses_per_24_hrs (such as “Once”, “PRN”, “Continuous”, “Weekly”’, or “Q 90 days”) the value would be missing. +The number of doses per 24 hours for which the medication is to be given. A daily dose would result in `doses_per_24_hrs`: 1, bidaily (BID) or twice a day would be 2, and so on. Within NHMC, if the medication order couldn’t be converted to `doses_per_24_hrs` (such as 'Once', 'PRN', 'Continuous', 'Weekly', or 'Q 90 days') the value would be missing. ### `route` -The route of administration for the medication, such as “Oral”, “Intravenous”, “Injection”, “Subcutaneous”, “Inhalation”, “Topical”, etc. May be missing. +The route of administration for the medication, such as 'Oral', 'Intravenous', 'Injection', 'Subcutaneous', 'Inhalation', 'Topical', etc. May be missing. diff --git a/content/en/docs/mimic-nw/modules/icu/_index.md b/content/en/docs/mimic-nw/modules/icu/_index.md index e2ccf434..9271f309 100644 --- a/content/en/docs/mimic-nw/modules/icu/_index.md +++ b/content/en/docs/mimic-nw/modules/icu/_index.md @@ -4,7 +4,9 @@ linkTitle: "ICU" date: 2023-09-18 weight: 30 description: > - The ICU module contains information collected from the clinical information system used within the ICU. Information covered includes icu admissions, procedures, and vital signs charted information. + The ICU module contains information collected from the clinical information system of both BIDMC and NHMC used within the ICU. Information covered includes icu admissions, procedures, and charted vital sign data. --- -The ICU module contains data sourced from the clinical information system at the BIDMC: MetaVision (iMDSoft). MetaVision tables were denormalized to create a star schema where the icustays and d_items tables link to a set of data tables all suffixed with "events". Data documented in the icu module includes icu admissions (icu stays) procedures (procedureevents, d_items), and vital signs charted information (chartevents, d_items). All events tables contain a stay_id column allowing identification of the associated ICU patient in icustays, and an itemid column allowing identification of the concept documented in d_items. \ No newline at end of file +The ICU module contains data sourced from the clinical information system at the BIDMC (MetaVision (iMDSoft)) and NHMC. MetaVision tables in BIDMC were denormalized to create a star schema where the icustays and d_items tables link to a set of data tables all suffixed with *events*. + +Data documented in the ICU module includes icu admissions (*icu stays*), procedures (*procedureevents*, *d_items*), and charted vital sign data (*chartevents*, *d_items*). All events tables contain a `stay_id` column allowing identification of the associated ICU patient in *icustays*, and an `itemid` column allowing identification of the concept documented in *d_items*. \ No newline at end of file diff --git a/content/en/docs/mimic-nw/modules/icu/chartevents.md b/content/en/docs/mimic-nw/modules/icu/chartevents.md index 94788bb7..780087a3 100644 --- a/content/en/docs/mimic-nw/modules/icu/chartevents.md +++ b/content/en/docs/mimic-nw/modules/icu/chartevents.md @@ -53,7 +53,7 @@ Date and time when the vital sign was measured, deidentified. ### `itemid` -Identifier for a single measurement type in the database. Each row associated with one `itemid` (e.g. 220045) corresponds to an instantiation of the same measurement (e.g. Heart Rate) for Routine Vital Signs `category`, and 'bpm' `unit_name`. +Identifier for a single measurement type in the database. Each row associated with one `itemid` (e.g. 220045) corresponds to an instantiation of the same measurement (e.g. Heart Rate) within the `category` of 'Routine Vital Signs', and `unit_name` of 'bpm'. ### `value`, `valuenum` @@ -63,7 +63,7 @@ Identifier for a single measurement type in the database. Each row associated wi ### `valueuom` -`valueuom` is the unit of measurement for the `value`, if appropriate. Either missing or “%”. +`valueuom` is the unit of measurement for the `value`, if appropriate. Either missing or '%'. ### `warning` diff --git a/content/en/docs/mimic-nw/modules/icu/d_items.md b/content/en/docs/mimic-nw/modules/icu/d_items.md index f6f9e427..dfb878c9 100644 --- a/content/en/docs/mimic-nw/modules/icu/d_items.md +++ b/content/en/docs/mimic-nw/modules/icu/d_items.md @@ -28,9 +28,10 @@ highnormalvalue | FLOAT # Detailed Description -The D_ITEMS table defines `itemid`, which represents measurements in the database. Measurements of the same type (e.g. heart rate) will have the same `itemid` (e.g. 220045). Values in the `itemid` column are unique to each row. All `itemid`s will have a value > 220000. +The *d_items* table defines `itemid`, which represents measurements in the database. Measurements of the same type (e.g. heart rate) will have the same `itemid` (e.g. 220045). Values in the `itemid` column are unique to each row. All `itemid`s will have a value > 220000. + +To faciliate future federation processes, we will release mappings within charted events (including vital signs) to standard terminologies (LOINC) and mappings for procedure events to standard terminologies (SNOMED). -To facilitate further federation processes, the chartevents mappings (including vital signs and procedures) to standard terminologies (LOINC) and procedurevents mappints to standard terminologies (SNOMED) will be released. We provide a list of common vital sign labels in the database, as defined by LOINC terminology, below: @@ -58,7 +59,7 @@ The `abbreviation` column, lists a common abbreviation for the label. ### `linksto` -`linksto` provides the table name which the data links to. For example, a value of 'chartevents' indicates that the `itemid` of the given row is contained in CHARTEVENTS. A single `itemid` is only used in one event table, that is, if an `itemid` is contained in CHARTEVENTS it will *not* be contained in any other event table (e.g. PROCEDUREEVENTS, etc). +`linksto` provides the table name which the data links to. For example, a value of 'chartevents' indicates that the `itemid` of the given row is contained in CHARTEVENTS. A single `itemid` is only used in one event table, that is, if an `itemid` is contained in CHARTEVENTS it will *not* be contained in any other event table (e.g. *procedureevents*, etc). ### `category` @@ -66,7 +67,7 @@ The `abbreviation` column, lists a common abbreviation for the label. ### `unitname` -`unitname` specifies the unit of measurement used for the `itemid`. This column is not always available, and this may be because the unit of measurement varies, a unit of measurement does not make sense for the given data type, or the unit of measurement is simply missing. Note that there is sometimes additional information on the unit of measurement in the associated event table, e.g. the `valueuom` column in CHARTEVENTS. +`unitname` specifies the unit of measurement used for the `itemid`. This column is not always available, and this may be because the unit of measurement varies, a unit of measurement does not make sense for the given data type, or the unit of measurement is simply missing. Note that there is sometimes additional information on the unit of measurement in the associated event table, e.g. the `valueuom` column in *chartevents*. ### `param_type` diff --git a/content/en/docs/mimic-nw/modules/icu/icustays.md b/content/en/docs/mimic-nw/modules/icu/icustays.md index 0752e762..f415a09b 100644 --- a/content/en/docs/mimic-nw/modules/icu/icustays.md +++ b/content/en/docs/mimic-nw/modules/icu/icustays.md @@ -7,7 +7,7 @@ description: > Tracking information for ICU stays including admission and discharge times. --- -Defines each ICU stay in the database using STAY\_ID. +Defines each ICU stay in the database using `stay_id`. **Links to:** @@ -41,7 +41,7 @@ Identifiers which specify the patient: `subject_id` is unique to a patient, `had `first_careunit` and `last_careunit` contain, respectively, the first and last ICU type in which the patient was cared for. -NHMC defintions for first_careunit and last_careunit: +NHMC definitions for `first_careunit` and `last_careunit`: | first_careunit/last_careunit | Full abbreviation (Epic) | |------------------------------------|----------------------------------| @@ -64,7 +64,7 @@ NHMC defintions for first_careunit and last_careunit: | CTU | CARDIAC TELEMETRY UNIT, General Medicine service | | RADIOLOGY | | -Note, the addition of ICU overflow in both BIDMC and NHMC as a `first_careunit` and/or `last_careunit`. In the context of COVID-19, an "ICU overflow" typically refers to a situation in which intensive care units (ICUs) in a hospital or healthcare facility have reached or exceeded their capacity due to a surge in COVID-19 patients requiring critical care. This overflow occurs when the number of patients needing intensive care for COVID-19 exceeds the available ICU beds. +Note, the addition of ICU overflow in both BIDMC and NHMC as a `first_careunit` and/or `last_careunit`. In the context of COVID-19, an 'ICU overflow' typically refers to a situation in which intensive care units (ICUs) in a hospital or healthcare facility have reached or exceeded their capacity due to a surge in COVID-19 patients requiring critical care. This overflow occurs when the number of patients needing intensive care for COVID-19 exceeds the available ICU beds. ### `intime`, `outtime` diff --git a/content/en/docs/mimic-nw/modules/icu/procedureevents.md b/content/en/docs/mimic-nw/modules/icu/procedureevents.md index c197ec7d..a075bd41 100644 --- a/content/en/docs/mimic-nw/modules/icu/procedureevents.md +++ b/content/en/docs/mimic-nw/modules/icu/procedureevents.md @@ -16,7 +16,7 @@ description: > # Important considerations -* In the context of COVID-19, it's important to note that there haven't been any new findings or observations, except for instances where the use of a certain procedured e.g. ventilation has increased. +* In the context of COVID-19, we have observed a higher frequency of certain procedures, such as invasive ventilation. # Table columns @@ -70,20 +70,20 @@ Date and time when the procedure ended. ### `itemid` -Identifier for a single event type in the procedurevents table. Each row associated with one `itemid` (e.g. 225792) corresponds to a type of measurement (e.g. Invasive Ventilation) within '2-Ventilation' `category`. The *d_items* table may be joined on this field. For any itemid appearing in the *procedureevents* table, *d_items* `linksto` column will have the value 'procedureevents'. -Note, in the context of COVID-19, +Identifier for a single event type in the *procedurevents* table. Each row associated with one `itemid` (e.g. 225792) corresponds to a type of measurement (e.g. Invasive Ventilation) and `category` (e.g. 2-Ventilation). The *d_items* table may be joined on this field. For any itemid appearing in the *procedureevents* table, *d_items* `linksto` column will have the value 'procedureevents'. + ## `value` -In the `procedureevents` table, this identifies the duration of the procedure (if applicable). For example, if querying for itemid 225794 (“Non-invasive Ventilation”), then the value column indicates the duration of ventilation therapy. +In the *procedureevents* table, this identifies the duration of the procedure (if applicable). For example, if querying for `itemid` 225794 (Non-invasive Ventilation), then the value column indicates the duration of ventilation therapy. ### `valueuom` -The unit of measurement for the value. Most frequently "None" (no value recorded); otherwise one of "day", "hour", or "min". A query for itemiid 225794 ("Non-invasive Ventilation") returning a `value` of 461 and `valueuom` of 'min' would correspond to non-invasive ventilation provided for 461 minutes; this value is expected to match the difference between the `starttime` and `endtime` fields for the record. A procedure with `valueuom` equal to "None" corresponds to a procedure which is instantaneous (e.g. intubation, patient transfer) or whose duration is not relevant (e.g. imaging procedures). For these records, there will be a difference of one second between `starttime` and `endtime` values. +The unit of measurement for the value. Most frequently 'None' (no value recorded); otherwise one of 'day', 'hour', or 'min'. A query for itemiid 225794 (Non-invasive Ventilation) returning a `value` of 461 and `valueuom` of 'min' would correspond to non-invasive ventilation provided for 461 minutes; this value is expected to match the difference between the `starttime` and `endtime` fields for the record. A procedure with `valueuom` equal to 'None' corresponds to a procedure which is instantaneous (e.g. intubation, patient transfer) or whose duration is not relevant (e.g. imaging procedures). For these records, there will be a difference of one second between `starttime` and `endtime` values. ### `statusdescription` -`statusdescription` states the ultimate status of the procedure referred to in the row. The statuses appearing on the `procedureevents` table are: +`statusdescription` states the ultimate status of the procedure referred to in the row. The statuses appearing on the *procedureevents* table are: * `Paused` - The current delivery has been paused. * `FinishedRunning` - The delivery of the item has finished (most frequently, the bag containing the compound is empty).