MIMIC 多参数ICU医疗数据集表结构
MIMICIII数据表信息
部分表格中字段解释为空，是因为该字段在其他表格中也存在，没有进行重复解释。如发现错误，可留言。
表1：admission
表来源：医院数据库。
表内容：病人的住院情况。
表行数：58976。
表间联系：通过subject_id与patients表相关。
SUBJECT_ID可能重复，重复说明该病人有多次入院。
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
行号 |
| SUBJECT_ID |
INT |
每位病人的标识 |
| HADM_ID |
INT |
每行一个，代表病人入住医院记录 |
| ADMITTIME |
TIMESTAMP(0) |
入院时间 |
| DISCHTIME |
TIMESTAMP(0) |
出院时间 |
| DEATHTIME |
TIMESTAMP(0) |
住院期间死亡的才有值，通常=DISCHTIME |
| ADMISSION_TYPE |
VARCHAR(50) |
住院类型 ‘ELECTIVE’:计划好的入院 ‘URGENT’和‘EMERGENCY’:意料之外的入院 ‘NEWBORN’:新生儿 |
| ADMISSION_LOCATION |
VARCHAR(50) |
入院前病人的位置信息(9个取值) EMERGENCY ROOM ADMIT TRANSFER FROM HOSP/EXTRAM TRANSFER FROM OTHER HEALT CLINIC REFERRAL/PREMATURE ** INFO NOT AVAILABLE ** TRANSFER FROM SKILLED NUR TRSF WITHIN THIS FACILITY HMO REFERRAL/SICK PHYS REFERRAL/NORMAL DELI |
| DISCHARGE_LOCATION |
VARCHAR(50) |
出院位置 |
| INSURANCE |
VARCHAR(255) |
保险，人口统计信息 |
| LANGUAGE |
VARCHAR(10) |
语言，人口统计信息 |
| RELIGION |
VARCHAR(50) |
宗教信仰，人口统计信息 |
| MARITAL_STATUS |
VARCHAR(50) |
婚姻状态，人口统计信息 |
| ETHNICITY |
VARCHAR(200) |
种族，人口统计信息 |
| EDREGTIME |
TIMESTAMP(0) |
进入急诊部的时间 |
| EDOUTTIME |
TIMESTAMP(0) |
搬离急诊部的时间 |
| DIAGNOSIS |
VARCHAR(300) |
诊断，自由文本，最终会议ICD形式在Diagnoses表中给出 |
| HOSPITAL_EXPIRE_FLAG |
TINYINT |
医院专家标志？ |
| HAS_CHARTEVENTS_DATA |
TINYINT |
是否有图表(chartevent)数据。 |
表2：callout
表来源：医院数据库。
表内容：提供病人准备从ICU转出或者已经从ICU转出时相关信息。
表行数：34499。
表间联系：通过subject_id与patients表相关；
通过hadm_id与admissions表相关。
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
行号 |
| SUBJECT_ID |
INT |
每位病人标志符 |
| HADM_ID |
INT |
入院记录标志符 |
| SUBMIT_WARDID |
INT |
提交出院申请的病房ID |
| SUBMIT_CAREUNIT |
VARCHAR(15) |
SUBMIT_WARDID是否与ICU费用中心相对应，如果是的话，是什么类型的ICU费用中心 |
| CURR_WARDID |
INT |
病人callout时所在的病房ID |
| CURR_CAREUNIT |
VARCHAR(15) |
CURR_WARDID对应哪个ICU费用中心 |
| CALLOUT_WARDID |
INT |
病人从哪个病房出院 =0代表‘Home’ =1代表‘First available ward’ |
| CALLOUT_SERVICE |
VARCHAR(10) |
病人出院的服务 |
| REQUEST_TELE |
SMALLINT |
值为二进制，表示病人是否要求了某种预防措施 |
| REQUEST_RESP |
SMALLINT |
同上 |
| REQUEST_CDIFF |
SMALLINT |
同上 |
| REQUEST_MRSA |
SMALLINT |
同上 |
| REQUEST_VRE |
SMALLINT |
同上 |
| CALLOUT_STATUS |
VARCHAR(20) |
呼叫状态 |
| CALLOUT_OUTCOME |
VARCHAR(20) |
病人最终是否出院 ‘Discharged’ or ‘Cancelled’ |
| DISCHARGE_WARDID |
INT |
病人出院的病房号。0代表home |
| ACKNOWLEDGE_STATUS |
VARCHAR(20) |
对callout请求的处理 ‘Acknowledged’‘Revised’‘Unacknowledged‘Reactivated’. |
| CREATETIME |
TIMESTAMP(0) |
callout请求发起时间 |
| UPDATETIME |
TIMESTAMP(0) |
callout请求变更时间 |
| ACKNOWLEDGETIME |
TIMESTAMP(0) |
callout请求首次应答时间 |
| OUTCOMETIME |
TIMESTAMP(0) |
记录CALLOUT_OUTCOME的时间 |
| FIRSTRESERVATIONTIME |
TIMESTAMP(0) |
病房预定信息 |
| CURRENTRESERVATIONTIME |
TIMESTAMP(0) |
病房预定信息 |
表3：caregivers
数据来源：Carevue 与Metavision数据库。
数据表内容：记录医护人员信息。
数据行数：7567。
表间联系：通过cgid与chartevents表相关。
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| CGID |
INT |
医护人员ID |
| LABEL |
VARCHAR(15) |
定义了医护人员的类型，例如 RN，MD，PharmD等 |
| DESCRIPTION |
VARCHAR(30) |
医护人员的附加信息 |
表4：chartevents
表来源：Carevue 与Metavision数据库。
表内容：记录所有病人的图表数据。
表行数：330,712,483。
表间联系：
通过 SUBJECT_ID与PATIENTS表相关
通过HADM_ID与ADMISSIONS相关
通过ICUSTAY_ID与ICUSTAYS相关
通过ITEMID与D_ITEMS相关
通过 CGID与CAREGIVERS 相关
简介：chartevent包含了所有可供患者使用的图表数据。在他们的ICU停留期间，病人信息的主要存储库是他们的电子图表。电子图表显示病人的日常生命体征和与他们的护理有关的任何额外信息：呼吸机设置、实验室值、代码状态、精神状态等等。因此，关于病人住院的大部分信息都包含在chartevent中。此外，即使在其他地方捕获了实验室值（labevent），它们也经常在chartevent中重复。这是因为在病人的电子图上显示实验室值是可取的，因此这些值是从存储实验室值的数据库复制到存储chartevent的数据库中。当labevent中的值与chartevent中的值不同时，以labevent中的值为准。
| Name |
Postgres data type |
In CareVue |
In Metavision |
字段含义 |
| ROW_ID |
INT |
Y |
Y |
行号 |
| SUBJECT_ID |
NUMBER(7,0) |
Y |
Y |
每个病人都不一样，病人标识 |
| HADM_ID |
NUMBER(7,0) |
Y |
Y |
每次住院都不一样，住院标识 |
| ICUSTAY_ID |
NUMBER(7,0) |
Y |
Y |
每次住ICU都不一样，ICU入住标识 |
| ITEMID |
NUMBER(7,0) |
Y |
Y |
测量类型标志符 |
| CHARTTIME |
DATE |
Y |
Y |
观测进行的时间 |
| STORETIME |
DATE |
Y |
Y |
记录值被人工验证输入系统的时间 |
| CGID |
NUMBER(7,0) |
Y |
Y |
医护人员标识 |
| VALUE |
VARCHAR2(200 BYTE) |
Y |
Y |
ITEMID标识的项目测量的值。如果这个值是数字，那么VALUENUM以数字格式包含相同的数据。如果这个数据不是数字，那么VALUENUM就是null |
| VALUENUM |
NUMBER |
Y |
Y |
在某些情况下（例如格拉斯哥昏迷量表、里士满镇静激动量表和代码状态），VALUENUM包含分数和值，其中包含分数和文本，描述了分数的含义。 |
| VALUEUOM |
VARCHAR2(20 BYTE) |
Y |
Y |
是value的度量单位 |
| WARNING |
NUMBER(1,0) |
|
Y |
警告和错误是Metaversion特定的列，提出某些值增高了记录在警告中 |
| ERROR |
NUMBER(1,0) |
|
Y |
在测量过程中发生了错误 |
| RESULTSTATUS |
VARCHAR2(20 BYTE) |
Y |
|
CareVue特定的列，指定测量的类型（结果状态是手动的或自动的） |
| STOPPED |
VARCHAR2(20 BYTE) |
Y |
|
CareVue特定的列，是否停止了测量 |
表5：cptevents （current procedural terminology）
表来源：医院数据库。
表内容：包含当前的程序（CPT）代码，它有助于为病人的程序进行计费。
行数：573146。
表间联系：通过subject_id与patients关联；
通过hadm_id与admissions关联。
简介：cptevent表包含了一个列表，列出了当前的程序术语代码，供哪些患者使用。每个代码表示在ICU停留期间对患者执行的不同过程。
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| COSTCENTER |
VARCHAR(10) |
为相应的CPT代码收费的成本中心。 有两种可能的成本中心：'ICU'和'Resp'。 “Resp”代码对应于机械或非侵入性通气，由呼吸治疗师收费。 “ICU”代码对应于ICU计费的程序 |
| CHARTDATE |
TIMESTAMP(0) |
治疗发生的时间 |
| CPT_CD |
VARCHAR(10) |
CPT_Code,治疗代码 |
| CPT_NUMBER |
INT |
CPT_CD列的数字形式，方便查询时进行范围比较。CPT_CD并非都是数字都是 |
| CPT_SUFFIX |
VARCHAR(5) |
当CPT_CD包含非数字字符时，CPT_SUFFIX列包含文本后缀 |
| TICKET_ID_SEQ |
INT |
CPT_CD顺序 |
| SECTIONHEADER |
VARCHAR(50) |
标题，标志CPT类别，是使用D_CPT表分配 |
| SUBSECTIONHEADER |
VARCHAR(300) |
子标题，标志CPT类别，是使用D_CPT表分配 |
| DESCRIPTION |
VARCHAR(200) |
有对应的呼吸成本中心的CPT代码时，该列解释代码意义，否则为空 |
表6：d_cpt
表来源：在线定义。
表内容：当前程序术语（CPT）代码的高级定义。
行数：134。
表关联：CPT_CD上的CPTEVENTS介于MINCODEINSUBSECTION和MAXCODEINSUBSECTION之间。
简介：这个表给出了关于当前程序术语（CPT）代码的一些高级信息。提供了程序(procedure)的目的，并在某些情况下提供了治疗程序的正文。但对于单个代码的详细信息是不可用的。注意：与所有其他表不同，D_CPT与CPTEVENTS中的CPT_CD并没有并没有一个一对一的映射，而D_CPT的每一行都映射到CPT_CD的范围内。？？？
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| CATEGORY |
SMALLINT |
数字，定义CPT_Code的类别 |
| SECTIONRANGE |
VARCHAR(100) |
给定部分的代码范围 |
| SECTIONHEADER |
VARCHAR(50) |
对给定部分的描述，有8个可能的部分 Evaluation and management Surgery Radiology Anesthesia 麻醉 Emerging technology Pathology and laboratory Performance measurement Medicine
|
| SUBSECTIONRANGE |
VARCHAR(100) |
对给定子部分的代码范围 |
| SUBSECTIONHEADER |
VARCHAR(300) |
对给定子部分的描述 |
| CODESUFFIX |
VARCHAR(5) |
当CPT_CD包含非数字字符时，CPT_SUFFIX列包含文本后缀 |
| MINCODEINSUBSECTION |
INT |
SUBSECTIONRANGE中的最小值 |
| MAXCODEINSUBSECTION |
INT |
SUBSECTIONRANGE中的最大值 |
表7：prescriptions
表来源：医院供货商订单输入数据库。
表内容：包含药物相关的订单条目，即处方。
行数：4,156,450
表关联：通过subject_id与patients关联
通过hadm_id与admissions关联
通过icustay_id与icustays关联
表简介：如果订单之后作为MIMICIII V1.0取消时，表中不会指出。
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| ICUSTAY_ID |
INT |
|
| STARTDATE |
TIMESTAMP(0) |
与ENDDATE一起制定处方有效的日期 |
| ENDDATE |
TIMESTAMP(0) |
与STARTDATE一起制定处方有效的日期 |
| DRUG_TYPE |
VARCHAR(100) |
药品的类型 |
| DRUG |
VARCHAR(100) |
药品名称 |
| DRUG_NAME_POE |
VARCHAR(100) |
药品名称 |
| DRUG_NAME_GENERIC |
VARCHAR(100) |
药品名称 |
| FORMULARY_DRUG_CD |
VARCHAR(120) |
标准药品编码，字符形式 |
| GSN |
VARCHAR(200) |
通用序列号（也是药品编码），数字形式 |
| NDC |
VARCHAR(120) |
国家（美国）药品编码，数字形式 |
| PROD_STRENGTH |
VARCHAR(120) |
|
| DOSE_VAL_RX |
VARCHAR(120) |
剂量值 |
| DOSE_UNIT_RX |
VARCHAR(120) |
剂量单位（片/ml..） |
| FORM_VAL_DISP |
VARCHAR(120) |
同上，剂量值 |
| FORM_UNIT_DISP |
VARCHAR(120) |
剂量单位 |
| ROUTE |
VARCHAR(120) |
给药途径（口服PO/静脉注射IV/肌肉注射IM/静脉滴注IV DRIP/皮下注射SC） |
表8：inputevents_cv
注：input是进入病人体内的流体，output是从病人体内排出或抽取的体液。
表来源：CareVue ICU数据库。
表内容：患者输入数据。
行数：17,527,935。
表关联：通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联
通过ICUSTAY_ID与ICUSTAYS关联
通过ITEMID与D_ITEMS 关联
通过CGID与CAREGIVERS 关联
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| ICUSTAY_ID |
INT |
|
| CHARTTIME |
TIMESTAMP(0) |
表示测量图表的时间 - 即记录在床边的临床信息系统。 对于收到的数量（通常是交易量），CHARTTIME表示收到该交易量的时间。 也就是说，它可以被认为是“结束时间”，即通过该CHARTTIME向患者施用X毫升溶液。 对于速率，CHARTTIME表示设定该速率的时间。 也就是说，它可以被认为是“开始时间”，即患者现在在该CHARTTIME接受X mcg / kg / min的药物。 |
| ITEMID |
INT |
数据库中单个测量类型的标识符。 与一个ITEMID（例如212）相关联的每一行对应于相同测量的实例化（例如，心率）。 Metavision ITEMID值均高于220000.CareVue数据中常用药物的子集的ITEMID值介于30000-39999之间。 剩余的输入/输出ITEMID值介于40000-49999之间 |
| AMOUNT |
DOUBLE PRECISION |
AMOUNT和AMOUNTUOM列出在STARTTIME和ENDTIME之间（如果两者都可用）或在ENDTIME（当确切的开始时间未知，但通常最多一小时之前）给予患者的药物或物质的量 |
| AMOUNTUOM |
VARCHAR(30) |
|
| RATE |
DOUBLE PRECISION |
RATE和RATEUOM列出了药物或物质在STARTTIME和ENDTIME之间（如果两者都可用）给予患者的速率，或者列出了药物目前在ENDTIME给药的速率 |
| RATEUOM |
VARCHAR(30) |
|
| STORETIME |
TIMESTAMP(0) |
记录手动输入观察或由临床人员手动验证的时间 |
| CGID |
BIGINT |
|
| ORDERID |
BIGINT |
ORDERID将同一解决方案中包含的多个项目链接在一起。 例如，当给予去甲肾上腺素和生理盐水的溶液时，去甲肾上腺素和生理盐水都出现在不同的行上但具有相同的ORDERID |
| LINKORDERID |
BIGINT |
LINKORDERID在多个实例中链接相同的顺序：例如，如果更改了使用去甲肾上腺素和生理盐水的解决方案的速率，将生成两个共享相同新ORDERID的新行，但LINKORDERID将是相同的。 |
| STOPPED |
VARCHAR(30) |
表示输液是否已断开或继续 |
| NEWBOTTLE |
INT |
表示是否在床边悬挂了新的溶液制剂 |
| ORIGINALAMOUNT |
DOUBLE PRECISION |
|
| ORIGINALAMOUNTUOM |
VARCHAR(30) |
|
| ORIGINALROUTE |
VARCHAR(30) |
|
| ORIGINALRATE |
DOUBLE PRECISION |
|
| ORIGINALRATEUOM |
VARCHAR(30) |
|
| ORIGINALSITE |
VARCHAR(30) |
|
表9：inputeevents_mv
表来源：Metavision ICU数据库。
表目的：患者输入数据。
行数：3,618,991。
表关联：通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联
通过ICUSTAY_ID与ICUSTAYS关联
通过ITEMID与D_ITEMS 关联
通过CGID与CAREGIVERS 关联
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
同inputevent_cv |
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| ICUSTAY_ID |
INT |
|
| STARTTIME |
TIMESTAMP(0) |
|
| ENDTIME |
TIMESTAMP(0) |
|
| ITEMID |
INT |
|
| AMOUNT |
DOUBLE PRECISION |
|
| AMOUNTUOM |
VARCHAR(30) |
|
| RATE |
DOUBLE PRECISION |
|
| RATEUOM |
VARCHAR(30) |
|
| STORETIME |
TIMESTAMP(0) |
|
| CGID |
BIGINT |
|
| ORDERID |
BIGINT |
|
| LINKORDERID |
BIGINT |
|
| ORDERCATEGORYNAME |
VARCHAR(100) |
管理类型？ |
| SECONDARYORDERCATEGORYNAME |
VARCHAR(100) |
二级管理类型 |
| ORDERCOMPONENTTYPEDESCRIPTION |
VARCHAR(200) |
描述药物成分在治疗方案中的作用 |
| ORDERCATEGORYDESCRIPTION |
VARCHAR(50) |
描述药物类别在治疗方案中的作用 |
| PATIENTWEIGHT |
DOUBLE PRECISION |
病人体重 |
| TOTALAMOUNT |
DOUBLE PRECISION |
通常通过在床边悬挂一袋液体实现在一段时间内连续输注来进行静脉给药。 TOTALAMOUNT和TOTALAMOUNTUOM列出了包含溶液的袋中的流体总量 |
| TOTALAMOUNTUOM |
VARCHAR(50) |
|
| ISOPENBAG |
SMALLINT |
|
| CONTINUEINNEXTDEPT |
SMALLINT |
是否进入下一个部门 |
| CANCELREASON |
SMALLINT |
（治疗）命令取消的原因 |
| STATUSDESCRIPTION |
VARCHAR(30) |
输液停止的原因。6种状态 |
| COMMENTS_STATUS |
VARCHAR(30) |
（治疗）命令是否已编辑或取消 |
| COMMENTS_TITLE |
VARCHAR(100) |
取消或编辑订单的人的职位 |
| COMMENTS_DATE |
TIMESTAMP(0) |
取消或编辑订单的人的日期 |
| ORIGINALAMOUNT |
DOUBLE PRECISION |
药物的剩余量 |
| ORIGINALRATE |
DOUBLE PRECISION |
原始输液速率 |
表10：outputevent
表来源：CareVue和Metavision ICU数据库。
表目的：患者的输出数据。
行数：4,349,218。
表关联：通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联
通过ICUSTAY_ID与ICUSTAYS关联
通过ITEMID与D_ITEMS 关联
通过CGID与CAREGIVERS 关联
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| ICUSTAY_ID |
INT |
|
| CHARTTIME |
TIMESTAMP(0) |
输出时间 |
| ITEMID |
INT |
|
| VALUE |
DOUBLE PRECISION |
VALUE和VALUEUOM列出CHARTTIME中物质（）的数量（当确切的开始时间未知时，通常最多一个小时）。 |
| VALUEUOM |
VARCHAR(30) |
|
| STORETIME |
TIMESTAMP(0) |
医护人员手动验证和输入数据的时间 |
| CGID |
BIGINT |
|
| STOPPED |
VARCHAR(30) |
(治疗)命令是否被中止 |
| NEWBOTTLE |
INT |
是否有新药 |
| ISERROR |
SMALLINT |
Metavision复选框，护理人员可以指定观察是一个错误 |
表11：labevents
表来源：医院数据库。
表目的：包含给定患者的所有实验室测量值，包括患者数据。
行数：27,854,055。
表间关联：通过SUBJECT_ID与PATIENTS
通过HADM_ID与ADMISSIONS
通过ITEMID与D_LABITEMS
注：labevents和chartevents表之间有些项目相同。如果测量结果之间存在分歧，则应将labevent作为基本事实。
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| ITEMID |
INT |
测量类型标志符 |
| CHARTTIME |
TIMESTAMP(0) |
记录观察图表的时间。 由于数据直接来自实验室数据库，因此未经ICU临床工作人员验证，因此没有相关的STORETIME |
| VALUE |
VARCHAR(200) |
VALUE包含为ITEMID标识的概念测量的值。 如果此值为数字，则VALUENUM以数字格式包含相同的数据。 如果此数据不是数字，则VALUENUM为空。 在某些情况下（例如格拉斯哥昏迷量表，里士满镇静激动量表和代码状态等分数），VALUENUM包含分数，VALUE包含分数和描述分数含义的文本 |
| VALUENUM |
DOUBLE PRECISION |
|
| VALUEUOM |
VARCHAR(20) |
VALUE的单位 |
| FLAG |
VARCHAR(20) |
采用预定阈值指示实验室值是否正常 |
表12:d_icd_diagnoses
表来源：在线资源。
表目的：ICD诊断的定义表。
行数：14,567。
表间关联：通过ICD9_CODE与DIAGNOSES关联。
简介:该表定义了DIAGNOSES的ICD-9代码。这些代码在病人住院的最后时间点给出，用来对住院期间给与的医疗服务计费。
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| ICD9_CODE |
VARCHAR(10) |
ICD9_CODE，每个Code代表一个诊断 |
| SHORT_TITLE |
VARCHAR(50) |
对给定代码的简单描述 |
| LONG_TITLE |
VARCHAR(300) |
同上 |
表13：d_icd_procedures
表来源：在线资源。
表目的：ICD程序的定义表。
行数：3,882。
表间关联：通过ICD9_CODE与PROCEDURES_ICD关联。
简介:该表定义了PROCEDURES的ICD-9代码。这些代码在病人住院的最后时间点给出，用来对住院期间给与的医疗服务计费。还可用来观测执行了哪些治疗程序。
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| ICD9_CODE |
VARCHAR(10) |
ICD9_CODE，每个Code代表一个procedure |
| SHORT_TITLE |
VARCHAR(50) |
对给定代码的简单描述 |
| LONG_TITLE |
VARCHAR(300) |
同上 |
表14：d_items
表来源：CareVue和Metavision ICU数据库。
表目的：ICU数据库中所有项目的定义表。
行数：12,487
表间关联：
通过ITEMID与CHARTEVENTS关联
通过ITEMID与DATETIMEEVENTS关联
通过ITEMID与INPUTEVENTS_CV关联
通过ITEMID与INPUTEVENTS_MV关联
通过SPEC_ITEMID，ORG_ITEMID或AB_ITEMID与MICROBIOLOGYEVENTS （例如，使用d_items.ITEMID = microbiologyevents.SPEC_ITEMID）
通过ITEMID与OUTPUTEVENTS关联
通过ITEMID与PROCEDUREEVENTS_MV关联
简介：D_ITEMS来自两个不同的ICU数据库。每个概念都有重复的ITEMID。
例如：心率被可以为211的ITEMID（CareVue）和220045的ITEMID（Metavision）。 ITEMID重复的另一个原因是CareVue中数据输入的自由文本，单个概念的拼写错误或同义描述，可能导致出现多个相同ITEMID。
每个ICU数据库系统都有自己的ITEMID集来表示单一概念。
所有Mentavision的ITEMNID>220000。
ITEMID列是此表的备用主键：每一行的ITEMID都是唯一的。
如果LINKSTO列为null，则数据当前不可用，但计划用于未来的版本。
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| ITEMID |
INT |
表d_item的备用主键 |
| LABEL |
VARCHAR(200) |
表明ITEMID代表的值 |
| ABBREVIATION |
VARCHAR(100) |
Metavision特有，LABEL的缩写 |
| DBSOURCE |
VARCHAR(20) |
表明数据库是Metavision还是Carevue |
| LINKSTO |
VARCHAR(50) |
数据链接到的表名 |
| CATEGORY |
VARCHAR(100) |
ITEMID对应的数据类型，如‘IV Medication’表示药物通过静脉注射 |
| UNITNAME |
VARCHAR(100) |
ITEMID表示的测量方法的单位 |
| PARAM_TYPE |
VARCHAR(30) |
描述记录的数据类型：日期，数字或文本字段。 |
| CONCEPTID |
INT |
未知，数据表中该列全为空 |
表15：d_labitems
表来源：医院数据库。
表目的：所有实验室测量的定义表。
行数：753
表间联系：通过ITEMID与LABEVENTS关联
简介：包含了所有与实验室检测相关的ITEMID。表LABEVENTS中的所有数据都链接到D_LABITEMS表。 医院数据库中每个唯一的LABEL都在此表中分配了一个ITEMID，使用此ITEMID可以有效地存储和查询数据。实验室项目是分开的，大多数项目定义都包含在D_ITEMS表中。
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| ITEMID |
INT |
实验室检测项目的ITEMID |
| LABEL |
VARCHAR(100) |
ITEMID代表的意思 |
| FLUID |
VARCHAR(100) |
描述检测的液体是什么，血液/尿液/... |
| CATEGORY |
VARCHAR(100) |
ITEMID对应的数据类型,“ABG”类别表示测量是动脉血气 |
| LOINC_CODE |
VARCHAR(100) |
LOINC_CODE包含与给定ITEMID关联的LOINC代码。 LOINC是一种本体，最初指定了实验室测量，但后来扩展到涵盖了广泛的临床相关概念。 LOINC公开提供一个表，其中包含有关每个LOINC代码的大量详细信息。 该表可在线免费获取，也可由数据库的监护人提供。??? |
表16：datetimeevents
表来源：CareVue和Metavision ICU数据库。
表目的：包含所有日期格式的数据。
行数：4,485,937
表间联系：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联
通过ICUSTAY_ID与ICUSTAYS关联
通过ITEMID与D_ITEMS关联
通过CGID与CAREGIVERS关联
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| ICUSTAY_ID |
INT |
|
| ITEMID |
INT |
项目ID |
| CHARTTIME |
TIMESTAMP(0) |
记录进行检测的时间 |
| STORETIME |
TIMESTAMP(0) |
由医护人员人工验证数据记录到系统的时间 |
| CGID |
INT |
医护人员ID |
| VALUE |
TIMESTAMP(0) |
|
| VALUEUOM |
VARCHAR(50) |
|
| WARNING |
SMALLINT |
|
| ERROR |
SMALLINT |
|
| RESULTSTATUS |
VARCHAR(50) |
|
| STOPPED |
VARCHAR(50) |
|
表17：diagnoses_icd
表来源：医院数据库。
表目的：包含患者的ICD诊断，最明显的是ICD-9诊断。
行数：651,047
表间联系：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联
通过ICD9_CODE与D_ICD_DIAGNOSES关联
| Name |
PostgreSQL data type |
Modifiers |
Description |
| ROW_ID |
INT |
not null |
|
| SUBJECT_ID |
INT |
not null |
|
| HADM_ID |
INT |
not null |
|
| SEQ_NUM |
INT |
|
SEQ_NUM提供ICD诊断与患者相关的顺序。 ICD诊断按优先级排序 |
| ICD9_CODE |
VARCHAR(10) |
|
与给定用户相关联的诊断代码 |
表18：drgcodes
表来源：医院数据库。
表目的：包含患者的诊断相关组（DRG）代码。
行数：125,557
表间联系：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联
简介：HCFA-DRG代码具有多个描述，因为它们随时间而变化。 有时这些描述是相似的，但有时它们是完全不同的诊断。 用户需要使用代码和描述来选择行。
| Name |
PostgreSQL data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| DRG_TYPE |
VARCHAR(20) |
提供DRG代码的类型。 数据库中有两种类型的DRG代码，具有重叠的范围，'HCFA'（Health Care Financing Administration）和'APR'（All Payers Registry）。 |
| DRG_CODE |
VARCHAR(20) |
诊断代码 |
| DESCRIPTION |
VARCHAR(300) |
对给定的DRG_CODE进行自然语言的简述 |
| DRG_SEVERITY |
SMALLINT |
DRG_SEVERITY和DRG_MORTALITY为“APR”DRG类型中的DRG代码提供了额外的粒度。诊断更严重时，严重性和死亡率允许更高的计费成本，反之亦然。 |
| DRG_MORTALITY |
SMALLINT |
|
表19：icustays
表来源：医院数据库。
表目的：定义数据库中的每个ICUSTAY_ID，即定义单个ICU停留。
行数：61,532。
表间关联：
SUBJECT_ID与PATIENTS
HADM_ID与ADMISSIONS
简介：ICUSTAY_ID是生成的标识符，不基于任何原始的数据标识符。ICUSTAYS表来自TRANSFERS表。根据ICUSTAY_ID对TRANSFERS表进行分组，并排除不存在ICUSTAY_ID的行。
| Name |
PostgreSQL data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| ICUSTAY_ID |
INT |
ICUSTAY_ID将所有ICU入院时间间隔24小时 |
| DBSOURCE |
VARCHAR(20) |
数据库来源,Metavision(2008-2012) or Carevue(2001-2008) |
| FIRST_CAREUNIT |
VARCHAR(20) |
患者被给予的第一种护理 |
| LAST_CAREUNIT |
VARCHAR(20) |
患者被给予的最后一种护理 |
| FIRST_WARDID |
SMALLINT |
患者第一次入住的ICU单元 |
| LAST_WARDID |
SMALLINT |
患者最后一次入住的ICU单元 |
| INTIME |
TIMESTAMP(0) |
患者入住ICU的时间 |
| OUTTIME |
TIMESTAMP(0) |
患者转出ICU的时间 |
| LOS |
DOUBLE |
入住ICU的时长 |
表20：microbiologyevents
表来源：医院数据库。
表目的：包含微生物学信息，包括进行的测试和敏感性。
行数：631,726。
表间联系：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID上与ADMISSIONS关联
通过SPEC_ITEMID与D_ITEMS关联
通过ORG_ITEMID与D_ITEMS关联
通过AB_ITEMID与D_ITEMS关联
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| CHARTDATE |
TIMESTAMP(0) |
记录检测的时间 |
| CHARTTIME |
TIMESTAMP(0) |
同CHARTDATE |
| SPEC_ITEMID |
INT |
细菌生长的标本ID |
| SPEC_TYPE_DESC |
VARCHAR(100) |
描述标本类型 |
| ORG_ITEMID |
INT |
生物体ID 如果有生物体的话，在测试时生长。没有生物体生长（即阴性培养物）为NULL |
| ORG_NAME |
VARCHAR(100) |
生物体名称 |
| ISOLATE_NUM |
SMALLINT |
为了测试抗生素，分离的菌落（整数;从1开始） |
| AB_ITEMID |
INT |
如果对给定生物进行了抗生素针敏感性测试，该列列出其ITEMID |
| AB_NAME |
VARCHAR(30) |
如果对给定生物进行了抗生素针敏感性测试，该列列出其名称 |
| DILUTION_TEXT |
VARCHAR(10) |
|
| DILUTION_COMPARISON |
VARCHAR(20) |
|
| DILUTION_VALUE |
DOUBLE PRECISION |
测试抗生素敏感性时的稀释值 |
| INTERPRETATION |
VARCHAR(5) |
解释抗生素的敏感性，并指出试验结果。 “S”:敏感的， “R”:抗性的， “I”:中间的， “P”:待定的 |
表21：noteevents
表来源：医院数据库。
表目的：包含患者的所有注释。
行数：2,083,180
表间联系：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联
通过CGID与CAREGIVERS关联
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| CHARTDATE |
TIMESTAMP(0) |
记录note的时间 |
| CATEGORY |
VARCHAR(50) |
note类别，如：‘Discharge’代表是discharge note |
| DESCRIPTION |
VARCHAR(300) |
对note类别的描述 |
| CGID |
INT |
医护人员ID |
| ISERROR |
CHAR(1) |
值为“1”，表明医护人员认为该note有错 |
| TEXT |
TEXT |
note text |
表22：patients
表来源：CareVue和Metavision ICU数据库。
表目的：包含所有患者的所有的charted（图表？）数据。
行数：46,520
链接到：
通过SUBJECT_ID与ADMISSIONS关联
通过SUBJECT_ID与ICUSTAYS关联
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| GENDER |
VARCHAR(5) |
性别 |
| DOB |
TIMESTAMP(0) |
出生日期。数据库中超过89岁的患者的出生日期会发生改变，以模糊他们的年龄并遵守HIPAA。 转变过程：确定患者首次入院时的年龄。 然后将出生日期定为第一次入院前的300年 |
| DOD |
TIMESTAMP(0) |
死亡日期 |
| DOD_HOSP |
TIMESTAMP(0) |
医院数据库中记录的死亡日期 |
| DOD_SSN |
TIMESTAMP(0) |
社会保障数据库记录的死亡日期 |
| EXPIRE_FLAG |
VARCHAR(5) |
EXPIRE_FLAG是一个二进制标志，指示患者是否死亡，即DOD是否为空。 这些死亡包括医院内的死亡（DOD_HOSP）和通过将患者与社会安全主死亡指数（DOD_SSN）匹配而确定的死亡 |
表23：procedureevents_mv
表来源：Metavision ICU数据库。
表目的：包含患者的（治疗）程序
行数：258,066
表间关联：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联
通过ICUSTAY_ID与ICUSTAYS关联
通过ITEMID与D_ITEMS关联
| Name |
Postgres data type |
| ROW_ID |
INT NOT NULL |
| SUBJECT_ID |
INT NOT NULL |
| HADM_ID |
INT NOT NULL |
| ICUSTAY_ID |
INT |
| STARTTIME |
TIMESTAMP(0) |
| ENDTIME |
TIMESTAMP(0) |
| ITEMID |
INT |
| VALUE |
DOUBLE PRECISION |
| VALUEUOM |
VARCHAR(30) |
| LOCATION |
VARCHAR(30) |
| LOCATIONCATEGORY |
VARCHAR(30) |
| STORETIME |
TIMESTAMP(0) |
| CGID |
INT |
| ORDERID |
INT |
| LINKORDERID |
INT |
| ORDERCATEGORYNAME |
VARCHAR(100) |
| SECONDARYORDERCATEGORYNAME |
VARCHAR(100) |
| ORDERCATEGORYDESCRIPTION |
VARCHAR(50) |
| ISOPENBAG |
SMALLINT |
| CONTINUEINNEXTDEPT |
SMALLINT |
| CANCELREASON |
SMALLINT |
| STATUSDESCRIPTION |
VARCHAR(30) |
| COMMENTS_EDITEDBY |
VARCHAR(30) |
| COMMENTS_CANCELEDBY |
VARCHAR(30) |
| COMMENTS_DATE |
TIMESTAMP(0) |
表24：procedures_icd
表来源：医院数据库。
表目的：包含患者的ICD程序，最值得注意的是ICD-9程序。
行数：240,095。
表间关联：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSION关联
通过ICD9_CODE与D_ICD_PROCEDURES关联
简介：ICD代码是在住院结束时生成用于计费目的的。
在MIMIC-III中记录所有患者住院的ICD代码。
| Name |
PostgreSQL data type |
Modifiers |
Description |
| ROW_ID |
INT |
not null |
|
| SUBJECT_ID |
INT |
not null |
|
| HADM_ID |
INT |
not null |
|
| SEQ_NUM |
INT |
|
procedure执行顺序 |
| ICD9_CODE |
VARCHAR(10) |
|
给定procedure对应的ICD-9代码 |
表25：services
表来源：医院数据库。
表目的：列出患者被接纳/转移的服务。
行数：73,343
表间联系：
通过SUBJECT_ID与PATIENTS关联
通过HADM_ID与ADMISSIONS关联
简介：服务表描述了患者接受的服务。虽然患者可以在物理上位于特定的ICU类型（例如MICU），但是他们不一定受到MICU工作人员的照顾。这可能是由于多种原因造成的，包括床位不足。如果想要确定患者在医院接受的服务类型，则应使用“服务”表。例如，如果对识别手术患者感兴趣，推荐的方法是搜索在外科手术服务下入院的患者。
每个服务在表中都采用缩写，对应说明如下：
| Service |
Description |
| CMED |
Cardiac Medical - for non-surgical cardiac related admissions |
| CSURG |
Cardiac Surgery - for surgical cardiac admissions |
| DENT |
Dental - for dental/jaw related admissions |
| ENT |
Ear, nose, and throat - conditions primarily affecting these areas |
| GU |
Genitourinary - reproductive organs/urinary system |
| GYN |
Gynecological - female reproductive systems and breasts |
| MED |
Medical - general service for internal medicine |
| NB |
Newborn - infants born at the hospital |
| NBB |
Newborn baby - infants born at the hospital |
| NMED |
Neurologic Medical - non-surgical, relating to the brain |
| NSURG |
Neurologic Surgical - surgical, relating to the brain |
| OBS |
Obstetrics - conerned with childbirth and the care of women giving birth |
| ORTHO |
Orthopaedic - surgical, relating to the musculoskeletal system |
| OMED |
Orthopaedic medicine - non-surgical, relating to musculoskeletal system |
| PSURG |
Plastic - restortation/reconstruction of the human body (including cosmetic or aesthetic) |
| PSYCH |
Psychiatric - mental disorders relating to mood, behaviour, cognition, or perceptions |
| SURG |
Surgical - general surgical service not classified elsewhere |
| TRAUM |
Trauma - injury or damage caused by physical harm from an external source |
| TSURG |
Thoracic Surgical - surgery on the thorax, located between the neck and the abdomen |
| VSURG |
Vascular Surgical - surgery relating to the circulatory system |
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| TRANSFERTIME |
TIMESTAMP(0) |
从PREV_SERVICE转到CURR_SERVICE的时间 |
| PREV_SERVICE |
VARCHAR(20) |
患者之前接受的服务 |
| CURR_SERVICE |
VARCHAR(20) |
患者现在接受的服务 |
表26：transfers
表来源：医院数据库。
表目的：患者整个住院期间的物理位置。
行数：261,897。
表间关联：
SUBJECT_ID与PATIENTS关联
HADM_ID与ADMISSIONS关联
ICUSTAYS与ICUSTAY_ID关联
简介： ICUSTAYS表来自此表。
护理单元基于与ICU成本中心相关联的WARDID来定义。
Beth Israel的ICU多年来一直在移动，因此相同的WARDID可被视为患者A的ICU，而不是患者B的ICU。
| Name |
Postgres data type |
Description |
| ROW_ID |
INT |
|
| SUBJECT_ID |
INT |
|
| HADM_ID |
INT |
|
| ICUSTAY_ID |
INT |
|
| DBSOURCE |
VARCHAR(20) |
数据库来源 |
| EVENTTYPE |
VARCHAR(20) |
描述了发生了什么转移事件：“admit”:入院，“transfer”：转院，“discharge”：出院 |
| PREV_CAREUNIT |
VARCHAR(20) |
患者之前住的护理单元 |
| CURR_CAREUNIT |
VARCHAR(20) |
患者现在住的护理单元 护理单元基于病房定义：如果病房是ICU成本中心，则护理单元定义为ICU的类型。 如果病房不是ICU，那么在大多数情况下，护理单位为空。例外：NWARD是新生儿的病房。 |
| PREV_WARDID |
SMALLINT |
患者住的前一个病房 |
| CURR_WARDID |
SMALLINT |
患者住的当前病房 医院数据库中的物理位置分组称为病房。 虽然在实践中ICU不被称为病房，但医院数据库在技术上将ICU跟踪为“具有ICU成本中心的病房”。 结果，每个ICU与WARDID相关联，但并非每个WARDID都是IC |
| INTIME |
TIMESTAMP(0) |
CURR_CAREUNIT的入住时间 |
| OUTTIME |
TIMESTAMP(0) |
CURR_CAREUNIT的转出时间 |
| LOS |
INT |
给定病房的住院时间，不一定是ICU，可能是普通病房 |
Care units 包括:
| Care unit |
Description |
| CCU |
Coronary care unit |
| CSRU |
Cardiac surgery recovery unit |
| MICU |
Medical intensive care unit |
| NICU |
Neonatal intensive care unit |
| NWARD |
Neonatal ward |
| SICU |
Surgical intensive care unit |
| TSICU |
Trauma/surgical intensive care unit |