健康档案数据验证

张旭峰，姚志洪,2

（1.上海生物信息技术研究中心，上海 200235；2.中科院上海健康科学研究所，上海 200025）

0 前言

随着信息技术的发展，建立了大量的医疗信息系统，但这些信息系统彼此独立且互不兼容，彼此间无法共享患者健康信息。因此，患者在不同地方看病时，往往需要做重复的检查，无形中加重了患者的负担，也导致了医疗资源的浪费。这种信息无法交互导致的医疗资源浪费，在国外也很严重[1,2]。为解决这个问题，各国都在做相关的信息标准化的尝试，比如美国的HL7标准[3,4]，欧洲的openEHR规范[5,6]。其中HL7是自顶向下构建信息模型，先由专家构建出完整的抽象模型（HL7中为RIM模型），然后根据实际应用领域选择部分模型并加以扩充（HL7中为DMIM和RMIM模型）。而openHER则是自底向上构建模型，先确定最基本的模块，然后针对不同领域选取模块进行组装，如果在组装时发现没有相应的基本模块，则加以扩充。自顶向下构建方式的优点是抽象出的核心模型（如HL7中的RIM模型）比较稳定，不会频繁更改，缺点则是核心模型的构建过程会相当漫长，且不易扩展。自底向上构建方式的优点则是可以较快的创建模型，易于扩展，但是相应的后期修改会较为频繁，在openEHR中通过将稳定的参考模型（reference model）和易变的原型和模板（archetypes& templates）分离，使得基本模块比较稳定，从而解决了这个问题。

中国现在实行的是自底向上的构建方式，先定义最基本的元数据，统一最基本的数据格式，再考虑以后的数据交换结构、数据模型。2009年卫生部发布的《健康档案基本架构与数据标准（试行）》[7]，则是这个过程的第一步。该标准定义了健康档案相关的元数据，基于这些元数据元来定义交换信息格式，将很好地解决院间的信息交互问题。

目前试行标准刚刚提出，各医疗信息系统中多少数据符合卫生部标准尚不清楚。因此对现有系统的数据进行检测，了解哪些数据不符合要求，以便于进一步改进，就显得尤为重要。另一方面，一旦各系统数据改造完成并提供符合标准的交换数据时，如何来证明这些交换数据符合标准，让接受方可以放心地接受这些数据，并正确解析，将会成为很重要的工作。因此，无论是为了推广健康标准的使用，还是为了保证交换数据的质量，都需要对现有医疗信息系统的数据进行验证。

要实现基于卫生部健康档案标准的数据共享，首先需要规范各医疗信息系统的数据，这方面的工作显然不可能由手工来完成。本文讨论了根据健康档案标准来验证实际医疗数据时，需要检测的内容以及检测流程，并据此实现了一个验证工具，该工具不仅可以帮助医疗信息系统改进其数据质量，以符合卫生部标准，而且也可以对传输的交换数据进行验证，确定这些交换数据是否符合卫生部标准。

1 验证内容

在设计基于健康档案标准的验证工具时，阅读了标准中对于数据的定义以及现有信息系统中可以获得的数据和数据字典（或称为元数据），发现验证工具必须实现如下验证功能：能对数据字典和实际交换数据中的单个数据进行验证，即元数据验证；能对数据字典和实际交换数据中的分组信息（该分组信息在健康档案标准中通过属性数据元标识符来限定）进行验证，即分组信息验证；同时在对实际交换数据进行验证时，必须考虑其中数据的上下文关系，即交换数据结构验证。

1.1 元数据验证

在健康档案标准中，给出了公共元数据以及特定应用领域的数据子集的定义。其中的每个元数据定义包括了数据名称、数据类型、长度、取值范围等内容。

因此验证工具的第一步工作，就是要检验实际数据是否符合这些定义。这方面的检验工作实际上包括两方面的内容：一个是检验现有数据库中的数据字典是否符合标准中的定义，比如某个属性在标准中定义为字符串类型，而数据库中定义为数值类型，就可以判断出这个字段不符合标准；另一个检验则是检验实际传输的数据是否满足标准定义。

一般而言，如果数据字典验证通过，则可以认为交换数据基本满足了健康档案标准。但实际情况下，健康档案的某些数据定义很难用数据字典来描述，比如标准中给出的一些编码定义，这些就只能通过检验实际数据来验证，而且有时候不一定能得到数据字典。

1.2 分组信息验证

在标准中的元数据属性数据元标识符隐含描述了元数据间的关系，比如表1中的三个元数据是定义在门诊诊疗数据集中的。从名称中可以看出，如果要描述一个手术/操作的信息，这三个数据必须同时出现，缺失其中的任何一个数据，都将导致信息的不完整。

