简介

两方或多方之间交换特定于行业（比如银行、保险或金融）的信息在如今的商业环境中变得越发重要。为了能够进行信息交换，各方必须就信息的格式达成一致，而这一般要通过由业界公会定义的特定于行业的格式实现（参见 Industry Formats and Services with pureXML）。这样的要求对于医疗行业同样适用。在医疗标准和规范（比如 Health Level 7 (HL7) Clinical Document Architecture (CDA)）内定义的诊断信息的结构（参见 The Clinical Document Architecture and the Continuity of Care Record: A Critical Analysis）对于医疗信息的交换非常重要。HL7 CDA 指定了诊断文档的结构和语义（参见 HL7 Clinical Document Architecture, Release 2）。本文的讨论所基于的就是 HL7 CDA。不过，本文的试验研究所提及的这些约束概念完全可以进一步应用于其他行业领域。除了对展示信息的结构要达成一致外，还要提供一种机制来确保信息的正确性以及完整性，这也很重要。比方说，在金融行业，Financial Product Markup Language (FpML) 可用来描述金融衍生品，它还提供了超出了 FpML XML 模式内所指定的那些规则之外的额外的验证规则，这些规则可用来确保数据的质量（参见 Consistency Checking of Financial Derivatives Transactions）。HL7 CDA 允许使用 HL7 Template 针对特定的临床场景对 CDA 进行约束并提供一种验证规则集（参见 Layered Constraints: The Proposal for HL7 Healthcare Templates）。这些规则集的目的就是为了借助约束的应用来改善经过 HL7 CDA 文档交换的医疗信息的质量。

本文对 HL7 CDA 上下文环境中的约束进行了分类，并对指定、检查和处理约束的能力进行了评估。约束在医疗信息中的应用通过两个不同的解决方案展示，这两个方案的实现也是本文要讨论内容的一部分。第一种方式完全基于软件，而第二种方式则要利用 XML 处理硬件。要介绍的这两个解决方案都在一个 SOA 环境中展示。解决方案的 Web 服务方面可以使验证后的数据对医疗服务提供者可用，这些提供者可能并不具备员工或设备来以其他方式访问这些数据。并且，本文还介绍了当发生约束失败时该如何生成用户友好的消息。

约束

本节要讨论的约束的分类是受 Financial Derivatives Consistency Constraint Classification 分类的启发（参见 Consistency Checking of Financial Derivatives Transactions）。图 1展示了在 HL7 CDA 文档的上下文中有可能发生医疗信息不一致性的地方：(1) 在本地需求的实现中（类型 I); (2) 在 HL7 CDA 文档的交叉检查中（类型 II）；(3) XML 格式的引用数据检查（类型 III） 和 (4) 非 XML 格式的引用数据检查（类型 IV）。

下一节描述了不一致信息的不同来源，给出了一些示例并展示了为避免不一致所采用的约束的一些示例实现。这些约束的实现基于了这样一个事实，即 HL7 CDA 文档均以 Extensible Markup Language (XML) 编码。如果需要，在本文的 参考资料部分，还可以找到对 XML Schema 或 Schematron 的介绍的相关链接。

类型 I（结构要求）。这些约束确保医疗信息的结构。对于 HL7 CDA，此结构是通过 HL7 提供的一个 XML 模式指定的。这之后，可以使用这个 XML 模式验证 HL7 CDA XML 文档实例，它决定了 HL7 CDA 文档是否包含了适当的等级结构中所要求的信息。有时候，由 XML 模式定义的结构并不足以传达特定要求，比如本地机构中的信息系统。假设，一个给定的机构要求一个实例文档中必须出现特定的一些信息，而这却被 HL7 CDA XML 模式视为可选。这时，可以用两种方式来解决这个问题。第一种方式是修改现有的 XML 模式（参见 清单 1）。

				
 <xs:element name="code" type="CD" minOccurs="0" maxOccurs="1" />

修改现有的 XML 模式来强制而不是可选地定义此元素（参见 清单 2）。

				
 <xs:element name="code" type="CD" minOccurs="1" maxOccurs="1" />

