健康檔案數(shù)據(jù)驗證

張旭峰，姚志洪,2

（1.上海生物信息技術(shù)研究中心，上海 200235；2.中科院上海健康科學(xué)研究所，上海 200025）

0 前言

隨著信息技術(shù)的發(fā)展，建立了大量的醫(yī)療信息系統(tǒng)，但這些信息系統(tǒng)彼此獨立且互不兼容，彼此間無法共享患者健康信息。因此，患者在不同地方看病時，往往需要做重復(fù)的檢查，無形中加重了患者的負擔(dān)，也導(dǎo)致了醫(yī)療資源的浪費。這種信息無法交互導(dǎo)致的醫(yī)療資源浪費，在國外也很嚴重[1,2]。為解決這個問題，各國都在做相關(guān)的信息標準化的嘗試，比如美國的HL7標準[3,4]，歐洲的openEHR規(guī)范[5,6]。其中HL7是自頂向下構(gòu)建信息模型，先由專家構(gòu)建出完整的抽象模型（HL7中為RIM模型），然后根據(jù)實際應(yīng)用領(lǐng)域選擇部分模型并加以擴充（HL7中為DMIM和RMIM模型）。而openHER則是自底向上構(gòu)建模型，先確定最基本的模塊，然后針對不同領(lǐng)域選取模塊進行組裝，如果在組裝時發(fā)現(xiàn)沒有相應(yīng)的基本模塊，則加以擴充。自頂向下構(gòu)建方式的優(yōu)點是抽象出的核心模型（如HL7中的RIM模型）比較穩(wěn)定，不會頻繁更改，缺點則是核心模型的構(gòu)建過程會相當漫長，且不易擴展。自底向上構(gòu)建方式的優(yōu)點則是可以較快的創(chuàng)建模型，易于擴展，但是相應(yīng)的后期修改會較為頻繁，在openEHR中通過將穩(wěn)定的參考模型（reference model）和易變的原型和模板（archetypes& templates）分離，使得基本模塊比較穩(wěn)定，從而解決了這個問題。

中國現(xiàn)在實行的是自底向上的構(gòu)建方式，先定義最基本的元數(shù)據(jù)，統(tǒng)一最基本的數(shù)據(jù)格式，再考慮以后的數(shù)據(jù)交換結(jié)構(gòu)、數(shù)據(jù)模型。2009年衛(wèi)生部發(fā)布的《健康檔案基本架構(gòu)與數(shù)據(jù)標準（試行）》[7]，則是這個過程的第一步。該標準定義了健康檔案相關(guān)的元數(shù)據(jù)，基于這些元數(shù)據(jù)元來定義交換信息格式，將很好地解決院間的信息交互問題。

目前試行標準剛剛提出，各醫(yī)療信息系統(tǒng)中多少數(shù)據(jù)符合衛(wèi)生部標準尚不清楚。因此對現(xiàn)有系統(tǒng)的數(shù)據(jù)進行檢測，了解哪些數(shù)據(jù)不符合要求，以便于進一步改進，就顯得尤為重要。另一方面，一旦各系統(tǒng)數(shù)據(jù)改造完成并提供符合標準的交換數(shù)據(jù)時，如何來證明這些交換數(shù)據(jù)符合標準，讓接受方可以放心地接受這些數(shù)據(jù)，并正確解析，將會成為很重要的工作。因此，無論是為了推廣健康標準的使用，還是為了保證交換數(shù)據(jù)的質(zhì)量，都需要對現(xiàn)有醫(yī)療信息系統(tǒng)的數(shù)據(jù)進行驗證。

要實現(xiàn)基于衛(wèi)生部健康檔案標準的數(shù)據(jù)共享，首先需要規(guī)范各醫(yī)療信息系統(tǒng)的數(shù)據(jù)，這方面的工作顯然不可能由手工來完成。本文討論了根據(jù)健康檔案標準來驗證實際醫(yī)療數(shù)據(jù)時，需要檢測的內(nèi)容以及檢測流程，并據(jù)此實現(xiàn)了一個驗證工具，該工具不僅可以幫助醫(yī)療信息系統(tǒng)改進其數(shù)據(jù)質(zhì)量，以符合衛(wèi)生部標準，而且也可以對傳輸?shù)慕粨Q數(shù)據(jù)進行驗證，確定這些交換數(shù)據(jù)是否符合衛(wèi)生部標準。

1 驗證內(nèi)容

