【MIMIC数据库教程】二、MIMIC-IV3.1表格与字段详解（二）：Hosp住院模块表格详解(上)

原创 已于 2025-03-11 16:33:48 修改 · 2.4k 阅读 · 17 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#数据库 #python #数据挖掘

于 2025-03-11 13:30:17 首次发布

MIMIC-IV 3.1 表格与字段详解（二）：Hosp 住院模块表格详解（上）

摘要： MIMIC-IV 是一个关系数据库，包含美国马萨诸塞州某三级学术医疗中心的住院患者数据。它继承 MIMIC-III 的基础，提供更丰富的数据，包括实验室测量、用药、生命体征记录等，支持医疗健康研究。但大量繁琐的表格极大地增加了数据处理的难度，本教程将详细介绍 MIMIC-IV 3.1 版本中包含的 31 张表格及其字段，帮助读者更好地理解和使用 MIMIC-IV 数据库。我将在本专栏中持续更新 MIMIC-IV 数据库的详细解读和数据挖掘，敬请关注！

数据模块概述

MIMIC-IV 3.1 版本包含 住院 (hosp) 和 重症监护 (ICU) 两个模块的数据：

  • Hosp: 提供全院电子病历数据，包括入院信息、实验室测量、微生物学、用药、账单等，共计 22 张表。
  • ICU: 记录重症监护室数据，如静脉注射、呼吸机设置、生命体征等，共计 9 张表。
    在之前的文章【MIMIC数据库教程】一、MIMIC-IV3.1表格与字段详解（一）中整体性的介绍了Hosp和ICU模块中的所有表格，本文将开始对这些表格详细介绍和解读。

🏥 Hosp:admissions表格

admissions表格提供了病人入院的相关信息,总共包含546028行，16个字段，其中hadm_id字段（住院号）为数据库主键（唯一），其余字段含义如下：

列名 字段含义 变量类型 缺失值数量
subject_id 患者ID 整数 0
hadm_id 住院号 整数 0
admittime 入院时间 时间 0
dischtime 出院时间 时间 0
deathtime 死亡时间 时间 534238
admission_type 入院紧急程度 字符串 0
admit_provider_id 收治病人的医护人员ID 字符串 4
admission_location 病人入院前的位置信息 字符串 1
discharge_location 病人出院后的地址 字符串 149818
insurance 保险 字符串 9355
language 语言 字符串 775
marital_status 婚姻状况 字符串 13619
race 种族 字符串 0
edregtime 进急诊科时间 时间 166788
edouttime 出急诊科时间 时间 166788
hospital_expire_flag 是否在住院期间死亡 bool 0

🏥 Hosp:d_hcpcs表格

d_hcpcs表格包含hcpcsevents表中CPT代码的可读定义，总共包含89208行，4个字段，其中code字段（CPT编码）为数据库主键（唯一），其余字段含义如下：