因此验证工具的另一项工作，就是检验这类关联信息是否缺失。而且这项工作无论是针对数据字典的验证，还是针对实际数据的验证，都是必须要做的。

1.3 交换数据结构验证

在对实际交换数据进行验证时，除了要验证元数据、分组信息之外，相当重要的一个验证内容就是验证其数据结构。之所以数据结构如此重要，是因为同样的数据内容在交换文件中所处位置不同，其代表的意义就会完全不同。以表1中给出的3个数据定义为例，如果患者做了两次手术，那么交换数据文件中将包含两组6个手术数据，当这6个手术数据以任意顺序存储时，接收方根据不同的顺序就会有不同的解释。因此传递数据的双方必须约定一个数据存储的结构，这样才能保证传输的数据不会被错误理解。

目前的健康档案试行标准中并没有给出数据传输时的结构，实际交换数据格式可以是任意形式的，比如纯文本、xml、excel等，只要其中的每一个数据项都符合元数据的定义，就可以认为这个交换格式是符合健康标准的，这显然不利于数据的共享。因此为了数据交换的需要，一个统一的交换数据结构是必须的。

当前XML变得越来越普遍，首先其半结构化的数据存储形式很容易描述健康档案中的元数据定义，同时其自包含的数据描述也容易让人阅读，因此在验证工具中，我们选择XML文档作为健康档案标准的交换格式。使用XML格式的另一个好处是，可以使用XML Schema来对数据格式进行限定，这样就可以使用通用的XML解析器来对数据验证，而不需要使用特定的验证工具。

在设计XML文档结构时，我们参考了HL7规范中的CDA标准[4]，针对CDA文档过于通用而导致文档结构过于复杂的问题，进行了简化，最终设计的XML文档结构包括一个通用的HEAD部分和针对不同数据集而内容不同的BODY部分。

基于XML交换数据结构的验证相对较简单，针对某个数据集，都有定义好的XML Schema对应，调用XML解析工具就可以判断交换文件结构是否正确，当然更详细的错误信息还是需要验证工具来给出。

表1 健康标准元数据定义示例[7]

2 验证流程

正如上一节所言，验证工具的主要任务，就是找出不符合标准的数据，这包括单个元素的检验和数据元标识符中隐含分组信息的检验，同时工具应该同时提供对数据字典（或元数据定义）的验证以及实际交换数据（包括交换数据的结构）的验证。

对数据字典的验证较简单，只需要给出数据字典中每个字段和标准中某个元数据的映射，检测工具就可以对两者进行一对一的比较，看数据字典中的字段定义是否满足标准中的要求。当然映射方面的工作，工具不可能实现完全的自动化，最终还是需要人工确认。

在对实际交换数据进行验证时，由于各家医院提交的交换数据可能是各种格式的，因此第一步就是将这些数据转换为工具默认使用的XML格式，一旦转换完成，就可以进入数据验证的步骤。

一个完整的验证流程如图1所示。从图中可以看出，验证的第一步就是要做映射，将医疗信息系统中现有数据映射到健康档案标准上，产生映射文件，根据映射文件就可以输出针对数据字典的验证信息。一旦数据字典的验证通过了，下一步就是对实际的交换数据进行验证。在对实际交换数据进行验证时，首先将各种格式的待验证数据转换为验证工具使用的XML格式，然后再进行验证。一旦卫生部发布了健康档案交换数据格式，则可以取消格式转换步骤。

图1 健康档案验证流程

3 系统架构

从图1可以看出，整个验证工具至少应该包括三个模块，即映射模块、转换模块和验证模块。但考虑到验证数据存储格式的多样性，以及现有健康档案标准是试行版，以后可能会有更改，因此实际设计的验证工具要复杂些，考虑到以后的扩展。

验证工具的包图如图2所示，图中忽略了一些辅助包。

图2 验证工具包图

图2中每个包的功能如下所述：

模型包中包含了整个工具用到的通用数据结构。

映射模块在这里拆分为数据源和映射两个包，其中数据源包用于将待测各类存储格式数据转换为模型中定义的通用数据格式，而映射包则将转换后的待测数据映射到健康标准元数据上。数据源包又分为两个子包，其中元数据子包用于解析待测数据字典，而内容子包则用于解析待测数据。

规范包用于将健康档案标准的定义转换为模型中定义的通用数据结构，其中元素子包用于解析标准中的单个元数据，而结构子包则是一个扩展，用于定义交换数据的结构，目前使用的是我们自己定义的一个基本结构，而当卫生部给出交换格式定义后，可以很方便的进行替换。