在設(shè)計基于健康檔案標準的驗證工具時，閱讀了標準中對于數(shù)據(jù)的定義以及現(xiàn)有信息系統(tǒng)中可以獲得的數(shù)據(jù)和數(shù)據(jù)字典（或稱為元數(shù)據(jù)），發(fā)現(xiàn)驗證工具必須實現(xiàn)如下驗證功能：能對數(shù)據(jù)字典和實際交換數(shù)據(jù)中的單個數(shù)據(jù)進行驗證，即元數(shù)據(jù)驗證；能對數(shù)據(jù)字典和實際交換數(shù)據(jù)中的分組信息（該分組信息在健康檔案標準中通過屬性數(shù)據(jù)元標識符來限定）進行驗證，即分組信息驗證；同時在對實際交換數(shù)據(jù)進行驗證時，必須考慮其中數(shù)據(jù)的上下文關(guān)系，即交換數(shù)據(jù)結(jié)構(gòu)驗證。

1.1 元數(shù)據(jù)驗證

在健康檔案標準中，給出了公共元數(shù)據(jù)以及特定應(yīng)用領(lǐng)域的數(shù)據(jù)子集的定義。其中的每個元數(shù)據(jù)定義包括了數(shù)據(jù)名稱、數(shù)據(jù)類型、長度、取值范圍等內(nèi)容。

因此驗證工具的第一步工作，就是要檢驗實際數(shù)據(jù)是否符合這些定義。這方面的檢驗工作實際上包括兩方面的內(nèi)容：一個是檢驗現(xiàn)有數(shù)據(jù)庫中的數(shù)據(jù)字典是否符合標準中的定義，比如某個屬性在標準中定義為字符串類型，而數(shù)據(jù)庫中定義為數(shù)值類型，就可以判斷出這個字段不符合標準；另一個檢驗則是檢驗實際傳輸?shù)臄?shù)據(jù)是否滿足標準定義。

一般而言，如果數(shù)據(jù)字典驗證通過，則可以認為交換數(shù)據(jù)基本滿足了健康檔案標準。但實際情況下，健康檔案的某些數(shù)據(jù)定義很難用數(shù)據(jù)字典來描述，比如標準中給出的一些編碼定義，這些就只能通過檢驗實際數(shù)據(jù)來驗證，而且有時候不一定能得到數(shù)據(jù)字典。

1.2 分組信息驗證

在標準中的元數(shù)據(jù)屬性數(shù)據(jù)元標識符隱含描述了元數(shù)據(jù)間的關(guān)系，比如表1中的三個元數(shù)據(jù)是定義在門診診療數(shù)據(jù)集中的。從名稱中可以看出，如果要描述一個手術(shù)/操作的信息，這三個數(shù)據(jù)必須同時出現(xiàn)，缺失其中的任何一個數(shù)據(jù)，都將導(dǎo)致信息的不完整。

因此驗證工具的另一項工作，就是檢驗這類關(guān)聯(lián)信息是否缺失。而且這項工作無論是針對數(shù)據(jù)字典的驗證，還是針對實際數(shù)據(jù)的驗證，都是必須要做的。

1.3 交換數(shù)據(jù)結(jié)構(gòu)驗證

在對實際交換數(shù)據(jù)進行驗證時，除了要驗證元數(shù)據(jù)、分組信息之外，相當重要的一個驗證內(nèi)容就是驗證其數(shù)據(jù)結(jié)構(gòu)。之所以數(shù)據(jù)結(jié)構(gòu)如此重要，是因為同樣的數(shù)據(jù)內(nèi)容在交換文件中所處位置不同，其代表的意義就會完全不同。以表1中給出的3個數(shù)據(jù)定義為例，如果患者做了兩次手術(shù)，那么交換數(shù)據(jù)文件中將包含兩組6個手術(shù)數(shù)據(jù)，當這6個手術(shù)數(shù)據(jù)以任意順序存儲時，接收方根據(jù)不同的順序就會有不同的解釋。因此傳遞數(shù)據(jù)的雙方必須約定一個數(shù)據(jù)存儲的結(jié)構(gòu)，這樣才能保證傳輸?shù)臄?shù)據(jù)不會被錯誤理解。

目前的健康檔案試行標準中并沒有給出數(shù)據(jù)傳輸時的結(jié)構(gòu)，實際交換數(shù)據(jù)格式可以是任意形式的，比如純文本、xml、excel等，只要其中的每一個數(shù)據(jù)項都符合元數(shù)據(jù)的定義，就可以認為這個交換格式是符合健康標準的，這顯然不利于數(shù)據(jù)的共享。因此為了數(shù)據(jù)交換的需要，一個統(tǒng)一的交換數(shù)據(jù)結(jié)構(gòu)是必須的。

