指定、檢查以及處理約束的能力對於確保醫療信息的整體質量至關重要。由 XML Schema 描述的 Health Level 7 (HL7) Clinical Document Architecture (CDA) 允許通過 HL7 Templates 進行約束的指定，而這可以在 Schematron 內實現。Schematron 可通過 XSLT 應用。本文給出了在 HL7 CDA 內進行約束檢查所需的軟硬件解決方案。這兩個解決方案的展示在一個 SOA 內進行，這個 SOA 同時包括了成功的和失敗的 XML 模式和 Schematron 約束檢查。本文對在 HL7 CDA 內應用約束進行了評估並給出了一些約束的類別，這些類別值得進一步深入研究。評估的結果顯示，通過 Schematron 指定、檢查以及處理約束是對 XML 模式處理的一種補充。這兩種約束方式都非常有用和實用，因而應得到進一步的應用。
簡介
常用縮寫詞
SOA：面向服務架構（Service OrIEnted Architecture）
XML：可擴展標記語言（Extensible Markup Language）
XSLT：可擴展樣式表轉換（Extensible Stylesheet Transformations）
兩方或多方之間交換特定於行業（比如銀行、保險或金融）的信息在如今的商業環境中變得越發重要。為了能夠進行信息交換，各方必須就信息的格式達成一致，而這一般要通過由業界公會定義的特定於行業的格式實現。這樣的要求對於醫療行業同樣適用。在醫療標准和規范（比如 Health Level 7 (HL7) Clinical Document Architecture (CDA)）內定義的診斷信息的結構對於醫療信息的交換非常重要。HL7 CDA 指定了診斷文檔的結構和語義。本文的討論所基於的就是 HL7 CDA。不過，本文的試驗研究所提及的這些約束概念完全可以進一步應用於其他行業領域。除了對展示信息的結構要達成一致外，還要提供一種機制來確保信息的正確性以及完整性，這也很重要。比方說，在金融行業，Financial Product Markup Language (FpML) 可用來描述金融衍生品，它還提供了超出了 FpML XML 模式內所指定的那些規則之外的額外的驗證規則，這些規則可用來確保數據的質量。HL7 CDA 允許使用 HL7 Template 針對特定的臨床場景對 CDA 進行約束並提供一種驗證規則集。這些規則集的目的就是為了借助約束的應用來改善經過 HL7 CDA 文檔交換的醫療信息的質量。
本文對 HL7 CDA 上下文環境中的約束進行了分類，並對指定、檢查和處理約束的能力進行了評估。約束在醫療信息中的應用通過兩個不同的解決方案展示，這兩個方案的實現也是本文要討論內容的一部分。第一種方式完全基於軟件，而第二種方式則要利用 XML 處理硬件。要介紹的這兩個解決方案都在一個 SOA 環境中展示。解決方案的 Web 服務方面可以使驗證後的數據對醫療服務提供者可用，這些提供者可能並不具備員工或設備來以其他方式訪問這些數據。並且，本文還介紹了當發生約束失敗時該如何生成用戶友好的消息。
約束
本節要討論的約束的分類是受 Financial Derivatives Consistency Constraint Classification 分類的啟發。圖 1展示了在 HL7 CDA 文檔的上下文中有可能發生醫療信息不一致性的地方：(1) 在本地需求的實現中（類型 I); (2) 在 HL7 CDA 文檔的交叉檢查中（類型 II）；(3) XML 格式的引用數據檢查（類型 III） 和 (4) 非 XML 格式的引用數據檢查（類型 IV）。
圖 1. 基於 Consistency Checking of Financial Derivatives Transactions的 HL7 CDA 約束分類
下一節描述了不一致信息的不同來源，給出了一些示例並展示了為避免不一致所采用的約束的一些示例實現。這些約束的實現基於了這樣一個事實，即 HL7 CDA 文檔均以 Extensible Markup Language (XML) 編碼。
類型 I（結構要求）。這些約束確保醫療信息的結構。對於 HL7 CDA，此結構是通過 HL7 提供的一個 XML 模式指定的。這之後，可以使用這個 XML 模式驗證 HL7 CDA XML 文檔實例，它決定了 HL7 CDA 文檔是否包含了適當的等級結構中所要求的信息。有時候，由 XML 模式定義的結構並不足以傳達特定要求，比如本地機構中的信息系統。假設，一個給定的機構要求一個實例文檔中必須出現特定的一些信息，而這卻被 HL7 CDA XML 模式視為可選。這時，可以用兩種方式來解決這個問題。第一種方式是修改現有的 XML 模式（參見 清單 1）。
清單 1. 原始 HL7 CDA XML 模式的節選 <xs:element name="code" type="CD" minOccurs="0" maxOccurs="1" />
修改現有的 XML 模式來強制而不是可選地定義此元素（參見 清單 2）。
清單 2. 修改後的 HL7 CDA XML 模式的節選 <xs:element name="code" type="CD" minOccurs="1" maxOccurs="1" />
第二種方式是用 Schematron 規則來補充這些 XML 模式。Schematron 允許在 HL7 CDA 文檔的內容中指定斷言，而且通常都是通過 XSLT 應用。在本例中，使用 Schematron 來決定特定元素在 XML 文檔中的存在，無需修改原始的 XML 模式（參見 清單 3）。
清單 3. 節選的 Schematron 規則 <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）。
清單 4. 檢查共存約束的 Schematron 規則的節選 <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 格式。
圖 2. 軟件方式概覽
清單 5 和 6顯示了從數據庫系統中返回的失敗的約束示例。另一個利用數據庫系統的可行方式是使用 XForms在客戶機上直接應用約束，使用 XForms是因為它們具有應用 Schematron 的能力。
清單 5. 一個 XML 模式驗證失敗的節選 XML document contains an element "x" that is not correctly specifIEd.
Reason code = "37". SQLCODE=-16196, SQLSTATE=2200M, DRIVER=3.50.152
清單 6. Schematron 驗證失敗 <?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 格式。
圖 3. 硬件方法概覽
清單 7和 8 顯示了從硬件設施生成的失敗的示例約束。
清單 7. XML 模式驗證失敗 <?XML version="1.0" encoding="UTF-8"?>
<error>
http://dp:2/: cvc-wildcard 2: unrecognized element {urn:hl7-org:v3}x
</error>
清單 8. Schematron 驗證失敗 <?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 驗證規則集的參考實現的基礎。