文档详情

HL7卫生健康标准

博****1
实名认证
店铺
PPT
5.42MB
约37页
文档ID:588550744
HL7卫生健康标准_第1页
1/37

HL7卫生交换标准 ——学习汇报 ￿￿￿￿￿￿￿ 假定有这样一个情况出现: ￿￿￿￿￿￿张某在县属医院内科就诊,由于病情的突变,县医院已经没有条件对他继续进行治疗,必须要转到市医院进行治疗但是由于两个医院间无法实现资源共享,县医院必须对张某重新开始进行诊断,而不能利用县医院已有的资料这样不论在时间上,还是在资源上,都造成了不必要的浪费,严重的甚至可能因为错过患者的最佳治疗时机而危及患者的生命 传统HIS与与LIS系系统间通信通信统一的一的结构化构化设计 ￿￿￿￿￿￿￿￿￿￿现今的医院信息系今的医院信息系统HIS((Hosipital Information System)已)已经得到广泛使用,但得到广泛使用,但是由于缺少是由于缺少统一的医一的医疗信息交信息交换标准,使得医院都成了信息的孤准,使得医院都成了信息的孤岛,,为了解决由于信息交了解决由于信息交换的的标准不同准不同而出而出现的种种的种种问题,,HL7标准技准技术应时而生 •Part 1 什么是HL7?•Part 2 ￿HL7的发展•Part 3 HL7标准详述 什么是HL7?•HL7 全称是Health Level 7,是标准化的卫生信息传输协议,医疗领域不同应用之间电子传输的协议。

它将允许各个医疗机构在异构系统之间,进行数据交互,包括整合非标准信息格式规范各医疗机构之间,医疗机构与病人、医疗事业行政单位、保险单位以及其它单位之间各种不同信息系统之间进行医疗数据传递的标准,使医院信息系统适应“以患者信息为中心”的要求 •Health Level 7中的“Level 7”是指OSI的七层模型中的最高一层,第七层——应用层但这并不是说它遵循OSI第七层的定义数据元素,它只是用来构成它自己的抽象数据类型和编码规则它也没有规定规范说明如何支持OSI第一到第六层的数据OSI模型 HL7并没有提供一个完全的“即插即用”解决方案,因为在医疗机构的传输环境中有两个重要的影响因素:⑴医疗机构的传输环境中缺乏处理的一致性;⑵产生的结果需要在用户和厂商间进行协商因此,它提供的是一个可在较大范围内选择数据和处理流程的灵活系统,并尽可能的包括所有已知的程序(触发器Trigger)和数据(段Segment和域Field)要求 ￿HL7标准是一个文本结构的文档首先,利用一些文字处理工具将文档中的各个数据定义抽取成数据结构,再将结构的形式存入预先定义的HL7规则数据库然后,开发一种代码生成器,它根据规则数据库的内容,自动生成某一种计算机语言代码。

最后,可将这些代码加入实际应用的程序框架 •Part 1 什么是HL7?•Part 2 ￿HL7的发展•Part 3 HL7标准详述 HL7的起源•Health Level Seven,该组织成立於1987年,由SamSchultz博士在宾夕法尼亚州大学医院主持的一次会议促成了HL7组织和通信标准的诞生随着许多用户、厂商、顾问组织的加入,HL7队伍在逐渐壮大,于是成立了HL7工作组•从1994年起是美国国家标准局(ANSI)授权的标准开发组织(SDO)之一,是从事医疗服务信息传输协议及标准研究和开发的非盈利组织 发展历史•从1987年3月以来,HL7工作组大约每三到四个月就聚在一起来开发和讨论这个规范工作组加入到委员会指定开发下的每个功能接口,另外,辅助委员会指定所有的控制结构和小组的不同管理这些委员会有责任编制和维护HL7界面标准中的章节•另外,在HL7内部经常形成不同的兴趣小组来发展他的思想,并且发起一些专门委员会没有涉及的特殊看法如果一个特殊的兴趣小组的行动得到批准并且一个新的章节经过讨论认为是必须的,他们可能请求HL7技术委员会主席和执行委员会组建一个技术委员会 •在最初的三个会议上,版本1.0标准草稿准备覆盖所有接口的结构、ADT、医嘱输入、面向显示的查询。

