KDD MIMIC-IV与MIMIC-III的区别
MIMIC-IV
MIMIC-IV将MIMIC-III的数据表模块化划分，反应各个模块的数据的独立性和不同本质。包含2008年至2018年（MIMIC-III：2001年至2012年）之间进入重症监护病房的数据，增加了急救中心和胸部x光片数据。
模块化
- core - admissions/patients/transfers 医院级别的病人轨迹数据
- hosp - diagnoses_icd / drgcodes / emar / emar_detail / hcpcsevents / labevents / microbiologyevents / procedures_icd 医院级别的数据：化验，微型，电子医药管理
- icu - icustays / d_items / chartevents / datetimeevents / inputevents / outputevents / procedureevents ICU级别数据：一些events数据表
- ed - main / medrecon / pyxis / triage / vitalsign / (TBD): vitalsign_hl7 急救中心数据（新增）
- cxr - 胸部x光片数据 （新增）
表的变化
core data
patient
增加入院年份和年龄信息
| Name | Postgres data type | 说明 |
|---|---|---|
| subject_id | INTEGER | 病人编号 |
| gender | VARCHAR(1) | 性别 |
| anchor_age | INTEGER | 入院时年龄 |
| anchor_year | INTEGER | 入院年份 |
| anchor_year_group | VARCHAR(255) | 入院年份范围 |
| dod | TIMESTAMP(0) | 死亡时间 TIMESTAMP or NULL |
ED data
新增急救中心数据，MIMIC-ED，包括200,000个患者以上的数据，约有百分65的患者在进入ICU前有急救中心数据记录。
main
主表是急诊科就诊的主要跟踪表。它提供了病人进入急诊室和离开急诊室的时间。它还提供一组为患者指定的诊断。
MEDRECON
急诊科入院时，工作人员会询问患者目前正在服用哪些药物。这个过程被称为药物调节，MEDRECON表存储护理提供者的发现。
PYXIS表
提供通过PYXIS系统进行的药物管理的信息。
Chest x-ray data
新增胸部x光片数据，MIMIC-CXR
| Name | Postgres data type | 说明 |
|---|---|---|
| subject_id | INTEGER NOT NULL | 患者编号 |
| study_id | INTEGER NOT NULL | 针对片子所写的报告编号 |
| dicom_id | TEXT NOT NULL | 片子编号 |
TRIAGE
“分诊表”包含患者首次在急诊科接受分诊时的相关信息。患者在分诊时由一个护理提供者进行评估，并询问一系列问题以评估其当前的健康状况。他们的生命体征被测量，并被指定一个级别的敏锐度。根据严重程度，患者要么在候诊室等待稍后的治疗，要么优先考虑立即治疗。
VITALSIGN
急诊科入院的患者每1-4小时都要进行常规生命体征检查。这些生命体征存储在VITALSIGN表中。
VITALSIGN_HL7
遥测数据
Hospital data
增加表，参考值范围，样本编号，优先级
MICROBIOLOGYEVENTS
增加测试内容的名称
EMAR
电子医药管理记录系统，electronic Medicine Administration Record (eMAR) system, 记录药品条形码
| Name | Postgres data type | 说明 |
|---|---|---|
| subject_id | INTEGER NOT NULL | 患者编号 |
| hadm_id | INTEGER NOT NULL | 病案号 |
| emar_id | VARCHAR(100) NOT NULL | 电子医药管理记录编号 emar_id = ‘subject_id-emar_seq’. |
| emar_seq | INTEGER NOT NULL | 按时间递增的连续整数 |
| poe_id | VARCHAR(25) NOT NULL | Provider order entry (POE) 编号 |
| pharmacy_id | VARCHAR(25) NOT NULL | 药房信息 |
| charttime | TIMESTAMP NOT NULL | 操作时间 |
| medication | TEXT | 药品名称 |
| event_txt | TEXT | 操作状态 ‘Administered’, ‘Applied’, ‘Confirmed’, ‘Delayed’, ‘Not Given’.. |
| scheduletime | TIMESTAMP | 计划时间 |
| storetime | TIMESTAMP NOT NULL | 存储时间 |
EMAR_DETAIL
| Name | Postgres data type | 说明 |
|---|---|---|
| subject_id | INTEGER NOT NULL | - |
| emar_id | VARCHAR(25) NOT NULL | - |
| emar_seq | INTEGER NOT NULL | - |
| parent_field_ordinal | NUMERIC(5, 3) | 同一eMar事件的多次给药。例如，全剂量的多个处方剂量。由于eMAR要求给药提供者扫描提供给患者的每个处方集的条形码，因此通常情况下，eMAR_detail中的多行对应于eMAR中的一行。如果有N个处方剂量，则该字段序数将取值“1.1”、“1.2”、…、“1.N” |
| administration_types | VARCHAR(50) | 操作类型 ‘IV Bolus’, ‘IV Infusion’, ‘Medication Infusion’, ‘Transdermal Patch’ |
| pharmacy_id | INTEGER | pharmacy 表中的编号 |
| barcode_type | VARCHAR(4) | 条形码类型 |
| Reason_for_No_Barcode | TEXT | - |
| Complete_Dose_Not_Given | VARCHAR(5) | - |
| Dose_Due | VARCHAR(50) | - |
| Dose_Due_Unit | VARCHAR(50) | - |
| Dose_Given | VARCHAR(255) | - |
| Dose_Given_Unit | VARCHAR(50) | - |
| will_remainder_of_dose_be_given | VARCHAR(5) | - |
| Product_Amount_Given | VARCHAR(30) | - |
| Product_Unit | VARCHAR(30) | - |
| Product_Code | VARCHAR(30) | - |
| Product_Description | VARCHAR(255) | - |
| Product_Description_Other | VARCHAR(255) | - |
| Prior_Infusion_Rate | VARCHAR(20) | - |
| Infusion_Rate | VARCHAR(20) | - |
| Infusion_Rate_Adjustment | VARCHAR(50) | - |
| Infusion_Rate_Adjustment_Amount | VARCHAR(30) | - |
| Infusion_Rate_Units | VARCHAR(30) | - |
| Route | VARCHAR(5) | - |
| Infusion_Complete | VARCHAR(255) | - |
| Completion_Interval | VARCHAR(30) | - |
| New_IV_Bag_Hung | VARCHAR(1) | - |
| Continued_infusion_in_other_location | VARCHAR(1) | - |
| Restart_Interval | VARCHAR(30) | - |
| Side | VARCHAR(10) | - |
| Site | VARCHAR(255) | - |
| non_formulary_visual_verification | VARCHAR(1) | - |
POE
提供者医嘱输入（POE）是医院护理提供者下单的通用接口。大多数治疗和程序必须通过POE下单。
INPUTEVENTS
只有MetaVision数据，并将成分存储在数据表中，“水”是大多数输入的一个组成部分，将患者接受的水量制成表格，可以准确估计患者的液体摄入量。
