mimic-iii数据库说明-01数据库介绍

wjgyy808

已于 2023-10-04 15:47:02 修改

阅读量4.9k

点赞数 2

文章标签：其他

于 2022-06-11 23:18:05 首次发布

mimic-iii数据库说明

关于数据库

1. 患者级别数据：SUBJECT_ID

以下是SUBJECT_ID PATIENTS 表中数据库中可用的静态数据列表：
GENDER
DOB
DOD
DOD_HOSP
DOD_SSN
此列表包含可用于单个患者的所有静态数据。请注意，DOD_SSN（对于DOD列也影响）是从社会保障死亡登记处获得的，即外部来源。它包含 Metavision 患者未来最多 90 天的死亡日期。它包含 CareVue 患者未来最多 4 年的死亡日期。

2. 医院级数据：HADM_ID

下表来自医院数据库，包含在医院记录的信息，但不一定是在患者入住 ICU 期间：
ADMISSIONS
CALLOUT
CPTEVENTS
DIAGNOSES_ICD
DRGCODES
ICUSTAYS
LABEVENTS
MICROBIOLOGYEVENTS
PATIENTS
PRESCRIPTIONS
PROCEDURES_ICD
SERVICES
TRANSFERS

以下是HADM_ID ADMISSIONS 表中数据库中可用的静态数据列表。对于单次住院，该数据是恒定的。

变量	说明	数据类型
ADMITTIME	入院时间	静态数据
DISCHTIME	出院时间	静态数据
DEATHTIME	如果患者在医院内死亡，则为患者的死亡日期	静态数据
ADMISSION_TYPE	入院类型：ELECTIVE、EMERGENCY、NEBORN 或 URGENT（注意这里的 NEWBORN 值并不能完美识别新生儿）	静态数据
ADMISSION_LOCATION	患者入院前的位置
DISCHARGE_LOCATION	患者出院后的位置
INSURANCE	患者的医疗保险类型
LANGUAGE	患者的主要语言
RELIGION	患者的宗教信仰
MARITAL_STATUS	患者的婚姻状况
ETHNICITY	患者陈述的种族
DIAGNOSIS	患者入院原因的简短描述

3. ICU级别数据：ICUSTAY_ID

下表来自 ICU 数据库，仅包含患者入住 ICU 期间的信息：

DATETIMEEVENTS
INPUTEVENTS_CV
INPUTEVENTS_MV
NOTEEVENTS
OUTPUTEVENTS
PROCEDUREEVENTS_MV

以下是ICUSTAY_ID ICUSTAYS 表中数据库中可用的静态数据列表：

变量	说明
DBSOURCE	患者所在的 ICU 数据库
FIRST_CAREUNIT	照顾患者的第一个单位（除 NWARD 外的所有 ICU）
LAST_CAREUNIT	照顾患者的最后一个护理单位（除 NWARD 外的所有 ICU）
FIRST_WARDID	表示患者第一个物理位置的整数
LAST_WARDID	表示患者最后物理位置的整数
INTIME	进入ICU的时间
OUTTIME	离开重症监护室的时间
LOS	患者在 ICU 的停留时间

数据库中的数据类型

MIMIC 中的数据是在常规临床护理期间记录的，并未明确用于回顾性数据分析。这是分析数据时要牢记的关键点。

数据库中有两种类型的数据：静态数据和动态数据。对于给定的标识符，静态数据只记录一次。静态数据的一个示例是DOBPATIENTS 表中的列。每位患者只有一个出生日期，该日期不会随时间而改变，也没有相关的时间戳记录。动态数据的一个例子是患者的血压，在住院期间定期测量。

静态数据和动态数据之间的这种区别只是一个有用的概念结构：出生日期和心率之间没有严格的技术区别。然而，静态数据往往没有关联ITEMID（因为不需要重复记录静态数据的值），而动态数据有一个ITEMID有助于有效存储重复测量的数据。

1. 静态数据

SUBJECT_ID
以下是SUBJECT_ID PATIENTS 表中数据库中可用的静态数据列表：

可用于患者的唯一静态数据是他们的性别 ( GENDER)、出生日期 ( DOB) 和各种死亡日期 ( DOD, DOD_HOSP, DOD_SSN)。这些列都出现在 PATIENTS 表中。

HADM_ID
以下是HADM_ID ADMISSIONS 表中数据库中可用的静态数据列表：
Admission time
Discharge time
Death time
Admission type

ICUSTAY_ID
以下是ICUSTAY_ID ICUSTAYS 表中数据库中可用的静态数据列表：

INTIME- 进入ICU的时间
OUTTIME- 离开重症监护室的时间
First care unit
Last care unit

