ARTICLE · 1318769
医疗文档共享为什么这么难?一文讲透 XDS 架构与核心组件
当一位患者在 A 医院做完 CT，转到 B 医院就诊时，为什么还要重新拍一次片子？这不是技术做不到，而是数据"过不去"。本篇作为系列开篇，我们用一篇文章讲清楚：医疗文档共享到底难在哪，XDS 是如何解决这个问题的。
患者在不同医疗机构就诊时，医疗数据无法互通，直接导致两个后果：重复检查和延误诊断。
想象一个典型的场景：一位慢病患者每月都要在社区医院测血压、在三甲医院复诊、在体检中心做年度体检——三份记录、三个系统、三个互不相通的"档案柜"。医生看不到全貌，患者只能靠"人肉携带"纸质报告。
▲ 每个机构都有自己的系统，数据却被锁在各自的围墙里
要把这件事做好，得先看清"难"在哪里。挑战分为两个层面：
① 电子病历系统（EMR）相互隔离
② 不同厂商系统数据格式不统一
③ 缺乏统一标识和索引机制
④ 文档版本管理混乱
⑤ 数据完整性和真实性难以验证
① 转诊流程繁琐、耗时长
② 纸质文档传递效率低下
③ 缺乏标准化的文档模板
④ 会诊记录难以追溯
⑤ 无法实现实时文档共享
数据层面是"格式不通"，流程层面是"流转不畅"。要同时解决这两类问题，靠点对点接口硬连是不现实的——几十家机构两两互联，接口数量会呈指数级爆炸。行业需要一个标准化的、中介式的共享框架。这就是 XDS。
XDS（Cross-Enterprise Document Sharing）是 IHE（Integrating the Healthcare Enterprise）框架定义的企业间文档共享集成规范。划几个重点：
✅ 核心目标：实现不同医疗机构之间电子医疗文档的安全、高效、标准化共享
✅ 技术底座：基于 ebXML Registry 标准，采用集中式注册 + 分布式存储架构
✅ 覆盖范围：支持门诊、住院、检查、检验、影像等多种类型医疗文档
✅ 标准接口：提供文档注册、检索、获取的标准化交易接口
✅ 广泛支持：医院信息系统（HIS）、影像系统（PACS）、检验系统（LIS）、区域健康平台
一句话总结：XDS 不搬运系统，只搬运"索引 + 文档"——各家系统不用推倒重建，只需要按照统一标准对外暴露文档即可。
XDS 不是一夜诞生的标准，它伴随医疗信息化发展不断演进：
注意最后两行：近年的演进方向是与 FHIR 深度融合——这正是本系列的主角 XDS-on-FHIR，我们在第 2 篇展开。
XDS 在国内医疗信息化中早已落地开花，典型场景包括：
🏥 区域健康信息平台
连接区域内所有医疗机构，实现居民健康档案的互联互通
🏨 医院集团化运营
支持医院集团内多院区之间的病历调阅和业务协同
🔗 医联体 / 医共体
实现上级医院与基层医疗机构之间的双向转诊和文档共享
📡 远程会诊平台
支持专家远程查阅患者完整诊疗文档，进行远程诊断
💳 医疗保险理赔
为保险公司提供标准化的医疗文档，简化理赔流程
🔬 科研数据共享
支持临床科研项目获取脱敏后的标准化医疗数据
进入第 2 章的核心：XDS 的架构精髓是"注册-存储分离"——文档本身存储在源系统，注册中心只提供索引。
四个核心参与者你需要记住：
📌 文档源（Document Source）：生产文档的一方，如 HIS、PACS
📌 文档存储（Document Repository）：存放文档实际内容
📌 文档注册中心（Document Registry）：文档的"图书馆索引卡片柜"
📌 文档消费者（Document Consumer）：先查索引、再取文档的使用方
此外，XDS 支持两种部署模式：XDS（集中式注册）和 XDR（点对点直接交换）；文档元数据遵循 IHE MHD / XDS-Mhd Profile 定义的规范。
1 文档源生成医疗文档（如 HIS、PACS） → 2 元数据注册向注册中心注册文档元数据 → 3 注册中心存储文档索引、提供检索服务
4 文档检索消费者查询符合条件文档 → 5 文档获取从存储获取实际文档内容
初学者最容易混淆的两个角色，对比着看就清楚了：
类比一下：Registry 是图书馆的检索目录柜，Repository 是书库。读者先查目录（查询元数据），再凭索书号去书库取书（获取文档）。
一份医疗文档在 XDS 体系中的完整旅程：
① 创建 Create — 文档源生成新的医疗文档
② 提交 Submit — 文档连同元数据被提交到 XDS 网络
③ 注册 Register — 元数据被注册到文档注册中心
④ 发布 Publish — 文档变为可被检索和获取的状态
⑤ 检索 Query — 消费者通过注册中心查询文档元数据
⑥ 获取 Retrieve — 消费者从存储获取所需文档
⑦ 归档 Deprecate — 文档被标记为历史版本，不再活跃
⑧ 删除 Remove — 文档从系统中移除（需符合保留策略）
XDS 通过一组编号为 ITI-xx 的"交易（Transaction）"定义参与者之间的每一次交互。这些编号会在后续文章中反复出现，建议收藏：
这些交易构成了 XDS 文档共享的完整流程闭环。
📌 本篇小结
1️⃣ 医疗信息孤岛导致重复检查、延误诊断，根因是数据格式与流转流程的双重割裂
2️⃣ XDS 用"集中式注册 + 分布式存储"架构，在不推翻现有系统的前提下实现标准化共享
3️⃣ 记住四大角色：Source（生产）、Repository（存书）、Registry（索引）、Consumer（用书）
4️⃣ ITI-18/41/42/43 等交易编号是 XDS 的"通用语言"
🔮 下期预告
传统 XDS 基于 SOAP/XML，重且繁琐。第 2 篇我们讲XDS-on-FHIR：如何用 FHIR R5 的 DocumentReference、Bundle 等资源，把这套 20 年的老架构"翻译"成现代 RESTful API——并附上完整的资源映射表和 JSON 示例。
📖 本系列共 4 篇，点击公众号菜单"合集"可查看全部
① XDS 背景与架构（本篇） → ② XDS-on-FHIR 规范与核心资源 → ③ 文档提交、检索与交易报文 → ④ 安全、实施与实战案例
