JMDC — 日本最大民间可用理赔数据库 AI-Ready Wikipedia

2,000 万+ 日本受雇人群理赔+健检联接数据

来源 JMDC Inc. url: https://www.jmdc.co.jp/en/bigdata发布时间: 2026-09-12最后更新: 2026-09-25 阅读 46
JMDC — 日本最大民间可用理赔数据库 AI-Ready Wikipedia

信息速览

数据集名称JMDC — 日本最大民间可用理赔数据库 AI-Ready Wikipedia
数据类型累计 2,000 万+ 被保险人,2005 年起月度更新,ICD-10 + WHO ATC 编码,商业许可付费使用,理赔+健检联接
规模累计被保险人 2,000 万+(截至 2026-05 官方口径)
接入方式JMDC Inc. url: https://www.jmdc.co.jp/en/bigdata
AI 就绪度

数据集封面

JMDC Claims Database — 日本最大民间可用理赔数据库 AI-Ready Wikipedia


INFOBOX

字段 内容
数据集名称 JMDC Claims Database
英文全称 JMDC Claims Database(Japan Medical Data Center Claims Database)
别名/简称 JMDC;Japan Medical Data Center;JMDC 健保组合库
疾病分类(ICD-11) 不限定单病种,覆盖 ICD-10 全部章节(对应 ICD-11 全谱系),主流应用集中于代谢、心血管与肿瘤领域
SNOMED CT 未提供原生映射(诊断以 ICD-10 为主键,可经术语服务映射至 SNOMED CT)
数据模态 门诊/住院/DPC/调剂/牙科理赔 + 特定健康体检 + 被保险人台账 + 医疗机构属性
AI 任务类型 疾病表型算法定义、结局预测、药物安全信号检测、发生率/患病率估计、医疗费用建模
样本总数 累计母集团 2,000 万+ 人(截至 2026-05 官方口径)
数据格式 关系型数据库表(合同制交付;2025-09 起提供 OMOP CDM 标准格式)
许可证 商业使用许可合同(无公开开源许可证)
访问级别 商业许可(付费签约后使用)
DUO 标签 不适用(商业合同许可模式,未登记 DUO 结构化标签)
语言 文档日语/英语;诊断与药品为标准化编码(ICD-10、WHO ATC 等)
首发日期 2005-01(最早理赔数据;健检 2008-04、牙科 2009-12 起)
最后更新 月度滚动追加,入库滞后约 5 个月(截至 2026-08 持续更新)
发布机构 JMDC Inc.(东京都港区,东证上市,代码 4483)
官方主页 https://www.jmdc.co.jp/en/bigdata
下载地址 合同制交付,无公开下载页(经官方询价签约后交付)
DOI 10.1002/jgf2.422(数据资源描述论文)
引用次数 数据库支撑论文 1,000+ 篇、学会发表 470+ 件(JMDC 官网,截至 2026-08)
AI 就绪度评分 ⭐⭐⭐(3/5)— 数据经辞书标准化、master 完备,研究无需重预处理;但无官方 AI 任务划分与预处理脚本,交付为专有关系表格式需自行 ETL,扣分明显
页面状态 published

§0 E-E-A-T 信任声明与免责声明

医学审核者:千方病案医学编辑部交叉审核:§2 医学背景(ICD-10 与 ICD-11/SNOMED CT 映射、理赔编码体系与临床任务定义、验证金标准描述)、§7 偏倚分析。

数据工程审核者:千方病案医学编辑部交叉审核:§4 DAIMS 数据字典(八表结构、主键与 flag 体系)、§5 数据划分策略、§6 预处理 Pipeline 和坑点。

审核日期:2026-09-05

审核方式:交叉审核

利益冲突声明:千方病案医数集与 JMDC Inc.、日本厚生劳动省无任何商业利益关联。本页面不销售 JMDC Claims Database 数据本身,仅提供 AI 就绪指南与学术信息服务。编辑者未接受 JMDC 的任何形式资助。

医疗免责声明:本页面提供的医学信息仅供研究和教育目的,不构成医疗建议、诊断或治疗方案。数据集的医学描述基于公开发表的文献,未经逐一临床验证。任何基于该数据集训练的 AI 模型在应用于临床决策前,必须经过独立的临床验证和监管审批。

技术免责声明:本页面的代码示例、预处理建议和基准性能数据基于公开资料整理,不保证在特定环境下的准确性和适用性。使用者应自行验证代码安全性和数据预处理流程的正确性。千方病案医数集不对因使用本页面信息而导致的任何直接或间接损失承担责任。

数据使用合规:使用本页面描述的数据集前,请务必阅读并遵守数据集原始许可协议。JMDC Claims Database 为付费商业许可数据,须与 JMDC Inc. 签订使用合同后方可获取,禁止二次转售或超出合同范围使用。DUO 标签仅供参考,具体使用限制以数据集官方协议为准。


§1 数据集概览

§1.0 30 秒速览

这是什么? JMDC Claims Database 是日本上市公司 JMDC Inc. 运营的商业健康保险理赔数据库。日本的大企业雇员普遍加入"健康保险组合"(行业/企业主办的社会保险),组合每月向医疗机构结算医疗费时会产生理赔单据(レセプト/Rezept)。JMDC 与全国 60 余家组合签约,把这些单据连同被保险人台账和年度特定健康体检结果,按匿名个人 ID 串联起来,形成一部"谁、在哪年哪月、看过什么病、开了什么药、花了多少医疗费、体检指标如何"的纵向流水账。截至 2026 年 5 月,其覆盖的签约组合母集团已达 2,076 万人,累计数据超过 2,000 万人。

为什么重要? 日本虽是全球医疗数据最丰富的国家之一,但官方的国民数据库(NDB)只对学术申请开放、无死亡信息且审批周期长。JMDC 是民间可用的最大规模流行病学理赔数据库:制药企业、保险公司、政府机构和 50 余所大学都在使用,已支撑 1,000 余篇论文。对于 AI 团队,它意味着一个 2,000 万级、个体可纵向追踪、诊断-药品-费用-体检四维联接的"真实世界数据"基础设施。

我能用它做什么? 你可以基于它做疾病表型算法定义与验证、药物上市后安全性与利用研究、患病率/发生率估计、基于理赔序列的疾病发生预测模型、体检指标暴露-结局研究等。它不适合研究 75 岁以上老年人(无数据)、需要检验值或出院转归的严重度分析(健保组合库无此类字段),且必须付费签约才能获取。

§1.1 摘要

JMDC Inc.(前称 Japan Medical Data Center,2002 年成立,2019 年 12 月在东京证券交易所上市)自 2005 年 1 月起,以月度频率从签约健康保险组合收集住院、门诊(外来)、调剂(调剤)理赔,牙科理赔自 2009 年 12 月、特定健康体检结果自 2008 年 4 月起入库。数据构成包括被保险人台账(全数、含未就诊者)、理赔汇总与四级明细(伤病/药品/诊疗行为/治疗材料)、医疗机构属性;诊断统一映射为 ICD-10,药品同时提供 WHO ATC 与 EphMRA ATC 分类及 MHLW 药品码,全部字段经 JMDC 独立医疗辞书自动标准化,研究者"几乎无需数据预处理"即可开始分析(Nagai et al., 2021)。被保险人以不可逆匿名化的个人 ID 纵向追踪,即使跨医院、跨机构就诊也可全量归集;家族识别码还支持母婴联接。规模上,2020 年 6 月为约 980 万人,2021 年 9 月约 1,300 万人,2005-2022 年间累计覆盖 1,400 万+ 员工及家属,签约组合母集团 2026 年 5 月达 2,076 万人,约占日本人口的两成。2025 年 9 月起,JMDC 与 Yuimedi 合作将数据转换为国际标准 OMOP CDM 格式提供。

§1.2 战略价值

维度一:日本真实世界数据的民间入口。 日本实行全民医保,理赔单据覆盖率接近全覆盖,但绝大多数公家数据库(NDB、DPC 研究班数据)不对企业或国际研究者开放或仅限学术申请。JMDC 是唯一进入"世界级"量级的民间理赔库:累计母集团 2,000 万+、时间跨度 20 年以上、月度更新。对于需要在日本开展药物流行病学、市场准入、上市后安全性监测(PMDA 监管提交场景)的组织,它几乎是不二之选。

维度二:AI 可纵向建模的 EHR 替代面。 与影像队列不同,理赔数据天然是"患者轴时序数据":个人 ID + 诊疗年月 + 编码事件流。这使得 JMDC 天然适配序列模型(如 Transformer/GRU)做疾病发生预测、医疗费用预测、不良事件信号检测。体检联接还额外提供了 BMI、血压、HbA1c 等连续暴露变量,可构建"体检暴露 → 未来理赔结局"的预测任务,这是多数理赔库不具备的。OMOP CDM 格式化后,与 OHDSI 全球网络工具链(Hades、PLP 等)可直接衔接。

维度三:经过验证的监管级证据链。 该库已有死亡终点验证(敏感度/特异度/PPV 约 95%)、糖尿病表型算法系统验证(17 种算法的 Kappa/PPV 定量比较)、母婴联接适用性评估(Duke-Margolis fit-for-purpose 框架)等公开方法学证据,这对需要向监管机构(PMDA、FDA)提交真实世界证据的团队极具价值。

§1.3 同类数据集横向对比

数据集 规模 模态 访问方式 与 JMDC 的差异化
JMDC Claims Database 累计 2,000 万+ 人(截至 2026-05) 理赔+健检+台账,个体 ID 纵向 商业许可付费 受雇人群 0-74 岁;跨机构可追踪;含家族识别
日本 NDB(厚生劳动省) 约 1.26 亿人、年 19 亿份单据 全国理赔+特定健检 学术申请制(另有免费 NDB Open Data 聚合表) 覆盖全年龄与全民;无死亡信息;不能与外部库联接
MDV EBM Provider 实际患者 3,000 万+(含重复计数) DPC 医院理赔+部分检验值 商业许可付费 急性期住院视角、含老年人;但跨院无法追踪个体
Medi-Scope(JMIRI) 约 666 万人(2018) 理赔+健检,个体 ID 商业许可付费 项目更全;规模与生态弱于 JMDC
MID-NET(PMDA) 约 400 万人(2018) 23 家医院电子病历+理赔 官方申请制 病历级细节(检验值);仅限药物安全性评估用途
MIMIC-III/IV(美国) 约 4 万/30 万患者 ICU 电子病历+波形 免费凭证化申请 单中心重症深度数据;与理赔库人群完全互补

§1.4 版本时间轴