2. 医院获得的数据

3. ICU获得的数据

下表来自 ICU 数据库，仅包含患者入住 ICU 期间的信息：
DATETIMEEVENTS
INPUTEVENTS_CV
INPUTEVENTS_MV
NOTEEVENTS
OUTPUTEVENTS
PROCEDUREEVENTS_MV

4. 外部获取的数据

DOD_SSN（对于DOD列也影响）是从社会保障死亡登记处获得的。DOD它包含 Metavision 患者未来最多 90 天的死亡日期。它包含 CareVue 患者未来最多 4 年的死亡日期。

液体的input和output

在研究重症监护病房患者时，输入和输出非常有用。输入是已给予患者的任何液体：例如口服或管饲或含有药物的静脉内溶液。输出是由患者排出的流体，例如尿液输出，或从患者体内提取的流体，例如通过引流管。在 MIMIC-III 数据中，这些数据在技术上是最复杂的。

MIMIC-III 数据库包含来自两个不同的重症监护信息系统的信息：Philips CareVue 和 iMDSoft Metavision。这两个数据库以不同的方式存储数据。在本文档的描述中，数据将被称为来自“CareVue”或“Metavision”，以区分不同的系统。

1.INPUTEVENTS_CV, INPUTEVENTS_MV, OUTPUTEVENTS

输入存在于两个单独的表中：INPUTEVENTS_CV 和 INPUTEVENTS_MV。INPUTEVENTS_CV 包含 CareVue 输入，而 INPUTEVENTS_MV 包含 Metavision 输入。这些表的结果可以合并，因为观察结果不会跨表重复。

output
CareVue 和 Metavision 数据中的输出以相当一致的方式记录。测量输出的时间记录在CHARTTIME列中。这里没有记录输出的开始时间—CHARTTIME对应的是相应体积已经输出的时间。输出的体积记录在VALUE列中，计量单位在VALUEUOM列中提供（通常为毫升，或 mL）。通常可以合理地假设记录的任何输出都是针对同一项目的当前CHARTTIME和前一个CHARTTIME之间的间隔。

input
CareVue 和 Metavision 对输入的处理方式不同。对于 CareVue 数据，只有CHARTTIME可用。其次，RATE和AMOUNT列是不同步的，并且最初存储在不同的表中。输入量（例如 50 mL 生理盐水）将存储在一张表中（最初的 IOEVENTS），并且通常每小时记录一次（尽管有时周期更长）。相反，RATE药物的价格将单独存储（在 MEDEVENTS 中），并且仅在临床工作人员更改或验证费率时更新。结果，原始数据看起来类似于：

CHARTTIME	VOLUME	VOLUMEUOM	CHARTTIME	RATE	RATEUOM
–	–	–	09:00	1	mL/min
10:00	60	mL
11:00	60	mL
–	–	–	11:30	0.5	mL/min
12:00	45 mL

此处仅每小时记录一次体积，没有可用的开始时间。但是，可以合理地假设体积测量对应于一小时。接下来，我们可以看到将速率滴定到 0.5，在 11:00 到 12:00 期间，以 1 mL/min 的速度输送半小时，以 0.5 mL/min 的速度输送半小时，导致过去一小时输送的总体积为 45 mL。

总而言之，对于 CareVue 数据，速率和体积将是不同步的，并且只有CHARTTIME可用。对于速率，CHARTTIME将对应于开始时间（药物设置为该速率时）。对于体积，CHARTTIME将对应于结束时间。

对于 Metavision 数据，数据库中没有体积的概念：只有RATE。所有输入都用 STARTTIME和ENDTIME记录。因此，数据库中Metavision患者的体积是根据比率得出的。此外，很容易推断出药物的确切开始和停止时间。

2.合并过程的详细信息

合并数据库的困难主要源于两个因素：CareVue 系统中信息归档的分辨率较低，以及数据库中“order”的不同定义。

本节的目的是提供有关如何合并这些数据的所有详细信息：这些信息对于理解使用数据库的目的不是必需的，但可以深入了解 IOEVENTS 表的格式。

飞利浦 CareVue
CareVue 系统跨五个表存储输入/输出 (IO) 数据：IOEVENTS、MEDEVENTS、ADDITIVES、SOLUTIONS 和 DELIVERIES。每次在数据库中记录新的药物订单时，ADDITIVES、SOLUTIONS 和 DELIVERIES 表都会填充有关订单的信息。最好用一个例子来描述数据归档格式。