當前XML變得越來越普遍，首先其半結(jié)構(gòu)化的數(shù)據(jù)存儲形式很容易描述健康檔案中的元數(shù)據(jù)定義，同時其自包含的數(shù)據(jù)描述也容易讓人閱讀，因此在驗證工具中，我們選擇XML文檔作為健康檔案標準的交換格式。使用XML格式的另一個好處是，可以使用XML Schema來對數(shù)據(jù)格式進行限定，這樣就可以使用通用的XML解析器來對數(shù)據(jù)驗證，而不需要使用特定的驗證工具。

在設(shè)計XML文檔結(jié)構(gòu)時，我們參考了HL7規(guī)范中的CDA標準[4]，針對CDA文檔過于通用而導(dǎo)致文檔結(jié)構(gòu)過于復(fù)雜的問題，進行了簡化，最終設(shè)計的XML文檔結(jié)構(gòu)包括一個通用的HEAD部分和針對不同數(shù)據(jù)集而內(nèi)容不同的BODY部分。

基于XML交換數(shù)據(jù)結(jié)構(gòu)的驗證相對較簡單，針對某個數(shù)據(jù)集，都有定義好的XML Schema對應(yīng)，調(diào)用XML解析工具就可以判斷交換文件結(jié)構(gòu)是否正確，當然更詳細的錯誤信息還是需要驗證工具來給出。

表1 健康標準元數(shù)據(jù)定義示例[7]

2 驗證流程

正如上一節(jié)所言，驗證工具的主要任務(wù)，就是找出不符合標準的數(shù)據(jù)，這包括單個元素的檢驗和數(shù)據(jù)元標識符中隱含分組信息的檢驗，同時工具應(yīng)該同時提供對數(shù)據(jù)字典（或元數(shù)據(jù)定義）的驗證以及實際交換數(shù)據(jù)（包括交換數(shù)據(jù)的結(jié)構(gòu)）的驗證。

對數(shù)據(jù)字典的驗證較簡單，只需要給出數(shù)據(jù)字典中每個字段和標準中某個元數(shù)據(jù)的映射，檢測工具就可以對兩者進行一對一的比較，看數(shù)據(jù)字典中的字段定義是否滿足標準中的要求。當然映射方面的工作，工具不可能實現(xiàn)完全的自動化，最終還是需要人工確認。

在對實際交換數(shù)據(jù)進行驗證時，由于各家醫(yī)院提交的交換數(shù)據(jù)可能是各種格式的，因此第一步就是將這些數(shù)據(jù)轉(zhuǎn)換為工具默認使用的XML格式，一旦轉(zhuǎn)換完成，就可以進入數(shù)據(jù)驗證的步驟。

一個完整的驗證流程如圖1所示。從圖中可以看出，驗證的第一步就是要做映射，將醫(yī)療信息系統(tǒng)中現(xiàn)有數(shù)據(jù)映射到健康檔案標準上，產(chǎn)生映射文件，根據(jù)映射文件就可以輸出針對數(shù)據(jù)字典的驗證信息。一旦數(shù)據(jù)字典的驗證通過了，下一步就是對實際的交換數(shù)據(jù)進行驗證。在對實際交換數(shù)據(jù)進行驗證時，首先將各種格式的待驗證數(shù)據(jù)轉(zhuǎn)換為驗證工具使用的XML格式，然后再進行驗證。一旦衛(wèi)生部發(fā)布了健康檔案交換數(shù)據(jù)格式，則可以取消格式轉(zhuǎn)換步驟。

圖1 健康檔案驗證流程

3 系統(tǒng)架構(gòu)

從圖1可以看出，整個驗證工具至少應(yīng)該包括三個模塊，即映射模塊、轉(zhuǎn)換模塊和驗證模塊。但考慮到驗證數(shù)據(jù)存儲格式的多樣性，以及現(xiàn)有健康檔案標準是試行版，以后可能會有更改，因此實際設(shè)計的驗證工具要復(fù)雜些，考慮到以后的擴展。

驗證工具的包圖如圖2所示，圖中忽略了一些輔助包。

圖2 驗證工具包圖

圖2中每個包的功能如下所述：

模型包中包含了整個工具用到的通用數(shù)據(jù)結(jié)構(gòu)。

映射模塊在這里拆分為數(shù)據(jù)源和映射兩個包，其中數(shù)據(jù)源包用于將待測各類存儲格式數(shù)據(jù)轉(zhuǎn)換為模型中定義的通用數(shù)據(jù)格式，而映射包則將轉(zhuǎn)換后的待測數(shù)據(jù)映射到健康標準元數(shù)據(jù)上。數(shù)據(jù)源包又分為兩個子包，其中元數(shù)據(jù)子包用于解析待測數(shù)據(jù)字典，而內(nèi)容子包則用于解析待測數(shù)據(jù)。

