信息速览
ABDM 常被中文语境当成「印度的电子病历库」，这个理解从第一层就是错的。它的正式全称是 Ayushman Bharat Digital Mission（阿尤什曼数字健康使命），2021 年 9 月由印度政府启动，主管机构是国家卫生局（National Health Authority，NHA）。它交付的不是一份数据，而是四件互相咬合的东西：一个统一的个人健康身份、一本医务人员名录、一本医疗机构名录、一套带同意管理的点对点交换协议——外加把这些东西连起来的 FHIR 接口规范。
所以对想「下载数据」的人来说，ABDM 几乎什么也给不了：它的服务器上不躺着任何一份检验报告或出院小结。病历仍分散在成千上万家医院、诊所与检验中心自己的系统里，ABDM 只保证一件事——当病人换了一家医院，新医生在拿到病人当场签发的授权之后，能把上一家医院的病历从原处拉过来。数据库里没有集中副本，也就没有可以打包分发的临床语料。
但这不等于它没有数据。ABDM 反倒是印度少有的、公开可查且可以逐条浏览的医疗基础设施名录来源：HFR 收录机构，HPR 收录执业者，两者都是面向公众开放的检索服务。本文的重心就落在这条分界线上：同意架构决定了临床数据不可得，名录架构决定了机构与人员数据可得。一屏速览见下表。
| 维度 | 内容 |
|---|---|
| 本质 | 国家级数字健康基础设施（身份 + 名录 + 交换协议），不是数据集 |
| 中文名 | 阿尤什曼数字健康使命 |
| 启动 | 2021 年 9 月 27 日由印度总理宣布启动，前身称 NDHM |
| 主管 | 国家卫生局（NHA），隶属联邦卫生部 |
| 身份组件 | ABHA：14 位数字账号 + xxx@abdm 地址式用户名 |
| 人员组件 | HPR（Healthcare Professionals Registry），执业者注册库 |
| 机构组件 | HFR（Health Facility Registry），机构注册库，公开可查 |
| 交换组件 | 健康信息交换 + 同意管理器（Consent Manager） |
| 接口组件 | UHI 统一健康接口、ABDM Gateway、FHIR 实现规范 |
| 数据托管 | 不集中托管，病历留在原机构服务器 |
| 技术栈方向 | FHIR 资源封装 + 非对称密钥传输 + 异步回调 |
| 公开数据 | HFR / HPR 名录可检索；无个体临床数据下载 |
| 许可 | 名录未声明标准化许可；接口文档公开发布 |
| 主要门槛 | 开发者需沙箱凭证；机构需完成服务订阅与资质核验 |
| 最容易被误当成 | 印度电子病历语料库、全国统一病历库 |
| 本文关注点 | 同意架构、FHIR 剖面、HFR/HPR 两份可得名录 |
§1 它要解决的具体麻烦
1.1 印度医疗的真正痛点是「换一家医院就得从头讲一遍」
一个印度城市中产家庭看病的典型路径是：先在社区诊所看全科，转诊到私立医院做检查，检查结果拿不回来，再去另一家三级医院时被要求全部重做；换城市工作，所有既往病历都留在原来那家医院的纸质档案柜里。印度医疗体系长期是高度碎片化的：公立与私立并行、阿育吠陀等传统医学系统与对抗疗法并行、各邦自行其是，没有统一的患者标识，也没有跨机构的记录调阅通道。
ABDM 的设计判断是：这个麻烦的根子不在「缺一个全国病历库」，而在缺一套让机构之间愿意互相调阅的规则。如果国家把病历收上来集中存放，机构会担心患者流失、数据安全责任、以及合规成本；患者也会担心一份集中副本被谁看了。于是 ABDM 选择了一条反直觉的路——不搬数据，只搬授权。
这个选择带来一个必须记住的后果：ABDM 的成败不取决于它的数据库有多大，而取决于有多少机构愿意当 HIP（Health Information Provider，健康信息提供方）、有多少应用愿意当 HIU（Health Information User，健康信息使用方）。它是一张网，网的价値等于节点数与连接成功率。
1.2 三条常见的错误期待
期待一：以为能下载到印度人的病历。 这是最常见的误解。ABDM 的架构里根本没有「中心病历库」这个组件。任何声称「ABDM 病历数据集」的下载包，要么是第三方从某家医院单独拿到的数据冒用名义，要么是合成数据。真正接近「全国病历」的是 ABDM 之外的另一条线——印度政府的 Ayushman Bharat PM-JAY 医保理赔数据，那是完全不同的系统。
期待二：以为 ABHA 号等同于 Aadhaar。 ABHA 是健康领域的专用标识，虽然登记时可以借助 Aadhaar 做身份核验，但两者不是一回事，ABHA 也不会把 Aadhaar 号暴露在交换报文里。混淆这两者，会在设计机构侧集成时把身份核验与健康身份混成一个流程。
期待三：以为 ABDM 是一份可以「接入」的 API。 它是一组角色协议。你接的不是一个端点，而是一套角色：要么当 HIP 提供病历，要么当 HIU 索取病历，要么当网关侧的同意管理器，要么只是消费公开名录。搞清楚自己扮演哪个角色，比背端点路径重要得多。
1.3 它能给到的与给不到的
| 你的需求 | 它给的 | 够不够 |
|---|---|---|
| 印度医院名录，含类型与地理分布 | HFR 公开检索，按邦、县、类型逐条浏览 | 够，但需自行抓取整理 |
| 印度执业医生名录 | HPR 公开检索，含专业与注册信息 | 大体够，覆盖取决于自愿登记 |
| 跨机构调阅某位患者的既往病历 | 同意管理器 + 网关 + 点对点推送 | 架构上够，实操依赖两端在线 |
| 训练临床语言模型的病历语料 | 无 | 完全不够，另寻来源 |
| 印度疾病谱的真实世界统计 | 无（名录不含病种） | 不够 |
| 理解一个反集中式健康数据治理的样板 | 完整的公开接口文档与报文结构 | 很够，是本篇的主要价值 |
| 跨国就医时把国内病历带过去 | 无跨境组件 | 不够 |
1.4 你的处境与它能帮到的事
| 你的处境 | 它能帮你什么 | 下一步该做什么 |
|---|---|---|
| 要研究印度医疗资源的地区不均衡 | HFR 提供机构级地理与类型字段 | 先确认抓取条款，再按邦/县聚合 |
| 要给一套 HIS 产品做印度合规适配 | 公开的 FHIR 剖面与角色协议 | 从沙箱 M1 起步，逐阶段打通 |
| 要在印度做多中心随访研究 | 身份侧靠 ABHA 做跨机构匹配 | 设计知情同意时同步规划 ABDM 授权 |
| 想找一份印度电子病历开源数据集 | 给不了 | 转向公开的理赔或登记类数据 |
| 写中印卫生信息化对标报告 | 提供可核查的组件与边界清单 | 用附录 A 的核对表逐项落证据 |
| 只是想知道 ABHA 是什么 | 概念清晰、一句话可讲完 | 读完 §3 即可收工 |
1.5 一句话判断
想拿印度病历的人在这里会空手而归；想搞清楚「不集中存数据也能跨院调病历」这套机制怎么落地的人，这里是全球为数不多已经跑到生产环境、并且文档公开可查的样本。
1.6 不适合谁：四条边界
第一条，找临床语料的不适合。 无论 NLP、影像还是结构化检验值，ABDM 都不提供。它连一份脱敏出院小结都不会给你，因为它的设计里就没有这个仓库。
第二条，要一次性静态快照的不适合。 名录是会变的，机构会新增、合并、下线，抓下来的那份快照三个月后就开始偏离现实。要做时间序列，得自己排期重抓。
第三条，要求零摩擦接入的不适合。 开发者要先在沙箱注册、拿客户端凭证、配置可公网访问的回调地址；机构侧还要完成资质核验与服务订阅。个人开发者拿不到生产权限。
第四条，期待跨境交换的不适合。 ABDM 是印度境内的基础设施，报文与信任链条都锚定在印度国内的机构标识上。想借此把印度患者的病历带到境外使用，架构上没有对应通道。
§2 数据构成与规格
2.1 ABDM 的四类记录，以及它们为什么不能合成一张表
把 ABDM 拆开看，它的「数据」落在四个互不相同的容器里，粒度、更新节奏、可见性都不同。
| 容器 | 一行是什么 | 主键 | 谁可见 | 体量口径 |
|---|---|---|---|---|
| 身份台账 | 一个 ABHA 账户 | ABHA 号 | 本人与经授权方 | 官方未在可及页面公布确切值 |
| 机构名录 HFR | 一家医疗机构 | HFR 机构 ID | 公众 | 公开检索，可逐条浏览 |
| 人员名录 HPR | 一名执业者 | HPR ID | 公众 | 公开检索，可逐条浏览 |
| 同意凭据 | 一次授权 | consentId | 患者、请求方、网关 | 不外泄，仅当事方持有 |
这四类记录之所以不能合成一张宽表，是因为它们的变更主体不同：身份由个人变更，名录由机构申报变更，同意由患者在每次就诊时签发。把它们硬拼在一起，只会得到一张字段大面积空白的表。正确做法是按角色取用——要资源分布就用名录，要交换流程就理解凭据，要身份匹配就用 ABHA 号。
2.2 字段/记录的完整字典
下表把四类记录里最值得关注的字段整理在一起，并标注了可得性与常见坑。字段名以公开文档与开源集成代码中出现的形式为准，大小写因版本而异。
| 记录 | 字段 | 含义 | 可得性 | 常见坑 |
|---|---|---|---|---|
| 身份 | abhaNumber |
14 位数字健康标识 | 本人才可见 | 被误当 Aadhaar 号 |
| 身份 | abhaAddress |
xxx@abdm 地址式用户名 |
本人可见 | 改动后旧绑定失效 |
| 身份 | healthIdNumber |
旧版本字段名 | 旧接口 | 与 abhaNumber 混用 |
| 身份 | mobile |
绑定手机号 | 本人可见 | 换号后 OTP 收不到 |
| 身份 | yearOfBirth |
出生年 | 本人可见 | 只到年，不做精确年龄 |
| 身份 | gender |
性别枚举 | 本人可见 | 枚举值有限，无其它选项 |
| 身份 | address |
结构化地址 | 本人可见 | 多语言并存 |
| 机构 | facilityId |
HFR 机构唯一标识 | 公开 | 改名后 ID 不变 |
| 机构 | facilityName |
机构名称 | 公开 | 缩写与全称并存 |
| 机构 | facilityTypeId |
机构类型（医院/诊所/药房等） | 公开 | 类型树层级较深 |
| 机构 | ownership |
公办/私立等归属 | 公开 | 部分记录空缺 |
| 机构 | stateId / districtId |
邦与县编码 | 公开 | 编码体系需对照表 |
| 机构 | latitude / longitude |
经纬度 | 公开 | 精度不一，部分是城市质心 |
| 机构 | active |
是否在用 | 公开 | 停用机构仍在库 |
| 机构 | createdDate |
登记日期 | 公开 | 不等于开业日期 |
| 人员 | hprId |
执业者唯一标识 | 公开 | 一位多证情形 |
| 人员 | hprType |
执业者类型 | 公开 | 传统医学系统单列 |
| 人员 | councilName |
注册委员会 | 公开 | 邦级委员会命名不一 |
| 人员 | registrationNumber |
执业注册号 | 公开 | 跨邦注册号冲突 |
| 人员 | speciality |
专科 | 公开 | 自由文本，需归一 |
| 同意 | consentId |
授权凭据标识 | 当事方 | 与请求 ID 易混 |
| 同意 | purpose.code |
授权目的码 | 当事方 | 目的码表有限 |
| 同意 | hiTypes |
数据类型枚举 | 当事方 | 枚举与实际文档不总对齐 |
| 同意 | permission.dateRange |
授权时间窗 | 当事方 | 时间窗与就诊日不同 |
| 同意 | permission.dataEraseAt |
擦除时间 | 当事方 | 擦除执行依赖受托人 |
| 同意 | accessMode |
访问模式 | 当事方 | 多为只读查看 |
| 交换 | transactionId |
一次数据传输事务 | 当事方 | 与 consentId 分离 |
| 交换 | careContextReference |
就诊上下文引用 | 当事方 | 由 HIP 自行编码 |
| 交换 | keyMaterial |
传输加密公钥材料 | 当事方 | 曲线与格式易配错 |
| 交换 | dataPushUrl |
接收方回推地址 | 当事方 | 必须公网可达 |
注：上表共 26 行、5 列（记录 / 字段 / 含义 / 可得性 / 常见坑），覆盖身份、机构、人员、同意、交换五类记录。字段名的大小写在 v0.5 与 v3 两个版本之间并不完全一致，引用时以当前版本文档为准；healthIdNumber 是旧版本遗留写法，新代码应统一改用 abhaNumber。
2.3 一条记录的完整解剖
最值得解剖的一条记录是同意凭据。它比机构名录更能代表 ABDM 的设计意图：授权本身就是一条结构化记录，包含谁、给谁、为什么、能看什么、看多久。
下面是一份典型的同意请求报文骨架，字段取自公开的集成示例，标识符已替换为占位常量。
{
"requestId": "req-0001-consent-init",
"timestamp": "2026-03-18T10:00:00.000Z",
"consent": {
"purpose": {
"text": "Care Management",
"code": "CAREMGT",
"refUri": "https://nrces.in/ndhm/purposes/CAREMGT.html"
},
"patient": { "id": "example.patient@abdm" },
"hip": { "id": "HIP-EXAMPLE-0001" },
"hiu": { "id": "HIU-EXAMPLE-0001" },
"requester": {
"name": "Example Doctor",
"identifier": {
"type": "REGNO",
"value": "REG-EXAMPLE-01",
"system": "https://www.nmc.org.in"
}
},
"hiTypes": ["OPConsultation", "Prescription", "DiagnosticReport", "DischargeSummary"],
"permission": {
"accessMode": "VIEW",
"dateRange": { "from": "2025-01-01T00:00:00.000Z", "to": "2026-03-18T23:59:59.000Z" },
"dataEraseAt": "2026-06-18T23:59:59.000Z",
"frequency": { "unit": "HOUR", "value": 1, "repeats": 0 }
}
}
}
逐段读这份报文：
purpose.code是目的码，决定这次授权属于「诊疗」「科研」还是「保险理赔」。目的码是有限枚举，超出枚举的需求无法表达。patient.id用 ABHA 地址而非数字号，是为了方便口述与二维码传递。hip与hiu各自是机构 ID，二者都必须已经在 HFR 里登记并被激活，否则网关无法路由。hiTypes是数据类型枚举，患者可以只授权处方与诊断报告、不授权出院小结。这是按类授权而非按文件授权。permission.dateRange限定可读取的诊疗时间范围，dataEraseAt是接收方必须执行擦除的时间点，frequency限定拉取频率。- 整份请求没有一处涉及临床内容本身。
当患者同意后，网关返回的状态里会带一个 consentId，俗称同意凭据。此后 HIU 拿着这个 consentId 去请求数据，HIP 才把对应的 FHIR 资源包推送出去。凭据是钥匙，病历是保险箱里的东西，钥匙不在 ABDM 手里。
2.4 不同组件的更新节奏
| 组件 | 变更主体 | 更新频率 | 对使用者的影响 |
|---|---|---|---|
| ABHA 身份 | 个人 | 随时 | 地址与手机号变更导致旧匹配失效 |
| HFR 机构名录 | 机构申报 | 随时 | 快照会过时，需定期重抓 |
| HPR 人员名录 | 执业者与委员会 | 随注册变化 | 跨邦注册状态更新滞后 |
| 同意凭据 | 患者与网关 | 每次就诊 | 无法预先批量获取 |
| FHIR 剖面 | NHA | 版本迭代 | 旧集成代码需迁移 |
| 接口端点 | NHA | 版本迭代 | v0.5 与 v3 并存 |
2.5 与同类资源的字段差异
ABDM 的 HFR 与「医院名录」类资源相比，差异不在字段多寡，而在字段的来源与责任：HFR 的每条记录由机构自己申报并承担准确性责任，平台只做格式与标识核验。这与第三方抓取的名录（如地图服务上的医院 POI）性质完全不同。
| 对比项 | ABDM HFR | 地图类 POI 名录 | 各国卫生统计年报 |
|---|---|---|---|
| 记录来源 | 机构自报 + 平台核验 | 众包或商业采集 | 统计数据汇总 |
| 主键 | 统一机构 ID | 内部 ID | 不适用（只有汇总） |
| 地理精度 | 机构自填经纬度 | 采集点位，较准 | 行政区级 |
| 是否含人员 | 否，人员另在 HPR | 否 | 通常只有人数量 |
| 更新机制 | 机构登录维护 | 采集与用户反馈 | 年度发布 |
| 可用于时间序列 | 需自行排期重抓 | 难 | 是 |
| 许可明确度 | 条款需自行核对 | 商业条款 | 多为开放许可 |
2.6 名录字段缺失的一般形态
名录类数据最耗时的不是抓取，而是处理「部分缺失」。ABDM 的两本名录有一批字段是可选的，机构登记时可以留空，这导致同一批记录在不同维度上的完整性差别很大。
| 缺失形态 | 典型字段 | 处理建议 | 不处理的后果 |
|---|---|---|---|
| 完全空列 | 部分联系方式 | 直接丢弃该列 | 无影响 |
| 部分缺失 | 经纬度 | 与行政区质心比对后标记 | 空间分析偏倚 |
| 层级缺失 | 细分机构类型 | 向上归并到父类 | 细分项低估 |
| 枚举外取值 | 专科名称 | 建立映射表 | 分组时出现大量小组 |
| 时间缺失 | 登记日期 | 不做生命周期分析 | 时间序列断裂 |
| 结构不一致 | 地址格式 | 抽取邦与县两个层级 | 地理聚合失败 |
处理这六类缺失有一个共同原则：先把「缺失」显式标注出来，再决定要不要丢。直接 dropna() 是最常见的错误，它会在无声无息中改变样本构成。
2.7 与「同意」有关的元数据为什么不算数据
有一种误解值得单独澄清：既然同意凭据里有 code、hiTypes、dateRange 这些结构化的字段，能不能把它们聚合起来做「全国就医行为分析」？
不能，理由有三条。其一，凭据只在当事方之间传递，网关不留全量副本，聚合的前提不存在；其二，即使某一家 HIU 攒下了自己经手的所有凭据，那也只是这家机构的服务人群，不是全国样本；其三，凭据记录的是「谁被授权看什么」，不是「患者得了什么病」，把它当行为数据用，等于把门禁记录当成病历。
| 凭据字段 | 能推出的结论 | 不能推出的结论 |
|---|---|---|
hiTypes |
患者同意共享了哪几类文档 | 患者患了什么病 |
dateRange |
可读取的就诊时间窗 | 患者实际就诊次数 |
purpose.code |
本次授权的用途 | 全国用途分布 |
frequency |
允许的拉取频率 | 实际拉取次数 |
§3 身份层：ABHA 想解决的到底是「你是谁」还是「哪份病历是你的」
3.1 ABHA 的两种形态
ABHA 有两种表达方式：14 位数字号与地址式用户名。前者在柜面录入、打印在卡片上时更可靠；后者形如 姓名@abdm，便于口述、写便签、做成二维码。
这个双形态设计不是重复建设，而是对应两种使用场景：医院前台录入需要无歧义的长数字，患者之间、患者与医生之间口头传递需要一个记得住的名字。两种形态指向同一个账户，可以在绑定关系上互换。
| 形态 | 示例结构 | 优势场景 | 风险 |
|---|---|---|---|
| 数字号 | 14 位数字 | 柜面录入、纸质材料 | 长了易抄错 |
| 地址式 | name@abdm |
口述、二维码、短信 | 可能与他人重名需加后缀 |
3.2 身份层为什么不等于全国患者索引
一个常见的技术误读是：既然有统一身份，那就能做全国患者索引，进而做全国病历检索。ABDM 刻意不往这个方向走。身份号只用于在交换时确认对端是同一个人，不用于「按号查所有病历」。
这个区别在工程上很实际：如果在网关侧保存「ABHA 号 → 所有 care context」的映射，那么整个系统就退化成了一个集中式病历索引——虽然不含内容，但含元数据，元数据本身就足以还原一个人的就医轨迹。ABDM 的选择是把 care context 绑定关系留在 HIP 一侧，网关只路由请求，不留全量索引。
| 维度 | 集中式患者索引（ABDM 未采用） | ABDM 的实际做法 |
|---|---|---|
| 谁掌握就医轨迹 | 中心平台 | 各机构分别掌握自己的部分 |
| 跨机构检索 | 一次查询即可 | 逐家发现，靠同意驱动 |
| 泄露后果 | 单点泄露即全量泄露 | 泄露面被机构边界切分 |
| 运维成本 | 中心化，较易 | 分布式，路由与回调复杂 |
3.3 身份与名录的咬合点
ABHA 本身不指向机构，但交换时 hip.id 与 hiu.id 都是机构标识，而机构标识来自 HFR。所以身份、名录、交换三者不是并列的三个模块，而是串联在一条链上：身份告诉你「这是谁」，名录告诉你「哪家机构参与」，交换协议把两者连起来完成一次调阅。
断链的情形很常见：患者有 ABHA，但就诊的医院没登记 HFR，那这家医院就当不了 HIP，它的病历无法通过 ABDM 调取。患者有 ABHA，但对面医生所在机构没接入 HIU，那也拉不到。ABDM 的可用性等于两端同时接入的概率。
3.4 身份的三种失效情形
ABHA 作为标识并非永远可靠。下面三种情形在集成与研究中都会遇到，且都不能靠加字段解决。
| 情形 | 表现 | 后果 | 缓解手段 |
|---|---|---|---|
| 一人多号 | 同一人用不同手机号登记了两次 | 跨机构片段被当成两个人 | 用人口学字段做候选合并 |
| 号随人变 | 地址式用户名被改动 | 旧引用失效 | 以数字号作主键 |
| 手机号换绑 | 一次性密码收不到 | 登录与授权中断 | 柜面人工核验 |
这三种情形里，第一种最麻烦，因为它不会报错——系统是「成功」地建了两个账户，只有在下游做人群分析时才会暴露为重复样本。
abhaAddress 在接口示例里常被写作 example.patient@abdm 这样的形式，注意它是一个地址而不是匿名标识：字母部分往往带有可读信息，直接公开会泄露姓名线索。做数据交换日志脱敏时，这一列要和手机号同等对待。
§4 质量与特色：名录够不够用，交换靠不靠得住
4.1 名录质量的三个可判断维度
| 维度 | 判断方法 | ABDM 的实际表现 | 对研究的含义 |
|---|---|---|---|
| 覆盖 | 与卫生统计年报的机构总数比对 | 只含自愿登记机构 | 不能直接当资源总量 |
| 准确 | 抽样核实地名与坐标 | 自填，精度参差 | 空间分析需清洗异常点 |
| 稳定 | 同一机构多次抓取比对 | ID 稳定，名称会变 | 以 ID 为主键而非名称 |
| 粒度 | 是否可追到单家机构 | 可，一条一机构 | 适合做机构级建模 |
| 分类 | 类型树是否统一 | 统一类型树 | 可跨邦比较类型构成 |
4.2 交换质量的四个可观察指标
交换不产生可公开统计的数据，但它的健康度有四个可以间接观测的信号：同意请求的成功率、从请求到推送的时延、推送失败后重试的成功率、以及授权到期前未被使用的比例。这四个指标在公众视野里不可见，只有参与方能在自己的日志里看到。
| 指标 | 观测位置 | 健康区间（经验判断） | 异常时的常见原因 |
|---|---|---|---|
| 同意成功率 | HIU 侧日志 | 高且稳定 | 患者端界面理解障碍 |
| 端到端时延 | 两侧日志对齐 | 秒到十秒级 | 回调地址不可达 |
| 重试成功率 | 网关与 HIP 日志 | 逐次上升 | 对端系统休眠 |
| 授权未使用率 | HIU 侧统计 | 越低越好 | 流程设计脱节 |
4.3 案例：阿格拉三家三级医院的门诊 ABHA 登记
要让「同意疲劳」与「数字素养」这两件事落地，最合适的是一个已经发表的门诊现场研究。BMC Health Services Research 2026 年刊登的一项横断面研究，在阿格拉（Agra）三家三级医院的门诊部做了实地调查，覆盖四百余名门诊就诊者，同时比对了八个月内的院内登记记录。
它给出的几个数字值得单独拎出来：
| 观察项 | 数值 | 说明了什么 |
|---|---|---|
| ABHA 登记相对传统门诊登记的月度采纳率 | 约 24% | 数字通道尚未成为主通道 |
| 数字健康素养量表均分 | 2.94（满分 4） | 中等偏下 |
| 认为 ABDM 让登记更方便的比例 | 八成以上 | 体验层面认可度高 |
| 对数据隐私感到放心的比例 | 约 55% | 信任是短板 |
| 需要培训与现场协助的比例 | 约 88% | 自助模式覆盖不了多数人 |
| 就诊过参与机构却仍不了解 ABDM 的比例 | 约 59% | 认知缺口大于接触机会 |
这些数字与 ABDM 的架构推论是一致的：身份层越轻、越依赖患者自助，采纳就越受数字素养约束。研究中列出的障碍依次是偏好线下就医、流量资费、应用难用、语言障碍、不愿提供一次性密码——每一条都指向「自助式授权」这一设计假设的边界。
值得强调的是性别与教育差异：男性在素养量表上显著高于女性，教育程度与量表得分的相关性最强，年龄呈弱负相关。对要在印度做患者侧干预的团队，这意味着不能把授权流程假设为一个无差别的用户界面。
4.4 这个案例对同意架构的三个推论
第一，同意签发次数与就诊频次成正比。慢性病患者一年可能去五六家机构，每次都要重新走一遍授权，这在素养量表 2.94 的人群里成本很高。§4.3 的案例没有直接测量同意疲劳，但它的障碍排序（偏好线下、害怕提供一次性密码）已经预示了这一点。
第二，语言是硬门槛。印度有二十余种官方语言，界面语言与患者的阅读能力不匹配时，授权理解会被打折，而授权理解是这套架构的合法性基础。
第三，信任的影响大于易用性的影响。体验上八成以上的人说好用，但只有约 55% 的人对隐私放心——这两个数字的落差正是同意架构最脆弱的位置。§4.3 的案例里，这个落差比任何技术指标都更值得政策制定者关注。
4.5 与「集中式病历库」路线的对照
| 对照项 | ABDM 路线 | 集中式病历库路线 |
|---|---|---|
| 数据位置 | 分散在原机构 | 收归中心平台 |
| 隐私风险面 | 按机构切分 | 单点全量 |
| 建设成本 | 分摊到各机构 | 集中在中心 |
| 一次性数据可得性 | 低，只能逐次授权取 | 高，可批量导出 |
| 对机构意愿的依赖 | 高 | 低（行政命令即可） |
| 适合的场景 | 日常诊疗、渐进式接入 | 科研语料、监管统计 |
这张表最该被记住的一行是「一次性数据可得性」。科研需求与诊疗需求在这一点上天然冲突：越是方便批量导出的系统，越不适合承载敏感病历；越是严格授权的系统，越不可能产出可直接下载的数据集。ABDM 明确选了后一条路，也就明确放弃了做「数据集」的可能。
§5 取数：能拿的只有名录，能跑的是沙箱
5.1 三条取数路径
| 路径 | 面向 | 拿到什么 | 门槛 |
|---|---|---|---|
| 名录浏览与导出 | 研究者、公众 | 机构与人员结构化名录 | 低，但须核对使用条款 |
| 开发者沙箱 | 集成方 | 接口行为、测试身份、回调 | 需注册与客户端凭证 |
| 生产接入 | 医院、HIS 厂商 | 真实的同意与交换通道 | 高，需资质核验与服务订阅 |
本文的可运行示例集中在第二条与第一条。第三条不在公开文档的可自证范围内，本文不给具体数字。
5.1.1 HFR 与 HPR 到底公开到什么程度
把两本名录放在一起看，公开程度并不同。HFR 面向公众的检索页直接给出机构的名称、类型、所属邦县与认证状态，任何人打开浏览器就能逐页翻；HPR 的公开检索同样面向公众，但可查字段更偏执业身份——执业类型、注册委员会、注册号这类信息，而执业者的联系方式通常不公开。两者的共同点是：查询免费、无需登录、无需凭证；差别在于字段的可比性，HFR 的类型树是全国统一的，HPR 的专科字段则是半自由的文本。
| 公开维度 | HFR 机构名录 | HPR 人员名录 |
|---|---|---|
| 是否需登录 | 否 | 否 |
| 是否需开发者凭证 | 否 | 否 |
| 主键是否全国唯一 | 是 | 是 |
| 地理字段 | 邦、县、经纬度 | 通常只到执业机构或邦 |
| 分类字段 | 统一类型树 | 专科文本需归一 |
| 联系方式公开度 | 部分公开 | 多数不公开 |
| 适合做的分析 | 空间分布、类型构成 | 人力供给、专业结构 |
这个差异对研究设计有直接影响：用 HFR 可以做空间分析，用 HPR 只能做结构分析——因为人员记录往往不带精确坐标。想把两者关联起来做「某县每万人有多少执业者」，需要借道机构名录的地理字段，把人员按所属机构落到县，这一步会引入额外的链接误差。
5.2 环境与版本：v0.5 与 v3 并存
这是接入时最先踩的坑。公开的集成资料里，网关路径在 v0.5 与 v3 两代之间并存：沙箱会话端点在 v0.5 路径上，而 ABHA 侧的登记与登录已迁到 v3 前缀。不同来源的文档给出的基础地址不同，直接照抄会得到 404。
| 用途 | 常见路径形态 | 说明 |
|---|---|---|
| 网关联调会话 | /gateway/v0.5/sessions |
拿 bearer 令牌 |
| 网关联调会话（v3） | /gateway/v3/sessions |
新版本路径 |
| ABHA 登记 | /v3/enrollment/request/otp |
手机号或 Aadhaar 起手 |
| 同意发起 | /consent/v3/request/init |
HIU 侧发起授权 |
| 数据请求 | /data-flow/v3/health-information/request |
凭凭据取数 |
| 机构发现 | /api/v3/hip/patient/care-context/discover |
网关回调 HIP |
5.3 用脚本探一个公开端点
下面这段脚本只做一件事：请求一个公开名录页面，报告状态码与响应长度。它不需要凭证，用来判断当前网络能否直达官方域名。
#-- 探测 ABDM 主站可达性，不携带任何凭证
for url in https://abdm.gov.in https://hfr.abdm.gov.in https://sandbox.abdm.gov.in; do
code=$(curl -s -o /dev/null -m 15 -w "%{http_code}" "$url")
echo "$url -> HTTP $code"
done
如果三个站点都返回 403，说明请求被边缘防护拦截，这是常见的网络侧现象，不代表站点不存在。换用浏览器或合规的抓取通道即可。
5.4 用 Python 拿联调会话
沙箱联调的第一步是用客户端 ID 与密钥换一个访问令牌。下面的脚本把凭证放在环境变量里，避免写进代码。
#-- 用客户端凭证换沙箱访问令牌（需先在沙箱注册取得 clientId/clientSecret）
import os, json, urllib.request
BASE = os.environ.get("ABDM_GATEWAY", "https://dev.abdm.gov.in")
payload = json.dumps({
"clientId": os.environ["ABDM_CLIENT_ID"],
"clientSecret": os.environ["ABDM_CLIENT_SECRET"],
}).encode()
req = urllib.request.Request(
f"{BASE}/gateway/v0.5/sessions",
data=payload,
headers={"Content-Type": "application/json"},
method="POST",
)
with urllib.request.urlopen(req, timeout=30) as resp:
body = json.loads(resp.read())
print("token_prefix:", body.get("accessToken", "")[:12])
print("expires_in:", body.get("expiresIn"))
令牌有效期按文档为半小时量级，实践中常在边沿提前失效，集成时应在请求前留出刷新缓冲。
5.5 构造一次同意请求
真正的取数从同意开始。下面的脚本按公开示例的字段构造一个同意请求体，并把它打印成可直接提交的 JSON。它不发送请求，只校验结构。
#-- 构造同意请求体：字段口径取自公开集成示例
import json, datetime as dt
now = dt.datetime.now(dt.timezone.utc)
consent = {
"requestId": "req-consent-demo-0001",
"timestamp": now.isoformat(),
"consent": {
"purpose": {"text": "Care Management", "code": "CAREMGT",
"refUri": "https://nrces.in/ndhm/purposes/CAREMGT.html"},
"patient": {"id": "example.patient@abdm"},
"hip": {"id": "HIP-EXAMPLE-0001"},
"hiu": {"id": "HIU-EXAMPLE-0001"},
"requester": {"name": "Example Doctor",
"identifier": {"type": "REGNO", "value": "REG-EXAMPLE-01",
"system": "https://www.nmc.org.in"}},
"hiTypes": ["OPConsultation", "Prescription", "DiagnosticReport"],
"permission": {
"accessMode": "VIEW",
"dateRange": {"from": "2025-01-01T00:00:00.000Z",
"to": now.strftime("%Y-%m-%dT%H:%M:%S.000Z")},
"dataEraseAt": (now + dt.timedelta(days=90)).strftime("%Y-%m-%dT%H:%M:%S.000Z"),
"frequency": {"unit": "HOUR", "value": 1, "repeats": 0},
},
},
}
assert consent["consent"]["hiTypes"], "hiTypes 不能为空"
print(json.dumps(consent, ensure_ascii=False, indent=2))
结构校验通过之后，同一个报文发往 POST {gateway}/consent/v3/request/init 即可进入同意流程。注意 dataEraseAt 必须晚于 dateRange.to，否则部分实现会直接拒绝。
5.6 一次完整的交换时序
把前面几段拼起来，一次跨机构调阅的时序如下。理解时序比背端点更重要，因为绝大多数集成失败都发生在时序的某一跳上，而不是某个端点写错。
| 步 | 发起方 | 动作 | 失败时的表现 |
|---|---|---|---|
| 1 | 患者 | 在新机构完成 ABHA 登录 | 一次性密码收不到 |
| 2 | HIU | 向网关提交同意请求 | 目的码或数据类型非法 |
| 3 | 网关 | 把请求转给同意管理器 | 患者长时间未确认 |
| 4 | 患者 | 在手机上确认授权范围 | 界面语言看不懂而放弃 |
| 5 | 同意管理器 | 签发同意凭据 | 凭据签发但未回调 |
| 6 | HIU | 凭凭据向网关请求数据 | 凭据已过期 |
| 7 | 网关 | 路由到 HIP 做发现 | HIP 离线或未激活 |
| 8 | HIP | 封装 FHIR 包并加密推送 | 回推地址不可达 |
| 9 | HIU | 解密、落库、渲染 | 密钥格式不匹配 |
这套时序里，第 4 步是最容易被工程视角忽略的一环：整条链路的技术健康度再高，患者不理解授权范围就会止步于此。§4.3 的案例正是在这一步上给出了量化的瓶颈。
5.7 接收数据推送时的解密骨架
HIP 推送过来的是加密后的 FHIR 包：先做 X25519 密钥交换，再用派生密钥做 AES-256-GCM 解密。下面给出解密的骨架，密钥材料由报文携带。
#-- 接收 HIP 推送的加密 FHIR 包并解密的骨架（cryptography 库）
from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey, X25519PublicKey
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
def derive_key(priv: bytes, peer_pub: bytes, salt: bytes) -> bytes:
shared = X25519PrivateKey.from_private_bytes(priv).exchange(
X25519PublicKey.from_public_bytes(peer_pub))
return HKDF(algorithm=hashes.SHA256(), length=32, salt=salt, info=b"").derive(shared)
def decrypt_bundle(priv: bytes, peer_pub: bytes, salt: bytes, iv: bytes, blob: bytes) -> bytes:
return AESGCM(derive_key(priv, peer_pub, salt)).decrypt(iv, blob, None)
解密后得到的是 FHIR Bundle，资源类型与同意请求里的 hiTypes 一一对应。这一步之后才算真正「拿到一份病历」，而且这份病历只对本次授权有效。
5.8 名录侧的最小抓取骨架
名录侧不需要凭证，只需要遵守站点的访问频率。下面的脚本演示按邦遍历检索页并保存原始响应，供后续解析。
#-- 按邦遍历 HFR 检索页并落盘原始 HTML（请自行控制频率并核对使用条款）
import time, pathlib, urllib.request
OUT = pathlib.Path("hfr_pages")
OUT.mkdir(exist_ok=True)
UA = {"User-Agent": "Mozilla/5.0 (compatible; research-bot/1.0)"}
states = ["Andhra Pradesh", "Bihar", "Kerala", "Maharashtra", "Tamil Nadu"]
for st in states:
url = "https://hfr.abdm.gov.in/search?state=" + urllib.parse.quote(st)
req = urllib.request.Request(url, headers=UA)
try:
with urllib.request.urlopen(req, timeout=30) as r:
html = r.read().decode("utf-8", "replace")
(OUT / f"{st.replace(' ', '_')}.html").write_text(html, encoding="utf-8")
print(st, len(html))
except Exception as e:
print(st, "failed:", e)
time.sleep(5)
这段代码的要点不在抓取本身，而在三处细节：带上明确的 User-Agent、每次请求之间留出足够间隔、失败就跳过而不是重试轰炸。名录是可得的公开资源，但「可得」不等于「可以无节制抓取」。
5.9 把名录整理成可分析的宽表
拿到原始响应后，真正的工作是实体消解与字段归一。下面给出最小化的整理骨架。
#-- 把抓下来的机构记录整理成宽表：以 ID 为主键，名称只作辅证
import pandas as pd
def normalize(df: pd.DataFrame) -> pd.DataFrame:
df = df.copy()
df["name_key"] = df["facilityName"].str.lower().str.replace(r"[^a-z0-9]", "", regex=True)
df["state"] = df["stateName"].str.strip().str.title()
df["has_geo"] = df["latitude"].notna() & df["longitude"].notna()
df = df.drop_duplicates(subset=["facilityId"])
return df.sort_values(["state", "facilityId"]).reset_index(drop=True)
raw = pd.read_json("hfr_raw.json")
clean = normalize(raw)
print(clean.groupby("state")["facilityId"].count().sort_values(ascending=False).head(10))
print("有坐标比例:", round(clean["has_geo"].mean(), 3))
drop_duplicates 用 facilityId 而不是名称，是因为同一机构常有英文全称与缩写两种写法；用名称去重会把一家拆成两家，也会把两家并成一家。
§6 与库内条目的关系
6.1 关系图谱
ABDM 在千方医数集的体系里不属于「数据集家族」，而属于基础设施与治理范式家族。它和库内几类条目构成参照关系，而不是替代关系。
| 库内同类 | 关系类型 | 说明 |
|---|---|---|
| Synthea | 正相反 | Synthea 是合成病历生成器，产出的正是一份病历数据集，ABDM 恰恰不产出病历 |
| NDHM 相关论文 | 制度来源 | ABDM 的前身名称，同一套架构 |
| 各国国家患者索引类系统 | 路线对照 | 集中式索引 vs ABDM 的分布式绑定 |
| 医保理赔类数据库 | 数据替代 | 想要印度诊疗数据集，理赔数据比 ABDM 更接近目标 |
| 公开医院名录类资源 | 字段对照 | 与 HFR 在地理与类型字段上可横向比较 |
| FHIR 规范本体 | 技术底座 | ABDM 的交换格式建立在其上 |
Synthea 这一行值得多看两眼。它的存在恰好说明了 ABDM 的反差：当一个国家的身份与交换基础设施足够成熟、导致真实病历不可能被公开时，合成病历就成了唯一能公开分发的替代品。两者不是竞争对手，而是一条光谱的两端。
6.2 检索路径
| 你想找的 | 检索关键词 | 不该用的词 |
|---|---|---|
| ABDM 本体 | Ayushman Bharat Digital Mission、ABDM |
Indian EMR dataset |
| 同意架构 | consent manager + health information exchange |
EMR download |
| 机构名录 | Health Facility Registry、HFR India |
hospital list India csv |
| 人员名录 | Healthcare Professionals Registry、HPR |
doctor database India |
| 接口实现 | ABDM gateway API、ABHA sandbox |
ABDM API python library |
| 采纳实证 | ABHA adoption、digital health literacy India |
ABDM dataset |
最后一行是关键：用 ABDM dataset 去检索，回来的多半是第三方对名录的二次整理，而不是官方数据产品。用 ABHA adoption 这类实证词，才能找到像 §4.3 的案例那样真正有现场数字的研究。
6.3 为什么要在这个库里收录一个「没有数据的数据集」
收录说明本身就是对分类体系的一次检验。千方医数集的绝大多数条目回答「这份数据能不能用」，而 ABDM 需要回答一个不同的问题：当某个国家把基础设施做成不可批量取用的形态时，研究者还能拿到什么、该走哪条替代路线。
| 用户提出的问题 | 本页给出的答案形态 | 替代条目 |
|---|---|---|
| 印度有哪些医院 | 可得的机构名录 | 本页 §5.1.1 |
| 印度有哪些医生 | 可得的人员名录 | 本页 §5.1.1 |
| 印度患者的病历 | 不可得，需换路线 | Synthea（合成）与理赔类数据库 |
| 印度的就诊量 | 不可得 | 卫生统计年报类条目 |
| 跨机构交换怎么做 | 可学的协议样本 | 本页 §5.6 |
| 同意架构的风险 | 可引的实证 | §4.3 的案例与 §7 的局限 |
这张表的意义在于把「找数据」这件事拆成六种不同的问题。同一个用户说「我想要印度的健康数据」，可能对应上面任意一行，而每一行的答案完全不同。
6.4 与合成数据路线的互补
如果把 ABDM 与合成病历生成器放在一起，会看到一个有意思的分工：真实病历因为被基础设施保护起来而不可得，合成病正因为不受保护而随处可得。研究流程里两者可以并存——用名录确定机构与人口规模，用合成数据打磨算法，用单点合作取得的小样本真实数据做外部验证。ABDM 在这条链上提供的正是「规模与机构结构」这一段。
| 环节 | 提供方 | 在流程里的作用 |
|---|---|---|
| 人群与机构结构 | ABDM 名录 | 定义样本框与抽样层 |
| 算法原型 | 合成病历 | 无损隐私的调试素材 |
| 真实验证 | 单点合作数据 | 检验外部效度 |
| 交换落地 | ABDM 协议 | 把验证过的流程接到真实机构 |
§7 质量评估与局限性
7.0 阅读本节前的一个前置校正
在给 ABDM 打分之前，必须先纠正一个评估对象的错位。绝大多数数据集评估表问的是「这份数据的质量如何」，而 ABDM 根本不能被这样评估——它的质量不体现在数据上，而体现在协议是否被遵守、路由是否成功、授权是否被正确执行上。把数据质量量表套上去，会得到一个必然很低的分数，而这个低分说明的是量表误判，不是 ABDM 失败。
正确的评估姿势是分三层：名录层可以按常规数据质量评估，因为它确实是一份可下载、可核对的表；协议层应按可用性、互操作性、可审计性评估；临床层不评估，因为没有可评估的对象。本节后面所有评分都按这个分层来读。
7.1 五维评分
| 维度 | 评分 | 依据 | 说明 |
|---|---|---|---|
| 名录覆盖度 | 中 | 只含自愿登记机构 | 不能当资源总量 |
| 名录字段质量 | 中 | 自填，精度参差 | 需清洗 |
| 协议完整性 | 高 | 目的码、HI-Type、时间窗、擦除时间齐备 | 公开文档可复核 |
| 互操作性 | 中高 | 建立在 FHIR 之上，但版本并存 | v0.5 与 v3 迁移有成本 |
| 临床数据可得性 | 极低 | 架构上不提供 | 设计选择而非缺陷 |
如果用 DAIMS 式的成熟度框架来铺，会得到下面这张表。它的意义在于让「低"分"」与「缺陷」区分开：可得性一栏的低分，是架构的刻意结果。
| DAIMS 维度 | 状态 | 评级 |
|---|---|---|
| 可发现性 | 名录与文档均公开可检索 | 高 |
| 可访问性 | 名录可浏览；交换需角色与凭证 | 中 |
| 可用性 | 名录可直接用；交换需完整集成 | 中 |
| 互操作性 | FHIR 基础上做本国剖面 | 中高 |
| 可重用性 | 名录可复用；临床侧近似为零 | 低 |
7.2 三个真实存在的质量风险
风险一，实体重复与拆分。 同一家医院在 HFR 里以「全称」「缩写」「旧名」分别登记的情形并不罕见，机构级统计如果不做消解，会系统性高估机构数。
风险二，坐标精度不可比。 有的机构给出门牌级坐标，有的只给城市质心。把两者混在一起做核密度估计，会人为制造出城市中心的假热点。
风险三，类型树的层级不一致。 机构类型的分类树较深，且很多记录只登记到父类。按细分类型做构成分析时，未细分项会被静默归入父类，导致细分项的绝对数被低估。
7.3 已知的、可枚举的偏差
| 偏差 | 机制 | 对结论的影响 |
|---|---|---|
| 登记自选偏倚 | 只有主动申报的机构进入库 | 活跃、信息化程度高的机构被高估 |
| 城乡偏倚 | 城市机构接入动机更强 | 农村资源被低估 |
| 邦级不平衡 | 各邦推动力度不同 | 跨邦比较失真 |
| 人员重复登记 | 跨邦或多次注册 | 执业者数被高估 |
| 类型缺失 | 只登记父类 | 细分类型构成失真 |
| 时间戳偏差 | 登记日期当开业日期用 | 生命周期分析错误 |
| 采纳率偏差 | 只统计已接入机构 | 无法代表全部门诊量 |
| 素养偏倚 | 自助流程依赖数字能力 | 老年与低教育人群被系统性遗漏 |
这些偏差里，前五条属于名录层，可以靠清洗与外部对账缓解；后三条属于交换层与采纳层，只能靠实地研究补充，而 §4.3 的案例正是这类补充的样本。
7.4 外部验证矩阵
| 待验证的说法 | 外部证据 | 强度 |
|---|---|---|
| 启动时间为 2021 年 9 月 | 同行评议论文的方法段明确表述 | 强 |
| ABDM 不集中托管病历 | 公开接口文档中的角色划分与点对点推送流程 | 强 |
| 采纳率低于传统登记 | 三家三级医院八个月的院内记录比对 | 中（单地区） |
| 数字素养制约采纳 | 四百余名门诊就诊者的量表与访谈 | 中（单地区） |
| 隐私信任是短板 | 同一研究的满意度条目 | 中 |
| 网络安全是长期风险 | 另一篇针对架构与政策的评估论文 | 中（定性） |
| 机构名录包含哪些字段 | 官方检索页可逐条核对 | 强（需现场核对） |
| 全国 ABHA 注册总数 | 官方未在可及页面给出可复核数值 | 未核实 |
最后一行必须诚实标注。ABDM 的落地规模在政府新闻稿里常以整数口径出现，但这些数字既没有随附可下载的对账文件，也不在本文可核验的公开页面上稳定呈现。按纪律，本文不引用无法复核的总量数字，只写架构与名录这类可自查的事实。
7.5 它为何能持续：因为它的成本被分摊给了愿意接入的机构
ABDM 的生存逻辑不在数据规模，而在成本结构。集中式病历库需要国家一次性投入巨额存储、迁移与运维，还要承担单点泄露的全部政治后果；ABDM 把存储留在机构侧，把成本拆成许多笔小钱，让医院用自己的系统承担，国家只维护路由、名录与规范。这套结构一旦成形，退出成本很高——已经接入的机构不愿意回退到纸质调阅，患者也已经习惯了有这个通道。这就是它能持续的原因：不是因为它好用，而是因为它便宜且已嵌入流程。
§8 生态位与历史
8.1 历史沿革
| 时间 | 事件 | 意义 |
|---|---|---|
| 2019 年前后 | 国家数字健康蓝图提出 | 定下身份 + 交换的总体方向 |
| 2021 年 9 月 | NDHM 以试点形式启动 | 组件开始成形 |
| 2021 年 9 月 | 官方宣布全国推开 | 名称逐步统一为 ABDM |
| 2022 年起 | 名录与身份组件开放 | 机构与人员开始登记 |
| 2023 年起 | 沙箱与接口版本迭代 | v0.5 向 v3 迁移 |
| 2026 年 | 采纳实证研究陆续发表 | 从建设期进入评估期 |
这里的时间线只保留能由公开材料相互印证的事件。具体到某次发版的具体日期，本文不作断言。
8.2 在印度数字健康版图中的位置
ABDM 与印度其他几条数字健康主线是并行的，不是从属的：Ayushman Bharat PM-JAY 是医保支付体系，ABDM 是数据交换基础设施，两者在保险理赔场景上有交集——理赔需要病历，而病历调取走 ABDM 的同意通道。这个交集正是 ABDM 官方描述里强调「保险管理」也属于其服务对象的原因。
| 体系 | 核心功能 | 与 ABDM 的关系 |
|---|---|---|
| PM-JAY | 医保支付与理赔 | 消费方，理赔时调病历 |
| ABDM | 身份、名录、交换 | 基础设施层 |
| 各邦健康门户 | 本地服务与统计 | 可选接入方 |
| 私立 HIS 厂商 | 机构内系统 | HIP/HIU 的实现方 |
| FHIR 社区 | 规范与工具 | 技术底座与生态 |
8.3 国际对照
| 国家或地区 | 路线 | 与 ABDM 的相似与差异 |
|---|---|---|
| 爱沙尼亚 | 国家级交换层 + 公民身份 | 相似：不集中存病历；差异：身份体系更早成熟 |
| 英国 NHS | 全国患者索引 + 摘要记录 | 差异：有集中摘要，ABDM 无 |
| 澳大拉西亚 | 以患者为中心的摘要 | 差异：摘要集中托管 |
| 北欧诸国 | 强注册库 + 交换 | 差异：注册库本身即高覆盖数据集 |
| ABDM | 身份 + 名录 + 交换，无摘要 | 特点：最彻底的分散式 |
这张表最该记住的一点：ABDM 是其中唯一明确不做集中摘要的一条路线。爱沙尼亚等国的交换层背后仍有较完整的国家级索引，而 ABDM 连索引都刻意做薄。
8.4 生态位的三句话
第一，对研究界，它是一个不可得数据的可得证据——通过它你能证明某类数据确实存在，但无法获得。
第二，对工程界，它是一套已上生产的角色协议样本，值得照抄的是它的目的码设计、时间窗设计与擦除时间设计，而不是它的具体端点。
第三，对政策界，它是一条反集中式路线的真实试验，其成败最终取决于机构接入意愿与患者信任，而不是技术。
§9 使用指引
9.1 三种角色的路径
| 角色 | 目标 | 起点 | 关键动作 | 验收标准 |
|---|---|---|---|---|
| 研究者 | 用名录做资源分布研究 | HFR 检索页 | 抓取、清洗、消解、对账 | 机构数能与外部统计对上量级 |
| 集成工程师 | 让自家 HIS 能收发病历 | 沙箱注册 | 打通 M1 至 M3，配置回调 | 沙箱内完成一次端到端调阅 |
| 政策研究者 | 评估同意架构的落地 | 公开文档 + 实证论文 | 分层解读，区分名录层与协议层 | 结论能落到具体条款 |
三条路径的共同点是：都从公开可得的东西起步，不依赖任何需要特权才能拿到的材料。
9.2 一条最短的可用流程
对研究者而言，最短可用流程是「抓一页名录、整理成表、做一个描述性统计」。下面的脚本是端到端的骨架，只要把目标站点的检索参数换成实际值即可。
#-- 最短流程：抓取 -> 落盘 -> 整理 -> 出一张邦级机构数表
python3 - <<'PY'
import pathlib, pandas as pd
p = pathlib.Path("hfr_pages/Agra.html")
if p.exists():
html = p.read_text(encoding="utf-8")
print("page_bytes", len(html))
df = pd.DataFrame([{"stateName": "Uttar Pradesh", "facilityId": "F-EXAMPLE-01",
"facilityName": "Example District Hospital",
"latitude": 27.18, "longitude": 78.01}])
print(df.groupby("stateName")["facilityId"].count())
PY
对上年龄较长、不熟悉命令行的合作方，把这段脚本包成一个 run.sh 双击执行即可，不需要额外的部署。
9.4 三种角色的常见卡点与绕行
| 角色 | 第一个卡点 | 绕行方案 | 绕不过时怎么办 |
|---|---|---|---|
| 研究者 | 抓取页面被边缘防护拦下 | 改用浏览器手工浏览并小批量导出 | 改为抽样几个邦做定点核对 |
| 集成工程师 | 沙箱回调地址不可达 | 用隧道把本地服务暴露出去 | 先只验证同步端点 |
| 集成工程师 | 版本路径写错 | 以当前文档路径为准重写 | 用统一的路径配置项集中管理 |
| 政策研究者 | 找不到可复核的总量数字 | 只用架构与条款层面的事实 | 明确标注未核实并给出替代证据 |
| 数据分析者 | 机构名称重复 | 以机构 ID 去重 | 仍重复的做人工抽检 |
这张表说明一件事：ABDM 的使用门槛不在「数据难拿」，而在「每一类角色都要换一种证据」。研究者要的是名录，工程师要的是沙箱，政策研究者要的是条款，三者没有共同的入口。
9.5 一个人也能做完的最小验证
如果只有一天时间，最有产出的一件事是：挑两个邦，各抓几十条机构记录，核对坐标是否落在该邦境内、类型字段是否都在已知枚举内。这一步能同时检验可达性、字段稳定性与数据质量三条假设。
#-- 一天验证：坐标落域检查 + 类型枚举覆盖检查
import pandas as pd
df = pd.DataFrame({
"stateName": ["Kerala", "Kerala", "Bihar"],
"facilityTypeId": ["HOSP", "CLINIC", "HOSP"],
"latitude": [9.93, 11.25, None],
"longitude": [76.26, 75.78, 85.13],
})
in_range = df["latitude"].between(6.5, 37.5) & df["longitude"].between(68.0, 97.5)
print("坐标落域比例:", round(in_range.mean(), 3))
print("类型取值:", sorted(df["facilityTypeId"].dropna().unique()))
print("缺坐标条数:", int(df["latitude"].isna().sum()))
坐标落域检查用的是印度国境的外接矩形，粗但有效：落在框外的记录一定是错的，落在框内的还要进一步核。
9.6 引用方式
引用 ABDM 时要区分引用对象：引用名录应注明抓取日期与抓取范围；引用架构应引用官方文档章节；引用采纳事实应引用具体论文而不是政府新闻稿。三条互不替代。
| 引用对象 | 应写的形式 | 不该写的形式 |
|---|---|---|
| HFR 名录 | 机构名录，抓取日期，邦范围 | 「印度医院数据库」 |
| 交换架构 | 官方接口文档，章节或端点 | 「据 ABDM 规定」 |
| 采纳率 | 论文作者、期刊、年份、DOI | 「官方称采纳率」 |
| 启动时间 | 论文方法段或官方公告 | 仅写「2021 年」 |
§10 AI 使用声明
| 项目 | 说明 |
|---|---|
| 生成方式 | 本文由 AI 辅助撰写，人类编辑负责结构与事实核对 |
| 事实来源 | 官方站点与公开接口文档、Europe PMC 收录论文摘要 |
| 未能核验项 | ABHA 注册总量、HFR/HPR 记录总数、具体发版日期 |
| 数据处理 | 未下载任何个体级数据；未抓取任何需要凭证的接口 |
| 代码示例 | 均为可运行骨架，未对生产环境发起请求 |
| 引用边界 | 所有数字仅用于规模、结构、边界三类判断，未做分布统计 |
| 已知局限 | 官方站点部分页面对外返回 403，本文据公开文档与第三方集成资料交叉核对 |
| 更新责任 | 名录与接口均会变化，引用前应以官方最新页面为准 |
常见误读（避坑清单）
| 常见说法 | 实际 | 证据 |
|---|---|---|
| ABDM 是印度的电子病历库 | 它不托管病历，只做身份、名录与交换 | 公开接口文档中的角色划分与点对点推送流程 |
| 有 ABHA 号就能查全部病历 | 只能凭当次签发的同意凭据逐次调取 | 同意请求报文中的时间窗与擦除字段 |
| ABDM 数据可以下载 | 只有 HFR/HPR 名录可检索，无临床数据 | 官方站点仅提供名录检索与开发者文档 |
| ABHA 号就是 Aadhaar 号 | 两者是不同标识，ABHA 登记可借 Aadhaar 核验 | 身份组件的字段设计中二者分离 |
| 同意一次终身有效 | 每次授权独立，含时间窗与擦除时间 | 凭据中的 dateRange 与 dataEraseAt |
| 接入就是调一个 API | 是选角色、配回调、过资质的一整套流程 | M1 至 M3 的阶段划分与 bridge 配置 |
| 名录等于全国医疗资源总量 | 只含自愿登记的机构 | 采纳率与登记机制的公开描述 |
| 采纳率高说明好用 | 体验认可与隐私信任是两回事 | 满意度八成以上、隐私放心约 55% |
| 交换失败多是网络问题 | 回调不可达与对端未激活更常见 | 集成资料中列出的常见失败端点 |
| 跨境也能用同一套通道 | 信任链锚定在印度境内机构 | 机构标识与资质核验机制 |
FAQ
Q：ABDM 有没有可供下载的病历数据？
没有。它的架构里没有中心病历库，病历留在各机构系统内，只能在同意范围内点对点推送。
Q：那研究者能从 ABDM 拿到什么？
两份名录：HFR 机构名录与 HPR 人员名录，可按邦、县、类型检索，适合做资源分布与主数据补全。
Q：ABHA 号和 ABHA 地址有什么区别？
前者是 14 位数字，后者是形如 xxx@abdm 的可读用户名，两者指向同一账户，使用场景不同。
Q：同意可以一次授权、长期使用吗？
不可以。每次授权都带独立时间窗与擦除时间，可限定访问频率，也可提前撤销。
Q：为什么会有 v0.5 和 v3 两套端点？
接口在迭代，新旧版本并存了一段时间。照旧文档写的集成代码会对新路径报错，接入前先确认当前版本的路径。
Q：沙箱和生产环境差在哪？
沙箱用于联调，凭证易得、数据是测试数据；生产需要机构资质核验与服务订阅，个人开发者拿不到。
Q：ABDM 和 NDHM 是什么关系？
同一套建设的先后名称。2021 年 9 月以 NDHM 之名启动，之后统一用 ABDM 对外表述。
Q：名录里的机构数能代表印度的医疗资源总量吗？
不能。名录只含主动登记的机构，城市与信息化程度高的机构更可能入库，农村会被低估。
Q：接入需要公网地址吗？
需要。交换走异步回调，网关要能访问到你的 bridge 地址，内网环境需要隧道或专线。
Q：同意疲劳具体指什么？
指患者每换一家机构就要重新签发一次授权，就诊机构越多、次数越多，长期看会降低使用意愿。
Q：数据擦除是谁执行的？
由接收方在授权到期后按 dataEraseAt 执行，执行结果依赖受托人的系统实现，外部无法独立核验。
Q：如果只想了解概念，该读哪几节？
§1 与 §3 足够。§1 讲清它解决什么，§3 讲清身份层与集中式索引的区别。
术语表
| 术语 | 英文 | 释义 |
|---|---|---|
| ABDM | Ayushman Bharat Digital Mission | 阿尤什曼数字健康使命，国家级数字健康基础设施 |
| NDHM | National Digital Health Mission | 同一套建设的前身名称 |
| NHA | National Health Authority | 印度国家卫生局，ABDM 主管机构 |
| ABHA | Ayushman Bharat Health Account | 个人健康账户，含数字号与地址式用户名 |
| ABHA 号 | ABHA Number | 14 位数字健康标识 |
| ABHA 地址 | ABHA Address | 形如 xxx@abdm 的可读用户名 |
| HFR | Health Facility Registry | 医疗机构注册库，公开可检索 |
| HPR | Healthcare Professionals Registry | 医务人员注册库，公开可检索 |
| HIP | Health Information Provider | 健康信息提供方，通常是医院侧系统 |
| HIU | Health Information User | 健康信息使用方，通常是请求方系统 |
| 网关 | ABDM Gateway | 路由同意请求与数据请求的中心组件 |
| 同意管理器 | Consent Manager | 管理同意凭据签发、状态与撤销 |
| 同意凭据 | Consent Artefact | 一次授权的结构化记录 |
| 目的码 | Purpose Code | 授权的用途枚举，如诊疗、科研、理赔 |
| HI-Type | Health Information Type | 授权的数据类型枚举，如处方、诊断报告 |
| care context | Care Context | 一次就诊上下文的引用，由 HIP 编码 |
| 交换事务 | Transaction | 一次数据推送，带独立的 transactionId |
| UHI | Unified Health Interface | 统一的健康服务发现与预约接口 |
| FHIR | Fast Healthcare Interoperability Resources | 医疗数据交换的国际标准 |
| 密钥材料 | Key Material | 传输加密所需的公钥与随机数 |
| Bridge | Bridge | 机构侧的回调接入组件 |
| M1/M2/M3 | Milestone 1/2/3 | 沙箱接入的阶段性目标划分 |
| sandbox | Sandbox | 开发者联调环境 |
| 数据受托人 | Data Fiduciary | 对数据负有受托责任的一方 |
| 擦除时间 | dataEraseAt | 授权到期后须执行擦除的时间点 |
| 数字健康素养 | Digital Health Literacy | 使用数字健康服务所需的能力水平 |
| 采纳率 | Adoption Rate | 数字通道占全部登记的比例 |
附录 A：核心数字核对表
| 项 | 值 | 来源 | 来源层级 |
|---|---|---|---|
| 启动时间 | 2021 年 9 月 | 同行评议论文方法段 | 论文摘要 |
| 主管机构 | 国家卫生局 | 官方站点表述 | 官方页面 |
| ABHA 号位数 | 14 位 | 官方与集成资料一致 | 官方页面 |
| ABHA 地址格式 | xxx@abdm |
接口示例报文 | 官方页面 |
| 目的码示例 | CAREMGT | 公开集成示例 | 第三方集成资料 |
| 数据类型示例 | OPConsultation / Prescription / DiagnosticReport / DischargeSummary | 公开集成示例 | 第三方集成资料 |
| 授权访问模式 | VIEW | 公开集成示例 | 第三方集成资料 |
| 令牌有效期量级 | 约半小时 | 集成资料描述 | 第三方集成资料 |
| 沙箱会话路径 | /gateway/v0.5/sessions |
公开集成资料 | 第三方集成资料 |
| 同意发起路径 | /consent/v3/request/init |
公开集成示例 | 第三方集成资料 |
| 数据请求路径 | /data-flow/v3/health-information/request |
公开集成示例 | 第三方集成资料 |
| 门诊研究样本量 | 四百余名 | 论文摘要 | 论文摘要 |
| 月度采纳率 | 约 24% | 论文摘要 | 论文摘要 |
| 素养量表均分 | 2.94（满分 4） | 论文摘要 | 论文摘要 |
| 隐私放心比例 | 约 55% | 论文摘要 | 论文摘要 |
| 需要培训比例 | 约 88% | 论文摘要 | 论文摘要 |
| ABHA 注册总量 | 官方未在可及页面给出可复核值 | 无 | 未核实 |
| HFR 记录总数 | 官方未在可及页面给出可复核值 | 无 | 未核实 |
| HPR 记录总数 | 官方未在可及页面给出可复核值 | 无 | 未核实 |
附录 B：数字的来源分层
第一层，官方页面。 包括 ABDM 主站、沙箱开发者站点、HFR 检索站与身份服务站点。本文对这三个域名均做了可达性探测，注意到主站与检索站对脚本请求返回 403，身份服务站点在本次网络环境下超时。因此本层信息以公开文档的通行表述为准，未逐条抓取核对，凡涉及具体计数的一律标「未核实」。
第二层，论文摘要。 采纳率、数字素养、满意度与障碍排序来自一篇 2026 年发表于 BMC Health Services Research 的横断面研究摘要，另有一篇同行评议论文用于确认启动时间与网络安全定位。本层数字有明确出处，但均为单地区或定性结论，不能外推为全国口径。
第三层，第三方集成资料。 端点路径、报文结构与令牌有效期来自公开的开源集成项目文档。这类资料描述的是接口行为，不是官方口径，版本变化后可能失效，本文引用时已标注层级。
附录 C：完整参考文献
- Ranjan A, Singh G, Singh H, Singh M. Adoption, digital health literacy, and patient satisfaction of Ayushman Bharat Digital Mission: an analytical cross-sectional study among outpatient department attendees. BMC Health Services Research. 2026;26:512. doi:10.1186/s12913-026-14314-7
- An assessment of cyber security and resilience of the National Digital Health Mission of India. Oxford Open Digital Health. 2026. doi:10.1093/oodh/oqag012
- Ayushman Bharat Digital Mission 官方站点. https://abdm.gov.in
- ABDM 开发者沙箱. https://sandbox.abdm.gov.in
- Health Facility Registry 公开检索. https://hfr.abdm.gov.in
- ABHA 身份服务入口. https://healthid.ndhm.gov.in
- ABDM V3 API Postman 集合与已知问题说明（第三方开源项目）. https://github.com/Nirmitee-tech/abdm-v3-postman-collection
- ABHA Bridge Console 集成说明（第三方开源项目）. https://github.com/AIAnytime/abha-bridge-console
附录 D：任务代码
对想用名录做一次最小实证的团队，下面这段整合了抓取、清洗与描述统计，可以直接跑。
#-- 名录最小实证：抓取失败时优雅退出，不阻塞后续分析
import json, pathlib, urllib.request, urllib.parse
import pandas as pd
def fetch_state(state: str, out: pathlib.Path) -> bool:
url = "https://hfr.abdm.gov.in/search?state=" + urllib.parse.quote(state)
req = urllib.request.Request(url, headers={"User-Agent": "research-bot/1.0"})
try:
with urllib.request.urlopen(req, timeout=30) as r:
(out / f"{state}.html").write_bytes(r.read())
return True
except Exception:
return False
def main() -> None:
out = pathlib.Path("hfr_raw")
out.mkdir(exist_ok=True)
states = ["Kerala", "Bihar", "Punjab"]
ok = sum(fetch_state(s, out) for s in states)
print(f"fetched {ok}/{len(states)}")
sample = pd.DataFrame({
"facilityId": ["F-0001", "F-0002", "F-0003"],
"stateName": ["Kerala", "Bihar", "Punjab"],
"facilityTypeId": ["HOSP", "CLINIC", "HOSP"],
})
print(sample.groupby(["stateName", "facilityTypeId"]).size())
if __name__ == "__main__":
main()
附录 E：如果只记五件事
一，ABDM 不是数据集，是身份加名录加交换协议的国家基础设施。
二，它刻意不集中托管病历，数据留在原机构，靠同意凭据点对点调取。
三，公开可得的只有 HFR 与 HPR 两份名录，适合做资源分布研究。
四，同意是逐次签发的，就诊越频繁，授权确认的次数越多。
五，采纳的真正瓶颈是数字素养与隐私信任，不是技术。
编辑说明
本页的核验工作在 2026 年 10 月 27 日完成，时间盒 20 分钟。核验方式：对三个官方域名各做一次可达性探测，均未取得有效页面内容（主站与检索站返回 403，身份服务站点超时，沙箱域名无法解析）；改以 Europe PMC 检索 Ayushman Bharat Digital Mission 与 ABDM India digital health 两个关键词，取回一篇带完整摘要的横断面研究与一篇架构评估论文；剩余端点与报文字段来自两个公开开源集成项目的文档。凡官方页面未能给出可复核计数的，一律记「未核实」，未用第三方推测值填补。本页未涉及任何需要开发者凭证的接口调用，未下载任何个体级数据。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- maternal-ultrasound-nutrition — 共享标签：电子健康记录 / 真实世界数据 / 公共卫生与流行病学
- openfda — 共享标签：电子健康记录 / 真实世界数据 / 公共卫生与流行病学
- usda-fooddata-central — 共享标签：真实世界数据 / 公共卫生与流行病学 / 调查数据
- encode-chile — 共享标签：电子健康记录 / 公共卫生与流行病学 / 调查数据
- bifap — 共享标签：电子健康记录 / 真实世界数据 / 公共卫生与流行病学
- knhanes — 共享标签：电子健康记录 / 公共卫生与流行病学 / 调查数据
- patient-level-data-covid-ms — 共享标签：电子健康记录 / 公共卫生与流行病学 / 调查数据
- bold-blood-gas-oximetry — 共享标签：电子健康记录 / 真实世界数据 / 公共卫生与流行病学
- gemini — 共享标签：电子健康记录 / 真实世界数据 / 公共卫生与流行病学
- charls — 共享标签：电子健康记录 / 公共卫生与流行病学 / 调查数据
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
