MIMIC-IV-Ext-CEKG — 十九张表一亿两千万事件

把一份重症病历变成一条能被流程挖掘算法读进去的事件日志，通常要耗掉一名博士生好几个月。难点不在算法，而在数据形态：流程挖掘要求每一行同时具备三样东西——一个时间戳、一个活动名、一个归属实体；而 MIMIC-IV 是为临床记录与行政管理设计的关系型库，时间散落在几十张表的不同列里，活动从来没有被命名过，患者、住院、留观、转科之间是多对多的。要把体征表、化验表、输液表、操作表拼出一条"入院—检查—用药—转科—出院"的轨迹，每一步都得自己拍板：时间戳取哪一列，同名操作怎么合并，缺失的住院号用什么回填。

MIMIC-IV-Ext-CEKG 是把这件事做完之后再发布的数据集。它不是新采集的队列，也不是又一个预测任务基准，而是一层已经预处理好的流程挖掘底座：19 张表、121,577,735 条事件、282,484 名患者、95 类临床活动，并且用五类约束节点映射（Constrained Node Mapping, CNM）把活动、活动域、疾病、ICD-10 与 SNOMED-CT 接到同一张图上。它的名字里 CEKG 是 Clinical Event Knowledge Graph 的缩写，即临床事件知识图谱——一个 2023 年才在国际流程挖掘会议上提出、专门面向多病共存患者的多实体事件数据框架。

它的定位清楚，代价也清楚。它只纳入了能提供时间与日期的那部分 MIMIC-IV 模块，因此天然漏掉一批没有精确时间戳的临床活动；它原样继承了 MIMIC-IV 按患者施加的日期偏移，因此不能拿去做与外部事件对齐的精确时序分析；官方自己写明，用它训练机器学习模型这件事"尚未被检验过"。一屏速览见下表。

一屏速览

维度	内容
全名	MIMIC-IV-Ext-CEKG: A Process-Oriented Dataset Derived from MIMIC-IV for Enhanced Clinical Insights
缩写含义	CEKG = Clinical Event Knowledge Graph，临床事件知识图谱
发布方	PhysioNet；数据由挪威科技大学（NTNU）与埃因霍温理工大学团队构建
首次发布	2025 年 4 月 8 日，版本 1.0.0（目前唯一版本）
表数量	1 个模块，19 张表
事件数	121,577,735 条
患者数	282,484 名
住院标识数	448,709 个
门诊标识数	550,405 个
活动类别数	95 类，每类配一个缩写同义词
实体（对象）数	5 个：患者、住院、门诊、住院序号、门诊序号
时间跨度	2008—2019 年（继承自 MIMIC-IV）
原始来源	MIMIC-IV v2.2、MIMIC-IV-ED v2.2、MIMIC-IV-Note v2.2，外加 OHDSI Athena 与 SNOMED-CT RF2
术语绑定	ICD-10 与 SNOMED-CT，通过 CNM1—CNM5 五类映射连接
文件格式	关系型表格（官方以 CSV 形式发布，可用 BigQuery 或 MariaDB 装载）
许可	PhysioNet Credentialed Health Data License 1.5.0，须凭证、CITI 培训与数据使用协议
典型用途	多实体（对象中心）流程挖掘、临床事件知识图谱构建、临床路径发现、时序建模

§1 它要解决的具体麻烦

1.1 流程挖掘要的三样东西，MIMIC-IV 一样都不现成

流程挖掘的输入是事件日志，而事件日志有一条极简的定义：每条记录必须有时间戳、活动名与归属实体。这条定义看着朴素，落到 MIMIC-IV 上却处处是坑。

时间戳的问题在于分散与精度不一。MIMIC-IV 里有的表精确到分钟（体征、输液、化验采样），有的只有日期（诊断、部分医嘱），有的干脆是"入 ICU 第一天"这类聚合量。要做事件序列，就得先把它们统一到同一个时间轴上——日期型记录还要决定它落在当天几点。

活动名的问题在于根本不存在。MIMIC-IV 没有任何一列写着"这次事件的名称叫什么"，它有的是 itemid、orderid、event_txt 这类编码或自由文本。把"抽了一次动脉血做血气"这件事叫成什么，是用 label 还是用 fluid 加 label，全靠使用者自己定，而两个团队定出来的活动名几乎不可能对齐。

实体的问题在于多对多。一次住院里有多次留观，一次留观里有多次转科，一个患者有多次住院。传统的单实体事件日志只能选一个作为案例标识（case notion），选 subject_id 就把同一个人几年的轨迹压成一条，选 hadm_id 就看不到门诊部分，选 stay_id 又把一次住院切碎。

这三样东西并不是并列的技术细节，它们之间还有耦合：一旦换了案例标识，活动名的合理粒度也会跟着变。以 subject_id 为轨迹单位时，"入院"这个活动在一条轨迹里可能出现十几次，过程发现算法会把它当成一个高频循环；以 hadm_id 为单位时，它只出现一次，才是符合直觉的形态。换句话说，活动名的定义与实体的选择必须先一起定下来，先定一个再补另一个，几乎必然要返工。

正是在这个意义上，多实体事件数据（multi-entity event data）才被提出来。它的主张很直接：不要强迫使用者只选一个案例标识，而是让一条事件同时挂在多个实体上，分析时再按问题决定看哪一层。这个概念在文献里有两个常用别名——侧重具体物理对象时叫对象中心事件日志（object-centric event log），侧重一般实体时叫多维事件日志（multi-dimensional event log），官方背景段把三个名字并列写了出来。

1.2 四条常见的错误期待

第一条，期待它是"MIMIC-IV 的一个更干净的版本"。它不是替代品，是投影：只保留能构成事件的那部分信息，且官方明确说只纳入了提供时间与日期的模块。想查某个原始字段的精确定义，仍然要回到 MIMIC-IV 本身。

第二条，期待它有"预测任务的现成标签"。它给的是事件序列与术语映射，不是结局标签。想做死亡率预测或再入院预测，标签要自己从事件轨迹里推，而官方明确提示在它上面训练机器学习模型的可行性还没有被检验过。

第三条，期待它的时间戳是真实日历时间。不是。MIMIC-IV 的日期按患者施加了随机偏移以去除标识，这个处理被原样继承；官方在用法说明里点名了这一点，并说明它会影响与外部事件或记录对齐的精确时序分析。

第四条，期待 95 类活动就是"MIMIC-IV 里所有做过的事"。不是，它是从能提供时间戳的那部分表里归并出来的。官方自己在方法段列出五个输入模块，在用法段却只写了三个模块，口径不一致，下文 §7.0 会处理。

1.3 它能给到的与给不到的

你的需求	它给的	够不够
多实体（对象中心）流程挖掘	五个实体并列，事件同时挂在患者与就诊上	够，这是它存在的理由
临床事件知识图谱构建	CNM1—CNM5 五类映射齐备，可直接喂给 CEKG 框架	够，且是唯一现成的大规模输入
单实体流程挖掘	取 Entity2_ID 作案例标识即可退化成传统事件日志	够，但浪费了它最独特的部分
临床路径发现与变异分析	95 类活动加特征级属性，支持按亚群切分	够，配 N_ClusterReference 两张表做亚群筛选
术语驱动的语义查询	SNOMED-CT 层级带 level 索引，可从根概念做路径遍历	够，只导入被用到的那部分概念
时序预测与深度学习	事件带时间戳，结构上是时序	不够，官方明示未检验
药物剂量或浓度的精确药学分析	NDC 码被校正与补全，含产品与包装信息	部分够，仍有 24 个码未能核实
影像、波形、自由文本	不涉及	不够，它只处理结构化事件
与外部日历事件对齐的研究	日期已被按患者偏移	不够，官方明确提示

