If you use the MIMIC-IV Database in your work, please cite the MIMIC-III paper and note you are using an updated version.
3 |
4 |
5 |
--------------------------------------------------------------------------------
/content/datasets/cxr.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "CXR"
3 | linktitle = "CXR"
4 | weight = 5
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Datasets"
10 |
11 | +++
12 |
13 | # CXR
14 |
15 | The following tables are in `mimic_cxr`:
16 |
17 | * [cxr](/cxr/cxr-record-list)
18 |
--------------------------------------------------------------------------------
/content/tutorials/study.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "TBD: Code Repository"
3 | linktitle = "TBD"
4 | weight = 2
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Tutorials"
10 |
11 | +++
12 |
13 | # Code Repository
14 |
15 | We intend to update the MIMIC code repository for MIMIC-IV. We will update users when it is available.
--------------------------------------------------------------------------------
/content/datasets/core.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Core"
3 | linktitle = "Core"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Datasets"
10 |
11 | +++
12 |
13 | # Core
14 |
15 | The following tables are in `mimic_core`:
16 |
17 | * [admissions](/core/admissions)
18 | * [patients](/core/patients)
19 | * [services](/core/services)
20 | * [stays](/core/stays)
21 | * [transfers](/core/transfers)
--------------------------------------------------------------------------------
/content/datasets/ed.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "ED"
3 | linktitle = "ED"
4 | weight = 4
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Datasets"
10 |
11 | +++
12 |
13 | # ED
14 |
15 | The following tables are in `mimic_ed`:
16 |
17 | * [main](/ed/main)
18 | * [medrecon](/ed/medrecon)
19 | * [pyxis](/ed/pyxis)
20 | * [triage](/ed/triage)
21 | * [vitalsign](/ed/vitalsign)
22 | * (TBD): [vitalsign_hl7](/ed/vitalsign_hl7)
--------------------------------------------------------------------------------
/content/datasets/icu.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "ICU"
3 | linktitle = "ICU"
4 | weight = 3
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Datasets"
10 |
11 | +++
12 |
13 | # ICU
14 |
15 | The following tables are in `mimic_icu`:
16 |
17 | * [icustays](/icu/icustays)
18 | * [d_items](/icu/d_items)
19 | * [chartevents](/icu/chartevents)
20 | * [datetimeevents](/icu/datetimeevents)
21 | * [inputevents](/icu/inputevents)
22 | * [outputevents](/icu/outputevents)
23 | * [procedureevents](/icu/procedureevents)
--------------------------------------------------------------------------------
/content/datasets/hosp.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Hosp"
3 | linktitle = "Hosp"
4 | weight = 2
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Datasets"
10 |
11 | +++
12 |
13 | # Hosp
14 |
15 | The following tables are in `mimic_hosp`:
16 |
17 | * [d_hcpcs](/hosp/d_hcpcs)
18 | * [d_icd_diagnoses](/hosp/d_icd_diagnoses)
19 | * [d_icd_procedures](/hosp/d_icd_procedures)
20 | * [d_labitems](/hosp/d_labitems)
21 | * [d_micro](/hosp/d_micro)
22 | * [diagnoses_icd](/hosp/diagnoses_icd)
23 | * [drgcodes](/hosp/drgcodes)
24 | * [emar](/hosp/emar)
25 | * [emar_detail](/hosp/emar_detail)
26 | * [hcpcsevents](/hosp/hcpcsevents)
27 | * [labevents](/hosp/labevents)
28 | * [microbiologyevents](/hosp/microbiologyevents)
29 | * [procedures_icd](/hosp/procedures_icd)
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Website and documentation for the MIMIC-IV Database
2 |
3 | Source code used to generate the MIMIC-IV website:
4 |
5 | https://mimic-iv.mit.edu
6 |
7 | To raise issues, please use the MIMIC-IV Code Repository:
8 |
9 | https://github.com/MIT-LCP/mimic-iv-code
10 |
11 | ## Instructions for running the website locally
12 |
13 | 1. Install Hugo. For instructions, see: http://gohugo.io/overview/installing/
14 | 2. Clone the website repository:
15 | ```
16 | git clone --recursive https://github.com/mit-lcp/mimic-iv-website.git
17 | ```
18 | 3. Run ```hugo server``` at the command line to build the website and serve the pages.
19 | 4. View the website at: http://127.0.0.1:1313
20 |
21 | The website was tested with Hugo Static Site Generator v0.59.1 linux/amd64 BuildDate: 2019-10-31T21:21:45Z.
--------------------------------------------------------------------------------
/content/hosp/d_hcpcs.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Dimension table: hcpcs"
3 | linktitle = "d_hcpcs"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## The d_hcpcs table
14 |
15 | The D_HCPCS table is used to acquire human readable definitions for the codes used in the HCPCSEVENTS table. The concepts primarily correspond to hospital billing.
16 |
17 | ### Links to
18 |
19 | * HCPCSEVENTS on `code`
20 |
21 |
26 |
27 | ## Table columns
28 |
29 | Name | Postgres data type
30 | ---- | ----
31 | `code` | CHAR(5)
32 | `category` | SMALLINT
33 | `long_description` | TEXT
34 | `short_description` | VARCHAR(180)
35 |
36 | ## Detailed description
37 |
38 | ### `code`
39 |
40 | A five character code which uniquely represents the event.
41 |
42 | ### `category`
43 |
44 | Broad classification of the code.
45 |
46 | ### `long_description`, `short_description`
47 |
48 | Textual descriptions of the `code` listed for the given row.
49 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | The MIT License (MIT)
2 |
3 | Copyright (c) 2019 MIT Laboratory for Computational Physiology
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy
6 | of this software and associated documentation files (the "Software"), to deal
7 | in the Software without restriction, including without limitation the rights
8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 |
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 |
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 |
--------------------------------------------------------------------------------
/content/hosp/d_micro.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Dimension table: microbiology items"
3 | linktitle = "d_micro"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *d_micro*
14 |
15 | Definition table for all microbiology measurements.
16 |
17 | ### Links to
18 |
19 | * microbiologyevents on `itemid`
20 |
21 | ## Table columns
22 |
23 | Name | Postgres data type
24 | ---- | ----
25 | `itemid` | INTEGER
26 | `label` | VARCHAR(200)
27 | `category` | VARCHAR(100)
28 |
29 | ## Detailed Description
30 |
31 | ### `itemid`
32 |
33 | As the primary key of the table, `itemid` is unique to each row.
34 |
35 | ### `label`
36 |
37 | The `label` column describes the concept which is represented by the `itemid`, e.g. "AMPICILLIN".
38 |
39 | ### `category`
40 |
41 | `category` categorizes the `itemid` into one of four types:
42 |
43 | * ANTIBIOTIC
44 | * MICROTEST
45 | * ORGANISM
46 | * SPECIMEN
47 |
48 | "SPECIMEN" describes the sample taken to perform the test, "MICROTEST" describes the type of test performed, "ORGANISM" is the biological organism grown, and "ANTIBIOTIC" is the antibiotic used for evaluating sensitivity of an organism.
49 |
--------------------------------------------------------------------------------
/content/hosp/hcpcsevents.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "HCPCS events"
3 | linktitle = "hcpcsevents"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *hcpcsevents*
14 |
15 | ## Links to
16 |
17 | * *d_hcpcs* on hcpcs_cd
18 |
19 |
24 |
25 | ## Table columns
26 |
27 | Name | Postgres data type
28 | ---- | ----
29 | `subject_id` | INTEGER
30 | `hadm_id` | INTEGER
31 | `hcpcs_cd` | CHAR(5)
32 | `seq_num` | INTEGER
33 | `short_description` | TEXT
34 |
35 | ### `subject_id`
36 |
37 | {{% include "/static/include/subject_id.md" %}}
38 |
39 | ### `hadm_id`
40 |
41 | {{% include "/static/include/hadm_id.md" %}}
42 |
43 | ### `hcpcs_cd`
44 |
45 | A five character code which uniquely represents the event.
46 | Link this to `code` in D_HCPCS for a longer description of the code.
47 |
48 | ### `seq_num`
49 |
50 | An assigned order to HCPCS codes for an individual hospitalization. This order sometimes conveys meaning, e.g. sometimes higher priority, but this is not guaranteed across all codes.
51 |
52 | ### `short_description`
53 |
54 | A short textual descriptions of the `hcpcs_cd` listed for the given row.
55 |
--------------------------------------------------------------------------------
/content/hosp/labevents.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "labevents"
3 | linktitle = "labevents"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *labevents*
14 |
15 | The *labevents* table stores the results of all laboratory measurements made for a single patient.
16 | These include hematology measurements, blood gases, chemistry panels, and less common tests such as genetic assays.
17 |
18 | ## Links to
19 |
20 | * *d_labitems* on `itemid`
21 |
22 |
27 |
28 | ## Table columns
29 |
30 | Name | Postgres data type
31 | ---- | ----
32 | `subject_id` | INTEGER NOT NULL
33 | `hadm_id` | INTEGER
34 | `stay_id` | INTEGER
35 | `spec_id` | INTEGER NOT NULL
36 | `itemid` | INTEGER NOT NULL
37 | `charttime` | TIMESTAMP NOT NULL
38 | `storetime` | TIMESTAMP
39 | `value` | VARCHAR(200)
40 | `valuenum` | DOUBLE PRECISION
41 | `valueuom` | VARCHAR(20)
42 | `ref_range_lower` | DOUBLE PRECISION
43 | `ref_range_upper` | DOUBLE PRECISION
44 | `flag` | VARCHAR(10)
45 | `priority` | VARCHAR(7)
46 |
47 |
48 | ### `subject_id`
49 |
50 | {{% include "/static/include/subject_id.md" %}}
51 |
52 | ### `hadm_id`
53 |
54 | {{% include "/static/include/hadm_id.md" %}}
55 |
--------------------------------------------------------------------------------
/content/hosp/drgcodes.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "DRG Codes"
3 | linktitle = "drgcodes"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *drgcodes*
14 |
15 | Diagnosis related groups (DRGs) are used by the hospital to obtain reimbursement for a patient's hospital stay.
16 | The codes correspond to the primary reason for a patient's stay at the hospital.
17 |
18 |
23 |
24 | ## Table columns
25 |
26 | Name | Postgres data type
27 | ---- | ----
28 | `subject_id` | INTEGER
29 | `hadm_id` | INTEGER
30 | `drg_type` | VARCHAR(4)
31 | `drg_code` | VARCHAR(10)
32 | `description` | VARCHAR(195)
33 | `drg_severity` | SMALLINT
34 | `drg_mortality` | SMALLINT
35 |
36 | ## Detailed Description
37 |
38 | ### `subject_id`
39 |
40 | {{% include "/static/include/subject_id.md" %}}
41 |
42 | ### `hadm_id`
43 |
44 | {{% include "/static/include/hadm_id.md" %}}
45 |
46 | ### `drg_type`
47 |
48 | The specific DRG ontology used for the code.
49 |
50 | ### `drg_code`
51 |
52 | The DRG code.
53 |
54 | ### `description`
55 |
56 | A description for the given DRG code.
57 |
58 | ### `drg_severity`, `drg_mortality`
59 |
60 | Some DRG ontologies further qualify the patient severity of illness and likelihood of mortality, which are recorded here.
--------------------------------------------------------------------------------
/content/ed/pyxis.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Pyxis"
3 | linktitle = "pyxis"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ED Tables"
10 |
11 | +++
12 |
13 | # The PYXIS table
14 |
15 | The PYXIS table provides information for medicine administrations made via the Pyxis system.
16 |
17 | **Table source:** Emergency department database.
18 |
19 | **Table purpose:** Track medicine administrations.
20 |
21 | **Number of rows:**
22 |
23 | **Links to:**
24 |
25 | * MAIN on `stay_id`
26 |
27 |
28 |
29 | # Table columns
30 |
31 | Name | Postgres data type
32 | ---- | ----
33 | `stay_id` | INT NOT NULL
34 | `charttime` | TIMESTAMP(0)
35 | `med_rn` | SMALLINT NOT NULL
36 | `name` | VARCHAR(255)
37 | `ifu` | VARCHAR(255)
38 | `gsn_rn` | SMALLINT NOT NULL
39 | `gsn` | VARCHAR(10)
40 |
41 | ## `stay_id`
42 |
43 | An identifier which uniquely identifies a single emergency department stay for a single patient.
44 |
45 | ## `charttime`
46 |
47 | The time at which the medication was charted, which is the closest approximation to the time the medication was administered.
48 |
49 | ## `med_rn`
50 |
51 | A row number for the medicine.
52 |
53 | ## `name`
54 |
55 | The name of the medicine.
56 |
57 | ## `ifu`
58 |
59 | ## `gsn`
60 |
61 | A hierarchical ontology which groups the medication.
62 |
63 | ## `gsn_rn`
64 |
65 | As a medicine may be a member of multiple groups in the GSN ontology, this row number differentiates them.
--------------------------------------------------------------------------------
/content/hosp/d_icd_procedures.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Dimension table: ICD procedures"
3 | linktitle = "d_icd_procedures"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## The D_ICD_PROCEDURES table
14 |
15 | This table defines International Classification of Diseases (ICD) codes for **procedures**. These codes are assigned at the end of the patient's stay and are used by the hospital to bill for care provided. They can further be used to identify if certain procedures have been performed (e.g. surgery).
16 |
17 | ### Links to
18 |
19 | * procedures_icd on `icd_code`
20 |
21 | ## Brief summary
22 |
23 |
24 |
25 | ## Table columns
26 |
27 | Name | Postgres data type
28 | ---- | ----
29 | `icd_code` | VARCHAR(10)
30 | `icd_version` | INTEGER
31 | `long_title` | VARCHAR(300)
32 |
33 | ## Detailed Description
34 |
35 | ### `icd_code`, `icd_version`
36 |
37 | `icd_code` is the International Coding Definitions (ICD) code.
38 |
39 | There are two versions for this coding system: version 9 (ICD-9) and version 10 (ICD-10). These can be differentiated using the `icd_version` column.
40 | In general, ICD-10 codes are more detailed, though code mappings (or "cross-walks") exist which convert ICD-9 codes to ICD-10 codes.
41 |
42 | Both ICD-9 and ICD-10 codes are often presented with a decimal. This decimal is not required for interpretation of an ICD code; i.e. the `icd_code` of '0010' is equivalent to '001.0'.
43 |
44 | ## `long_title`
45 |
46 | The title fields provide a brief definition for the given procedure code in ``.
47 |
--------------------------------------------------------------------------------
/content/ed/vitalsign.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Vital signs"
3 | linktitle = "vitalsign"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ED Tables"
10 |
11 | +++
12 |
13 | # The VITALSIGN table
14 |
15 | Patients admitted to the emergency department have routine vital signs taken ever 1-4 hours. These vital signs are stored in the VITALSIGN table.
16 |
17 | **Table source:** Emergency department database.
18 |
19 | **Table purpose:** Provides nurse documented vital signs.
20 |
21 | **Number of rows:**
22 |
23 | **Links to:**
24 |
25 | * MAIN on `stay_id`
26 |
27 |
28 |
29 | # Table columns
30 |
31 | Name | Postgres data type
32 | ---- | ----
33 | `stay_id` | INTEGER NOT NULL
34 | `charttime` | TIMESTAMP(0)
35 | `temp` | NUMERIC(10, 4)
36 | `pulse` | NUMERIC(10, 4)
37 | `SBP` | INTEGER
38 | `DBP` | INTEGER
39 | `RR` | NUMERIC(10, 4)
40 | `O2Sat` | NUMERIC(10, 4)
41 | `Rhythm` | TEXT
42 | `Pain` | TEXT
43 |
44 | ## `stay_id`
45 |
46 | An identifier which uniquely identifies a single emergency department stay for a single patient.
47 |
48 | ## `charttime`
49 |
50 | The time at which the vital signs were charted.
51 |
52 | ## `temp`
53 |
54 | The patient's temperature.
55 |
56 | ## `pulse`
57 |
58 | The patient's heart rate.
59 |
60 | ## `sbp`, `dbp`
61 |
62 | The patient's diastolic (dbp) and systolic (sbp) blood pressure.
63 |
64 | ## `rr`
65 |
66 | The patient's respiratory rate.
67 |
68 |
69 |
70 | ## `o2sat`
71 |
72 | The patient's peripheral oxygen saturation.
73 |
74 | ## `rhythm`
75 |
76 | The patient's current heart rhythm
77 |
78 | ## `pain`
79 |
80 | The patient's self-reported level of pain on a scale from 0-10.
--------------------------------------------------------------------------------
/content/hosp/procedures_icd.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "ICD Procedures"
3 | linktitle = "procedures_icd"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *procedures_icd*
14 |
15 | During routine hospital care, patients are billed by the *hospital* for procedures they undergo.
16 | 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.
17 |
18 | ## Important considerations
19 |
20 | - 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.
21 |
22 | ## Table columns
23 |
24 | Name | Postgres data type
25 | ---- | ----
26 | `subject_id` | INTEGER
27 | `hadm_id` | INTEGER
28 | `seq_num` | INTEGER
29 | `icd_code` | CHAR(7)
30 | `icd_version` | INTEGER
31 |
32 | ### `subject_id`
33 |
34 | {{% include "/static/include/subject_id.md" %}}
35 |
36 | ### `hadm_id`
37 |
38 | {{% include "/static/include/hadm_id.md" %}}
39 |
40 | ## `seq_num`
41 |
42 | The order in which the procedures occurred within the hospital stay.
43 |
44 | ### `icd_code`, `icd_version`
45 |
46 | `icd_code` is the International Coding Definitions (ICD) code.
47 |
48 | There are two versions for this coding system: version 9 (ICD-9) and version 10 (ICD-10). These can be differentiated using the `icd_version` column.
49 | In general, ICD-10 codes are more detailed, though code mappings (or "cross-walks") exist which convert ICD-9 codes to ICD-10 codes.
50 |
51 | Both ICD-9 and ICD-10 codes are often presented with a decimal. This decimal is not required for interpretation of an ICD code; i.e. the `icd_code` of '0010' is equivalent to '001.0'.
52 |
--------------------------------------------------------------------------------
/content/core/transfers.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Transfers"
3 | linktitle = "transfers"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Core Tables"
10 |
11 | +++
12 |
13 | ## *transfers*
14 |
15 | Physical locations for patients throughout their hospital stay.
16 |
17 | ### Links to
18 |
19 | * *patients* on `subject_id`
20 | * *admissions* on `hadm_id`
21 |
22 | ## Important considerations
23 |
24 | * The `icustays` table is derived from this table.
25 |
26 | ## Table columns
27 |
28 | Name | Postgres data type
29 | ---- | ----
30 | `subject_id` | INTEGER
31 | `hadm_id` | INTEGER
32 | `stay_id` | INTEGER
33 | `transfer_id` | INTEGER
34 | `eventtype` | VARCHAR(10)
35 | `careunit` | VARCHAR(255)
36 | `intime` | TIMESTAMP(0)
37 | `outtime` | TIMESTAMP(0)
38 |
39 | ## Detailed Description
40 |
41 | ## `subject_id`, `hadm_id`, `transfer_id`
42 |
43 | Identifiers which specify the patient: `subject_id` is unique to a patient, `hadm_id` is unique to a patient hospital stay, `stay_id` is unique to a patient stay in a hospital unit, `transfer_id` is unique to a patient physical location.
44 |
45 | ## `eventtype`
46 |
47 | `eventtype` describes what transfer event occurred: 'admit' for an admission, 'transfer' for an intra-hospital transfer and 'discharge' for a discharge from the hospital.
48 |
49 | ## `careunit`
50 |
51 | `careunit` contains the care unit in which the patient currently resides.
52 |
53 | The `intime` and `outtime` of the transfer event correspond to the `careunit`.
54 |
55 | ## `intime`, `outtime`
56 |
57 | `intime` provides the date and time the patient was transferred into the current care unit (`careunit`) from the previous care unit. `outtime` provides the date and time the patient was transferred out of the current physical location.
58 |
--------------------------------------------------------------------------------
/content/ed/medrecon.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Medicine Reconciliation"
3 | linktitle = "medrecon"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ED Tables"
10 |
11 | +++
12 |
13 | # The MEDRECON table
14 |
15 | On admission to the emergency departments, staff will ask the patient what current medications they are taking. This process is called medicine reconciliation, and the MEDRECON table stores the findings of the care providers.
16 |
17 | **Table source:** Emergency department database.
18 |
19 | **Table purpose:** Document medications a patient is currently taking.
20 |
21 | **Number of rows:**
22 |
23 | **Links to:**
24 |
25 | * MAIN on `stay_id`
26 |
27 |
28 |
29 | # Table columns
30 |
31 | Name | Postgres data type
32 | ---- | ----
33 | `stay_id` | INT NOT NULL
34 | `charttime` | TIMESTAMP(0)
35 | `name` | VARCHAR(255)
36 | `gsn` | VARCHAR(10)
37 | `ndc` | VARCHAR(12)
38 | `etc_rn` | SMALLINT NOT NULL
39 | `etccode` | VARCHAR(8)
40 | `etcdescription` | VARCHAR(255)
41 |
42 | ## `stay_id`
43 |
44 | An identifier which uniquely identifies a single emergency department stay for a single patient.
45 |
46 | ## `charttime`
47 |
48 | The time at which the medicine reconciliation was charted.
49 |
50 | ## `name`
51 |
52 | The name of the medication.
53 |
54 | ## `gsn`
55 |
56 | A code for the medication.
57 |
58 | ## `ndc`
59 |
60 | The National Drug Code (ndc) for the medication.
61 |
62 | ## `etc_rn`, `etccode`, `etcdescription`
63 |
64 | Medications are grouped using a hierarchical ontology. As more than one group may be associated with the medication, `etc_rn` is used to differentiate the groups (there is no meaning to the order of `etc_rn`). `etccode` provides the code and `etcdescription` provides the description of the group.
--------------------------------------------------------------------------------
/content/icu/outputevents.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Outputevents"
3 | linktitle = "outputevents"
4 | weight = 10
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ICU Tables"
10 |
11 | +++
12 |
13 |
14 | # The outputevents table
15 |
16 | **Table source:** MetaVision ICU database.
17 |
18 | **Table purpose:** Output data for patients.
19 |
20 | **Number of rows:** 3,703,137
21 |
22 | **Links to:**
23 |
24 | * PATIENTS on `subject_id`
25 | * ADMISSIONS on `hadm_id`
26 | * ICUSTAYS on `stay_id`
27 | * D_ITEMS on `itemid`
28 |
29 |
30 |
31 | # Table columns
32 |
33 | Name | Data type
34 | ---- | --------
35 | SUBJECT\_ID | Integer
36 | HADM\_ID | Integer
37 | STAY\_ID | Integer
38 | CHARTTIME | Date with times
39 | STORETIME | Date with times
40 | ITEMID | Integer
41 | VALUE | Floating point number
42 | VALUEUOM | Text
43 | WARNING | Binary (0 or 1)
44 |
45 | # Detailed Description
46 |
47 | ## subject_id, hadm_id, stay_id
48 |
49 | 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.
50 |
51 |
57 |
58 | ## CHARTTIME
59 |
60 | `CHARTTIME` is the time of an output event.
61 |
62 | ## STORETIME
63 |
64 | `STORETIME` records the time at which an observation was manually input or manually validated by a member of the clinical staff.
65 |
66 | ## ITEMID
67 |
68 | 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).
69 |
70 | ## VALUE, VALUEUOM
71 |
72 | `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).
--------------------------------------------------------------------------------
/content/cxr/cxr-record-list.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "CXR Record List"
3 | linktitle = "cxr_record_list"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "CXR Tables"
10 |
11 | +++
12 |
13 | # CXR Record List
14 |
15 | This table lists all records in the MIMIC-CXR database.
16 | Each DICOM file, corresponding to a single chest x-ray, is assigned a unique `dicom_id`.
17 | This table links those IDs to a `study_id` for the radiology report and a `subject_id` for the patient.
18 |
19 | **Table source:** Hospital database.
20 |
21 | **Table purpose:** Provides a link between `subject_id`, `study_id`, and `dicom_id`.
22 |
23 | **Number of rows:**
24 |
25 | **Links to:**
26 |
27 | * CORE.PATIENTS on `subject_id`
28 |
29 | # Important considerations
30 |
31 | Chest x-rays are available for all *patients* who presented to the emergency department. The logic was:
32 |
33 | * extract patient identifiers for all patients admitted to the emergency department between 2011 - 2016
34 | * use these patient identifiers to extract *all* chest x-rays performed during 2011-2016
35 |
36 | As such, if a patient was admitted to the ED between 2011 - 2016, then x-rays will be available for the ED admission, and any subsequent stays in the hospital (e.g. if they were admitted to the intensive care unit, their chest x-rays in the ICU will be available).
37 |
38 | # Table columns
39 |
40 | Name | Postgres data type
41 | ---- | ----
42 | `subject_id` | INTEGER NOT NULL
43 | `study_id` | INTEGER NOT NULL
44 | `dicom_id` | TEXT NOT NULL
45 |
46 | ## `subject_id`
47 |
48 | `subject_id` is a unique identifier which specifies an individual patient. Any rows associated with a single `subject_id` pertain to the same individual.
49 |
50 | ## `study_id`
51 |
52 | A unique identifier for the radiology report written for the given chest x-ray.
53 |
54 | ## `dicom_id`
55 |
56 | A unique identifier for the chest x-ray.
--------------------------------------------------------------------------------
/content/icu/procedureevents.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Procedureevents"
3 | linktitle = "procedureevents"
4 | weight = 10
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ICU Tables"
10 |
11 | +++
12 |
13 |
14 | # The procedureevents_mv table
15 |
16 | **Table source:** MetaVision ICU database.
17 |
18 | **Table purpose:** Contains procedures for patients
19 |
20 | **Number of rows:** 592,932
21 |
22 | **Links to:**
23 |
24 | * PATIENTS on `subject_id`
25 | * ADMISSIONS on `hadm_id`
26 | * ICUSTAYS on `stay_id`
27 | * D_ITEMS on `itemid`
28 |
29 |
30 |
31 | # Table columns
32 |
33 |
34 | Name | Data type
35 | ---- | --------
36 | SUBJECT\_ID | Integer
37 | HADM\_ID | Integer
38 | STAY\_ID | Integer
39 | ITEMID | Integer
40 | CHARTTIME | Date with times
41 | STORETIME | Date with times
42 | VALUE | Text
43 | VALUENUM | Decimal number
44 | VALUEUOM | Text
45 | WARNING | Binary (0 or 1)
46 | LOCATION | VARCHAR(30)
47 | LOCATIONCATEGORY | VARCHAR(30)
48 | STORETIME | TIMESTAMP(0)
49 | CGID | INT
50 | ORDERID | INT
51 | LINKORDERID | INT
52 | ORDERCATEGORYNAME | VARCHAR(100)
53 | SECONDARYORDERCATEGORYNAME | VARCHAR(100)
54 | ORDERCATEGORYDESCRIPTION | VARCHAR(50)
55 | ISOPENBAG | SMALLINT
56 | CONTINUEINNEXTDEPT | SMALLINT
57 | CANCELREASON | SMALLINT
58 | STATUSDESCRIPTION | VARCHAR(30)
59 | COMMENTS_EDITEDBY | VARCHAR(30)
60 | COMMENTS_CANCELEDBY | VARCHAR(30)
61 | COMMENTS_DATE | TIMESTAMP(0)
62 |
63 |
79 |
80 |
81 |
87 |
--------------------------------------------------------------------------------
/content/hosp/d_icd_diagnoses.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Dimension table: ICD diagnoses"
3 | linktitle = "d_icd_diagnoses"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 |
14 | ## The d_icd_diagnoses table
15 |
16 | This table defines International Classification of Diseases (ICD) Version 9 and 10 codes for **diagnoses**. These codes are assigned at the end of the patient's stay and are used by the hospital to bill for care provided.
17 |
18 | ### Links to
19 |
20 | * *diagnoses_icd* ON `icd_code`
21 |
22 |
23 |
24 | ## Table columns
25 |
26 | Name | Postgres data type
27 | ---- | ----
28 | `icd_code` | VARCHAR(10)
29 | `icd_version` | INTEGER
30 | `long_title` | VARCHAR(300)
31 |
32 | ## Detailed Description
33 |
34 | ### `icd_code`, `icd_version`
35 |
36 | `icd_code` is the International Coding Definitions (ICD) code.
37 |
38 | There are two versions for this coding system: version 9 (ICD-9) and version 10 (ICD-10). These can be differentiated using the `icd_version` column.
39 | In general, ICD-10 codes are more detailed, though code mappings (or "cross-walks") exist which convert ICD-9 codes to ICD-10 codes.
40 |
41 | Both ICD-9 and ICD-10 codes are often presented with a decimal. This decimal is not required for interpretation of an ICD code; i.e. the `icd_code` of '0010' is equivalent to '001.0'.
42 |
43 | ICD-9 and ICD-10 codes have distinct formats: ICD-9 codes are 5 character long strings which are entirely numeric (with the exception of codes prefixed with "E" or "V" which are used for external causes of injury or supplemental classification). Importantly, ICD-9 codes are retained as strings in the database as the leading 0s in codes are meaningful.
44 |
45 | ICD-10 codes are 3-7 characters long and always prefixed by a letter followed by a set of numeric values.
46 |
47 | ### `long_title`
48 |
49 | The `long_title` provides the meaning of the ICD code. For example, the ICD-9 code 0010 has `long_title` "Cholera due to vibrio cholerae".
50 |
--------------------------------------------------------------------------------
/content/hosp/poe_detail.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Provider Order Entry detail"
3 | linktitle = "poe_detail"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *poe_detail*
14 |
15 | The *poe_detail* table provides further information on POE orders. The table uses an Entity-Attribute-Value (EAV) model: the entity is `poe_id`, the attribute is `field_name`, and the value is `field_value`.
16 | EAV tables allow for flexible description of entities when the attributes are heterogenous.
17 |
18 | ## Links to
19 |
20 | * *poe_detail* on `poe_id`
21 |
22 |
27 |
28 | ## Table columns
29 |
30 | Name | Postgres data type
31 | ---- | ----
32 | `poe_id` | VARCHAR(25) NOT NULL
33 | `poe_seq` | INTEGER NOT NULL
34 | `subject_id` | INTEGER NOT NULL
35 | `field_name` | VARCHAR(255)
36 | `field_value` | TEXT
37 |
38 | ### `poe_id`
39 |
40 | A unique identifier for the given order. `poe_id` is composed of `subject_id` and a monotonically increasing integer, `poe_seq`, in the following format: `subject_id`-`poe_seq`.
41 |
42 | ### `poe_seq`
43 |
44 | A monotonically increasing integer which chronologically sorts the POE orders. That is, POE orders can be ordered sequentially by `poe_seq`.
45 |
46 | ### `subject_id`
47 |
48 | {{% include "/static/include/subject_id.md" %}}
49 |
50 | ### `field_name`
51 |
52 | Each row provides detail regarding a particular aspect of a POE order. `field_name` is the name given to that aspect. It is one of the following values:
53 |
54 | * Admit category
55 | * Admit to
56 | * Code status
57 | * Consult Status
58 | * Consult Status Time
59 | * Discharge Planning
60 | * Discharge When
61 | * Indication
62 | * Level of Urgency
63 | * Transfer to
64 | * Tubes & Drains type
65 |
66 | ### `field_value`
67 |
68 | `field_value` is the value associated with the given POE order and `field_name`. For example, for the `field_name` of 'Admit to', the `field_value` column contains the type of unit the patient was admitted to (Psychiatry, GYN, and so on).
69 |
--------------------------------------------------------------------------------
/content/ed/vitalsign_hl7.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Vital signs (HL7)"
3 | linktitle = "vitalsign_hl7"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ED Tables"
10 |
11 | +++
12 |
13 | # The VITALSIGN_HL7 table
14 |
15 | **This table is not yet populated.**
16 |
17 | Patients admitted to the emergency department may be monitored by telemetry.
18 | Minute-by-minute vital signs for telemetry are communicated to a central server in the hospital, and these vital signs are recorded here.
19 | However, vital signs are only communicated with patient identifiers manually input into the bedside monitors, a process which is not routine practice.
20 | As a result, many patients who are monitored by telemetry do not have their vital signs recorded in this table.
21 |
22 | **Table source:** Emergency department database.
23 |
24 | **Table purpose:** Continuous vital signs for monitored patients.
25 |
26 | **Number of rows:**
27 |
28 | **Links to:**
29 |
30 | * MAIN on `stay_id`
31 |
32 |
33 |
34 | # Table columns
35 |
36 | Name | Postgres data type
37 | ---- | ----
38 | `stay_id` | INTEGER NOT NULL
39 | `charttime` | TIMESTAMP(0) NOT NULL
40 | `hr` | INTEGER
41 | `resp` | INTEGER
42 | `spo2` | INTEGER
43 | `pulse` | INTEGER
44 | `nbp_d` | INTEGER
45 | `nbp_m` | INTEGER
46 | `nbp_s` | INTEGER
47 |
48 | ## `stay_id`
49 |
50 | An identifier which uniquely identifies a single emergency department stay for a single patient.
51 |
52 | ## `charttime`
53 |
54 | The date and time that the set of vital signs were recorded.
55 |
56 | ## `hr`
57 |
58 | The patient's heart rate.
59 |
60 | ## `resp`
61 |
62 | The patient's respiratory rate.
63 |
64 | ## `spo2`
65 |
66 | The patient's peripheral oxygen saturation.
67 |
68 | ## `pulse`
69 |
70 | The patient's heart rate derived from a photoplethysmogram.
71 |
72 | ## `nbp_d`, `nbp_m`, `nbp_s`
73 |
74 | 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).
--------------------------------------------------------------------------------
/content/hosp/diagnoses_icd.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "ICD diagnoses"
3 | linktitle = "diagnoses_icd"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *diagnoses_icd*
14 |
15 | During routine hospital care, patients are billed by the *hospital* for diagnoses associated with their hospital stay.
16 | 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.
17 | Diagnoses are billed on hospital discharge, and are determined by trained persons who read signed clinical notes.
18 |
19 | ## Table columns
20 |
21 | Name | Postgres data type
22 | ---- | ----
23 | `subject_id` | INTEGER
24 | `hadm_id` | INTEGER
25 | `seq_num` | INTEGER
26 | `icd_code` | CHAR(7)
27 | `icd_version` | INTEGER
28 |
29 | ## Detailed Description
30 |
31 | ### `subject_id`
32 |
33 | {{% include "/static/include/subject_id.md" %}}
34 |
35 | ### `hadm_id`
36 |
37 | {{% include "/static/include/hadm_id.md" %}}
38 |
39 | ### `seq_num`
40 |
41 | The priority assigned to the diagnoses.
42 | The priority can be interpreted as a ranking of which diagnoses are "important", but many caveats to this broad statement exist.
43 | For example, patients who are diagnosed with sepsis must have sepsis as their *2nd* billed condition. The 1st billed condition must be the infectious agent.
44 | There's also less importance placed on ranking low priority diagnoses "correctly" (as there may be no correct ordering of the priority of the 5th - 10th diagnosis codes, for example).
45 |
46 | ### `icd_code`, `icd_version`
47 |
48 | `icd_code` is the International Coding Definitions (ICD) code.
49 |
50 | There are two versions for this coding system: version 9 (ICD-9) and version 10 (ICD-10). These can be differentiated using the `icd_version` column.
51 | In general, ICD-10 codes are more detailed, though code mappings (or "cross-walks") exist which convert ICD-9 codes to ICD-10 codes.
52 |
53 | Both ICD-9 and ICD-10 codes are often presented with a decimal. This decimal is not required for interpretation of an ICD code; i.e. the `icd_code` of '0010' is equivalent to '001.0'.
54 |
--------------------------------------------------------------------------------
/content/ed/main.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Main"
3 | linktitle = "main"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ED Tables"
10 |
11 | +++
12 |
13 | # The MAIN table
14 |
15 | The MAIN table is the primary tracking table for emergency department visits.
16 | It provides the time the patient entered the emergency department and the time they left the emergency department.
17 | It also provides a set of diagnoses assigned for the patient.
18 |
19 | **Table source:** Emergency department database.
20 |
21 | **Table purpose:** Track patient admissions to the emergency department.
22 |
23 | **Number of rows:**
24 |
25 | **Links to:**
26 |
27 |
28 |
29 | # Table columns
30 |
31 | Name | Postgres data type
32 | ---- | ----
33 | `subject_id` | INTEGER NOT NULL
34 | `stay_id` | INTEGER NOT NULL
35 | `intime` | TIMESTAMP(0) NOT NULL
36 | `outtime` | TIMESTAMP(0) NOT NULL
37 | `sex` | CHAR(1) NOT NULL
38 | `dx1` | VARCHAR(255)
39 | `dx1_icd` | VARCHAR(10)
40 | `dx2` | VARCHAR(255)
41 | `dx2_icd` | VARCHAR(10)
42 | `dx3` | VARCHAR(255)
43 | `dx3_icd` | VARCHAR(10)
44 | `dx4` | VARCHAR(255)
45 | `dx4_icd` | VARCHAR(10)
46 | `dx5` | VARCHAR(255)
47 | `dx5_icd` | VARCHAR(10)
48 | `dx6` | VARCHAR(255)
49 | `dx6_icd` | VARCHAR(10)
50 | `dx7` | VARCHAR(255)
51 | `dx7_icd` | VARCHAR(10)
52 | `dx8` | VARCHAR(255)
53 | `dx8_icd` | VARCHAR(10)
54 | `dx9` | VARCHAR(255)
55 | `dx9_icd` | VARCHAR(10)
56 |
57 | ## `subject_id`
58 |
59 | `subject_id` is a unique identifier which specifies an individual patient. Any rows associated with a single `subject_id` pertain to the same individual.
60 |
61 | ## `stay_id`
62 |
63 | An identifier which uniquely identifies a single emergency department stay for a single patient.
64 |
65 | ## `intime`, `outtime`
66 |
67 | The admission datetime (`intime`) and discharge datetime (`outtime`) of the given emergency department stay.
68 |
69 | ## `dx1_icd`, `dx2_icd`, ... `dx9_icd`
70 |
71 | The ICD coded diagnoses for the patient, ordered by priority.
72 |
73 | ## `dx1`, `dx2`, ..., `dx9`
74 |
75 | The textual description of ICD diagnoses for the patient.
76 |
--------------------------------------------------------------------------------
/content/ed/triage.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Triage"
3 | linktitle = "triage"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ED Tables"
10 |
11 | +++
12 |
13 | # The TRIAGE table
14 |
15 | The TRIAGE table contains information about the patient when they were first triaged in the emergency department.
16 | Patients are assessed at triage by a single care provider and asked a series of questions to assess their current health status.
17 | Their vital signs are measured and a level of acuity is assigned. Based on the level of acuity, the patient either waits in the waiting room for later attention, or is prioritized for immediate care.
18 |
19 | **Table source:** Emergency department database.
20 |
21 | **Table purpose:**
22 |
23 | **Number of rows:**
24 |
25 | **Links to:**
26 |
27 | * MAIN on `stay_id`
28 |
29 | # Important considerations
30 |
31 | * There is no time associated with triage observations. The closest approximation to triage time is the `intime` of the patient from the MAIN table.
32 |
33 | # Table columns
34 |
35 | Name | Postgres data type
36 | ---- | ----
37 | `stay_id` | INTEGER NOT NULL
38 | `temp` | NUMERIC(10, 4)
39 | `HR` | NUMERIC(10, 4)
40 | `RR` | NUMERIC(10, 4)
41 | `SaO2` | NUMERIC(10, 4)
42 | `Pain` | NUMERIC(10, 4)
43 | `Acuity` | NUMERIC(10, 4)
44 | `SBP` | NUMERIC(10, 4)
45 | `DBP` | NUMERIC(10, 4)
46 |
47 | ## `stay_id`
48 |
49 | An identifier which uniquely identifies a single emergency department stay for a single patient.
50 |
51 | ## `temp`
52 |
53 | The patient's temperature in degrees Celsius.
54 |
55 | ## `HR`
56 |
57 | The patient's heart rate.
58 |
59 | ## `RR`
60 |
61 | The patient's respiratory rate.
62 |
63 | ## `SaO2`
64 |
65 | The patient's peripheral oxygen saturation.
66 |
67 | ## `Pain`
68 |
69 | The level of pain self-reported by the patient, on a scale of 0-10.
70 |
71 | ## `Acuity`
72 |
73 | The assigned acuity level for the patient. The acuity level determines how immediately the patient requires care:
74 |
75 | * 1 - Not urgent
76 | * 5 - Must be admitted and seen by medical staff immediately
77 |
78 | ## `SBP`, `DBP`
79 |
80 | The patient's systolic and diastolic blood pressure, respectively, measured in millimitres of mercury (mmHg).
81 |
--------------------------------------------------------------------------------
/content/icu/icustays.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "ICU stays"
3 | linktitle = "icustays"
4 | weight = 10
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ICU Tables"
10 |
11 | +++
12 |
13 |
14 | # The icustays table
15 |
16 | **Table source:** Hospital database.
17 |
18 | **Table purpose:** Defines each ICU stay in the database using STAY\_ID.
19 |
20 | **Number of rows:** 65,794
21 |
22 | **Links to:**
23 |
24 | * PATIENTS on `subject_id`
25 | * ADMISSIONS on `hadm_id`
26 |
27 | # Important considerations
28 |
29 | * `stay_id` is a *generated* identifier that is *not* based on any raw data identifier. The hospital and ICU databases are not intrinsically linked and so do not have any concept of an ICU encounter identifier.
30 | * The ICUSTAYS table is derived from the TRANSFERS table. Specifically, it excludes rows in TRANSFERS where the ward is not an ICU.
31 |
32 | # Table columns
33 |
34 | Name | Postgres data type
35 | ---- | ----
36 | SUBJECT\_ID | INT
37 | HADM\_ID | INT
38 | STAY\_ID | INT
39 | FIRST\_CAREUNIT | VARCHAR(20)
40 | LAST\_CAREUNIT | VARCHAR(20)
41 | INTIME | TIMESTAMP(0)
42 | OUTTIME | TIMESTAMP(0)
43 | LOS | DOUBLE | PRECISION
44 |
45 | # Detailed Description
46 |
47 | ## `subject_id`, `hadm_id`, `stay_id`
48 |
49 | 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 ward stay.
50 |
51 | ## `FIRST_CAREUNIT`, `LAST_CAREUNIT`
52 |
53 | `FIRST_CAREUNIT` and `LAST_CAREUNIT` contain, respectively, the first and last ICU type in which the patient was cared for. As an `stay_id` groups all ICU admissions within 24 hours of each other, it is possible for a patient to be transferred from one type of ICU to another and have the same `stay_id`.
54 |
55 | Care units are derived from the TRANSFERS table, and definition for the abbreviations can be found in the documentation for TRANSFERS.
56 |
57 | ## `INTIME`, `OUTTIME`
58 |
59 | `INTIME` provides the date and time the patient was transferred into the ICU. `OUTTIME` provides the date and time the patient was transferred out of the ICU.
60 |
61 | ## `LOS`
62 |
63 | `LOS` is the length of stay for the patient for the given ICU stay, which may include one or more ICU units. The length of stay is measured in fractional days.
64 |
--------------------------------------------------------------------------------
/content/basics/data-sources.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Data sources"
3 | linktitle = "Data sources"
4 | weight = 3
5 | toc = "false"
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Basics"
10 |
11 | +++
12 |
13 | # Data sources
14 |
15 | This page overviews the raw system used to extract data for each of the components of MIMIC-IV.
16 |
17 |
18 | # Hospital acquired data
19 |
20 | The following tables were sourced from the hospital database, and contain information recorded in the hospital, but not necessarily during the patient's ICU stay:
21 |
22 | * ADMISSIONS
23 | * CALLOUT
24 | * CPTEVENTS
25 | * DIAGNOSES_ICD
26 | * DRGCODES
27 | * ICUSTAYS
28 | * LABEVENTS
29 | * MICROBIOLOGYEVENTS
30 | * PATIENTS
31 | * PRESCRIPTIONS
32 | * PROCEDURES_ICD
33 | * SERVICES
34 | * TRANSFERS
35 |
36 | # ICU acquired data
37 |
38 | MetaVision is a clinical information system provided by iMDSoft which acrhives and displays data at the bedside for patients cared in intensive care units as the Beth Israel Deaconness Medical Center. All of the ICU data available in the `mimic_icu` schema are sourced from MetaVision.
39 | The following tables were sourced from the ICU databases, and contain information only during a patient's ICU stay:
40 |
41 | * CHARTEVENTS
42 | * DATETIMEEVENTS
43 | * INPUTEVENTS
44 | * OUTPUTEVENTS
45 | * PROCEDUREEVENTS
46 |
47 | # Externally acquired data
48 |
49 | The `DOD_SSN` (which also contributes to the `DOD` column) is acquired from the social security death registry. It contains dates of death up to 90 days in the future for Metavision patients. It contains dates of death up to 4 years in the future for CareVue patients.
50 |
51 |
58 |
59 |
--------------------------------------------------------------------------------
/content/hosp/emar.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Electronic Medical Administration Record"
3 | linktitle = "emar"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *emar*
14 |
15 | The EMAR table is used to record administrations of a given medicine to an individual patient.
16 | Records in this table are populated by bedside nursing staff scanning barcodes associated with the medicine and the patient.
17 |
18 | ## Links to
19 |
20 | * *emar_detail* on `emar_id`
21 | * *pharmacy* on `pharmacy_id`
22 | * *prescriptions* on `poe_id`
23 | * *poe* on `poe_id`
24 |
25 |
30 |
31 | ## Table columns
32 |
33 | Name | Postgres data type
34 | ---- | ----
35 | `subject_id` | INTEGER NOT NULL
36 | `hadm_id` | INTEGER NOT NULL
37 | `emar_id` | VARCHAR(100) NOT NULL
38 | `emar_seq` | INTEGER NOT NULL
39 | `poe_id` | VARCHAR(25) NOT NULL
40 | `charttime` | TIMESTAMP NOT NULL
41 | `medication` | TEXT
42 | `event_txt` | TEXT
43 | `scheduletime` | TIMESTAMP
44 | `storetime` | TIMESTAMP NOT NULL
45 |
46 | ### `subject_id`
47 |
48 | {{% include "/static/include/subject_id.md" %}}
49 |
50 | ### `hadm_id`
51 |
52 | {{% include "/static/include/hadm_id.md" %}}
53 |
54 | ### `emar_id`, `emar_seq`
55 |
56 | 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`'.
57 |
58 | ### `poe_id`
59 |
60 | An identifier which links administrations in *emar* to orders in *poe* and *prescriptions*.
61 |
62 | ### `pharmacy_id`
63 |
64 | An identifier which links administrations in *emar* to pharmacy information in the *pharmacy* table.
65 |
66 | ### `charttime`
67 |
68 | The time at which the medication was administered.
69 |
70 | ### `medication`
71 |
72 | The name of the medication which was administered.
73 |
74 | ### `event_txt`
75 |
76 | Information about the administration. Most frequently `event_txt` is 'Administered', but other possible values are 'Applied', 'Confirmed', 'Delayed', 'Not Given', and so on.
77 |
78 | ### `scheduletime`
79 |
80 | If present, the time at which the administration was scheduled.
81 |
82 | ### `storetime`
83 |
84 | The time at which the administration was documented in the eMAR table.
85 |
--------------------------------------------------------------------------------
/content/hosp/microbiologyevents.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "*microbiologyevents*"
3 | linktitle = "*microbiologyevents*"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *microbiologyevents*
14 |
15 | Microbiology tests are a common procedure to check for infectious growth and to assess which antibiotic treatments are most effective.
16 |
17 | The table is best explained with a demonstrative example. If a blood culture is requested for a patient, then a blood sample will be taken and sent to the microbiology lab.
18 | The time at which this blood sample is taken is the `charttime`.
19 | The `spec_type_desc` will indicate that this is a blood sample.
20 | Bacteria will be cultured on the blood sample, and the remaining columns depend on the outcome of this growth:
21 |
22 | * If no growth is found, the remaining columns will be NULL
23 | * 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`).
24 | * 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`).
25 |
26 | ## Links to
27 |
28 | * d_micro on `spec_itemid`
29 | * d_micro on `test_itemid`
30 | * d_micro on `org_itemid`
31 | * d_micro on `ab_itemid`
32 |
33 |
38 |
39 | ## Table columns
40 |
41 | Name | Postgres data type
42 | ---- | ----
43 | `subject_id` | INTEGER
44 | `hadm_id` | INTEGER
45 | `stay_id` | INTEGER
46 | `spec_id` | VARCHAR(8) NOT NULL
47 | `chartdate` | TIMESTAMP(0) NOT NULL
48 | `charttime` | TIMESTAMP(0)
49 | `spec_itemid` | INTEGER NOT NULL
50 | `spec_type_desc` | VARCHAR(100) NOT NULL
51 | `test_seq` | INTEGER NOT NULL
52 | `storedate` | TIMESTAMP(0)
53 | `storetime` | TIMESTAMP(0)
54 | `test_itemid` | INTEGER
55 | `test_name` | VARCHAR(100)
56 | `test_text` | VARCHAR
57 | `org_itemid` | INTEGER
58 | `org_name` | VARCHAR(100)
59 | `isolate_num` | SMALLINT
60 | `quantity` | VARCHAR(50)
61 | `ab_itemid` | INTEGER
62 | `ab_name` | VARCHAR(30)
63 | `dilution_text` | VARCHAR(10)
64 | `dilution_comparison` | VARCHAR(20)
65 | `dilution_value` | DOUBLE PRECISION
66 | `interpretation` | VARCHAR(5)
67 |
68 | ### `subject_id`
69 |
70 | {{% include "/static/include/subject_id.md" %}}
71 |
72 | ### `hadm_id`
73 |
74 | {{% include "/static/include/hadm_id.md" %}}
75 |
--------------------------------------------------------------------------------
/content/core/patients.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Patients"
3 | linktitle = "patients"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Core Tables"
10 |
11 | +++
12 |
13 | ## *patients*
14 |
15 | Information that is consistent for the lifetime of a patient is stored in this table.
16 |
17 | ## Table columns
18 |
19 | Name | Postgres data type
20 | ---- | ----
21 | <<<<<<< HEAD
22 | `subject_id` | INTEGER
23 | `gender` | VARCHAR(1)
24 | `anchor_age` | INTEGER
25 | `anchor_year` | INTEGER
26 | `anchor_year_group` | VARCHAR(255)
27 | `dod` | TIMESTAMP(0)
28 | =======
29 | subject_id | INT
30 | GENDER | VARCHAR(5)
31 | ANCHOR\_AGE | INT
32 | ANCHOR\_YEAR | INT
33 | ANCHOR\_YEAR_SHIFTED | INT
34 | DOD | TIMESTAMP(0)
35 | >>>>>>> update patient table with anchor info
36 |
37 | ## Detailed Description
38 |
39 | ### `subject_id`
40 |
41 | `subject_id` is a unique identifier which specifies an individual patient. Any rows associated with a single `subject_id` pertain to the same individual. As `subject_id` is the primary key for the table, it is unique for each row.
42 |
43 | ### `gender`
44 |
45 | `gender` is the genotypical sex of the patient.
46 |
47 | `dod` is the date of death as recorded in the hospital database.
48 |
49 | ### `anchor_age`, `anchor_year`, `anchor_year_group`
50 |
51 | These columns provide information regarding the actual patient year for the patient admission, and the patient's age at that time.
52 |
53 | * `anchor_year` is a shifted year for the patient.
54 | * `anchor_year_group` is a range of years - the patient's `anchor_year` occurred during this range.
55 | * `anchor_age` is the patient's age in the `anchor_year`.
56 | * Example: a patient has an `anchor_year` of 2153, `anchor_year_group` of 2008 - 2010, and an `anchor_age` of 60.
57 | * The year 2153 for the patient corresponds to 2008, 2009, or 2010.
58 | * The patient was 60 in the shifted year of 2153, i.e. they were 60 in 2008, 2009, or 2010.
59 | * A patient admission in 2154 will occur in 2009-2011, an admission in 2155 will occur in 2010-2012, and so on.
60 |
61 | ## `ANCHOR_AGE`, `ANCHOR_YEAR`, `ANCHOR_YEAR_SHIFTED`
62 |
63 | `ANCHOR_AGE`, `ANCHOR_YEAR`, and `ANCHOR_YEAR_SHIFTED` are intended to be analyzed together. The `ANCHOR_AGE` is the age of the patient in the given `ANCHOR_YEAR`/`ANCHOR_YEAR_SHIFTED`. In order to determine the age of a patient on admission to the hospital, it is necessary to account for the number of years between `ANCHOR_YEAR_SHIFTED` and their hospital admission time.
64 |
65 | ## `DOD`
66 |
67 | The de-identified date of death for the patient. Date of death is extracted from the hospital information system only, and does not include out of hospital mortality as of MIMIC-IV v1.0.
68 |
--------------------------------------------------------------------------------
/content/icu/datetimesevents.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Datetimeevents"
3 | linktitle = "datetimeevents"
4 | weight = 10
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ICU Tables"
10 |
11 | +++
12 |
13 |
14 | # The datetimeevents table
15 |
16 | **Table source:** MetaVision ICU database.
17 |
18 | **Table purpose:** Contains all date formatted data.
19 |
20 | **Number of rows:** 5,988,217
21 |
22 | **Links to:**
23 |
24 | * PATIENTS on `subject_id`
25 | * ADMISSIONS on `hadm_id`
26 | * ICUSTAYS on `STAY_ID`
27 | * D_ITEMS on `itemid`
28 |
29 |
30 |
31 | # Table columns
32 |
33 |
34 | Name | Data type
35 | ---- | --------
36 | SUBJECT\_ID | Integer
37 | HADM\_ID | Integer
38 | STAY\_ID | Integer
39 | CHARTTIME | Date with times
40 | STORETIME | Date with times
41 | ITEMID | Integer
42 | VALUE | Date with times
43 | VALUEUOM | Text
44 | WARNING | Binary (0 or 1)
45 |
46 | # Detailed Description
47 |
48 | 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.
49 |
50 | ## `subject_id`, `hadm_id`, `stay_id`
51 |
52 | 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 ward stay.
53 |
54 |
60 |
61 | ## `CHARTTIME`, `STORETIME`
62 |
63 | `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.
64 |
65 | ## `ITEMID`
66 |
67 | 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).
68 |
69 | ## `VALUE`
70 |
71 | 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.
72 |
73 | ## `VALUEUOM`
74 |
75 | The unit of measurement for the value - almost always the text string "Date".
76 |
77 | ## `WARNING`
78 |
79 | `WARNING` specifies if a warning for this observation was manually documented by the care provider.
--------------------------------------------------------------------------------
/content/hosp/d_labitems.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Dimension table: lab items"
3 | linktitle = "d_labitems"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *d_labitems*
14 |
15 | *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.
16 |
17 | 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.
18 |
19 | ### Links to
20 |
21 | * LABEVENTS on `itemid`
22 |
23 | ## Important considerations
24 |
25 | * 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.
26 | We welcome improvements to the present codes or assignment of LOINC codes to unmapped data elements from the community.
27 |
28 | ## Table columns
29 |
30 | Name | Postgres data type
31 | ---- | ----
32 | `itemid` | INTEGER
33 | `label` | VARCHAR(50)
34 | `fluid` | VARCHAR(50)
35 | `category` | VARCHAR(50)
36 | `loinc_code` | VARCHAR(50)
37 |
38 | ## Detailed Description
39 |
40 | ### `itemid`
41 |
42 | 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.
43 |
44 | ### `label`
45 |
46 | The `label` column describes the concept which is represented by the `itemid`.
47 |
48 | ### `fluid`
49 |
50 | `fluid` describes the substance on which the measurement was made. For example, chemistry measurements are frequently performed on blood, which is listed in this column as 'BLOOD'. Many of these measurements are also acquirable on other fluids, such as urine, and this column differentiates these distinct concepts.
51 |
52 | ### `category`
53 |
54 | `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.
55 |
56 | ### `loinc_code`
57 |
58 | `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.
59 |
--------------------------------------------------------------------------------
/config.toml:
--------------------------------------------------------------------------------
1 | languageCode = "en-us"
2 | title = "MIMIC-IV"
3 | version = "v0.1"
4 | theme = "mimic-theme"
5 | baseurl = "https://mimic-iv.mit.edu/"
6 | canonifyurls = false
7 | googleAnalytics = ""
8 |
9 | [params]
10 | # Also be sure to update GitHub URL down below if you change this
11 | GitHubURL = "https://github.com/mit-lcp/mimic-building/"
12 |
13 | [params.button1]
14 | name = "Learn"
15 | button = "btn-primary"
16 | url = "/about/data"
17 | icon = "icon-idea"
18 |
19 | [params.button2]
20 | name = "Access"
21 | button = "btn-success"
22 | url = "/about/access"
23 | icon = "icon-arrow-down"
24 |
25 | [params.button3]
26 | name = "Code"
27 | button = "btn-dark"
28 | url = "https://github.com/mit-lcp/mimic-code/"
29 | icon = "fa fa-github fa-lg"
30 |
31 | [params.segment1]
32 | title = "MIMIC-IV"
33 | text = "MIMIC-IV is a large ED and ICU database."
34 | icon = "icon-circlestar"
35 |
36 | [params.segment2]
37 | title = "200,000+ ED stays, 60,000+ ICU stays"
38 | text = "The breadth of MIMIC-IV allows for a wide range of research studies."
39 | icon = "icon-heart"
40 |
41 | [params.segment3]
42 | title = "Multimodal data"
43 | text = "ED patients linked to free-text radiology reports and images."
44 | icon = "icon-talking"
45 |
46 | [params.acknowledgement]
47 | citation = "MIMIC-IV"
48 | bibtex = """
49 | TBD.
50 | """
51 |
52 | [[menu.main]]
53 | name = "About"
54 | pre = ""
55 | weight = 1
56 | url = "/about/"
57 | [[menu.main]]
58 | name = "Basics"
59 | pre = ""
60 | weight = 2
61 | url = "/about/"
62 | [[menu.main]]
63 | name = "Datasets"
64 | pre = ""
65 | weight = 10
66 | url = "/datasets/"
67 | [[menu.main]]
68 | name = "Core Tables"
69 | pre = ""
70 | weight = 20
71 | url = "/core/"
72 | [[menu.main]]
73 | name = "Hosp Tables"
74 | pre = ""
75 | weight = 30
76 | url = "/hosp/"
77 | [[menu.main]]
78 | name = "ICU Tables"
79 | pre = ""
80 | weight = 40
81 | url = "/icu/"
82 | [[menu.main]]
83 | name = "ED Tables"
84 | pre = ""
85 | weight = 50
86 | url = "/ed/"
87 | [[menu.main]]
88 | name = "CXR Tables"
89 | pre = ""
90 | weight = 60
91 | url = "/cxr/"
92 | [[menu.main]]
93 | name = "Tutorials"
94 | pre = ""
95 | weight = 70
96 | url = "/tutorials/"
97 | [[menu.main]]
98 | name = "GitHub"
99 | pre = ""
100 | weight = 80
101 | url = "https://www.github.com/mit-lcp/mimic-code/"
102 |
--------------------------------------------------------------------------------
/content/hosp/poe.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Provider Order Entry"
3 | linktitle = "poe"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *poe*
14 |
15 | Provider order entry (POE) is the general interface through which care providers at the hospital enter orders. Most treatments and procedures must be ordered via POE.
16 |
17 | ## Links to
18 |
19 | * *poe_detail* on `poe_id`
20 |
21 |
26 |
27 | ## Table columns
28 |
29 | Name | Postgres data type
30 | ---- | ----
31 | `poe_id` | VARCHAR(25) NOT NULL
32 | `poe_seq` | INTEGER NOT NULL
33 | `subject_id` | INTEGER NOT NULL
34 | `hadm_id` | INTEGER NOT NULL
35 | `ordertime` | TIMESTAMP NOT NULL
36 | `order_type` | VARCHAR(25)
37 | `order_subtype` | VARCHAR(50)
38 | `transaction_type` | VARCHAR(15)
39 | `discontinue_of_poe_id` | VARCHAR(25)
40 | `discontinued_by_poe_id` | VARCHAR(25)
41 | `order_status` | VARCHAR(15)
42 |
43 | ### `poe_id`
44 |
45 | A unique identifier for the given order. `poe_id` is composed of `subject_id` and a monotonically increasing integer, `poe_seq`, in the following format: `subject_id`-`poe_seq`.
46 |
47 | ### `poe_seq`
48 |
49 | A monotonically increasing integer which chronologically sorts the POE orders. That is, POE orders can be ordered sequentially by `poe_seq`.
50 |
51 | ### `subject_id`
52 |
53 | {{% include "/static/include/subject_id.md" %}}
54 |
55 | ### `hadm_id`
56 |
57 | {{% include "/static/include/hadm_id.md" %}}
58 |
59 | ### `ordertime`
60 |
61 | The date and time at which the provider order was made.
62 |
63 | ### `order_type`
64 |
65 | The type of provider order. One of the following:
66 |
67 | * ADT orders
68 | * Blood Bank
69 | * Cardiology
70 | * Consults
71 | * Critical Care
72 | * General Care
73 | * Hemodialysis
74 | * IV therapy
75 | * Lab
76 | * Medications
77 | * Neurology
78 | * Nutrition
79 | * OB
80 | * Radiology
81 | * Respiratory
82 | * TPN
83 |
84 | ### `order_subtype`
85 |
86 | Further detail on the type of order made by the provider. The `order_subtype` is best interpreted alongside the `order_type`, e.g. `order_type = 'Cardiology'` with `order_subtype = 'Holter Monitor'`.
87 |
88 | ### `transaction_type`
89 |
90 | The action which the provider performed when performing this order. One of the following:
91 |
92 | * Change
93 | * Co
94 | * D/C
95 | * H
96 | * New
97 | * T
98 |
99 | ### `discontinue_of_poe_id`, `discontinued_by_poe_id`
100 |
101 | If this order discontinues a previous order, then `discontinue_of_poe_id` will link to the previous order which was discontinued.
102 | Conversely, if this order was later discontinued by a distinct order, then `discontinued_by_poe_id` will link to that future order.
103 |
104 | ### `order_status`
105 |
106 | Whether the order is still active ('Active') or whether it has been inactivated ('Inactive').
107 |
--------------------------------------------------------------------------------
/content/about/access.md:
--------------------------------------------------------------------------------
1 | +++
2 | date = "2015-09-01T14:02:13-04:00"
3 | title = "Getting access"
4 | linktitle = "Getting access"
5 | weight = 2
6 | toc = false
7 |
8 | [menu]
9 | [menu.main]
10 | parent = "About"
11 |
12 | +++
13 |
14 | ## Getting Access
15 |
16 | Access to MIMIC-IV is strictly controlled by the LCP, and all users who wish to use MIMIC-IV must be granted approval to use the data directly by the LCP.
17 | During the final preparation phase access is made available to members of the [Critical Data Consortium](https://clinicaldata.mit.edu/).
18 |
19 | As data is distributed via Google Cloud Platform (GCP), a valid Google account is required to access the data. Accessing the data is done in three stages:
20 |
21 | 1. Users must become a credentialed user on PhysioNet with access to MIMIC-III. This process involves completing a training course in human subjects research and signing of a data use agreement. Details of this process [are available online](https://mimic.physionet.org/gettingstarted/access).
22 | 2. Users must add a valid Google account e-mail to their credentialed PhysioNet user account.
23 | 3. Users must contact mimic-support@physionet.org and request access to MIMIC-IV. The e-mail should state the name of the Consortium organization of which they are a member, and the PhysioNet account to which they would like access provisioned. The e-mail should be sent from an address associated with the Consortium organization, or have a member of the Consortium organization copied to verify your affiliation.
24 |
25 | More detail on these three steps is provided below.d
26 |
27 | ### Credentialing
28 |
29 | A user must be credentialed in order to access the database, as appropriate training is necessary for the handling of human subjects in research.
30 | Credentialing requires completion of a training course, as follows:
31 |
32 | - Register on the CITI program website, selecting “Massachusetts Institute of Technology Affiliates” as your organization affiliation: https://www.citiprogram.org/index.cfm?pageID=154&icat=0&ac=0
33 | - Follow the links to add a Massachusetts Institute of Technology Affiliates course. In the Human Subjects training category, select the “Data or Specimens Only Research” course
34 | - Complete the course and save a copy of your certificate.
35 |
36 | Once completed, register an account on PhysioNet. Navigate to the credentialing page, and apply for credentialed privileges: https://physionet.org/settings/credentialing/
37 |
38 | ### Data use agreement
39 |
40 | Once your account is credentialed, sign the data use agreement for MIMIC-III: https://physionet.org/content/mimiciii/
41 |
42 | Be sure to specify the Google Cloud Platform account you will use: https://physionet.org/settings/cloud/
43 |
44 | ### Contact us
45 |
46 | Once approved, send an e-mail to mimic-support@physionet.org with:
47 |
48 | - The Critical Data Consortium organization you are a member of
49 | - Your PhysioNet account
50 | - Your request for MIMIC-IV and acknowledgement that you will abide by the same data use agreement as MIMIC-III and the terms in the Consortium agreement
51 |
--------------------------------------------------------------------------------
/content/hosp/prescriptions.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Prescriptions"
3 | linktitle = "prescriptions"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *prescriptions*
14 |
15 | The *prescriptions* table provides information about prescribed medications. Information includes the name of the drug, coded identifiers including the Generic Sequence Number (GSN) and National Drug Code (NDC), the product strength, the formulary dose, and the route of administration.
16 |
17 | ## Links to
18 |
19 | * *poe* on `poe_id`
20 | * *pharmacy* on `pharmacy_id`
21 | * *emar* on `poe_id`
22 |
23 |
28 |
29 | ## Table columns
30 |
31 | Name | Postgres data type
32 | ---- | ----
33 | `subject_id` | INTEGER NOT NULL
34 | `hadm_id` | INTEGER NOT NULL
35 | `pharmacy_id` | INTEGER
36 | `starttime` | TIMESTAMP
37 | `stoptimetime` | TIMESTAMP
38 | `drug_type` |
39 | `drug` | TEXT
40 | `gsn` | VARCHAR(10)
41 | `ndc` | VARCHAR(20)
42 | `prod_strength` | TEXT
43 | `form_rx` |
44 | `dose_val_rx` |
45 | `dose_unit_rx` |
46 | `form_val_disp` |
47 | `form_unit_disp` |
48 | `doses_per_24_hrs` |
49 | `route` |
50 |
51 | ### `subject_id`
52 |
53 | {{% include "/static/include/subject_id.md" %}}
54 |
55 | ### `hadm_id`
56 |
57 | {{% include "/static/include/hadm_id.md" %}}
58 |
59 | ### `pharmacy_id`
60 |
61 | An identifier which links administrations in *emar* to pharmacy information in the *pharmacy* table.
62 |
63 | ### `starttime`, `stoptime`
64 |
65 | The prescribed start and stop time for the medication.
66 |
67 | ### `drug_type`
68 |
69 | The component of the prescription which the drug occupies. Can be one of 'MAIN', 'BASE', or 'ADDITIVE'.
70 |
71 | ### `drug`
72 |
73 | A free-text description of the medication administered.
74 |
75 | ### `gsn`
76 |
77 | The Generic Sequence Number (GSN), a coded identifier used for medications.
78 |
79 | ### `ndc`
80 |
81 | The National Drug Code (NDC), a coded identifier which uniquely identifiers medications.
82 |
83 | ### `prod_strength`
84 |
85 | A free-text description of the composition of the prescribed medication (e.g. '12 mg / 0.8 mL Oral Syringe', '12.5mg Tablet', etc).
86 |
87 | ### `form_rx`
88 |
89 | The container in which the formulary dose is delivered (e.g. 'TABLET', 'VIAL', etc).
90 |
91 | ### `dose_val_rx`
92 |
93 | The prescribed dose for the patient intended to be administered over the given time period.
94 |
95 | ### `dose_unit_rx`
96 |
97 | The unit of measurement for the dose.
98 |
99 | ### `form_val_disp`
100 |
101 | The amount of the medication which is contained in a single formulary dose.
102 |
103 | ### `form_unit_disp`
104 |
105 | The unit of measurement used for the formulary dosage.
106 |
107 | ### `doses_per_24_hrs`
108 |
109 | 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) would be 2, and so on.
110 |
111 | ### `route`
112 |
113 | The route of administration for the medication.
--------------------------------------------------------------------------------
/content/hosp/services.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Services"
3 | linktitle = "services"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *services*
14 |
15 | The *services* table describes the service that a patient was admitted under. While a patient can be physicially located at a given ICU type (say MICU), they are not necessarily being cared for by the team which staffs the MICU. This can happen due to a number of reasons, including bed shortage. The *services* table should be used if interested in identifying the type of service a patient is receiving in the hospital. For example, if interested in identifying surgical patients, the recommended method is searching for patients admitted under a surgical service.
16 |
17 | Each service is listed in the table as an abbreviation - this is exactly how the data is stored in the hospital database. For user convenience, we have provided a description of each service type.
18 |
19 | Service | Description
20 | --- | ---
21 | CMED | Cardiac Medical - for non-surgical cardiac related admissions
22 | CSURG | Cardiac Surgery - for surgical cardiac admissions
23 | DENT | Dental - for dental/jaw related admissions
24 | ENT | Ear, nose, and throat - conditions primarily affecting these areas
25 | GU | Genitourinary - reproductive organs/urinary system
26 | GYN | Gynecological - female reproductive systems and breasts
27 | MED | Medical - general service for internal medicine
28 | NB | Newborn - infants born at the hospital
29 | NBB | Newborn baby - infants born at the hospital
30 | NMED | Neurologic Medical - non-surgical, relating to the brain
31 | NSURG | Neurologic Surgical - surgical, relating to the brain
32 | OBS | Obstetrics - conerned with childbirth and the care of women giving birth
33 | ORTHO | Orthopaedic - surgical, relating to the musculoskeletal system
34 | OMED | Orthopaedic medicine - non-surgical, relating to musculoskeletal system
35 | PSURG | Plastic - restortation/reconstruction of the human body (including cosmetic or aesthetic)
36 | PSYCH | Psychiatric - mental disorders relating to mood, behaviour, cognition, or perceptions
37 | SURG | Surgical - general surgical service not classified elsewhere
38 | TRAUM | Trauma - injury or damage caused by physical harm from an external source
39 | TSURG | Thoracic Surgical - surgery on the thorax, located between the neck and the abdomen
40 | VSURG | Vascular Surgical - surgery relating to the circulatory system
41 |
42 | ## Links to
43 |
44 | * patients on `subject_id`
45 | * admissions on `hadm_id`
46 |
47 |
48 |
49 | ## Table columns
50 |
51 | Name | Postgres data type
52 | ---- | ----
53 | `subject_id` | INT
54 | `hadm_id` | INT
55 | `transfertime` | TIMESTAMP(0)
56 | `prev_service` | VARCHAR(20)
57 | `curr_service` | VARCHAR(20)
58 |
59 | ### `subject_id`
60 |
61 | {{% include "/static/include/subject_id.md" %}}
62 |
63 | ### `hadm_id`
64 |
65 | {{% include "/static/include/hadm_id.md" %}}
66 |
67 | ## `transfertime`
68 |
69 | `transfertime` is the time at which the patient moved from the `prev_service` (if present) to the `curr_service`.
70 |
71 | ## `prev_service`, `curr_service`
72 |
73 | `prev_service` and `curr_service` are the previous and current service that the patient resides under.
74 |
--------------------------------------------------------------------------------
/content/icu/d_items.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Dimension table: items"
3 | linktitle = "d_items"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ICU Tables"
10 |
11 | +++
12 |
13 |
14 | # The d_items table
15 |
16 | **Table source:** Metavision ICU databases.
17 |
18 | **Table purpose:** Definition table for all items in the ICU databases.
19 |
20 | **Number of rows:** 3,816
21 |
22 | **Links to:**
23 |
24 | * CHARTEVENTS on `ITEMID`
25 | * DATETIMEEVENTS on `ITEMID`
26 | * INPUTEVENTS on `ITEMID`
27 | * OUTPUTEVENTS on `ITEMID`
28 | * PROCEDUREEVENTS on `ITEMID`
29 |
30 | # Important considerations
31 |
32 | * If the `LINKSTO` column is null, then the data is currently unavailable, but planned for a future release.
33 |
34 | # Table columns
35 |
36 | Name | Postgres data type
37 | ---- | ----
38 | ITEMID | INT
39 | LABEL | VARCHAR(200)
40 | ABBREVIATION | VARCHAR(100)
41 | LINKSTO | VARCHAR(50)
42 | CATEGORY | VARCHAR(100)
43 | UNITNAME | VARCHAR(100)
44 | PARAM\_TYPE | VARCHAR(30)
45 | LOWNORMALVALUE | Floating point number
46 | HIGHNORMALVALUE | Floating point number
47 |
48 | # Detailed Description
49 |
50 | 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.
51 |
52 | ## `ITEMID`
53 |
54 | As an alternate primary key to the table, `ITEMID` is unique to each row.
55 |
56 | ## `LABEL`, `ABBREVIATION`
57 |
58 | The `LABEL` column describes the concept which is represented by the `ITEMID`. The `ABBREVIATION` column, only available in Metavision, lists a common abbreviation for the label.
59 |
60 | ## `LINKSTO`
61 |
62 | `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. IOEVENTS, CHARTEVENTS, etc).
63 |
64 | ## `CATEGORY`
65 |
66 | `CATEGORY` provides some information of the type of data the `ITEMID` corresponds to. Examples include 'ABG', which indicates the measurement is sourced from an arterial blood gas, 'IV Medication', which indicates that the medication is administered through an intravenous line, and so on.
67 |
68 | ## `UNITNAME`
69 |
70 | `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.
71 |
72 | ## `PARAM_TYPE`
73 |
74 | `PARAM_TYPE` describes the type of data which is recorded: a date, a number or a text field.
75 |
76 | ## `LOWNORMALVALUE`, `HIGHNORMALVALUE`
77 |
78 | These columns store reference ranges for the measurement. Note that a reference range encompasses the *expected* value of a measurement: values outside of this may still be physiologically plausible, but are considered unusual.
--------------------------------------------------------------------------------
/content/basics/identifiers.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Identifiers"
3 | linktitle = "Identifiers"
4 | weight = 1
5 | toc = "false"
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Basics"
10 |
11 | +++
12 |
13 |
24 |
25 | # Patient identifiers
26 |
27 | Patients are identified in the database using three possible identifiers: `subject_id`, `hadm_id`, and `stay_id`.
28 | Every unique patient is assigned a unique `subject_id`, all unique hospitalizations are assigned a unique `hadm_id`, and finally all unique ward stays are assigned a unique `transfer_id`. In this context, a ward is a distinct area of the hospital, and a new `transfer_id` is assigned to a patient if the hospital patient tracking system records that they have been moved from one room to another.
29 |
30 | However, many patients will move from one specific location to another, but practically their type of care has not changed. A good example is a patient moving bed locations within an ICU: these changes result in the patient having a new `transfer_id`, but the patient never left the ICU and we would consider this as a continuous episode of care. In order to alleviate this issue, we have created a `stay_id`, which is retained across all ward stays of the same type occurring within 24 hours of each other. That is, if a patient leaves and returns to the ICU within 24 hours, they will have the same `stay_id` for the second ICU stay.
31 |
32 | ## `subject_id`
33 |
34 | The PATIENTS table contains information for each unique `subject_id`. `subject_id` is sourced from the hospital, and is an anonymized version of a patient's medical record number.
35 |
36 | ## `hadm_id`
37 |
38 | The ADMISSIONS table contains information for each unique `hadm_id`. `hadm_id` is sourced from the hospital, and is an anonymized version of an identifier assigned to each patient hospitalization.
39 |
40 | ## `transfer_id`
41 |
42 | The TRANSFERS table contains information for each unique `transfer_id`. `transfer_id` is an artificially generated identifier which is uniquely assigned to a ward stay for an individual patient.
43 |
44 | ## `stay_id`
45 |
46 | The TRANSFERS table also contains the `stay_id`. This is an artificially generated identifier which groups reasonably contiguous episodes of care.
--------------------------------------------------------------------------------
/content/icu/chartevents.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Chartevents"
3 | linktitle = "chartevents"
4 | weight = 10
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "ICU Tables"
10 |
11 | +++
12 |
13 |
14 | # The chartevents table
15 |
16 | **Table source:** MetaVision ICU database.
17 |
18 | **Table purpose:** Contains all charted data for all patients.
19 |
20 | **Number of rows:** 264,885,089
21 |
22 | **Links to:**
23 |
24 | * PATIENTS on `subject_id`
25 | * ADMISSIONS on `hadm_id`
26 | * ICUSTAYS on `stay_id`
27 | * D_ITEMS on `itemid`
28 |
29 | # Brief summary
30 |
31 | CHARTEVENTS contains all the charted data available for a patient. During their ICU stay, the primary repository of a patient's information is their electronic chart. The electronic chart displays patients' routine vital signs and any additional information relevant to their care: ventilator settings, laboratory values, code status, mental status, and so on. As a result, the bulk of information about a patient's stay is contained in CHARTEVENTS. Furthermore, even though laboratory values are captured elsewhere (LABEVENTS), they are frequently repeated within CHARTEVENTS. This occurs because it is desirable to display the laboratory values on the patient's electronic chart, and so the values are copied from the database storing laboratory values to the database storing the CHARTEVENTS.
32 |
33 | # Important considerations
34 |
35 | * Some items are duplicated between the labevents and chartevents tables. In cases where there is disagreement between measurements, labevents should be taken as the ground truth.
36 |
37 | # Table columns
38 |
39 | Name | Data type
40 | ---- | --------
41 | SUBJECT\_ID | Integer
42 | HADM\_ID | Integer
43 | STAY\_ID | Integer
44 | CHARTTIME | Date with times
45 | STORETIME | Date with times
46 | ITEMID | Integer
47 | VALUE | Text
48 | VALUENUM | Decimal number
49 | VALUEUOM | Text
50 | WARNING | Binary (0 or 1)
51 |
52 | ## `subject_id`, `hadm_id`, `stay_id`
53 |
54 | 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 ward stay. More information about these identifiers is [available here](/basics/identifiers).
55 |
56 | ## `CHARTTIME`, `STORETIME`
57 |
58 | `CHARTTIME` records the time at which an observation was made, 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.
59 |
60 |
67 |
68 | ## `ITEMID`
69 |
70 | 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).
71 |
72 | ## `VALUE`, `VALUENUM`
73 |
74 | `VALUE` contains the value measured for the concept identified by the `ITEMID`. If this value is numeric, then `VALUENUM` contains the same data in a numeric format. If this data is not numeric, `VALUENUM` is null. In some cases (e.g. scores like Glasgow Coma Scale, Richmond Sedation Agitation Scale and Code Status), `VALUENUM` contains the score and `VALUE` contains the score and text describing the meaning of the score.
75 |
76 | ## `VALUEUOM`
77 |
78 | `VALUEUOM` is the unit of measurement for the `VALUE`, if appropriate.
79 |
80 | ## `WARNING`
81 |
82 | `WARNING` specifies if a warning for this observation was manually documented by the care provider.
--------------------------------------------------------------------------------
/content/about/whatsnew.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "What's new?"
3 | linktitle = "What's new?"
4 | weight = 5
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "About"
10 |
11 | +++
12 |
13 | # What's new in MIMIC-IV?
14 |
15 | Many users will be familiar with [MIMIC-III](http://mimic.mit.edu/), the predecessor of MIMIC-IV.
16 | A number of improvements have been made, including simplifying the structure, adding new data elements, and improving the usability of previous data elements.
17 |
18 | ## Structure
19 |
20 | The structure of MIMIC-IV is necessarily different than MIMIC-III.
21 | In MIMIC-III, the set of tables were given as one large set, with no obvious differentiation between them.
22 | In MIMIC-IV, we explicitly state the source database of each table.
23 | Not only does this clarify the data provenance, but it answers many questions regarding data coverage.
24 | For example, as the CHARTEVENTS table is sourced from the ICU clinical information system, it will only provide data for patients while they are in an ICU.
25 | Conversely, the LABEVENTS table is sourced from the hospital database, and consequently contains information for a patient's entire hospital stay.
26 |
27 | ## Contemporary
28 |
29 | MIMIC-IV contains data from 2008 - 2018 (inclusive).
30 | Tests which have been more recently introduced to MIMIC-CXR (e.g. procalcitonin) will be available.
31 |
32 | ## Years are included
33 |
34 | The date-shift strategy in MIMIC has changed.
35 | Instead of releasing the day of the week and the season, we will release the year of patient admission.
36 | This allows studying patients over time as care practices change.
37 |
38 | ### ED data
39 |
40 | Completely new to MIMIC is the inclusion of data from the emergency department (MIMIC-ED).
41 | This data covers over 200,000 patients and provides crucial information about the initial period of their hospital stay. The ED section describes the tables in MIMIC-ED. Approximately 65% of patients admitted to an ICU at the BIDMC are first seen in the emergency department.
42 |
43 | ### Chest x-ray data
44 |
45 | Imaging data is also an entirely new addition to MIMIC. The MIMIC-CXR database is [publicly available](https://physionet.org/content/mimic-cxr/). Notably, the `subject_id` identifier used in the MIMIC-CXR database is consistent with the `subject_id` used in MIMIC-IV. Therefore, all chest x-rays in MIMIC-CXR are linkable to patient stays in MIMIC-IV.
46 |
47 |
48 | ## Table-wise improvements over MIMIC-III
49 |
50 | A number of enhancements have been made to tables which may be familiar to you from MIMIC-III.
51 | Entirely new tables have also been added.
52 |
53 | ### Hospital data
54 |
55 | #### LABEVENTS
56 |
57 | * Reference ranges are now available.
58 | * A specimen identifier (`spec_id`) allows users to group all measurements made for a single specimen (e.g. all blood gas measurements from the same sample of blood).
59 | * A priority column indicates the priority level of the laboratory measure.
60 |
61 | #### MICROBIOLOGYEVENTS
62 |
63 | * Now contains the name of the test performed.
64 |
65 | #### EMAR and EMAR_DETAIL
66 |
67 | Two entirely new tables are made available, sourced from the relatively newly installed electronic Medicine Administration Record (eMAR) system.
68 | Bedside staff will scan barcodes for each individual formulary unit of a medication when administering it. This allows for a granular, high resolution record of when a medication was given.
69 |
70 | #### HCPCSEVENTS, D_HCPCS
71 |
72 | TBD.
73 |
74 | ### ICU data
75 |
76 | #### INPUTEVENTS
77 |
78 | * Ingredients are now stored in the data. Importantly, "water" is an ingredient in most inputs, and tabulating the amount of water a patient receives allows accurate estimation of the patient's fluid intake.
79 |
--------------------------------------------------------------------------------
/content/hosp/emar_detail.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "eMAR details"
3 | linktitle = "emar_detail"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *emar_detail*
14 |
15 | The *emar_detail* table contains information for each medicine administration made in the EMAR table.
16 | Information includes the associated pharmacy order, the dose due, the dose given, and many other parameters associated with the medical administration.
17 |
18 | ## Links to
19 |
20 | * *emar* on `emar_id`
21 | * *pharmacy* on `pharmacy_id`
22 |
23 |
28 |
29 | ## Table columns
30 |
31 | Name | Postgres data type
32 | ---- | ----
33 | `subject_id` | INTEGER NOT NULL
34 | `emar_id` | VARCHAR(25) NOT NULL
35 | `emar_seq` | INTEGER NOT NULL
36 | `parent_field_ordinal` | NUMERIC(5, 3)
37 | `administration_types` | VARCHAR(50)
38 | `pharmacy_id` | INTEGER
39 | `barcode_type` | VARCHAR(4)
40 | `Reason_for_No_Barcode` | TEXT
41 | `Complete_Dose_Not_Given` | VARCHAR(5)
42 | `Dose_Due` | VARCHAR(50)
43 | `Dose_Due_Unit` | VARCHAR(50)
44 | `Dose_Given` | VARCHAR(255)
45 | `Dose_Given_Unit` | VARCHAR(50)
46 | `will_remainder_of_dose_be_given` | VARCHAR(5)
47 | `Product_Amount_Given` | VARCHAR(30)
48 | `Product_Unit` | VARCHAR(30)
49 | `Product_Code` | VARCHAR(30)
50 | `Product_Description` | VARCHAR(255)
51 | `Product_Description_Other` | VARCHAR(255)
52 | `Prior_Infusion_Rate` | VARCHAR(20)
53 | `Infusion_Rate` | VARCHAR(20)
54 | `Infusion_Rate_Adjustment` | VARCHAR(50)
55 | `Infusion_Rate_Adjustment_Amount` | VARCHAR(30)
56 | `Infusion_Rate_Units` | VARCHAR(30)
57 | `Route` | VARCHAR(5)
58 | `Infusion_Complete` | VARCHAR(255)
59 | `Completion_Interval` | VARCHAR(30)
60 | `New_IV_Bag_Hung` | VARCHAR(1)
61 | `Continued_infusion_in_other_location` | VARCHAR(1)
62 | `Restart_Interval` | VARCHAR(30)
63 | `Side` | VARCHAR(10)
64 | `Site` | VARCHAR(255)
65 | `non_formulary_visual_verification` | VARCHAR(1)
66 |
67 | ### `subject_id`
68 |
69 | {{% include "/static/include/subject_id.md" %}}
70 |
71 | ### `emar_id`, `emar_seq`
72 |
73 | 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`'.
74 |
75 | ### `parent_field_ordinal`
76 |
77 | `parent_field_ordinal` delineates multiple administrations for the same eMar event, e.g. multiple formulary doses for the full dose. As eMAR requires the administrating provider to scan a barcode for *each* formulary provided to the patient, it is often the case that multiple rows in *emar_detail* correspond to a single row in *emar* (e.g. multiple pills are administered which add up to the desired dose). There is one row per eMAR order with a NULL `parent_field_ordinal`: this row usually contains the desired dose for the administration. Afterward, if there are N formulary doses, `parent_field_ordinal` will take values '1.1', '1.2', ..., '1.N'. The most common case occurs when there is only one formulary dose per medication. In this case the `emar_id` will have two rows in the *emar_detail* table: one with a NULL value for `parent_field_ordinal` (usually providing the dose due), and one row with a value of '1.1' for `parent_field_ordinal` (usually providing the actual dose administered).
78 |
79 | ### `administration_types`
80 |
81 | The type of administration, including 'IV Bolus', 'IV Infusion', 'Medication Infusion', 'Transdermal Patch', and so on.
82 |
83 | ### `pharmacy_id`
84 |
85 | An identifier which allows linking the eMAR order to pharmacy information provided in the *pharmacy* table. Note: rarely the same `emar_id` may have multiple distinct `pharmacy_id` across rows in the *emar_detail* table.
86 |
87 | ### Remaining columns
88 |
89 | The remaining columns provide information about the delivery of the formulary dose of the administered medication.
90 |
91 |
--------------------------------------------------------------------------------
/content/about/data.md:
--------------------------------------------------------------------------------
1 | +++
2 | date = "2015-09-01T19:33:17-04:00"
3 | title = "MIMIC-IV"
4 | linktitle = "MIMIC-IV"
5 | weight = 1
6 | toc = false
7 |
8 | [menu]
9 | [menu.main]
10 | parent = "About"
11 |
12 | +++
13 |
14 | ## MIMIC-IV
15 |
16 | MIMIC-IV is an update to MIMIC-III, containing hospitalized patients from 2008 - 2019 inclusive.
17 | The data is separated into ``modules'' to reflect the non-overlapping nature and distinct origins of the individual modules.
18 |
19 | There are currently five modules:
20 |
21 | - [core](/datasets/core) - admissions/transfers/stays/services - this is the hospital level patient tracking dataset
22 | - [hosp](/datasets/hosp) - hospital level data for patients: labs, micro, and electronic medication administration
23 | - [icu](/datasets/icu) - ICU level data. These are the event tables, and are identical in structure to MIMIC-III (chartevents, etc)
24 | - [ed](/datasets/ed) - data from the emergency department, fairly simple structure
25 | - [cxr](/datasets/cxr) - metadata linking CXRs to patients
26 |
27 | 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. A metadata table is being created to identify all major instances of this behavior.
28 |
29 | ## Release notes
30 |
31 | This page lists changes implemented in sequential updates to the MIMIC-CXR 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).
32 |
33 | ### Current version
34 |
35 | The current version of the database is v0.2. When referencing this version, we recommend using the full title: MIMIC-IV v0.2.
36 |
37 | ### MIMIC-IV v0.2
38 |
39 | - Updated demographics in the patient table
40 | - `anchor_year` -> `anchor_year_group`
41 | - `anchor_year_shifted` -> `anchor_year`
42 | - See the [patients table](/core/patients) for detail on these columns
43 | - *transfers*
44 | - Deleted the `los` column
45 | - *emar*
46 | - `mar_id` -> `emar_id`
47 | - `emar_id` is now a composite of `subject_id` and `emar_seq`, and has form "subject_id-emar_seq"
48 | - `emar_seq` column - a monotonically increasing integer starting with the first eMAR administration
49 | - Added `poe_id` and `pharmacy_id` columns for linking to those tables
50 | - *emar_detail*
51 | - `mar_id` -> `emar_id` (changed as above)
52 | - Deleted the `mar_detail_id` column
53 | - *hcpcsevents*
54 | - `ticket_id_seq` -> `seq_num`
55 | - *labevents*
56 | - Many previously NULL values are now populated - these were removed originally due to deidentification
57 | - Added the `comments` column. This contains deidentified free-text comments with labs. PHI is replaced with three underscores (`___`). If an entire comment is `___`, then the entire comment was scrubbed.
58 | - `spec_id` -> `specimen_id`
59 | - *microbiologyevents*
60 | - `stay_id` column removed
61 | - `spec_id` -> `micro_specimen_id`
62 | - Added the [*poe*](/hosp/poe) and [*poe_detail*](/hosp/poe_detail) tables
63 | - Documentation of provider orders for various treatments and other aspects of patient management
64 | - Added the [*prescriptions*](/hosp/prescriptions) table
65 | - Documentation of medicine prescriptions via the provider order interface
66 | - Added the [*pharmacy*](/hosp/pharmacy) table
67 | - Detailed information regarding prescriptions provided by the pharmacy including formulary dose, route, frequency, dose, and so on.
68 | - *inputevents*
69 | - Fixed an error in the calculation of the *amount* column
70 | - *icustays*
71 | - Re-derived `stay_id` - the new `stay_id` are distinct from the previous version.
72 | - *diagnosis*
73 | - Added [*diagnosis*](/ed/diagnosis) table with similar schema as the *diagnosis_icd* table.
74 | - *main*
75 | - Removed diagnosis columns from this table (inserted into *diagnosis* above)
76 |
77 | ### MIMIC-IV v0.1
78 |
79 | MIMIC-IV v0.1 was released on 15 August 2019.
80 |
--------------------------------------------------------------------------------
/content/core/admissions.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Admissions"
3 | linktitle = "admissions"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Core Tables"
10 |
11 | +++
12 |
13 | ## *admissions*
14 |
15 | The *admissions* table gives information regarding a patient's admission to the hospital. Since each unique hospital visit for a patient is assigned a unique `hadm_id`, the *admissions* table can be considered as a definition table for `hadm_id`. Information available includes timing information for admission and discharge, demographic information, the source of the admission, and so on.
16 |
17 | ### Links to
18 |
19 | * *patients* on `subject_id`
20 |
21 | ## Important considerations
22 |
23 | * The data is sourced from the admission, discharge and transfer database from the hospital (often referred to as 'ADT' data).
24 | * Organ donor accounts are sometimes created for patients who died in the hospital. These are distinct hospital admissions with very short, sometimes negative lengths of stay. Furthermore, their `deathtime` is frequently the same as the earlier patient admission's `deathtime`.
25 |
26 | ## Table columns
27 |
28 | Name | Postgres data type
29 | ---- | ----
30 | `subject_id` | INTEGER
31 | `hadm_id` | INTEGER
32 | `admittime` | TIMESTAMP(0)
33 | `dischtime` | TIMESTAMP(0)
34 | `deathtime` | TIMESTAMP(0)
35 | `admission_type` | VARCHAR(40)
36 | `admission_location` | VARCHAR(60)
37 | `discharge_location` | VARCHAR(60)
38 | `insurance` | VARCHAR(255)
39 | `language` | VARCHAR(10)
40 | `marital_status` | VARCHAR(80)
41 | `ethnicity` | VARCHAR(80)
42 | `edregtime` | TIMESTAMP(0)
43 | `edouttime` | TIMESTAMP(0)
44 | `hospital_expire_flag` | SMALLINT
45 |
46 | ## Detailed description
47 |
48 | The *admissions* table defines all hospitalizations in the database. Hospitalizations are assigned a unique random integer known as the `hadm_id`.
49 |
50 | ### `subject_id`, `hadm_id`
51 |
52 | Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. `hadm_id` ranges from 2000000 - 2999999. 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`.
53 |
54 | ### `admittime`, `dischtime`, `deathtime`
55 |
56 | `admittime` provides the date and time the patient was admitted to the hospital, while `dischtime` provides the date and time the patient was discharged from the hospital. If applicable, `deathtime` provides the time of in-hospital death for the patient. Note that `deathtime` is only present if the patient died in-hospital, and is almost always the same as the patient's `dischtime`. However, there can be some discrepancies due to typographical errors.
57 |
58 | ### `admission_type`
59 |
60 | `admission_type` is useful for classifying the urgency of the admission. There are 9 possibilities: 'AMBULATORY OBSERVATION', 'DIRECT EMER.', 'DIRECT OBSERVATION', 'ELECTIVE', 'EU OBSERVATION', 'EW EMER.', 'OBSERVATION ADMIT', 'SURGICAL SAME DAY ADMISSION', 'URGENT'.
61 |
62 | ### `admission_location`, `discharge_location`
63 |
64 | `admission_location` provides information about the location of the patient prior to arriving at the hospital. Note that as the emergency room is technically a clinic, patients who are admitted via the emergency room usually have it as their admission location.
65 |
66 | Similarly, `discharge_location` is the disposition of the patient after they are discharged from the hospital.
67 |
68 | ### `insurance`, `language`, `marital_status`, `ethnicity`
69 |
70 | The `insurance`, `language`, `marital_status`, and `ethnicity` columns provide information about patient demographics for the given hospitalization.
71 | Note that as this data is documented for each hospital admission, they may change from stay to stay.
72 |
73 | ### `edregtime`, `edouttime`
74 |
75 | The date and time at which the patient was registered and discharged from the emergency department.
76 |
77 | ### `hospital_expire_flag`
78 |
79 | This is a binary flag which indicates whether the patient died within the given hospitalization. `1` indicates death in the hospital, and `0` indicates survival to hospital discharge.
80 |
--------------------------------------------------------------------------------
/content/hosp/pharmacy.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Pharmacy"
3 | linktitle = "pharmacy"
4 | weight = 1
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Hosp Tables"
10 |
11 | +++
12 |
13 | ## *poe*
14 |
15 | Provider order entry (POE) is the general interface through which care providers at the hospital enter orders. Most treatments and procedures must be ordered via POE.
16 |
17 | ## Links to
18 |
19 | * *poe_detail* on `poe_id`
20 |
21 |
26 |
27 | ## Table columns
28 |
29 | Name | Postgres data type
30 | ---- | ----
31 | `subject_id` | INTEGER NOT NULL
32 | `hadm_id` | INTEGER NOT NULL
33 | `pharmacy_id` | INTEGER NOT NULL
34 | `starttime` | TIMESTAMP
35 | `stoptime` | TIMESTAMP
36 | `medication` |
37 | `proc_type` | VARCHAR(50) NOT NULL
38 | `status` | VARCHAR(50)
39 | `entertime` | TIMESTAMP NOT NULL
40 | `verifiedtime` | TIMESTAMP
41 | `route` |
42 | `frequency` |
43 | `disp_sched` |
44 | `infusion_type` | VARCHAR(15)
45 | `sliding_scale` | VARCHAR(1)
46 | `lockout_interval` | VARCHAR(50)
47 | `basal_rate` | REAL
48 | `one_hr_max` | VARCHAR(10)
49 | `doses_per_24_hrs` | REAL
50 | `duration` | REAL
51 | `duration_interval` | VARCHAR(50)
52 | `expiration_val` | INTEGER
53 | `expiration_unit` | VARCHAR(50)
54 | `expirationdate` | TIMESTAMP
55 | `dispensation` | VARCHAR(50)
56 | `fill_quantity` |
57 | `poe_id` | VARCHAR(25)
58 | `poe_submit_tm` | TIMESTAMP
59 | `poe_id_approval_ind` |
60 | `poe_id_indication_full` |
61 | `poe_id_ind_emp` |
62 | `poe_id_ind_preop` |
63 | `poe_id_ind_pathogen` |
64 | `poe_id_ind_cx_site` |
65 |
66 | ### `subject_id`
67 |
68 | {{% include "/static/include/subject_id.md" %}}
69 |
70 | ### `hadm_id`
71 |
72 | {{% include "/static/include/hadm_id.md" %}}
73 |
74 | ### `pharmacy_id`
75 |
76 | A unique identifier for the given pharmacy entry.
77 |
78 | ### `starttime`, `stoptime`
79 |
80 | The start and stop times for the given prescribed medication.
81 |
82 | ### `medication`
83 |
84 | The name of the medication provided.
85 |
86 | ### `ord_proc_type_full`
87 |
88 | The type of order: "IV Piggyback", "Non-formulary", "Unit Dose", and so on.
89 |
90 | ### `status_full`
91 |
92 | Whether the prescription is active, inactive, or discontinued.
93 |
94 | ### `entertime`
95 |
96 | The date and time at which the prescription was entered into the pharmacy system.
97 |
98 | ### `verifiedtime`
99 |
100 | The date and time at which the prescription was verified by a physician.
101 |
102 | ### `route`
103 |
104 | The intended route of administration for the prescription.
105 |
106 | ### `frequency`
107 |
108 | The frequency at which the medication should be administered to the patient. Many commonly used short hands are used in the frequency column.
109 | Q# indicates every # hours; e.g. "Q6" or "Q6H" is every 6 hours.
110 |
111 | ### `disp_sched`
112 |
113 | The hours of the day at which the medication should be administered, e.g. "08, 20" would indicate the medication should be administered at 8:00 AM and 8:00 PM, respectively.
114 |
115 | ### `infusion_type`
116 |
117 |
118 |
119 | ### `sliding_scale`
120 |
121 |
122 |
123 | ### `lockout_interval`
124 |
125 |
126 |
127 | ### `basal_rate`
128 |
129 |
130 |
131 | ### `one_hr_max`
132 |
133 |
134 |
135 | ### `doses_per_24_hrs`
136 |
137 | The number of expected doses per 24 hours. Note that this column can be misleading for continuously infused medications as they are usually only "dosed" once per day, despite continuous administration.
138 |
139 | ### `duration`, `duration_interval`
140 |
141 | `duration` is the numeric duration of the given dose, while `duration_interval` can be considered as the unit of measurement for the given duration. For example, often `duration` is 1 and `duration_interval` is "Doses". Alternatively, `duration` could be 8 and the `duration_interval` could be "Weeks".
142 |
143 | ### `expiration_val`
144 |
145 |
146 |
147 | ### `expiration_unit`
148 |
149 |
150 |
151 | ### `expirationdate`
152 |
153 |
154 |
155 | ### `dispensation`
156 |
157 | The source of dispensation for the medication.
158 |
159 | ### `fill_quantity`
160 |
161 | What proportion of the formulary to fill.
162 |
163 | ### `poe_id`
164 |
165 | A foreign key which links to the provider order entry order in the *prescriptions* table associated with this pharmacy record.
166 |
167 | ### `poe_submit_tm`
168 |
169 |
170 |
171 | ### `poe_id_approval_ind`
172 |
173 |
174 |
175 | ### `poe_id_indication_full`
176 |
177 |
178 |
179 | ### `poe_id_ind_emp`
180 |
181 |
182 |
183 | ### `poe_id_ind_preop`
184 |
185 |
186 |
187 | ### `poe_id_ind_pathogen`
188 |
189 |
190 |
191 | ### `poe_id_ind_cx_site`
192 |
193 |
194 |
--------------------------------------------------------------------------------
/content/about/cloud.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Cloud"
3 | linktitle = "Cloud"
4 | weight = 3
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "About"
10 |
11 | +++
12 |
13 | # MIMIC-IV
14 |
15 | We are primarily sharing MIMIC-IV via BigQuery. We highly recommend using BigQuery as we plan to roll out updates to it over the coming months, and staying on the platform will greatly simplify use of the data. If absolutely necessary, it is possible to download the data from a Google cloud bucket; instructions are provided at the end of the document.
16 |
17 | ## Sources of data
18 |
19 | ### BigQuery
20 |
21 | BigQuery is a columnar, distributed relational database management system. BigQuery accesses only the columns specified in the query, making it ideal for data analysis workflows. [Read more about BigQuery on Google.](https://cloud.google.com/bigquery/)
22 |
23 | BigQuery is available [via the web browser](https://console.cloud.google.com/bigquery).
24 |
25 | ### Adding physionet-data
26 |
27 | ### BigQuery Datasets
28 |
29 | BigQuery has a hierarchy as follows: each project can contain one or more datasets, and each dataset can contain one or more tables. The rough equivalent for a project is a relational database, and the equivalent of a dataset is a schema. Unlike MIMIC-III, MIMIC-IV has multiple datasets (schemas). This allows users to immediately know the source of the data, and simplifies understanding of the database structure.
30 |
31 | A tutorial on using BigQuery [is available online](/about/bigquery).
32 |
33 |
36 |
37 | Subsequent table by table documentation is available online:
38 |
39 | * [core](/datasets/core)
40 | * [hosp](/datasets/hosp)
41 | * [icu](/datasets/icu)
42 | * [ed](/datasets/ed)
43 | * [cxr](/datasets/cxr)
44 |
45 | ## Google Cloud bucket
46 |
47 | Google stores data in ``buckets''. Access to these buckets is controlled using the same mechanism for access control as BigQuery. There are a few methods of downloading data from buckets. We suggest one of two approaches: downloading the data via your web browser, or using the Google Cloud tools.
48 |
49 | ### Web browser download
50 |
51 | 1. Navigate to the bucket: https://console.cloud.google.com/storage/browser/mimic-iv.physionet.org
52 | 2. Ensure you are logged into the correct Google account. Use the top right icon to view and/or change your current activate Google account. We only provide access to the account given to us.
53 | 3. Select each file in turn, and click "Download".
54 |
55 | While slightly tedious, there are less than 20 files, and so this process is reasonably done.
56 |
57 | ### Google cloud tools (gsutil)
58 |
59 | 1. Download the Google Cloud SDK and follow the instructions to install it: https://cloud.google.com/storage/docs/gsutil_install
60 | 2. Open a terminal
61 | 3. Ensure you have initialized the SDK: `gcloud init`
62 | 4. (Optional) Authenticate using the approved Google account: `gsutil auth`
63 | * This is not required if you authenticated with the correct account during `gcloud init`
64 | 5. Run the below shell commands (or, copy them into a script to run). All commands are of the form: `gsutil -m cp ./`, i.e. they copy to the current folder.
65 |
66 | ```sh
67 | # core
68 | gsutil -m cp gs://mimic-iv.physionet.org/core/patients.csv.gz gs://mimic-iv.physionet.org/core/admissions.csv.gz gs://mimic-iv.physionet.org/core/stays.csv.gz gs://mimic-iv.physionet.org/core/services.csv.gz ./
69 |
70 | # hospital
71 | gsutil -m cp gs://mimic-iv.physionet.org/hosp/d_hcpcs.csv.gz gs://mimic-iv.physionet.org/hosp/d_icd_diagnoses.csv.gz gs://mimic-iv.physionet.org/hosp/d_icd_procedures.csv.gz gs://mimic-iv.physionet.org/hosp/d_labitems.csv.gz gs://mimic-iv.physionet.org/hosp/d_micro.csv.gz gs://mimic-iv.physionet.org/hosp/diagnoses_icd.csv.gz gs://mimic-iv.physionet.org/hosp/drgcodes.csv.gz gs://mimic-iv.physionet.org/hosp/hcpcsevents.csv.gz gs://mimic-iv.physionet.org/hosp/microbiologyevents.csv.gz gs://mimic-iv.physionet.org/hosp/procedures_icd.csv.gz ./
72 |
73 | # big hospital tables (>1 GB compressed) that are sharded
74 | gsutil -m cp gs://mimic-iv.physionet.org/hosp/emar_*.csv.gz gs://mimic-iv.physionet.org/hosp/emar_detail_*.csv.gz gs://mimic-iv.physionet.org/hosp/labevents_*.csv.gz ./
75 |
76 | # ICU
77 | gsutil -m cp gs://mimic-iv.physionet.org/icu/d_items.csv.gz gs://mimic-iv.physionet.org/icu/datetimeevents.csv.gz gs://mimic-iv.physionet.org/icu/icustays.csv.gz gs://mimic-iv.physionet.org/icu/outputevents.csv.gz gs://mimic-iv.physionet.org/icu/procedureevents.csv.gz ./
78 |
79 | # big ICU tables (>1 GB compressed) that are sharded
80 | gsutil -m cp gs://mimic-iv.physionet.org/icu/chartevents_*.csv.gz gs://mimic-iv.physionet.org/icu/inputevents_*.csv.gz ./
81 |
82 | # ED
83 | gsutil -m cp gs://mimic-iv.physionet.org/ed/main.csv.gz gs://mimic-iv.physionet.org/ed/medrecon.csv.gz gs://mimic-iv.physionet.org/ed/pyxis.csv.gz gs://mimic-iv.physionet.org/ed/triage.csv.gz gs://mimic-iv.physionet.org/ed/vitalsign.csv.gz gs://mimic-iv.physionet.org/ed/vitalsign_hl7.csv.gz ./
84 |
85 | # CXR
86 | gsutil -m cp gs://mimic-iv.physionet.org/cxr/cxr/record_list.csv.gz gs://mimic-iv.physionet.org/cxr/cxr/study_list.csv.gz ./
87 | ```
88 |
89 | Note this script copies into the local folder.
90 |
91 | # Documentation
92 |
93 | Once you have access to MIMIC-IV, we highly recommend you read the [database introduction](/mimic-iv). Subsequent table by table documentation is [available online](/tables/overview.md).
94 |
--------------------------------------------------------------------------------
/content/basics/times.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Times"
3 | linktitle = "Times"
4 | weight = 2
5 | toc = "false"
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "Basics"
10 |
11 | +++
12 |
13 | # Time types
14 |
15 | Time in the database is stored with one of two suffixes: `TIME` and `DATE`. If a column has `TIME` as the suffix, e.g. `CHARTTIME`, then the data resolution is down to the minute. If the column has `DATE` as the suffix, e.g. `CHARTDATE`, then the data resolution is down to the day. That means that measurements in a `CHARTDATE` column will always have 00:00:00 has the hour, minute, and second values. This does *not* mean it was recorded at midnight: it indicates that we do not have the exact time, only the date.
16 |
17 | # Date shifting
18 |
19 | All dates in the database have been shifted to protect patient confidentiality. Dates will be internally consistent for the same patient, but randomly distributed in the future. Dates of birth which occur in the present time are *not* true dates of birth. Furthermore, dates of birth which occur before the year 1900 occur if the patient is older than 89. In these cases, the patient's age at their first admission has been fixed to 300.
20 |
21 | # Time columns in the database
22 |
23 | ## `CHARTTIME` vs `STORETIME`
24 |
25 | Most data, with the exception of patient related demographics, are recorded with a time indicating when the observation was made: `CHARTTIME`. `CHARTTIME` dates back to the use of paper charts: in order to facilitate efficient observations by nursing staff, the day was separated into hourly blocks, and observations were recorded within these hourly blocks. Thus, any time one performed a measurement between the hours of 04:00 and 05:00, the data would be charted in the 04:00 block, and so on. This concept has carried forward into the electronic recording of data: even if data is recorded at 04:23, in many cases it is still charted as occurring at 04:00.
26 |
27 | `STORETIME` provides information on the recording of the data element itself. All observations in the database must be validated before they are archived into the patient medical record. The `STORETIME` provides the exact time that this validation occurred. For example, a heart rate may be charted at 04:00, but only validated at 04:40. This indicates that the care provider validated the measurement at 4:40 and indicated that it was a valid observation of the patient at 04:00.
28 | Conversely, it's also possible that the `STORETIME` occurs *before* the `CHARTTIME`. While a Glasgow Coma Scale may be charted at a `CHARTTIME` of 04:00, the observation may have been made and validated slightly before (e.g. 3:50). Again, the validation implies that the care staff believed the measurement to be an accurate reflection of the patient status at the given `CHARTTIME`.
29 |
30 | ## Summing up: `CHARTTIME` vs. `STORETIME`
31 |
32 | `CHARTTIME` is the time at which a measurement is *charted*. In almost all cases, this is the time which best matches the time of actual measurement. In the case of continuous vital signs (heart rate, respiratory rate, invasive blood pressure, non-invasive blood pressure, oxygen saturation), the `CHARTTIME` is usually exactly the time of measurement. `STORETIME` is the time at which the data is recorded in the database: logically it occurs after `CHARTTIME`, often by hours, but usually not more than that.
33 |
34 | ## CHARTDATE
35 |
36 | `CHARTDATE` is equivalent to `CHARTTIME`, except it does not contain any information on the time (all hour, minute, and seconds are 0 for these measurements).
37 |
38 | ## ADMITTIME, DISCHTIME, DEATHTIME
39 |
40 | `ADMITTIME` and `DISCHTIME` are the hospital admission and discharge times, respectively. `DEATHTIME` is the time of death of a patient if they died *in* hospital. If the patient did not die within the hospital for the given hospital admission, `DEATHTIME` will be null.
41 |
42 | ## CREATETIME, UPDATETIME, ACKNOWLEDGETIME, OUTCOMETIME, FIRSTRESERVATIONTIME, CURRENTRESERVATIONTIME
43 |
44 | `CREATETIME` is the time at which an ICU discharge was requested for a given patient. `UPDATETIME` is the time which the ICU discharge request was updated. `ACKNOWLEDGETIME` was the time at which the discharge request was acknowledged by the transfers team. `OUTCOMETIME` is the time at which the ICU discharge request was completed (with an outcome of 'Discharged' or 'Canceled'). `FIRSTRESERVATIONTIME` and `CURRENTRESERVATIONTIME` only occur for patients who require certain locations in the hospital.
45 |
46 | ## INTIME, OUTTIME
47 |
48 | `INTIME` and `OUTTIME` provide the time at which a patient entered and exited the given unit. In the ICUSTAYS table, the unit is always an ICU. In the TRANSFERS table, the unit can be any ward in the hospital.
49 |
50 | ## STARTTIME, ENDTIME
51 |
52 | For events which occur over a period of time, `STARTTIME` and `ENDTIME` provide the beginning and end time of the event. For medical infusions, these columns indicate the period over which the substance was administered.
53 |
54 | ## COMMENTS_DATE
55 |
56 | `COMMENTS_DATE` provides the time at which a cancel or edit comment was made for a given order.
57 |
58 | ## DOB, DOD, DOD_HOSP, DOD_SSN
59 |
60 | `DOB` is the patient's date of birth. If the patient is older than 89, their date of birth is set to 300 at their first admission. `DOD` is the patient's date of death: sourced either from the hospital database (`DOD_HOSP`) or the social security database (`DOD_SSN`).
61 |
62 | ## TRANSFERTIME
63 |
64 | `TRANSFERTIME` is the time at which the patient's service changes.
65 |
66 |
75 |
--------------------------------------------------------------------------------
/content/icu/inputevents.md:
--------------------------------------------------------------------------------
1 | +++
2 | date = "2015-09-01T19:34:46-04:00"
3 | title = "Inputevents"
4 | linktitle = "Inputevents"
5 | weight = 10
6 | toc = false
7 |
8 | [menu]
9 | [menu.main]
10 | parent = "ICU Tables"
11 |
12 | +++
13 |
14 | # The Inputevents table
15 |
16 | **Table source:** MetaVision ICU database.
17 |
18 | **Table purpose:** Input data for patients.
19 |
20 | **Number of rows:** 7,643,978
21 |
22 | **Links to:**
23 |
24 | * PATIENTS on `subject_id`
25 | * ADMISSIONS on `hadm_id`
26 | * ICUSTAYS on `stay_id`
27 | * D_ITEMS on `ITEMID`
28 |
29 | # Brief example
30 |
31 | 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.
32 |
33 | Let's examine an example of a patient being given norepinephrine.
34 |
35 | Item | `STARTTIME` | `ENDTIME` | `RATE` | `RATEUOM` | `ORDERID` | `LINKORDERID`
36 | ---- | ---- | ---- | ---- | ---- | ---- | ----
37 | Norepinephrine | 18:20 | 18:25 | 1 | mcg/kg/min | 8003 | 8003
38 | NaCl | 18:20 | 18:25 | 10 | ml/hr | 8003 | 8003
39 | Norepinephrine | 18:25 | 20:00 | 2 | mcg/kg/min | 8020 | 8003
40 | NaCl | 18:25 | 20:00 | 20 | ml/hr | 8020 | 8003
41 |
42 | 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.
43 |
44 | # Important considerations
45 |
46 | * 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.
47 | * A bolus will be listed as ending one minute after it started, i.e. `ENDTIME` = `STARTTIME` + 1 minute
48 |
49 | # Table columns
50 |
51 | Name | Postgres data type
52 | ---- | ----
53 | ROW\_ID | INT
54 | SUBJECT\_ID | INT
55 | HADM\_ID | INT
56 | ICUSTAY\_ID | INT
57 | STARTTIME | TIMESTAMP(0)
58 | ENDTIME | TIMESTAMP(0)
59 | ITEMID | INT
60 | AMOUNT | DOUBLE PRECISION
61 | AMOUNTUOM | VARCHAR(30)
62 | RATE | DOUBLE PRECISION
63 | RATEUOM | VARCHAR(30)
64 | STORETIME | TIMESTAMP(0)
65 | CGID | BIGINT
66 | ORDERID | BIGINT
67 | LINKORDERID | BIGINT
68 | ORDERCATEGORYNAME | VARCHAR(100)
69 | SECONDARYORDERCATEGORYNAME | VARCHAR(100)
70 | ORDERCOMPONENTTYPEDESCRIPTION | VARCHAR(200)
71 | ORDERCATEGORYDESCRIPTION | VARCHAR(50)
72 | PATIENTWEIGHT | DOUBLE PRECISION
73 | TOTALAMOUNT | DOUBLE PRECISION
74 | TOTALAMOUNTUOM | VARCHAR(50)
75 | ISOPENBAG | SMALLINT
76 | CONTINUEINNEXTDEPT | SMALLINT
77 | CANCELREASON | SMALLINT
78 | STATUSDESCRIPTION | VARCHAR(30)
79 | COMMENTS\_STATUS | VARCHAR(30)
80 | COMMENTS\_TITLE | VARCHAR(100)
81 | COMMENTS\_DATE | TIMESTAMP(0)
82 | ORIGINALAMOUNT | DOUBLE PRECISION
83 | ORIGINALRATE | DOUBLE PRECISION
84 |
85 | # Detailed Description
86 |
87 | ## `subject_id`, `hadm_id`, `stay_id`
88 |
89 | 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.
90 |
91 |
98 |
99 | ## `STARTTIME`, `ENDTIME`
100 |
101 | `STARTTIME` and `ENDTIME` record the start and end time of an input/output event.
102 |
103 | ## ITEMID
104 |
105 | 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).
106 | MetaVision `ITEMID` values are all above 220000. Since this data only contains data from MetaVision, it only contains `ITEMID` above 220000 (see [here](/mimicdata/metavision/) for details about MetaVision)
107 |
108 | ## AMOUNT, AMOUNTUOM
109 |
110 | `AMOUNT` and `AMOUNTUOM` list the amount of a drug or substance administered to the patient either between the `STARTTIME` and `ENDTIME`.
111 |
112 | ## RATE, RATEUOM
113 |
114 | `RATE` and `RATEUOM` list the rate at which the drug or substance was administered to the patient either between the `STARTTIME` and `ENDTIME`.
115 |
116 | ## STORETIME
117 |
118 | `STORETIME` records the time at which an observation was manually input or manually validated by a member of the clinical staff.
119 |
120 | ## ORDERID, LINKORDERID
121 |
122 | `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`.
123 |
124 | `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.
125 |
126 | ## ORDERCATEGORYNAME, SECONDARYORDERCATEGORYNAME, ORDERCOMPONENTTYPEDESCRIPTION, ORDERCATEGORYDESCRIPTION
127 |
128 | 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)
129 |
130 | ## PATIENTWEIGHT
131 |
132 | The patient weight in kilograms.
133 |
134 | ## TOTALAMOUNT, TOTALAMOUNTUOM
135 |
136 | 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.
137 |
138 | ## STATUSDESCRIPTION
139 |
140 | ```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:
141 |
142 | * Changed - The current delivery has ended as some aspect of it has changed (most frequently, the rate has been changed)
143 | * Paused - The current delivery has been paused
144 | * FinishedRunning - The delivery of the item has finished (most frequently, the bag containing the compound is empty)
145 | * Stopped - The delivery of the item been terminated by the caregiver
146 | * 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)
147 | * Flushed - A line was flushed.
148 |
149 | ## ISOPENBAG
150 |
151 | Whether the order was from an open bag.
152 |
153 | ## CONTINUEINNEXTDEPT
154 |
155 | If the order ended on patient transfer, this field indicates if it continued into the next department (e.g. a floor).
156 |
157 | ## CANCELREASON
158 |
159 | If the order was canceled, this column provides some explanation.
160 |
161 | ## COMMENTS\_STATUS, COMMENTS\_TITLE, COMMENTS_DATE
162 |
163 | 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.
164 |
165 | ## ORIGINALAMOUNT
166 |
167 | 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`.
168 |
169 | ## ORIGINALRATE
170 |
171 | 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`.
172 | However, these two columns are usually the same, but have minor non-clinically significant differences due to rounding error.
--------------------------------------------------------------------------------
/content/about/bigquery.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "BigQuery"
3 | linktitle = "BigQuery"
4 | weight = 4
5 | toc = false
6 |
7 | [menu]
8 | [menu.main]
9 | parent = "About"
10 |
11 | +++
12 |
13 | ## BigQuery UI
14 |
15 | The aim of this tutorial is to get you familiarized with BigQuery web UI to
16 | query/filter/aggregate/export data.
17 |
18 | This tutorial is based upon one from the [Google Healthcare datathon repository](https://github.com/GoogleCloudPlatform/healthcare).
19 | It is written with the *old* BigQuery interface, and focuses on the MIMIC-III/eICU-CRD datasets.
20 |
21 | ### Prerequisites
22 |
23 | * You should already have had a valid Google account with access to the datasets.
24 | * If you do not have a Google account, you can create one at http://www.gmail.com. You need to add this e-mail to your PhysioNet account.
25 | * Access to MIMIC-III/eICU-CRD can be done via the their PhysioNet project pages.
26 | * All users have access to the demo datasets.
27 |
28 | PhysioNet does not cover the cost of queries against `physionet-data`
29 | (though this cost is mostly trivial). In order to run queries, you will need
30 | to configure a *project* for your account, which BigQuery can then use to bill
31 | for your usage of the cloud platform. For more information on GCP projects,
32 | see [the documentation on creating and managing projects.](https://cloud.google.com/resource-manager/docs/creating-managing-projects).
33 |
34 | All PhysioNet data is hosted on the `physionet-data` project. You will only have
35 | read-access privileges to these datasets. As a result, if you would like to save
36 | the results of any queries, you will need to save them to a dataset created
37 | on your own project.
38 |
39 | ## TLDR
40 |
41 | In this section we are going to run a query to briefly showcase BigQuery's
42 | capability. The goal is to aggregate the mimic demo data to find out the
43 | correlation between age and the average length of stay in hours in ICU.
44 |
45 | Run the following query from BigQuery web interface (See "Executing Queries"
46 | section above for how to access BigQuery web interface).
47 |
48 | 
49 |
50 | ```SQL
51 | #standardSQL
52 | WITH re AS (
53 | SELECT
54 | DATETIME_DIFF(icu.outtime, icu.intime, HOUR) AS icu_length_of_stay,
55 | DATE_DIFF(DATE(icu.intime), DATE(pat.dob), YEAR) AS age
56 | FROM `physionet-data.mimiciii_demo.icustays` AS icu
57 | INNER JOIN `physionet-data.mimiciii_demo.patients` AS pat
58 | ON icu.subject_id = pat.subject_id)
59 | SELECT
60 | age,
61 | AVG(icu_length_of_stay) AS stay
62 | FROM re
63 | WHERE age < 100
64 | GROUP BY age
65 | ORDER BY age
66 | ```
67 |
68 | You can download the returned result as a CSV file and genereate a chart with
69 | your preferred tools.
70 |
71 | 
72 |
73 | The following is a scatter chart plotted from the result with Google Sheets.
74 |
75 | 
76 |
77 | ## Detailed Tutorial
78 |
79 | ### BigQuery Basics
80 |
81 | Feel free to skip this section if you are already familiar with BigQuery.
82 |
83 | #### BigQuery Table Name
84 |
85 | A BigQuery table is uniquely identified by the three-layer hierarchy of project
86 | ID, dataset ID and table name. For example in the following query:
87 |
88 | ```SQL
89 | SELECT
90 | subject_id
91 | FROM
92 | `physionet-data.mimiciii_demo.icustays`
93 | LIMIT 10
94 | ```
95 |
96 | `physionet-data.mimiciii_demo.icustays` specifies the table we are querying,
97 | where `physionet-data` is the project that hosts the datasets, `mimiciii_demo`
98 | is the name of the dataset, and `icustays` is the table name. Backticks (\`) are
99 | used as there is a non-standard character (-) in the project name. If the
100 | dataset resides in the same project, you can safely omit the project name,
101 | e.g.`my-project.my_dataset.my_table`can be written as`my_dataset.my_table`
102 | instead.
103 |
104 | #### SQL Dialect
105 |
106 | BigQuery supports 2 SQL dialects, legacy and standard. During this datathon we
107 | highly recommend using standard SQL dialect.
108 |
109 | **Follow the steps below to make sure the StandardSQL dialect is used**:
110 |
111 | 1. Click "COMPOSE QUERY" on top left corner;
112 | 2. Click "Show Options" below the input area;
113 | 3. Lastly, make sure "Use Legacy SQL" is **NOT** checked, and click "Hide Options".
114 |
115 | 
116 |
117 | Alternatively,
118 | ["#standardSQL" tag](https://cloud.google.com/bigquery/docs/reference/standard-sql/enabling-standard-sql)
119 | can be prepended to each query to tell BigQuery the dialect you are using, which
120 | is what we used in the TLDR section above.
121 |
122 | ## MIMIC-III Basics
123 |
124 | ### Dataset Exploration
125 |
126 | As mentioned previously, the datasets are hosted in a different project, which
127 | can be accessed
128 | [here](https://bigquery.cloud.google.com/dataset/physionet-data:mimiciii_demo).
129 | On the left panel, you will see the `mimiciii_demo` dataset, under which you
130 | will see the table names.
131 |
132 | To view the details of a table, simply click on it (for example the `icustays`
133 | table). Then, on the right side of the window, you will have to option to see
134 | the schema, metadata and preview of rows tabs.
135 |
136 | ### Queries
137 |
138 | Most of the following queries are adapted from the
139 | [MIMIC cohort selection tutorial](https://github.com/MIT-LCP/mimic-code/blob/master/tutorials/cohort-selection.ipynb).
140 |
141 | ## Analysis
142 |
143 | Let's take a look at a few queries. To run the queries yourself, copy the SQL
144 | statement to the input area on top of the web interface and click the red "RUN
145 | QUERY" button.
146 |
147 | ```SQL
148 | SELECT
149 | subject_id,
150 | hadm_id,
151 | icustay_id,
152 | intime,
153 | outtime,
154 | DATETIME_DIFF(outtime, intime, DAY) AS icu_length_of_stay
155 | FROM `physionet-data.mimiciii_demo.icustays`
156 | ```
157 |
158 | Let's save the result of previous query to an intermediate table for later
159 | analysis:
160 |
161 | 1. Create a dataset by clicking the caret below the search box on the left sidebar, and choose "Create new dataset";
162 | * Set dataset ID to "temp" and data expiration to 2 days;
163 | * Click "OK" to save the dataset.
164 | 2. Click "Save to table" button on the right;
165 | * Set destination dataset to "temp" and table to "icustays", use the default value for project;
166 | * Click "OK" to save the table, it usually takes less than a few seconds for demo tables.
167 |
168 | 
169 |
170 | Now let's take a look at a query that requires table joining: include the
171 | patient's age at the time of ICU admittance. This is computed by the date
172 | difference in years between the ICU intime and the patient's date of birth. The
173 | former is available in the icustays table, and the latter resides in the dob
174 | column of the patients table.
175 |
176 | ```SQL
177 | SELECT
178 | icu.subject_id,
179 | icu.hadm_id,
180 | icu.icustay_id,
181 | pat.dob,
182 | icu.icu_length_of_stay,
183 | DATE_DIFF(DATE(icu.intime), DATE(pat.dob), YEAR) AS age
184 | FROM `physionet-data.mimiciii_demo.patients` AS pat
185 | INNER JOIN `temp.icustays` AS icu
186 | ON icu.subject_id = pat.subject_id
187 | ```
188 |
189 | Again, let's save the table as "pat_icustays" in the "temp" dataset for use
190 | later. Briefly look at the age of patients when they are admitted with the
191 | following query.
192 |
193 | Now let's run the following query to produce data to generate a histrogram graph
194 | to show the distribution of patient ages in ten-year buckets (i.e. [0, 10), [10,
195 | 20), ..., [90, ∞).
196 |
197 | ```SQL
198 | WITH bu AS (
199 | SELECT
200 | CAST(FLOOR(age / 10) AS INT64) AS bucket
201 | FROM `temp.pat_icustays`)
202 | SELECT
203 | IF(bucket >= 9, ">= 90", FORMAT("%d - %d", bucket * 10, (bucket + 1) * 10)) AS age,
204 | COUNT(bucket) AS total
205 | FROM bu
206 | GROUP BY bucket
207 | ORDER BY bucket ASC
208 | ```
209 |
210 | Now click "Save to Google Sheets" button and wait 1-2 seconds until a yellow
211 | notification shows up, click "Click to view" which leads you to Google
212 | Spreadsheet in a new browser window. As you can see, the data from our last
213 | query is dumped into a spreadsheet. By clicking "Insert -> Chart" from the menu
214 | bar on top, a nice histrogram graph is automatically created for us!
215 |
216 | 
217 |
218 | If you prefer using other tools to process the final result, a CSV file can be
219 | downloaded by clicking the "Downed as CSV" button. If downloading fails because
220 | the file is too large (we highly recommend aggregating the data to a small
221 | enough result before downloading though), you can save it to a temporary table,
222 | click the caret then "Export table" button from the dropdown menu and save it to
223 | Google Cloud Storage, then you can download the file from
224 | [GCS](https://console.cloud.google.com/storage).
225 |
226 | 
227 |
228 | Now let's see if there is correlation between age and average length of stay in
229 | hours. Since we are using the age of patients when they get admitted, so we
230 | don't need to worry about multiple admissions of patients. Note that we treat
231 | the redacted ages (> 90) as noises and filter them out.
232 |
233 | ```SQL
234 | WITH re AS (
235 | SELECT
236 | DATETIME_DIFF(icu.outtime, icu.intime, HOUR) AS icu_length_of_stay,
237 | DATE_DIFF(DATE(icu.intime), DATE(pat.dob), YEAR) AS age
238 | FROM `physionet-data.mimiciii_demo.icustays` AS icu
239 | INNER JOIN `physionet-data.mimiciii_demo.patients` AS pat
240 | ON icu.subject_id = pat.subject_id)
241 | SELECT
242 | icu_length_of_stay AS stay,
243 | age
244 | FROM re
245 | WHERE age < 100
246 | ```
247 |
248 | Follow the same steps to save the result to Google Spreadsheet, by default a
249 | linear chart is generate. We will need to change the chart type to scatter chart
250 | through the chart editor on the right.
251 |
252 | ## Useful Tips
253 |
254 | ### Saving View
255 |
256 | Datathon organizers might not allow you to create new tables. However, you can
257 | save a view of a query's output to then use in later queries.
258 |
259 | 1. **Create a temporary dataset in the datathon project.** Next to the datathon
260 | project in the left side of the BigQuery UI, click the arrow and then
261 | `Create new dataset`. Give the dataset a temporary name that can be
262 | identified to your team (like 'team6temp').
263 | 1. **Save the view.** After running your query, click the button next to `Run
264 | Query` that says `Save view`. Select the temporary dataset you created and
265 | then give the view a name.
266 | 1. **Query your view.** Now you can perform a query using the syntax
267 | `project.dataset.view` like the following:
268 |
269 | ```SQL
270 | SELECT * FROM `datathon_project.team6temp.our_custom_view`;
271 | ```
272 |
273 | ### Working with DATETIME
274 |
275 | The times in the tables are stored as DATETIME objects. This means you cannot
276 | use operators like <, =, or > for comparing them.
277 |
278 | * Use the
279 | [DATETIME functions](https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions)in
280 | BigQuery. An example would be if you were trying to find things within 1
281 | hour of another event. In that case, you could use the native DATETIME_SUB()
282 | function. In the example below, we are looking for stays of less than 1 hour
283 | (where the admit time is less than 1 hour away from the discharge time).
284 | `[...] WHERE ADMITTIME BETWEEN DATETIME_SUB(DISCHTIME, INTERVAL 1 HOUR) AND
285 | DISCHTIME`
286 |
287 | * If you are more comfortable working with timestamps, you can cast the
288 | DATETIME object to a TIMESTAMP object and then use the
289 | [TIMESTAMP functions](https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions).
290 |
291 | ### Input / Output Options
292 |
293 | There are a few cases where you may want to work with files outside of BigQuery.
294 | Examples include importing your own custom Python library or saving a dataframe.
295 | [This tutorial](https://colab.research.google.com/notebooks/io.ipynb) covers
296 | importing and exporting from local filesystem, Google Drive, Google Sheets, and
297 | Google Cloud Storage.
298 |
299 | ## Closing
300 |
301 | Congratulations! You've finished the BigQuery web UI tutorial. In this tutorial
302 | we demonstrated how to query, filter, aggregate data, and how to export the
303 | result to different locations through BigQuery web UI. If you would like to
304 | explore the real data, please use `mimiciii_clinical` as the dataset name. For
305 | example, the table `mimiciii_demo.icustays` becomes `mimiciii_clinical.icustays`
306 | when you need the actual MIMIC data. Please take a look at more comprehensive
307 | examples [here](https://github.com/GoogleCloudPlatform/healthcare/blob/master/datathon/mimic_eicu/tutorials/bigquery_tutorial.ipynb) such as creating charts and training
308 | machine learning models in an interactive way (or copy the queries over to web
309 | UI to execute if you prefer) if you are interested.
310 |
--------------------------------------------------------------------------------