最低0.47元/天 解锁文章
详述CPTEVENTS和DRGCODES两种患者详细计费信息表（十三）
越努力 越幸运
06-08 451
本文主要向大家介绍了两个描述患者详细计费信息的当前诊疗记录表。CPTEVENTS当前诊疗码记录表和DRGCODES疾病相关组信息表，具体描述请查阅本博客～
【MIMIC数据库教程】一、MIMIC-IV3.1表格与字段详解（一）：Hosp和ICU模块表格整体介绍
BD_Design_cs的博客
03-11 2904
MIMIC-IV 3.1 版本包含住院 (hosp) 和 重症监护 (ICU)提供全院电子病历数据，包括入院信息、实验室测量、微生物学、用药、账单等，共计22 张表。记录重症监护室数据，如静脉注射、呼吸机设置、生命体征等，共计9 张表。
【MIMIC数据库教程】三、MIMIC-IV3.1表格与字段详解（三）：Hosp住院模块表格详解(中)
BD_Design_cs的博客
03-11 1991
MIMIC-IV 3.1 版本包含住院 (hosp) 和 重症监护 (ICU)提供全院电子病历数据，包括入院信息、实验室测量、微生物学、用药、账单等，共计22 张表。记录重症监护室数据，如静脉注射、呼吸机设置、生命体征等，共计9 张表。在之前的文章【MIMIC数据库教程】一、MIMIC-IV3.1表格与字段详解（一）中整体性的介绍了Hosp和ICU模块中的所有表格，本文将开始对这些表格详细介绍和解读。
MIMIC-ivSQL查询策略-总结篇
skyskytotop的博客
01-30 4843
也看了不少的官方提供的mimic-iv的SQL的写法，总结一下，写在这里。 尽管数据库提供了很多的表格， 真正用到的就那么几个： mimic_core.admissions; mimic_icu.chartevents; mimic_hosp.labevents; mimic_hosp.diagnosis_icd; 待续 用到的SQL语句的种类也不是很多， 建立临时表格， with 筛选 :where… in 构建列:case when … then …(可多个) else…end 表格连接 join
MIMIC-IV数据库中衍生表（派生表或视图）的含义
数说时代
09-30 1890
在当今医学研究中，MIMIC-IV数据库作为一项重要的临床数据资源，为研究人员提供了丰富的患者信息和医疗事件数据。这不仅为临床决策提供了数据支持，也为进一步的科学研究奠定了基础。MIMIC-IV数据库中各个衍生表的深入解析，不仅为临床研究提供了宝贵的数据资源，也为学术界在急性疾病管理和评估方面的探索打开了新的视野。希望通过这篇文章，读者能对MIMIC-IV数据库及其应用有更深刻的认识，并激励更多的研究者利用这一平台推动医学科学的发展。ICU住院期间的每小时数据。KDIGO标准下肌酐水平数据。
MIMIC-IV数据库中患者院内死亡的单因素生存分析
skyskytotop的博客
05-26 3077
目的 由易到难，对mimic-iv的查询进行实际操作，体现先前文章中提到的mimic-iv数据查询的规律。 数据分析计划 死亡，是重症患者最重要的结局指标，在MIMIC数据库中收录了院内死亡的数据，以及进出ICU的时间（和进出医院的时间），所以我们可以获得是否死亡，以及从入ICU（或入院）到死亡发生之间的时间，有了这两个指标，我们可以通过Cox单因素（参数和非参数）模型来观察ICU（和医院）内死亡的趋势，以及某个变量（比如，性别和种族等）对死亡趋势的影响，以为后续的分析奠定基础。 数据的获取 我们需要数个变
MIMIC-III数据集介绍
热门推荐
qq_43787862的博客
03-23 4万+
Data Descriptor:MIMIC-III, a freely accessible critical care database 这篇paper是对MIMIC-III数据集的一个介绍，不涉及研究内容，故按照论文本身的框架来总结。
【MIMIC数据库教程】四、MIMIC-IV3.1表格与字段详解（四）：Hosp住院模块表格详解(下)
BD_Design_cs的博客
03-12 1306
MIMIC-IV 3.1 版本包含住院 (hosp) 和 重症监护 (ICU)提供全院电子病历数据，包括入院信息、实验室测量、微生物学、用药、账单等，共计22 张表。记录重症监护室数据，如静脉注射、呼吸机设置、生命体征等，共计9 张表。在之前的文章【MIMIC数据库教程】一、MIMIC-IV3.1表格与字段详解（一）中整体性的介绍了Hosp和ICU模块中的所有表格，本文将开始对这些表格详细介绍和解读。
【MIMIC数据库教程】五、MIMIC-IV3.1表格与字段详解（五）：ICU模块表格详解
BD_Design_cs的博客
03-12 2335
MIMIC-IV 3.1 版本包含住院 (hosp) 和 重症监护 (ICU)提供全院电子病历数据，包括入院信息、实验室测量、微生物学、用药、账单等，共计22 张表。记录重症监护室数据，如静脉注射、呼吸机设置、生命体征等，共计9 张表。在之前的文章【MIMIC数据库教程】一、MIMIC-IV3.1表格与字段详解（一）中整体性的介绍了Hosp和ICU模块中的所有表格，本文将开始对这些表格详细介绍和解读。
MIMIC 多参数ICU医疗数据集表结构
sz891016的博客
10-30 2万+
MIMICIII数据表信息 部分表格中字段解释为空，是因为该字段在其他表格中也存在，没有进行重复解释。如发现错误，可留言。 表1：admission 表来源：医院数据库。 表内容：病人的住院情况。 表行数：58976。 表间联系：通过subject_id与patients表相关。 SUBJECT_ID可能重复，重复说明该病人有多次入院。 Name Po...
MIMIC数据库基本信息分析
m0_37520426的博客
04-15 1万+
一、MIMIC数据库中26张表介绍 数据库中一共有26张表，记录患者入院的各种信息，每张表的介绍如下所示。 表格名 信息 admission 患者基本信息，比如性别、种族、语言、宗教、婚姻、入院和出院时间、死亡时间等 callout 提供病人准备从ICU转出或者已经从ICU转出时相关信息 caregivers 记录医护人员信息（ID、类型、附加...
怎么优化慢SQL
chenxuefeng_accp的专栏
01-06 641
摘要：本文系统介绍了MySQL慢SQL优化方法论，涵盖慢SQL定位、常见问题分析及优化策略。通过开启慢查询日志和使用EXPLAIN分析执行计划，可快速识别性能瓶颈。优化措施包括：合理设计索引（避免失效）、解决排序和临时表问题、优化JOIN查询、处理大分页性能问题等。高级优化手段涉及SQL重写、读写分离、分库分表和缓存技术。这些方法不仅适用于InnoDB引擎，部分也适用于其他关系型数据库，是提升数据库性能的实用指南。
AI应用（5）- RAG知识库理解
最新发布
小糖豆
01-07 572
知识库其实是自己建立的库，并不是让模型记住，而是把文档变成可以检索的库，模型在这个过程中只是读证据，综合多端证据，按照规则输出而已。
使用TwinCAT为半导体设备设计数据功能的技术方案
ponygame的博客
01-05 1387
摘要：本文提出基于TwinCAT平台的半导体设备数据统计系统方案，采用分层架构实现实时数据采集与处理。实时层(PLC)负责1-10ms级数据采集、预处理和基础统计计算，符合SEMI标准要求；非实时层(.NET)实现数据分析、存储和WPF/WinForms界面展示。系统通过ADS协议实现高效通信，支持EtherCAT等现场总线接入，提供实时监控、历史趋势、统计报表等功能。方案涉及TwinCAT编程、C#开发、数据库设计等多技术领域，具有实时性强、模块化程度高、符合行业标准等特点，但需掌握IEC61131-3、
HTML:SQLite本地网页查看
aimersong69的博客
01-06 133
本文介绍了一个基于Web的SQLite本地查看器工具，无需安装即可在浏览器中查看SQLite数据库。该工具采用HTML5技术实现，支持拖拽上传.db/.sqlite文件，提供表结构浏览、数据查询、自定义SQL执行和数据导出为CSV等功能。通过sql.js库实现前端SQL解析，保证数据在本地处理，避免云端传输的安全风险。界面采用现代化设计，包含响应式布局、表格展示和交互式操作，适合开发人员快速查看和分析SQLite数据库内容。
浅谈Qt中的QSql模块整体设计
红军不怕远征难，万水千山只等闲
01-01 1231
Qt的QSql模块是Qt框架提供的数据库抽象层，旨在屏蔽不同数据库（如SQLite、MySQL等）的底层API差异，提供统一的操作接口。其核心设计包括三层架构：应用层调用API执行数据库操作，抽象接口层定义统一接口（如QSqlDatabase、QSqlQuery），驱动适配层通过插件机制适配具体数据库。QSql支持SQL执行、参数绑定、事务控制等功能，并与Qt的MVC组件深度整合。模块采用工厂模式、适配器模式等设计模式，确保扩展性和跨平台兼容性。开发者可通过自定义驱动和模型扩展功能，但需注意线程安全和性能优
TDengine JAVA 语言连接器入门指南
TDengine(老段）专注时序数据库领域
01-04 1584
JAVA 语言连接器
sql基础操作
醉卧考场君莫笑
01-03 956
本文介绍了SQL基础操作指令，包括数据库和数据表的基本操作。主要内容涵盖：数据库的查看、创建、打开和删除；数据类型的分类（数值型、字符型、日期时间型等）；数据表的创建、修改和删除方法；以及数据插入操作。文章通过具体语法示例和练习题目，帮助读者掌握SQL基础指令的使用，如创建表结构、修改字段、导入数据等基本数据库操作技能。
ctfshow-web177
2501_93515460的博客
01-02 1095
这道题本身并不难，真正卡住人的地方也不在 payload 的复杂程度，而在对 SQL 执行过程的理解是否清晰。一开始很多“看起来不对劲”的现象，其实都不是注入失败，而是语句确实执行了，只是结果被 LIMIT、原查询或语法细节掩盖了。在这次过程中比较大的收获有两个：一是逐渐意识到，SQL 注入不是“试哪个 payload 能回显”，而是要搞清楚当前返回的到底是哪一条查询的结果；二是一些之前容易忽略的细节，比如引号是否真正闭合、数字/函数后是否允许跟单引号、以及 UNION 行是否真的接管了输出。
ERROR: column p.hadm_id does not exist LINE 3: p.hadm_id, ^ HINT: Perhaps you meant to reference the column "proc.hadm_id".仍然报错
04-16
<think>好的，我现在需要帮助用户解决他们在使用MIMIC-IV 3.1数据库时遇到的SQL语法错误和列名不存在的问题。首先，我需要仔细分析用户的问题描述，他们提到两个错误：一个是“syntax error at or near ORDER”，另一个是列名“p.hadm_id”不存在，应该使用“proc.hadm_id”。同时，用户还引用了之前的一些回答和相关资料，我需要参考这些信息来提供准确的解决方案。 首先，关于“syntax error at or near ORDER”的问题。根据之前的回答，用户可能是在编写SQL查询时，ORDER BY子句的位置不正确，或者在之前的语句中存在括号未闭合的情况。例如，在WHERE子句中可能缺少右括号，导致ORDER BY被错误解析。我需要检查用户提供的SQL代码，看看是否存在这样的问题。另外，用户提到的列名错误“p.hadm_id”不存在，而应该使用“proc.hadm_id”，这可能是因为在JOIN操作中，用户错误地引用了表的别名。 接下来，我需要回顾用户提供的引用内容，尤其是关于MIMIC-IV数据库结构的教程，比如Hosp模块的表格详解。用户引用的教程中提到，Hosp模块包括patients、procedures_icd等表格，需要确认这些表格的字段是否正确。例如，检查procedures_icd表是否有hadm_id字段，以及是否在JOIN时正确关联了subject_id和hadm_id。 用户之前的问题中已经给出了修正后的骨科手术查询代码，但可能还存在错误。例如，在JOIN patients表时，可能只使用了subject_id进行连接，而没有考虑到hadm_id的必要性，导致后续引用p.hadm_id时出错，因为patients表中可能没有hadm_id字段，而hadm_id存在于admissions表中。因此，正确的做法应该是从procedures_icd表中直接获取hadm_id，或者通过admissions表来关联。 此外，用户提供的引用中提到了使用Python读取MIMIC-IV数据库的方法，但当前的问题集中在SQL查询上，暂时不需要涉及Python部分。不过，可能需要提醒用户在数据处理阶段如果遇到大型表格，可以考虑分块读取等方法。 现在需要具体解决用户的错误。首先，关于ORDER BY附近的语法错误，需要检查WHERE子句中的括号是否正确闭合。例如，用户之前的查询可能在WHERE子句中有多个OR条件，但未正确闭合括号，导致ORDER BY被误认为属于WHERE子句的一部分。修正方法是确保所有括号正确闭合。 其次，关于列名p.hadm_id不存在的问题，需要确认patients表中是否存在hadm_id字段。根据MIMIC-IV的结构，patients表存储的是患者的基本信息，如subject_id、出生日期、性别等，而hadm_id（住院ID）通常存储在admissions表中。因此，在查询住院相关的信息时，需要从procedures_icd表或admissions表中获取hadm_id，而不是patients表。因此，用户可能在JOIN时错误地引用了patients表的hadm_id，而实际上应该使用procedures_icd表中的hadm_id，因为procedures_icd表已经包含hadm_id字段，或者需要通过admissions表来关联。 因此，修正方案应该是：在SELECT子句中，使用proc.hadm_id而不是p.hadm_id，因为procedures_icd表（别名为proc）已经包含hadm_id字段，不需要通过patients表获取。同时，检查JOIN条件是否正确关联了subject_id和hadm_id，如果需要的话，可能需要引入admissions表进行连接。 最后，需要确保所有JOIN操作都正确关联了所需的字段，并且WHERE子句中的条件正确闭合，避免语法错误。此外，提醒用户在编写SQL时注意字段的来源表，避免引用不存在的列。 总结解决方案步骤： 1. 检查并修正WHERE子句中的括号闭合问题，确保ORDER BY正确放置。 2. 将p.hadm_id替换为proc.hadm_id，因为procedures_icd表包含该字段。 3. 确保JOIN操作正确关联了subject_id和hadm_id，必要时引入admissions表。 4. 验证所有字段的来源表，避免引用不存在的列。</think>### 一、错误原因分析 #### 1. `syntax error at or near "ORDER"` - **根本原因**：WHERE条件中多条件组合**未正确闭合括号**，导致SQL解析器误判ORDER BY子句位置 - **典型错误示例**： ```sql WHERE (cond1 OR cond2 -- 缺少闭合括号 ORDER BY ... ``` #### 2. `column p.hadm_id does not exist` - **数据结构特性**： - `mimiciv_hosp.patients`表仅包含患者基础信息（`subject_id`、出生日期、性别等）[^2] - **hadm_id（住院号）存储于`admissions`表**和临床操作相关表（如`procedures_icd`） - **错误根源**：尝试从patients表获取住院号导致列不存在 $$ \begin{aligned} &\text{正确数据流向} \\ &\text{procedures_icd} \xrightarrow{\text{hadm\_id}} \text{admissions} \xrightarrow{\text{subject\_id}} \text{patients} \end{aligned} $$ ### 二、修正方案 #### 修正后的骨科手术查询代码： ```sql SELECT proc.subject_id, proc.hadm_id, -- 直接从procedures_icd表获取 proc.icd_code, di.long_title AS procedure_name, proc.chartdate FROM mimiciv_hosp.procedures_icd proc INNER JOIN mimiciv_hosp.d_icd_procedures di ON proc.icd_code = di.icd_code AND proc.icd_version = di.icd_version WHERE (proc.icd_code LIKE &#39;0PQ%&#39; -- 关节置换 OR proc.icd_code LIKE &#39;0PS%&#39; -- 脊柱手术 OR proc.icd_code LIKE &#39;0PU%&#39; -- 上肢手术 OR proc.icd_code LIKE &#39;0PT%&#39; -- 下肢手术 OR proc.icd_code LIKE &#39;0P7%&#39;) -- 注意闭合括号 AND proc.icd_version = 10 ORDER BY proc.chartdate DESC; -- 正确结束位置 ``` ### 三、关键改进点 1. **数据源优化**： - 直接使用`procedures_icd.hadm_id`字段（已包含住院号） - 移除冗余的patients表连接（除非需要性别/年龄等基础信息） 2. **括号完整性验证**： ```diff - WHERE (cond1 OR cond2 + WHERE (cond1 OR cond2) ``` 3. **编码版本过滤**： - 添加`proc.icd_version=10`明确限定ICD-10-PCS编码 ### 四、扩展验证方法 1. **字段存在性检查**： ```sql SELECT column_name FROM information_schema.columns WHERE table_name = &#39;procedures_icd&#39; AND column_name = &#39;hadm_id&#39;; -- 返回hadm_id则确认字段存在[^2] ``` 2. **执行计划验证**： ```sql EXPLAIN ANALYZE SELECT ... -- 粘贴完整查询语句 ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值