•⒉0版本随后被准备到Tyson’s Corner的全体会议,并出现在1988年9月的Tucson的第二次全体会议上从第二次全体会议以来,2.1、2.2、2.3版本的编辑和修改就没有间断过•现已用XML开发了v3.0版,但HL7 v2.4版本仍是ANSI正式发布的版本同时,工作小组已经发展到300个人,远远超过了原来的12个人 国内的发展•HL7标准正在国内逐渐获得大家的认识2000年,中国加入HL7组织,成为HL7的成员国组织,在国内开始进行HL7标准的推广和本地化研究工作HL7的主要应用领域是HIS/RIS,目前主要是规范HIS/RIS系统及其设备之间的通信,它涉及到病房和病人信息管理、化验系统、药房系统、放射系统、收费系统等各个方面 •Part 1 什么是HL7•Part 2 HL7的发展•Part 3 HL7标准详述 HL7详述•1、 HL7标准的目标与目的•2、 HL7标准的特点•3、 HL7标准实现的功能及其方法•4、HL7标准协议简述•5、HL7接口引擎的工作原理 •总体来说,HL7的目的是促进医疗环境中的通讯,主要的目标是提供在医疗计算机应用程序之间进行数据交换的标准,这些应用程序是除去或从本质上减少用户接口编程和程序维护,否则这些编程和维护必不可少。

1、HL7标准的目的与目标 目的目的•开发和研制医疗数据信息传输协议及标准•优化临床及其管理数据信息的程序•降低卫生信息系统互联的成本•提高卫生信息系统之间数据信息共享的程度 •⑴ HL7标准应该支持各种技术环境下的数据交换,同时也应支持各种编程语言和操作系统,以及支持各种通讯环境•⑵ 同时支持单数据流和多数据流两种通讯方式•⑶ 最大限度的兼容性,预留了供不同使用者 使用的特殊的表、编码定义、和消息段(如:HL7的Z-segments)•⑷ 标准必须具有可扩展性,以支持新的要求,这包括协议本身的扩展及与现有系统和新 系统的兼容•⑸ 标准应该是在充分参考现有的产品通讯协议基础上,被广泛接受的工业标准而不应该支持特定公司的某些利益以至损害到其他用户•⑹ HL7的长期目标就是制定一种用于医疗机构电子数据交换的标准或协议目标: 2、特点•￿◈完整性-对基本的医嘱,财务,检验信息都有了规范的描述,而且做得非常详细,如病人的饮食忌讳,宗教信仰等按照相应的ISO标准(国际标准化组织划定的标准)进行描述•◈可实现性-选择OSI第七层做标准,保证其可实现性•◈兼容和扩展性-包括对中药计量单位的支持•◈安全性-由于HL7的开发和兼容性导致安全性很难保障,尽管支持数字签名,但主要还是要靠网络底层协议保证。

3、实现的功能及其方法•◆￿信息交换(Message interchange)￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿◆￿软件组织(Software components)￿•◆￿文档与记录架构(Document and record architecture)◆ 医学逻辑(Medical Logic)￿•￿HL7标准可以在不同的系统中进行接口的编址,这些系统可以发送或接收一些信息,包括:就诊者住院/登记、出院或转院(ADT)数据、查询、资源和就诊者的计划安排表、医嘱、诊断结果临床观察、账单、主文件的更新信息、医学记录、安排、就诊者的转诊以及就诊者的护理￿实现功能 •HL7实际上是一组标准的API接口,这样可以大大简化不同厂家同类应用程序接口的复杂度和工作量有二种实现的方法:•一、采用点对点通讯方法以实现不同系统的对接•二、采用HL7服务器的方法实现,HL7 Server实际上是应用服务器,形成居于HL7接口的中心数据库,这样可以减少接口数量,提高系统可靠性实现方法: 4、HL7标准协议简述•HL7标准协议就是一种数据交换协议,并不涉及底层的通讯协议 •HL7通讯协议中,有四个最基本的术语:•★触发事件(trigger events):当现实世界中发生的事件产生了系统间数据流动的需求,则称其为触发事件。

•★消息(message):它是系统间传输数据的最小单位,由一组有规定次序的段组成每个消息都是用一个消息类型来表示其用途•★段(segment):它是数据字段的一个逻辑组合每个段都用一个唯一的三字符代码所标志,这个代码称作段标志•★字段(field):它是一个字符串,是段的最小组成单位•HL7标准包含256个事件、116个消息类型、139个段、55种数据类型、408个数据字典,涉及79种编码系统基本术语 数据交换的基本单位—消息• 在HL7通信协议中,消息(Message)是数据交换的基本单位HL7的消息是自动生成的,它将HL7标准文档自动转化为一个HL7规则数据库和部分程序数据结构代码实现一个通信标准的具体工作是生成数据结构,以及实现一个构造器(Builder)和一个解析器(Parser)•数据结构表现了标准中各个数据对象的相互关系构造器将数据结构中的数据转化成能在电子数据交换媒介中传输的数据串而解析器能够将数据串解析回原来的数据结构 •在HL7通讯协议中,每个事件对应一个消息,如患者入院对应ADT A01消息•每条消息都有各自的消息类型(V2.4共有112种)来表示其用途。

