简介： 很多卫生保健组织都在积极地向 IT 解决方案的面向服务的体系结构（Service-Oriented Architecture，SOA）寻求帮助，以促进行业的转型。但如何确保为这些活动而交付的解决方案是否满足业务用户的需求，将会面临极大的挑战。分析业务远景和需求，并将其与技术联系起来，这是 SOA 实现中最为重要的一部分。本文将以卫生信息交换网络为例，介绍管理此类需求的一种方法和相关的最佳实践，说明如何在引入 SOA 的过程中使用软件工具来确保技术投资与业务目标保持一致。

将 IT 与卫生信息交换保持一致所面临的挑战

自从美国政府提出要求到 2014 年全国都采用电子医疗记录（Electronic Medical Record，EMRs）的战略计划（请参见参考资料部分提供的指向文章“Bush Touts Plan for Electronic Medicine”的链接）后，卫生保健信息的共享需求急剧增加。各个卫生保健组织内的卫生信息交换显然并不足以满足患者的要求和充分公开卫生服务的需求。为了提高病患护理的质量，减少成本和提高提供服务的效率，卫生保健数据需要在跨社区和地区间进行交换。此外，为了在疾病管理和疾病发作控制方面提高公众健康，需要在整个国家（甚至跨国）方便地获得所共享的卫生信息，如图 1 中所示。几年前非典型肺炎 (SARS) 爆发充分表明了对卫生信息随需应变可用性的需求

图 1. 卫生保健信息交换网络

不过，不要低估构建这样的卫生信息网络所面临的挑战。需要有效的信息交换网络才能够满足所有参与者的需求：患者、卫生保健服务提供商、健康保险公司、政府和其他参与其中的组织。同时，这还要求所有各方向网络公开服务供其他人使用，并采用行业标准来支持卫生保健数据的集成和使用。

技术和真正的卫生信息交换业务需求之间存在多个断层：

从 IT 角度而言，在这样大的范围内实现卫生信息共享的工作期间，很多 IT 团队将开发用于内部使用或开源用途的大量组件和资产。这就意味着技术资产的量将继续增加，但却缺乏公共库来对组件和资产进行收集和管理。这可能会导致出现很多重复构件。

从业务战略的角度而言，卫生信息网络的需求将由业务用户根据需要按自顶向下的方式进行标识。但其中很多人并不能完全了解可用于支持这些需求的启用了 SOA 版本的技术。这就导致在业务战略和基础技术之间存在互相理解的差异，而且这将继续成为卫生保健转型工作中很多 SOA 活动的主要障碍。

卫生保健信息共享项目的很多常见需求通过不同的项目在网络的不同级别捕获，在收集和维护方面存在重复工作。

接下来让我们看一个例子，以说明为何需要收集和管理需求。卫生保健信息交换网络需要能够对患者进行注册和标识，然后存储并注册该患者的数据。如果没有可共享的需求池，这些标识和收集需求的工作需要进行额外的步骤和工作（否则就可能丢失重要信息）。另外，还需要支持此类系统有效工作的 IT 需求来对业务需求进行补充。

正如众多研究论文和调查中指出的，在定义和管理需求方面的失败可能会导致软件解决方案开发项目的失败（请参见参考资料部分提供的指向“Why Software Fails”和“Improving time-to-market using SDL tools and techniques”的链接）。尽管规范的工程需求很容易通过先进的需求软件工具（如 IBM? Rational? RequisitePro?）处理，但在很多复杂项目中，需求以手动方式管理，占用了大量的劳动成本，而且缺乏全面利用其潜能的深度和广度（请参见参考资料部分提供的指向“Software Technology in the Health Care Industry”的链接）。卫生保健业务需求与支持业务需求的技术需求之间的这个区别如图 2 中所示。以结构方式捕获和分析需求，将需求与资产建立联系，并管理其间的动态关系，这些工作在解决方案开发周期中都不能忽视。这就是 SOA 所尝试应对的挑战。

图 2. 卫生保健业务目标与现有卫生保健 IT 资产之间的差距

本文将介绍可通过使用需求工程方法和工具来缩小这个差距的解决方案。

SOA 的业务需求管理和实现