时间 里程碑 来源
2005-01 住院/门诊/调剂理赔开始入库 Nagai et al., 2021
2008-04 特定健康体检结果开始联接入库 Nagai et al., 2021
2009-12 牙科理赔开始入库 Nagai et al., 2021
2019-12-16 JMDC Inc. 于东京证券交易所上市(代码 4483) Stockopedia
2020-06 可访问被保险人约 980 万 Nagai et al., 2021
2021-09 累计约 1,300 万人 ACE 综述 2022
2022 2005-2022 年累计覆盖 1,400 万+ 员工及家属 PMID 37808588
2025-09-30 与 Yuimedi 合作启动 OMOP CDM 格式化交付 JMDC 官方新闻
2026-05 签约组合母集团 2,076 万人;官网称累计超 2,000 万人 FY2026/3 决算资料

§1.5 典型应用场景

  1. 药物流行病学与上市后安全:利用处方码(WHO ATC)+ 出院转归与死亡 flag 构建新用药者队列,做目标试验模拟(target trial emulation)式的安全性比较。日本药企与全球药企的日本分公司是该场景最大的使用群体,PMDA 监管提交中已有成熟实践。
  2. 患病率/发生率全国估计:全数调查型台账支持分性别、分年龄组的发生率与特定治疗率计算,并可按性别-年龄结构放大至全国。罕见病领域尤其有价值——组合库 2,000 万级母集团可让年发生率极低的病种也具备可估计样本。
  3. 疾病表型算法定义与验证:结合 ICD-10 码、疑似 flag 与药品码,开发并量化验证可复用的表型算法(如糖尿病 17 算法验证范式)。这类方法学产出本身即可发表,并构成后续所有研究的基础设施。
  4. 体检暴露-结局预测建模:以特定健检(BMI、HbA1c、血压、吸烟)为暴露、未来理赔为结局,训练纵向预测模型,适用于健康管理与保险精算场景。健保组合自身的健康事业(健康指导效果评价)也大量使用该设计。
  5. 母婴联接药物安全研究:用家族识别码联接孕妇-婴儿对,研究宫内药物暴露与先天畸形/早产的关联(需注意孕周效度限制)。该场景已被 Amgen/Emory 团队以 Duke-Margolis 框架完成系统适用性评估,是国际药企使用该库的前沿方向。

§2 医学背景

§2.0 制度背景:日本医保体系与理赔单据

理解 JMDC 必须先理解日本全民医保的制度结构。日本 1961 年实现全民医保,医疗费用按"诊疗报酬"点数制度结算;不同身份对应不同保险者,理赔单据(レセプト/Rezept)由医疗机构按月向保险者请求支付:

保险制度 覆盖人群 与 JMDC 的关系
健康保险组合(组合保险) 大企业雇员及其被扶养家属(<75 岁) JMDC 数据源:60 余家组合匿名化后提供数据
协会けんぽ(全国健康保险协会) 中小企业雇员 不在 JMDC 数据源内
国民健康保险 个体经营、无业者 不在 JMDC 数据源内
后期高龄者医疗制度 75 岁以上 制度上与组合保险互斥,故该库无 ≥75 岁数据

理赔单据按请求类型分为医学诊疗(入院/外来)、调剂(药店处方配药)、牙科三类,每份单据包含伤病名、诊疗行为、药品、材料四个明细块及费用点数。组合保险的关键特征是"保险者视角":同一雇员在任何医疗机构发生的全部费用都向其所属组合请求,因此以组合为单位归集数据即可实现跨医院的个人级完整追踪——这是 JMDC 区别于医院级数据库(MDV 等)的制度根源。组合还有法定义务为 40-74 岁加入者实施特定健康检查,这解释了健检数据的存在与口径。

§2.1 疾病编码映射表(ICD-11)

JMDC 诊断原生编码为 ICD-10(保险请求用病名码)。下表列出该库主流应用病域的 ICD-11 对应关系:

标签 ICD-11 编码 中文名称 该库中的研究地位
Type 2 diabetes 5A11 2 型糖尿病 表型算法验证最充分的病种(17 算法定量比较)
Essential hypertension BA00 原发性高血压 特定健检(40-74 岁)核心筛查目标
Dyslipidaemias 5C80 血脂代谢异常 特定健检血脂五项联接分析
Acute myocardial infarction BA41 急性心肌梗死 理赔内死亡终点验证场景
Cerebral infarction 8B11 脑梗死 OHDSI 跨库预测模型应用场景
Malignant neoplasm of colon 2B91 结肠恶性肿瘤 保险请求病名按治疗目的编码的典型领域
Malignant neoplasm of stomach 2B72 胃恶性肿瘤 日本高发瘤种,发生率研究常用
Depressive episode 6A70 抑郁发作 受雇人群心理健康的代表性病种
Asthma CA23 哮喘 慢性气道疾病纵向用药分析

§2.1b SNOMED CT 映射表

JMDC 未提供官方 SNOMED CT 映射,下表为常用研究概念经标准术语服务(如 OMOP 通用映射)转换后的参考对应:

标签 ICD-11 SNOMED CT 术语名称
2 型糖尿病 5A11 44054006 Diabetes mellitus type 2
原发性高血压 BA00 38341003 Hypertensive disorder, systemic arterial
高脂血症 5C80 55822004 Hyperlipidemia
急性心肌梗死 BA41 22298006 Myocardial infarction
脑梗死 8B11 230690007 Cerebral infarction
结肠恶性肿瘤 2B91 363406005 Malignant tumor of colon
胃恶性肿瘤 2B72 93762005 Malignant tumor of stomach
抑郁发作 6A70 370143000 Major depressive disorder, single episode
哮喘 CA23 195967001 Asthma

§2.2 疾病背景与流行病学

JMDC 的人群构成决定了其流行病学重心:大企业雇员及其被扶养家属(年龄 0-74 岁,≥75 岁因制度原因完全缺失)。这一人群的疾病谱以生活方式相关疾病(代谢综合征、2 型糖尿病、高血压、血脂异常)、壮年及工作年龄段的恶性肿瘤、精神心理疾病与肌肉骨骼疾病为主。日本自 2008 年起依法对 40-74 岁被保险者实施"特定健康检查",目标即预防生活方式相关疾病,这也是 JMDC 健检数据联接率较高(近半数个体可联接特定健检)的制度基础。需强调:官方资源论文明确指出,该库"疾病状态与检验结果无法确认"(组合库无检验值),且对老年人群覆盖不足,因此任何流行病学估计都应视为"0-74 岁受雇参保人群"口径,而非全国人群口径;如需全国口径,官方建议按性别-年龄组结构放大并与 NDB 公开统计对比校准(Nagai et al., 2021 提供了完整的放大对比方法)。

§2.3 临床任务定义

任务类型 定义 该库支持方式
筛查(Screening) 从健康人群中识别高风险个体 特定健检指标(BMI/血压/HbA1c/血脂)作为预测因子
诊断(Diagnosis) 确定个体是否患目标疾病 ICD-10 码 + 疑似 flag 排除 + 药品码佐证的表型算法
分级(Severity) 疾病严重度分层 组合库受限(无检验值/无出院转归);可用医疗资源占用 flag 近似
预后(Prognosis) 预测未来结局/费用/再入院 台账死亡 flag、住院日期、点数(费用)时间序列

§2.4 患者人群特征表

维度 描述
来源 全国 60 余家健康保险组合(名单与地理信息不公开)
时间范围 2005-01 至今,月度追加(入库滞后约 5 个月)
年龄 0-74 岁;≥75 岁无数据;>65 岁极少
性别 男女均覆盖,男性占比偏高(大企业雇员结构)
种族 未单独记录(日本受雇参保人群为主)
就医类型 门诊+住院+调剂+牙科全量理赔;跨医疗机构可归集至同一人

人群结构的两点解读:其一,"被扶养家属"纳入使得婴幼儿与老年配偶(<75 岁)也有覆盖,儿科与妇产科研究可行,但家属的理赔归集依赖于其以同一组合为保险者,随雇佣变动容易脱退;其二,男性占比偏高源于大企业雇员结构,做性别特定疾病研究时需注意分母口径与性别分层的统计效力。

§2.5 临床价值

对临床研究者而言,JMDC 的核心价值在于"全数、纵向、可追踪"三点的组合:台账覆盖未就诊的健康人,使患病率与发生率有真实分母;个人 ID 使同一人在多家医院的诊疗完整归集,避免医院级数据库的重复计数与断链;死亡记录与住院日期使硬终点可定义。对健康保险组合自身,该库支撑 PDCA 循环(医疗费分析、高风险人群检出);对社会,它以约两成人口的受雇人群视角补充了以老年人为主的公立数据生态。2025 年起的 OMOP CDM 化进一步使其具备进入国际多库联合分析(OHDSI 网络)的能力,填补了"日本数据在国际研究网络中存在感有限"的缺口(JMDC 官方新闻,2025-09-30)。

§2.6 金标准与验证研究

验证对象 划分 标注方式 标注者/参照 性质
理赔内死亡终点 65-74 岁住院死亡队列 与住院死亡记录对照 敏感度/特异度/PPV ≈95% 官方引述的验证研究汇总(Nagai et al., 2021 引文 28)
糖尿病表型算法 特定健检血检为参照标准 17 种算法交叉定量 敏感度/特异度/PPV/Kappa Nishioka et al., J Diabetes Investig 2022;算法 9/12 平衡最优,算法 16 敏感度 94.0%
母婴联接队列 2005-01 至 2022-03 孕产记录 Duke-Margolis fit-for-purpose 评估 385,295 对母婴、57% 孕期连续在保 Barberio et al., Clinical Epidemiology;早产 3.6% 低于人群预期 5.6%,孕周效度受限

§3 数据集规格

§3.0 版本抉择矩阵

JMDC 对外提供多个产品形态,选型取决于你的需求与预算:

你的需求 推荐版本 大小 理由
学术药物流行病学研究(自定义队列+生存分析) Raw Data 全库 License 或领域别 License 未公开(关系库交付) 需要患者级原始表做复杂联接与自助统计
制药公司标准化流行病学查询 JMDC Data Mart 全包 未公开 内置标准化分析环境,开箱即用
快速发生率/患病率考察 JMDC Data Mart Light 未公开 轻量 Web 工具,无需本地建模环境
销售与市场分析(药企 S&M 部门) Data Mart P-Market PLUS 未公开 面向市场交易额分析的定制口径
上市后安全性监测(药物警戒) Data Mart Pharmacovigilance 包 未公开 信号检测工作流内置
国际多库联合研究 / OHDSI 工具链 OMOP CDM 格式化交付(2025-09 起与 Yuimedi 合作) 未公开 标准 CDM+术语映射,兼容 Hades/PLP
需要老年人、检验值、出院转归的住院研究 JMDC 医疗机构库(另一个库,非本条目主体) 2019-10 约 940 万人、218 机构 含 DPC 调查表、JLAC10 检验值与 65+ 人群,2014-04 起