消息结构•一个消息由多个段(Segment)组成,每一段都有相应的名称,用于界定其内容或功能(V2.4共有138种)而一个段又由多个数据字段(Data Field)组成•一个消息中的第一个段总是消息头段(Message head segment),它指明了发送和接收的程序名、消息类型、以及一个唯一的消息ID号码等,接下去段的构成由消息的类型决定如,PID段(Patient Identification Data)包括姓名、地址、社会保险号等一个数据字段又有可能由多个组件组成有些消息可进一步由事件码(event code)细分MessageSegment Segment..............SegmentFieldField ...............FieldComponentComponent ............... Component 消息的编码原则•单个字段的重复使用单个字段的重复使用 —— 使用重复字段分隔符使用重复字段分隔符￿￿￿￿~例:营口路例:营口路101号号￿ ￿~ 军工路军工路516号号•字段分割符字段分割符￿￿￿￿￿￿￿￿—— 使用符号使用符号￿ ￿| 作为字段作为字段之间的分割之间的分割例:例:| 营口路营口路101号号￿ ￿~ 军工路军工路516号号￿ ￿|•成分的分割成分的分割 —— 使用符号使用符号￿ ￿^ 作为成分的分割作为成分的分割例:例:| 营口路营口路101号号￿ ￿^ 200093 ~ ￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿军工路军工路516号号￿ ￿^200093 | ——子子成分成分之间由之间由““&”进行分隔进行分隔例例: |AAA^XXX~YYY&ZZZ^BBB| 工作原理HL7接口引擎工作原理图 •★Send/Receive module(发送/接收模块):支持TCP/IP通讯协议,HIS系统向数据中心发送电子病历信息,信息格式为符合HL7标准的字符串格式。

数据中心接收并解析HL7信息,将解析后的信息存到数据中心的数据库中,完成后回复发送端一个ACK确认信息,确认信息已经发送成功★HL7 Adaptor module(转换模块):实现字符串格式数据与XML格式之间的相互转换,对信息格式进行检查验证,保证发送/接收病历数据的正确完整•★HL7 API module(应用接口模块):提供符合HL7标准的应用接口,医疗应用系统可以调用接口函数,按照HL7标准格式填写参数,实现向其他医疗应用系统发送数据该模块也可以调用符合HL7标准的Windows组件应用程序,将医疗信息数据传递给医疗应用系统,实现接收其他医疗应用系统的数据•★HL7 Resource module(HL7资源模块):支持各种实际应用的HL7医疗信息事件,如检查医嘱、转诊等•★Mapping module(对照模块):提供翻译对照功能,可以按照医疗应用系统进行定制基本模块 ￿￿￿￿￿￿￿￿对于HL7接口引擎的概念,可以这样理解,它是一组支持HL7通讯的过程调用函数或控件,应用程序按照HL7接口引擎的约定提供参数,模块之间的通讯则由HL7接口引擎完成 2012年主流的医疗信息整合技术为“HL7/XML接口引擎”,在国外发达国家中,它是整合多种技术合成的医疗信息整合技术,用以转译各种医院信息系统数据至符合HL7标准的XML信息格式,以实现各种医疗卫生信息系统之间的信息共享与交换。

要深入了解HL7接口引擎的原理,我们还是必须要从数据通讯这个方面来研究HL7接口引擎 •在数据通讯方面,有两种层次的数据交换应用第一层次数据交换应用,是对现有信息进行处理,并获取其他系统的数据来完成本系统内部的功能比如在不同系统之间交换采集到的病人姓名、性别、地址、ID等数据,或者是医嘱、费用等结果信息数据在这个层次不能交换各种业务过程信息,也不能进行系统和系统之间的交互数据交换应用第二种层次的是基于不同系统之间进行整合的数据通讯,其目的达到不同系统之间的无缝连接而进行的数据通讯和数据交换应用在这个层次的数据交换不仅要交换各种结果信息,同时还要交换各种过程信息,从而达到系统之间的交互目的应用的原则是:在需要的时候获取需要的信息数据这正是HL7定义了众多的事件和消息格式的原因 数据交换方式•Engine方式方式,主要目的是使得用户原有正在使用运行的不能替换的系统具有HL7的通讯能力这种方式主要应用于系统之间较为简单的数据交换,参与数据交换的系统明确,交换的数据信息量少,投资小,系统之间不需要进行交互的情况这种方式只是相当于在整个系统中增加了一个新的通讯处理处理模块来支持HL7的处理,利用这个通讯模块来对系统之间的数据库进行数据操作,达到数据同步的目的。