1.4 你的处境与它能帮到的事

你的处境	它能帮你什么	下一步该做什么
你做过单实体流程挖掘，想转到多实体但找不到数据	提供五个实体并列的现成事件日志，不必自己做连接与回填	先用 N_ClusterReference1 圈一个慢病亚群，再按 §5.4 的方式切出子集
你在做临床路径变异分析，苦于活动名各家不一致	95 类活动由官方统一命名并配缩写同义词，可直接引用	把你的活动名映射到这 95 类，再用 K_CNM3 取得 SNOMED-CT 概念
你想把疾病编码与操作编码接成一张语义图	CNM1 接疾病与 ICD，CNM2 接 ICD 与 SNOMED-CT，CNM3 接活动与 SNOMED-CT	从 G_ICD 的 1,759 个码出发，按 J_CNM2 走到概念层
你在做多病共存患者的照护路径研究	实体属性里直接给了多病共存、已治疗、未治疗、新发四类属性	在 C_EntitiesAttributes 里按 Origin 与 Name 过滤
你手上只有 MIMIC-IV 权限，想省掉预处理	它替你做了 ICD-9 转 ICD-10、NDC 校正、化验项目归并	仍需单独申请本数据集的凭证，派生审批不覆盖父项目
你想复现 CEKG 论文的图构建流程	提供论文里缺的那块——一个大规模现成数据集	配合作者 2023 年论文与 2024 年工具论文一起读

1.5 一句话判断

它不是"更大的 MIMIC-IV"，而是"已经替你把 MIMIC-IV 折成事件日志形态的那一层"；如果你的工作在流程挖掘或临床路径这一侧，它省掉的是几个月的数据工程；如果你的工作在预测建模这一侧，它并不能替代任何现成的基准。

1.6 不适合谁：四条边界

不适合拿来做结局预测而期望有明确基线。 官方没有提供任何预测任务定义、划分方式或评测口径，并且明确写着用它训练机器学习模型的可能性尚未被检验。把它当成又一个 benchmark 用，会发现没有可比的对手。

不适合拿来做绝对时间意义上的时序研究。 日期被按患者偏移，跨患者的时间先后不可比，也不能与外部真实事件（如政策变更、季节因素）对齐。

不适合拿来做覆盖全部临床活动的完整性分析。 它只纳入带时间戳的部分，没有精确时间戳的活动被留在了外面，用它统计"某类操作做了多少"会系统性偏低。

不适合在只有 MIMIC-IV 凭证的情况下使用。 它是一个独立凭证的派生项目，父项目的审批不自动覆盖它；反过来也一样，你需要分别申请。

§2 数据构成与规格

2.1 十九张表与它们的分工

官方数据描述段把这 19 张表分成五组：事件层、实体属性层、术语层、映射层、聚类参考层。下表按官方表名字母前缀排列，并给出作者维护的官方文档站所载的记录数；PhysioNet 页面本身只描述列含义，不列行数。

表	分组	官方记录数	作用
B_EventLog	事件层	121,577,735	主事件日志，每行一个事件
C_EntitiesAttributes	实体属性层	7,243,702	实体及其属性的取值
D_EntitiesAttributeRel	实体属性层	5,133,925	实体与属性之间的关系
E_ActivityAttributes	事件层	395,077,510	活动实例的特征名与特征值
F_ActivitiesDomain	事件层	7	活动所属的域，共 7 个取值
G_ICD	术语层	1,759	ICD 码、版本与标题
H_SCT_Node	术语层	9,302	SNOMED-CT 概念节点与层级
H_SCT_REL	术语层	官方文档未列	SNOMED-CT 概念间关系
I_CNM1	映射层	1,759	疾病标识 → ICD 码
J_CNM2	映射层	官方文档未列	ICD 码 → SNOMED-CT
K_CNM3	映射层	官方文档未列	活动 → SNOMED-CT
L_CNM4_1	映射层	官方文档未列	活动 → 活动域
L_CNM4_2	映射层	官方文档未列	活动域 → SNOMED-CT
M_CNM5_Activity_Instance_ID	映射层	120,108,091	活动实例标识清单
M_CNM5_Activity_Instance_ID_with_features_Entities	映射层	官方文档未列	活动实例的特征与实体
M_CNM5_Activity_Instance_ID_with_class_Entities	映射层	官方文档未列	活动实例的类别与实体
M_CNM5_class	映射层	官方文档未列	疾病名与疾病标识的对应
N_ClusterReference1	聚类参考层	281,929	患者级聚类参考（性别、锚定年龄、死亡状态等）
N_ClusterReference2	聚类参考层	4,859,894	就诊级聚类参考（ICD-10 码与根概念）

表层关系可以这样理解：B 是主干，E 是主干上每个事件挂的特征，C 与 D 描述主干上每个实体的属性与属性间关系，G 与 H 两张术语表提供标准词汇，I 到 M 是把主干、疾病与术语三者缝起来的五类映射，N 的两张表是给"只想跑一部分数据"的人准备的筛选索引。

表名前缀不是随意排的，它同时是官方数据描述段的叙述顺序与推荐的阅读顺序：先读 B 建立对事件形态的认识，再读 C、D 看实体侧有什么属性，接着看 E、F 了解活动的特征与归类，然后进入 G、H 两张术语表，最后用 I 到 M 的五类映射把前面这些接起来。按这个顺序读的好处是每一步都只用上已经见过的概念。

有一组数字值得单独记住：E_ActivityAttributes 的 395,077,510 行是官方文档给出记录数的各表中最大的，比事件表的 121,577,735 行多得多；而 M_CNM5_Activity_Instance_ID 的 120,108,091 行与事件数处在同一数量级。这两条 함께说明同一件事：特征是按"活动实例—特征名—特征值"三元组展开存的，因此特征表的行数不由事件数决定，而由事件数乘以每个事件携带的特征条数决定。做容量规划时应该按 E 表而不是 B 表估算。

2.2 事件日志主表的字段字典

B_EventLog 是唯一包含时间维度的表，也是绝大多数用法的入口。逐列含义如下。

