diff --git a/content/en/docs/IV/_index.md b/content/en/docs/IV/_index.md index db2f1821..be4bda7a 100644 --- a/content/en/docs/IV/_index.md +++ b/content/en/docs/IV/_index.md @@ -25,6 +25,6 @@ MIMIC-IV is separated into "modules" to reflect the provenance of the data. Ther MIMIC-Note is currently not publicly available and the structure is subject to change. {{% /pageinfo %}} -All patients across all datasets are in `mimic_core`. However, not all ICU patients have ED data, not all ICU patients have CXRs, not all ED patients have hospital data, and so on. Within an individual dataset, there are also incomplete tables as certain electronic systems did not exist in the past. For example, eMAR data is only available from 2015 onward. +All patients across all datasets are in the [hosp](/docs/iv/modules/hosp) module. However, not all ICU patients have ED data, not all ICU patients have CXRs, not all ED patients have hospital data, and so on. Within an individual dataset, there are also incomplete tables as certain electronic systems did not exist in the past, particularly the eMAR system. Tables for each module are detailed in the respective sections. \ No newline at end of file diff --git a/content/en/docs/IV/about/changelog.md b/content/en/docs/IV/about/changelog.md index 54f9a094..59f60458 100644 --- a/content/en/docs/IV/about/changelog.md +++ b/content/en/docs/IV/about/changelog.md @@ -7,9 +7,59 @@ description: > Changes between releases of MIMIC-IV. --- -The latest version of MIMIC-IV is v1.0. +The latest version of MIMIC-IV is v2.1. -This page lists changes implemented in sequential updates to the MIMIC-IV database. Issues are tracked using a unique issue number, usually of the form #100, #101, etc (this issue number relates to a private 'building' repository). +This page lists changes implemented in sequential updates to the MIMIC-IV database. Issues are tracked using a unique issue number, usually of the form #100, #101, etc. Note that some of these issues are only accessible in a private 'building' repository. + +### MIMIC-IV v2.1 + +MIMIC-IV v2.1 was released on November 14, 2022. It removed a subset of subject_id which will be retained internally as a test set. Future data releases will exclude these patients. + +#### Major changes + +* A subset of patients were removed from the dataset. 15,748 subject_id were removed from the patients table. 23,093 hadm_id were removed from the admissions table. 3,762 stay_id were removed from the icustays table. + +### MIMIC-IV v2.0 + +MIMIC-IV v2.0 was released on June 12, 2022. It focused on expanding the data elements available for patients within MIMIC-IV v1.0. Additional data available includes out-of-hospital date of death, information from the online medical record system (which includes height and weight), and more detail for continuous infusions in the ICU. + +#### Major changes + +* The core module has been removed to simplify the schema. The _admissions_, _patients_, and _transfers_ tables are now in the hosp module. +* Neonates have been removed from the dataset. Neonatal data will be released in a separate project with data from the neonatal intensive care unit. + +#### icu module + +* _icustays_ + * Around 700 stays (~1%) have changed due to the changes in the _patients_ table. +* _chartevents, d\_items_ + * The problem list from MetaVision has been added. All problems are documented with the same `itemid` now present in _d\_items_: 220001. There are just over 1,000 unique problems. Most documented problems are related to the care plan for the patient and documented during nurse shift changes (either 7am or 7pm). Less frequently, the ongoing issues are documented here. +* _ingredientevents_ + * This is a new table associated with _inputevents_. Each intravenous administration tracked in _inputevents_ is associated with a set of ingredients. These ingredients include water content, caloric information, and so on. The goal of the _inputevents_ table is to support nutrition research and to provide a mechanism for estimating fluid input via summing all instances of the water ingredient. These ingredients have been separated from the _inputevents_ table to simplify analysis and reduce the size of _inputevents_. +* _inputevents_ + * Removed a single column which contained only null values: `cancelreason`. +* _procedureevents_ + * Removed columns which contained only null values: `totalamount`, `totalamountuom`, `cancelreason`, `comments_editedby`, `comments_canceledby`, `comments_date`, `secondaryordercategoryname`. + +#### hosp module + +* _admissions_ + * Fixed an issue where hospitalizations were missing _edregtime_ and _edouttime_ when the patient was admitted via the ED (reported in [#1247](https://github.com/MIT-LCP/mimic-code/issues/1247), thanks [@MEladawi](https://github.com/MEladawi)). +* _patients_ + * `dod` is now populated with out-of-hospital mortality from state death records. For patients admitted to the ICU, this change has increased capture of date of death from 8,223 records to 23,844 (i.e. we now have out-of-hospital mortality for an additional 15,621 ICU patients). + * The mechanism for determining patients included in MIMIC was changed. For the most part this has resulted in an improvement, particularly regarding the logic for merging patients who had distinct medical record numbers. As a result of this change, most tables have had a change in the data content. Approximately 1% of stays were affected. +* _transfers_ + * Fixed a bug where the `outtime` for ED stays with no associated `hadm_id` (i.e. an ED stay where the individual was not admitted to the hospital) was incorrect. This resulted in all _transfers_ rows with a NULL `hadm_id` having an apparent stay of minutes or less. The `outtime` column has now been corrected. +* _labevents, d\_labitems_ + * The `itemid` for _d\_labitems_ has been changed for 43 items. These are extremely infrequently documented and each `itemid` has fewer than 100 observations in _labevents_. The exact `itemid` are provided in the changelog file CHANGELOG.txt. + * Errors were found in the current values of `loinc_code` (reported in [#938](https://github.com/MIT-LCP/mimic-code/issues/938), thanks [@Mauvila](https://github.com/Mauvila)). In order to enable collaborative improvement, the `loinc_code` column has been removed, and will now be collaboratively developed in the [MIMIC Code Repository](https://github.com/MIT-LCP/mimic-code/). Initial values will be sourced from the hospital system. + * A number of labs which previously had the value in the comments field now have the value in the value field (reported in [#941](https://github.com/MIT-LCP/mimic-code/issues/941), thanks [@Mauvila](https://github.com/Mauvila)). This change makes the _labevents_ table more consistent with MIMIC-III, which had these values in the value field. +* _microbiologyevents_ + * New organisms, tests, specimens, and antibiotics have been added. +* _omr_ + * A new table has been added: _omr._ The source of this data is the Online Medical Record, and it contains miscellaneous information useful for understanding an individual's health. As of v2.0, the _omr_ table has the following information: blood pressure, height, weight, body mass index, and Estimated Glomerular Filtration Rate (eGFR). These values are available from both inpatient and outpatient visits, and in many cases a "baseline" value from before a patient's hospitalization is available. +* _prescriptions_ + * The `formulary_drug_cd` table has been added back (was previously in MIMIC-III). This column has the same set of values as the `product_code` column of emar\_detail. ### MIMIC-IV v1.0 diff --git a/content/en/docs/IV/about/concepts.md b/content/en/docs/IV/about/concepts.md index 01287cc7..459aaecb 100644 --- a/content/en/docs/IV/about/concepts.md +++ b/content/en/docs/IV/about/concepts.md @@ -41,6 +41,7 @@ The *transfers* table contains information for each unique `transfer_id`. `trans ## `stay_id` The *transfers* table also contains the `stay_id`. This is an artificially generated identifier which groups reasonably contiguous episodes of care. +The `stay_id` present in *icustays* is derived from the `stay_id` values in the *transfers* table. # date and times @@ -83,7 +84,7 @@ For events which occur over a period of time, `starttime` and `endtime` provide ### `dod` -`dod` is the patient's date of death sourced from the hospital database. +`dod` is the patient's date of death sourced from one of two sources: the hospital database or a state death database. See the [*patients*](/docs/iv/modules/hosp/patients) documentation for more detail. ### `transfertime` diff --git a/content/en/docs/IV/modules/_index.md b/content/en/docs/IV/modules/_index.md index f05b58da..f1c24665 100644 --- a/content/en/docs/IV/modules/_index.md +++ b/content/en/docs/IV/modules/_index.md @@ -1,8 +1,18 @@ --- -title: "Tables" +title: "Modules" linkTitle: "Modules" weight: 3 date: 2020-08-10 description: > - Description of the data contained in the MIMIC-IV tables. + Description of the data contained in each of the the MIMIC-IV modules. --- + +Data within the modules are available on PhysioNet: + +* hosp, icu: [MIMIC-IV](https://physionet.org/content/mimiciv/) +* ed: [MIMIC-IV-ED](https://physionet.org/content/mimic-iv-ed/) +* note: [MIMIC-IV-Note](https://physionet.org/content/mimic-iv-note/) +* cxr: [MIMIC-CXR](https://physionet.org/content/mimic-cxr/) + +The sections below describe data within each module. + \ No newline at end of file diff --git a/content/en/docs/IV/modules/ed/_index.md b/content/en/docs/IV/modules/ed/_index.md index e4b168b6..437d4db9 100644 --- a/content/en/docs/IV/modules/ed/_index.md +++ b/content/en/docs/IV/modules/ed/_index.md @@ -4,5 +4,5 @@ linkTitle: "ED" date: 2020-08-10 weight: 40 description: > - The ED module contains data for emergency department patients collected while they are in the ED. Information includes reason for admission, triage assessment, vital signs, and medicine reconciliaton. Patient identifiers allow MIMIC-ED to be linked to other MIMIC-IV modules. + The ED module contains data for emergency department patients collected while they are in the ED. Information includes reason for admission, triage assessment, vital signs, and medicine reconciliaton. The `subject_id` and `hadm_id` identifiers allow MIMIC-IV-ED to be linked to other MIMIC-IV modules. --- diff --git a/content/en/docs/IV/modules/ed/diagnosis.md b/content/en/docs/IV/modules/ed/diagnosis.md index b1c087ea..4f78d1b4 100644 --- a/content/en/docs/IV/modules/ed/diagnosis.md +++ b/content/en/docs/IV/modules/ed/diagnosis.md @@ -14,7 +14,7 @@ The *diagnosis* table provides billed diagnoses for patients. Diagnoses are dete **Table purpose:** Track patient admissions to the emergency department. -**Number of rows:** 949,172 +**Number of rows:** 899,050 **Links to:** @@ -29,7 +29,7 @@ Name | Postgres data type `seq_num` | INTEGER NOT NULL `icd_code` | VARCHAR(10) NOT NULL `icd_version` | INTEGER NOT NULL -`icd_title` | VARCHAR(255) NOT NULL +`icd_title` | TEXT NOT NULL ## `subject_id` diff --git a/content/en/docs/IV/modules/ed/edstays.md b/content/en/docs/IV/modules/ed/edstays.md index 233aee25..99010837 100644 --- a/content/en/docs/IV/modules/ed/edstays.md +++ b/content/en/docs/IV/modules/ed/edstays.md @@ -15,7 +15,7 @@ It provides the time the patient entered the emergency department and the time t **Table purpose:** Track patient admissions to the emergency department. -**Number of rows:** 448,972 +**Number of rows:** 425,087 **Links to:** @@ -25,11 +25,16 @@ It provides the time the patient entered the emergency department and the time t Name | Postgres data type ---- | ---- -`subject_id` | INTEGER NOT NULL -`hadm_id` | INTEGER NOT NULL -`stay_id` | INTEGER NOT NULL -`intime` | TIMESTAMP(0) NOT NULL -`outtime` | TIMESTAMP(0) NOT NULL +`subject_id` | INTEGER NOT NULL +`hadm_id` | INTEGER NOT NULL +`stay_id` | INTEGER NOT NULL +`intime` | TIMESTAMP(0) NOT NULL +`outtime` | TIMESTAMP(0) NOT NULL +`gender` | VARCHAR(1) NOT NULL +`race` | VARCHAR(60) +`arrival_transport` | VARCHAR(50) NOT NULL +`disposition` | VARCHAR(255) + ## `subject_id` @@ -48,3 +53,39 @@ An identifier which uniquely identifies a single emergency department stay for a ## `intime`, `outtime` The admission datetime (`intime`) and discharge datetime (`outtime`) of the given emergency department stay. + +## `gender` + +The patient's administrative gender as documented in the hospital system. + +## `race` + +The patient's self-reported race. Race is aggregated into higher level categories for very small groups. +As of MIMIC-IV-ED v2.1, there were 33 unique categories for race. + +## `arrival_transport` + +The method through which the individual arrived at the ED. A count of the possible entries is provided below. + +arrival_transport | count +--- | --- +WALK IN | 251849 +AMBULANCE | 155752 +UNKNOWN | 15352 +OTHER | 1266 +HELICOPTER | 868 + +## `disposition` + +The method through which the individual left the ED. Of the non-null methods, the possibilities include: + +disposition | count +--- | --- +HOME | 241632 +ADMITTED | 158010 +TRANSFER | 7025 +LEFT WITHOUT BEING SEEN | 6155 +OTHER | 4297 +LEFT AGAINST MEDICAL ADVICE | 1881 +ELOPED | 5710 +EXPIRED | 377 \ No newline at end of file diff --git a/content/en/docs/IV/modules/ed/medrecon.md b/content/en/docs/IV/modules/ed/medrecon.md index 27354707..b2c484e9 100644 --- a/content/en/docs/IV/modules/ed/medrecon.md +++ b/content/en/docs/IV/modules/ed/medrecon.md @@ -14,7 +14,7 @@ On admission to the emergency departments, staff will ask the patient what curre **Table purpose:** Document medications a patient is currently taking. -**Number of rows:** 3,147,294 +**Number of rows:** 2,987,342 **Links to:** diff --git a/content/en/docs/IV/modules/ed/pyxis.md b/content/en/docs/IV/modules/ed/pyxis.md index f432e96f..11e28ee0 100644 --- a/content/en/docs/IV/modules/ed/pyxis.md +++ b/content/en/docs/IV/modules/ed/pyxis.md @@ -16,7 +16,7 @@ Note that as the same medication may have multiple `gsn` values, each row does * **Table purpose:** Track medicine administrations. -**Number of rows:** 1,674,652 +**Number of rows:** 1,586,053 **Links to:** @@ -33,7 +33,6 @@ Name | Postgres data type `charttime` | TIMESTAMP(0) `med_rn` | SMALLINT NOT NULL `name` | VARCHAR(255) -`ifu` | VARCHAR(255) `gsn_rn` | SMALLINT NOT NULL `gsn` | VARCHAR(10) diff --git a/content/en/docs/IV/modules/ed/triage.md b/content/en/docs/IV/modules/ed/triage.md index 4d287475..c4a18376 100644 --- a/content/en/docs/IV/modules/ed/triage.md +++ b/content/en/docs/IV/modules/ed/triage.md @@ -16,18 +16,61 @@ All fields in *triage* were originally free-text. For deidentification purposes, **Table source:** Emergency department information system. -**Table purpose:** +**Table purpose:** Store information collected on triage to the emergency department. -**Number of rows:** +**Number of rows:** 425,087 **Links to:** * *edstays* on `stay_id` -# Important considerations - -* There is no time associated with triage observations. The closest approximation to triage time is the `intime` of the patient from the *edstays* table. - +## Important considerations + +There is no time associated with triage observations. The closest approximation to triage time is the `intime` of the patient from the *edstays* table. + +The numeric entries in this table were originally stored as free-text. As a result, the columns required deidentification. Free-text entries which could not be converted trivially were removed. Normally, the application of deidentification in MIMIC-IV is indicated using three underscores (`___`) to make it clear to users that we have modified the data. However, due to the data type restriction, we were unable to do this in this case. As a result, **missing data in the numeric columns indicates either deidentified data or no data recorded**. However, this is usually rare. Below is a table demonstrating how often data were removed for deidentification purposes: + +Column | Number of NULL values inserted for deidentification | Number of rows missing data in v2.1 +--- | --- | --- +`temperature` | 680 | 23415 +`heartrate` | 292 | 17090 +`resprate` | 223 | 20353 +`o2sat` | 414 | 20596 +`sbp` | 238 | 18291 +`dbp` | 214 | 19091 +`acuity` | 0 | 6987 + +From the above, we can see that of the 23415 rows missing a `temperature` value, only 680 had a free-text value which was deleted during deidentification (~3%). + + # Table columns Name | Postgres data type @@ -40,9 +83,9 @@ Name | Postgres data type `o2sat` | NUMERIC(10, 4) `sbp` | NUMERIC(10, 4) `dbp` | NUMERIC(10, 4) -`pain` | NUMERIC(10, 4) +`pain` | TEXT `acuity` | NUMERIC(10, 4) -`chiefcomplaint` | TEXT +`chiefcomplaint` | VARCHAR(255) ## `subject_id` diff --git a/content/en/docs/IV/modules/ed/vitalsign.md b/content/en/docs/IV/modules/ed/vitalsign.md index 4374adfa..615cc2da 100644 --- a/content/en/docs/IV/modules/ed/vitalsign.md +++ b/content/en/docs/IV/modules/ed/vitalsign.md @@ -14,15 +14,56 @@ Patients admitted to the emergency department have routine vital signs taken eve **Table purpose:** Provides nurse documented vital signs. -**Number of rows:** 1,651,119. +**Number of rows:** 1,564,610 **Links to:** * *edstays* on `stay_id` - - -# Table columns +## Important considerations + +The numeric entries in this table were originally stored as free-text. As a result, the columns required deidentification. Free-text entries which could not be converted trivially were removed. Normally, the application of deidentification in MIMIC-IV is indicated using three underscores (`___`) to make it clear to users that we have modified the data. We decided it was better to omit this modification than to add confusion and difficulty to users by sharing the majority numeric data as text. As a result, **missing data in the numeric columns indicates either deidentified data or no data recorded**. However, for the most part, missing data indicates that no information was documented. Below is a table demonstrating how often data were removed for deidentification purposes: + +Column | Number of NULL values inserted for deidentification | Number of rows missing data in v2.1 +--- | --- | --- +`temperature` | 11048 | 564968 +`heartrate` | 3282 | 69710 +`resprate` | 1330 | 89393 +`o2sat` | 46620 | 135836 +`sbp` | 2854 | 81256 +`dbp` | 2854 | 81256 + +From the above, we can see that of the 564968 rows missing a `temperature` value, 11048 had a free-text value which was deleted during deidentification (~2%). + + + +## Table columns Name | Postgres data type ---- | ---- diff --git a/content/en/docs/IV/modules/ed/vitalsign_hl7.md b/content/en/docs/IV/modules/ed/vitalsign_hl7.md deleted file mode 100644 index 3c024d2a..00000000 --- a/content/en/docs/IV/modules/ed/vitalsign_hl7.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: "vitalsign_hl7 table" -date: 2020-08-10 -weight: 1 -description: > - vitalsign_hl7 table ---- - -# The *vitalsign_hl7* table - -**This table is not yet populated.** - -Patients admitted to the emergency department may be monitored by telemetry. -Minute-by-minute vital signs for telemetry are communicated to a central server in the hospital, and these vital signs are recorded here. -However, vital signs are only communicated with patient identifiers manually input into the bedside monitors, a process which is not routine practice. -As a result, many patients who are monitored by telemetry do not have their vital signs recorded in this table. - -**Table source:** Emergency department information system. - -**Table purpose:** Continuous vital signs for monitored patients. - -**Number of rows:** 0. - -**Links to:** - -* *edstays* on `stay_id` - - - -# Table columns - -Name | Postgres data type ----- | ---- -`subject_id` | INTEGER NOT NULL -`stay_id` | INTEGER NOT NULL -`charttime` | TIMESTAMP(0) NOT NULL -`hr` | INTEGER -`resp` | INTEGER -`spo2` | INTEGER -`pulse` | INTEGER -`nbp_d` | INTEGER -`nbp_m` | INTEGER -`nbp_s` | INTEGER - -## `subject_id` - -`subject_id` is a unique identifier which specifies an individual patient. Any rows associated with a single `subject_id` pertain to the same individual. - -## `stay_id` - -An identifier which uniquely identifies a single emergency department stay for a single patient. - -## `charttime` - -The date and time that the set of vital signs were recorded. - -## `hr` - -The patient's heart rate. - -## `resp` - -The patient's respiratory rate. - -## `spo2` - -The patient's peripheral oxygen saturation. - -## `pulse` - -The patient's heart rate derived from a photoplethysmogram. - -## `nbp_d`, `nbp_m`, `nbp_s` - -The patient's diastolic (d), mean (m), and systolic (s) blood pressure. The `n` indicates that the measurement was made non-invasively (i.e. with a blood pressure cuff). \ No newline at end of file diff --git a/content/en/docs/IV/modules/hosp/_index.md b/content/en/docs/IV/modules/hosp/_index.md index 16c800d5..cc7f9f41 100644 --- a/content/en/docs/IV/modules/hosp/_index.md +++ b/content/en/docs/IV/modules/hosp/_index.md @@ -8,4 +8,4 @@ description: > --- 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,transfers), laboratory measurements (labevents, d_labitems), microbiology cultures (microbiologyevents), provider orders (poe, poe_detail), medication administration (emar, emar_detail), medication prescription (prescriptions, pharmacy), hospital billing information (diagnoses_icd, d_icd_diagnoses, procedures_icd, d_icd_procedures, hcpcsevents, d_hcpcs, drgcodes), and service related information (services). +Information includes patient and admission details (patients, admissions, transfers), laboratory measurements (labevents, d_labitems), microbiology cultures (microbiologyevents), provider orders (poe, poe_detail), medication administration (emar, emar_detail), medication prescription (prescriptions, pharmacy), hospital billing information (diagnoses_icd, d_icd_diagnoses, procedures_icd, d_icd_procedures, hcpcsevents, d_hcpcs, drgcodes), and hospital service related information (services). diff --git a/content/en/docs/IV/modules/hosp/admissions.md b/content/en/docs/IV/modules/hosp/admissions.md index 9902d06d..a1af8b44 100644 --- a/content/en/docs/IV/modules/hosp/admissions.md +++ b/content/en/docs/IV/modules/hosp/admissions.md @@ -61,6 +61,7 @@ Each row of this table contains a unique `hadm_id`, which represents a single pa Similarly, `discharge_location` is the disposition of the patient after they are discharged from the hospital. #### Association with UB-04 billing codes + `admission_location` and `discharge_location` are associated with internal hospital `ibax` codes which aren't provided in MIMIC-IV. These internal codes tend to align with UB-04 billing codes. In some cases more than one internal code is associated with a given `admission_location` and `discharge_location`. This can either be do to; 1) multiple codes being used by the hospital for the same `admission_location` or `discharge_location`, or 2) during de-identification multiple internal codes may be combined into a single `admission_location` or `discharge_location`. diff --git a/content/en/docs/IV/modules/hosp/d_icd_diagnoses.md b/content/en/docs/IV/modules/hosp/d_icd_diagnoses.md index a4ffbc40..8ce221e5 100644 --- a/content/en/docs/IV/modules/hosp/d_icd_diagnoses.md +++ b/content/en/docs/IV/modules/hosp/d_icd_diagnoses.md @@ -14,7 +14,7 @@ This table defines International Classification of Diseases (ICD) Version 9 and ### Links to -* *diagnoses_icd* ON `icd_code` +* *diagnoses_icd* ON `icd_code` and `icd_version` diff --git a/content/en/docs/IV/modules/hosp/d_icd_procedures.md b/content/en/docs/IV/modules/hosp/d_icd_procedures.md index ab492a96..70898eca 100644 --- a/content/en/docs/IV/modules/hosp/d_icd_procedures.md +++ b/content/en/docs/IV/modules/hosp/d_icd_procedures.md @@ -13,7 +13,7 @@ This table defines International Classification of Diseases (ICD) codes for **pr ### Links to -* *procedures_icd* on `icd_code` +* *procedures_icd* on `icd_code` and `icd_version` ## Brief summary diff --git a/content/en/docs/IV/modules/hosp/d_labitems.md b/content/en/docs/IV/modules/hosp/d_labitems.md index 4722e379..fb1ea8bf 100644 --- a/content/en/docs/IV/modules/hosp/d_labitems.md +++ b/content/en/docs/IV/modules/hosp/d_labitems.md @@ -4,23 +4,22 @@ linktitle: "d_labitems" weight: 1 date: 2020-08-10 description: > - Dimension table for *labevents*; provides a description of all lab items. + Dimension table for *labevents* provides a description of all lab items. --- ## *d_labitems* -*d_labitems* contains definitions for all `itemid` associated with lab measurements in the MIMIC database. All data in LABEVENTS link to the *d_labitems* table. Each unique (`fluid`, `category`, `label`) tuple in the hospital database was assigned an `itemid` in this table, and the use of this `itemid` facilitates efficient storage and querying of the data. +*d_labitems* contains definitions for all `itemid` associated with lab measurements in the MIMIC database. All data in *labevents* link to the *d_labitems* table. Each unique (`fluid`, `category`, `label`) tuple in the hospital database was assigned an `itemid` in this table, and the use of this `itemid` facilitates efficient storage and querying of the data. Laboratory data contains information collected and recorded in the hospital laboratory database. This includes measurements made in wards within the hospital and clinics outside the hospital. Most concepts in this table have been mapped to LOINC codes, an openly available ontology which facilitates interoperability. ### Links to -* LABEVENTS on `itemid` +* *labevents* on `itemid` ## Important considerations -* Many of the LOINC codes were assigned during a project to standardize the ontology of lab measurements in the MIMIC database. Consequently, the codes were assigned post-hoc, may not be perfect, and may not be present for every lab measurement. -We welcome improvements to the present codes or assignment of LOINC codes to unmapped data elements from the community. +This table used to contain a column called `loinc_code`, which store standardized identifiers for laboratory measurements. To support ongoing improvement of these labels, the assignment of LOINC codes is now done in the [MIMIC Code Repository](https://www.github.com/MIT-LCP/mimic-code). ## Table columns @@ -30,13 +29,12 @@ Name | Postgres data type `label` | VARCHAR(50) `fluid` | VARCHAR(50) `category` | VARCHAR(50) -`loinc_code` | VARCHAR(50) ## Detailed Description ### `itemid` -A unique identifier for a laboratory concept. `itemid` is unique to each row, and can be used to identify data in LABEVENTS associated with a specific concept. +A unique identifier for a laboratory concept. `itemid` is unique to each row, and can be used to identify data in labevents associated with a specific concept. ### `label` @@ -49,7 +47,3 @@ The `label` column describes the concept which is represented by the `itemid`. ### `category` `category` provides higher level information as to the type of measurement. For example, a category of 'ABG' indicates that the measurement is an arterial blood gas. - -### `loinc_code` - -`loinc_code` contains the LOINC code associated with the given `itemid`. LOINC is an ontology which originally specified laboratory measurements but has since expanded to cover a wide range of clinically relevant concepts. LOINC openly provide a table which contains a large amount of detail about each LOINC code. This table is freely available online. diff --git a/content/en/docs/IV/modules/hosp/diagnoses_icd.md b/content/en/docs/IV/modules/hosp/diagnoses_icd.md index 0b132ce5..da3200b5 100644 --- a/content/en/docs/IV/modules/hosp/diagnoses_icd.md +++ b/content/en/docs/IV/modules/hosp/diagnoses_icd.md @@ -13,6 +13,10 @@ During routine hospital care, patients are billed by the *hospital* for diagnose This table contains a record of all diagnoses a patient was billed for during their hospital stay using the ICD-9 and ICD-10 ontologies. Diagnoses are billed on hospital discharge, and are determined by trained persons who read signed clinical notes. +### Links to + +* *d_icd_diagnoses* ON `icd_code` and `icd_version` + ## Table columns Name | Postgres data type @@ -20,7 +24,7 @@ Name | Postgres data type `subject_id` | INTEGER `hadm_id` | INTEGER `seq_num` | INTEGER -`icd_code` | CHAR(7) +`icd_code` | VARCHAR(7) `icd_version` | INTEGER ## Detailed Description diff --git a/content/en/docs/IV/modules/hosp/emar_detail.md b/content/en/docs/IV/modules/hosp/emar_detail.md index 42e23ea8..df0dd080 100644 --- a/content/en/docs/IV/modules/hosp/emar_detail.md +++ b/content/en/docs/IV/modules/hosp/emar_detail.md @@ -17,15 +17,10 @@ Information includes the associated pharmacy order, the dose due, the dose given * *emar* on `emar_id` * *pharmacy* on `pharmacy_id` - - - ## Important considerations * The eMAR system was implemented during 2011-2013. As a result, eMAR data is not available for all patients. - - ## Table columns Name | Postgres data type diff --git a/content/en/docs/IV/modules/hosp/labevents.md b/content/en/docs/IV/modules/hosp/labevents.md index 3baa1824..e427ba29 100644 --- a/content/en/docs/IV/modules/hosp/labevents.md +++ b/content/en/docs/IV/modules/hosp/labevents.md @@ -16,10 +16,28 @@ These include hematology measurements, blood gases, chemistry panels, and less c * *d_labitems* on `itemid` - ## Table columns diff --git a/content/en/docs/IV/modules/hosp/microbiologyevents.md b/content/en/docs/IV/modules/hosp/microbiologyevents.md index e0a8b044..30a44de4 100644 --- a/content/en/docs/IV/modules/hosp/microbiologyevents.md +++ b/content/en/docs/IV/modules/hosp/microbiologyevents.md @@ -20,12 +20,27 @@ Bacteria will be cultured on the blood sample, and the remaining columns depend * If bacteria is found, then each organism of bacteria will be present in `org_name`, resulting in multiple rows for the single specimen (i.e. multiple rows for the given `spec_type_desc`). * If antibiotics are tested on a given bacterial organism, then each antibiotic tested will be present in the `ab_name` column (i.e. multiple rows for the given `org_name` associated with the given `spec_type_desc`). Antibiotic parameters and sensitivities are present in the remaining columns (`dilution_text`, `dilution_comparison`, `dilution_value`, `interpretation`). +## Important considerations + +Typically, negative values are indicated by a NULL value. However, `itemid` 90856 has a value of "NEGATIVE", and should be included in queries which seek to segregate microbiology data based on positive/negative findings. + +`hadm_id` is assigned to observations using the administrative transfer table. However this does not always perfectly capture labs around the hospital stay. +To be specific, as of v2.1, it is possible to assign 1,449,547 observations with an `hadm_id` using a join to *admissions* with `subject_id`, `admittime`, and `dischtime`. However, only 1,396,224 (96%) of these observations have an `hadm_id` actually stored in the *microbiologyevents* table. Users wishing to ensure capture of labs proximal to hospital stays should be aware of this, and use joins with time as necessary. + - ## Table columns Name | Postgres data type | Example value diff --git a/content/en/docs/IV/modules/hosp/patients.md b/content/en/docs/IV/modules/hosp/patients.md index 391a8aeb..9a54d2d0 100644 --- a/content/en/docs/IV/modules/hosp/patients.md +++ b/content/en/docs/IV/modules/hosp/patients.md @@ -44,4 +44,8 @@ These columns provide information regarding the actual patient year for the pati ### `dod` -The de-identified date of death for the patient. Date of death is extracted from the hospital information system only. **Out-of-hospital mortality is currently unavailable as of MIMIC-IV v1.0**. +The de-identified date of death for the patient. Date of death is extracted from two sources: the hospital information system and the [Massachusetts State Registry of Vital Records and Statistics](https://www.mass.gov/orgs/registry-of-vital-records-and-statistics). +Individual patient records from MIMIC were matched to the vital records using a custom algorithm based on identifiers including name, social security number, and date of birth. + +As a result of the linkage, out of hospital mortality is available for MIMIC-IV patients up to **one year post-hospital discharge**. All patient deaths occurring more than one year after hospital discharge are censored. +Survival studies should incorporate this into their design. \ No newline at end of file diff --git a/content/en/docs/IV/modules/hosp/prescriptions.md b/content/en/docs/IV/modules/hosp/prescriptions.md index 3b509b23..5652ebaa 100644 --- a/content/en/docs/IV/modules/hosp/prescriptions.md +++ b/content/en/docs/IV/modules/hosp/prescriptions.md @@ -29,10 +29,13 @@ Name | Postgres data type `subject_id` | INTEGER NOT NULL `hadm_id` | INTEGER NOT NULL `pharmacy_id` | INTEGER +`poe_id` | VARCHAR(25) +`poe_seq` | INTEGER `starttime` | TIMESTAMP `stoptime` | TIMESTAMP `drug_type` | VARCHAR(20) NOT NULL `drug` | VARCHAR(255) NOT NULL +`formulary_drug_cd` | VARCHAR(50) `gsn` | VARCHAR(10) `ndc` | VARCHAR(20) `prod_strength` | VARCHAR(255) @@ -68,6 +71,10 @@ The component of the prescription which the drug occupies. Can be one of 'MAIN', A free-text description of the medication administered. +### `formulary_drug_cd` + +A hospital specific ontology used to order drugs from the formulary. + ### `gsn` The Generic Sequence Number (GSN), a coded identifier used for medications. diff --git a/content/en/docs/IV/modules/hosp/procedures_icd.md b/content/en/docs/IV/modules/hosp/procedures_icd.md index 80bb13f1..84aac0c2 100644 --- a/content/en/docs/IV/modules/hosp/procedures_icd.md +++ b/content/en/docs/IV/modules/hosp/procedures_icd.md @@ -12,6 +12,10 @@ description: > During routine hospital care, patients are billed by the *hospital* for procedures they undergo. This table contains a record of all procedures a patient was billed for during their hospital stay using the ICD-9 and ICD-10 ontologies. +### Links to + +* *d_icd_procedures* on `icd_code` and `icd_version` + ## Important considerations - Procedures during the hospital stay can be billed (1) by the hospital or (2) by the provider. This table contains only procedures billed by the hospital. @@ -24,7 +28,7 @@ Name | Postgres data type `hadm_id` | INTEGER NOT NULL `seq_num` | INTEGER NOT NULL `chartdate` | DATE NOT NULL -`icd_code` | CHAR(7) +`icd_code` | VARCHAR(7) `icd_version` | INTEGER ### `subject_id` @@ -37,11 +41,11 @@ Name | Postgres data type ## `seq_num` -The order in which the procedures occurred within the hospital stay. +An assigned priority for procedures which occurred within the hospital stay. ## `chartdate` -The date of the associated procedures. +The date of the associated procedures. Date does *not* strictly correlate with `seq_num`. ### `icd_code`, `icd_version` diff --git a/content/en/docs/IV/modules/icu/_index.md b/content/en/docs/IV/modules/icu/_index.md index 10d3e0bc..de95c5c8 100644 --- a/content/en/docs/IV/modules/icu/_index.md +++ b/content/en/docs/IV/modules/icu/_index.md @@ -7,4 +7,4 @@ description: > The ICU module contains information collected from the clinical information system used within the ICU. Documented data includes intravenous administrations, ventilator settings, and other charted items. --- -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 intravenous and fluid inputs (inputevents), patient outputs (outputevents), procedures (procedureevents), information documented as a date or time (datetimeevents), and other charted information (chartevents). 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. +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 intravenous and fluid inputs (inputevents), ingredients of the aforementioned inputs (ingredientevents), patient outputs (outputevents), procedures (procedureevents), information documented as a date or time (datetimeevents), and other charted information (chartevents). 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. diff --git a/content/en/docs/IV/modules/icu/chartevents.md b/content/en/docs/IV/modules/icu/chartevents.md index 04c43794..1194e59c 100644 --- a/content/en/docs/IV/modules/icu/chartevents.md +++ b/content/en/docs/IV/modules/icu/chartevents.md @@ -15,7 +15,7 @@ description: > **Table purpose:** Contains all charted data for all patients. -**Number of rows:** 264,885,089 +**Number of rows:** 313,645,063 **Links to:** @@ -34,18 +34,18 @@ description: > # Table columns -Name | Data type +Name | Postgres Data type ---- | -------- -subject\_id | Integer -hadm\_id | Integer -stay\_id | Integer -charttime | Date with times -storetime | Date with times -itemid | Integer -value | Text -valuenum | Decimal number -valueuom | Text -warning | Binary (0 or 1) +subject\_id | INTEGER +hadm\_id | INTEGER +stay\_id | INTEGER +charttime | TIMESTAMP(0) +storetime | TIMESTAMP(0) +itemid | INTEGER +value | VARCHAR(200) +valuenum | DOUBLE PRECISION +valueuom | VARCHAR(20) +warning | SMALLINT ## `subject_id`, `hadm_id`, `stay_id` diff --git a/content/en/docs/IV/modules/icu/d_items.md b/content/en/docs/IV/modules/icu/d_items.md index f8f4df1d..261c6d66 100644 --- a/content/en/docs/IV/modules/icu/d_items.md +++ b/content/en/docs/IV/modules/icu/d_items.md @@ -14,7 +14,7 @@ description: > **Table purpose:** Definition table for all items in the ICU databases. -**Number of rows:** 3,816 +**Number of rows:** 4,014 **Links to:** @@ -26,13 +26,12 @@ description: > # Important considerations -* If the `LINKSTO` column is null, then the data is currently unavailable, but planned for a future release. +* If the `linksto` column is null, then the data is currently unavailable, but planned for a future release. # Table columns Name | Postgres data type ---- | ---- -<<<<<<< HEAD itemid | INTEGER label | VARCHAR(200) abbreviation | VARCHAR(100) diff --git a/content/en/docs/IV/modules/icu/datetimesevents.md b/content/en/docs/IV/modules/icu/datetimesevents.md index ed3f2977..5e2a6d2e 100644 --- a/content/en/docs/IV/modules/icu/datetimesevents.md +++ b/content/en/docs/IV/modules/icu/datetimesevents.md @@ -14,13 +14,13 @@ description: > **Table purpose:** Contains all date formatted data. -**Number of rows:** 5,988,217 +**Number of rows:** 7,112,999 **Links to:** * patients on `subject_id` * admissions on `hadm_id` -* icustays on `STAY_ID` +* icustays on `stay_id` * d_items on `itemid` @@ -28,21 +28,21 @@ description: > # Table columns -Name | Data type +Name | Postgres Data type ---- | -------- -subject\_id | Integer -hadm\_id | Integer -stay\_id | Integer -charttime | Date with times -storetime | Date with times -itemid | Integer -value | Date with times -valueuom | Text -warning | Binary (0 or 1) +subject\_id | INTEGER +hadm\_id | INTEGER +stay\_id | INTEGER +charttime | TIMESTAMP(3) +storetime | TIMESTAMP(3) +itemid | INTEGER +value | TIMESTAMP(3) +valueuom | VARCHAR(20) +warning | SMALLINT # Detailed Description -DATETIMEEVENTS contains all date measurements about a patient in the ICU. For example, the date of last dialysis would be in the DATETIMEEVENTS table, but the systolic blood pressure would not be in this table. As all dates in MIMIC are anonymized to protect patient confidentiality, all dates in this table have been shifted. Note that the chronology for an individual patient has been unaffected however, and quantities such as the difference between two dates remain true to reality. +*datetimeevents* contains all date measurements about a patient in the ICU. For example, the date of last dialysis would be in the *datetimeevents* table, but the systolic blood pressure would not be in this table. As all dates in MIMIC are anonymized to protect patient confidentiality, all dates in this table have been shifted. Note that the chronology for an individual patient has been unaffected however, and quantities such as the difference between two dates remain true to reality. ## `subject_id`, `hadm_id`, `stay_id` @@ -55,22 +55,22 @@ Identifiers which specify the patient: `subject_id` is unique to a patient, `had --> -## `CHARTTIME`, `STORETIME` +## `charttime`, `storetime` -`CHARTTIME` records the time at which an observation was charted, and is usually the closest proxy to the time the data was actually measured. `STORETIME` records the time at which an observation was manually input or manually validated by a member of the clinical staff. +`charttime` records the time at which an observation was charted, and is usually the closest proxy to the time the data was actually measured. `storetime` records the time at which an observation was manually input or manually validated by a member of the clinical staff. -## `ITEMID` +## `itemid` -Identifier for a single measurement type in the database. Each row associated with one `ITEMID` (e.g. 212) corresponds to an instantiation of the same measurement (e.g. heart rate). +Identifier for a single measurement type in the database. Each row associated with one `itemid` (e.g. 212) corresponds to an instantiation of the same measurement (e.g. heart rate). -## `VALUE` +## `value` The documented date - this is the value that corresponds to the concept referred to by `itemid`. For example, if querying for `itemid`: 225755 ("18 Gauge Insertion Date"), then the `value` column indicates the date the line was inserted. -## `VALUEUOM` +## `valueuom` The unit of measurement for the value - almost always the text string "Date". -## `WARNING` +## `warning` -`WARNING` specifies if a warning for this observation was manually documented by the care provider. \ No newline at end of file +`warning` specifies if a warning for this observation was manually documented by the care provider. \ No newline at end of file diff --git a/content/en/docs/IV/modules/icu/icustays.md b/content/en/docs/IV/modules/icu/icustays.md index c507e908..aee3990b 100644 --- a/content/en/docs/IV/modules/icu/icustays.md +++ b/content/en/docs/IV/modules/icu/icustays.md @@ -14,7 +14,7 @@ description: > **Table purpose:** Defines each ICU stay in the database using STAY\_ID. -**Number of rows:** 76,540 +**Number of rows:** 73,181 **Links to:** diff --git a/content/en/docs/IV/modules/icu/ingredientevents.md b/content/en/docs/IV/modules/icu/ingredientevents.md new file mode 100644 index 00000000..e8c96b08 --- /dev/null +++ b/content/en/docs/IV/modules/icu/ingredientevents.md @@ -0,0 +1,108 @@ +--- +date: "2022-06-12T00:00:00-04:00" +title: "Ingredientevents" +linktitle: "Ingredientevents" +weight: 10 +date: 2020-08-10 +description: > + Ingredients of continuous or intermittent administrations including nutritional and water content. +--- + +# The *inputevents* table + +**Table source:** MetaVision ICU database. + +**Table purpose:** Ingredients contained within inputs data for patients. + +**Number of rows:** 12,229,408 + +**Links to:** + +* patients on `subject_id` +* admissions on `hadm_id` +* icustays on `stay_id` +* d_items on `itemid` + +# Important considerations + +* In the source data, there is no concept of a volume in the database: only a `rate`. All rows are recorded with a `starttime` and an `endtime`. The `amount` in this table is *derived* from the `rate` column, and provided for convenience. An exception is bolus administrations: these are listed as ending one minute after they started, i.e. `endtime`: `starttime` + 1 minute, and they do not have a `rate`. + +# Table columns + +Name | Postgres data type +---- | ---- +subject\_id | INTEGER +hadm\_id | INTEGER +stay\_id | INTEGER +starttime | TIMESTAMP(0) +endtime | TIMESTAMP(0) +storetime | TIMESTAMP(0) +itemid | INTEGER +amount | DOUBLE PRECISION +amountuom | VARCHAR(20) +rate | DOUBLE PRECISION +rateuom | VARCHAR(20) +orderid | INTEGER +linkorderid | INTEGER +statusdescription | VARCHAR(20) +originalamount | DOUBLE PRECISION +originalrate | DOUBLE PRECISION + +# Detailed Description + +## `subject_id`, `hadm_id`, `stay_id` + +Identifiers which specify the patient: `subject_id` is unique to a patient, `hadm_id` is unique to a patient hospital stay and `stay_id` is unique to a patient ICU stay. + + + +## `starttime`, `endtime` + +`starttime` and `endtime` record the start and end time of the event. + +## `storetime` + +`storetime` records the time at which an observation was manually input or manually validated by a member of the clinical staff. + +## `itemid` + +Identifier for a single measurement type in the database. Each row associated with one `itemid` which corresponds to an instantiation of the same measurement (e.g. norepinephrine). + +## `amount`, `amountuom` + +`amount` and `amountuom` list the amount of a drug or substance administered to the patient either between the `starttime` and `endtime`. + +## `rate`, `rateuom` + +`rate` and `rateuom` list the rate at which the drug or substance was administered to the patient either between the `starttime` and `endtime`. + +## `orderid`, `linkorderid` + +`orderid` links multiple items contained in the same solution together. For example, when a solution of noradrenaline and normal saline is administered both noradrenaline and normal saline occur on distinct rows but will have the same `orderid`. + +`linkorderid` links the same order across multiple instantiations: for example, if the rate of delivery for the solution with noradrenaline and normal saline is changed, two new rows which share the same new `orderid` will be generated, but the `linkorderid` will be the same. + +## `statusdescription` + +`statusdescription` states the ultimate status of the item, or more specifically, row. It is used to indicate why the delivery of the compound has ended. There are only six possible statuses: + +* Changed - The current delivery has ended as some aspect of it has changed (most frequently, the rate has been changed) +* Paused - The current delivery has been paused +* FinishedRunning - The delivery of the item has finished (most frequently, the bag containing the compound is empty) +* Stopped - The delivery of the item been terminated by the caregiver +* Rewritten - Incorrect information was input, and so the information in this row was rewritten (these rows are primarily useful for auditing purposes - the rates/amounts described were *not* delivered and so should not be used if determining what compounds a patient has received) +* Flushed - A line was flushed. + +## `originalamount` + +Drugs are usually mixed within a solution and delivered continuously from the same bag. This column represents the amount of the compound contained in the bag at `starttime`. + +## `originalrate` + +This is the rate that was input by the care provider. Note that this may differ from `rate` because of various reasons: `originalrate` was the original planned rate, while the `rate` column will be the true rate delivered. \ No newline at end of file diff --git a/content/en/docs/IV/modules/icu/inputevents.md b/content/en/docs/IV/modules/icu/inputevents.md index 34615618..092c94a3 100644 --- a/content/en/docs/IV/modules/icu/inputevents.md +++ b/content/en/docs/IV/modules/icu/inputevents.md @@ -14,7 +14,7 @@ description: > **Table purpose:** Input data for patients. -**Number of rows:** 7,643,978 +**Number of rows:** 8,978,893 **Links to:** @@ -25,41 +25,39 @@ description: > # Brief example -The original source database recorded input data using two tables: RANGESIGNALS and ORDERENTRY. These tables do not appear in MIMIC as they have been merged to form the INPUTEVENTS table. RANGESIGNALS contains recorded data elements which last for a fixed period of time. Furthermore, the RANGESIGNALS table recorded information for each component of the drug separately. For example, for a norepinephrine administration there would be two components: a main order component (norepinephrine) and a solution component (NaCl). The `STARTTIME` and `ENDTIME` of RANGESIGNALS indicated when the drug started and finished. *Any* change in the drug rate would result in the current infusion ending, and a new `STARTTIME` being created. +The original source database recorded input data using two tables: RANGESIGNALS and ORDERENTRY. These tables do not appear in MIMIC as they have been merged to form the INPUTEVENTS table. RANGESIGNALS contains recorded data elements which last for a fixed period of time. Furthermore, the RANGESIGNALS table recorded information for each component of the drug separately. For example, for a norepinephrine administration there would be two components: a main order component (norepinephrine) and a solution component (NaCl). The `starttime` and `endtime` of RANGESIGNALS indicated when the drug started and finished. *Any* change in the drug rate would result in the current infusion ending, and a new `starttime` being created. Let's examine an example of a patient being given norepinephrine. -Item | `STARTTIME` | `ENDTIME` | `RATE` | `RATEUOM` | `ORDERID` | `LINKORDERID` +Item | `starttime` | `endtime` | `rate` | `rateuom` | `orderid` | `linkorderid` ---- | ---- | ---- | ---- | ---- | ---- | ---- Norepinephrine | 18:20 | 18:25 | 1 | mcg/kg/min | 8003 | 8003 NaCl | 18:20 | 18:25 | 10 | ml/hr | 8003 | 8003 Norepinephrine | 18:25 | 20:00 | 2 | mcg/kg/min | 8020 | 8003 NaCl | 18:25 | 20:00 | 20 | ml/hr | 8020 | 8003 -The `STARTTIME` for the solution (NaCl) and the drug (norepinephrine) would be 18:20. The rate of the drug is 1 mcg/kg/min, and the rate of the solution is 10 mL/hr. The nurse decides to increase the drug rate at 18:25 to 2 mcg/kg/min. As a result, the `ENDTIME` for the two rows corresponding to the solution (NaCl and norepinephrine) is set to 18:25. Two new rows are generated with a `STARTTIME` of 18:25. These two new rows would continue until either (i) the drug rate was changed or (ii) the drug was delivery was discontinued. The `ORDERID` column is used to group drug delivery with rate of delivery. In this case, we have NaCl and norepinephrine in the same bag delivered at the same time - as a result their `ORDERID` is the same (8003). When the rate is changed, a new `ORDERID` is generated (8020). The column `LINKORDERID` can be used to link this drug across all administrations, even when the rate is changed. Note also that `LINKORDERID` is always equal to the first `ORDERID` which occurs for the solution, as demonstrated in the example above. +The `starttime` for the solution (NaCl) and the drug (norepinephrine) would be 18:20. The rate of the drug is 1 mcg/kg/min, and the rate of the solution is 10 mL/hr. The nurse decides to increase the drug rate at 18:25 to 2 mcg/kg/min. As a result, the `endtime` for the two rows corresponding to the solution (NaCl and norepinephrine) is set to 18:25. Two new rows are generated with a `starttime` of 18:25. These two new rows would continue until either (i) the drug rate was changed or (ii) the drug was delivery was discontinued. The `orderid` column is used to group drug delivery with rate of delivery. In this case, we have NaCl and norepinephrine in the same bag delivered at the same time - as a result their `orderid` is the same (8003). When the rate is changed, a new `orderid` is generated (8020). The column `linkorderid` can be used to link this drug across all administrations, even when the rate is changed. Note also that `linkorderid` is always equal to the first `orderid` which occurs for the solution, as demonstrated in the example above. # Important considerations -* For Metavision data, there is no concept of a volume in the database: only a `RATE`. All inputs are recorded with a `STARTTIME` and an `ENDTIME`. As a result, the volumes in the database for Metavision patients are *derived* from the rates. Furthermore, exact start and stop times for the drugs are easily deducible. -* A bolus will be listed as ending one minute after it started, i.e. `ENDTIME`: `STARTTIME` + 1 minute +* For Metavision data, there is no concept of a volume in the database: only a `rate`. All inputs are recorded with a `starttime` and an `endtime`. As a result, the volumes in the database for Metavision patients are *derived* from the rates. Furthermore, exact start and stop times for the drugs are easily deducible. +* A bolus will be listed as ending one minute after it started, i.e. `endtime`: `starttime` + 1 minute # Table columns Name | Postgres data type ---- | ---- -row\_id | INT subject\_id | INT hadm\_id | INT -icustay\_id | INT +stay\_id | INT starttime | TIMESTAMP(0) endtime | TIMESTAMP(0) +storetime | TIMESTAMP(0) itemid | INT amount | DOUBLE PRECISION amountuom | VARCHAR(30) rate | DOUBLE PRECISION rateuom | VARCHAR(30) -storetime | TIMESTAMP(0) -cgid | BIGINT orderid | BIGINT linkorderid | BIGINT ordercategoryname | VARCHAR(100) @@ -69,13 +67,8 @@ ordercategorydescription | VARCHAR(50) patientweight | DOUBLE PRECISION totalamount | DOUBLE PRECISION totalamountuom | VARCHAR(50) -isopenbag | SMALLINT -continueinnextdept | SMALLINT -cancelreason | SMALLINT +`isopenbag` | SMALLINT statusdescription | VARCHAR(30) -comments\_status | VARCHAR(30) -comments\_title | VARCHAR(100) -comments\_date | TIMESTAMP(0) originalamount | DOUBLE PRECISION originalrate | DOUBLE PRECISION @@ -93,77 +86,67 @@ Identifiers which specify the patient: `subject_id` is unique to a patient, `had --> -## `STARTTIME`, `ENDTIME` +## `starttime`, `endtime` -`STARTTIME` and `ENDTIME` record the start and end time of an input/output event. +`starttime` and `endtime` record the start and end time of an input/output event. -## ITEMID +## `storetime` -Identifier for a single measurement type in the database. Each row associated with one `ITEMID` which corresponds to an instantiation of the same measurement (e.g. norepinephrine). -MetaVision `ITEMID` values are all above 220000. Since this data only contains data from MetaVision, it only contains `ITEMID` above 220000 (see [here](/docs/about/sources/metavision/) for details about MetaVision) +`storetime` records the time at which an observation was manually input or manually validated by a member of the clinical staff. -## AMOUNT, AMOUNTUOM +## `itemid` -`AMOUNT` and `AMOUNTUOM` list the amount of a drug or substance administered to the patient either between the `STARTTIME` and `ENDTIME`. +Identifier for a single measurement type in the database. Each row associated with one `itemid` which corresponds to an instantiation of the same measurement (e.g. norepinephrine). -## RATE, RATEUOM +## `amount`, `amountuom` -`RATE` and `RATEUOM` list the rate at which the drug or substance was administered to the patient either between the `STARTTIME` and `ENDTIME`. +`amount` and `amountuom` list the amount of a drug or substance administered to the patient either between the `starttime` and `endtime`. -## STORETIME +## rate, rateuom -`STORETIME` records the time at which an observation was manually input or manually validated by a member of the clinical staff. +`rate` and `rateuom` list the rate at which the drug or substance was administered to the patient either between the `starttime` and `endtime`. -## ORDERID, LINKORDERID +## orderid, linkorderid -`ORDERID` links multiple items contained in the same solution together. For example, when a solution of noradrenaline and normal saline is administered both noradrenaline and normal saline occur on distinct rows but will have the same `ORDERID`. +`orderid` links multiple items contained in the same solution together. For example, when a solution of noradrenaline and normal saline is administered both noradrenaline and normal saline occur on distinct rows but will have the same `orderid`. -`LINKORDERID` links the same order across multiple instantiations: for example, if the rate of delivery for the solution with noradrenaline and normal saline is changed, two new rows which share the same new `ORDERID` will be generated, but the `LINKORDERID` will be the same. +`linkorderid` links the same order across multiple instantiations: for example, if the rate of delivery for the solution with noradrenaline and normal saline is changed, two new rows which share the same new `orderid` will be generated, but the `linkorderid` will be the same. -## ORDERCATEGORYNAME, SECONDARYORDERCATEGORYNAME, ORDERCOMPONENTTYPEDESCRIPTION, ORDERCATEGORYDESCRIPTION +## `ordercategoryname`, `secondaryordercategoryname`, `ordercomponenttypedescription`, `ordercategorydescription` -These columns provide higher level information about the order the medication/solution is a part of. Categories represent the type of administration, while the `ORDERCOMPONENTTYPEDESCRIPTION` describes the role of the substance in the solution (i.e. main order parameter, additive, or mixed solution) +These columns provide higher level information about the order the medication/solution is a part of. Categories represent the type of administration, while the `ordercomponenttypedescription` describes the role of the substance in the solution (i.e. main order parameter, additive, or mixed solution) -## PATIENTWEIGHT +## `patientweight` The patient weight in kilograms. -## TOTALAMOUNT, TOTALAMOUNTUOM +## `totalamount`, `totalamountuom` Intravenous administrations are usually given by hanging a bag of fluid at the bedside for continuous infusion over a certain period of time. These columns list the total amount of the fluid in the bag containing the solution. -## STATUSDESCRIPTION - -```STATUSDESCRIPTION``` states the ultimate status of the item, or more specifically, row. It is used to indicate why the delivery of the compound has ended. There are only six possible statuses: - -* Changed - The current delivery has ended as some aspect of it has changed (most frequently, the rate has been changed) -* Paused - The current delivery has been paused -* FinishedRunning - The delivery of the item has finished (most frequently, the bag containing the compound is empty) -* Stopped - The delivery of the item been terminated by the caregiver -* Rewritten - Incorrect information was input, and so the information in this row was rewritten (these rows are primarily useful for auditing purposes - the rates/amounts described were *not* delivered and so should not be used if determining what compounds a patient has received) -* Flushed - A line was flushed. - -## ISOPENBAG +## `isopenbag` Whether the order was from an open bag. -## CONTINUEINNEXTDEPT +## `continueinnextdept` If the order ended on patient transfer, this field indicates if it continued into the next department (e.g. a floor). -## CANCELREASON +## `statusdescription` -If the order was canceled, this column provides some explanation. +`statusdescription` states the ultimate status of the item, or more specifically, row. It is used to indicate why the delivery of the compound has ended. There are only six possible statuses: -## COMMENTS\_STATUS, COMMENTS\_TITLE, COMMENTS_DATE - -Specifies if the order was edited or canceled, and if so, the date and job title of the care giver who canceled or edited it. +* Changed - The current delivery has ended as some aspect of it has changed (most frequently, the rate has been changed) +* Paused - The current delivery has been paused +* FinishedRunning - The delivery of the item has finished (most frequently, the bag containing the compound is empty) +* Stopped - The delivery of the item been terminated by the caregiver +* Flushed - A line was flushed. -## ORIGINALAMOUNT +## `originalamount` -Drugs are usually mixed within a solution and delivered continuously from the same bag. This column represents the amount of the drug contained in the bag at `STARTTIME`. For the first infusion of a new bag, `ORIGINALAMOUNT`: `TOTALAMOUNT`. Later on, if the rate is changed, then the amount of the drug in the bag will be lower (as some has been administered to the patient). As a result, `ORIGINALAMOUNT` < `TOTALAMOUNT`, and `ORIGINALAMOUNT` will be the amount of drug leftover in the bag at that `STARTTIME`. +Drugs are usually mixed within a solution and delivered continuously from the same bag. This column represents the amount of the drug contained in the bag at `starttime`. For the first infusion of a new bag, `originalamount`: `totalamount`. Later on, if the rate is changed, then the amount of the drug in the bag will be lower (as some has been administered to the patient). As a result, `originalamount` < `totalamount`, and `originalamount` will be the amount of drug leftover in the bag at that `starttime`. -## ORIGINALRATE +## `originalrate` -This is the rate that was input by the care provider. Note that this may differ from `RATE` because of various reasons: `ORIGINALRATE` was the original planned rate, while the `RATE` column will be the true rate delivered. For example, if a a bag is about to run out and the care giver decides to push the rest of the fluid, then `RATE` > `ORIGINALRATE`. +This is the rate that was input by the care provider. Note that this may differ from `rate` because of various reasons: `originalrate` was the original planned rate, while the `rate` column will be the true rate delivered. For example, if a a bag is about to run out and the care giver decides to push the rest of the fluid, then `rate` > `originalrate`. However, these two columns are usually the same, but have minor non-clinically significant differences due to rounding error. \ No newline at end of file diff --git a/content/en/docs/IV/modules/icu/outputevents.md b/content/en/docs/IV/modules/icu/outputevents.md index cf6f3a72..9ed0884a 100644 --- a/content/en/docs/IV/modules/icu/outputevents.md +++ b/content/en/docs/IV/modules/icu/outputevents.md @@ -14,7 +14,7 @@ description: > **Table purpose:** Output data for patients. -**Number of rows:** 3,703,137 +**Number of rows:** 4,234,967 **Links to:** @@ -29,18 +29,18 @@ description: > Name | Data type ---- | -------- -subject\_id | Integer -hadm\_id | Integer -stay\_id | Integer -charttime | Date with times -storetime | Date with times -itemid | Integer -value | Floating point number -valueuom | Text +subject\_id | INTEGER +hadm\_id | INTEGER +stay\_id | INTEGER +charttime | TIMESTAMP(3) +storetime | TIMESTAMP(3) +itemid | INTEGER +value | DOUBLE PRECISION +valueuom | VARCHAR(20) # Detailed Description -## subject_id, hadm_id, stay_id +## `subject_id`, `hadm_id`, `stay_id` Identifiers which specify the patient: `subject_id` is unique to a patient, `hadm_id` is unique to a patient hospital stay and `stay_id` is unique to a patient ICU stay. @@ -51,18 +51,18 @@ Identifiers which specify the patient: `subject_id` is unique to a patient, `had --> -## CHARTTIME +## `charttime` -`CHARTTIME` is the time of an output event. +`charttime` is the time of an output event. -## STORETIME +## `storetime` -`STORETIME` records the time at which an observation was manually input or manually validated by a member of the clinical staff. +`storetime` records the time at which an observation was manually input or manually validated by a member of the clinical staff. -## ITEMID +## `itemid` -Identifier for a single measurement type in the database. Each row associated with one `ITEMID` (e.g. 212) corresponds to an instantiation of the same measurement (e.g. heart rate). +Identifier for a single measurement type in the database. Each row associated with one `itemid` (e.g. 212) corresponds to an instantiation of the same measurement (e.g. heart rate). -## VALUE, VALUEUOM +## `value`, `valueuom` -`VALUE` and `VALUEUOM` list the amount of a substance at the `CHARTTIME` (when the exact start time is unknown, but usually up to an hour before). \ No newline at end of file +`value` and `valueuom` list the amount of a substance at the `charttime` (when the exact start time is unknown, but usually up to an hour before). \ No newline at end of file diff --git a/content/en/docs/IV/modules/icu/procedureevents.md b/content/en/docs/IV/modules/icu/procedureevents.md index 52108f2b..77038f6a 100644 --- a/content/en/docs/IV/modules/icu/procedureevents.md +++ b/content/en/docs/IV/modules/icu/procedureevents.md @@ -14,7 +14,7 @@ description: > **Table purpose:** Contains procedures for patients -**Number of rows:** 592,932 +**Number of rows:** 696,092 **Links to:** @@ -23,42 +23,36 @@ description: > * icustays on `stay_id` * d_items on `itemid` - +# Important considerations + +This table is **not** a required documentation field during routine care. As a result, existence of procedures here indicates their presence, but absence does not indicate the procedure was not conducted. The consistency of documentation varies by the type of procedure. For example, invasive ventilation tends to be documented, whereas non-invasive documentation is less consistently documented. # Table columns Name | Data type ---- | -------- -subject\_id | Integer -hadm\_id | Integer -stay\_id | Integer -starttime | TIMESTAMP NOT NULL -endtime | TIMESTAMP NOT NULL -storetime | TIMESTAMP NOT NULL -itemid | Integer -value | Float (53) -valueuom | VARCHAR (20) +subject\_id | INTEGER +hadm\_id | INTEGER +stay\_id | INTEGER +starttime | TIMESTAMP +endtime | TIMESTAMP +storetime | TIMESTAMP +itemid | INTEGER +value | DOUBLE PRECISION +valueuom | VARCHAR(20) location | VARCHAR(100) locationcategory | VARCHAR(50) -orderid | Integer -linkorderid | Integer +orderid | INTEGER +linkorderid | INTEGER ordercategoryname | VARCHAR(50) -secondaryordercategoryname | VARCHAR(50) ordercategorydescription | VARCHAR(30) -patientweight | FLOAT(53) -totalamount | FLOAT(53) -totalamountuom | VARCHAR(50) +patientweight | DOUBLE PRECISION isopenbag | SMALLINT continueinnextdept | SMALLINT -cancelreason | SMALLINT statusdescription | VARCHAR(20) -comments_date | TIMESTAMP - +originalamount | DOUBLE PRECISION +originalrate | DOUBLE PRECISION # Detailed Description @@ -66,73 +60,72 @@ In particular, "originalrate" is either 0 or 1 for all records. Identifiers which specify the patient: `subject_id` is unique to a patient, `hadm_id` is unique to a patient hospital stay and `stay_id` is unique to a patient ICU stay. -## `STARTTIME`, `ENDTIME` +## `starttime`, `endtime` -`STARTTIME` and `ENDTIME` record the start and end time of an event. +`starttime` and `endtime` record the start and end time of an event. -## `STORETIME` +## `storetime` -`STORETIME` specifies the time when the event was recorded in the system. +`storetime` specifies the time when the event was recorded in the system. -## `ITEMID` +## `itemid` -Identifier for a single measurement type in the database. Each row associated with one `ITEMID` (e.g. 212) corresponds to a type of measurement (e.g. heart rate). The `mimic_icu.d_items` table may be joined on this field. For any itemid appearing in the `procedureevents` table, `mimic_icu.d_items.linksto` will have the value 'procedureevents'. +Identifier for a single measurement type in the database. Each row associated with one `itemid` (e.g. 212) corresponds to a type of measurement (e.g. heart rate). 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` +## `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. -## `VALUEUOM` +## `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. -## `LOCATION` , `LOCATION CATEGORY` +## `location` , `locationcategory` -`LOCATION` and `LOCATION CATEGORY` provide information about where on the patient's body the procedure is taking place. For example, the `location` might be 'Left Upper Arm' and the `locationcategory` might be 'Invasive Venous'. +`location` and `locationcategory` provide information about where on the patient's body the procedure is taking place. For example, the `location` might be 'Left Upper Arm' and the `locationcategory` might be 'Invasive Venous'. -## `ORDERID`, `LINKORDERID` +## `orderid`, `linkorderid` These columns link procedures to specific physician orders. Unlike in the `mimic_icu.inputevents` table, most procedures in `procedureevents` are ordered independently. -There are a limited number of records for which the same procedure was performed again at a later date under the same original order. When a procedure was repeated under the same original order, the `LINKORDERID` field of the record for the later procedure will be set to the `ORDERID` field of the earlier record. In all other cases, `ORDERID` = `LINKORDERID`. +There are a limited number of records for which the same procedure was performed again at a later date under the same original order. When a procedure was repeated under the same original order, the `linkorderid` field of the record for the later procedure will be set to the `orderid` field of the earlier record. In all other cases, `orderid` = `linkorderid`. -## `ORDERCATEGORYNAME`, `SECONDARYORDERCATEGORYNAME`, `ORDERCATEGORYDESCRIPTION` +## `ordercategoryname`, `ordercategorydescription` These columns provide higher level information about the medication/solution order. Categories represent the type of administration. -## `PATIENTWEIGHT` +## `patientweight` The patient weight in kilograms. -## `TOTALAMOUNT`, `TOTALAMOUNTUOM` - -These columns refer to intravenous administrations and are not recorded on the `procedureevents` table; they will be `null` for all entries. - -## `ISOPENBAG` +## `isopenbag` Whether the order was from an open bag. -## `CONTINUEINNEXTDEPT` +## `continueinnextdept` If the order ended on patient transfer, this field indicates if it continued into the next department (e.g. a floor). -## `CANCELREASON` - -This column is 0 for all records. +## `statusdescription` -## `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). * `Stopped` - The delivery of the item been terminated by the caregiver. -Nearly all procedures recorded in `procedureevents` have a status of `FinishedRunning`. +Nearly all procedures recorded in *procedureevents* have a status of `FinishedRunning`. + +## `originalamount`, `originalrate` + +These fields are present in the table and never null, but have no clear meaning. +In particular, "originalrate" is either 0 or 1 for all records. diff --git a/content/en/docs/IV/modules/note/ecg.md b/content/en/docs/IV/modules/note/ecg.md deleted file mode 100644 index 7f1b9568..00000000 --- a/content/en/docs/IV/modules/note/ecg.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "ECG" -linktitle: "ecg" -weight: 1 -date: 2021-03-02 -description: > - Electrocardiogram reports. ---- - -## *ecg* - -The *ecg* table contains echocardiography reports - specifically the free-text interpretation of a 12-lead electrocardiogram (ECG). - -## Links to - -* *ecg_detail* on `note_id` - - - -## Table columns - -Name | Postgres data type ----- | ---- -`note_id` | VARCHAR(25) NOT NULL -`subject_id` | INTEGER NOT NULL -`hadm_id` | INTEGER NOT NULL -`note_type` | CHAR(2) NOT NULL -`note_seq` | INTEGER NOT NULL -`charttime` | TIMESTAMP NOT NULL -`storetime` | TIMESTAMP -`text` | TEXT NOT NULL - -### `note_id` - -A unique identifier for the given note. `note_id` is composed of `subject_id`, the `note_type` (always two characters long), and a monotonically increasing integer, `note_seq`, in the following format: `subject_id`-`note_type`-`note_seq`. - -### `subject_id` - -{{% include "/static/include/subject_id.md" %}} - -### `hadm_id` - -{{% include "/static/include/hadm_id.md" %}} - -### `note_type` - -The type of note recorded in the row. This tables only has one type of note: - -* 'EK' - electrocardiogram report - -### `note_seq` - -A monotonically increasing integer which chronologically sorts the notes within `note_type` categories. That is, notes can be ordered sequentially by `note_seq`. - -### `charttime` - -The time at which the note was charted - this is usually the most relevant time for interpreting the content of the note, but it is not necessarily when the note was fully written. - -### `storetime` - -The time at which the note was stored in the database. This is usually when the note was completed and signed. diff --git a/content/en/docs/IV/modules/note/ecg_detail.md b/content/en/docs/IV/modules/note/ecg_detail.md deleted file mode 100644 index 8f0af965..00000000 --- a/content/en/docs/IV/modules/note/ecg_detail.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "ECG detail" -linktitle: "ecg_detail" -weight: 1 -date: 2021-03-02 -description: > - Auxiliary information for ecg notes. ---- - -## *ecg_detail* - -Additional information associated with notes documented in the *ecg* table. Can be linked to the *ecg* table using `note_id`. - -**As of MIMIC-Note v1.0 this table is empty.** - -## Links to - -* *ecg_detail* on `note_id` - - - -## Table columns - -Name | Postgres data type ----- | ---- -`note_id` | VARCHAR(25) NOT NULL -`subject_id` | INTEGER NOT NULL -`field_name` | VARCHAR(255) NOT NULL -`field_value` | TEXT NOT NULL -`field_ordinal` | INTEGER NOT NULL - -### `note_id` - -A unique identifier for the given note. `note_id` is composed of `subject_id`, the `note_type` (always two characters long), and a monotonically increasing integer, `note_seq`, in the following format: `subject_id`-`note_type`-`note_seq`. - -### `subject_id` - -{{% include "/static/include/subject_id.md" %}} - -### `field_name` - -Each row provides detail regarding a particular aspect of a note. `field_name` is the name given to that aspect. - -### `field_value` - -`field_value` is the value associated with the given `field_name`, associated with a note. For example, for the `field_name` of 'author', the `field_value` column contains the author of the note. diff --git a/content/en/docs/IV/modules/note/echo.md b/content/en/docs/IV/modules/note/echo.md deleted file mode 100644 index 3245c5c0..00000000 --- a/content/en/docs/IV/modules/note/echo.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "Echo" -linktitle: "echo" -weight: 1 -date: 2021-03-02 -description: > - Echocardiography reports. ---- - -## *echo* - -The *echo* table contains echocardiography reports - specifically the free-text interpretation associated with echocardiograms. - -## Links to - -* *echo_detail* on `note_id` - - - -## Table columns - -Name | Postgres data type ----- | ---- -`note_id` | VARCHAR(25) NOT NULL -`subject_id` | INTEGER NOT NULL -`hadm_id` | INTEGER NOT NULL -`note_type` | CHAR(2) NOT NULL -`note_seq` | INTEGER NOT NULL -`charttime` | TIMESTAMP NOT NULL -`storetime` | TIMESTAMP -`text` | TEXT NOT NULL - -### `note_id` - -A unique identifier for the given note. `note_id` is composed of `subject_id`, the `note_type` (always two characters long), and a monotonically increasing integer, `note_seq`, in the following format: `subject_id`-`note_type`-`note_seq`. - -### `subject_id` - -{{% include "/static/include/subject_id.md" %}} - -### `hadm_id` - -{{% include "/static/include/hadm_id.md" %}} - -### `note_type` - -The type of note recorded in the row. There are two types of note: - -* 'EC' - echocardiography report - -### `note_seq` - -A monotonically increasing integer which chronologically sorts the notes within `note_type` categories. That is, notes can be ordered sequentially by `note_seq`. - -### `charttime` - -The time at which the note was charted - this is usually the most relevant time for interpreting the content of the note, but it is not necessarily when the note was fully written. - -### `storetime` - -The time at which the note was stored in the database. This is usually when the note was completed and signed. diff --git a/content/en/docs/IV/modules/note/echo_detail.md b/content/en/docs/IV/modules/note/echo_detail.md deleted file mode 100644 index e4b45155..00000000 --- a/content/en/docs/IV/modules/note/echo_detail.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "Echo detail" -linktitle: "echo_detail" -weight: 1 -date: 2021-03-02 -description: > - Auxiliary information for echo notes. ---- - -## *echo_detail* - -Additional information associated with notes documented in the *echo* table. Can be linked to the *echo* table using `note_id`. - -## Links to - -* *echo_detail* on `note_id` - - - -## Table columns - -Name | Postgres data type ----- | ---- -`note_id` | VARCHAR(25) NOT NULL -`subject_id` | INTEGER NOT NULL -`field_name` | VARCHAR(255) NOT NULL -`field_value` | TEXT NOT NULL -`field_ordinal` | INTEGER NOT NULL - -### `note_id` - -A unique identifier for the given note. `note_id` is composed of `subject_id`, the `note_type` (always two characters long), and a monotonically increasing integer, `note_seq`, in the following format: `subject_id`-`note_type`-`note_seq`. - -### `subject_id` - -{{% include "/static/include/subject_id.md" %}} - -### `field_name` - -Each row provides detail regarding a particular aspect of a note. `field_name` is the name given to that aspect. As of MIMIC-IV, v1.0, possible values include: - -* contrast -* doppler -* technical quality -* test -* status -* blood pressure -* heart rate -* height -* weight - -### `field_value` - -`field_value` is the value associated with the given `field_name`, associated with a note. For example, for the `field_name` of 'author', the `field_value` column contains the author of the note.