第二种方式是用 Schematron 规则来补充这些 XML 模式（参见 参考资料）。Schematron 允许在 HL7 CDA 文档的内容中指定断言，而且通常都是通过 XSLT 应用。在本例中，使用 Schematron 来决定特定元素在 XML 文档中的存在，无需修改原始的 XML 模式（参见 清单 3）。

				
 <assert test="hl7:code"> 
  The necessary information on the code system to 
  identify that the blood parameter is missing. 
 </assert>

类型 II（内部的一致性）。类型 II 的约束评估 HL7 CDA XML 文档实例的内容，因而避免了 HL7 CDA XML 文档内的不一致性。所评估的内容既包括被隔离的值，又包括依赖于同一个 XML 文档内的其他信息的那些值。举个例子，一个约束决定了被编码到 HL7 CDA 文档的血液指标值是否在所允许的参考范围之内。对于血液指标，一些引用值对于男性和女性病人可以是一样的，而其他的一些值则因性别而异。这些约束亦可以以同样的方式指定为类型 I 约束，即通过修改 HL7 CDA XML 模式，或者通过实现 Schematron 规则（参见 清单 4）。

				
 <let name="gender" value="administrativeGenderCode/@code" /> 

 <report test="hl7:code[@code = '718-7'] 
  and (($gender='M' and hl7:value[@value > 17.2 or @value < 13.8]) or 
       ($gender='F' and hl7:value[@value > 15.1 or @value < 12.1))"> 
  Hemoglobin is not within the reference range, which could imply 
  illness of the patient, that needs to be clarified. 
 </report>

XML 模式的例子并未包括，因为目前版本为 1.0 的 XML Schema 并不支持对共存约束的评估。它的后续版本 1.1（参见 参考资料）提供了更多的灵活性。在 XML Schema 版本 1.1 中，可以在 XML 文档内容上定义断言，包括共存约束，但是只能是单一一种 XML 数据类型。对于 XML Schema 1.1 断言，没有统一的方式来为非技术人员提供对定制消息的支持（参见 清单 3）。

类型 III（XML 格式的参考数据）。类型 III 的约束允许定义约束来评估存储在不同的 HL7 CDA XML 文档实例内的内容之间的依赖性。比如，定义工作流内不同 HL7 CDA XML 文档实例间的关系就是这样一个例子。这些关系的理论背景不在本文的讨论范围之内，但本示例中所用的这些关系的其中一个关系是 “append”。“Append” 表明一个 HL7 CDA XML 文档实例补充了另一个现有的 HL7 CDA XML 文档实例，这意味者这些文档本身均不是有效的。只有联合在一起它们才有效。在本例中的这个约束确保了没有违背这种关系，并且这两个 HL7 CDA XML 文档都是可用的。XML Schema 和 Schematron 的示例实现并未包括，因为这些技术不允许在其当前版本中指定类型 III 约束。在 Consistency Checking of Financial Derivatives Transaction中给出了一种通过创建跨文档链接来处理类型 III 约束的方式。W3C 的 Service Modeling Language（参见 参考资料）还包括了通过 deref()扩展函数得到的跨文档约束功能。

类型 IV（非 XML 格式的参考数据）约束的第四个类型是用来评估存储在一个 HL7 CDA XML 文档实例中的值与存储在一个非 XML 数据源中的值之间的依赖性的一类约束。例如，一个非 XML 数据源可以是一个关系表。举个例子，比方说，血液指标的参考值可存储在一个关系数据库表中，并且这些血液指标值要针对存储在这个表内的参考值进行验证。XML Schema 或 Schematron 在当前版本中均不允许指定类型 IV 的约束。

实现

在本节中，前面章节中描述过的使用 XML Schema 和 Schematron 的那些约束将被应用于医疗信息以确保正确性、完整性和一致性。这里介绍了两种不同的方法：一个是基于软件的解决方案，另一个是基于硬件的解决方案。

软件方式第一种方式利用了数据库系统 IBM DB2®的原生 XML 支持，称为 pureXML®。这个数据库能够以一种原生的格式存储 XML 并能提供多种与 XML 相关的功能，例如 XML Schema 验证和通过 XQuery 检索 XML 文档的能力。这种方式（参见 图 2）包含三个组件，它们是：数据库系统、Web 服务和客户机。这个数据库系统之所以支持约束检查，借助的是注册 HL7 CDA XML 模式、根据所注册的模式验证 HL7 CDA XML 文档以及执行 XSL 转换来应用 Schematron 约束的能力。这个场景允许将 HL7 CDA XML 文档实例提交给数据库，在那里约束被应用于 XML 文档实例。此文档被插入到数据库，在这个数据库中，它与验证结果一起被存储为原生 XML 格式。

清单 5 和 6显示了从数据库系统中返回的失败的约束示例。另一个利用数据库系统的可行方式是使用 XForms在客户机上直接应用约束，使用 XForms是因为它们具有应用 Schematron 的能力（参见 参考资料，获取关于 XForms 的更多信息。）

				
 XML document contains an element "x" that is not correctly specified. 
 Reason code = "37". SQLCODE=-16196, SQLSTATE=2200M, DRIVER=3.50.152

				
 <?xml version="1.0" encoding="UTF-8"?> 
 The necessary information on the code system to identify the 
 blood parameter is missing.

硬件方式。第二种方式利用了处理 XML 数据的硬件能力，称为 IBM WebSphere®DataPower®。作为这个解决方案的一部分，此功能包括根据 HL7 CDA XML 模式对 HL7 CDA XML 文档实例进行验证以及通过 XSL 转换应用 Schematron 规则。这种方式（参见 图 3）包括四个不同的组件，它们是：数据库系统、允许在数据库内插入和存储 HL7 CDA XML 文档实例的 Web 服务、执行约束检查的 DataPower 设施以及将 HL7 CDA XML 文档实例提交给硬件设施的客户机。这个客户机可以是任何发出 Web 服务请求的组件，例如，它可以是一个基于 XForms 的客户机，甚或是另一个信息系统。这个场景允许将 HL7 CDA XML 文档提交给 DataPower 设施，所有约束都在那里被应用。在根据 HL7 CDA XML 模式或 Schematron 规则做完验证后，DataPower 设施会将 XML 文档与验证结果一起转发给一个 Web 服务，这个 Web 服务将 HL7 CDA XML 文档实例与验证结果插入到数据库，在这个数据库里，它被保存为一个原生的 XML 格式。

清单 7和 8 显示了从硬件设施生成的失败的示例约束。

				
 <?xml version="1.0" encoding="UTF-8"?> 
 <error> 
  http://dp:2/: cvc-wildcard 2: unrecognized element {urn:hl7-org:v3}x 
 </error>

				
 <?xml version="1.0" encoding="UTF-8"?> 
 <error> 
  Hemoglobin is not within the reference range, which could imply 
  illness of the patient, that needs to be clarified. 
 </error>

观察

使用 XML Schema 和 Schematron 对约束进行指定以及对这些约束的检查允许我们讨论在实现过程中发现的不同点。XML Schema 与 Schematron 最明显的区别就是在对类型 I 的结构性约束的检查过程中产生的错误消息的质量。根据 HL7 CDA XML 模式对 HL7 CDA XML 文档实例进行验证的观察，正如在之前的两种方式中所展示的，都是通过一个 XML 解析器进行的。并且，这两种情况下的结果错误消息也都是由 XML 解析器生成的。参见清单 5和 7。这些错误消息对非技术人员并不是很有用。通过特定于行业的编辑器创建 XML 文档的人员以及探究为何 XML 文档未能执行约束检查的人员通常并不一定是技术人员。

通过 XML 解析器生成的错误信息的不友好性是一个众所周知的问题。Customized Document Validation to Support a Flexible XML-based Knowledge Management Framework中介绍了一种替代方法。该方法描述了一种验证技术来补充现有的 XML 模式验证，通过提供用于 XML 模式验证失败的特定软件错误处理程序，提供了在错误消息定义方面的灵活性。另一个可以提高消息质量的方法是为 XML 解析器收集 XML 模式注释信息并将其包括在错误消息中，这些注释信息常常出现在工业标准模式中。此外，Schematron 允许定义定制的错误消息。示例请参见清单 6和 8。

此外，Schematron 可以为 XML 文档实例中的某个上下文环境定义约束，使得我们可以为特定类型的违例以及特定的用户与工具设计非常具体和有针对性的错误消息。修改一个 XML 模式来并入额外的本地约束可能并不总是那么直观或行得通。随着 XML 模式的发展，可能需要将这些额外的本地约束重新应用到新的 XML 模式。有了 Schematron，可以将额外的规则添加到另一个 Schematron 规则集中，这比修改 XML 模式要简单得多。您可以根据处理和组织的需要来分别地应用不同的 Schematron 规则集。观察到的另一个区别是在 XML Schema 或 Schematron 中定义的约束在应用方面的灵活性。当应用由 XML Schema 定义的约束时，必须要遵从 “非全有即全无” 的原则，而 Schematron 则允许部分应用这些规则。由 Schematron 定义的约束在应用方面的灵活性可以让我们根据当前的需来应用约束。举个例子，比方说，只需要检查某种类型的约束，例如结构性约束。又如，只有 HL7 CDA XML 文档中的某些部分需要检查。

本文中的另一个观察就是 Schematron 与 XML Schema 不足以指定所有被标示的约束。XML Schema 或 Schematron 都不允许跨不同的 XML 文档（类型 III）规定约束或在一个 XML 文档与非 XML 数据源（类型 IV）之间规定约束。

结束语

本文介绍了约束的分类，之后展示了 XML Schema 和 Schematron 是互补的，并可被用来指定结构性约束及 HL7 CDA XML 文档实例内容上的约束。实现部分则展示了 XML Schema 是一种很好的、很成熟的、定义 XML 文档结构的方式。但是在 XML Schema 解析器的验证期间生成的错误消息的质量可被显著改进。Schematron 依然是对 XML 模式验证的一种补充，提供了消息定制以及当模式发展时，一种实现扩展性以及规则集组合的简便方式。XML Schema 1.1 通过数据类型内的断言将约束的概念带入了 XML Schema，不过，不能进行消息定制。本文展示了能够处理 Schematron 和 XML Schema 的商业软硬件解决方案。需要进一步工作的领域包括在大量数据上执行各种 约束检查手段以及研究 XML 约束检查方法在其他行业领域的可用性。

总之，使用 XML 模式指定约束非常适合于实现基本的文档结构，比如 HL7 CDA。Schematron 则非常适合于局部结构和 HL7 CDA 内容约束，而这又非常适合于 HL7 模板。本文讨论了一些不能由 XML Schema 和 Schematron 实施的约束（类型 III 和类型 IV）。Schematron 满足了 HL7 Templates 方面的两个主要要求。它可被用来指定除 HL7 CDA XML 模式外的结构约束，并且它允许指定约束来评估 HL7 CDA XML 文档的内容，这可以是针对特定诊断情境的那些约束。Schematron 可以是 HL7 Templates 验证规则集的参考实现的基础。

参考资料

学习

• Layered Constraints: The Proposal for HL7 Healthcare Templates（Liora Alschuler，Robert H. Dolin，Sandy Boyer，Charlie Mead 和 Peter Elkin）。在 XML 2008，2002 年 12 月 8-13，美国马里兰州巴尔的摩，2002。
  
  
• HL7 Clinical Document Architecture, Release 2（Robert H. Dolin，Liora Alschuler，Sandy Boyer，Calvin Beebe，Fred M. Behlen，Paul V. Biron 和 Amnon Shabo）。 American Medical Informatics Association 杂志，13:30-39，2006。
  
  
• Consistency Checking of Financial Derivatives Transactions（Daniel Dui，Wolfgang Emmerich，Christian Nentwich，and Bryan Thal). In Objects, Components, Architectures, Services, and Applications for a Networked World（Mehmet Aksit，Mira Mezini 和 Rainer Unland，编辑），International Conference NetObjectDays 2002，7-10 October 2002，Erfurt，Germany，Revised Papers，Computer Science 的 2591 期 Lecture Notes。Springer，2003 年。
  
  
• The Clinical Document Architecture and the Continuity of Care Record: A Critical Analysis（Jeffrey M. Ferranti，R. Clayton Musser，Kensaku Kawamoto 和 W. Ed Hammond）。American Medical Informatics Association 杂志，13:242-252，2006 年。
  
  
• Customized Document Validation to Support a Flexible XML-based Knowledge Management Framework（Timothy P. Hanna，Roberto A. Rocha，Nathan C. Hulse，Guilherme Del Fiol，Richard L. Bradshaw 和 Lorrie K. Roemer）。 AMIA 2005 年年会会议录，2005 年 10 月 22-26 日，美国华盛顿，第 291-295 页，2005 年。
  
  
• 通过 Data Web Services 使用面向 pureXML 的 Universal Services（Susan Malaika 和 Christian Pichler，developerWorks，2008 年 8 月）：使您的 pureXML 列能被 Web 服务操作轻松访问。
  
  
• Industry Formats and Services with pureXML(alphaWorks)：本文展示了用一个 DB2 9 pureXML 数据库进行端到端的 XML 数据交换，通过 RESTful generic Web 服务进行检索，通过 Atom 提要和启用了 XForms 功能的浏览器提供用户交互。
  
  
• Clinical Document Architecture（Health Level Seven）：更多地了解这个文档标记标准，它指定了诊断文档的结构和语义以便于交换。
  
  
• ISO Schematron（Schematron）：了解这种语言是如何进行 XML 文档内模型存在与否的断言的。
  
  
• XML Schema 1.1（World Wide Web Consortium）：研究 XML Schema 如何能定义 XML 文档的结构、内容和语义。
  
  
• XForms 1.0（World Wide Web Consortium）：用 XForms 创建独立于设备的表单，它将传统的 XHTML 表单分为三个部分 —XForms 模型、实例数据和用户界面。表示同内容分离开后，减少了服务器往返和脚本编写。
  
  
• SML (Service Modeling Language)（World Wide Web Consortium）：综合 SML 和 XML Schema 及 Schematron 来为复杂服务和系统建模，包括结构、约束、策略和最佳实践。
  
  
• IBM XML 认证：了解如何成为 IBM 认证的 XML 和相关技术的开发人员。
  
  
• XML 技术库：访问 developerWorks XML 专区，获得广泛的技术文章、技巧、教程、标准和 IBM 红皮书。
  
  
• developerWorks 技术事件 和 网络广播：随时关注技术的最新进展。
  
  
• 技术书店：浏览有关本文所述主题以及其他技术主题的图书。
  
  
• developerWorks podcasts：收听针对软件开发人员的有趣访谈和讨论。
  
  

获得产品和技术

• IBM 产品评估版：下载或 在线试用 IBM SOA Sandbox并开始尝试使用来自 DB2®、Lotus®、Rational®、Tivoli®和 WebSphere®的应用程序开发工具和中间件产品。
  
  

讨论

• XML 专区讨论论坛：参与任何与 XML 有关的讨论。
  
  
• developerWorks blogs：查看这些 blog 并加入 developerWorks 社区。
  
  

作者简介

Susan Malaika 是 IBM Information Management Group（属于 IBM Software Group）的一名高级技术人员。她的专长包括 XML、Web 和数据库。她曾在 Global Grid Forum 开发过支持网格环境数据的标准。她与人合作出版了关于 Web 的专著，发表了关于事务处理和 XML 的文章。她是 IBM Academy of Technology 的成员。

Christian Pichler 是 Research Studios Austria 的高级研究员，从事与 eGovernment 和 eBusiness 相关的各种项目。他拥有奥地利 Technical University of Vienna 的计算机科学硕士学位，当前正在攻读计算机科学博士学位，主要关注互操作性系统。

为本文评分

评论

回页首

内容

• 简介
• 约束
• 实现
• 观察
• 结束语
• 参考资料
• 作者简介
• 建议