内容
简介: 在新医改推行的区域医疗中,病人 / 居民在社区建有健康档案,在多家医院就诊,并与相关公卫机构有关系。而每个机构都有各自的身份标识,如何关联这些标识,为每个人建立完整的信息视图,这是搭建电子健康档案系统的基础。Enterprise
Master Person Index 支持采用 IHE PIX/PDQ 标准化方式,接收并管理人员信息和身份标识、提供查询和索引功能。InfoSphere
Master Data Management Server 可以用来管理人员 / 组织主数据,拥有丰富的内置模型和管理服务,并提供灵活的扩展框架,这为构造
EMPI 提供了基础平台。文章将介绍病人信息的交互场景、HL7 和 IHE 相关标准、MDM Server
功能和扩展框架,EMPI 体系结构以及开发过程。
随着中国新医改的推进,医疗卫生行业正受到前所未有的重视,医疗信息化建设逐渐成为 IT 市场的热点之一。实现以人为本的医疗服务体系,是新医改方案明确提出的目标。而发展区域卫生信息化,建立电子健康档案,整合医疗卫生信息资源,是实现目标的关键工作。
新医改要建立以人为中心的健康档案,人员是开展各项医疗活动的基础,有效管理居民 / 病人信息对于建立电子健康档案起着基础作用。为了有效利用医疗资源,鼓励“小病在社区、大病在医院、康复回社区”的就诊模式,病人会在社区、专科医院、综合医院形成的区域中发生检查、就诊、治疗等各种医疗活动,这就要求正确标识病人的身份,并与现有系统中的病案号、就诊号关联。在各医院共享病人的医疗文档时,来自不同医院的文档需要对应到同一个病人,这时需要提供唯一的身份标识,而不仅是各自医院的内部
ID。在建立和查阅电子健康档案中,查询居民信息、进而提供完整一致的个人信息是必不可少的功能需求。
这里举一个例子,一名儿童既在其居住社区中建立了健康档案,同时接受计划免疫。于是他在社区管理系统和儿童计划免疫系统中就会进行重复登记。这对于单个系统而言问题不大,带来的影响就是要求该人员多次登记自己的信息。而对于包含多个系统的区域数据中心而言,在数据的统计分析、整理利用等方面就会带来较大的问题,如数据冗余、数据不一致、难以建立用户的统一视图、无法为用户关联多个应用等。
即使在一个系统内部,如社区管理系统,由于信息收集分散在各个社区,在系统内汇总数据的时候同样需要进行这样的数据清洗和匹配操作。而医院内的问题更加明显,病人多次到医院就诊,因为忘记携带就诊卡,可能重复注册多次;而且由于院内系统单独建立,病人信息会在电子病例系统、检验科、放射科中存在多条记录。作为连接社区、医院以及其它卫生机构的区域医疗中心,需要统一管理居民
/ 病人信息,检查并保证数据质量,并建立与现有系统内部标识的关联,从而为数据分析和建立电子健康档案打下坚实的基础。
HL7
HL7 卫生信息交换标准 (Health Level 7) 是医疗领域中不同应用间进行电子传输的标准协议。它允许各个医疗机构在异构系统之间,进行数据的交互。HL7
在世界范围内得到了广泛的应用和支持,很多医院的 IT 系统都是基于 HL7 消息进行交互的。目前 HL7
存在 V2.x 和 V3 两大类版本,V2.x 采用特殊字符间隔的文本形式,由于发布时间较早,已经被大规模采用,最新的
V2.7 正处于投票阶段。V3 则采用 XML 进行描述,具有显式的数据模型和 Schema,便于理解、解析和处理。这两个版本大部分可以实现相同的功能,由于应用场合不同,HL7
组织将同时给予持续的支持和更新。那么在实际项目中如何选择呢?如果需要集成已有系统,而这些系统使用 HL7
V2.x 收发消息,那应继续采用 V2.x 消息,以最大限度的复用资源;如果被集成系统中并没有处理 HL7
的能力,需要改造已有系统,那可以直接采用 V3 消息,以方便程序的开发和管理。
在 HL7 描述的交互消息中,病人管理部分用于传输新创建或者更新的病人基本信息和访问记录,这在医疗业务中起着基础作用。某病人在一家医院注册就诊,他的个人信息和访问记录就会进入病人管理系统,同时传递给感兴趣的其他系统。每条消息都存在多个段(Segment),分别表达不同的信息,如
MSH 表示消息头,EVN 表示消息类型,PID 表示病人 / 人员身份信息,NK1 表示相关人员,PV1
表示就诊记录等。其中 PID 是 EMPI 系统关注的重点,描述了病人的详细信息,包括标识符列表和姓名、性别、出生日期、联系方式等人口统计学信息。
IHE
IHE(Integrating the Healthcare Enterprise) 是一个致力于集成医疗行业信息系统的组织,推出一系列集成规范,旨在合理使用现有标准如
HL7、DICOM 来满足特定的医疗业务需要。它通过 IT 技术框架,来定义特定标准的实现和最佳实践,以最大程度的满足信息共享的目的。
与 EMPI 相关的集成规范主要包括 PIX (Patient Identifier Cross-Reference)
和 PDQ (Patient Demographics Query)。PIX 应用在涉及多个医疗机构的区域中,支持病人标识的跨域引用。下图中有三个病人标识域,每个域中有两类参与者——病人身份源系统和消费者系统,它们与中间的跨域引用管理器相连,身份源通过
Patient Identity Feed 事务将病人标识和详细信息传递到管理器,消费者则通过 PIX
Query 事务向管理器查询病人跨域标识,它们之间传递的消息就是 HL7 中的特定消息。交互关系如图 1
所示。
图 1. PIX 交互关系示意图
PDQ 用于查询病人信息,包括两类参与者——提供者和消费者,消费者分别通过 Patient Demographics
Query 和 Patient Demographics and Visit Query 事务向提供者查询病人的详细信息和就诊记录,如图
2 所示。
图 2. PDQ 参与者交互关系
卫生部标准
国家卫生部召集医疗行业内的专家学者和企业代表,一直在制定我国的卫生行业标准。卫生部于 2009 年 5
月发布了《健康档案基本架构与数据标准》,其中的“个人信息基本数据集”列出了电子健康档案中个人的元数据,这可以作为我们实现
EMPI 时,系统间传递消息内容的重要参考。2009 年 8 月发布了《电子病例基本架构与数据标准征求意见稿》,其中的“患者基本信息”列出了医疗机构中存储电子病例时的个人元数据,这从被集成系统角度为我们提供了参考。
在区域医疗环境中,病人、居民信息分散在医院、社区等多个医疗机构中,普遍存在冗余和不一致的现象,这使得病人就诊时难以形成完整准确的信息视图,造成医疗资源的浪费和病人满意度的降低。而这些数据因为具有稳定、基础、通用的特点,被看作是区域医疗行业的主数据
(Master Data)。高效的主数据管理有助于降低成本、提高灵活性、降低风险。
InfoSphere Master Data Management Server 是一种面向服务的实时解决方案,设计用于管理以客户为中心的业务流程和事务,同时保留客户知识和流程,例如交互历史记录、事件通知、隐私和数据授权规则、
客户关系(家庭用户、商业或提供商)以及客户价值剖析。 InfoSphere MDM Server 关注客户数据的操作管理,允许
CRM、渠道和后台系统访问它,以获得通用的主数据视图和更新服务。
InfoSphere Master Data Management Server 开箱即用地提供超过
700 种业务服务,可帮助企业管理复杂的客户业务流程和简单的主数据查询与更新。多种预先集成的业务逻辑组件可帮助组织管理业务规则、事件检测与管理、隐私和安全性规则、数据验证和复制检测处理。通过这些功能,InfoSphere
Master Data Management Server 即可作为以客户为中心的事务处理的业务流程中枢。
IBM InfoSphere Master Data Management Server 的关键组件包括:基于可扩展数据模型的主数据存储库,包含相似数据匹配功能的数据质量管理、灵活的义务规则配置和模块集成、及时响应变化的事件管理、基于角色授权的安全服务,支持外部应用集成的
SOA 服务接口、强大的数据管理用户界面以及高效的批处理管理。
根据区域医疗业务分析和主数据管理的需要,Enterprise Master Person Index(
简称 EMPI) 针对区域内的居民建立主数据和主索引,提供统一人员视图。这需要在技术上解决以下问题:
- 标准的访问协议和数据格式
系统应遵循医疗行业的 HL7 标准和 IHE 规范,便于医疗系统的接入和互操作。
- 灵活、高度可扩展的数据模型
居民信息应当存储在一个高度可扩展性的数据存储模型中,确保该模型能够面对集成中的复杂业务场景以及未来业务发展的需要。
- 针对不同类型应用的多种信息集成方式
在区域信息系统的集成过程中,需要提供实时、准实时、批量等多种整合手段,以适应不同应用系统对人员信息的需求。
- 确保信息质量的技术手段
提供有效的数据检查、重复匹配等技术手段,来保证病人 / 居民的信息质量。
在本方案中,EMPI 通过适配层连接外部交互系统,实现标准访问协议;主要的业务逻辑由主数据管理层完成;并提供
Web 界面与最终用户交互。EMPI 的体系结构如图 3 所示。
图 3. EMPI 体系结构
(1)主数据管理层
该层以 InfoSphere MDM Server 为基础,遵从其扩展框架,扩展出业务需要的数据模型和服务。图中绿色部分表明
MDM Server 本身的层次结构,包括存储层(操作数据库和历史数据库)、公共服务层(完成基本的数据匹配、规则处理、事件管理、通知机制以及访问权限管理等)、业务服务层(管理参与方、关系、地址、组织、分组等各类主数据)、连接层(支持
RMI、Web 服务、MQ 等多种连接方式)。
结合 EMPI 的业务需求,分别对各层进行扩展。在存储层,扩展数据模型,建立居民、医疗机构等类型及其代码表。在公共服务层,扩展匹配规则,根据各区域实际需求制定匹配算法,也可以连接外部的
QualityStage 软件,实现更复杂的概率性匹配;扩展通知类型,允许监听居民的创建、合并、更新等动作,发送通知到外部系统;扩展权限规则,通过集成
LDAP,定义系统中的角色和访问权限。在业务服务层,提供面向外部的业务服务,包括 IHE 要求的病人管理、病人查询,针对从业人员的管理,以及医疗机构的管理。在连接层,针对扩展的数据模型和业务服务,定义服务请求的
XML 格式,实现发布 - 订阅模式,支持批量加载处理。
(2)数据监管层
针对区域内的居民、从业者、机构管理员、系统管理员等各种角色提供 Web 界面,以完成业务相关的数据管理和查询操作。该层与最终用户进行交互,通过调用主数据管理层暴露的服务实现各种功能。
(3)适配层
与 EMPI 系统交互的外部系统包括产生人员信息的数据源系统、查询人员信息的消费系统和相关的订阅系统。该层将来自外部系统的符合标准协议和数据格式的请求,转换成对主数据管理层的调用;并将处理结果转换成标准数据格式,返回到外部系统;同时监听来自主数据管理层的通知消息,及时通知到感兴趣的订阅系统。
由于 EMPI 系统的主要功能通过主数据管理层完成,下文简要介绍基于 MDM Server 的开发步骤。
准备开发环境
MDM 目前最新版本是 8.5,本文选用 Linux For WAS 版本。在下载的安装包中存在 Workbench
压缩包,它是用于开发的 eclipse 插件,可以安装到 RSA/RAD 中。该插件安装后,在新建对话框中出现
MDM Workbench 文件夹,选择“MDM Development and Test Environment”运行开发向导,全选各选项,在随后的对话框中依次配置
MDM 安装包路径、WAS 服务器、DB2 服务器和 MDM 应用程序,点击完成。Workbench 将运行一系列脚本,完成导入
MDM 开发项目、配置 WAS profile、创建数据库、部署 MDM 应用,并验证安装过程。
图 4. MDM 开发和测试环境向导
向导运行成功后,MDM 开发环境已经建立完成,可以在该工作区中进行扩展,最终发布到同一 WAS profile
中测试。
扩展数据模型
根据对 EMPI 的需求分析,设计数据模型,包含关键元素的简化模型如图 5 所示。
图 5. EMPI 数据模型
图中的绿色部分表示 MDM Server 本身提供的类,黄色部分是针对 EMPI 扩展的类。居民 Resident
表示 EMPI 管理的人员,扩展自 [MDM]Person 类,可以用来描述病人,也可以描述医生等从业者。标识
Identifier 表示机构中的内部标识,扩展自 [MDM]Identifier 类。居民之间具有各种关系,他们位于一个或多个家庭中。家庭
Family 扩展自 [MDM]Group,通过 FamilyMember 建立与人员的包含关系。医疗机构
Organization 扩展自 [MDM]Organization。
在 MDM Workbench 中通过 Data Extension 可以扩展出所需的 Resident、Organization、Identifier
和 Family,同时基本的添加、更新、删除事务服务会自动创建。
扩展业务服务
为了实现 EMPI 相关的 IHE PIX 和 PDQ 集成接口,在主数据管理层需要实现相应的服务,见表
1。
表 1. EMPI 业务服务接口
服务 |
描述 |
Identifier addResident (Resident) |
增加居民 |
Identifier updateResident (Resident) |
更新居民信息 |
Identifier mergeResidents (Identifier, Identifier[])
|
合并相似居民 |
Identifier linkResidents (Identifier, Identifier[])
|
关联相似居民 |
Identifier unlinkResidents (Identifier, Identifier[])
|
撤销关联相似居民 |
Identifier moveResident (Identifier, Identifier)
|
转移居民标识 |
Identifier changeResident (Identifier, Identifier)
|
更改居民标识 |
Identifier[] queryResident (Query[]) |
查询居民列表 |
Resident retrieveResident (Identifier) |
获取居民信息 |
Identifier[] queryResidentCR (Identifier, Identifier[])
|
查询居民跨域引用 |
在 MDM Workbench 中通过 Txn Addition 创建面向业务的 Composite
Service,在服务实现中调用前面自动生成的原子服务,完成业务逻辑。
扩展查询功能
由于扩展了数据模型,针对居民的查询条件包含新增属性,如血型、教育程度、专业等,这为查询功能的实现增加了困难。通过在项目中添加自定义查询类,来扩展这种能力。
扩展监管界面
EMPI 除了与外部系统交互之外,还为各种最终用户提供服务,这通过扩展 MDM DataStewardship
Web 应用来完成。该应用可与 MDM Server 部署在同一台服务器,通过 RMI 方式调用 MDM
服务。它采用 JSF 框架,模型部分是由 MDM Server 导出的数据 Schema 生成的 SDO
模型。扩展监管界面的工作包括,重新生成 SDO 模型,在页面上增加扩展字段,或者新增 tab 页展现独立的功能,并与数据模型相关联。
在典型的区域医疗场景中,病人 / 居民在社区建有健康档案,在多家医院就诊,并与相关公卫机构存在关系。而每个机构都有各自的身份标识,如何关联这些标识,为每个人建立完整的信息视图,这是搭建电子健康档案系统的基础。
基于 InfoSphere MDM Server 建立的 EMPI 系统具有以下优势:
- 互联互通的行业标准
支持 HL7 数据标准和 IHE 集成规范,外部系统可以通过 PIX/PDQ 规定的事务与 EMPI
交互。
- 快捷的跨域索引能力
提供对医疗组织(医院、社区、公卫机构)的管理能力,维护人员在各组织中的标识信息,对外提供跨域索引服务。
- 高效灵活的匹配算法
针对不同业务需要,提供确定性匹配和概率性匹配,通过高效的匹配算法计算匹配度。
- 大数据量的信息处理
通过优化的处理引擎,快速处理大规模数据。
- 360 度人员完整视图
为病人 / 居民建立 360 度完整视图,便于维护相关信息,包括人口统计学信息、标识信息以及健康信息。
- 强大的扩展能力
根据业务需求,可以扩展数据模型、业务服务和访问接口,从而提供更高的灵活性。
|