很多 IT 项目的失败都是由于需求管理糟糕造成的。（请参见“参考资料”中指向“Why Software Fails”和“Managing emerging software technologies: a technology transfer framework”的链接）。需求管理失败的最常见因素是不现实或不明确的项目目标以及定义糟糕的系统需求。最后很容易出现“追逐技术”的情况，而没有将重点放在实现满足业务需求的系统上。工程需求最近已发展成为软件工程领域的一项至关重要的活动，而且这方面仍然是研究社区的重点之一（请参见参考资料中列出的参考书目和指向“The fundamental nature of requirements engineering activities as a decision-making process”和“Requirement acquisition for rapid application development”的链接）。市场上可帮助处理系统开发的需求流程的商品化软件产品日益增多（请参见参考资料给出的指向“Requirements engineering for COTS based systems”的链接）。虽然人们对于采用 SOA 的解决方案开发的好处越来越重视，SOA 的采用也越来越广泛，但系统管理 SOA 解决方案的需求方面的各种做法尚未在卫生保健行业得到广泛应用。由于卫生保健业务流程及在这些流程中交换的卫生数据的复杂本质，在捕获和分析需求方面面临着巨大的挑战。

SOA 是一种 IT 体系结构风格，支持面向服务，允许将业务流程作为关联的服务进行集成，以支持业务敏捷性。SOA 的主要目标之一是让组织具有足够的响应能力和灵活性，以便采用新业务战略和创建新服务来克服今天大家所知的业务变更的动态性本质所带来的挑战（请参见参考资料中的“Service-oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap”）。SOA 生命周期从安排专家进入业务服务开发流程以了解业务目标和需求开始。这样的做法很合理，因为在 SOA 实现过程的这个位置，重点是以开发业务需求为目的的业务驱动的端到端迭代过程。

业务需求管理是 SOA 生命周期的第一步。这是构建卫生保健信息交换系统的一个关键点。这些需求可帮助确保卫生保健目标和服务需求在卫生保健信息网络内及各个网络间向所有涉众共享，并得到正确执行。

建立将卫生信息交换需求与 IT 关联的模型

接下来让我们看看在将业务需求映射到交付支持 SOA 的解决方案所需的基础技术时所涉及的步骤：

步骤 1. 建立可重用层，以将卫生信息交换的业务功能与 IT 资产联系起来

本文中所描述的方法使用需求管理软件（本例中为 Rational RequisitePro）作为需求存储库、分析和工程工具，您需要在 Rational RequisitePro 中建立卫生保健解决方案组件层。为此，您必须：

在 Rational RequisitePro 中收集、组织卫生保健互操作性所需的所有卫生保健相关的功能和非功能性能力，并进行优先排序。
捕获并组织现有 IT 资产来支持卫生保健互操作性，包括解决方案组件、产品和服务。这些资产由不同的实体开发，其来源非常广泛，如开源资产、行业标准、内部资产、业务合作伙伴提供的资产和通用 IT 资产。

使用 Rational RequisitePro 提供的可跟踪性功能将每个功能组件映射到将支持此功能的适用 IT 资产。

RequisitePro 充当关系存储库，存储所有的功能型和非功能型能力以及卫生信息交换网络的基础资产。此工作建立一个中间层，用于在抽象业务需求和技术资产之间建立联系。建立了这个层以后，可以将其重用于需要特定于卫生保健资产的各种项目。

步骤 2. 从参与卫生信息交换的各个实体中捕获业务需求

目前在社区、州和地区级别已经进行或正在开发很多卫生信息交换项目。进行这方面工作的组织包括地区卫生信息组织（Regional Health Information Organization，RHIO）、美国国家卫生信息网（National Health Information Network，NHIN）和很多私营组织赞助的卫生信息交换项目。其中很多项目都可能具有相同的需求，因此需要相同的技术。例如，以电子方式安全共享患者数据需要所有这些活动。另一个例子是使用主病患索引对患者进行标识。不过，各个组织仍然投入了大量的精力以传统方式为不同的卫生保健解决方案创建经常使用的需求，而没有认识到这些工作可能已经由其他人完成了，或者可能会有更好的办法对其进行共享。因此，卫生信息网络使用软件工程池构造一个公用需求池将是很有意义的，可以促进需求的重用。

