用面向服务架构改进医疗系统表现

医疗领域中的SOA

技术迅速的发展及其在医疗领域中的应用导致医疗组织堆积了许多不能彼此交互的系统。但是，从业务上来说，这些系统不仅需要组织内协同工作，而且还要求能从外部访问。在这种状况下，集成的负担往往落在了那些为完成一项任务而不得不访问多个系统的使用者身上。但是，使用面向服务架构（SOA）可以改善重要信息的交付，而且能在成本、安全和部署风险均可接受的条件下使得数据在整个医疗社区内共享。

管理不断增长的系统集合是当今医疗组织要面临的挑战。创建、集成和维护这些系统的代价越来越大，同时对系统用户的要求也在提高。组织必须解决不断发展的临床需求，同时还需支持营收循环和管理商务功能。另外，为了支持区域性医疗服务的交接，与其他医疗组织进行互操作的需求也在增加。面向服务架构为整个医疗组织的系统资源重用与共享提供了系统设计和管理原则。SOA不要求对现有系统进行再造。通过SOA，现有流程可以与新功能结合构建一个服务库，其中的每个服务是解决方案的组成部分。使用那些与业务过程一致的共享服务，SOA在加强互操作性的同时减少了孤立系统间同步数据的需求。无论服务位于何处，它们都可以被用来创建超越桌面、部门、以及医疗组织的解决方案。

医疗信息技术中SOA使用介绍

如果某个医疗组织只依赖单个系统支撑企业各部门工作和提供医疗服务，那么他们往往已经有了一个共享和重用系统资源的解决方案。但是，更典型的是这种组织：它依赖一个或多个企业内部系统，支持部门特定需求的额外系统，设备有自己的系统，互操作使用复杂的数据接口网络完成。在拥有大量系统集合的组织中应用 SOA更容易显出它的优势。一个SOA环境可以使系统资产能被整个组织访问，并为现有孤立的系统功能提供了共享的可能。例如，SOA无需购置额外系统就能帮助满足那些未被履行的过程需求，并为标准化流程和数据管理提供了机会。这意味着现有系统功能会因为它们打包成可共享服务而获得升值。图1显示了医疗系统功能和相关应用的例子。尽管这个图表没有包含一个功能或系统的完整列表，但是它展示了在一个典型医疗环境中系统功能的冗余。

图1. 医疗系统和功能

SOA将一个服务定义为一个自包含、定义良好、可理解功能的独立工作单元。工作单元可以是一个整体流程，一个支持流程的功能，或是一个业务流程的一个步骤。通过SOA，服务可以直接支持业务流程，原因在于它们是作为一个系统解决方案被“发现”和编制的。那些跨系统、部门和组织使用的功能极有可能通过 SOA提高重用性和被标准化。如果系统功能在系统间是冗余的，那么相应的业务流程有可能是关联的并且很可能表明该流程需要作为服务共享。图1中，大量冗余的功能有：

• 患者挂号
• 入院、出院和转院
• 记录病情和诊断
• 缴费和记录费用
• 创建临床记录

每个系统功都可以被分成任务以进一步提高服务的重用性。例如，“患者挂号”功能可能会被分成“查找和浏览病人病历”、“创建和更新病人病历”、“核实保险资质”、“历史建档”（新建或者更新）以及其它在挂号过程中完成的业务活动。这种划分使其他服务和应用可以使用“患者挂号”的部分功能。任务“查找和浏览病人病历”可能会被绝大多数组织使用，而任务“创建和更新病人病历”可能只会被入院和前台服务人员使用。在某些情况下，其他系统提供的功能可能会比目前流程中使用的要好。例如，另一系统使用的“核实保险资质”功能可能比处理“患者挂号”的系统中相应功能提供了更多功能。在SOA 环境中，功能可以被标准化并被不同系统与流程使用。

图2显示了“患者挂号”服务功能的概念视图：

图2. “患者挂号”系统功能

随着SOA在医疗行业进一步的推广，服务集和其他特殊服务有望得到使用，使用者可能是某个医疗组织的服务采购（Service Procurement）组织功能（详见第二章）。由于系统提供的服务是位置透明的，这些被购买的服务可能在组织外托管。例如，诊断相关组（Diagnostic Related Group，简称DRG）或者其它类似受控药品词汇编码这样的服务可供集成进一个组织的解决方案。这个服务可能位于一个外部的代理系统，被不同医疗组织使用。SOA提供的一个附加好处就是可以方便地为整个组织以及所有使用该服务的医疗组织维护单独一份最新的DRG代码集。图3显示了一个医疗行业服务分类的例子。

图3. 医疗行业服务分类举例

用SOA解决医疗数据集成