§3.1 模态详情

模态 内容 关键字段示例
理赔汇总 每人每月每类单据的医疗费汇总 诊疗年月、单据类型(入院/外来/DPC/调剂)、实际医疗天数、入院/出院日期、点数(费用)、DPC 码
伤病明细 住院与门诊的伤病诊断 伤病开始日期、ICD-10 码、伤病码、主伤病 flag、占用资源最多 flag、疑似 flag、转归分类码
药品明细 处方与调剂 处方日、调剂日、EphMRA ATC、WHO ATC、MHLW 药品码、电子理赔药品码、日剂量、给药天数、用量、后发品 flag、按需 flag、剂型码
诊疗行为明细 注射、手术、检查等 行为日期、行为码、次数、点数
治疗材料明细 人工关节、支架等 治疗日期、材料码、次数、点数
特定健康体检 法定 40-74 岁健检结果 BMI、腹围、SBP/DBP、TG/HDL/LDL、AST/ALT/γ-GTP、FBS/HbA1c、尿酸、肌酐、心电图所见、眼底分级(Keith-Wagener/Scheie)、吸烟、饮酒、运动与饮食习惯、既往史
台账 被保险人全数属性 出生年月、性别码、在职/家属码、首末可观测月、中途脱退 flag、死亡 flag
医疗机构 就诊机构属性 床数区间、管理主体码、癌症诊疗据点医院 flag

§3.2 规模按时间点子集表

时间点 可访问被保险人数(含历史退出者) 来源
2018-06 约 560 万 J Pharm Health Care Sci 2021
2020-06 约 980 万 Nagai et al., 2021
2021-09 约 1,300 万(累计) ACE 综述 2022
2022 2005-2022 累计 1,400 万+ 员工及家属 PMID 37808588
2026-05 签约组合母集团 2,076 万人;累计超 2,000 万 FY2026/3 决算;官网

§3.3 数据格式表

形态 格式 说明
Raw Data License 关系型数据库表/CSV 全库或领域别交付,需自有分析环境
Data Mart 系列 云端数据库 + Web 工具 全包/Light/P-Market PLUS/药物警戒
OMOP CDM(2025 起) OMOP CDM 标准表 与 Yuimedi 合作转换,面向国际研究

§3.4 存储大小

JMDC 未公开披露整库字节规模;交付形态为关系型数据库表与云端 Data Mart,实际存储取决于合同范围(全库 vs 领域别)与时间窗。本页不做无来源的估计。作为容量规划参考:需纳入分析的人-月面板行数量级约为"可访问人数 × 在保月数",全库规模下以 DuckDB/Spark 分区管理为宜(见 §6.8)。

§3.5 标注方式

本数据集无人工监督标注。所有"标签"均为保险业务流程的自动产物:诊断码由医疗机构按保险请求目的编码,经审查支付机构核对后入库,再由 JMDC 医疗辞书自动标准化至 ICD-10/ATC。对 AI 任务而言,结局标签需研究者用表型算法定义(详见 §6.3),这既是挑战也是该库方法学研究的活跃领域。

§3.6 标注者资质与一致性

编码质量由双重机制保障:其一,日本理赔单据需通过审查支付机构(社会保険診療報酬支払基金)的机械化审查(外部检查),格式错误与明显异常在源头上被拦截;其二,JMDC 入库时独立执行重复检查、月度数据量异动检查、格式与正常范围校验(如未来日期),发现错误后转换为正则或规范码(Nagai et al., 2020)。缺失值保留原样,但因上述外部审查,缺失相对较少。

§3.7 采集周期

月度采集;诊疗发生后约 5 个月完成入库。这意味着任何时点的"最新可用月份"均滞后于现实约半年,做实时监测类应用时必须计入该滞后(详见坑点 4)。

§3.8 地域覆盖

覆盖日本全国:组合加入者分布于其雇主企业在日本全国的所有分支机构,但按匿名化政策,组合名称与地理信息均不对外提供(Nagai et al., 2021)。

§3.9 设备规格

不适用。本数据集无医学影像、生理信号或设备元数据;健检数值来自法定体检项目(测量设备未入库)。

§3.10 深度溯源链

医疗机构开具理赔单据 → 提交健康保险组合 → 组合向审查支付机构请求审查与支付 → 组合将(脱敏后的)理赔与台账数据月度交付 JMDC → JMDC 执行质量校验与医疗辞书标准化 → 按合同交付研究/企业用户。健检数据由组合按《工业安全与卫生法》法定体检流程采集后随台账交付。全程符合 APPI(个人信息保护法)第 2 条第 9 项的匿名化处理要求。


§4 数据结构

§4.0 目录树

以下为依据资源描述论文表 1(Nagai et al., 2021)整理的规范化目录组织示例,用于规划 ETL 后的本地数据层;实际合同交付的文件切分与命名以 JMDC 提供的规格书为准:

jmdc_claims/                                # ETL 后推荐组织(依据官方表结构整理)
├── master/                                 # JMDC 独立医疗辞书标准化主数据
│   ├── master_disease.csv                  # 伤病 master:ICD-10 / 伤病码 / 病名
│   ├── master_drug.csv                     # 药品 master:WHO ATC / EphMRA ATC / MHLW 码 / 电子理赔药品码
│   ├── master_activity.csv                 # 诊疗行为 master:行为码 / 点数
│   ├── master_material.csv                 # 治疗材料 master
│   └── master_institution.csv              # 医疗机构 master:床数区间 / 管理主体 / 癌症据点 flag
├── population/
│   └── person.csv                          # 台账:出生年月 / 性别码 / 在职·家属码 / 首末可观测月 / 脱退 flag / 死亡 flag
├── claims/
│   ├── claim_summary.csv                   # 理赔汇总:诊疗年月 / 单据类型 / 实际天数 / 入院·出院日期 / 点数 / DPC 码
│   ├── claim_disease.csv                   # 伤病明细:ICD-10 / 伤病码 / 主伤病 flag / 疑似 flag / 转归码
│   ├── claim_drug.csv                      # 药品明细:处方日 / 调剂日 / ATC / 日剂量 / 给药天数 / 后发品 flag
│   ├── claim_activity.csv                  # 诊疗行为明细:行为码 / 次数 / 点数
│   └── claim_material.csv                  # 材料明细:材料码 / 次数 / 点数
├── checkup/
│   └── checkup_result.csv                  # 健检:BMI / 血压 / 血脂 / HbA1c / 肝功 / 眼底 / 生活习惯问卷
└── institution/
    └── medical_institution.csv             # 就诊机构属性

§4.1 DAIMS 字段字典(核心字段)

字段名 类型 说明 示例值 AI 用途 观测误差 信息性缺失编码 取值范围
person_id 文本 不可逆匿名化个人 ID ANON0001… 个体追踪主键 无 无(台账全数覆盖) 组合内唯一
birth_ym 日期 出生年月(不含日) 1978-03 年龄分层、协变量 月粒度截断 无 合同期内有效
gender_code 整数 性别码 1 分层/公平性分析 无 无 1/2
employee_flag 整数 在职本人或被扶养家属 1 区分雇员/家属人群 无 无 0/1
first_month / last_month 日期 首/末可观测月 2005-01 / 2021-12 观察期与删失定义 无 无 2005-01 起
withdrawal_flag 整数 中途脱退 flag(含进行中) 1 区分删失类型 无 无 0/1
death_flag 整数 台账死亡 flag(验证 PPV≈95%) 0 硬终点 死后滞后期 无 0/1
icd10_code 文本 ICD-10 病名码 E11 表型算法输入 保险目的编码偏倚 空值=该月无伤病 ICD-10 全码域
suspected_flag 整数 疑似伤病 flag 1 必须排除的假阳性源 无 无 0/1
main_disease_flag 整数 主伤病/占用资源最多 flag 1 结局归属判定 无 无 0/1
who_atc_code 文本 WHO ATC 药品分类码 A10BJ 暴露定义、药物安全 仿制药合并计数 空值=非药品单据 ATC 全码域
days_of_administration 整数 单次处方给药天数 30 暴露窗口估算 无 无 正整数
generic_flag 整数 后发(仿制)药品 flag 0 用药模式分析 无 无 0/1
points 整数 医疗费点数(1 点=10 日元) 125,400 费用预测、资源强度 年度点数改定影响 无 非负整数
hba1c 浮点 健检糖化血红蛋白(NGSP) 6.8 暴露/前期指标 检体采集时点差异 空值=未受检 体检报告范围

§4.2 标签分布

数据集无预设标签。结局分布由研究者按表型算法产生,分布形态强依赖算法定义(例如仅用病名码与加用药品码会得到显著不同的阳性集合,Nishioka et al., 2022 已定量演示)。建议在报告模型结果时,同时报告表型算法的敏感度/特异度/PPV 证据链,而非只报告模型 AUROC。

以下代码演示"同一病种、不同算法定义下的阳性集合差异"的自检流程,应在任何建模前完成:

def phenotyping_comparison(person, disease, drug,
                           icd_prefix: str = "E11", atc_prefix: str = "A10"):
    """三种表型口径的人数对比:仅病名 / 仅药品 / 病名+药品并集。
    输出差异规模可帮助判断目标疾病的'报销驱动编码'程度。"""
    dx = set(disease[disease["icd10_code"].astype(str).str.startswith(icd_prefix)
                     & (disease["suspected_flag"] == 0)]["person_id"])
    rx = set(drug[drug["who_atc_code"].astype(str).str.startswith(atc_prefix)]["person_id"])
    n_total = person["person_id"].nunique()
    report = {
        "仅病名(含报销驱动假阳性)": len(dx),
        "仅药品(漏掉未治疗者)": len(rx),
        "并集(算法 9 风格)": len(dx | rx),
        "交集(算法 12 风格,最强 PPV)": len(dx & rx),
        "台账分母": n_total,
    }
    for k, v in report.items():
        print(f"{k}: {v:,} 人({v / n_total:.2%})")
    return report

# 经验规则:'仅病名'远大于'交集'时,说明大量记录是检查驱动的待排编码,
# 直接用病名码当标签会把报销行为学成标签(坑点 1/5 的量化体检)。

§4.3 关键统计

