内容

• 背景知识
• 相关标准和规范
• IBM HIE 资产
• 基于 HIE 实现文档共享
• 医疗文档共享示例场景
• 总结
• 参考资料

背景知识

医疗文档

患者在参加医疗活动享受医疗服务时候，医疗服务机构会产生为该患者产生卫生服务纪录，例如儿童出生会产生出生医学证明、健康体检信息等纪录，病人在门诊诊疗时候会产生诊疗或者医嘱纪录，病人住院会产生住院并案首页、出院小节等纪录，病人在医院或者健康机构检查时候会产生实验室报告、健康体检信息等纪录，所有的这些纪录具有独立语义的完整的医疗信息，可以以文档的形式被医疗机构 IT 系统进行交换和共享，在这里这些纪录统称为医疗文档。

交换和共享

医疗文档是构建居民统一电子健康档案 (EHR, Electronic Health Record) 的重要来源，医疗文档的共享是区域医疗解决方案中的基本目标。居民在医疗机构诊疗产生的医疗文档进行采集，形成居民完整的健康档案，供居民、临床医生、全科医生以及相关机构进行调阅和查看。

医疗文档的交换和共享是构建区域卫生信息平台的核心业务之一，也是区域医疗解决方案的重要组成部分之一。各医疗机构的应用系统应该能够将需要共享的医疗文档上传到区域 EHR 平台，由平台进行统一管理和维护，而在需要查询和调阅时候，医疗机构应用系统也可以查询和展示相关的医疗文档，从而达到跨医疗机构的医疗文档的共享的目的。

相关标准和规范

医疗文档类型是多种多样的，可以是文本、影像、结构化信息等等，如果类型和结构不能统一，就不能使医疗机构和系统对文档的理解和处理做到一致，这需要建立统一的标准来定义文档的语法和语义，临床文档架构 CDA（Clinical Document Architecture）是目前在医疗界得到广泛承认和使用的文档标准。同时，除了文档标准外，还需要将交换方式和模型做到标准化，使得各医疗机构能够使用统一的 IT 交互规范实现无障碍地跨医疗机构文档共享，医疗信息集成规范（IHE，Integrating Healthcare Enterprise）给出了这方面的规范。

HL7 CDA

HL7（Health Level 7）是在医疗信息系统之间交换临床、财务和管理信息的一套标准，而 CDA（Clinical Document Architecture）是 HL7 标准集的一部分，它以临床文档交换为目的，描述临床文档的结构和语义的文档标记标准。CDA 提供了临床文档的交换模型，便于实现临床信息的标准化，例如病案首页、出院小结、观察报告等。CDA 遵循 XML 标准、遵循 HL7 RIM 参考模型，CDA 既可以包含计算机可识别的标准化结构文本、也可以包含自由文本、影像等人可识别的信息。CDA 结构如清单 1 所示，具体标记解释请参考 HL7 官方网站。

				 
 <ClinicalDocument> 
  ... CDA Header ... 
  <structuredBody> 
    <section> 
      <text>...</text> 
      <observation>...</observation> 
      <substanceAdministration> 
       <supply>...</supply>
      </substanceAdministration> 
      <observation> 
        <externalObservation>... 
        </externalObservation> 
      </observation>
				   </section>
    <section> 
        <section>...</section> 
    </section> 
  </structuredBody> 
 </ClinicalDocument> 

IHE XDS 和 ATNA

医疗信息集成规范（Integrating Healthcare Enterprise，IHE）目标不仅是在鼓励整合，更是一种实现平台的框架。IHE 定义了不同方面的技术框架（Technical Framework），例如基础架构（IT Infrastructure）、放射医学（Radiology），实验室（Laboratory），心脏病学（Cardiology）等。基础架构技术架构中又进一步定义了集成概要（Integration Profile）来描述不同系统集成的实现规范，例如 PIX/PDQ, XDS, ATNA 等，其中：

• 跨企业文档共享 XDS（Cross-Enterprise Document Sharing）定义了信任领域（Affinity Domain）内不同的医疗机构以交换文档的方式共享病人医疗纪录，XDS 详细定义了文档注册库（Document Registry），文档存储库（Document Repository），文档源（ Document Source），文档消费者（Document Consumer），病人身份源（Patient Source）等几个角色（Actor）以及这几个角色进行信息交换的交易接口（Transaction），这些交易的接口的数据格式是基于 SOAP 和 ebXML 之上而数据模式则参考了 HL7 RIM 概念模型。XDS 集成概要包括 XDS.a 和 XDS.b 两种类型，XDS.a 发布较早基于 ebXML2.1 构造，除了 SOAP 接口外还有 HTTP 接口；而 XDS.b 基于 ebXML3.0 构造，接口全部是 SOAP 方式。
• 审计跟踪和节点认证 ATNA（Audit Trail and Node Authentication）定义如何保证节点之间传递信息的安全，包括在节点之间建立安全通道，在传输信息时候纪录审计消息等。