規(guī)范包用于將健康檔案標準的定義轉(zhuǎn)換為模型中定義的通用數(shù)據(jù)結(jié)構(gòu)，其中元素子包用于解析標準中的單個元數(shù)據(jù)，而結(jié)構(gòu)子包則是一個擴展，用于定義交換數(shù)據(jù)的結(jié)構(gòu)，目前使用的是我們自己定義的一個基本結(jié)構(gòu)，而當衛(wèi)生部給出交換格式定義后，可以很方便的進行替換。

驗證模塊對應(yīng)這里的驗證包，該包用于對數(shù)據(jù)字典或數(shù)據(jù)進行驗證，包含四個子包，分別對應(yīng)不同的驗證內(nèi)容。其中元數(shù)據(jù)子包用于對數(shù)據(jù)字典進行驗證，內(nèi)容子包用于對實際數(shù)據(jù)進行驗證，而分組子包則用于對健康標準中的隱含分組信息進行驗證。結(jié)構(gòu)子包是一個待擴展的包，我們針對自己定義的數(shù)據(jù)交換結(jié)構(gòu)實現(xiàn)了一個原型，一旦衛(wèi)生部頒布了數(shù)據(jù)交換結(jié)構(gòu)規(guī)則，則可以擴展為支持衛(wèi)生部規(guī)范的結(jié)構(gòu)驗證。

轉(zhuǎn)換模塊的功能包含在XML包中，XML包同樣是一個待擴展包，其輸出的xml相關(guān)文檔依賴于指定的數(shù)據(jù)交換結(jié)構(gòu)規(guī)范。一旦衛(wèi)生部給出健康檔案交換結(jié)構(gòu)規(guī)范， XML包可以輸出相應(yīng)的定義交換數(shù)據(jù)結(jié)構(gòu)的xsd文件和用于交換的xml數(shù)據(jù)文件。目前XML包輸出的是基于我們自定義交換數(shù)據(jù)結(jié)構(gòu)的xsd文檔和xml文檔。

因此該驗證工具不僅可以對數(shù)據(jù)字典和實際數(shù)據(jù)進行驗證，同時也可以將不符合要求的數(shù)據(jù)轉(zhuǎn)換為符合健康檔案規(guī)范要求的數(shù)據(jù)。

4 測試結(jié)果

我們使用自己開發(fā)驗證工具對一些醫(yī)療數(shù)據(jù)進行了驗證，發(fā)現(xiàn)在目前的情況下，確實有相當多的數(shù)據(jù)不符合衛(wèi)生部發(fā)布的健康檔案標準的定義。當前我們的驗證集中于HRC00.01門診診療基本數(shù)據(jù)集標準和HRC00.02住院診療基本數(shù)據(jù)集標準兩個數(shù)據(jù)集，但其它數(shù)據(jù)集的情況應(yīng)該類似。

根據(jù)驗證結(jié)果，我們對驗證工具輸出的檢測結(jié)果信息進行了歸納分析，發(fā)現(xiàn)基本可以歸納為以下的6種差異類型。

(1)長度不匹配：數(shù)據(jù)類型相同，但給出的數(shù)據(jù)字典定義或?qū)嶋H數(shù)據(jù)的長度和標準中定義的長度不符合；

(2)類型不匹配：給出的數(shù)據(jù)類型和標準中定義的數(shù)據(jù)類型不符；

(3)內(nèi)容不匹配：自己制定的編碼含義和標準中定義的編碼含義不符；

(4)結(jié)構(gòu)不匹配：標準中定義的元數(shù)據(jù)比較通用，比如“檢測/檢驗-項目名稱”僅一個字段，而醫(yī)院針對不同的檢驗，有單獨的表對應(yīng)，每張表中的字段名稱、類型都不完全相同；

(5)定義不匹配：標準中對某些取值進行了編碼，而現(xiàn)有醫(yī)療信息系統(tǒng)中則直接使用這些值，或者相反；

(6)采用標準不匹配：標準中使用的國家標準都比較新，而現(xiàn)有醫(yī)療信息系統(tǒng)采用的國家標準都比較舊。

詳細說明見表2中的分析和舉例。

表2 檢測差異類型說明

除此之外，標準中還有一部分的元數(shù)據(jù)在實際醫(yī)療數(shù)據(jù)中無法找到對應(yīng)的數(shù)據(jù)項。