从而使得应用系统的工作站终端可以从数据库中获取其他系统所提供的数据其主要缺点是:由于系统内的各个应用模块终端并不具有HL7消息的处理能力,因此,无法实现系统与系统之间的实时数据处理,以及应用终端的查询请求等应用•Ready方式方式是在整个系统中,在各个应用终端已经对HL7的接口协议进行了设计和处理,各个终端都应当可以接收和处理HL7消息,并进行相关的处理在理论上可以达到系统和系统之间的实时交互,可以相互主动地在"需要的时候"获取对方可以提供的数据信息当然,这种方式属于理想的方式,适合于在厂商开发新系统时,从更高的应用角度,进行前瞻性的设计,有利于在多系统应用环境中的应用整合￿ 数据交互场景• ￿￿￿￿以HIS和RIS/PACS之间的数据交换来说明Engine方式的实现:需求产生的起源在于一个病人要去放射科进行检查的时候,为了识别这个病人的信息,放射科需要录入病人的基本信息,而这些信息在住院管理系统中已经全部录入系统了,因此,放射科的这些工作相当于重复的录入工作,由此产生了两个系统之间需要进行的数据交换但这种交换主要是属于单向以HIS的数据库为数据源•￿HIS系统定时将数据库中PACS所需要的数据信息发送到HIS/PACS,并根据病人在数据库中的状态记录,定义其事件消息类型,如入院、出院等,但这种消息类型的定义并没有实时交换的意义,而只是为了传送病人状态,以方便对方系统进行处理而已。

￿￿￿￿￿￿这种交换方式只是两个后台数据两个后台数据库之之间的数据交的数据交换,实际上类似于数据库数据同步的功能因此,对于各工作站端点的操作人员来说其只能被动的接受数据库中已有数据进行处理,其不能够主动去实现查询、病人位置通知等数据处理操作,也不能做到实时进行数据交换,不能做到在医疗过程中进行系统之间的交互,如:实现通过HIS实时向RIS/PACS下达预约的请求消息,并从RIS/PACS直接获取病人预约信息,在这种情况下需要等到从预约处拿回预约通知单才能够知道具体的预约时间￿￿￿￿￿如果我们要主主动获取数据,该如何实现呢?或者说主动获取数据有什么意义呢?我们可以设想一个比较复杂的数据交换过程,比如下一个实例: 一个心脏外科病人在胸外科住院,该胸外科应用了供临床医生使用的工作站系统该病人需要实施心脏手术,在术前、术后需要进行心脏三位片(心脏正位片、左前斜位、右前斜位)的摄片,进行术前、术后的对比而这个时候在这两次摄片的预约和执行过程中可能出现几种情况:1、￿病人在指定的预约时间,因为某种原因不能进行前往放射科进行摄片,需要更改预约时间;2、￿在病人预约的排队等候拍片的过程中,由于心功能差或者机器故障,无法实行送检的摄片预约,取消预约,改为床旁摄片预约或更改预约时间;￿3、￿在摄片过程中由于病人情况出现问题,取消了第二、三摄片,更改预约时间;4、￿在摄片过程中发现需要进行增强摄片(也许不适用于心三位片);5、￿在摄片当时发现摄片效果不理想,重新摄片;6、￿在回到科室后发现摄片效果不理想,进行重新摄片;7、￿如果病人对预约的时间有特别要求,或者其中某个操作需要指定某个医师执行,要与放射科协商预约时间。

￿￿￿￿￿￿￿如果两个系统都是采用第一种方式,在各个工作站(包括胸外科的医生工作站、影像科室的)并没有考虑如何和其他系统进行交互,也就是说在工作站不能处理HL7消息,,那么作为病人的主管医师,必须等候到病人将此以上状况的变更带回到病房,或者与放射科之间进行联络,才能够知道摄片的进行状态和结果￿￿￿￿￿￿￿而如果两个系统都是以Ready状态实现,那么当RIS系统中对病人的执行状态进行修改的时候,则会发送相应的预约修改状态的消息传送给病房的医师,并且所有的过程都可以记录在系统中,医师可以随时通过系统了解一个病人目前在其他系统中的状态甚至,如果一个医院要达到一个更高的服务水准,达到诸如星级宾馆的服务水准:病人在到达医院的任何一个地点,接受某项服务的时候,都有医护人员可以了解该病人的状态,并及时主动为其服务,而不是病人去等待在这种情况下,医院内整体的信息流动和系统交互就显得十分必要了 学习感言HL7标准是一种抽象的理念HL7标准的学习是一种理解方式的转变HL7标准的普及对我们国内的医疗体系是一种变革,对我们每个人都是思维上的变革 。

下载提示
相似文档
正为您匹配相似的精品文档