IBM HIE 资产

HIE（Healthcare Information Exchange）是 IBM 的现有资产和基于 IHE 的解决方案，它采用了 IBM 公司高性能、稳健的、大规模的中间件产品和 IHE 定义的医疗卫生信息交换规范，实现对医疗健康机构（医院、医生诊所、医疗实验室、研究机构等）之间医疗文档（健康档案、就诊纪录、出院小节、医嘱、检测报告等）共享和交换，HIE 实现了 IHE 定义的 XDS（包括 XDS.a 和 XDS.b）和 ATNA 两个集成概要，其总体架构图如图 1 所示。

方案的每个组成部分功能介绍如下：

1. 文档注册库（Document Registry）：该注册库维护了已注册文档的元数据，文档元数据包含病人 ID、文档标题、文档类型、主治医师、医院科室、提交时间等信息，文档注册库类似文档的索引中心，提供了符合 XDS Profile 定义的交易接口。
   1. Patient Identity Feed：该接口表示身份源（Patient Identity Source）可以将病人身份标志注册到文档注册库中。
   2. Query Registry, Stored Registry Query：两个接口均提供对文档元数据（Document Metadata）的查询，文档消费者（Document Consumer）可以传入一些参数查询病人的文档元数据信息，例如根据病人 ID 查询该病人拥有的病历文档。
   3. Register Document：该接口定义了 Document Repository 需要向 Document Registry 注册文档元数据。
2. 文档存储库（Document Repository）：该存储库存储了病人的具体文档，并提供了 IHE XDS 定义的以下交易接口：
   1. Provide&Register Document：提供了提交文档的接口。文档源（Document Source）可以将病人的文档以及元数据提交到 Document Repository，Document Repository 在将文档保存到自己的存储库中后，再将文档的元数据通过 Register Document 接口注册到 Document Registry 中。
   2. Retrieve Document：该接口定义了获取文档的交易，文档消费者（Document Consumer）根据文档的元数据将文档从指定的 Document Repository 中获取出来。
3. 审核日志库（ATNA Audit Repository）：存储了信息交换过程的审计日志，并提供了管理界面以便跟踪和查询。

IBM HIE 还支持患者身份管理，跨领域的查询（支持 IHE XCA-Cross Community Access），IHE XUA（Cross Enterprise User Assertion)）身份标识提供者服务，XDS-I 影像资源交换等技术，在此不做具体介绍。

在部署模型中，该解决方案可支持完全中心式、完全联邦式或者混合式三种部署模式。例如，在一个信用领域内，仅在中心位置部署一个 Document Registry 和 Document Repository，所有医疗机构的系统直接与他们进行集成；也可以在中心位置部署一个 Document Registry，在各医疗机构内部分别部署自己的 Document Repository；或者部署多个 Document Registry 和 Document Repository，形成联邦模式。

HIE 的实现是基于 IBM 成熟的中间件产品 WebSphere 应用服务器和 DB2 UDB 数据库实现的，同时 Document Repository 可根据实际需求选用 DB2 UDB， DB2 PureXML，或者 DB2 ECM （Enterprise Content Manager）来存储和管理文档。HIE 可以利用 WebSphere 应用服务器提供的负载均衡、集群等技术，提供高可用性、可伸缩性和健壮性，从而满足区域医疗环境下对大容量、高并发的数据处理要求。HIE 也可以和目录服务器 Tivoli Directory Server，联邦身份管理服务器 Tivoli Federated Identity Manager 等进行集成，提供对认证、授权以及身份映射的管理。

基于 HIE 实现文档共享

基于电子健康档案的区域医疗 SOA 解决方案一文中给出了区域医疗的总体解决方案总体架构图，在总体架构图中，EHR 数据服务部分提供了对健康信息和临床文档（CDA 格式）的存储、管理和共享，如图 2 所示，它以 HIE 为核心提供了基于 IHE XDS 标准的外界访问服务，同时又进行了一定的扩展，支持对医疗文档的管理和定制功能。

这些扩展包括：

