HL7卫生健康标准.pptx

,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,2016/12/1,#,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,版本随后被准备到,Tysons 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,）细分,。,Message,Segment,Segment,.,Segment,Field,Field,.,Field,Component,Component,.,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,标准的普及对我们国内的医疗体系是一种变革，对我们每个人都是思维上的变革,