列	取值形态	含义	使用注意
Event_ID	整数	每条事件的唯一编号	官方记录数为 121,577,735
Timestamp	日期时间	活动发生的时间	患者级偏移已被继承，跨患者不可比
Activity	活动名	事件对应的活动标签	共 95 个不同取值
Activity_Synonym	缩写	活动名缩写，如 BGT 代表 Blood Gas Test	95 个活动配 95 个缩写
Activity_Attributes_ID	整数外键	每个"特征名+特征值"组合的唯一编号	同特征同值同号，同特征不同值不同号
Activity_Instance_ID	整数外键	每个"活动+全部特征取值"组合的唯一编号	用于在整个日志中追踪同一个活动实例
Entity1_origin / Entity1_ID	Patients / 患者号	第一个实体，等价 MIMIC 的 subject_id	282,484 个不同患者号
Entity2_origin / Entity2_ID	Admission / 住院号	第二个实体，等价 hadm_id	448,709 个不同取值，纯门诊患者为空
Entity3_origin / Entity3_ID	Outpatient / 门诊号	第三个实体，门诊就诊	550,405 个不同取值，纯住院患者为空
Entity4_origin / Entity4_ID	Admission_Sequence / 序号	该患者的住院次序	取值 1 到 238，纯门诊患者为空
Entity5_origin / Entity5_ID	Outpatient_Sequence / 序号	该患者的门诊次序	取值 1 到 114，纯住院患者为空
temp_patient_id	整数	子集分析的辅助列	等于 Entity1_ID
temp_encounter_id	整数或 O 前缀串	子集分析的辅助列	官方记录数为 999,112 个不同取值；建图前必须剔除

2.3 一条事件的完整解剖

官方给过一个四事件的例子，把两个外键的设计意图说得很清楚。设第一个事件是"血气检验"，特征为 po2=295、lactate=3.23；第二个是"血压测量"，特征为 Blood pressure=137/79；第三个又是"血气检验"，但特征为 po2=412、lactate=0.73；第四个又是血气检验，特征与第一个完全相同。

于是 Activity_Attributes_ID 的分配是：po2=295 得 1，lactate=3.23 得 2，血压那串得 3，po2=412 因为是同特征不同值所以得 4，lactate=0.73 得 5；第四个事件的两个特征与第一个完全相同，因此复用 1 与 2。而 Activity_Instance_ID 的分配是：第一与第四个事件同为血气检验且特征值一致，共用 1；第二个事件是不同活动，也得到 1（实例编号在活动内部计数）；第三个事件同为血气检验但取值不同，得到 3。

这个设计的实际含义是：Activity_Attributes_ID 把"特征名—特征值"这对组合压成一个整数，让事件表不必为每个可能的检验项开一列；Activity_Instance_ID 把"这次操作连同它当时的全部取值"压成一个整数，使得在不回表的情况下也能判断两次操作是否同质。代价是任何对特征的分析都必须回 E_ActivityAttributes 联结，而那张表有 395,077,510 行。

2.4 五个实体与主键映射

五个实体不是并列的概念层级，而是三条独立的索引轴加两条次序轴：患者（Entity1）是一条，住院（Entity2）与门诊（Entity3）是互斥的两条就诊轴，住院次序（Entity4）与门诊次序（Entity5）分别在各自轴上从 1 开始编号。

MIMIC 主键	对应实体	官方规模	何时为空
subject_id	Entity1（Patients）	282,484	不为空
hadm_id	Entity2（Admission）	448,709	纯门诊患者为空
新建的门诊号	Entity3（Outpatient）	550,405	纯住院患者为空
由 hadm_id 派生	Entity4（Admission_Sequence）	1—238	纯门诊患者为空
由门诊号派生	Entity5（Outpatient_Sequence）	1—114	纯住院患者为空

次序轴的取值范围本身就是一条边界信息：一名患者在这份数据里最多有 238 次住院、114 次门诊。这个上限对设计"按第几次就诊切分"的实验很有用，也比任何推算出来的集中趋势更可靠——因为它是官方直接给出的取值区间，而不是从数据里算出来的。

两条次序轴还有一个容易被忽略的用途：它们让"首次住院"与"第三次住院"这类对比不必依赖时间戳。由于 MIMIC-IV 的日期被按患者偏移，跨患者的绝对先后不可比，但同一患者内部住院次序是确定的，因此按 Entity4_ID 分组可以绕开日期偏移做"第几次住院"的分层分析。官方把它们做成独立实体而不是让使用者自己排序，正是为了让这件事不必回表重算。

2.5 五类约束节点映射

CNM 是 CEKG 框架里的核心机制，作用是给图上不同标签的节点之间建立关系。官方把它拆成五类，每类对应一张或一组表。

映射	连接的两端	生成方式	说明
CNM1	疾病标识 → ICD 码	由 MIMIC-IV 直接得到	官方说明疾病不一定都能映射到 ICD，故需假设性标识
CNM2	ICD 码 → SNOMED-CT	借 OHDSI Athena 自动映射	1,760 个码中有 8 个需人工映射
CNM3	活动 → SNOMED-CT	人工，用 SNOMED-CT 浏览器逐个查	人工成分最重的一类
CNM4_1 / CNM4_2	活动 → 活动域 → SNOMED-CT	人工，经活动域中转	官方说明活动域为人工整理
CNM5	活动实例 → 疾病等新实体	无法直接得到，留待领域知识或机器学习	因此官方只提供"便于生成 CNM5"的辅助表

CNM5 的缺席值得单独说。CEKG 框架假定事件可以指向疾病这类新实体，但 MIMIC-IV 里事件与疾病之间没有直接的关联列，官方因此没有造一条映射出来，而是提供了 M_CNM5 系列四张表供使用者自行生成——这是这个数据集里唯一一处把"做不了"明确写进设计的地方。

2.6 与上游 MIMIC-IV 的字段差异

官方在用法说明里列了三项它相对 MIMIC-IV 做的实质改动，这三项也是它与上游字段不一致的来源。

第一项是 ICD。MIMIC-IV 的编码存在一列 25K 个不可比编码、格式错误、ICD-9 与 ICD-10 混用、粒度层级不一致四类问题。它把这些码统一成两列：一列 1,760 个高层 ICD 码，一列 19K 个可比的 ICD 码，并统一为 ICD-10，保留层级结构（例如 E11 与 E11.329 的父子关系）。

第二项是 NDC（国家药品编码）。官方把 pharmacy、eMAR、prescriptions 三张表的药房数据合并后导出 5,732 个编码，再通过网络抓取扩展到 7,376 个；其中 6,265 个核实到了准确的产品与包装信息，1,087 个需借助 GSN、RxNorm 与专有库人工查找，24 个最终未能核实，只靠相关表的附加信息做了修正。

第三项是化验项目。官方把 Chemistry、Hematology、Blood_Gas 三张化验表合并成一张，并人工细化了 fluid 的取值（把"血"细分为外周全血样本分析、外周血浆样本分析等），同时给 label 补了短同义词、计量单位与正常值范围。

§3 它是谁的数据

3.1 贡献者与机构

三位作者分属两所机构：Milad Naeimaei Aali 与 Pieter Jelle Toussaint 来自挪威科技大学（NTNU，特隆赫姆），Felix Mannhardt 来自埃因霍温理工大学。署名顺序与 PhysioNet 页面标注的通讯作者一致。这个组合本身就说明了数据集的性质——流程挖掘方向的研究组与临床信息学方向的研究组合作，产出的是一个方法论驱动的数据集，而不是临床科室驱动的队列。

官方致谢里特别提到 Alistair Johnson，感谢他就"基于 MIMIC-IV 构建这样一个数据集是否可行"给出的指导与答复。

3.2 时间线

时间	事件
2023 年	CEKG 框架论文在国际流程挖掘会议（ICPM）发表，提出临床事件知识图谱并给出本地原型脚本
2024 年	同一组作者的 CEKG 工具论文发表，把原型脚本扩展为在线构建与管理工具
2025 年 4 月 8 日	MIMIC-IV-Ext-CEKG 版本 1.0.0 在 PhysioNet 发布

