搜索
HL7HL7HL7HL7翻译资料中国数字医疗论坛目的本文为卫生保健、医院信息系统销售、查询，以及在多系统环境下利用HL7协议评价系统发展和实现活动的其他支持组织提供了帮助。该支持指南包括以下信息：A．计划方法B．设计和实现方法C．HL7的2.2版本综述D．HL7的2.3版本综述E．HL7的处理核对清单F．HL7的信息框图G．底层协议H．帮助提示I．工程实例J．样本模板（RFI/RFP/约定要点）K．常见问题该支持指南表述了HL7实现委员会在为组织执行或考虑HL7接口实现发展支持材料所作出的努力。有关内容或格式的评述和建议容易接受，而且为指南后所列的执行委员会主席人选提供了指导。要紧记计划和设计/实现方法会在帮助计划和执行HL7接口方面提供指南。该指南可用来联合你的标准系统发展方法。该指南也可用来联合HL7接口标准的说明书。该说明书可提供给HL7组织的所有成员。要加入该组织和接受目前说明书的注册副本，需将成员纪录表格和适当的费用寄到HL7。该指南并不作为确认或证明HL7接口的工具。作为美国国家标准协会（ANSI）认证的标准发展组织，HL7声明该说明可作为接口发展的工具。当前并没有对一个HL7接口适合所述说明进行确认的测试或者批准过程。专用单元的函数和责任（如，配备，销售和查询）可以作为这些接口合同。将来HL7机构可以发展认证程序或符合性测试程序。考虑主要发展活动（如，综合系统升级/更换）的机构，向开放系统体系和/或者多临床整体化的转移，并考虑带有中央医院信息系统（HIS）的财务及管理系统。HL7作为整合这些系统的机构可参考方法学的计划分支。已决定在任意类型的环境中实现一个或多个HL7接口的机构在有用计划部分也可以寻找某些有用信息，而且应该集中在第3章所包括的实现方法的设计和实现子部分。HIS售主应该集中在设计和实现部分，但也要考虑考察作为背景的计划部分。1.21.21.21.2HL7背景HL7建于1987，用来发展独立卫生保健定向计算制度中临床、财务和管理信息的电子交-2-换标准，如医院信息系统，临床实验系统，企业系统和药房系统。在过去的3年，HL7的伙伴已经发展超过1700个医院、专业协会、卫生保健行业和几乎包括所有的主要卫生保健组织顾问和卖主的私人成员。HL7标准已经得到了大多数组织卖主的支持，如今并在美国的大型医院得到了使用。该标准也在国际上的很多国家得到了应用，如：澳大利亚、奥地利、比利时、芬兰、德国、荷兰、以色列、日本、新西兰和英国。1994年6月，HL7被美国国家标准协会（ANSI）任命为ANSI认证标准发展成员。HL7在1994年12月发布了标准的第四版本（2.2版本）。该一致标准在ANSI规则下表决，并在1996年2月8日通过作为一项ANSI标准。1997年4月在CD-ROM上发布的2.3版本在1997年5月通过作为ANSI标准。1.31.31.31.3HL7事物版本2.3的标准定义了关于传输数据的事物，包括病人登记，确认，解除与转移，保险，支出和收入，实验测试的整理总结，图像研究，护理和物理观察，食谱数量，药剂数量，供应数量，主要档案，委任安排，问题清单，临床试验纪录，病人许可，语音指令，高级指示和生理信号。HL7中的强制任务也优先处理带有新状态技术的原型事物，诸如CORBA和Microsoft的OLE事物。1.41.41.41.4与其他标准发展组织的合作HL7主要针对卫生健康的信息标准，并与其他标准发展成员紧密合作，如美国测试和材料协会（ASTM），标准认证协会X12N，美国放射学院（ACR），国家电子制造协会（NEMA），处方药物计划国家委员会（NCPDP），电力与电子工程协会（IEEE），以及通过ANSI的卫生健康信息标准协会。合作的事例包括与ASTM的交叉版权，以及与IEEE、ACR-NEMA、X12N和NCPDP的主体联合工作组会议。HL7已经通过国际互联网FTP服务[mcis.duke.edu]免费提供了备忘录和标准草案，并在HL7@Virginia.EDU服务列表上提供了一个讨论组。我们也欢迎其他标准组织提供上述服务。1.51.51.51.5综述这部分是摘录了第1章的HL7的2.3版本的标准，包括了HL7基本概念的描述，接受内部变化和演化的方法，而且这种途径已经构造用来接受目前和将来变化的通信环境。1111....5555....1111HL7编码规则在HL7编码规则中描述的信息格式由不同长度及被区域分隔符分隔的数据区组成。规则描述了不同的数据类型如何在数据区编码，以及何时专用数据区可以重发。数据区联合成称为段的逻辑集合。段由段分割符号分隔开，每个段由三字符的字节值开始，并在一个消息中标识该段。段可按需要或任意定义，并允许重复。专用数据区在消息中可通过数据区与相关段的位置进行查找。所有数据可利用一个字符集表示为可显示字符。ASCII可显示字符集（包括20和7E间的十六进制值）为默认的字符集，除非在MSH的首段进行修改。所有的特殊分割符和特殊字符也为可视化字符，除了段分隔符为ASCII回车字符。1.HL7的2.3版本或ASTM1238对可印刷ASCII字符的合法数据集进行的限制并无本征。前面的限制用来使许多现存通信系统的局限性进行适应。一些现存系统将利用一些8-位字符作为流控制字符来代替数据，其他系统将除去8位。-3-2.欧洲共同体(EC)需要可印刷字符(例如德文，法国重低音符f)并不在上述定义的有限数据集内。个人计算机市场通过把字母字符分配为128到256间的编码来使这些字符相互容纳，而且市场以不同的方式达到此目的。ISO8859是一个256－字符集，包括了所有需要的欧文并作为欧洲标准的候补。一旦欧洲定义了8位字符集规范，HL7将在需要的环境下接受此数据集，并无异议的进行使用。3.多字符编码：a.UNICODE–当通信使用UNICODE时，所有的字符会有同样数量的字节表征，所有的分隔符为特定字节长度的单字符，标准会以单字节长度使用，但字符的长度可以超过一个字节。b.JISX0202-ISO2022为在不同的字符集以及单字节和多字节字符表征间的转换提供一个换码序列。日本已经采纳了ISO2022，其以JISX0202为换码序列使Kanji和ASCII字符在相同的消息能够混和。单字节和多字节字符在带有JISX0202的JISKanji编码中仅使用低7位以确保对所有的标准通信系统透明。HL7消息以JISX0202发送时，所有的HL7分隔符必须以单字节的ASCII字符发送，而且从ASCII到Kanji以及Kanji到ASCII的换码序列必须出现在分隔符之间。在多数情况下Kanji的使用需限定在正文字段。JISX系列的其他部分可支持Katakana(JISX0201/ISOIR13)、Romaji(JISX0201/ISOIR14)、Kanji(JISX0208/ISOIR87)和(JISX0212/ISOIR159)，它们可以用在如JISX0202同样方式的HL7消息的使用中。c.在单个国家为表征多字节字符而使用不一致规则的情况下，要合乎倡导以确保他们使用同样的规则集。编码规则可区分空值和隐含值的数据字段，前者由两个相邻的引号表征，后者无数据表征(也就是两个连续分隔字符)。当一个数据进行校正时，空值和隐含值间区别较为重要。在前者情况下数据的字段置为空，后者情况下，该字段保留先前值。编码规则规定如果接受申请不能处理一个不存在的数据字段，该字段就认为存在而非空。编码规则规定接受申请应该忽略消息中出现的字段，但并不期望把环境量作为误差。1.5.21.5.21.5.21.5.2局部变化HL7标准是为了使数据交换标准化，而非附属的应用系统。这意味着此标准在不同机构的应用中会有更为广阔变化。在标准内支持变换需求可按以下方式寻址：4.在摘着消息中所需的数据字段需要支持消息或基本目标间的关系逻辑。其它字段被指定且可随意选择。5.对规则中的规定可以附加具有局部特征的消息或部分消息，使用这种规定可以防止标准未来版本的冲突。1.5.31.5.31.5.31.5.3标准的发展变化所有的标准必须发展成为它们支持的变化并作为结果进行应用。在对此认同情况下，标准在所有消息中包括了一个协议版本ID。新的事物或数据单元将作为标准变化的结果或由于在标准范围内允许局部实行的变化，而被增加到HL7环境中。重要的是这些变化无需通信申请可在指定位置上被执行而同时进行升级。为处理隐含和意外字段在编码规则中的特殊规定在这里非常重要。由于这些规定，新的字段可以先增加到发送或源系统；接受系统将忽略新的数据字段直到该系统被更新而使用这-4-些字段。通常这些规则首先要改变这个接收系统。直到发送系统改变，这个接收系统将发现新的“隐含”的和根据数据规则而处理的非显现数据字段。同样地，HL7编码规则支持数据字段量值上的变化。在消息中通过检查分隔符而不是偏移量来寻找字段，改变字段长度并不能改变用于检测后续字段的程序。1.5.41.5.41.5.41.5.4文件传输适用性虽然HL7标准可以按照客户－服务器(远程操作)模型进行定义，但该标准在文件传输上得到平等应用。一个或多个消息可以按照编码规则并连同一个文件及利用外部媒介如FTAM、FTP、Kermit或其他传输协议进行编码。响应可在文件中进行分组和传输。标准的第2章为HL7消息分批