统计项 数值 来源
签约健康保险组合数 60 余家 OHE Consulting Report 2019
覆盖日本人口比例 约 7.6%(2020-06) Sleep Medicine 2024 论文引述
特定健检联接率 近半数个体可联接特定健检 MHLW 研究班综述(PMC9712845)
数据入库滞后 约 5 个月 Nagai et al., 2021
数据库支撑论文 1,000+ 篇、学会发表 470+ 件 JMDC 官网(截至 2026-08)

§4.4 数据层级

被保险人(person_id,台账全数)
└── 月(claim_month,2005-01 起逐月)
    └── 理赔单据(claim_summary,按入院/外来/DPC/调剂/牙科分类)
        ├── 伤病明细(claim_disease,每伤病一条)
        ├── 药品明细(claim_drug,每药品一条)
        ├── 诊疗行为明细(claim_activity,每行为一条)
        └── 治疗材料明细(claim_material,每材料一条)
(旁路联接)年度特定健康体检(checkup_result,按 person_id + 健检日期)

§4.5 缺失值与信息性缺失

情形 机制 对 AI 的影响与处理建议
检验值整体缺失 组合库设计上不含临床检验值 不可用健检外的检验变量;严重度调整改用资源占用 flag 或药品强度近似
健检字段空值 未参加当年度特定健检 空值非随机(健康意识强的人更常体检),需做参检偏倚处理
月份记录缺失 脱退(退职/转出组合)后不再产生记录 非随机删失:退职常与健康状况相关,需用 first/last_month 显式建模观察窗
出生日期仅到月 匿名化截断 精确年龄=月份差近似;婴幼儿月龄分析受限
出院转归缺失 组合库无出院摘要 住院结局仅能用死亡 flag/再入院代理

§5 划分与使用建议

§5.1 官方划分

JMDC 是真实世界数据源,官方不提供任何 AI 训练/验证/测试划分。官方提供的"划分"是研究设计层面的:以台账定义目标人群分母,以首末可观测月定义随访窗,以入退保事件定义风险期。

§5.2 社区惯例划分

论文中的通行做法:以 index date(如首次处方/首次诊断)为锚,要求 index 前至少 365 天连续在保(洗脱期/基线期),index 后定义暴露窗与结局窗;训练/验证/测试按 person_id 随机分层,或按时间前后切分以模拟前瞻部署(推荐后者,见 §5.3)。

§5.3 泄漏风险(重点)

  1. 同人多月记录泄漏:同一患者跨月的理赔高度相关,按记录行随机切分会造成患者级信息泄漏,必须按 person_id 分组切分。
  2. 家族泄漏:家族识别码意味着同一家族成员共享保险计划与就医环境,极端情况下应按家族聚类评估,避免家族级泄漏高估性能。
  3. 时间泄漏:index 前信息(包括 index 当月单据内的转归性记录)进入特征会造成标签泄漏;理赔单据内费用、点数与诊断同月发生,特征工程时必须把"同月信息"视为不可自动使用的前视窗口。
  4. 发布滞后造成的隐性前视:入库滞后约 5 个月,若按日历月切分训练/测试,测试月的数据在现实中尚未完整产生,会高估模型可部署性能。

这四类泄漏的共性是"信息在时间上不可前视",而理赔数据因汇总单据与明细同表、费用与诊断同月,泄漏面比影像数据更大。一个实用的自检:任何进入模型的特征,追问"如果我在 index 日当天站在床边,我能知道这个值吗",答案是否则必须移到特征窗之外。

§5.4 交叉验证建议

优先使用前向链式时间切分(expanding window)+ person_id 分组;报告跨时间窗的 AUROC 漂移而非单点性能。若做生存分析,采用以入保时间为时间尺度的 Cox 模型并处理 immortal time bias(从入保到首次暴露的人时不能计入暴露组)。

§5.5 外部验证建议

与 NDB 放大统计、DPC 数据或 MDV 数据做队列特征比对(Nagai et al., 2021 已提供官方放大对比框架);国际研究可将 JMDC 作为日本区域库接入 OHDSI 网络做跨库 PLP 外部验证;任何泛化性声明都应单独评估老年段(几乎无数据支撑)。

§5.6 推荐切分方案示例

以"2005-2026 年数据、部署目标是滚动预测"为例的时间外推切分(注意每个月份边界之间预留 5 个月入库滞后真空带):

切分 时间窗 角色 说明
训练窗 2005-01 至 2019-12 模型拟合 覆盖多个诊疗报酬改定周期
真空带 2020-01 至 2020-05 — 模拟入库滞后导致的现实不可用期
验证窗 2020-06 至 2022-12 超参与早停 覆盖 COVID-19 冲击段,检验鲁棒性
真空带 2023-01 至 2023-05 — 同上
测试窗 2023-06 起 最终报告 报告时须扣除末端未完整月份

三个注意事项:①所有窗内切分必须按 person_id(必要时按家族 ID)分组;②测试窗跨诊疗报酬改定年(如 2024-04)时,报告改定前后分段性能;③随机切分结果只能作为附录对照,不得作为主结果。


§6 AI 就绪指南

§6.0 云端快速启动

JMDC 无公开下载渠道,不适用公共云沙箱一键运行。签约用户通常在本地或私有云(AWS/GCP 日本区域)环境中接收交付。下述代码假设你已通过合同获得导出的 CSV 数据层。

推荐以 DuckDB 作为轻量分析层——理赔数据是典型的"窄表 + 大行数"结构,数据库端聚合远优于 pandas 全表加载:

# 环境准备(私有云/本地,均可离线完成)
pip install duckdb pandas pyarrow torch scikit-learn

# 建议目录权限:交付数据仅限合同授权人员访问
# jmdc_claims/ 下所有 CSV 统一 UTF-8,编码列保持文本类型读取
import duckdb

# 直接对 CSV 目录建库外查询,避免一次性载入内存
con = duckdb.connect("jmdc_analytics.duckdb")
con.execute("""
    CREATE TABLE claim_disease AS
    SELECT * FROM read_csv_auto('jmdc_claims/claims/claim_disease*.csv',
                                all_varchar=false)
""")
n = con.execute("SELECT COUNT(DISTINCT person_id) FROM claim_disease").fetchone()[0]
print(f"有伤病记录的人数: {n:,}")

§6.1 快速上手

# ============================================================
# 目录结构预期(见 §4.0):
#   jmdc_claims/
#     ├── population/person.csv
#     ├── claims/claim_summary.csv
#     ├── claims/claim_disease.csv
#     ├── claims/claim_drug.csv
#     └── checkup/checkup_result.csv
# data_root 与上述目录的拼接关系:data_root / 子目录 / 表名.csv
# 最小可用子集:person.csv + claim_disease.csv + claim_drug.csv
#   (足以完成"糖尿病表型算法"这一最经典任务)
# ============================================================
import pandas as pd

data_root = "jmdc_claims"

person = pd.read_csv(f"{data_root}/population/person.csv",
                     dtype={"person_id": str})
disease = pd.read_csv(f"{data_root}/claims/claim_disease.csv",
                      dtype={"person_id": str, "icd10_code": str})
drug = pd.read_csv(f"{data_root}/claims/claim_drug.csv",
                   dtype={"person_id": str, "who_atc_code": str})

# 台账口径:先算分母(全数、含未就诊者),这是 JMDC 区别于医院库的第一原则
n_denominator = person["person_id"].nunique()
print(f"台账总人数(分母): {n_denominator:,}")

§6.2 数据获取

步骤 内容 说明
1. 需求定义 明确病域/时间窗/所需表 决定选择全库 License 还是领域别 License 或 Data Mart
2. 官方询价 经 官网大数据页 联系 提供研究方案概要与用途声明
3. 签订使用合同 明确用途范围、保密与发布限制 可用于调查、研究与商业目的
4. 交付与部署 关系库/CSV 交付或云端 Data Mart 开通 附数据规格书与 master 说明
5. 发表前合规 论文投稿前确认合同发布条款 JMDC 维护公开论文列表页
# 无公开下载,无法脚本化获取;以下为获取后的完整性自检示例
from pathlib import Path
required = ["population/person.csv", "claims/claim_summary.csv",
            "claims/claim_disease.csv", "claims/claim_drug.csv"]
for rel in required:
    p = Path("jmdc_claims") / rel
    assert p.exists(), f"缺少必需表: {rel}"
print("交付完整性 OK")

§6.3 预处理全流程:疾病表型算法(可运行范式)

以 2 型糖尿病为例,复现 Nishioka et al. (2022) 验证过的算法家族:仅用病名码会产生大量假阳性(医生为使 HbA1c 检查可报保险而编码),必须组合"非疑似 flag + 糖尿病药品码"。

import numpy as np
import pandas as pd

# ---------- 1) 日期解析与清洗 ----------
disease = disease.copy()
disease["claim_month"] = pd.to_datetime(disease["claim_month"])
drug = drug.copy()
drug["prescription_date"] = pd.to_datetime(drug["prescription_date"])

# ---------- 2) 定义"可信糖尿病诊断"记录 ----------
# 病名码 E11(ICD-10: 2 型糖尿病),排除疑似 flag
dm_dx = disease[
    disease["icd10_code"].astype(str).str.startswith("E11")
    & (disease["suspected_flag"] == 0)
][["person_id", "claim_month"]]

# 药品佐证:WHO ATC A10(糖尿病用药)
dm_rx = drug[drug["who_atc_code"].astype(str).str.startswith("A10")][
    ["person_id", "prescription_date"]
].rename(columns={"prescription_date": "event_date"})

# 算法 12 风格:同一记录上病名+药品同现(最强 PPV)
# 算法 9 风格:病名与药品各自出现即纳入(平衡 Kappa 最优)
dm_algo9 = pd.concat([dm_dx.rename(columns={"claim_month": "event_date"}),
                      dm_rx]).drop_duplicates(["person_id", "event_date"])

# ---------- 3) 队列构建:index 前 1 年连续在保 ----------
person["first_month"] = pd.to_datetime(person["first_month"])
person["last_month"] = pd.to_datetime(person["last_month"])
index_dates = dm_algo9.groupby("person_id")["event_date"].min()
cohort = person.join(index_dates.rename("index_date"), on="person_id").dropna(
    subset=["index_date"]
)
one_year = pd.DateOffset(months=12)
cohort = cohort[
    (cohort["index_date"] - cohort["first_month"] >= one_year)
    & (cohort["index_date"] <= cohort["last_month"])
]
print(f"算法 9 风格糖尿病队列: {len(cohort):,} 人")