这条时间线解释了数据集的动机：框架与工具都已有，缺的是"一个大规模、拿来就能用的数据集"，官方背景段把这句话直接写成了立项理由。

3.3 采集场景

数据来自美国马萨诸塞州波士顿贝斯以色列女执事医疗中心（Beth Israel Deaconess Medical Center）重症监护病房收治患者的去标识化健康记录，时间跨度为 2008 年至 2019 年。这是从 MIMIC-IV 继承来的，不是本数据集自己采集的。

由此带来两条与使用场景直接相关的边界。其一，人群是 ICU 收治患者，不是普通门诊人群，因此"多病共存"在这里的定义偏向重症与复杂住院人群。其二，单中心、单一国家、单一医疗系统，跨机构泛化能力无从谈起——官方没有对此作任何声明，但这是一个派生数据集无法摆脱的约束。

3.4 派生链条

层级	内容
上游	MIMIC-IV v2.2、MIMIC-IV-ED v2.2、MIMIC-IV-Note v2.2
外部输入	OHDSI Athena 词表系统、SNOMED-CT RF2（Description / Relationship / TextDefinition 三个文件）、SNOMED-CT 浏览器
加工	八个步骤：基础设施 → 输入准备 → 事件表构建 → ICD 表构建 → 实体活动表构建 → SNOMED-CT 表构建 → 聚类参考表构建 → 发布
产物	19 张表

官方在"父项目"区块列出三个上游版本，并要求使用时一并引用。注意这里与方法段、用法段之间存在的模块口径差异（§7.0）。

§4 它最独特的东西

4.1 稀缺性：现成的多实体事件日志

流程挖掘 community 里，单实体事件日志的公开数据并不算稀缺，多实体的才是。所谓多实体，是指一条事件同时挂在多个对象上——一次血气检验既属于某个患者，也属于某次住院，还可能属于某次留观。传统事件日志强迫你只选一个案例标识，于是必然丢失其他视角；多实体事件日志（在文献里也叫对象中心事件日志或多维事件日志）保留了全部视角，代价是数据结构复杂得多。

MIMIC-IV-Ext-CEKG 给了五个实体，并且是一次性给到 ICU 级别的规模：121,577,735 条事件。就"现成、大规模、多实体、且带临床术语绑定"这四个条件的交集而言，它是目前公开渠道里少见的一个。

4.2 差异化证据

对比对象	它的形态	本数据集的差异
MIMIC-IV 本身	关系型临床库，无活动概念	多出 95 类命名活动与统一时间戳
单实体事件日志类派生集	一个案例标识，通常只覆盖急诊或住院之一	五个实体并列，住院与门诊同在
只做术语映射的派生集	给编码加标准词表	除映射外还给出事件序列与实例级特征
影像或波形类派生集	面向感知任务	面向过程与路径分析
站内 MIMIC-IV-Ext 系列其他成员	各自面向诊断决策、入排问答等任务	本数据集面向过程本身，不给任务标签

4.3 活动粒度的具体案例

95 类活动的特征数量分布很宽：官方给出的清单里，最少的三类活动（从急诊离院、急诊挂号、随机尿蛋白电泳）特征数为 0，最多的"外周血血浆样本分析"有 183 个特征。中间的例子包括"血气检验"24 个特征、"序贯器官衰竭评分"28 个特征、"简化急性生理评分"19 个特征、"首日化验检验"86 个特征。

这种宽度带来一个实际后果：同样是"一个事件"，不同活动的特征规模可以相差两个数量级。做特征级建模时，把 95 类活动一视同仁地平铺成一个大宽表，会得到一个列数极多且绝大多数为空的矩阵；更合理的做法是按活动分组建模，或者只用 E_ActivityAttributes 里你关心的那部分特征。

官方清单里还有一处值得留意的现象：部分活动的特征名看起来与该活动的语义无关，例如"血压测量"的特征里出现了 specimen_id，"骨穿标本浆液分析"的特征里出现了 Lambda 与 CD56。这提示特征归并过程是按表与列的来源做的，而非按语义严格筛选，使用它时应先核对特征名的实际出处。

与之相关的另一个后果是：特征数相同的两个活动，语义含量可能完全不是一回事。清单里特征数为 2 的活动有十四个，其中既有"抗生素给药"这样的临床操作，也有"骨髓标本浆液分析"这样的检验；前者只有 ab_id 与 COHb 两个特征，后者的两个特征却是 Lambda 与 CD56。因此不能把"特征数"当作活动信息量的代理指标来筛选活动。

4.4 映射的两层：自动生成与人工核对

19 张表里的映射不是同一批工艺做出来的，至少分三档。第一档是自动的：CNM1 由 MIMIC-IV 直接得到，CNM2 借 OHDSI Athena 的 ICD-SNOMED 映射得到。第二档是半自动的：NDC 码靠网络抓取加人工查找，ICD 码靠抓取加人工比对。第三档是纯人工的：CNM3 与 CNM4 系列完全靠 SNOMED-CT 浏览器逐个查证，F_ActivitiesDomain 的 7 个域也是人工整理的。

这三档的可靠性并不相同，而官方没有对每一档给出覆盖率数字，只给出了两个具体的点：CNM2 的 1,760 个码里有 8 个需要人工映射；NDC 的 7,376 个码里最终有 24 个未能核实。这意味着人工干预在量上是小的，但在语义关键处（活动到概念的映射）是全部的。

4.5 边界条件

时间精度上的边界。 日期型记录在回填时间戳时用了一套规则：若给日期加 12 小时落在该实体时间区间内就用它，否则取区间中点。测量型记录则是在区间最早时间上加 24 小时。这两条规则让时间戳具备可比性，但也意味着相当一部分事件的时间是构造出来的，而非记录的。

实体完整性上的边界。 官方说明按 subject_id 与日期去匹配 hadm_id 时并非总能匹配上，匹配不上的会置空；匹配到多个住院号时，只保留排名最高的那个，其余丢弃；最终仍缺住院号的，填 0。也就是说，Entity2_ID 为 0 的行不代表真实存在编号为 0 的住院。

术语覆盖上的边界。 H_SCT_Node 只有 9,302 条，远不是完整的 SNOMED-CT。官方的做法是只导入被活动、活动域与 ICD 映射用到的那些概念，以及它们到根概念（138875005）路径上的全部概念。这是一个刻意的范围控制，好处是体积小、查询快，代价是任何超出这个概念子集的问题都答不了。

§5 怎么拿到

5.1 官方入口与准入条件

入口是 PhysioNet 上的项目页，最终 URL 带版本号。访问分四步：注册 PhysioNet 账号；申请成为凭证化用户；完成人体研究伦理与数据隐私培训（页面要求的课程是 CITI 的 Data or Specimens Only Research）；签署本数据集专有的数据使用协议。

许可为 PhysioNet Credentialed Health Data License 1.5.0，数据使用协议为 PhysioNet Credentialed Health Data Use Agreement 1.5.0。三点必须记住：只有签署了协议的用户才能看到文件；父项目 MIMIC-IV 的凭证不覆盖本数据集；本数据集的凭证也不覆盖父项目。另外，官方页面在部分区域会返回"Data is not available in your region"，这不是数据集下架，而是区域限制。