在绝大多数医疗组织内，护士使用多个系统和设备给患者提供护理。护士可能会从一个患者管理应用（检查患者特征和入院信息）切换到一个或者多个电子病历（electronic medical record ，EMR）应用（观察患者早期和目前症状临床记录），或切换到一个收费应用（确保计费正常），或者切换到多个辅助系统（请求一个订单）。如果护士不能访问那些联系患者主治医生或者查看另一个组织临床记录的系统，护士就不得不用电话或者传真完成这些事情。在完成整个护理服务的过程中，这些系统以及行为支持功能都是必需的。但是，在这个例子中，编排各系统完成工作的是护士，不是系统。提供互操作的是护士。

传统上来说，医疗组织通过同步不同系统间（在某些组织中，系统数目大约是100或者更多）的数据来支持互操作。所有这些系统几乎都会管理患者信息。系统数据库使用数据接口进行同步，对于少数关键系统，则是复制数据条目。起初，系统间数据接口是点对点的，每个系统都有自己的消息格式。随着系统数目增加，更大的医疗组织开始采用类似Health Level 7（HL7）的标准接口格式和中央数据接口引擎。另外，基于Internet的通信使医疗组织可以与外部组织（例如支付者）交换数据。图4 展示了一个公共医疗数据集成架构。这个环境包括了各种不同类型的服务器、老式点对点接口、以及很多通过一个数据接口引擎处理的接口。

图4. 公共遗留医疗数据集成架构

尽管组织内外系统和系统数据库之间的数据已经同步，但这种数据接口方式不能支持数据互操作。流程之间的数据处理和通信涉及多个系统和冗余处理过程。为了支持整个工作流，用户必须要在几个应用程序之间切换才能完成一个过程。系统还必须清除冗余数据。利用SOA，可以使用现有系统功能开发服务，如图5所示。

图5. 医疗行业的SOA集成架构

在SOA环境中，系统流程被组织成和表现为一组服务。整个组织通过标准接口使用每个服务。所有维护或访问相同信息的部门使用相同服务，任何数据和冗余处理对用户来说都是透明的。应用支持一个引用一个或者多个服务的特殊工作流，每个服务与其相关的系统进行通信。为完成一个工作流，用户再也不需要在几个系统之间进行切换，整个流程和支持系统间的数据会自然同步。编排好的服务与用户工作流的一致真正实现了医疗组织流程与人之间的互操作。为了符合健康保险携带和责任法案（Health Insurance Portability and Accountability Act，HIPAA），各个组织正在增进与支付者的标准数据通信。另一个频繁的需求是与其它医疗组织进行集成，以支持临床工作流和参与医疗信息网络（healthcare information network，HIN）。一个组织还可能会在它的SOA解决方案中集成外部服务以提供完整的流程互操作。例如，如果一个患者已在一个组织中挂过号，那么这个服务就可以使用一个由HIN提供的外部服务将这个病人在整个护理社区内挂号。这不仅同步了患者的挂号信息，而且这个外部通信也在几乎没有人工干预的情况下被部署到了相关工作流中，在组织系统边界之外创建了互操作。

SOA是系统发展的下一步。它构建在以前的架构方法之上，同时更好地解决了组织内外机动性和有效重用的问题。SOA提供了真正的互操作性。绝大多数医疗组织都有一个庞大的包含冗余处理和数据的系统集合。SOA将系统功能选出并包装成服务，使之能在整个企业中得到更好地关注和使用。组织可以将他们的工作重心从维护一个复杂的数据接口策略转移到面向服务应用的创建上来，这样可以在支持互操作性的同时更紧密地与医疗流程保持一致。本章的整个剩余部分，我们将探讨这些主题：在医疗领域，通过SOA实现的真正医疗数据互操作是如何产生产业转型的。

医疗信息网络的SOA方案

数据集成和互操作是医疗系统中的一个关键需求。以金钱和生命为代价的药物误用往往都是因为护理点缺少格式良好、可用和正确的信息。

在世界范围内，对很多政府和相关医疗研究所来说，解决这个问题是一个关键焦点领域。解决数据集成问题的办法就是医疗信息网络（Healthcare information networks ，简称HIN）。HIN是政府、医院、专门实验室、药房以及保险代理（支付者）等多个机构间合作建立的，提供由共享信息通路、数据仓库和应用接口组成的数据交换网络，实现跨医疗系统快速准确地关键医疗信息交换。

HIN适于如下主要使用模型：

