|
|
浅谈HL7标准本地化工作
摘要：本文对HL7本地化过程中需要进行的工作进行了探讨，介绍了本地化工作的思路和导致需要进行本地化原因，这些原因可以划分为三类,一类是由于文化差异导致的本地化工作，一类是医疗模式导致的本地化工作，一类是信息化发展程度不同导致的本地化工作，并对其中的解决方法进行了一些讨论。
关键词：HL7 本地化
HL7标准是美国HL7组织在1987年开始为了医疗保健行业内的电子数据交换而研究制定的一个电子数据交换标准，其目标是：在不同的计算机应用程序之间实施公用的接口。该组织致力于使那些在医疗应用系统中交换的某些关键数据集合的格式和协议标准化。2000年，中国加入HL7组织，成为HL7的成员国组织，在国内开始进行HL7标准的推广和本地化研究工作。经过几年的发展，HL7标准正在国内逐渐获得大家的认识，进行HL7研究和本地化工作的人也越来越多。我们对HL7 2.x版本经过长时间的研究，结合国内具体的标准发展状况和实际需求，进行了多项本地化工作。本文特对我们工作中的经验进行了一些总结，和大家进行探讨。
HL7标准是在1987年开始制定，此后经过多次升级改版，但在2.x版本后，基本上都保持了向后兼容的特性，标准的整体框架和技术基本上没有进行太多的改动。我们的本地化工作是以2000年正式通过的2.4版本为基础。
HL7标准是基于消息机制进行数据交换。在技术层面是不需要进行本地化，本地化的工作主要存在于消息内容的定义和消息内容的编码上。按照HL7标准的规定，最小的应用数据单位是：消息（message），也就是说两个系统之间进行数据交换时的最小结构。字段（field）是一个消息的最小构成单位，而段（segment）在HL7中定义为多个字段的逻辑分组，是消息的组成单位。也就是说，一个消息正是有多个段（segment）来组成，而一个段（segment）是多个具有逻辑关系的字段（field）组成。从台湾的本地化工作来看，是基于单个消息来定义某一个接口的。这样可以快速的应用在某一个方面，这与台湾地域狭小，从事医疗软件开发的企业不多有关。基本上可以依靠几家大型医院和几个大型厂商就可以定下某一个接口标准。国内医疗软件厂商众多，却缺乏龙头企业。如果仅依靠某几个消息来定义接口，则很可能会发生HL7 2.X版本最常见的问题：因为同一位置的数据字段的定义不同，而导致相互之间的消息不能兼容，发生数据传输的错误。基于这样的考虑，我们的本地化工作从每个段（segment）开始。在确定所需要的段（segment）的基础上，组合成所需要的消息格式。我们对2.4版本的所有章节，进行了分析和讨论。
我们总结主要以下三个大的方面需要进行本地化工作：
1、中西方文化差异和生活模式差异导致的本地化工作
这是本地化工作中最常见的一个差异。典型的表现是HL7标准中有很多对国内没有应用价值的字段。典型的如姓名的表示方法，在国内一般只采用一个“姓名”的字段，而在国外姓名的表示方法复杂，由前缀、后缀、教名等多种成分，对应的在HL7标准中，也有family name、given name、suffix、prefix等多重成分内容，而国内姓名的记录往往只是用一个字段，因此在本地化工作中需要将国内的姓名表达方法指定到特定的字段中；在身份识别上，SSN和Driver's license Number是其需要的特定字段，而国内尚没有SSN号码的概念，对Driver's license Number也很少进行记录。这些还是比较表面、明显的差异，还有一些更深层次的文化差异。例如：按照西方的习俗，在女子结婚后，要随夫姓，存在更名的过程，为了识别患者身份，在HL7标准中也存在Mother’s Maiden Name等字段。另外，在国内习惯将工作单位、职业等作为病人基本信息来进行识别病人，而在HL7标准中，则将这些信息放置在next of kin / associated parties segment（亲属和社会关系）段里面，并没有放置在patient identification segment中，主要是因为国内是以单位作为一个基层组织，深入到了公民的生活中，而在美国则以个体/家庭为基本单位，因此并没有将其作为一个基本信息。当然我们认为这样的划分也是有一定道理的，毕竟随着城市的发展和国家现代化的建设，自由职业者和流动人群越来越多。
对于这方面原因导致的本地化工作，我们可以通过空闲相应的字段进行处理，仅采用段（segment）中适用的字段（field），并适当调整数据信息的分类即可完成，但需要深刻了解中西方文化的差异和表现。
2、医疗模式导致的本地化工作
第二类主要的影响因素是由于国家之间的医疗模式的差别而导致本地化工作。在这方面又分为两个层面，一个是医疗制度上的，在这方面两国医疗流程、医疗表达方式差异较少，基本上仅需做很少的本地化工作即可进行应用。差异较多的是在预约、收费结算等辅助环节上；另一个层面是在医疗保险信息的处理。在美国的医疗保险制度较为完善，信息化程度较高，虽然存在多个医疗保险计划，比如：Medicaid、Medicare；但这些医疗保险计划基本上都制定了较为完整的信息申报体系，差异不是很大，都可以采用DRGs、CPT等诊断/手术编码直接判断医疗费用的结算金额，也都有各自的明确的账单代码体系。目前，国内各地的医保政策、医保结算方法等都不一致，难以通过统一的信息整合，同时，医疗保险的政策变动也较大，医保的数据方式和数据内容都不一致。在医保结算方面，目前很难用HL7的相关数据信息，基本上只能完全进行本地化定制。
对于这部分工作，基本上只能采用扩充标准、逐步应用的办法。在HL7中，为标准的本地化和客户化作了一定的设计。HL7定义Z字段开头的段被保留用来进行本地化和客户化。但需要注意的是，有一些经过本地化的字段已经被补充到HL7的应用指导中，因此在进行本地化时，定义Z字母开头的段时，需要先查找是否已经被定义过，以保持最大的兼容性。
3、信息化发展程度不同差异导致的本地化工作
这个方面的差异主要表现在数据字段的编码表上。由于美国的信息化程度较高，因此在信息分类、数据编码上较为完善，而我国在这方面相对来说较为落后，因此导致同一字段，编码规则的不一致。最简单的例子就是性别的表示。在HL7中，对于性别的定义的推荐编码有6个值，而在我国国标的性别定义中只有3个值。HL7的推荐值更符合医学上的应用，而国标最初是为了人事管理而开发的，一直在医疗上没有进行细化。在这个时候到底是推荐使用HL7的编码还是采用国标，成为了一个问题。
另外一个方面来说，性别还是可以应用国标的字段。更多的问题是很多字段在我国都没有相应的标准编码或者数据字典。HL7标准本身虽然定义了一些数据编码，并没有全部进行自行定义，主要是应用其他组织完成和维护的标准编码，例如：ICD9、ICD10、ATC、CPT 4、LOINC等，在2.4版本中总共引用了79套编码体系。这些编码体系都有各自独立的组织进行维护，而不是由HL7组织维护，但这些编码体系是HL7标准能够成功应用的基础。
应该说这种原因造成的本地化工作是最难以解决的，只能通过逐步的完善补充来进行，需要进行大量的协调和组织工作。
本地化工作中发现的问题
1、基础信息标准不全。
在HL7 2.4版本中引用了79套编码，而在国内基本上还没有比较一套比较完整的标准体系，即便有一些编码标准，也因为宣传、贯彻、推广的不力，导致这些标准都没有能够在行业中获得普遍应用。这些工作的缺乏，使得在需要进行数据交换时，不得不浪费大量的精力完成不同系统之间的编码对照工作。
2、标准滞后的问题
一个标准在产生的时候，就必定会随着技术的进入和应用的深入而逐步得到扩展和升级。HL7从发布1987年到现在的17年间已经更新了8个版本了。而国内的标准制定之后往往很多年都难以得到修整和增补，导致标准在推广中逐渐落后于应用，而导致标准成为没有人遵循的标准，被市场束之高阁。
基础标准的缺乏，这是将会是HL7标准本地化获得成功应用的最大困难之一。最佳的解决办法是以行业组织或者建立医疗信息方面的标准管理组织来负责这些编码标准的维护、更新。
参考资料：
1、 HL7 2.4版本 www.hl7.org |
|
发表于 2004-5-8 19:02:31
发表于 2004-5-8 21:20:28