5.2 目录结构

官方以关系型表格形式发布，推荐两种装载方式：本地用 MariaDB 之类的 SQL 关系库，云端用 Google BigQuery。19 张表在同一个模块下，表名字母前缀（B 到 N）即官方数据描述段的排列顺序，也是阅读顺序。

5.3 批量下载

#-- 凭证化整库下载：把 <USER> 换成 PhysioNet 用户名，口令在提示处输入
wget -r -N -c -np --user <USER> --ask-password \
  https://physionet.org/files/mimic-iv-ext-cekg/1.0.0/

#-- 只取事件日志一张表时，先列目录确认确切文件名再下载
curl -sL --user <USER> \
  https://physionet.org/files/mimic-iv-ext-cekg/1.0.0/ | grep -i eventlog

5.4 组装成可挖掘的事件日志

import pandas as pd

#-- 只读事件层必需的列；temp_* 两列是子集分析用的辅助列，建图前必须剔除
cols = ["Event_ID", "Timestamp", "Activity", "Activity_Synonym",
        "Activity_Instance_ID", "Entity1_ID", "Entity2_ID",
        "Entity3_ID", "Entity4_ID", "Entity5_ID"]
ev = pd.read_csv("B_EventLog.csv", usecols=cols,
                 parse_dates=["Timestamp"])

#-- 退化成单实体事件日志：把住院号作为案例标识，丢掉没有住院号的门诊行
single = ev.dropna(subset=["Entity2_ID"]).copy()
single = single.rename(columns={"Entity2_ID": "case:concept:name",
                                "Activity": "concept:name",
                                "Timestamp": "time:timestamp"})

import pm4py

#-- 交给 PM4Py 之前先按时间排序，否则发现出的模型会错乱
log = pm4py.format_dataframe(
    single.sort_values("time:timestamp"),
    case_id="case:concept:name",
    activity_key="concept:name",
    timestamp_key="time:timestamp")

#-- 多实体视角：换个案例标识就是另一条轨迹，不要把它们混进同一个日志
per_patient = ev.rename(columns={"Entity1_ID": "case:concept:name"})

5.5 术语映射的组装

#-- 从疾病走到 ICD 再走到 SNOMED-CT 概念：三段联结
SELECT c1.Disorder_ID,
       c1.ICD_Code,
       c2.SCT_ID,
       s.SCT_DescriptionA_Type2,
       s.SCT_Level
FROM   I_CNM1      AS c1
JOIN   J_CNM2      AS c2 ON c2.ICD_Code = c1.ICD_Code
JOIN   H_SCT_Node  AS s  ON s.SCT_ID    = c2.SCT_ID
WHERE  s.SCT_Type = 'concept';

#-- 从活动走到 SNOMED-CT：先经活动域，或直接查人工映射表
SELECT k.Activity, k.Activity_Synonym, d.Activity_Domain, l.SCT_ID
FROM   K_CNM3            AS k
JOIN   L_CNM4_1          AS d ON d.Activity = k.Activity
JOIN   L_CNM4_2          AS l ON l.Activity_Domain = d.Activity_Domain;

H_SCT_Node 里的 SCT_Level 是概念到根概念 138875005 的距离索引，官方说明一个概念可能有多条到根的路径，因此可能有多个层级值。做层级上卷查询时，这个索引能省掉递归遍历，但要记得它是一对多而不是一对一的。

5.6 文件结构的五个坑

第一个坑：temp_patient_id 与 temp_encounter_id 是辅助列。 官方明确说明，无论是在全量还是子集上工作，这两列在生成最终 CEKG 事件日志时都应被剔除。它们只是子集筛选用的把手，不是实体。

第二个坑：Entity2_ID 与 Entity3_ID 的互斥。 住院患者没有门诊号，门诊患者没有住院号，两列各自有空值。按其中一列做连接时，另一侧的样本会被静默丢掉。

第三个坑：Entity2_ID 为 0 不是真实编号。 官方写了，匹配不到住院号时会填 0。把它当成一个真实的 hadm_id 去关联 MIMIC-IV，会得到空结果或错误结果。

第四个坑：E_ActivityAttributes 的行数远大于事件数。 它有 395,077,510 行，因为它存的是"活动实例—特征名—特征值"三元组，一次血气检验可能对应二十几行。以为它和事件表一一对应而直接做行对齐，是常见错误。

第五个坑：SNOMED-CT 不是全量。 H_SCT_Node 只有 9,302 条，是按需导入的子集。想查一个没被任何活动、活动域或 ICD 用到的概念，这张表里不会有。

补充两条操作层面的提醒。第一，B_EventLog 的读取应当用 usecols 显式指定列，而不是整表读入后再丢列——五个实体各两列、加上两个辅助列与两个外键，整表宽度足以让内存占用翻倍，而绝大多数分析只用到其中一半。第二，若你的流程挖掘工具要求事件日志按案例标识与时间有序，务必在格式化之前排序；本数据集的 Event_ID 不保证与 Timestamp 同序，按 Event_ID 顺序直接喂进去会产出错误的直接跟随图。

§6 与库内条目的关系

6.1 关系图谱

MIMIC-IV（母数据集）
├── MIMIC-IV-ED（急诊模块）──→ 本数据集的门诊实体来源之一
├── MIMIC-IV-Note（出院小结）──→ 上游输入之一
└── MIMIC-IV-Ext-CEKG（本数据集）
      ├── B_EventLog ──→ 多实体事件日志
      ├── G_ICD / H_SCT_Node ──→ 术语层
      └── I—M 系列 CNM 表 ──→ 语义映射层

同一个"Ext"命名前缀下还有若干成员，各自解决的是完全不同的问题，不能靠前缀推断内容。

6.2 检索路径

若你要的是"事件序列 + 术语绑定 + 多实体"，直接取本数据集。若你要的是"急诊留观的事件日志"，站内 MIMICEL 是更贴近的选择，它基于 MIMIC-IV-ED 构建，案例标识与活动类别都更聚焦。若你要的是"临床事件的时间序列对"，MIMIC-IV-Ext-22MCTS 提供的是另一条路线——从出院小结里抽事件与相对小时。若你要的是"带标签的预测或问答任务"，应转向 MIMIC-IV-Ext-CDM、MIMIC-IV-Ext-CDS 或 MIMIC-IV-Ext-Apixaban-Trial 这一类。

还有一条反向的检索路径容易被忽略：如果你的问题最终要落在原始字段上——比如某个化验项目的单位、某个编码的版本、某次操作的原始记录——那么本数据集不是终点而是跳板，你需要顺着 Entity1_ID 与 Entity2_ID 回到 MIMIC-IV 本体去核。反过来说，如果你发现自己在做的事是"把 MIMIC-IV 拼成事件序列"，那应该先停下来确认这件事是不是已经被人做过。

判断是否需要同时申请两个凭证，可以用一条简单的规则：只要你的工作涉及回上游核对字段语义，就需要两个；只要你的工作完全停留在事件与术语这一层，本数据集一个就够。

6.3 分工判据：一张对照表