• 在两个护理提供者之间交换患者电子病历，以获得如患者疾病史、过敏史、顽固疾病问题等关键信息
• 在第一和第二个护理提供者或者实验室之间交换转诊病人以及这些病人的用药结果
• 对治疗进行电子预授权，这样就能快速获知患者的保险计划是否支持某项治疗或者用药
• 电子化索赔填报和支付以提高准确性和加快医务治疗的现金流循环
• 一种支持电子订购和监视处方消费的手段
• 一个法律要求的用于生物疫情监测（例如流行性感冒和其它的传染性疾病）的关键医疗信息综合数据仓库
• 患者和医疗机构涉众访问相关数据的门户

图6给出了一个基于SOA的HIN架构的图形化描述。

图6. HIN 参与者

建立可持续的HIN

实现HIN的关键挑战是建立一个可持续的财务模型。其中，运营网络的成本和风险是医疗社区可以承受的。它提供了一个连续的价值来源来证明维护网络当前运营成本的正当性。即使某些社区，政府（当地的、地区的、国家的）为社区利益提供了大量资助，物质方面仍需考虑成本、价值和可持续性问题。

使用医疗数据集成遗留机制实现和长期支撑一个HIN在财务上并不可行。如果每次新医院、药房或者政府机构加入HIN都要开发一个新的点对点或者代理接口，如下的架构和成本问题就会产生，如图7所示。

图7. 点对点/代理集成架构图

基于点对点或者代理集成方式的问题在于，接口数量相对于HIN成员数量以指数规模递增。一项由加拿大Health Infoways1完成的研究清楚地表明，从成本和可持续性角度来说，以这种遗留方式来做集成是多么的没有价值：

• 单次集成成本：简单 = 32,000加拿大元（CAD）；中等 = CAD 95,000；复杂 = CAD 190,000
• 加拿大有38,783个系统
• 各种集成类型的数量：简单 = 4,527；中等 = 20,081；复杂 = 14,175
• 这会产生15亿个系统接口点
• 成本总计约是1840亿CAD

从成本上看，加拿大的这个例子清楚地表明，用点对点集成架构建立一个大规模HIN是完全不可行的。就在本文撰写时，美国许多州和地方政府正在建设234个区域性HIN，每个HIN大概花费2~5百万美元。超过70％的初期启动资金都花在了将第一个医院和保险公司接入到信息网络中。如果想让HIN能够承担它们的长期支出，这种经济模式必须改变。

HIN的SOA实施指南

使用SOA作为HIN的集成架构，集成成本会显著降低，并能够建立一个医疗社区可承受的价值来源。要达到这个目标，HIN的服务架构必须：

• 简化和减少网络中建立互操作的接口点数量
• 将架构、基础设施、软件以及相关业务服务作为一个内聚单元
• 可部署于医院、实验室、药房和保险公司，以及一个共享HIN中
• 支持遗留系统，包括当前和发展中的医疗数据格式标准
• 在成本、复杂度、实用性和可适应性等方面，能根据不同规模医疗组织进行调整。

在HIN中应用SOA技术带来的第一个关键好处就是简化了数据互操作。尽管医疗行业有数据格式的行业标准（如HL7），但是这些标准的一个根本问题在于它们在不同软件中格式不一样。因而，HIN的首要目标应该是标准化软件解释，实现在网络上进行医疗数据的表示和翻译。实现这一目标最经济的做法是使用一组表示医疗数据的标准化核心业务服务集合。

如图8所示，使用SOA服务管理标准化的数据表示（“规范数据表示”，canonical data representation）的实现将使系统接口点数量减少一个数量级。HIN中所有参与者和数据中心不是为网络中每个参与者创建和维护一个系统接口，而是将它们的系统格式转换成这个服务指定的格式。服务为每个需要交换的数据（例如患者、提供者、预约、治疗安排等等）都定义了标准格式。

图8. SOA集成架构

这个基于规范的SOA系统集成架构减少了超过65％的集成点数量和代价。SOA核心业务服务管理的规范数据表示实现了：

• 独立于任何特殊端点应用的结构
• 在实现上将信息架构与技术基础设施分离
• 确保实现的一致性的精确消息定义
• 业务流程驱动数据的可视化
• 为特殊业务交易清楚地定义唯一的应用

利用那些构建在规范数据表示之上的服务，HIN只需依赖数据的标准化软件解释就能使网络中所有参与者共享和消费系统功能。这样HIN就能提供共享服务，例如提供者注册、医疗术语转换、主患者索引、以及代表整个医疗社区的病历定位服务，而不用使这些服务必须部署或复制到每个参加HIN的组织的数据中心中。图 9描述了这个架构以及一些共享服务的例子。

图9. 可能的HIN服务集合