在开发卫生保健解决方案的过程中，业务目标通常在较高的级别由决策者定义，而详细的业务需求由领域专家、业务分析人员和流程所有者定义。这往往会在业务目标和可操作需求之间引入断层。为了确保这些活动的解决方案满足业务需要，应该对需求进行管理，以针对一个或多个高级业务目标进行验证，并能追溯到这些业务目标。图 3 显示了如何使用 Rational RequisitePro 整合卫生信息交换的业务需求并对其进行优先排序。

通过使用这种类型的方法，不仅可以捕获、评估和协调这些需求，还能够使用工具提供的变更管理功能进行治理，如版本控制与跟踪修订历史以及团队讨论等。

通过上面的工作可以创建与活动远景一致的重用需求基准。图 3 对此进行了说明。

图 3. 整合卫生信息交换的业务需求并进行优先排序

步骤 3. 将需求映射到功能性能力

有了步骤 1 中建立的可重用技术层和步骤 2 中建立的业务需求层，将业务与技术相关就变得较为容易了。现在您需要将每个需求映射到能够满足需求的 IT 功能。例如，如果查询患者记录 是一项需要的业务功能，则业务架构师可以很容易地将其与门诊文档存储库（查询的数据源）关联起来。不过同时要在符合法律遵从性的前提下完成此业务功能，需要在查询门诊文档时有相应的 审核服务。图 4 显示了映射到卫生保健 IT 功能的这些需求。

图 4. 业务需求与卫生保健 IT 功能的联系可指示业务与技术之间的关系

步骤 4. 将业务目标与需求透明地与技术资产建立联系

建立了需求和 IT 功能之间的关系后，下一步就是要无缝地将业务和技术层连接在一起，如图 6 中所示。通过层次结构，可以很容易地看到哪些目标由哪些业务需求提供支持、由哪项技术完成并通过哪些资产启用（请参见图 5）。

图 5. 通过建立每个层次之间的关系，可以提供从业务视图到卫生保健 IT 视图的透明可跟踪性

图 6 给出了一个树形视图示例，说明如何从技术级别通过业务级别支持和实现检测疾病发作 的高级目标。在这些技术资产中，可以很容易确定 Integrating the Healthcare Enterprise (IHE ATNA) 推出的 Audit Trail and Node Authentication Profile 以及 Open Health Framework (OHF ATNA) 客户机的 Audit Trail and Node Authentication 客户机等开源项目。

图 6. 卫生信息交换的业务目标在 Rational RequisitePro 中向下追溯到卫生健康 IT 资产

使用本文所述的需求模型和方法可产生很大的促进作用，因为工具极大地简化了复杂性，将需求的抽象级别提升到了能够在整个开发周期进行扩展的地步。这样可以在业务所有者和技术人员之间进行更好的沟通，因此能够正确地转换和执行需求，从而得到正确的产品（请参见参考资料部分提供的指向“Aligning Information Technology with Health Information Exchange”的链接）。此外，根据 SOA 的原则，通过这一方式处理的需求可以在整个开发周期中使用，以促进系统设计、构造和测试工作，从而以低成本的方式获得高质量解决方案，缩短整体开发时间。

结束语

要弥合交付卫生保健服务和采用技术之间的差距，这在卫生保健行业采用 IT 来推动医疗实践的进步时是一大挑战。SOA 提供了有效的方法来在创建卫生保健信息交换系统时应对此挑战。业务驱动的 SOA 是一种增量式的方法，可满足卫生保健业务目标、应对其挑战并充分考虑现实。启用了 SOA 的系统首先从了解业务需求开始，然后确定哪些技术将如何满足这些需求。通过本文介绍的 COTS 软件工具，您可以方便地将业务需求与对应的技术需求联系起来，并以系统的方式对其加以管理。您可以将业务需求映射到 IT 功能，并透明地将其与用于满足需求的资产及产品关联起来。此外，此模型中收集的需求和资产可以供很多卫生保健项目重用，而其中的信息共享至关重要。此方法可以从业务必要性方面推动项目开发，从而确保卫生保健行业转型过程中交付的解决方案更为成功地满足业务目标，并同时完全使用可用的卫生保健资产来减少成本。