站内词条	它的产出形态	与本数据集的分工
MIMIC-IV	关系型临床库	上游；本数据集替你做了折成事件日志的活
MIMICEL	急诊事件日志，单实体为主	同属事件日志，但只看急诊、实体更少
MIMIC-IV-ED	急诊模块原始表	本数据集门诊实体的来源之一
MIMIC-IV-Note	去标识化自由文本	上游输入之一，本数据集未把文本做成实体
MIMIC-IV-Ext-22MCTS	事件—相对小时对	同为事件化，但源是文本抽取而非结构化表
MIMIC-IV-Ext-CDM	自主诊断评测集	面向 LLM 诊断决策，不给事件日志
MIMIC-IV-Ext-CDS	急诊决策支持评测集	面向分诊与转诊，任务导向
MIMIC-IV-Ext-Apixaban-Trial	入排标准问答对	面向试验入排，规模小、人工复核
MIMIC-IV-ECHO	超声影像与测量	面向影像模态
MIMIC-IV-ECG	十二导联波形	面向波形模态

§7 质量评估与局限性

7.0 前置校正：有几处口径要先统一

在引用任何数字之前，先处理官方材料内部的四处不一致。

第一处是模块范围。方法段列出的输入模块是 MIMICIV_HOSP、MIMICIV_ICU、MIMICIV_DERIVED、MIMICIV_ED、MIMICIV_NOTE 五个，而用法段写的是"只包含 mimiciv_hosp、mimiciv_icu 与 mimiciv_derived 三个模块"。两句话不可能同时成立，官方没有给出解释。实践上应按用法段理解——即只有三个模块真正进入了事件层——但必须知道官方自己说过五个。

第二处是 ICD 高层码的数量。方法段写"1,760 个高层 ICD 码"，官方文档站给出的 G_ICD 记录数与不同疾病数是 1,759。差 1，来源不明。

第三处是患者数。事件日志的不同患者号是 282,484，而 N_ClusterReference1 的记录数是 281,929。两者不是同一个口径（一个是不同取值数，一个是表行数），差 555，不能互相替代引用。

第四处是列名。PhysioNet 数据描述段写 G_ICD 的第四列是 ICD_Code_Title，官方文档站同一张表同一位置写的是 ICD_strong_Title。以哪一处为准无法判断，写 SQL 时最好先读实际表头。

7.1 五维评分

维度	评价	理由
规模	高	1.2 亿条事件、28 万余患者，事件日志类里少见
结构完整度	高	五实体、五类映射、术语层齐备，结构自洽
文档完备度	中	有独立的官方表级文档站，但 PhysioNet 页本身不列行数，且存在上述四处不一致
可用性	中	需凭证、CITI 与协议三重门槛；区域限制会让部分用户看不到文件
任务就绪度	低	不给预测标签，官方明示机器学习可用性未检验

7.2 映射的两层机制

映射数据在这里分"有据可查"与"人工判断"两层。前者包括 CNM1（直接来自 MIMIC-IV 的疾病编码）与 CNM2（来自 OHDSI Athena 的标准映射），可用外部词表复核。后者包括 CNM3、CNM4 系列与 F_ActivitiesDomain 的 7 个域，完全依赖人工查证，无法用外部词表复核，只能靠领域专家复审。

这两层的可靠性差异，在使用上的含义是：涉及疾病与 ICD 的结论相对可追溯；涉及"某个活动对应哪个 SNOMED-CT 概念"的结论，本质是作者的一次专业判断，引用时应注明。

7.3 可枚举的偏差清单

时间戳的构造性偏差。 日期型记录的时间戳按规则构造（加 12 小时或取区间中点），测量型记录加 24 小时。因此事件之间的先后次序里，有一部分是规则产生的而非记录产生的。任何依赖精确间隔的分析（如"从开医嘱到执行的等待时间"）都会受此影响。

患者的日期偏移偏差。 MIMIC-IV 按患者施加的随机日期偏移被原样继承，跨患者的绝对时间不可比。

活动覆盖的选择性偏差。 只纳入带时间戳的模块，没有精确时间的临床活动被系统性排除，因此"某类操作的总量"类统计会偏低。

特征归并的语义松弛。 活动特征里出现与活动名语义不符的字段（如血压测量带 specimen_id），说明归并是按列来源而非语义做的。

术语子集偏差。 SNOMED-CT 只导入被用到的概念及其到根的路径，范围之外的问题答不了。

单中心人群偏差。 全部数据来自一家医院的重症监护病房，且以复杂住院人群为主。

7.4 外部验证情况

官方没有给出任何外部验证结果，也没有给出基线实验。唯一与"验证"沾边的表述是负面的：官方明确说在上面训练机器学习模型的可能性尚未被检验，M_CNM5 系列表是为这件事准备的。作者自己的 CEKG 框架论文与工具论文提供了方法论侧的验证，但那些验证不使用本数据集。

因此，对想引用它的研究而言，一个现实的建议是：把它作为流程挖掘与图构建的输入，而把任何性能数字都留给自己的实验，不要在文献里找现成基线——目前没有。

7.5 为什么这些局限会持续存在

大部分局限是继承来的，不是可以修的。日期偏移来自 MIMIC-IV 的去标识化策略，派生数据集无权改动；活动覆盖的缺失来自源数据的记录粒度，补不上；单中心人群的性质无法通过后处理改变。

真正可能改进的是文档一致性那几处。模块口径、ICD 高层码数量、患者数与列名四处不一致，全部属于表述层面的问题，一次版本修订就能解决。而官方目前只有 1.0.0 一个版本，尚未出现修订。

§8 生态位与历史

8.1 沿革：从框架到工具到数据

这条线走得很有次序：2023 年先提出 CEKG 框架并给出本地原型脚本，2024 年把原型脚本做成在线构建与管理工具，2025 年补上最后一块——一个大规模、拿来就能用的数据集。官方背景段把动机写成一句话：框架与工具都有了，缺的是一个现成的大规模数据集。

这个次序解释了数据集的许多设计选择。它之所以用 CNM1 到 CNM5 这样的编号命名表，是因为这些表名直接取自框架论文里的机制名；它之所以强调"无需预处理即可用于流程挖掘"，是因为填补的正是这一格；它之所以把 SNOMED-CT 的层级做成带 level 索引的子集而不是整表导入，是因为框架的核心操作之一就是沿层级做路径遍历，而官方在方法段里明确写了这个索引"用于提升查询速度"。

从这个次序也能看出一个更一般的现象：近年的 MIMIC 派生项目正在从"加一层任务"转向"换一种形态"。早期派生集多半是给原始数据贴上标签或配上问答，让它可以喂给某个模型；这一类派生集不改变数据的组织方式。而本数据集与少数同类做的是另一件事——把关系型库重组成事件日志或图，让原本无法直接运行的一类算法可以直接运行。两类派生集的评审口径不该混用：前者看标签质量，后者看结构是否自洽。

8.2 与 CEKG 框架及工具的关系

它不是一个独立的数据产品，而是框架的输入。官方用法说明的第一句就写明了：要使用它，需要获得授权访问；它虽然专为构建临床事件知识图谱与配套工具而设计，但也可以用于更广泛的流程挖掘工具——B_EventLog 与 E_ActivityAttributes 两张表可以进任何流程挖掘或数据挖掘流程。

8.3 生态位

在 MIMIC-IV 的派生生态里，多数成员做的是"加一层任务"：加标签、加问答、加配对、加影像。本数据集做的是"换一种形态"：把关系型库折成事件日志与图。这两种路线不冲突，但使用者容易混淆——看到 Ext 前缀就以为有标签，是常见的误判。