患者 A 最近住进了 ICU，将给予去甲肾上腺素以将其血压恢复到至少 60 mmHg 的值。给药途径是静脉内给药，即药物将通过插入静脉的管线直接泵入患者的血流中。护士会准备 250 毫升氯化钠 (NaCl) 溶液来容纳药物。因此，在护士准备溶液时，SOLUTIONS 表将包含患者 A 的 250 mL NaCl 条目。然后护士将药物混合到溶液中：在这个例子中，假设是 8 毫克去甲肾上腺素。8 mg 去甲肾上腺素将记录在 ADDITIVES 表中，并且将记录一个标识符，将 8 mg 去甲肾上腺素与 250 mL NaCl 溶液联系起来。最后，护士可以选择设置初始分娩速度和路线：在这种情况下，可以是 10 mL/hr 静脉注射。这些将填充RATE和ROUTEDELIVERIES 表中的列。请注意，DELIVERIES 数据的出现频率较低，并且没有始终如一地记录。

现在溶液已经准备好，护士可以开始给病人服用药物。现在时间是18:20。在 18:00 时，IOEVENTS 表中记录了 0 mL 的初始条目（通常会发生这种情况，但尚未验证是否总是发生这种情况）。护士以 1 mcg/kg/min 的速度开始。MEDEVENTS 包含一个条目CHARTTIME18:20 的速率为 1 mcg/kg/min。五分钟后，即 18:25，护士注意到血压仍低于所需的 60 mmHg，并增加了剂量。护士将剂量提高到 2 mcg/kg/min，MEDEVENTS 在 18:25 记录新剂量 2 mcg/kg/min。护士再次检查并注意到血压已达到 60 mmHg 的目标值并停止滴定药物。在 19:00，记录给予患者的药物量。如果患者体重 100 公斤，那么给药量将等于：

5 分钟 * 1 mcg/kg/min * 100 kg + 25 min * 2 mcg/kg/min * 100 kg = 500 mcg + 5000 mcg = 5500 mcg = 5.5 mg

施用的溶液量将等于：

（5 分钟 * 1 微克/公斤/分钟 * 100 公斤 + 25 分钟 * 2 微克/公斤/分钟 * 100 公斤）* 250 毫升 / 8 毫克 = 5.5 毫克 * 250 毫升 / 8 毫克 = 171.875 毫升

因此，IOEVENTS 将在 19:00 记录 171.875 mL。如果患者继续以相同的速度服用该药物，则 IOEVENTS 将在 20:00 记录 (60 * 2 * 100 * 250 / 8000) = 375 mL。注意：

除非汇率更新，否则 MEDEVENTS 中不存在新条目
IOEVENTS 始终按小时记录一个值，无论 IO 事件已存在多长时间
375 mL 比原来的 250 mL 袋大：在给药期间，护士需要用相同配方的新溶液更换空袋
请注意，有时（但并非总是）将包的更换作为新订单记录在 ADDITIVES/SOLUTIONS/DELIVERIES 表中。如果药物已停药，然后在患者住院后重新开处方，通常会发生这种情况。

Metavision
Metavision 使用两个表记录 IO 数据：RANGESIGNALS 和 ORDERENTRY。这些表没有出现在 MIMIC-III 中，因为它们已合并形成 INPUTEVENTS_MV 表。RANGESIGNALS 包含持续一段固定时间的记录数据元素。此外，RANGESIGNALS 表分别记录了药物每种成分的信息。例如，对于去甲肾上腺素给药，将有两种成分：主要成分（去甲肾上腺素）和溶液成分（NaCl）。RANGESIGNALS的STARTTIME和ENDTIME表示药物开始和结束的时间。药物速率的任何变化都将导致当前输注结束，并产生新的输注STARTTIME。

让我们回到上面给患者服用去甲肾上腺素的例子。STARTTIME溶液（NaCl）和药物（去甲肾上腺素）的时间为 18:20 。药物的速率将被列为 1 mcg/kg/min，溶液的速率将被列为 10 mL/hr。和以前一样，护士决定在 18:25 将药物速率提高到 2 mcg/kg/min。因此，ENDTIME对应于溶液（NaCl 和去甲肾上腺素）的两行的 18:25 设置为 18:25。生成两个新行，aSTARTTIME为 18:25。这两个新行将持续到 (i) 药物费率改变或 (ii) 药物输送停止。这ORDERID对于对应于相同溶液/速率的 NaCl 和去甲肾上腺素的每个实例，列将是相同的。也就是说，对于 18:20 到 18:25 之间的输液，NaCl 和去甲肾上腺素的ORDERID. LINKORDERID将进一步将药物与所有管理部门联系起来，即使比率发生变化。下表演示了这些概念：