# ---------- 4) 观察窗标准化:每月一行的人-月面板 ----------
months = pd.period_range("2005-01", "2024-12", freq="M")
person_months = person[["person_id", "first_month", "last_month"]].copy()
# 生产环境建议用数据库端区间展开,避免内存爆炸

第二段:基于时点患病率(point prevalence)与暴露窗口的标准化计算——药疫学研究的两块基石:

# ---------- 5) 时点患病率:分母必须是当月在保的全数台账 ----------
def point_prevalence(person: pd.DataFrame, cases: set,
                     year: int, month: int = 6) -> float:
    anchor = pd.Period(f"{year}-{month:02d}", freq="M")
    at_risk = person[
        (person["first_month"].dt.to_period("M") <= anchor)
        & (person["last_month"].dt.to_period("M") >= anchor)
    ]
    denom = at_risk["person_id"].nunique()
    return len(cases & set(at_risk["person_id"])) / denom

# ---------- 6) 暴露窗口:按给药天数展开处方区间,避免把处方日当暴露日 ----------
drug = drug.sort_values(["person_id", "prescription_date"])
drug["exposure_end"] = drug["prescription_date"] + pd.to_timedelta(
    drug["days_of_administration"].fillna(1), unit="D"
)
#  immortal time 检查:从入保(first_month)到首张处方之间的人时
#  只能计入"未暴露组"——生存分析中必须显式处理(§6.5 坑点 2 同源逻辑)
first_rx = drug.groupby("person_id")["prescription_date"].min()
time_to_first_rx = (
    first_rx - person.set_index("person_id")["first_month"].reindex(first_rx.index)
).dt.days
print(f"入保至首张处方天数中位数: {time_to_first_rx.median():.0f} 天")

第三段:大表场景下推荐把队列抽取下推到数据库层(DuckDB SQL 版本,语义与上面 pandas 版一致):

-- 算法 9 风格糖尿病队列:非疑似 E11 病名 或 A10 药品,index 前 12 个月连续在保
WITH dx AS (
    SELECT person_id, MIN(claim_month) AS index_date
    FROM claim_disease
    WHERE icd10_code LIKE 'E11%' AND suspected_flag = 0
    GROUP BY person_id
),
rx AS (
    SELECT person_id, MIN(prescription_date) AS index_date
    FROM claim_drug
    WHERE who_atc_code LIKE 'A10%'
    GROUP BY person_id
),
cases AS (
    SELECT person_id, MIN(index_date) AS index_date
    FROM (
        SELECT person_id, index_date FROM dx
        UNION ALL
        SELECT person_id, index_date FROM rx
    )
    GROUP BY person_id
)
SELECT p.person_id, c.index_date
FROM cases c
JOIN person p USING (person_id)
WHERE DATE(c.index_date, '-12 months') >= p.first_month   -- 基线期在保
  AND c.index_date <= p.last_month;                        -- index 时仍在保

§6.4 PyTorch DataLoader:理赔序列预测模型

任务示例:以某人前 12 个月的"伤病码 + 药品码"事件序列预测未来 12 个月内是否发生糖尿病相关住院/新发强适应证用药。

import torch
from torch.utils.data import Dataset, DataLoader
from collections import defaultdict

VOCAB = {"<pad>": 0, "<unk>": 1}
def encode(code: str) -> int:
    if code not in VOCAB:
        VOCAB[code] = len(VOCAB)
    return VOCAB[code]

class JMDCSequenceDataset(Dataset):
    """每样本 = 一名患者的 12 个月事件序列(按月聚合的多热向量栈)。
    X: [12, vocab] 月级多热编码(伤病码 + 药品码);
    y: 未来 12 个月内结局发生与否(0/1)。
    注意:必须按 person_id 分组切分 train/val/test(见 §5.3 泄漏风险)。"""
    def __init__(self, person_ids: list,
                 events: pd.DataFrame, labels: dict,
                 window: int = 12):
        self.ids = person_ids
        self.events = events
        self.labels = labels
        self.window = window
        # 预构建 月->编码列表 索引,避免逐样本扫描全表
        self.by_person = defaultdict(lambda: defaultdict(list))
        for row in events.itertuples(index=False):
            m = row.claim_month.to_period("M")
            self.by_person[row.person_id][m].append(encode(row.code))

    def __len__(self):
        return len(self.ids)

    def __getitem__(self, i):
        pid = self.ids[i]
        rec = self.by_person.get(pid, {})
        months = sorted(rec)[-self.window:]          # 最近 window 个月
        seq = torch.zeros(self.window, len(VOCAB))
        for j, m in enumerate(months):
            for code in rec[m]:
                seq[j, code] = 1.0
        y = torch.tensor(self.labels.get(pid, 0), dtype=torch.float32)
        return seq, y

# DataLoader 实例化(person_id 级切分后)
train_ds = JMDCSequenceDataset(train_ids, events_df, label_map)
train_loader = DataLoader(train_ds, batch_size=64, shuffle=True,
                          num_workers=4, pin_memory=True)

# 最小模型:月级 GRU 序列编码器
import torch.nn as nn
class ClaimGRU(nn.Module):
    def __init__(self, vocab_size: int, hidden: int = 128):
        super().__init__()
        self.rnn = nn.GRU(vocab_size, hidden, batch_first=True)
        self.head = nn.Linear(hidden, 1)
    def forward(self, x):                     # x: [B, 12, vocab]
        _, h = self.rnn(x)
        return self.head(h[-1]).squeeze(-1)   # logits [B]

# 训练循环(含按 person_id 分组后的验证)
device = "cuda" if torch.cuda.is_available() else "cpu"
model = ClaimGRU(vocab_size=len(VOCAB)).to(device)
opt = torch.optim.AdamW(model.parameters(), lr=1e-3)
loss_fn = nn.BCEWithLogitsLoss()

for epoch in range(5):
    model.train()
    for x, y in train_loader:
        x, y = x.to(device), y.to(device)
        opt.zero_grad()
        loss = loss_fn(model(x), y)
        loss.backward()
        opt.step()
    # 每轮在验证窗上评估 AUROC,注意验证集与训练集无同人(§5.3)
    print(f"epoch {epoch}: train loss = {loss.item():.4f}")

§6.5 坑点 8 个

⚠️ 坑点 1:疑似(suspected)flag 不排除,表型全是假阳性(分类:标签理解)

问题:日本理赔病名按保险请求目的编码,医生为使检查/用药可报保险,常为"待排"疾病编码,官方专门设置了疑似伤病 flag。做疾病队列时若不排除疑似记录,会把"正在检查是否患病"的健康人划为病例。
症状:患病率显著高于文献值;只用病名码定义糖尿病时假阳性大量出现(Nishioka et al., 2022 实证)。
解决:

  1. 简单方法:所有病名条件加 suspected_flag == 0 过滤。
  2. 进阶方法:病名码 + 药品码联接算法(同记录同现优先),并用健检血检做参照验证敏感度/特异度/PPV。
  3. SOTA 方法:为每个研究病种发布带验证指标的算法卡(algorithm card),复用 Nishioka 17 算法范式报告 Kappa/Youden。
    参考:Nishioka et al., J Diabetes Investig 2022;13(2):249-255, doi:10.1111/jdi.13641

⚠️ 坑点 2:脱退删失是信息性的,直接随访会偏向健康人(分类:偏倚陷阱)

问题:被保险人退出组合(退职、转出)后记录立即终止,而退职与健康状态相关(重病者可能退职转入国民健康保险或后续期老年人医疗制度),构成非随机删失。
症状:长期随访队列人数"无故"衰减;结局率随随访时间延长而系统性低估。
解决:

  1. 简单方法:以台账 first/last_month 显式构造观察期,随访窗内脱退者按删失处理而非"未发生结局"。
  2. 进阶方法:生存分析用时间-事件框架 + 逆概率删失加权(IPCW)。
  3. SOTA 方法:敏感度分析比较"最坏情形编码"(脱退者全部视为发生结局)下的区间估计。
    参考:Nagai et al., J Gen Fam Med 2021;22(3):118-127, doi:10.1002/jgf2.422(官方弱点声明)

⚠️ 坑点 3:把 JMDC 当全国人群,年龄结构立即背叛你(分类:偏倚陷阱)

问题:JMDC 人群为大企业雇员及家属(0-74 岁,>65 岁极少,≥75 岁无),存在健康工人效应;直接报告"日本全国患病率"会产生系统性偏差。
症状:老年病(骨质疏松、晚期肿瘤)发生率远低于全国统计;与 NDB 比较时 ICD-10 各章就诊数结构不一致。
解决:

  1. 简单方法:所有外推结论限定"0-74 岁参保人群"口径。
  2. 进阶方法:按性别-年龄组结构放大(Nagai et al., 2021 图 2-11 提供官方放大方法并与 NDB 对比校准)。
  3. SOTA 方法:老年病研究改用 JMDC 医疗机构库(含 65+ 与 DPC 信息)或 NDB。
    参考:Nagai et al., 2021(官方放大对比章节);OHE Consulting Report 2019

⚠️ 坑点 4:入库滞后 5 个月,"最新月份"是空洞的(分类:工程陷阱)

问题:数据在诊疗月后约 5 个月才进入数据库,任何时点导出的表中最后几个月记录不完整。
症状:月度事件量在序列末端断崖式下跌;按日历月切分训练/测试时测试窗数据不完整。
解决:

  1. 简单方法:所有分析把"可用月末"设为导出日期减 5 个月。
  2. 进阶方法:时间切分在训练窗与测试窗之间再预留 5 个月真空带,模拟真实部署时序。
  3. SOTA 方法:数据更新管线以"发布批次"而非日历月为版本锚点,监控每月批次到达率后判定可用性。
    参考:Nagai et al., 2021(采集周期章节)

⚠️ 坑点 5:病名编码服务于报销,不服务于临床定义(分类:标签理解)

问题:理赔是收费凭证:病名码的存在逻辑是"这项检查/治疗/用药需要这个诊断才可报",因此病名与临床真相之间隔着报销规则。
症状:轻症记录密集(用药审查需要)、重症反而遗漏(无需额外报销项目时未必编码);转归、严重度字段缺失。
解决:

  1. 简单方法:结局定义用"硬事件"(死亡 flag、入院/出院日期、手术行为码)而非病名链。
  2. 进阶方法:组合病名+行为+药品三通道的表型算法,并报告每通道的验证贡献。
  3. SOTA 方法:对关键结局做抽样人工病历核对(如日本药疫学界对卒中的验证范式),至少报告 PPV。
    参考:Nagai et al., 2021(Strengths and Weaknesses 章节)

⚠️ 坑点 6:组合库没有检验值,严重度调整无路可走(分类:预处理陷阱)