在流程挖掘生态里，它的位置是"规模最大且带临床术语的多实体事件日志之一"。它的竞争对象不是别的 MIMIC 派生集，而是"研究者自己从原始库拼一个事件日志"这件事本身。

8.4 谁在用

官方页面记录的项目浏览量为 666 次（当前版本与全部版本同一数值，说明尚未有版本迭代加总）。这个量级与 MIMIC-IV 本体相比很小，符合一个面向窄领域方法论、且需凭证访问的数据集的预期。

引用它的方式官方给了明确的 BibTeX，并额外要求同时引用 PhysioNet 平台本身的文献，以及三个上游父项目。

§9 使用指引

9.1 三种角色的路径

角色	建议路径
流程挖掘研究者	直接用 B_EventLog，按 Entity2_ID 或 Entity1_ID 选案例标识；需要特征时再联结 E_ActivityAttributes；需要语义时走 K_CNM3 与 L_CNM4 系列
临床路径分析人员	先用 N_ClusterReference1 按患病种数、住院次数、年龄、性别与死亡状态圈定亚群，再回事件表按 temp_patient_id 切子集
医疗知识图谱工程师	从 G_ICD 的 1,759 个码出发，经 I_CNM1 与 J_CNM2 到概念层，用 H_SCT_REL 与 SCT_Level 做层级遍历；活动侧走 CNM3 与 CNM4

9.2 最短流程

第一步，申请凭证、完成 CITI 培训、签署协议，并单独确认父项目 MIMIC-IV 的访问。第二步，装载 19 张表到本地 MariaDB 或 BigQuery。第三步，只取 B_EventLog，剔除两列 temp_*，确认实体列的空值模式。第四步，按研究问题选案例标识，用 PM4Py 格式化成事件日志并做过程发现。第五步，若需要语义，再按需联结术语与映射层，不要一开始就全表联结。

9.3 引用方式