验证模块对应这里的验证包，该包用于对数据字典或数据进行验证，包含四个子包，分别对应不同的验证内容。其中元数据子包用于对数据字典进行验证，内容子包用于对实际数据进行验证，而分组子包则用于对健康标准中的隐含分组信息进行验证。结构子包是一个待扩展的包，我们针对自己定义的数据交换结构实现了一个原型，一旦卫生部颁布了数据交换结构规则，则可以扩展为支持卫生部规范的结构验证。

转换模块的功能包含在XML包中，XML包同样是一个待扩展包，其输出的xml相关文档依赖于指定的数据交换结构规范。一旦卫生部给出健康档案交换结构规范， XML包可以输出相应的定义交换数据结构的xsd文件和用于交换的xml数据文件。目前XML包输出的是基于我们自定义交换数据结构的xsd文档和xml文档。

因此该验证工具不仅可以对数据字典和实际数据进行验证，同时也可以将不符合要求的数据转换为符合健康档案规范要求的数据。

4 测试结果

我们使用自己开发验证工具对一些医疗数据进行了验证，发现在目前的情况下，确实有相当多的数据不符合卫生部发布的健康档案标准的定义。当前我们的验证集中于HRC00.01门诊诊疗基本数据集标准和HRC00.02住院诊疗基本数据集标准两个数据集，但其它数据集的情况应该类似。

根据验证结果，我们对验证工具输出的检测结果信息进行了归纳分析，发现基本可以归纳为以下的6种差异类型。

(1)长度不匹配：数据类型相同，但给出的数据字典定义或实际数据的长度和标准中定义的长度不符合；

(2)类型不匹配：给出的数据类型和标准中定义的数据类型不符；

(3)内容不匹配：自己制定的编码含义和标准中定义的编码含义不符；

(4)结构不匹配：标准中定义的元数据比较通用，比如“检测/检验-项目名称”仅一个字段，而医院针对不同的检验，有单独的表对应，每张表中的字段名称、类型都不完全相同；

(5)定义不匹配：标准中对某些取值进行了编码，而现有医疗信息系统中则直接使用这些值，或者相反；

(6)采用标准不匹配：标准中使用的国家标准都比较新，而现有医疗信息系统采用的国家标准都比较旧。

详细说明见表2中的分析和举例。

表2 检测差异类型说明

除此之外，标准中还有一部分的元数据在实际医疗数据中无法找到对应的数据项。

从实际的验证过程中，我们发现，医院本身的数据已经基本上涵盖了健康档案标准指定的内容，两者间的差异，很多体现在数据类型、数据长度、使用分类标准的不同上。而验证工具给出的检测结果，可以很好地帮助医院完成这方面的改进。

5 后续研究工作

目前我们实现的验证工具在对交换数据进行验证时，并没有考虑数据的上下文，比如男性的健康档案中是不应该包含孕检信息的，验证工具如果能够检测出这方面的错误，将会有很大的应用价值。

另外现有的验证工具并没有考虑验证可忽略数据和可重复数据。以标准中的门诊数据集为例，如果在相应的交换数据文档中出现多个药物是正常的，因此在验证时应该能检测出这些重复数据并判断为正确，但是如果在同样一份门诊交换数据文档中出现了多个患者姓名则显然是不对的。同样在门诊数据集中定义了手术相关的元数据，但如果在看病过程中没有做手术，那么在交换数据文档中不存在手术数据是合理的，验证工具应该不应该判定为数据缺失。

以上两方面的验证工作，都和交换数据结构的定义有关，在以后的工作中，我们将会关注于这方面的研究。

6 总结

卫生部的健康档案标准推出不久，从我们测试下来的情况来看，医院中符合标准的数据并不多，找出这些不符合的数据，并转换为标准指定的形式，将会花费大量的人力物力。而通过健康档案标准验证工具来辅助完成这项工作，将帮助医院降低查找这些差异的代价，有助于加速标准的推广。

文中讨论了在对现有医疗数据进行验证时，需要验证的内容（即包括数据字典的验证和实际交换数据的验证，单个数据的验证和分组数据的验证）以及完整的验证流程，并介绍了实现的验证工具，该工具输出的验证结果有助于帮助医院改进其数据质量，以符合健康档案标准。同时该工具在设计之初就考虑了后期的扩展，一旦卫生部颁布了健康档案的数据交换格式，将很容易在工具中加入针对交换格式的验证功能。

[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]中华人民共和国卫生部.卫生部印发健康档案架构与数据标准(试行)的通知[EB/OL]. (2009-05-19)[2010-01-21].http://www.gov.cn/gzdt/2009-05/19/content_1319085.htm.