问题:健保组合库不含临床检验值(这是官方明示的弱点),而健检数据只有年度一次且仅覆盖参检者。
症状:用理赔做结局预测时,模型拿不到 HbA1c、eGFR 等关键协变量,性能与可解释性受限;把健检值当作"实时检验"使用会产生时间错位。
解决:

  1. 简单方法:严重度代理改用医疗资源占用(点数、住院天数、占用资源最多 flag)。
  2. 进阶方法:健检值作为"年度快照"协变量,显式建模其与 index 的时间距离。
  3. SOTA 方法:需要检验值的研究切换 JMDC 医疗机构库(JLAC10 标准化检验值表)或 MID-NET。
    参考:Nagai et al., 2021;Nagai et al., J Gen Fam Med 2020, doi:10.1002/jgf2.367

⚠️ 坑点 7:母婴联接的孕周陷阱:出生日期被抑制、分娩码高缺失(分类:偏倚陷阱)

问题:家族识别码虽支持母婴联接,但为保护隐私,婴儿出生日期被抑制,且活产分娩记录码缺失率高达 60%;孕周信息不可得,孕期暴露窗口难以精确锚定。
症状:早产率仅 3.6%(人群预期 5.6%),系统性低估;以末次月经推算的孕期暴露分类大量错位。
解决:

  1. 简单方法:仅做描述性研究(孕期用药率、共病谱),避开孕周敏感结局。
  2. 进阶方法:用分娩相关行为码+新生儿记录的联合规则推断分娩时点,做 fit-for-purpose 敏感度分析。
  3. SOTA 方法:宫内暴露窗研究改用孕周可靠的登记/病历数据源,JMDC 作为补充。
    参考:Barberio et al., Characterizing fit-for-purpose real-world data… , Clinical Epidemiology(Dove Press)

⚠️ 坑点 8:家族与同人聚集导致评估虚高(分类:数据泄漏)

问题:同一人跨月跨机构的记录高度相关,同一家族成员共享环境与就诊模式;按记录行或按个体随机切分都会让模型在测试集"见过答案的近亲"。
症状:随机切分的 AUROC 显著高于时间外推切分;上线后性能骤降。
解决:

  1. 简单方法:按 person_id 分组切分(GroupShuffleSplit/GroupKFold)。
  2. 进阶方法:训练/测试同时按家族聚类切分,并用家族 ID 分层抽样。
  3. SOTA 方法:主结果用前向链式时间外推 + 人员分组,随机切分仅作附录对照。
    参考:§5.3 本页方法学综合;OHDSI Book of PyTorch/PLP 的时间外推惯例

§6.6 数据增强(安全与危险)

操作 安全性 说明
事件 dropout(随机掩码少量码) ✅ 安全 模拟编码遗漏,提升鲁棒性
月级时间窗滑动采样 ✅ 安全 扩展人-月样本,注意不跨越 index 泄漏
码表层级上卷(ICD-10 章/ATC 第 1 层) ✅ 安全 缓解稀疏长尾码
随机改写 ICD-10 码位 ❌ 危险 制造临床无意义的假码
剂量/天数随机缩放 ❌ 危险 破坏暴露窗口与 DDD 逻辑
人为插入未来月份记录 ❌ 危险 违反因果时序,制造标签泄漏

§6.7 模型推荐表

任务 推荐模型 理由
患病率/发生率、暴露-结局推断 Logistic 回归 / Cox 比例风险 药疫学金标准,可解释、易做敏感度分析
结局预测(表格协变量) LightGBM / XGBoost 人-月面板上的强基线,天然处理缺失
纵向理赔序列预测 GRU / Transformer(多热月级输入) 事件流稀疏多热结构适配;参考 RETain/BEHRT 思路
多库联合预测 OHDSI Patient-Level Prediction 框架 OMOP 化后可直接进入跨库开发-验证流程

§6.8 硬件需求表

场景 配置建议 说明
队列表型 + 生存分析 32 GB 内存工作站 pandas/duckdb 单机即可,优先数据库端聚合
全库人-月面板 + GBDT 128 GB 内存 + 16 核 人-月行数量大,建议 DuckDB/Spark 分区
序列深度模型 1-2 张 24 GB GPU 序列按月聚合后输入规模可控;瓶颈通常在 I/O 与 vocab

§6.9 评估指标代码

import numpy as np

def pharma_eval(y_true, y_score, threshold: float = 0.5):
    """药疫学口味的三件套:判别 + 校准 + 阈值下 PPV/NPV。
    理赔库研究的惯例是同时报告表型算法的验证指标(§2.6)。"""
    y_true = np.asarray(y_true); y_score = np.asarray(y_score)
    order = np.argsort(-y_score)
    ranks = np.empty_like(order, dtype=float); ranks[order] = np.arange(1, len(y_score) + 1)
    n_pos, n_neg = y_true.sum(), (1 - y_true).sum()
    auroc = (ranks[y_true == 1].sum() - n_pos * (n_pos + 1) / 2) / (n_pos * n_neg)
    pred = (y_score >= threshold).astype(int)
    ppv = pred[y_true == 1].mean() if n_pos else np.nan      # 阳性预测值
    npv = (1 - pred[y_true == 0]).mean() if n_neg else np.nan
    # 校准:十分位组的期望 vs 实际
    bins = pd.qcut(y_score, 10, duplicates="drop")
    calib = pd.DataFrame({"y": y_true, "p": y_score, "b": bins}).groupby("b", observed=True).agg(
        obs=("y", "mean"), exp=("p", "mean"))
    return {"AUROC": auroc, f"PPV@{threshold}": ppv, f"NPV@{threshold}": npv,
            "calibration": calib}

生产环境推荐改用 sklearn 的向量实现(与上面手写版交叉验证数值一致性后再上线):

from sklearn.metrics import roc_auc_score, average_precision_score, brier_score_loss

def sklearn_eval(y_true, y_score) -> dict:
    return {
        "AUROC": roc_auc_score(y_true, y_score),
        "AUPRC": average_precision_score(y_true, y_score),  # 类别失衡时比 AUROC 更敏感
        "Brier": brier_score_loss(y_true, y_score),          # 校准的单一标量摘要
    }
# 报告惯例:AUROC + AUPRC + 校准曲线(十分位),并按性别/年龄分层复算全部指标

§6.10 MLOps 笔记

  1. 版本锚点:以 JMDC 数据交付批次(月)为数据版本锚点,记录每个训练运行的 cutoff 月份。
  2. 重训节奏:每年 4 月日本诊疗报酬改定会使编码与费用结构跳变,改定年后建议强制重训并监控 ICD-10 各章构成漂移。
  3. 漂移监控:跟踪每月新发事件量、病名码分布、点数分布;末端月份量骤降时优先怀疑入库滞后而非真实疫情。
  4. 合规流水线:模型与聚合统计的对外发布须过合同合规检查;个体级结果不得输出。
  5. 特征仓库:把表型算法沉淀为版本化 SQL/Python 模块(输入码表、flag 规则、验证指标三元组一体),跨项目复用并随 ICD 编码行为漂移定期复核。

§7 质量评估与局限性

§7.1 已知偏倚表

偏倚类型 描述 严重程度 缓解措施
选择偏倚(受雇人群) 大企业雇员及家属,未覆盖失业、个体经营、高龄人群 高 限定结论口径;按性别-年龄放大;换库
健康工人效应 在职人群总体更健康 中 与外部人群数据对比校正;避免绝对率外推
信息性删失 脱退与健康状况相关 高 生存框架 + IPCW;最坏情形敏感度分析
编码偏倚 病名按报销目的编码,疑似记录混杂 高 疑似 flag 排除 + 药品码佐证 + 验证指标
老年代表性不足 >65 岁极少、≥75 岁无 高(老年研究) 改用医疗机构库/NDB
时间滞后 入库滞后约 5 个月 低-中 分析窗预留空档;批次版本锚定

§7.2 标注质量

无人工标注;数据质量由审查支付机构外部检查与 JMDC 入库校验(重复检查、月度量异动检查、格式/范围校验、错误码规范化)双机制保障(Nagai et al., 2020)。关键结局的编码效度有公开验证证据:理赔内死亡对住院死亡的敏感度/特异度/PPV 约 95%(65-74 岁人群,官方引述);糖尿病表型算法已建立 17 算法的定量验证基准。研究者在发表时引用这些验证锚点可大幅提升证据等级。

值得强调的是,"标注质量"在该库语境下是可被研究者主动提升的:同一结局用不同算法会得到不同效度,把验证环节前置到表型定义阶段(而非模型评估阶段),是日本理赔数据方法学社区(Nishioka 等人的工作所代表的方向)的一致共识。

§7.3 泛化性评估表

场景 失效风险 证据
外推至日本全国人群 高:年龄/职业结构差异 Nagai et al., 2021 与 NDB 的结构对比
老年病研究 极高:≥75 岁无数据 官方弱点声明
婴幼儿研究 中:家属覆盖但出生日期仅到月 官方字段说明;母婴联接评估
国际多库联合研究 低-中:OMOP 化后可行 2025-09 Yuimedi 合作公告
孕产暴露精确窗分析 高:孕周效度受限、早产低估 Barberio et al., Clinical Epidemiology

§7.4 伦理与合规

数据按 APPI(个人信息保护法)第 2 条第 9 项实施匿名化后,由组合基于二次利用同意机制提供;组合名称与地理信息不公开。使用须经与 JMDC 签订使用合同,允许调查、研究与商业目的;个人层面知情同意由组合侧匿名化框架替代处理。研究者发表前应确认合同发布条款;IRB 要求因机构而异(多数学术机构对合同制匿名化理赔数据出具豁免,见公开论文的机构审批实践,如 PMID 37808588 所示的大学 IRB 批准)。

§7.5 公平性

该库的公平性结构由日本健保制度决定:性别上男性(雇员主体)占比偏高;年龄上工作年龄段主导;家属(含儿童与老年配偶)覆盖受扶养收入门槛约束。训练 AI 模型时应报告按性别、年龄分层的性能差异;对家属子群体的样本量明显小于雇员主体,小样本分层的性能评估须谨慎。

§7.6 数据漂移

三大漂移源:①诊疗报酬改定(每两年一次,4 月实施)改变点数与部分编码行为,费用类模型需按改定周期重校准;②诊疗指南与药品准入(如新药上市)改变处方结构;③社会事件冲击(如 COVID-19 疫情)造成就诊结构与延迟就医的断层。建议以年度为最小监控单元跟踪码分布与费用分布的 PSI(总体稳定性指数)。

