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数据,并将成分存储在数据表中,“水”是大多数输入的一个组成部分,将患者接受的水量制成表格,可以准确估计患者的液体摄入量。
来源:oschina
链接:https://my.oschina.net/u/4264342/blog/4479346