使用第三章和第四章中描述的企业服务总线技术，HIN中的数据中心和每个参与组织都可以互相发布和消费对方的服务，编排工作流以快速支持网络中新的业务交易以及参与者间的交互。另外，在服务总线架构上的服务容器结构使一个医院、实验室、药房或者保险公司中现有的临床系统和管理系统直接“面对”XML Web服务并参与这个架构。这允许以一种递增和迭代的方式实现SOA好处，从而利用现有技术投资。图10显示了这种服务总线架构。

图10. 服务总线架构

如这些例子所示，使用SOA技术可以充分降低任何规模HIN的实现成本。SOA以软件服务的形式给医疗社区交付特性，这些软件服务提供了一个行进中的价值源，而不仅仅是一个简单的门户和集成患者数据记录的数据库。

通过SOA扩展电子病历

截至目前为止，在这一章中我们花了相当的篇幅来讨论使用SOA技术可以如何改进医疗信息系统的集成和显著减少这些事情的成本；但是，全世界临床信息自动化、电子化的平均总数还是很小。

为了自动收集、发布及验证患者病历，世界各地许多医疗机构正计划或者已完成了电子病历（Electronic Medical Records ，简称EMR）系统。尽管这项技术在商业上具备可用性已有30年，但是世界上临床医生在日常工作中采用EMR的平均数低于20％。图11总结了这种低采用率的原因，并显示了SOA可以如何帮助增进EMR的采用。

图11. 电子病历（EMR）系统的应用障碍

采用SOA技术可以直接解决图11所述的很多问题。

首先，很多电子病历被设计成跨部门和医疗岗位的企业应用。这么广的应用范围给软件带来的最常见影响是屏幕中布满标签页、数据字段、按钮及其它用户界面元素，这对那些平时工作中只需某个功能片断就可以完成手头任务的人们来说，培训和使用都带来了很大的复杂性。一个基于SOA的 EMR能够轻易地支持很多用户界面窗体，因为核心数据和业务逻辑功能与表现层是松耦合的。因此，ISV开发者或者潜在的即便是一个具有足够工程才能的IT 部门都可以按部门与（或）工作类型提供特定的用户界面，无需复制EMR引擎的核心处理和数据验证。

其次，由于基于SOA的EMR被构造为一套数据与商业规则的组合软件服务，工作流可以很容易地支持各组织或者部门客户化需求，无需求助于一种“最佳组合（best-of-breed）”部署——在其中，各部门几乎从各软件开发商那里复制了一个应用程序栈，因为每个开发商都只擅长某个特殊的部门工作流。它不仅不止一次的为组织节省花在相同核心技术上的资金，而且随着一个公共服务基础设施在这个基于SOA的EMR中不断重用，还显著降低了集成和维护成本

。

最后，如文中所讨论的，SOA架构可以使一个EMR系统或者医院流程的整个功能被外包，托管于一个共享数据中心中，作为工具被消费。例子包括那些SOA增强型HIN提供的功能，例如受控的医疗词汇转换、主患者索引服务、患者病历定位服务、保险确认、索赔处理以及转院管理。这其中的关键优势在于这些功能的实现和维护成本。通过外包和托管使用模型（有时被称为实用计算或应用服务提供商），软件功能往往可以以相当低的总成本获得。这是因为服务器、数据中心基础设施、软件许可证和工程成本由许多消费者分担，而不是像EMR部署在内部数据中心时那样被每个消费者反复地负担。如果使用 SOA技术与工艺，一个医疗IT组织可以快速地整合内部托管系统，技术上直接与外包系统一致。图12描述了这个架构。

图12. 集成托管和外包应用的架构

要了解关于使用SOA改善医疗系统性能的更多信息，请参考由Girish Juneja、Blake Dournaee、Joe Natoli与Steve Birkel合著，Intel出版社出版的《面向服务架构揭秘》（《Service Oriented Architecture Demystified 》）。

关于作者

Girish Juneja是Intel SOA产品部门的主管，有超过15年工程和技术策略方面的经验。

Blake Dournaee目前是Intel SOA产品部门的产品经理，Blake是撰写第一本关于XML安全书籍的作者之一。

Joe Natoli是Intel数字医疗集团的平台架构师。Joe是Intel信息技术部门的SOA战略与规划研究计划的资助成员和架构师。

Steve Birkel是Intel信息技术部门的首席技术架构师，在那里他领导技术基础设施战略与企业集成的开发。

译者注：为了与国内的官方新闻用语相符，部分“health”翻译成了“医疗”。

查看英文原文：Improving Performance of Healthcare Systems with Service Oriented Architecture

Intel公司版权所有。本文取自Girish Juneja、Blake Dournaee、Joe Natoli和Steve Birkel的《面向服务架构揭密（Service Oriented Architecture Demystified）》。欲知详情，请访问Intel出版社网站：http://www.intel.com/intelpress/sum_soa.htm.