第 3 部分 建立居民主索引系统实现主数据管理

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