诺维医学科研官网：https://www.newboat.top 更新换版中！
bilibili：文章对应的讲解视频在此。熊大学习社 熊大学习社的个人空间-熊大学习社个人主页-哔哩哔哩视频
微信公众号：熊大学习社、诺维之舟
公益网站，首页 | 公益网站 ，内有医学资料库
诺维之舟AI：https://gpt4.nwzz.xyz 可在线使用GPT4
课程相关资料：
（1）课程资料包括SCI论文复现全部代码-基于R、PostgreSql/Navicat等软件、SQL常用命令与批处理脚本、讲义等。关注公众号“熊大学习社”，回复“mimic01”，获取资料链接。
我们坚持学以致用，做有质量的分享。关注B站熊大学习社，公众号诺维之舟、熊大学习社。您的一键三连是我最大的动力。
一对一论文指导学员免费获取学习课程和专属答疑。了解咨询扫客服二维码。
0 课程的总体框架
-
Day1：一、MIMIC数据库零基础入门
（1）MIMIC数据库获取
（2）MIMIC数据库软件安装
（3）MIMIC数据表介绍、基础数据提取
-
Day2：二、MIMIC数据库数据提取与清洗
（1）数据提取方法
（2）关键数据有哪些
（3）数据清洗的常用方法
-
Day3：三、MIMIC数据库SCI论文复现上
（1）MIMIC数据库常用的研究方法
（2）MIMIC数据库SCI论文解析
（3）数据提取与清洗
-
Day4：四、MIMIC数据库SCI论文复现下
（1）多模型Logistic回归模型
（2）限制性立方样条图RCS
（3）亚组分析
这次直播课程的特点：上手操作+撸代码，零基础到SCI复现，随时互动交流，快速开启你的医学研究。
1 MIMIC离线数据库
（1）了解MIMIC数据库
带着问题去学习：怎么了解MIMIC数据库？
MIMIC官网：MIMIC
MIMIC全称是Medical Information Mart for Intensive Care, 是一个重症医学数据库。2003年，在NIH的资助下，来自美国麻省理工(MIT)、英国牛津大学等机构的急诊科医生、重症科医生、计算机科学专家等共同建立的一个数据库。
目前的最新版本是MIMIC-IV 2.2，涵盖了2008至2019年期间的近300,000名患者的临床数据，包括手术、治疗和疾病等方面的信息。数据中包含了包括生命体征、实验室检查、治疗过程、诊断结果、药物使用等大量的医疗信息。
（2）MIMIC数据库版本和数据特点
带着问题去学习：MIMIC数据库有哪些版本？数据分别有什么特点？
MIMIC 数据库目前已经产生了MIMIC Ⅱ、Ⅲ、Ⅳ三个版本 MIMIC数据库包含了BIDMC（美国的一个知名医疗中心）所有内外科ICU患者的数据，数据团队为保护患者隐私，对患者信息进行去标识化处理，向全世界的研究人员免费开放。
-
MIMIC Ⅲ数据库
收集了BIDMC 2001年6月至2012年10月ICU收治的53423例成年患者数据和2001年至2008年收治的7870例新生儿重症患者数据。
文档说明：MIMIC-III documentation | MIMIC
ICD编码全称为International Classification of Diseases，是由世界卫生组织（WHO）制定的国际统一的疾病分类方法。
-
MIMIC Ⅳ数据库
在MIMIC Ⅲ的基础上做了一些改进，包括数据更新和部分表格重构，收集了 2008至2019年BIDMC收治的超过19万名患者、45万次住院记录的临床数据。数据库记录了患者的人口统计学信息、实验室检查、用药情况、生命体征、手术操作、疾病诊断、药物管理、随访生存状态等详细信息。
文档说明：MIMIC-IV documentation | MIMIC
（3）离线数据库已准备好！
官方下载：MIMIC-IV v2.2
注册申请的步骤，可参考文章。MIMIC数据库申请流程： MIMIC数据库申请流程-CSDN博客
离线数据库已准备好，可直接拿过来用！
MIMIC离线数据库|干净原版|mimic iv 2.2版，已放学习资料包。也可自行获取：https://nwzz.xyz/buy/33
2 MIMIC IV数据库导入和使用准备
（1）离线数据库和软件下载
-
01 MIMIC离线数据库
7G多，解压后65G多，导入数据库占用空间快70G！
-
02 mimic-code-main(sql命令)
对mimic数据库解压、导入、视图、检查等一系列操作的集合。批处理，一行代码搞定！
-
03 PostgreSQL
数据库管理软件，相当于SQL Server，但使用效率更高。具体配置一会儿再讲。
-
04 解压软件7z
很重要，命令行处理，批量解压需要。
-
05 Navicat
数据导入后，主要通过Navicat进行数据查询，也就是数据的初步提取。
（2）安装PostgreSQL
（a）安装步骤
PostgreSQL数据库下载的官网：PostgreSQL: Downloads
重点：一是操作系统匹配，选对版本。学习资料版有Windows版本。二是安装位置的空间足够。PostgreSQL软件安装位置与MIMIC导入的目录在同一盘符，需要空间空闲100G。建议准备一个硬盘或U盘。三是数据管理员账号和密码一定要记好！
关键截图1：4项全选
关键截图2：选择安装目录
关键截图3：设置数据库超级管理员postgres的密码，重要！
关键截图4：默认端口号，5432
将psql.exe增加到环境变量的path中。psql.exe的路径：G:\program files\PostgreSQL\14\bin\psql.exe。添加到环境变量后，可以通过命令行进行访问。
# 添加环境变量前 "G:\program files\PostgreSQL\14\bin\psql.exe" -U postgres -p 5432 # 添加环境变量后 psql -U postgres -p 5432
测试效果，成功！
同样，增加环境变量，增加PGDATA，路径是postgreSQL里面的data文件夹。
（b）常见问题
-
（i）数据库连接不上，端口无法连接。
解决方法：重启服务或重启电脑。
-
（ii）pgAdmin4 无法连接本地数据库,或登陆时一直出现报错！
-
解决方法：重启pg_ctl服务。Navicat与pgadmin不能同时登陆！如图
pg_ctl restart
（c）psql 常用命令
参考文章：PostgreSQL psql 常用命令
# 列出所有数据库 \l+ # 查看角色 \du # 查看架构权限 \dn+ # 查看表名 \dt # 显示一个表的结构, table_one为表名 \d table_name
列出所有数据库
查看角色
查看架构权限
查看表名
（3）安装Navicat
（a）安装步骤
安装Navicat
之后选择破解补丁对应的系统的版本。按说明.txt的内容将对应文件夹里的所有文件拷贝至Navicat Premium 12安装位置的根目录（即能看到navicat.exe的那个目录）。
拷贝后如图。
打开Navicat软件，出现试用日期：1899-12-30，可一直使用！
（b）常见问题
（i）连接服务器失败！
解决方法：重启服务。Navicat与pgadmin不能同时登陆！
（ii）Navicat能查询数据，但tables表不显示。
解决方案：【参考文章】Navicat Premium 下看不到PostgreSQL下已创建的表（已解决！！）_navicat连接postgresql后创建的表不显示-CSDN博客
可能是版本太低。更新版本！新的版本已更新至学习资料包。
（4）安装7-Zip 解/压缩软件
7-Zip 解/压缩软件在学习资料包。
后面需要用7z的命令行，因此需要添加到环境变量。步骤同psql。
测试如下，正常！
写一个批处理，批量解压MIMIC离线数据库，解压后65G多。此代码可用诺维之舟AI平台的GPT4代劳。
@echo off
setlocal
set sourcedir=D:\MIMIC\mimic-iv-2.2
set targetdir=G:\program files\mimiciv
set logFile=%~dp0\extract.log
echo Starting to extract files from %sourcedir% to %targetdir%
for /R %sourcedir% %%I in (*.csv.gz) do (
echo Extracting %%I >> %logFile%
"7z" e "%%I" -o"%targetdir%" -aoa
)
pause
批量解压中！
解压前后文件对比：
| 解压前 | 解压后 |
|---|---|
|
|
|
看看数据表，最大的有12G多，一个csv表这么大，打开查阅很费事！因此，需要用postgreSQL管理数据库，好比一个仓库管理系统。
（5）导入MIMIC数据库
-
第一步：创建mimiciv数据库
drop database if exists mimiciv; create database mimiciv owner postgres;
分别输入这两行命令。如果有mimiciv数据库，则删除；然后创建一个新的数据库。
-
第二步： 调用SQL脚本创建表
调用create.sql脚本创建表，目录路径要英文名的文件名，不要出现中文。斜杠调整后如下。
G:/program files/MIMIC/mimic-code-main/mimic-iv/buildmimic/postgres/create.sql
# 进入mimiciv数据库 \c mimiciv # 创建表 \i 'G:/program files/MIMIC/mimic-code-main/mimic-iv/buildmimic/postgres/create.sql'
-
第三步：加载数据
G:\program files\MIMIC\mimic-code-main\mimic-iv\buildmimic\postgres
G:/program files/MIMIC/mimic-code-main/mimic-iv/buildmimic/postgres
# 设置mimiciv数据存放路径 \set mimic_data_dir 'G:/program files/MIMIC/mimic-iv-2.2' # windows下需要设置编码方式为UTF8，否则会报错 \encoding 'UTF8' # 加载数据，路径修改为load_7z.sql存放的路径 \i 'G:/program files/MIMIC/mimic-code-main/mimic-iv/buildmimic/postgres/load_7z.sql'
看一下load_7z.sql文件内容，都是命令行，其中就有7z。
安装过程很漫长，大概6小时！如果长时间不动，点一下Enter键。
安装正常后结果如图！
（6）测试MIMIC数据库
-
（a）查表
查询一下数据库，看看结果！
# 选取mimiciv数据库的admissions表，前10行 SELECT * FROM mimiciv.admissions LIMIT 10
报错：
解决方案：一是加上分号，切记；二是框架（schema）和表名要准确。
SELECT * FROM mimiciv_hosp.admissions LIMIT 10;
-
（b）查看schema
SELECT schema_name FROM information_schema.schemata;
-
（c）查看有哪些表
# 命令行下访问数据库 psql -U postgres -p 5432 # 进入mimiciv \c mimiciv # 查看hosp框架下的表格 select * from pg_tables where schemaname='mimiciv_hosp';
（7）建立视图
# 建立索引 \i 'G:/program files/MIMIC/mimic-code-main/mimic-iv/buildmimic/postgres/index.sql' # 验证 \i 'G:/program files/MIMIC/mimic-code-main/mimic-iv/buildmimic/postgres/validate.sql' # 验证 \i 'G:/program files/MIMIC/mimic-code-main/mimic-iv/buildmimic/postgres/validate_demo.sql' postgres-functions.sql # 生成函数 \i 'G:/program files/MIMIC/mimic-code-main/mimic-iv/concepts_postgres/postgres-functions.sql' # 视图 \i 'G:/program files/MIMIC/mimic-code-main/mimic-iv/concepts_postgres/postgres-make-concepts.sql'
建立索引，非必要！
验证，非必要！
创建函数，必要！
创建视图，必要！时间较长，几个小时！
3 MIMIC IV常用数据说明
MIMIC Ⅳ数据库主要有三类数据：
第一类是从医院电子病历系统 (EHR，electronic health record)中提取的临床数据，包括患者的人口统计学、疾病诊断、实验室检测、药物治疗、生命体征等。
第二类是ICU床旁监护设备采集的波形数据、生命体征、液体管理和事件记录，主要来自于IMDSoft MetaVision系统。
第三类是死亡随访数据，通过社会保险系统得到患者院外死亡的日期，作为MIMIC 数据库的组成部分，这部分数据对研究患者的预后很重要。
MIMIC-IV数据库主要分为两个模块，分别是 Hosp 模块和 ICU 模块（其他模块本文不做讲解）
（1）Hosp 模块介绍
Hosp模块提供从医院范围内的电子健康记录中获取的所有数据，这些数据主要在住院期间记录，有一些表格也包括来自医院外的数据。所涵盖的信息包括患者和入院信息、实验室测量、微生物学、药物管理和收费诊断等。
（a）omr（医疗记录表）
在线医疗记录（OMR）表记录了电子健康记录中的杂项信息。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| chartdate | 记录日期 | 记录观察结果的日期 | DATE NOT NULL |
| seq_num | 序列数 | 唯一区分同一天记录的同一类型结果的单调递增整数。例如，如果两次血压测量发生在同一天，seq_num会按时间顺序排列 | INTEGER NOT NULL |
| result_name | 结果属性名 | 每一行提供关于EHR中单个观察的详细信息。result_name提供了对观察结果的可人工解释的描述 | VARCHAR(100) NOT NULL |
| result_value | 结果属性值 | result_value是与给定OMR观测相关联的值。例如，对于“血压”的result_name，field_value列包含记录的血压（120/80、130/70，依此类推） | TEXT NOT NULL |
SELECT * FROM omr LIMIT 100;
知识点：
（1）subject_id。好比病人的身份证，唯一的。另有hadm_id，为入院编号。
subject_id 每个患者有唯一的subject_id。
hadm_id 患者的每一次入院会有一个唯一的hadm_id。
transfer_id 患者每一次更换病房会有一个唯一的transfer_id。
stay_id 在相同类型病房内进行转移，则会更新一个transfer_id，但会有相同的stay_id，例如用ICU中的一个病房转移到另一个病房，则stay_id不变，transfer_id更新。
所有id的分配都是随机的，与时间先后无关。
（2）chartdate与storetime。前者是观察记录的时间，后者是存档的时间。同一事，前者早于后者。chartdate与charttime。前者精确到日期，后者精确到分钟。
注意：charttime与storetime不一样，一个是实际上用药的时间，一个是记录用药的时间。研究中，charttime用的多。
（b）provider（提供者编号表）
提供表列出了数据库中使用的提供者标识符，此表只有一个字段属性。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| provider_id | 提供编号 | provider_id列出了整个数据库中使用的提供者的所有可能标识符。提供者标识符遵循一致的模式：字母“P”，后跟三个数字，后跟两个字母或两个数字。例如，“P003AB”、“P00102”、“P1248B”等。提供者标识符是随机生成的，除了在数据库中唯一标识同一提供者之外，没有任何固有含义 | VARCHAR(10) NOT NULL |
SELECT * FROM provider LIMIT 100;
（c）admissions（入院信息表）
入院表提供了有关患者入院的信息。由于患者每次唯一的医院就诊都被分配了一个唯一的hadm_id，因此入院表可以被视为hadm_id的定义表。可用信息包括入院和出院的时间信息、人口统计信息、入院来源等。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符，与单个subject_id相关联的任何行都属于同一个人。该表可能有重复的subject_id，表示一名患者多次入院。ADMISSIONS表可以使用subject_id链接到PATIENTS表 | INTEGER NOT NULL |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER NOT NULL |
| admittime | 入院时间 | admittime提供患者入院的日期和时间 | TIMESTAMP NOT NULL |
| dischtime | 出院时间 | dischtime提供患者出院的日期和日期 | TIMESTAMP |
| deathtime | 死亡时间 | deathtime表示患者住院死亡时间，只有当患者在医院去世时，死亡时间才会出现 | TIMESTAMP |
| admission_type | 入院类型 | admission_type表示对入院的紧迫性进行分类。有9种可能性：‘AMBULATORY OBSERVATION’, ‘DIRECT EMER.’, ‘DIRECT OBSERVATION’, ‘ELECTIVE’, ‘EU OBSERVATION’, ‘EW EMER.’, ‘OBSERVATION ADMIT’, ‘SURGICAL SAME DAY ADMISSION’, ‘URGENT’ | VARCHAR(40) NOT NULL |
| admit_provider_id | 标识符 | admit_provider_id为收治患者的提供者提供匿名标识符。提供者标识符遵循一致的模式：字母“P”，后跟三个数字，后跟两个字母或两个数字。例如，“P003AB”、“P00102”、“P1248B”等。提供者标识符是随机生成的，除了在数据库中唯一标识同一提供者之外，没有任何固有含义 | VARCHAR(10) |
| admission_location | 入院位置 | admission_location表示患者在到达医院之前的位置的信息。请注意，由于急诊室在技术上是一个诊所，通过急诊室入院的患者通常将其作为入院地点 | VARCHAR(60) |
| discharge_location | 出院位置 | discharge_location表示患者出院后的位置 | VARCHAR(60) |
| insurance | 保险类型 | insurance表示患者的保险类型 | VARCHAR(255) |
| language | 语种 | language表示患者的语种 | VARCHAR(10) |
| marital_status | 婚姻状况 | marital_status表示患者的婚姻状况 | VARCHAR(30) |
| race | 种族 | race表示患者的种族情况 | VARCHAR(80) |
| edregtime | 急诊留观时间 | edregtime表示患者登记进入急诊科的日期和时间 | TIMESTAMP |
| edouttime | 急诊出观时间 | edouttime表示患者登记进入急诊科的日期和时间 | TIMESTAMP |
| hospital_expire_flag | 院内死亡标记 | hospital_expire_flag表示患者是否在给定的住院时间内死亡。1表示在医院中死亡，0表示存活到出院 | SMALLINT |
知识点：
（1）保险、语言、婚姻状况和种族列提供了特定住院患者的人口统计信息。请注意，由于每次入院都会记录这些数据，因此这些数据可能会随住院时间而变化。
（2）患者入院信息， 以每次入院为单位记录， 每条记录有一个单独的hadm_id, hospital_expire_flag只当次住院是否院内死亡， 部分院内死亡患者没有deathtime, 可能是数据库本身问题.
SELECT * FROM admissions LIMIT 100;
（d）d_hcpcs（代码定义表）
d_hcpcs表用于获取hcpcsevents表中使用的代码定义。这些概念主要对应于医院计费，并且大多是CPT代码。注意：并非所有代码定义都可用。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| code | 代码 | 唯一表示事件的五个字符的代码 | CHAR(5) NOT NULL |
| category | 代码类别 | category表示代码分类 | SMALLINT |
| long_description | 长描述 | long_description表示给定行列出的代码的文本描述 | TEXT |
| short_description | 短描述 | short_description表示给定行列出的代码的文本描述 | VARCHAR(180) |
SELECT * FROM d_hcpcs LIMIT 100;
（e）d_icd_diagnoses（诊断代码索引表）
d_icd_diagnostics表定义了国际疾病分类（ICD）第9版和第10版的诊断代码。这些代码在患者住院结束时获得，用于支付医院所提供的护理费用。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| icd_code | 国际定义疾病编码 | icd_code表示世界卫生组织制定的国际统一的疾病分类方法，是一种字母和数字相结合的编码 | CHAR(7) NOT NULL |
| icd_version | 疾病编码版本号 | 此编码系统有两个版本：版本9（ICD-9）和版本10（ICD-10）。这些可以使用icd_version列进行区分。一般来说，ICD-10代码更详细，尽管存在将ICD-9代码转换为ICD-10码的代码映射（或“交叉步”）。 ICD-9和ICD-10代码通常都用十进制表示。解释ICD代码时不需要此小数；即“0010”的icd_code等效于“001.0”。 ICD-9和ICD-10代码有不同的格式：ICD-9代码是5个字符长的字符串，完全是数字（前缀为“E”或“V”的代码除外，这些代码用于外部伤害原因或补充分类）。重要的是，ICD-9代码作为字符串保留在数据库中，因为代码中的前导0是有意义的。 ICD-10代码长3-7个字符，前缀总是一个字母，后面跟着一组数值 | INTEGER NOT NULL |
| long_title | 编码含义 | long_title提供了ICD代码的含义。例如，ICD-9代码0010的标题很长，是“霍乱弧菌引起的霍乱” | VARCHAR(255) |
SELECT * FROM d_icd_diagnoses LIMIT 100;
（f）d_icd_procedures（手术操作索引表）
d_icd_procedures表定义了国际疾病分类（ICD）程序代码。这些代码在患者住院结束时分配，用于支付医院所提供的护理费用。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| icd_code | 国际定义疾病编码 | icd_code表示世界卫生组织制定的国际统一的疾病分类方法，是一种字母和数字相结合的编码 | CHAR(7) NOT NULL |
| icd_version | 疾病编码版本号 | 此编码系统有两个版本：版本9（ICD-9）和版本10（ICD-10）。这些可以使用icd_version列进行区分。一般来说，ICD-10代码更详细，尽管存在将ICD-9代码转换为ICD-10码的代码映射（或“交叉步”）。 ICD-9和ICD-10代码通常都用十进制表示。解释ICD代码时不需要此小数；即“0010”的icd_code等效于“001.0”。 ICD-9和ICD-10代码有不同的格式：ICD-9代码是5个字符长的字符串，完全是数字（前缀为“E”或“V”的代码除外，这些代码用于外部伤害原因或补充分类）。重要的是，ICD-9代码作为字符串保留在数据库中，因为代码中的前导0是有意义的。 ICD-10代码长3-7个字符，前缀总是一个字母，后面跟着一组数值 | INTEGER NOT NULL |
| long_title | 编码含义 | long_title提供了ICD代码的含义。例如，ICD-9代码0010的标题很长，是“霍乱弧菌引起的霍乱” | VARCHAR(255) |
SELECT * FROM d_icd_procedures LIMIT 100;
（g）d_labitems（化验项目索引表）
d_labitems表是对所有化验项目的描述。d_labitems表包含了与MIMIC数据库中的实验室测量相关联的所有itemid的定义。labelvents中的所有数据都链接到d_labitems表。医院数据库中的每个唯一（流体、类别、标签）元组都在该表中分配了一个条目ID，使用该条目ID有助于高效存储和查询数据。 其中实验室数据包含收集并记录在医院实验室数据库中的信息。这包括在医院内的病房和医院外的诊所进行的测量。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| itemid | 化验项目编号 | 化验项目概念的唯一标识符。itemid对每一行都是唯一的，可用于标识与特定概念相关联的标签中的数据 | INTEGER |
| label | 项目标签 | 标签列描述了由itemid表示的概念 | VARCHAR(50) |
| fluid | 流体类型 | fluid表示进行测量的流体物质。例如，经常对血液进行化学测量，血液在本栏中被列为“血液”。这些测量中的许多也可以在其他液体上获得，如尿液，本专栏区分了这些不同的概念 | VARCHAR(50) |
| category | 化验类型 | category提供了关于测量类型的更高级别的信息。例如，“ABG”类别表示测量是动脉血气 | VARCHAR(50) |
SELECT * FROM d_labitems LIMIT 100;
（h）diagnoses_icd（诊断代码表）
在常规医院护理期间，医院会向患者收取与住院相关的诊断费用。该表包含患者在住院期间使用ICD-9和ICD-10本体的所有诊断记录。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符，与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER NOT NULL |
| seq_num | 序列数 | seq_num表示分配给诊断的优先级。优先级可以被解释为对哪些诊断是“重要的”的排名。例如，被诊断为败血症的患者必须将败血症作为他们的第二种疾病。第一种情况必须是传染源。对低优先级诊断进行“正确”排序也不那么重要（例如，第5到第10个诊断代码的优先级可能没有正确的排序） | INTEGER NOT NULL |
| icd_code | 国际定义疾病编码 | icd_code表示世界卫生组织制定的国际统一的疾病分类方法，是一种字母和数字相结合的编码 | VARCHAR(7) |
| icd_version | 疾病编码版本号 | 此编码系统有两个版本：版本9（ICD-9）和版本10（ICD-10）。这些可以使用icd_version列进行区分 | INTEGER |
SELECT * FROM diagnoses_icd LIMIT 100;
（i）drgcodes（患者诊断类别表）
该表是住院的计费诊断类别组（DRG）代码。医院使用诊断类别组（DRG）来报销患者的住院费用。这些代码与患者住院的主要原因相对应。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符，与单个subject_id相关联的任何行都属于同一个人 | INTEGER |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER |
| drg_type | 诊断类别 | DRG诊断类别 | VARCHAR(4) |
| drg_code | 诊断编码 | DRG诊断编码 | VARCHAR(10) |
| description | 描述 | 给定诊断编码的描述 | VARCHAR(195) |
| drg_severity | 严重程度 | drg_severity分为4个等级，用整数表示，分别表示严重程度高低 | SMALLINT |
| drg_mortality | 死亡率 | drg_mortality分为4个等级，用整数表示，分别表示死亡率大小 | SMALLINT |
SELECT * FROM drgcodes LIMIT 100;
（j）emar（患者服用药物表）
EMAR表用于记录单个患者服用某种药物的情况。该表中的记录由床边护理人员扫描与药物和患者相关的条形码填充。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | ubject_id是指定单个患者的唯一标识符，与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER |
| emar_id | 服用药物编号 | EMAR表的标识符。emar_id是emar中每条记录的唯一标识符。emar_id由subject_id和emar_seq组成，其模式如下：“subject_id-emar-seq” | VARCHAR(25) NOT NULL |
| emar_seq | 编号序列 | EMAR表的标识符。emar_id是emar中每条记录的唯一标识符。emar_id由subject_id和emar_seq组成，其模式如下：“subject_id-emar-seq” | INTEGER NOT NULL |
| poe_id | 订单输入编号 | 将emar中的管理与poe中的订单和处方联系起来的标识符 | VARCHAR(25) NOT NULL |
| pharmacy_id | pharmacy标识符 | 将emar中的管理与pharmacy表中的药房信息联系起来的标识符 | INTEGER |
| enter_provider_id | 输入emar标识符 | enter_provider_id为将信息输入EMAR系统的提供者提供匿名标识符。提供者标识符遵循一致的模式：字母“P”，后跟三个数字，后跟两个字母或两个数字。例如，“P003AB”、“P00102”、“P1248B”等。提供者标识符是随机生成的，除了在数据库中唯一标识同一提供者之外，没有任何固有含义 | VARCHAR(10) |
| charttime | 用药时间 | 表示用药时间 | TIMESTAMP NOT NULL |
| medication | 药物名称 | 表示患者服用药物的名称 | TEXT |
| event_txt | 管理信息 | 有关管理的信息。最常见的event_txt是“Administratored”，但其他可能的值是“Applied”、“Confirmed”、“Delayed”、“Not Given”等 | VARCHAR(100) |
| scheduletime | 计划时间 | 如果存在，则为计划管理的时间 | TIMESTAMP |
| storetime | 存储时间 | 表示eMAR表中记录给药的时间 | TIMESTAMP NOT NULL |
SELECT * FROM emar LIMIT 100;
（k）emar_detail（给药详细信息表）
emar_detail表包含emar表中每种药物给药的信息。信息包括相关的药房订单、到期剂量、给药剂量以及与医疗管理相关的许多其他参数。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| emar_id | 服用药物编号 | EMAR表的标识符。emar_id是emar中每条记录的唯一标识符。emar_id由subject_id和emar_seq组成，其模式如下：“subject_id-emar-seq” | VARCHAR(25) NOT NULL |
| emar_seq | 编号序列 | emar_seq是按时间顺序对emar订单进行编号的连续整数 | INTEGER NOT NULL |
| parent_field_ordinal | 给药剂量 | parent_field_ordinal描述了同一EMAR事件的多次给药，例如全剂量的多个处方剂量。由于EMAR要求给药提供者扫描提供给患者的每个处方的条形码，通常情况下emar_detail中的多行对应于emar中的一行（例如，给药的多个药丸加起来达到所需剂量）。emar_detail行的结构如下： | VARCHAR(10) |
| administration_type | 给药类型 | 给药类型，包括“静脉滴注”、“静脉输液”、“药物输液”和“透皮贴剂”等。 | VARCHAR(50) |
| pharmacy_id | 药房表标识 | 允许将EMAR订单链接到药房表中提供的药房信息的标识符。注意：很少相同的emar_id在emar_detail表中的行之间有多个不同的pharmacy_id。 | INTEGER NOT NULL |
| barcode_type | 暂无 | VARCHAR(4) | |
| reason_for_no_barcode | 暂无 | TEXT | |
| complete_dose_not_given | 暂无 | VARCHAR(5) | |
| dose_due | 暂无 | VARCHAR(100) | |
| 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(40) | |
| infusion_rate | 暂无 | VARCHAR(40) | |
| infusion_rate_adjustment | 暂无 | VARCHAR(50) | |
| infusion_rate_adjustment_amount | 暂无 | VARCHAR(30) | |
| infusion_rate_unit | 暂无 | VARCHAR(30) | |
| route | 暂无 | VARCHAR(10) | |
| infusion_complete | 暂无 | VARCHAR(1) | |
| completion_interval | 暂无 | VARCHAR(50) | |
| new_iv_bag_hung | 暂无 | VARCHAR(1) | |
| continued_infusion_in_other_location | 暂无 | VARCHAR(1) | |
| restart_interval | 暂无 | TEXT | |
| side | 暂无 | VARCHAR(10) | |
| site | 暂无 | VARCHAR(255) | |
| non_formulary_visual_verification | 暂无 | VARCHAR(1) |
注意：每个eMAR订单有一行parent_field_ordinal为空：这一行通常包含给药所需的剂量。之后，如果有N个处方剂量，parent_field_ordinal 将取值“1.1”、“1.2”、…、“1.N”。最常见的情况是每种药物只有一个处方剂量。在这种情况下，emar_id在emar_detail表中有两行：一行parent_field_ordinal的值为NULL（通常提供到期剂量），另一行parent_field_ordial的值为“1.1”（通常提供实际给药剂量）。
SELECT * FROM emar_detail LIMIT 100;
（l）hcpcsevents（计费表）
住院期间发生的计费事件。包括CPT代码。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER NOT NULL |
| chartdate | 记录日期 | 与编码事件关联的日期 | DATE |
| hcpcs_cd | 代码 | 唯一表示事件的五个字符的代码。将其链接到d_hcpcs中的代码以获得代码的详细描述 | CHAR(5) NOT NULL |
| seq_num | 代码序列 | 为个人住院指定的HCPCS代码顺序。这个顺序有时传达意义，例如有时更高的优先级，但这并不能保证所有代码都能实现 | INTEGER NOT NULL |
| short_description | 文本描述 | 为给定行列出的hcpcs_cd的简短文本描述 | VARCHAR(180) |
SELECT * FROM hcpcsevents LIMIT 100;
（m）labevents（患者化验测量表）
labelvents表存储单个患者的所有化验测量结果。这些包括血液学测量、血气分析、化学小组和不太常见的测试，如基因分析。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| labevent_id | 化验测量标识符 | 化验测量结果的唯一标识符 | INTEGER NOT NULL |
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER |
| specimen_id | 样本测量标识 | 唯一表示用于化验测量的样本。大多数实验室测量都是对患者来源的样本（样本）进行的，如血液、尿液等。通常对同一样本进行多次测量。specimen_id将对同一样本进行的测量进行分组，例如对同一血液样本进行的血气测量 | INTEGER NOT NULL |
| itemid | 项目标识符 | 唯一表示实验室概念的标识符 | INTEGER NOT NULL |
| order_provider_id | 订单提供者编号 | order_provider_id为下订单的提供者提供了一个匿名标识符 | VARCHAR(10) |
| charttime | 采集样本时间 | 绘制化验测量的时间。这通常是采集样本的时间，通常明显早于可进行测量的时间。 | TIMESTAMP(0) |
| storetime | 测量时间 | 在化验系统中进行测量的时间。这是护理提供者可以获得信息的时候。 | TIMESTAMP(0) |
| value | 测量结果 | 化验测量结果 | VARCHAR(200) |
| valuenum | 数字测量结果 | 数字类型的化验测量结果 | DOUBLE PRECISION |
| valueuom | 化验计量单位 | 化验测量概念的计量单位 | VARCHAR(20) |
| ref_range_lower | 正常值上限 | 化验测量正常范围的下限参考范围。超出参考范围的值被视为异常 | DOUBLE PRECISION |
| ref_range_upper | 正常值下线 | 化验测量正常范围的上限参考范围。超出参考范围的值被视为异常 | DOUBLE PRECISION |
| flag | 结果异常标记 | 一个简短的字符串，主要用于指示实验室测量是否异常 | VARCHAR(10) |
| priority | 测量优先级 | 实验室测量的优先级：常规或统计（紧急） | VARCHAR(7) |
| comments | 文本 | 与化验测量相关的未识别的自由文本评论。这些信息提供了有关样本的信息，是否向护理人员发出了关于结果的通知，解释的考虑因素，或者在某些情况下，评论包含实验室本身的结果。已完全取消标识的评论（即未保留任何信息内容）显示为三个下划线：___。NULL注释表示没有对该行进行任何注释。 | TEXT |
SELECT * FROM labevents LIMIT 100;
（n）microbiologyevents（微生物病原检测表）
微生物测试是一种常见的检查感染生长和评估哪种抗生素治疗最有效的程序。本表是患者在医院检测后标本微生物的检测结果。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| microevent_id | 检测编号 | 表示行的唯一标识 | INTEGER NOT NULL |
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER |
| micro_specimen_id | 样本标识 | 唯一表示进行微生物学测量的样本。大多数微生物学测量都是对患者来源的样本（样本）进行的，如血液、尿液等。通常对同一样本进行多次测量。micro_specimen_id将对同一样本进行的测量进行分组，例如从同一血液样本中生长的生物体 | INTEGER NOT NULL |
| order_provider_id | 订单提供者编号 | order_provider_id为下订单的提供者提供了一个匿名标识符 | VARCHAR(10) |
| chartdate | 记录日期 | 记录了绘制观测的时间，通常是最接近实际测量数据的时间。chartdate与chartdime相同，只是没有可用的时间 | TIMESTAMP(0) NOT NULL |
| charttime | 记录时间 | 记录了绘制观测的时间，通常是最接近实际测量数据的时间 | TIMESTAMP(0) |
| spec_itemid | 细菌生长测试标识 | 进行细菌生长测试的标本。样本是从患者身上提取的样本；例如血、尿、痰等 | INTEGER NOT NULL |
| spec_type_desc | 细菌生长测试类型 | 进行细菌生长测试的标本类型 | VARCHAR(100) NOT NULL |
| test_seq | 测试序列 | 如果绘制了多个样本，test_seq将对它们进行描绘。例如，如果有氧和无氧培养瓶用于同一个样本，它们将具有不同的test_seq值（可能为1和2）。 | INTEGER NOT NULL |
| storedate | 存储日期 | 微生物学结果可用的日期（存储日期）或日期和时间（存储时间）。虽然在评估微生物培养的过程中可以获得许多中期结果，但这里的时间是最后一次已知更新的时间 | TIMESTAMP(0) |
| storetime | 存储时间 | 微生物学结果可用的日期日期和时间（存储时间） | TIMESTAMP(0) |
| test_itemid | 测试标识 | 对给定样本进行的测试 | INTEGER |
| test_name | 测试名称 | 对给定样本进行的测试的样本名称 | VARCHAR(100) |
| org_itemid | 生长标识 | 测试时生长的生物体（如果有的话）。如果为NULL，则表示没有生物体生长（即阴性培养） | INTEGER |
| org_name | 生长名称 | 测试时生长的生物体（如果有的话）的名称 | VARCHAR(100) |
| isolate_num | 分离数量 | 为了测试抗生素，分离的菌落（整数；从1开始） | SMALLINT |
| quantity | 暂无 | 暂无 | VARCHAR(50) |
| ab_itemid | 敏感性抗生素标识 | 如果一种抗生素对给定的生物体进行了敏感性测试，则此处列出了该抗生素 | INTEGER |
| ab_name | 敏感性抗生素名称 | 敏感性抗生素名称 | VARCHAR(30) |
| dilution_text | 稀释文本 | 检测抗生素敏感性时的稀释值（符号+值） | VARCHAR(10) |
| dilution_comparison | 稀释对比 | 检测抗生素敏感性的稀释值比较 | VARCHAR(20) |
| dilution_value | 稀释值 | 检测抗生素敏感性时的稀释值 | DOUBLE PRECISION |
| interpretation | 测试结果 | 抗生素敏感性的解释，并指示测试结果。“S”是敏感的，“R”是抗性的，“I”是中间的，“P”是待定的 | VARCHAR(5) |
| comments | 文本定义 | 与微生物学测量相关的未识别的自由文本评论。这些信息提供了有关样本的信息，是否向护理提供者发出了关于结果的通知，解释的考虑因素，或者在某些情况下，评论包含测量本身的结果。已完全取消标识的评论（即未保留任何信息内容）显示为三个下划线：___。NULL注释表示没有对该行进行任何注释 | TEXT |
SELECT * FROM microbiologyevents LIMIT 100;
（o）patients（患者信息表）
如果信息存在，该表会列出患者的性别、年龄和死亡日期。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| gender | 患者性别 | 患者的基因型性别 | VARCHAR(1) NOT NULL |
| anchor_age | 入院年龄 | 这些列提供了有关患者入院的实际患者年份以及患者当时的年龄的信息 | INTEGER NOT NULL |
| anchor_year | 入院年份 | 对于患者来说，anchor_eyear是一个转换的年份。 anchor_eyear_group是一个年份范围，患者的anchor_eYear发生在这个范围内。 anchor_age是患者在anchor_year中的年龄。如果患者的年龄超过89岁，那么无论他们的实际年龄如何，他们的年龄都将设置为91岁 | INTEGER NOT NULL |
| anchor_year_group | 年龄范围 | 对于患者来说，anchor_eyear是一个转换的年份。 anchor_eyear_group是一个年份范围，患者的anchor_eYear发生在这个范围内。 anchor_age是患者在anchor_year中的年龄。如果患者的年龄超过89岁，那么无论他们的实际年龄如何，他们的年龄都将设置为91岁 | VARCHAR(255) NOT NULL |
| dod | 死亡标记 | 患者未确定的死亡日期。死亡日期从两个来源提取：医院信息系统和马萨诸塞州生命记录和统计登记处。使用基于姓名、社会保险号码和出生日期等标识符的自定义算法，将MIMIC的个人患者记录与生命记录进行匹配。 由于这种联系，MIMIC-IV患者出院后一年内可获得院外死亡率。所有患者出院后一年以上死亡的情况都会受到审查。生存研究应将此纳入其设计中 | TIMESTAMP(0) |
SELECT * FROM patients LIMIT 100;
知识点：
（1）年龄怎么算。
以subject_id为10000032为例，anchor_year为2180，anchor_year_group为2014-2016，anchor_age为52。患者的2180年对应于2014-2016年，52岁。如果入院时间2185年，患者住院将发生在2019-2021年，此时，年龄为57岁。
2180，2014-2016，52
2185，？ ，？
52+(2185-2180)=57
（p）pharmacy（药房表）
药房表提供了有关为患者开具的已填充药物的详细信息。药房信息包括药物剂量、处方剂量数量、给药频率、用药途径和处方持续时间。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER NOT NULL |
| pharmacy_id | 药品编号 | 给定药房条目的唯一标识符。药房表格的每一行都有一个唯一的pharmacy_id。该标识符可用于将药房信息链接到提供者订单（在poe或处方中）或药物管理（在emar中） | INTEGER NOT NULL |
| poe_id | 订单输入编号 | 提供者订单的唯一标识符。poe_id由subject_id和一个单调递增的整数poe_seq组成，格式如下：subject_id-poe_seq | VARCHAR(50) |
| starttime | 开始时间 | 给定处方药的开始时间 | TIMESTAMP(3) |
| stoptime | 停止时间 | 给定处方药的停止时间 | TIMESTAMP(3) |
| medication | 药物名称 | 提供的药物名称 | TEXT |
| proc_type | 订单类型 | 订单类型：“IV Piggyback”、“非处方”、“单位剂量”等 | VARCHAR(50) NOT NULL |
| status | 处方状态 | 处方是激活的、非激活的还是停用的 | VARCHAR(50) |
| entertime | 输入时间 | 将处方输入药房系统的日期和时间 | TIMESTAMP(3) NOT NULL |
| verifiedtime | 验证时间 | 医生验证处方的日期和时间 | TIMESTAMP(3) |
| route | 给药途径 | 处方的预期给药途径 | VARCHAR(50) |
| frequency | 给药频率 | 应给患者服用药物的频率。在频率列中使用了许多常用的短手。Q#表示每#小时；例如“Q6”或“Q6H”是每6小时一次 | VARCHAR(50) |
| disp_sched | 给药时间 | 一天中应该给药的时间，例如“08、20”表示应该分别在上午8:00和下午8:00给药 | VARCHAR(255) |
| infusion_type | 输注类型 | 描述输液类型的编码字母：“B”、“C”、“N”、“N1”、“O”或“R” | VARCHAR(15) |
| sliding_scale | 滑动量表标记 | 指示是否应按滑动量表给药：“Y”或“N” | VARCHAR(1) |
| lockout_interval | 给药间隔 | 患者必须等待的时间，直到为自己提供另一剂；常用于患者自控镇痛 | VARCHAR(50) |
| basal_rate | 给药速率 | 24小时内给药的速率 | REAL |
| one_hr_max | 给药最大剂量 | 一小时内可能给予的最大剂量 | VARCHAR(10) |
| doses_per_24_hrs | 24小时给药剂量 | 每24小时的预期剂量。请注意，本栏可能会误导持续输注的药物，因为尽管持续给药，但它们通常每天只“给药”一次 | REAL |
| duration | 给药持续时间 | 给定剂量的数字持续时间 | REAL |
| duration_interval | 持续时间测量单位 | 而duration_interval可以被视为给定持续时间的测量单位 | VARCHAR(50) |
| expiration_value | 有效期长度 | 如果药物有一个相关的有效期，这些列会详细说明这种情况发生的时间 | INTEGER |
| expiration_unit | 时间单位 | expiration_unit提供药物到期的时间长度，例如30天、72小时等 | VARCHAR(50) |
| expirationdate | 到期日期 | expirationdate提供未识别的到期日期 | TIMESTAMP(3) |
| dispensation | 分配来源 | 药物的分配来源 | VARCHAR(50) |
| fill_quantity | 公式比例 | 填写公式集的比例 | VARCHAR(50) |
SELECT * FROM pharmacy LIMIT 100;
（q）poe（提供者订单输入表）
提供者订单输入（POE）是医院护理提供者输入订单的通用界面。大多数治疗和程序必须通过POE订购。医疗服务提供者作出的与病人护理有关的命令。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| poe_id | 订单输入编号 | 提供者订单的唯一标识符。poe_id由subject_id和一个单调递增的整数poe_seq组成，格式如下：subject_id-poe_seq | VARCHAR(25) NOT NULL |
| poe_seq | 订单顺序标识 | 一个单调递增的整数，按时间顺序对POE顺序进行排序。也就是说，POE订单可以按POE_seq顺序排序 | INTEGER NOT NULL |
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER |
| ordertime | 订单时间 | 提供者订单的日期和时间 | TIMESTAMP(0) NOT NULL |
| order_type | 订单类型 | 提供者订单的类型 | VARCHAR(25) NOT NULL |
| order_subtype | 订单详细信息 | 供应商订单类型的进一步详细信息。order_subtype最好与order_type一起解释，例如order_type:“Cardiology”与order_subtype:“Holter Monitor” | VARCHAR(50) |
| transaction_type | 操作类型 | 提供程序在执行此订单时执行的操作 | VARCHAR(15) |
| discontinue_of_poe_id | 中止订单编号 | 如果此订单中止了前一个订单，那么discontinue_of_poe_id将链接到已中止的前一个顺序 | VARCHAR(25) |
| discontinued_by_poe_id | 未来订单编号 | 如果该订单后来被一个不同的订单中断，那么discontinued_by_poe_id将链接到该未来订单 | VARCHAR(25) |
| order_provider_id | 订单提供者编号 | order_provider_id为下订单的提供者提供了一个匿名标识符 | VARCHAR(10) |
| order_status | 订单状态 | 订单是否仍处于活动状态（“活动”）或是否已被取消激活（“激活”）。 | VARCHAR(15) |
SELECT * FROM poe LIMIT 100;
（r）poe_detail（供应商补充信息表）
医院供应商订单的补充信息。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| poe_id | 订单输入编号 | 提供者订单的唯一标识符。poe_id由subject_id和一个单调递增的整数poe_seq组成，格式如下：subject_id-poe_seq | VARCHAR(25) NOT NULL |
| poe_seq | 订单顺序标识 | 一个单调递增的整数，按时间顺序对POE顺序进行排序。也就是说，POE订单可以按POE_seq顺序排序 | INTEGER NOT NULL |
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| field_name | 订单详细信息名称 | 每一行都提供了有关POE订单特定方面的详细信息。field_name是该方面的名称。从MIMIC-IV v2.2开始，下表列出了可能的值以及字段值中最常见的条目 | VARCHAR(255) NOT NULL |
| field_value | 订单详细信息值 | field_value是与给定POE订单和field_name相关联的值。例如，对于“入院”的field_name，field_value列包含患者入院的单位类型（精神病学、妇科等） | TEXT |
SELECT * FROM admissions LIMIT 100;
（s）prescriptions（处方药物表）
prescriptions表提供了有关处方药物的信息。信息包括药物名称、编码标识符，包括通用序列号（GSN）和国家药品代码（NDC）、产品强度、处方剂量和给药途径。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER NOT NULL |
| pharmacy_id | 药房表标识 | 将emar中的管理与药房表中的药房信息联系起来的标识符。 | INTEGER NOT NULL |
| poe_id | 订单输入编号 | 提供者订单的唯一标识符。poe_id由subject_id和一个单调递增的整数poe_seq组成，格式如下：subject_id-poe_seq | VARCHAR(25) |
| poe_seq | 订单顺序标识 | emar_seq是按时间顺序对emar订单进行编号的连续整数 | INTEGER |
| order_provider_id | 订单提供者编号 | order_provider_id为发起订单的提供者提供了一个匿名标识符 | VARCHAR(10) |
| starttime | 暂无 | TIMESTAMP(3) | |
| stoptime | 暂无 | TIMESTAMP(3) | |
| drug_type | 暂无 | VARCHAR(20) NOT NULL | |
| drug | 暂无 | VARCHAR(255) NOT NULL | |
| formulary_drug_cd | 暂无 | VARCHAR(50) | |
| gsn | 暂无 | VARCHAR(255) | |
| ndc | 暂无 | VARCHAR(25) | |
| prod_strength | 暂无 | VARCHAR(255) | |
| form_rx | 暂无 | VARCHAR(25) | |
| dose_val_rx | 暂无 | VARCHAR(100) | |
| dose_unit_rx | 暂无 | VARCHAR(50) | |
| form_val_disp | 暂无 | VARCHAR(50) | |
| form_unit_disp | 暂无 | VARCHAR(50) | |
| doses_per_24_hrs | 暂无 | REAL | |
| route | 暂无 | VARCHAR(50) |
SELECT * FROM prescriptions LIMIT 100;
（t）procedures_icd（患者手术记录表）
在医院的常规护理过程中，患者接受的手术由医院收费。该表包含患者在住院期间使用ICD-9和ICD-10本体的所有手术记录。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER NOT NULL |
| seq_num | 优先级序列 | 住院期间发生的程序的指定优先级 | INTEGER NOT NULL |
| chartdate | 记录日期 | 相关程序的日期。日期与seq_num没有严格关联 | DATE NOT NULL |
| icd_code | 国际定义疾病编码 | icd_code表示世界卫生组织制定的国际统一的疾病分类方法，是一种字母和数字相结合的编码 | VARCHAR(7) |
| icd_version | 疾病编码版本号 | 此编码系统有两个版本：版本9（ICD-9）和版本10（ICD-10） | INTEGER |
SELECT * FROM procedures_icd LIMIT 100;
（u）services（患者医疗服务表）
services表记录了患者接受的服务。每项服务都以缩写形式列在表中——这正是数据存储在医院数据库中的方式。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INT |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INT |
| transfertime | 服务种类更改时间 | transfertime是患者从先前服务（如果存在）转移到当前服务的时间 | TIMESTAMP(0) |
| prev_service | 先前服务类型 | prev_service表示患者的先前服务类型 | VARCHAR(20) |
| curr_service | 当前服务类型 | curr_service表示患者的当前服务类型 | VARCHAR(20) |
注意：虽然患者可以在特定的ICU类型（比如MICU）进行物理定位，但他们不一定由MICU的工作人员团队照顾。发生这种情况的原因有很多，包括床位短缺。
SELECT * FROM services LIMIT 100;
（v）transfers（患者周转信息表）
transfers表记录了患者住院期间的周转信息。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER NOT NULL |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER |
| transfer_id | 周转编号 | transfer_id对患者物理位置唯一。 请注意，icustays和edstays表中存在的stay_id是从transfer_id派生的。例如，三个连续的ICU病房将为每个不同的物理位置提供三个单独的transfer_id（例如，患者可以从一张床移动到另一张床）。整个住宿将有一个单独的stay_id，其将等于第一个物理位置的transfer_id。 | INTEGER NOT NULL |
| eventtype | 转移类型 | 事件类型描述了发生的转移事件：急诊科住院为“ed”，入院为“入院”，院内转移为“转移”，出院为“出院” | VARCHAR(10) |
| careunit | 病房类型 | 患者所在的病房或病房的类型。护理单位的例子包括医疗ICU、外科ICU、医疗病房、新生儿托儿所等 | VARCHAR(255) |
| intime | 入科室时间 | intime提供患者从以前的护理单元转移到当前护理单元（护理单元）的日期和时间 | TIMESTAMP(0) |
| outtime | 出科室时间 | outtime提供患者从当前物理位置转出的日期和时间 | TIMESTAMP(0) |
SELECT * FROM transfers LIMIT 100;
（2）ICU 模块介绍
（a）caregiver
caregiver_id引用的ICU模块中ICU护理人员的描述表。从MIMIC-IV v2.2开始，此表只是列出了数据库中所有唯一的caregiver_id。 请注意，为了区分全医院EHR中使用的标识符与ICU信息系统中使用的标识，我们为ICU采用了“护理人员”的命名法（caregiver_id和护理人员）。对于hosp模块中的医院数据，我们使用“提供者”（provider_id和providers）的术语。然而，从概念上讲，这两组标识符和表格都指的是医院的执业提供者。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| caregiver_id | 护理人员编号 | caregiver_id列出了ICU模块中使用的护理人员的所有可能标识符。caregiver_id唯一标识在ICU信息系统中记录数据的单个护理人员。 | VARCHAR(10) NOT NULL |
SELECT * FROM admissions LIMIT 100;
（b）d_items
是描述itemid的维度表。记录项目代码索引的概念。
D_ITEMS表定义itemid，表示数据库中的测量值。相同类型（例如心率）的测量将具有相同的项目ID（例如220045）。itemid列中的值对每一行都是唯一的。所有itemid的值都将大于220000。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| itemid | 项目编号 | 化验项目概念的唯一标识符。itemid对每一行都是唯一的，可用于标识与特定概念相关联的标签中的数据 | INTEGER |
| label | 项目标签 | 标签列描述了由itemid表示的概念 | VARCHAR(200) |
| abbreviation | 项目缩写 | 缩写列仅在Metavision中可用，列出了标签的常用缩写 | VARCHAR(100) |
| linksto | 链接 | linksto提供数据链接到的表名。例如，值“chartevents”表示给定行的itemid包含在chartevents中。单个项目ID仅用于一个事件表中，也就是说，如果某个项目ID包含在CHARTEVENTS中，则不会包含在任何其他事件表中（例如IOEVENTS、CHARTEVENTS等）。 | VARCHAR(50) |
| category | 项目类型 | 类别提供了itemid对应的数据类型的一些信息。例如，“ABG”表示测量来源于动脉血气，“IV药物”表示通过静脉注射给药，等等。 | VARCHAR(100) |
| unitname | 度量单位 | unitname指定用于itemid的度量单位。此列并不总是可用的，这可能是因为测量单位不同，测量单位对给定的数据类型没有意义，或者测量单位只是缺少。请注意，在相关的事件表中有时会有关于测量单位的附加信息，例如CHARTEVENTS中的valueuom列。 | VARCHAR(100) |
| param_type | 数据类型 | 描述记录的数据类型：日期、数字或文本字段。 | VARCHAR(30) |
| lownormalvalue | 参考下限 | 测量正常参考范围下限 | FLOAT |
| highnormalvalue | 参考上限 | 测量正常参考范围上限 | FLOAT |
SELECT * FROM d_items LIMIT 100;
（c）chartevents
ICU住院期间发生的图表事件，包含ICU中记录的大部分信息。
chartevents包含患者可用的所有图表数据。在他们入住ICU期间，患者信息的主要存储库是他们的电子病历。电子图表显示患者的常规生命体征以及与他们的护理相关的任何其他信息：呼吸机设置、实验室值、代码状态、精神状态等。因此，关于患者住院的大部分信息都包含在图表事件中。此外，即使实验室值在其他地方（标签）被捕获，它们也经常在图表事件中重复。之所以会出现这种情况，是因为希望在患者的电子病历上显示实验室值，因此将值从存储实验室值的数据库复制到存储病历事件的数据库中。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER |
| stay_id | 住宿标识 | 患者病房住宿唯一标识 | INTEGER |
| caregiver_id | 护理人员编号 | caregiver_id列出了ICU模块中使用的护理人员的所有可能标识符。caregiver_id唯一标识在ICU信息系统中记录数据的单个护理人员 | INTEGER |
| charttime | 记录时间 | 记录了绘制观测的时间，通常是最接近实际测量数据的时间 | TIMESTAMP(0) |
| storetime | 存储时间 | 记录临床工作人员手动输入或手动验证观察结果的时间 | TIMESTAMP(0) |
| itemid | 项目编号 | 数据库中单个测量类型的标识符。与一个项目ID（例如220045）相关联的每一行对应于相同测量（例如心率）的实例化 | INTEGER |
| value | 测量值 | value包含为itemid标识的概念测量的值 | VARCHAR(200) |
| valuenum | 测量数字值 | 如果value是数字，则valuenum以数字格式包含相同的数据。如果此数据不是数字，则valuenum为null。在某些情况下（如格拉斯哥昏迷量表、里士满镇静激动量表和代码状态等分数），valuenum包含分数，value包含分数和描述分数含义的文本 | DOUBLE PRECISION |
| valueuom | 计量单位 | valueuom是价值的计量单位（如果适用） | VARCHAR(20) |
| warning | 警告标记 | warning指定护理提供者是否手动记录了此观察的警告 | SMALLINT |
SELECT * FROM chartevents LIMIT 100;
（d）datetimeevents
datetimeevents包含ICU中患者的所有日期测量值。例如，上次透析的日期将在datetimeevents表中，但收缩压不在此表中。由于MIMIC中的所有日期都是匿名的，以保护患者的机密性，因此此表中的所有数据都已更改。请注意，单个患者的年表没有受到影响，两个日期之间的差异等数量仍然真实
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER |
| stay_id | 住宿标识 | 患者病房住宿唯一标识 | INTEGER |
| caregiver_id | 护理人员编号 | caregiver_id列出了ICU模块中使用的护理人员的所有可能标识符。caregiver_id唯一标识在ICU信息系统中记录数据的单个护理人员。 | INTEGER |
| charttime | 记录时间 | 记录了绘制观测的时间，通常是最接近实际测量数据的时间 | TIMESTAMP(3) |
| storetime | 存储时间 | 存储时间记录临床工作人员手动输入或手动验证观察结果的时间 | TIMESTAMP(3) |
| itemid | 项目编号 | 数据库中单个测量类型的标识符。与一个项目ID（例如220045）相关联的每一行对应于相同测量（例如心率）的实例化 | INTEGER |
| value | 文档日期 | 文档日期-这是与itemid引用的概念相对应的值。例如，如果查询itemid:2225755（“18仪表插入日期”），则值列指示行插入的日期。 | TIMESTAMP(3) |
| valueuom | 测量单位 | 值的测量单位-几乎总是文本字符串“Date”。 | VARCHAR(20) |
| warning | 警告标记 | warning指定护理提供者是否手动记录了此观察的警告。 | SMALLINT |
SELECT * FROM datetimeevents LIMIT 100;
（e）icustays
该表记录了ICU住院信息，包括入院和出院时间。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INT |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INT |
| stay_id | 住宿标识 | 患者病房住宿唯一标识 | INT |
| first_careunit | 第一个ICU类型 | first_careunit包含患者的第一个ICU类型。由于stay_id在24小时内将所有入住ICU的患者分组，因此患者有可能从一种类型的ICU转移到另一种类型，并拥有相同的stay_id | VARCHAR(20) |
| last_careunit | 最后ICU类型 | last_careunit包含患者的最后一个ICU类型。由于stay_id在24小时内将所有入住ICU的患者分组，因此患者有可能从一种类型的ICU转移到另一种类型，并拥有相同的stay_id | VARCHAR(20) |
| intime | 转入时间 | INTIME提供患者转入ICU的日期和时间 | TIMESTAMP(0) |
| outtime | 转出时间 | OUTTIME提供患者转出ICU的日期和时间 | TIMESTAMP(0) |
| los | 住院时间 | LOS是患者在指定ICU住院期间的住院时间，可能包括一个或多个ICU单元。停留时间以天数为单位 | DOUBLE PRECISION |
SELECT * FROM icustays LIMIT 100;
（f）ingredientevents
该表记录了连续或间歇给药的成分，包括营养成分和含水量。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER |
| stay_id | 住宿标识 | 患者病房住宿唯一标识 | INTEGER |
| caregiver_id | 护理人员编号 | caregiver_id列出了ICU模块中使用的护理人员的所有可能标识符。caregiver_id唯一标识在ICU信息系统中记录数据的单个护理人员 | INTEGER |
| starttime | 开始时间 | 记录事件的开始时间 | TIMESTAMP(0) |
| endtime | 结束时间 | 记录事件的结束时间 | TIMESTAMP(0) |
| storetime | 存储时间 | 存储时间记录临床工作人员手动输入或手动验证观察结果的时间 | TIMESTAMP(0) |
| itemid | 项目编号 | 数据库中单个测量类型的标识符。与一个项目ID（例如220045）相关联的每一行对应于相同测量（例如心率）的实例化 | INTEGER |
| amount | 服用药量 | amount列出了在开始时间和结束时间之间给患者服用的药物或物质的量 | DOUBLE PRECISION |
| amountuom | 药量单位 | 记录amount值单位 | VARCHAR(20) |
| rate | 服药速率 | rate列出从开始时间到结束时间给患者服用药物或物质的速率 | DOUBLE PRECISION |
| rateuom | 速率单位 | rate值的单位 | VARCHAR(20) |
| orderid | 这些列将程序链接到特定的医嘱。与mimic_icu.inputevents表不同，procedureevents中的大多数过程都是独立排序的。 有数量有限的记录在以后的某个日期根据相同的原始订单再次执行了相同的程序。当在同一原始订单下重复某个过程时，后面过程的记录的linkorderid字段将设置为前面记录的orderid字段。在所有其他情况下，orderid=linkorderid | INTEGER | |
| linkorderid | 这些列将程序链接到特定的医嘱。与mimic_icu.inputevents表不同，procedureevents中的大多数过程都是独立排序的。 有数量有限的记录在以后的某个日期根据相同的原始订单再次执行了相同的程序。当在同一原始订单下重复某个过程时，后面过程的记录的linkorderid字段将设置为前面记录的orderid字段。在所有其他情况下，orderid=linkorderid | INTEGER | |
| statusdescription | 状态描述 | statusdescription说明行中引用的程序的最终状态。过程事件表上显示的状态为： 已暂停-当前交付已暂停。 FinishedRun-物品的交付已经完成（最常见的情况是，装有化合物的袋子是空的）。 已停止-医务人员已终止项目的交付。 过程事件中记录的几乎所有过程都具有FinishedRun状态 | VARCHAR(20) |
| originalamount | 原始量 | 这些字段存在于表中，从不为空，但没有明确的含义。特别是，对于所有记录，“originalrate”都是0或1。 | DOUBLE PRECISION |
| originalrate | 原始速率 | 这些字段存在于表中，从不为空，但没有明确的含义。特别是，对于所有记录，“originalrate”都是0或1。 | DOUBLE PRECISION |
SELECT * FROM ingredientevents LIMIT 100;
（g）inputevents
该表记录了关于连续输注或间歇给药的记录信息。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INT |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INT |
| stay_id | 住宿标识 | 患者病房住宿唯一标识 | INT |
| caregiver_id | 护理人员编号 | caregiver_id列出了ICU模块中使用的护理人员的所有可能标识符。caregiver_id唯一标识在ICU信息系统中记录数据的单个护理人员。 | INTEGER |
| starttime | 开始时间 | 记录事件的开始时间 | TIMESTAMP(0) |
| endtime | 结束时间 | 记录事件的结束时间 | TIMESTAMP(0) |
| storetime | 存储时间 | 存储时间记录临床工作人员手动输入或手动验证观察结果的时间 | TIMESTAMP(0) |
| itemid | 项目编号 | 数据库中单个测量类型的标识符。与一个项目ID（例如220045）相关联的每一行对应于相同测量（例如心率）的实例化 | INT |
| amount | 服用药量 | amount列出了在开始时间和结束时间之间给患者服用的药物或物质的量 | DOUBLE PRECISION |
| amountuom | 药量单位 | 记录amount值单位 | VARCHAR(30) |
| rate | 服用速率 | rate列出从开始时间到结束时间给患者服用药物或物质的速率 | DOUBLE PRECISION |
| rateuom | 速率单位 | rate值的单位 | VARCHAR(30) |
| orderid | 这些列将程序链接到特定的医嘱。与mimic_icu.inputevents表不同，procedureevents中的大多数过程都是独立排序的。 有数量有限的记录在以后的某个日期根据相同的原始订单再次执行了相同的程序。当在同一原始订单下重复某个过程时，后面过程的记录的linkorderid字段将设置为前面记录的orderid字段。在所有其他情况下，orderid=linkorderid | BIGINT | |
| linkorderid | 这些列将程序链接到特定的医嘱。与mimic_icu.inputevents表不同，procedureevents中的大多数过程都是独立排序的。 有数量有限的记录在以后的某个日期根据相同的原始订单再次执行了相同的程序。当在同一原始订单下重复某个过程时，后面过程的记录的linkorderid字段将设置为前面记录的orderid字段。在所有其他情况下，orderid=linkorderid | BIGINT | |
| ordercategoryname | 给药类型 | 这些列提供了有关药物/解决方案所属订单的更高级别信息。类别表示给药类型，而ordercomponenttypedescription描述物质在溶液中的作用（即主订单参数、添加剂或混合溶液） | VARCHAR(100) |
| secondaryordercategoryname | 给药类型 | 这些列提供了有关药物/解决方案所属订单的更高级别信息。类别表示给药类型，而ordercomponenttypedescription描述物质在溶液中的作用（即主订单参数、添加剂或混合溶液） | VARCHAR(100) |
| ordercomponenttypedescription | 订单组成描述 | 这些列提供了有关药物/解决方案所属订单的更高级别信息。类别表示给药类型，而ordercomponenttypedescription描述物质在溶液中的作用（即主订单参数、添加剂或混合溶液） | VARCHAR(200) |
| ordercategorydescription | 订单类型描述 | 这些列提供了有关药物/解决方案所属订单的更高级别信息。类别表示给药类型，而ordercomponenttypedescription描述物质在溶液中的作用（即主订单参数、添加剂或混合溶液） | VARCHAR(50) |
| patientweight | 患者体重 | 记录患者体重 | DOUBLE PRECISION |
| totalamount | 液体总量 | 静脉给药通常是在床边挂一袋液体，在一定时间内连续输注。这些列列出了装有溶液的袋子中的液体总量 | DOUBLE PRECISION |
| totalamountuom | 液体计量单位 | totalamount的计量单位 | VARCHAR(50) |
| isopenbag | SMALLINT | ||
| statusdescription | 状态描述 | statusdescription说明行中引用的程序的最终状态。过程事件表上显示的状态为： 已暂停-当前交付已暂停。 FinishedRun-物品的交付已经完成（最常见的情况是，装有化合物的袋子是空的）。 已停止-医务人员已终止项目的交付。 过程事件中记录的几乎所有过程都具有FinishedRun状态 | VARCHAR(30) |
| originalamount | 原始量 | 这些字段存在于表中，从不为空，但没有明确的含义。特别是，对于所有记录，“originalrate”都是0或1。 | DOUBLE PRECISION |
| originalrate | 原始速率 | 这些字段存在于表中，从不为空，但没有明确的含义。特别是，对于所有记录，“originalrate”都是0或1。 | DOUBLE PRECISION |
SELECT * FROM inputevents LIMIT 100;
（h）outputevents
该表记录有关患者输出的信息，包括尿液、引流等。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER |
| stay_id | 住宿标识 | 患者病房住宿唯一标识 | INTEGER |
| caregiver_id | 护理人员编号 | caregiver_id列出了ICU模块中使用的护理人员的所有可能标识符。caregiver_id唯一标识在ICU信息系统中记录数据的单个护理人员。 | INTEGER |
| charttime | 记录时间 | 记录了绘制观测的时间，通常是最接近实际测量数据的时间 | TIMESTAMP(3) |
| storetime | 存储时间 | 存储时间记录临床工作人员手动输入或手动验证观察结果的时间 | TIMESTAMP(3) |
| itemid | 项目编号 | 数据库中单个测量类型的标识符。与一个项目ID（例如220045）相关联的每一行对应于相同测量（例如心率）的实例化 | INTEGER |
| value | 测量值 | value和valueuom列出了记录时间（确切开始时间未知，但通常在一小时前）物质的量 | DOUBLE PRECISION |
| valueuom | 测量单位 | value和valueuom列出了记录时间（确切开始时间未知，但通常在一小时前）物质的量 | VARCHAR(20) |
SELECT * FROM outputevents LIMIT 100;
（i）procedureevents
ICU住院期间记录的程序（如通气），但不一定在ICU内进行（如x射线成像）。
在日常护理过程中，此表不是必需的文档字段。因此，这里存在程序表明存在程序，但不存在并不表明没有进行程序。文件的一致性因程序类型而异。例如，有创通气往往有记录，而无创通气的记录则不那么一致。
| 字段 | 中文字段 | 字段描述 | 字段类型 |
|---|---|---|---|
| subject_id | 患者编号 | subject_id是指定单个患者的唯一标识符。与单个subject_id相关联的任何行都属于同一个人 | INTEGER |
| hadm_id | 病案编号 | 该表的每一行都包含一个唯一的hadm_id，表示单个患者入院。hadm_id的范围从2000000到2999999 | INTEGER |
| stay_id | 住宿标识 | 患者病房住宿唯一标识 | INTEGER |
| caregiver_id | 护理人员编号 | caregiver_id列出了ICU模块中使用的护理人员的所有可能标识符。caregiver_id唯一标识在ICU信息系统中记录数据的单个护理人员。 | INTEGER |
| starttime | 开始时间 | starttime记录事件的开始时间 | TIMESTAMP |
| endtime | 结束时间 | endtime记录事件的结束时间 | TIMESTAMP |
| storetime | 存储时间 | storetime记录在系统中记录事件的时间。 | TIMESTAMP |
| itemid | 项目编号 | 数据库中单个测量类型的标识符。与一个项目ID（例如220045）相关联的每一行对应于相同测量（例如心率）的实例化 | INTEGER |
| value | 持续时间 | 在procedureevents表中，这标识了程序的持续时间（如果适用）。例如，如果查询itemid 225794（“无创通气”），则值列指示通气治疗的持续时间 | DOUBLE PRECISION |
| valueuom | 持续时间单位 | value值的计量单位 | VARCHAR(20) |
| location | 位置 | 位置和位置类别提供关于手术在患者身体上的何处进行的信息。例如，位置可能是“左上臂”，位置类别可能是“侵入性静脉”。 | VARCHAR(100) |
| locationcategory | 位置类别 | 位置和位置类别提供关于手术在患者身体上的何处进行的信息。例如，位置可能是“左上臂”，位置类别可能是“侵入性静脉”。 | VARCHAR(50) |
| orderid | 这些列将程序链接到特定的医嘱。与mimic_icu.inputevents表不同，procedureevents中的大多数过程都是独立排序的。 有数量有限的记录在以后的某个日期根据相同的原始订单再次执行了相同的程序。当在同一原始订单下重复某个过程时，后面过程的记录的linkorderid字段将设置为前面记录的orderid字段。在所有其他情况下，orderid=linkorderid | INTEGER | |
| linkorderid | 这些列将程序链接到特定的医嘱。与mimic_icu.inputevents表不同，procedureevents中的大多数过程都是独立排序的。 有数量有限的记录在以后的某个日期根据相同的原始订单再次执行了相同的程序。当在同一原始订单下重复某个过程时，后面过程的记录的linkorderid字段将设置为前面记录的orderid字段。在所有其他情况下，orderid=linkorderid | INTEGER | |
| ordercategoryname | 高级别名称 | 这些列提供有关药物/溶液订单的更高级别信息。类别代表管理的类型。 | VARCHAR(50) |
| ordercategorydescription | 高级别类型描述 | 这些列提供有关药物/溶液订单的更高级别信息。类别代表管理的类型。 | VARCHAR(30) |
| patientweight | 患者体重 | 表示患者体重 | DOUBLE PRECISION |
| isopenbag | SMALLINT | ||
| continueinnextdept | 转移标记 | 如果订单在患者转移时结束，此字段指示订单是否继续到下一个科室（例如楼层） | SMALLINT |
| statusdescription | 状态描述 | statusdescription说明行中引用的程序的最终状态。过程事件表上显示的状态为： 已暂停-当前交付已暂停。 FinishedRun-物品的交付已经完成（最常见的情况是，装有化合物的袋子是空的）。 已停止-医务人员已终止项目的交付。 过程事件中记录的几乎所有过程都具有FinishedRun状态 | VARCHAR(20) |
| originalamount | 原始量 | 这些字段存在于表中，从不为空，但没有明确的含义。特别是，对于所有记录，“originalrate”都是0或1。 | DOUBLE PRECISION |
| originalrate | 原始速率 | 这些字段存在于表中，从不为空，但没有明确的含义。特别是，对于所有记录，“originalrate”都是0或1。 | DOUBLE PRECISION |
SELECT * FROM procedureevents LIMIT 100;
4 小结
-
（1）抛砖引玉。接触新事物，积累技能是一个磨的过程，刚开始需要多记多实操。后续，对于数据表的内在联系，以及怎么更好地理解它，不同的场景如何提取数据，如找出MIMIC数据库中没有住院的病人等。又如，数据竖表变成横表。涉及数据的合并方式，这是基于SQL语言完成。下次直播课分享。
-
（2）课程福利。
-
（3）课程资料获取。课程资料包括SCI论文复现全部代码-基于R、PostgreSql/Navicat等软件、SQL常用命令与批处理脚本、讲义等。关注公众号“熊大学习社”，回复“mimic01”，获取资料链接。
服务合作见客服二维码。关注B站熊大学习社，公众号诺维之舟、熊大学习社。您的一键三连是我最大的动力。
扫一扫
2966
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