從實際的驗證過程中，我們發(fā)現(xiàn)，醫(yī)院本身的數(shù)據(jù)已經(jīng)基本上涵蓋了健康檔案標準指定的內(nèi)容，兩者間的差異，很多體現(xiàn)在數(shù)據(jù)類型、數(shù)據(jù)長度、使用分類標準的不同上。而驗證工具給出的檢測結(jié)果，可以很好地幫助醫(yī)院完成這方面的改進。

5 后續(xù)研究工作

目前我們實現(xiàn)的驗證工具在對交換數(shù)據(jù)進行驗證時，并沒有考慮數(shù)據(jù)的上下文，比如男性的健康檔案中是不應(yīng)該包含孕檢信息的，驗證工具如果能夠檢測出這方面的錯誤，將會有很大的應(yīng)用價值。

另外現(xiàn)有的驗證工具并沒有考慮驗證可忽略數(shù)據(jù)和可重復(fù)數(shù)據(jù)。以標準中的門診數(shù)據(jù)集為例，如果在相應(yīng)的交換數(shù)據(jù)文檔中出現(xiàn)多個藥物是正常的，因此在驗證時應(yīng)該能檢測出這些重復(fù)數(shù)據(jù)并判斷為正確，但是如果在同樣一份門診交換數(shù)據(jù)文檔中出現(xiàn)了多個患者姓名則顯然是不對的。同樣在門診數(shù)據(jù)集中定義了手術(shù)相關(guān)的元數(shù)據(jù)，但如果在看病過程中沒有做手術(shù)，那么在交換數(shù)據(jù)文檔中不存在手術(shù)數(shù)據(jù)是合理的，驗證工具應(yīng)該不應(yīng)該判定為數(shù)據(jù)缺失。

以上兩方面的驗證工作，都和交換數(shù)據(jù)結(jié)構(gòu)的定義有關(guān)，在以后的工作中，我們將會關(guān)注于這方面的研究。

6 總結(jié)

衛(wèi)生部的健康檔案標準推出不久，從我們測試下來的情況來看，醫(yī)院中符合標準的數(shù)據(jù)并不多，找出這些不符合的數(shù)據(jù)，并轉(zhuǎn)換為標準指定的形式，將會花費大量的人力物力。而通過健康檔案標準驗證工具來輔助完成這項工作，將幫助醫(yī)院降低查找這些差異的代價，有助于加速標準的推廣。

文中討論了在對現(xiàn)有醫(yī)療數(shù)據(jù)進行驗證時，需要驗證的內(nèi)容（即包括數(shù)據(jù)字典的驗證和實際交換數(shù)據(jù)的驗證，單個數(shù)據(jù)的驗證和分組數(shù)據(jù)的驗證）以及完整的驗證流程，并介紹了實現(xiàn)的驗證工具，該工具輸出的驗證結(jié)果有助于幫助醫(yī)院改進其數(shù)據(jù)質(zhì)量，以符合健康檔案標準。同時該工具在設(shè)計之初就考慮了后期的擴展，一旦衛(wèi)生部頒布了健康檔案的數(shù)據(jù)交換格式，將很容易在工具中加入針對交換格式的驗證功能。

[1]Jane Grimson,Gaye Stephens,et al.Sharing health-care records over the Internet[J].Internet Computing, IEEE,2001,5(3):49-59.

[2]J.Grimson,W.Grimson,W.Hasselbring.The System Integration Challenge in Healthcare[J].Communications of the ACM,2000,43(6):49-55.

[3]George W. Beeler. HL7 Version 3——An object-oriented methodology for collaborative standards development[J].International Journal of Medical Informatics,1998,48(1):151-161.

[4]Dolin RH,Alschuler L,et al.HL7 Clinical Document Architecture,Release 2[J]. Journal of American Medical Informatics Association,2006,13(1):30-39.

[5]S.Garde, E. Hovenga, et al. Expressing clinical data sets with openEHR archetypes: A solid basis for ubiquitous computing[J].International Journal of Medical Informatics,2007,76S: S334-S341.

[6]Jasmin Buck, Sebastian Garde, et al. Towards a comprehensive electronic patient record to support an innovative individual care concept for premature infants using the openEHR approach[J].International Journal of Medical Informatics,2009,78:521-531.

[7]中華人民共和國衛(wèi)生部.衛(wèi)生部印發(fā)健康檔案架構(gòu)與數(shù)據(jù)標準(試行)的通知[EB/OL]. (2009-05-19)[2010-01-21].http://www.gov.cn/gzdt/2009-05/19/content_1319085.htm.