import numpy as np

def psi(expected: np.ndarray, actual: np.ndarray, bins: int = 10) -> float:
    """群体稳定性指数:>0.2 需人工复盘,>0.25 建议触发重训。"""
    edges = np.quantile(expected, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf
    e = np.histogram(expected, edges)[0] / len(expected) + 1e-6
    a = np.histogram(actual, edges)[0] / len(actual) + 1e-6
    return float(np.sum((a - e) * np.log(a / e)))

# 典型监控对象:月度点数分布、ICD-10 章级构成、A10 药品占比
# 参照分布 = 上一个完整会计年度;实际分布 = 最近月份批次

§7.7 DAIMS 数据集质量评估

# 检查项 状态 说明
1 宽格式 ⚠️ 关系型窄表,人-月面板需自行 pivot
2 唯一标识 ✅ 匿名个人 ID + 家族识别码,跨库跨机构可追踪
3 特殊字符 ✅ 编码均为标准码域,经辞书规范化
4 重复行 ✅ JMDC 入库时执行重复检查
5 缺失编码 ✅ 缺失保留原样且有外部审查兜底,缺失率低
6 标签标识 ⚠️ 无预设标签,结局需表型算法定义
7 罕见类分组 ⚠️ 长尾码需研究者自行上卷至章/类层面
8 偏倚评估 ✅ 官方资源论文系统披露优点与弱点
9 数据字典 ✅ 完整 master 体系与表说明(资源论文表 1)
10 信息性缺失解释 ⚠️ 脱退/未参检的信息性缺失需研究者自行处理
11 设备记录 ❌ 无影像/信号/设备元数据
12 共线性 ✅ 点数-天数-行为次数等字段逻辑一致,无自动共线问题
13 编码映射 ✅ ICD-10、WHO/EphMRA ATC、MHLW 码、JLAC10(医疗机构库)
14 时间戳处理 ⚠️ 部分字段仅年月粒度,日期级字段有限
15 划分建议 ✅ 本页 §5 提供分组与时间外推划分方案
16 泄漏讨论 ✅ 本页 §5.3 系统覆盖同人/家族/时间/滞后泄漏
17 标签分布 ⚠️ 无官方标签分布报告,分布依赖算法定义
18 测量偏倚 ✅ 报销目的编码偏倚已公开讨论并有验证研究
19 外部验证建议 ✅ 官方放大对比框架 + OHDSI 网络路径
20 版本记录 ⚠️ 无显式版本号,月度滚动交付需自建批次锚点
21 预处理脚本 ❌ 无官方开源脚本(辞书内置但代码不公开)
22 合规要求 ✅ 合同条款 + APPI 匿名化框架清晰
23 多模态对齐 ✅ 理赔-健检-台账按 person_id 内置联接
24 去标识化 ✅ 不可逆匿名化,出生日期月粒度截断,地理信息移除

DAIMS 评分:18.5 / 24

评分解读:该库在标识体系、编码映射、去标识化与合规四个维度达到满分水准,反映了商业数据库在数据工程与法务上的成熟度;失分集中在"AI 任务配套"——无预设标签、无官方划分、无预处理脚本、无显式版本号——这些都需要研究团队自建方法学基础设施。

对你意味着什么:如果你的团队已有强方法学能力(表型算法、生存分析、时序建模),JMDC 是投入产出比极高的真实世界数据资产;如果团队期待"下载即训练"的基准体验,请先储备以下三件事——①建立批次版本锚点与数据质量看板;②为目标病种开发并验证表型算法(引用 Nishioka 范式);③按 §5.3 实施分组 + 时间外推的评估协议。

§7.8 外部验证矩阵

外部数据集/场景 来源机构 评估任务 性能指标 相对内部变化 关键发现
NDB 放大统计 厚生劳动省 就诊/住院量结构比对 按性别-年龄组放大后一致性 各 ICD-10 章结构差异可量化 官方提供完整放大与对比方法(Nagai et al., 2021 图 2-11)
特定健检血检参照 同组合健检 糖尿病表型算法 算法 9/12 Kappa 最优;算法 16 敏感度 94.0% 仅病名码大量假阳性 Nishioka et al., 2022(J Diabetes Investig)
住院死亡记录 组合台账 死亡终点效度 敏感度/特异度/PPV ≈95%(65-74 岁住院死亡) — Nagai et al., 2021 引述的验证研究
Duke-Margolis fit-for-purpose 评估 Amgen/Emory 母婴联接适用性 385,295 对;57% 孕期连续在保 早产 3.6% vs 人群 5.6% 描述性研究适用;孕周敏感结局受限
OHDSI 11 库网络 Janssen/IQVIA/Stanford 等 跨库预后模型外部验证 JMDC 以 5,550,200 人参与 3 国 11 库 — JMDC 可进入国际 OMOP 工作流(PMID 31910437)

§8 基准性能与生态

§8.1 排行榜与代表性基准

JMDC 是真实世界数据源而非竞赛基准,不存在公开排行榜。社区的事实"基准"是方法学研究与跨库外部验证,代表性结果如下(数值源自不同任务与算法定义,不可直接互相比较):

研究 任务 关键数值 年份 关键技术 完整引用 代码
糖尿病算法验证 表型算法 17 算法;算法 16 敏感度 94.0%;算法 9/12 Kappa 最优 2022 病名+药品码联接 + 健检参照 Nishioka et al., 2022, J Diabetes Investig. doi:10.1111/jdi.13641 未公开
死亡终点验证 结局效度 敏感度/特异度/PPV ≈95% 2021 与住院死亡对照 见 Nagai et al., 2021, J Gen Fam Med. doi:10.1002/jgf2.422(引文 28) 不适用
OHDSI 跨库卒中预后 出血性转化预测 JMDC 以 5,550,200 人参与 11 库 3 国验证 2019 OMOP CDM + PLP 框架 Reps et al.(PMID 31910437) 研究协议公开(OHDSI GitHub)
母婴联接评估 数据适用性 385,295 对;57% 连续在保 2023 前后 Duke-Margolis 框架 Barberio et al., Clinical Epidemiology(Dove Press) 未公开

§8.2 SOTA 总结与选型建议

在"日本理赔数据方法学"这一事实基准线上:表型算法研究已从"经验定义"演进到"定量验证发布";预测建模正从单库 GBDT 向 OHDSI 网络化跨库验证迁移。选型建议:以业务问题为锚(安全信号选药物警戒包工作流,发生率估计选全数台账口径,预测建模选 Raw Data + OMOP 路径),不要为追模型新颖度牺牲表型验证的严谨性。

§8.3 评测协议

推荐协议:①声明数据批次 cutoff 与 5 个月滞后处理;②报告表型算法验证指标;③person_id 分组 + 前向时间外推评估;④报告按性别/年龄分层的性能;⑤与 NDB 放大统计做队列特征 sanity check。

若以论文发表为目标,建议在方法部分固定披露以下清单(审稿人对理赔库研究的标准追问点):

披露项 内容要求
数据批次 交付月份、cutoff 月、滞后处理方式
表型算法 完整码表 + flag 处理 + 验证指标(引用或自测)
观察期定义 first/last_month 的使用方式、脱退处理
暴露窗口 处方日 vs 给药天数展开、DDD 或天数近似
切分方式 person_id 分组、时间外推、真空带设置
分层性能 性别、年龄段、雇员/家属子群体
数据集 机构 模态 与 JMDC 关系
NDB / NDB Open Data 厚生劳动省 全国理赔+健检 全民口径的公家对照
JMDC 医疗机构库 JMDC DPC 病历摘要+检验值 同门补充库(含老年与检验值)
MDV EBM Provider Medical Data Vision DPC 医院数据 商业竞品(住院视角)
Medi-Scope JMIRI 理赔+健检 商业竞品(项目更全规模较小)
MID-NET PMDA 23 院病历级 药物安全官方网络
MarketScan(美国) IBM 美国商业理赔 同类商业理赔的国际对照

§8.5 关键论文 Top 6

  1. Kimura S, Sato T, Ikeda S, Noda M, Nakayama T. Development of a database of health insurance claims: standardization of disease classifications and anonymous record linkage. J Epidemiol. 2010;20(5):413-419. doi:10.2188/jea.JE20090066 —— JMDC 库的奠基论文,提出伤病分类标准化与匿名记录联接方法论。
  2. Nagai K, Tanaka T, Kodaira N, Kimura S, Takahashi Y, Nakayama T. Data resource profile: JMDC claims database sourced from health insurance societies. J Gen Fam Med. 2021;22(3):118-127. doi:10.1002/jgf2.422 —— 健保组合库的官方资源档案:表结构、规模、优弱点与放大对比方法的一站式参考。
  3. Nagai K, Tanaka T, Kodaira N, Kimura S, Takahashi Y, Nakayama T. Data resource profile: JMDC claims databases sourced from Medical Institutions. J Gen Fam Med. 2020. doi:10.1002/jgf2.367 —— 医疗机构库(DPC/检验值/老年人群)的官方资源档案。
  4. Nishioka Y, Takeshita S, Kubo S, Myojin T, Noda T, Okada S, Ishii H, Imamura T, Takahashi Y. Appropriate definition of diabetes using an administrative database: a cross-sectional cohort validation study. J Diabetes Investig. 2022;13(2):249-255. doi:10.1111/jdi.13641 —— 表型算法定量验证的范式之作(17 算法)。
  5. Barberio J, Hernandez RK, Naimi AI, Patzer RE, Kim C, Lash TL. Characterizing fit-for-purpose real-world data: an assessment of a mother-infant linkage in the Japan Medical Data Center claims database. Clinical Epidemiology(Dove Press). —— 以监管框架评估该库孕产研究适用性的代表工作。
  6. Reps JM, et al. Development and validation of a prognostic model predicting symptomatic hemorrhagic transformation in acute ischemic stroke at scale in the OHDSI network.(PMID 31910437) —— 展示 JMDC 进入 OMOP 跨库大规模预测验证的先例。

§8.6 社区活跃度

截至 2026-08:1,000+ 篇论文、470+ 件学会发表(JMDC 官网口径);主要制药与器械厂商、生保损保、官公厅与日本 50+ 大学采用。学术侧的活跃度可以从资源论文的引用轨迹与官方论文列表页(持续更新)观察;产业侧,JMDC 上市后连续多年营收高速增长(FY2026/3 收益 504.62 亿日元、同比 +21%),Healthcare-Big Data 为核心分部,制药 S&M(销售与市场)交易额同比 +43%(FY2025 Q3 决算口径),数据资产处于持续扩张期:与电子病历厂商的战略联盟(2026-02 公告)、OMOP 化(2025-09)、可穿戴 PHR 数据接入(Pep Up 平台 800 万+ ID)都在同步推进。对 AI 团队而言,这是生态活跃度与数据持续供给能力的强信号。

§8.7 生态快照表

资源 类型 链接 推荐理由
JMDC Big Data 官方页 官方入口 jmdc.co.jp/en/bigdata 询价签约的唯一官方入口
JMDC Claims Database 介绍 官方介绍 jmdc.co.jp/?p=12734 三大特性与使用实绩的官方口径
制药解决方案页 官方产品 jmdc.co.jp/pharma/ Data Mart 全系产品线说明
论文列表页 官方文献库 info.jmdc.co.jp/jrda/ 覆盖两大库的发表论文持续更新
ETL-LambdaBuilder JMDC 条目 OHDSI 社区文档 ohdsi.github.io/ETL-LambdaBuilder/docs/JMDC 早期 OMOP ETL 规格的社区参考
OMOP CDM 合作公告 官方新闻 JMDC×Yuimedi(2025-09-30) 国际标准格式化的最新进展

§9 相关资源与引用

§9.1 官方资源

§9.2 方法学与社区资源

§9.3 BibTeX 引用块

@article{Kimura2010_JMDC,
  author  = {Kimura, Shinya and Sato, Takaaki and Ikeda, Shun and Noda, Mitsuhiko and Nakayama, Takeo},
  title   = {Development of a database of health insurance claims: standardization of disease classifications and anonymous record linkage},
  journal = {Journal of Epidemiology},
  year    = {2010},
  volume  = {20},
  number  = {5},
  pages   = {413--419},
  doi     = {10.2188/jea.JE20090066}
}

@article{Nagai2021_JMDC,
  author  = {Nagai, Katsuhiko and Tanaka, Takashi and Kodaira, Norihisa and Kimura, Shinya and Takahashi, Yoshimitsu and Nakayama, Takeo},
  title   = {Data resource profile: JMDC claims database sourced from health insurance societies},
  journal = {Journal of General and Family Medicine},
  year    = {2021},
  volume  = {22},
  number  = {3},
  pages   = {118--127},
  doi     = {10.1002/jgf2.422}
}

@article{Nagai2020_JMDC_MedInst,
  author  = {Nagai, Katsuhiko and Tanaka, Takashi and Kodaira, Norihisa and Kimura, Shinya and Takahashi, Yoshimitsu and Nakayama, Takeo},
  title   = {Data resource profile: JMDC claims databases sourced from Medical Institutions},
  journal = {Journal of General and Family Medicine},
  year    = {2020},
  doi     = {10.1002/jgf2.367}
}

@article{Nishioka2022_DM_Algorithms,
  author  = {Nishioka, Yuichi and Takeshita, Saki and Kubo, Shinichiro and Myojin, Tomoya and Noda, Tatsuya and Okada, Sadanori and Ishii, Hitoshi and Imamura, Tomoaki and Takahashi, Yutaka},
  title   = {Appropriate definition of diabetes using an administrative database: a cross-sectional cohort validation study},
  journal = {Journal of Diabetes Investigation},
  year    = {2022},
  volume  = {13},
  number  = {2},
  pages   = {249--255},
  doi     = {10.1111/jdi.13641}
}

§9.4 引用指南

使用该数据库的研究,请同时引用:①数据资源描述论文(Nagai et al., 2021 或对应库版本);②奠基方法论文(Kimura et al., 2010);③你所使用的表型算法验证研究(如糖尿病算法用 Nishioka et al., 2022)。合同可能对论文致谢或送审有具体条款,以合同为准。

此外的三点实践建议:①在 Methods 中明确声明使用的库版本(健保组合库 vs 医疗机构库)与数据批次月份,避免两类 JMDC 数据被混用引用(官方论文列表页对此也做了区分);②引用验证研究时注明其对应的人群段(如死亡终点验证针对 65-74 岁住院死亡);③如结果用于监管提交,引用 Duke-Margolis fit-for-purpose 评估(Barberio et al.)作为适用性论证的框架先例。


§10 AI 使用声明卡

§10.1 AI 模型列表

模型 用途 使用范围
fast-model(千方写作助手) 初稿生成、结构组织、事实核对辅助 全文初稿;所有数字与事实经编辑交叉核对检索来源

§10.2 AI 参与范围

AI 参与了初稿撰写、结构规划与语言润色;选题、框架、质量标准由千方病案医学编辑部制定;全部关键数字(规模、日期、验证指标、财务数据)均经 Web 检索来源核对并在正文标注;医学与数据工程内容按 §0 声明完成交叉审核。AI 未访问任何 JMDC 合同交付数据,本页不含对原始数据的直接分析。

§10.3 输入来源列表

  1. Nagai K, Tanaka T, Kodaira N, Kimura S, Takahashi Y, Nakayama T. Data resource profile: JMDC claims database sourced from health insurance societies. J Gen Fam Med. 2021;22(3):118-127. doi:10.1002/jgf2.422
  2. Nagai K, Tanaka T, Kodaira N, Kimura S, Takahashi Y, Nakayama T. Data resource profile: JMDC claims databases sourced from Medical Institutions. J Gen Fam Med. 2020. doi:10.1002/jgf2.367
  3. Kimura S, Sato T, Ikeda S, Noda M, Nakayama T. Development of a database of health insurance claims: standardization of disease classifications and anonymous record linkage. J Epidemiol. 2010;20(5):413-419. doi:10.2188/jea.JE20090066
  4. Nishioka Y, Takeshita S, Kubo S, et al. Appropriate definition of diabetes using an administrative database: a cross-sectional cohort validation study. J Diabetes Investig. 2022;13(2):249-255. doi:10.1111/jdi.13641
  5. Barberio J, Hernandez RK, Naimi AI, Patzer RE, Kim C, Lash TL. Characterizing fit-for-purpose real-world data: an assessment of a mother-infant linkage in the Japan Medical Data Center claims database. Clinical Epidemiology(Dove Press). 全文链接
  6. Reps JM, et al. Development and validation of a prognostic model predicting symptomatic hemorrhagic transformation in acute ischemic stroke at scale in the OHDSI network. PMID 31910437
  7. Office of Health Economics Consulting. Governance arrangements for real-world evidence generation in Japan. 2019. 报告 PDF
  8. Current status, challenges, and future perspectives of real-world data and real-world evidence in Japan. J Pharm Health Care Sci. 2021. doi:10.1007/s40801-021-00266-3
  9. Epidemiology of narcolepsy and idiopathic hypersomnia in Japan: a retrospective analysis of health insurance claims from the Japan Medical Data Center. Sleep Medicine. 2024. ScienceDirect
  10. Smoking cessation behavior in patients with a diagnosis of a non-communicable disease(JMDC 2005-2022 口径). PMID 37808588
  11. A review of research studies using data from the administrative claims databases in Japan(厚生劳动省研究班). PMC9712845
  12. 日本の大規模統合データベースの特性比較表. BMC Med Inform Decis Mak. 2021;21:167. doi:10.1186/s12911-021-01526-6
  13. JMDC Inc. 官方主页(公司概览/业务说明). jmdc.co.jp/en
  14. JMDC Inc. JMDC Claims Database 介绍页. jmdc.co.jp/?p=12734
  15. JMDC Inc. ビッグデータ(製薬分野)产品页. jmdc.co.jp/pharma/
  16. JMDC Inc. 2026 年 3 月期通期决算说明资料. 2026-05-08. 决算 PDF
  17. JMDC Inc. / Yuimedi. リアルワールドデータの OMOP CDM 対応に向けた協業開始. 2025-09-30. 官方新闻
  18. OHDSI. ETL-LambdaBuilder: JMDC ETL Documentation. ohdsi.github.io
  19. Stockopedia. JMDC Inc.(TYO:4483)公司档案:设立 2002-01-31、上市 2019-12-16. stockopedia.com

§10.4 人工校验记录

内容模块 审核者 审核方式 审核状态
规模数字与时间轴(§1、§3.2) 千方病案医学编辑部 逐条对照官方决算资料与资源论文 ✅ 已通过
表结构与字段字典(§4) 千方病案医学编辑部 对照 Nagai et al., 2021 表 1 逐字段核对 ✅ 已通过
医学背景与编码映射(§2) 千方病案医学编辑部 ICD-11/SNOMED 术语交叉核对 ✅ 已通过
坑点与验证证据(§6.5、§7.8) 千方病案医学编辑部 逐条对照验证研究原文 ✅ 已通过
许可与合规描述(§3、§7.4) 千方病案医学编辑部 对照官方访问条款与 APPI 说明 ✅ 已通过
代码示例(§6) 千方病案医学编辑部 语法检查与逻辑核对(合同数据不可公开运行) ✅ 已通过

§10.5 AI 生成章节标注

本页全文由 AI 辅助生成初稿;其中 §1.0 速览、§6 坑点体系与 §7 DAIMS 评估为 AI 依据检索证据的结构化归纳,均经人工逐条核对后发布。

§10.6 最后人工审核日期

2026-09-05(与 §0 审核日期一致)

页面状态:published(全部内容已完成审核并发布)


§C 结构化数据(JSON-LD)


相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集,按相关度降序排列:

  • cgrd — 共享标签:电子健康记录 / 药物发现与化学 / 临床电子病历 / 真实世界数据 / 药物安全
  • thin — 共享标签:电子健康记录 / 药物发现与化学 / 临床电子病历 / 真实世界数据 / 药物安全
  • trinetx — 共享标签:电子健康记录 / 药物发现与化学 / 真实世界数据 / 药物安全
  • cprd — 共享标签:电子健康记录 / 临床电子病历 / 真实世界数据 / 药物安全
  • twosides — 共享标签:电子健康记录 / 药物发现与化学 / 真实世界数据 / 药物安全
  • faers — 共享标签:电子健康记录 / 药物发现与化学 / 真实世界数据 / 药物安全
  • nhird — 共享标签:电子健康记录 / 药物发现与化学 / 医保理赔 / 药物安全
  • snds — 共享标签:电子健康记录 / 医保理赔 / 真实世界数据 / 药物安全
  • gepard — 共享标签:电子健康记录 / 医保理赔 / 真实世界数据 / 药物安全
  • optum-clinformatics — 共享标签:药物发现与化学 / 医保理赔 / 真实世界数据 / 药物安全

导航说明:本章节由全站统一标签体系自动计算生成(标签重合度算法),双向可达;点击链接可跳转至对应数据集词条。

返回 AI-Ready 数据集