@article{PhysioNet-mimic-iv-ext-cekg-1.0.0,
  author = {{Naeimaei Aali}, Milad and Mannhardt, Felix and Toussaint, Pieter Jelle},
  title  = {{MIMIC-IV-Ext-CEKG: A Process-Oriented Dataset Derived from MIMIC-IV
             for Enhanced Clinical Insights}},
  journal = {{PhysioNet}},
  year    = {2025},
  month   = apr,
  note    = {Version 1.0.0},
  doi     = {10.13026/qr9d-6t52},
  url     = {https://doi.org/10.13026/qr9d-6t52}
}

版本 1.0.0 的 DOI 是 10.13026/qr9d-6t52，最新版本的 DOI 是 10.13026/wqvp-h188。写正式引用时，还应包含 PhysioNet 平台本身的文献，以及 MIMIC-IV v2.2、MIMIC-IV-ED v2.2、MIMIC-IV-Note v2.2 三个父项目的引用——官方在父项目区块明确提出了这一要求。

§10 AI 使用声明

项目	声明
文本生成	本文由 AI 辅助撰写，编辑把关结构与事实
数字来源	规模、结构、边界三类数字来自 PhysioNet 官方 1.0.0 页面正文，以及作者维护的官方表级文档站
文件核验	19 张表的表名与列定义经官方 Data Description 段逐一确认；区域限制导致无法直读文件内容或目录清单
不一致说明	官方材料内部存在四处口径不一致（模块范围、ICD 高层码 1,760／1,759、患者数 282,484／281,929、列名 ICD_Code_Title／ICD_strong_Title），已在 §7.0 列出
论文信息	仅检索公开索引的元数据与官方参考文献列表，未读 CEKG 框架论文与工具论文全文
未核验内容	各表的确切列数与文件体积；H_SCT_REL、J_CNM2、K_CNM3、L_CNM4_1、L_CNM4_2、M_CNM5 系列三张表的记录数；活动特征名与活动名不符的具体成因；9,302 个 SNOMED-CT 概念的层级构成
图像	无配图；封面为生成式提示词，不含任何真实病历内容
免责	本文不构成临床建议；数据使用须遵守凭证制许可与数据使用协议

常见误读（避坑清单）

说法	实际	证据
CEKG 与心电图（ECG）有关	CEKG 是 Clinical Event Knowledge Graph，临床事件知识图谱	官方标题全称与背景段缩写定义
它是 MIMIC-IV 的升级替代版	它是投影：只保留能构成事件的部分	官方用法说明关于模块选择性的表述
有了它就不用申请 MIMIC-IV 了	两者凭证互相不覆盖，须分别申请	官方 Access 与 Parent Projects 区块
95 类活动等于 MIMIC-IV 里所有做过的事	只纳入带时间戳的部分，无时间戳的活动被排除	官方用法说明
事件时间戳是真实日历时间	继承 MIMIC-IV 按患者施加的日期偏移	官方 Limitations 段
1.2 亿条事件对应 1.2 亿个不同患者	患者数 282,484，事件数 121,577,735	官方文档站 General Overview
Entity2_ID 为 0 是真实住院号	0 是匹配失败后的填充值	官方 Methods 关于默认值 0 的说明
它自带预测任务的标签与基线	没有任务定义，官方明示机器学习可用性未检验	官方 Usage Notes
H_SCT_Node 是完整的 SNOMED-CT	只导入被用到的概念及其到根的路径，共 9,302 条	官方 Methods Step 6 与文档站
E_ActivityAttributes 与事件表一一对应	它存的是三元组，行数 395,077,510，远多于事件数	官方文档站 Activity Attributes 页
五类 CNM 都是自动生成的	CNM3 与 CNM4 系列完全人工，活动域也是人工整理	官方 Methods 各 Sub-step
temp_patient_id 是第五个实体之外的实体	它是子集筛选辅助列，建图前应剔除	官方 Data Description 与文档站

FAQ

Q1：CEKG 到底是哪个缩写？为什么容易和 ECG 搞混？

CEKG 是 Clinical Event Knowledge Graph 的首字母缩写，中文译作临床事件知识图谱，是流程挖掘领域 2023 年提出的一个框架。它与心电图 ECG（electrocardiogram）没有关系，数据集里也不含任何波形或心电数据。混淆主要来自字母顺序：CEKG 与 ECG 只差一个字母的位置，而 MIMIC 系列里确实存在多个心电相关的派生项目，容易凭字面联想。判断方法很简单——看官方标题全称，A Process-Oriented Dataset Derived from MIMIC-IV 里的 Process-Oriented（面向过程）已经点明了性质，这是一个关于"过程"而不是关于"信号"的数据集。

Q2：我已经有 MIMIC-IV 的凭证，为什么还要再申请一次？

因为 PhysioNet 的凭证是按项目授予的，派生项目与父项目的审批彼此独立。官方页面把这一点写得很清楚：只有签署了本数据集数据使用协议的凭证化用户才能访问文件；同时在父项目区块列出 MIMIC-IV v2.2、MIMIC-IV-ED v2.2 与 MIMIC-IV-Note v2.2，要求使用时一并引用。反向也一样——你拿到了本数据集的凭证，也不等于可以去看 MIMIC-IV 的原始表。若你的工作需要回到上游核对字段定义（例如某个化验项目的单位或某个编码的版本），两个权限都得有。此外，部分地区会因为法律或政策限制直接返回区域不可用的提示，这与审批状态无关。

Q3：95 类活动是怎么定出来的，能不能自己改？

活动是在方法段的第五步"活动整合"里归并出来的，来源有三类：由若干张表合并得到，由一张表拆分得到，或直接沿用原表不加改动。官方举过拆分的例子——POE 表按 field_name 的不同取值被拆成了十张表；也举过合并的例子——首日血气的两张表通过新增一列取值（NA 与 ART）合并成一张。活动名与缩写是一一对应的 95 对。能不能改，取决于你要不要和别人对齐：这套命名的价值在于它是公开的、固定的，别人引用"Blood Gas Test"时指的是同一件事；你当然可以在自己内部重命名，但那样就失去了可比性，也失去了 K_CNM3 里已经配好的 SNOMED-CT 映射。

Q4：为什么官方自己的材料里数字对不上？

至少四处。其一是模块范围，方法段列了五个输入模块，用法段只写三个；其二是 ICD 高层码，方法段写 1,760，文档站的 G_ICD 记录数与不同疾病数都是 1,759；其三是患者数，事件日志的不同患者号是 282,484，聚类参考表一是 281,929 行；其四是 G_ICD 第四列的列名，PhysioNet 页写 ICD_Code_Title，文档站写 ICD_strong_Title。前两处属于口径表述问题，第三处本来就不是同一个统计对象（不同取值数对表行数），第四处是同一字段的两个写法。处理办法是引用时写明出处，不要把两个数字混着用；涉及列名的，读实际表头确认。

Q5：它能不能直接用来训练机器学习模型？

官方的态度是明确的否定式表述：在这份数据上训练机器学习模型的可能性尚未被检验。官方为此准备了 M_CNM5 系列四张表，作用是"便于生成 CNM5 映射"，即让使用者自己去做事件与疾病之间的关联，而这件事官方没有替你做。此外官方提到，这些表配合 B_EventLog 的时间戳，可以适配时序分析模型的训练——注意措辞是"可以适配"，不是"已经验证"。所以现实的做法是：把它当作结构与语义都齐备的输入，建模与评测全部自己设计，并且不要期待在文献里找到可比基线。

术语表

术语	含义
CEKG	Clinical Event Knowledge Graph，临床事件知识图谱；面向多病共存患者的多实体事件数据框架
CNM	Constrained Node Mapping，约束节点映射；CEKG 中给不同标签节点建立关系的机制，本数据集分 CNM1—CNM5 五类
流程挖掘	Process mining；从事件日志中发现、监控与优化流程的一类方法
事件日志	Event log；每条记录含时间戳、活动与实体的数据表
多实体事件数据	Multi-entity event data；一条事件同时挂在多个实体上的数据形态
对象中心事件日志	Object-centric event log；多实体事件数据的同义说法，强调实体是具体对象
多维事件日志	Multi-dimensional event log；多实体事件数据的另一种说法
案例标识	Case notion；把事件归入同一条轨迹所依据的那个字段
活动	Activity；事件日志里的动作标签，本数据集共 95 类
活动实例	Activity instance；某次活动连同它当时的全部特征取值
活动域	Activity domain；活动的归类，本数据集共 7 个取值
多病共存	Multimorbidity；同一患者同时患多种慢性病
IDTR	Identifier-Based Time Range；按标识符组合记录时间戳上下界的辅助表
NDC	National Drug Code，国家药品编码；美国药品与包装标识
SNOMED-CT	Systematized Nomenclature of Medicine—Clinical Terms，系统化医学临床术语
RF2	SNOMED-CT 的发布格式；本数据集用其中的 Description、Relationship、TextDefinition 三个文件
OHDSI Athena	观察性健康数据科学与信息学协作组的词表系统；本数据集用它做 ICD 到 SNOMED-CT 的映射
GSN	药品通用序号；NDC 人工核查找时用到的资源之一
RxNorm	美国国立医学图书馆的临床药物标准词表
anchor age	锚定年龄；MIMIC-IV 中的患者年龄字段
SOFA	Sequential Organ Failure Assessment，序贯器官衰竭评分
SAPS II	Simplified Acute Physiology Score，简化急性生理评分
DUA	Data Use Agreement，数据使用协议；凭证制数据的法律前置条件
CITI	美国研究伦理与安全在线培训平台；此处要求完成 Data or Specimens Only Research 课程

附录 A：核心数字核对表

数字	出处
19（表数量，1 个模块）	官方 Data Description 段首句
121,577,735（事件数）	官方文档站 General Overview 与 EventLog 页
282,484（不同患者号）	官方文档站 EventLog 页
448,709（不同住院号）	官方文档站 EventLog 页
550,405（不同门诊号）	官方文档站 EventLog 页
999,112（temp_encounter_id 不同取值）	官方文档站 EventLog 页
1—238（住院次序取值范围）	官方文档站 EventLog 页
1—114（门诊次序取值范围）	官方文档站 EventLog 页
95（活动类别数与缩写数）	官方 Methods Step 3 Sub-step 5；文档站 General Overview
1,759（不同疾病数，基于高层 ICD）	官方文档站 General Overview；G_ICD 与 I_CNM1 记录数
1,760（方法段所述高层 ICD 码数）	官方 Methods Step 4 Sub-step 1
19K（方法段所述可比 ICD 码数）	官方 Methods Step 4 Sub-step 1
8（1,760 个 ICD 码中需人工映射到 SNOMED-CT 的个数）	官方 Methods Step 4 Sub-step 3
7,243,702（C_EntitiesAttributes 记录数）	官方文档站 Entities Attributes 页
5,133,925（D_EntitiesAttributeRel 记录数）	官方文档站 Entities Attribute Rel 页
395,077,510（E_ActivityAttributes 记录数）	官方文档站 Activity Attributes 页
7（F_ActivitiesDomain 记录数与活动域个数）	官方文档站 Activities Domain 页
9,302（H_SCT_Node 记录数）	官方文档站 SCT Node 页
18（SNOMED-CT 顶层概念数）	官方 Data Description 与文档站 SCT Node 页
138875005（SNOMED-CT 根概念 ID）	官方 Methods Step 6 与 Data Description
120,108,091（M_CNM5_Activity_Instance_ID 记录数）	官方文档站 CNM5 Activity Instance ID 页
281,929（N_ClusterReference1 记录数）	官方文档站 Cluster Reference 1 页
4,859,894（N_ClusterReference2 记录数）	官方文档站 Cluster Reference 2 页
5,732 → 7,376（NDC 码导出数与扩展后数）	官方 Methods Step 3 Sub-step 3
6,265 / 1,087 / 24（NDC 已核实 / 人工查 / 未核实）	官方 Methods Step 3 Sub-step 3
10（POE 表按 field_name 拆分出的表数）	官方 Methods Step 3 Sub-step 4
183（单个活动的最大特征数）	官方文档站活动清单
2008—2019（数据时间跨度）	官方 Background 段
2025 年 4 月 8 日（发布日）	官方页 Published 行
10.13026/qr9d-6t52（v1.0.0 DOI）	官方 Discovery 区块
10.13026/wqvp-h188（最新版本 DOI）	官方 Discovery 区块
666（项目浏览量）	官方 Project Views