• 元数据定制：HIE 实现了对 XDS 集成概要的文档元数据的管理和查询，该组件可在此之上对现有的元数据进行定制和扩充，例如增加新的元数据。
• 术语以及语义：针对医疗卫生行业内的不同系统的术语、编码给出定义和解释，因为不同的系统定义的编码和术语可能不一样，该组件可以支持不同系统的编码和标准编码（如 LOINC 编码）的映射和管理。
• 检索：支持以不同的方式检索文档存储库，虽然 HIE 给出了一些标准查询接口，但不并能满足一些特定的检索需求，该组件可以提供基于内容关键字的全文检索功能，例如查询所有患有糖尿病的病人文档。
• 文档模板管理：CDA 是一个统一的文档架构，需要定义不同的模板以支持在不同业务域的文档类型，例如门诊纪录模板、出院小节模板、检测报告模板等。文档模板管理提供了对 CDA 文档模板的定义、管理和验证功能。
• 数据同步服务：支持其他系统和 EHR 数据服务模块的文档数据同步，也支持文档更新的自动通知功能。

医疗文档共享示例场景

我们以一个常见的转诊例子解释该解决方案的应用场景，在由医院和社区中心组成的领域内，医院和社区可以共享病人医疗文档，该场景过程如图 3 如下

1. 居民张三按照卫生部门要求通过基于 Web 界面的应用注册身份信息，并得到唯一的病人 ID。在该步骤中，Web 应用担当了病人身份源 (Patient Identity Source) 的角色，它使用 Patient Identity Feed 交易向 HIE Registry 注册病人 ID。
2. 张三突发脑出血，并立即入院治疗。医院医生使用应用 EMR(Electronic Medical Record) 系统纪录病人病情、诊疗过程、医嘱信息等。在张三出院后，EMR 可以生成出院小节，该出院小节以本地接口调用的情况下发送到 HIE 适配器。
3. HIE 适配器可以将出院小节转换为标准的 CDA 格式，并构造出文档元数据（也可以从 CDA 文档中直接提取元数据）。HIE 适配器将出院小节 CDA 以及元数据发布到 HIE Repository；在该步骤中，EMR（通过 HIE 适配器）担当文档源（Document Source）的角色，使用 Provide&RegistryDocument 交易将文档上传到 HIE Repository。
4. HIE Repository 将出院小节元数据使用 RegisterDocument 交易注册到 HIE Registry。
5. 张三出院转到社区中心接受进一步康复治疗，社区医生需要了解张三在医院的诊疗过程，使用社区应用系统 (Community Information system) 根据张三病人 ID 查询张三的就诊纪录，使用本地接口调用 HIE 适配器。
6. HIE 适配器首先根据病人 ID 到 HIE Registry 查询张三的病历文档元数据。
7. 然后再根据文档元数据到 HIE Repository 获取出院小节 CDA 文档。在 6) 步和 7) 步中，社区应用系统 CIS（通过 HIE 适配器）担当文档消费者（Document Consumer）角色，使用 QueryRegistry 交易到 XDS Registry 查询文档元数据，使用 RetrieveDocument 交易到 XDS Repository 获取文档。
8. CIS 应用在得到 CDA 文档后，可以在界面中以比较友好的方式展示给社区医生。例如，可以使用 XSLT 将 CDA 文档转换为 HTML 页面显示在浏览器上。

几点说明：

1. 本场景为了简化，认为在该领域内，张三在医院和社区使用的是唯一的全局病人 ID。在实际场景中，如果医院和社区使用了不同的病人 ID，则需要考虑使用病人主索引（EMPI，Enterprise Master Patient ID）将病人在不同机构的身份标志关联到全局标志。
2. EHR 数据服务模块中，仅仅突出作为文档注册库的 HIE Registry 和文档存储库的 HIE Repository，其他组件没有列出。
3. 病人隐私保护、授权管理等安全方面的管理在本场景中没有考虑。
4. HIE 适配器的作用是为了方便医院或者社区应用系统接入到 HIE，具体实现可以参考开源工具 OHT（Open Health Tooling），OHT 有一个子项目 OHT IHE 提供了 IHE XDS 的客户端支持，使用 OHT IHE 提供的 API 可以非常容易地构造 Document Source 和 Document Consumer 的请求消息。

总结

本文首先介绍了医疗文档的概念和对交换共享的需要，并简单列出了医疗卫生行业内的相关标准和规范，然后详细介绍了 IBM 的现有资产 -HIE 解决方案。最后给出了以 IBM HIE 解决方案为基础的医疗文档共享参考解决方案和应用场景。

参考资料

• 本系列的 第 1 部分：为您概述了整个系列所会涉及的标准、内容以及各部分的重点主题。
• 参考 HL7官方网站了解更多的 HL7 和 CDA 知识。
• 参考 IHE官方网站学习 IHE 实现框架和集成概要，例如 XDS, ATNA 等。
• IBM HIE 对 IHE 实现的描述。
• OHT IHE是 IHE 的客户端开源的参考实现，使用它可以非常容易地接入到 IBM HIE 解决方案。
• developerWorks SOA and Web services 专区：让您了解更多和 SOA 以及 Web 服务相关的内容，包括技术文章、教程以及特殊专题等。