著录项信息
专利名称 | 基于RIA的监护方法 |
申请号 | CN201110352158.1 | 申请日期 | 2011-11-09 |
法律状态 | 授权 | 申报国家 | 中国 |
公开/公告日 | 2012-04-11 | 公开/公告号 | CN102406500A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | A61B5/00 | IPC分类号 | A;6;1;B;5;/;0;0;;;H;0;4;L;2;9;/;0;6查看分类表>
|
申请人 | 西安理邦科学仪器有限公司 | 申请人地址 | 陕西省西安市高新区科创路168号电子科技大学科技园C栋423、425、427号
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 西安理邦科学仪器有限公司 | 当前权利人 | 西安理邦科学仪器有限公司 |
发明人 | 石富旬;张进 |
代理机构 | 深圳市科吉华烽知识产权事务所(普通合伙) | 代理人 | 胡吉科;于标 |
摘要
本发明提供了一种基于RIA的监护方法,包括如下步骤:A.服务器与多个监护仪建立通信通道,终端机与服务器建立通信通道;B.安装在服务器中的中央监控单元并发处理业务逻辑处理步骤、实时数据推送步骤、实时数据接收步骤,所述中央监控单元向安装在终端机内的用户操作平台推送实时数据采用长连接的数据推送结合RTMP协议的方式。
1.一种基于RIA的监护方法,其特征在于,包括如下步骤:
A. 服务器与多个监护仪建立通信通道,终端机与服务器建立通信通道;
B. 安装在服务器中的中央监控单元并发处理业务逻辑处理步骤、实时数据推送步骤、实时数据接收步骤,用户操作平台安装在终端机内,中央监控单元采用长连接的数据推送结合RTMP协议的方式向用户操作平台推送实时数据;
所述业务逻辑处理步骤包括:
B11. 启动业务逻辑处理模块,用于响应用户操作平台的业务逻辑请求;
B12. 监听用户操作平台所发出的业务逻辑请求;
B13. 判断业务逻辑请求;
B14. 将处理结果发送给用户操作平台,并更新实时数据推送列表;
所述实时数据接收步骤包括:
B21. 启动实时数据接收模块,用于接收监护仪发送的实时数据;
B22. 判断工作模式;
B23. 根据不同的工作模式,进行接收实时数据;
所述B13步骤包括:
B131. 判断访问规则;
B132. 判断用户操作平台是否需要进行升级;
B133. 对用户进行认证;
B134. 对用户操作平台进行初始化;
B135. 接收对实时数据的订阅与退订;
所述实时数据推送步骤包括:
B31. 启动实时数据推送模块,用于向用户操作平台推送实时数据;
B32. 判断是否满足实时数据的推送条件;
B33. 根据实时数据推送列表,向在线的用户操作平台推送实时数据。
2.根据权利要求1所述的监护方法,其特征在于:防火墙上开放服务器的实时数据监听端口,支持TCP/IP协议的监护仪可以通过网络将实时数据远程发送给医院的服务器。
3.根据权利要求1所述的监护方法,其特征在于:在执行B131步骤至B134步骤时,每执行一个步骤,便将处理结果发送给用户操作平台;在执行B135步骤后,对实时数据推送列表进行更新。
4. 根据权利要求1所述的监护方法,其特征在于,在所述B23步骤中,工作模式为总线型网络,包括如下步骤:
B231. 初始化总线;
B232. 对网络中的监护仪进行点名;
B233. 判断当前监护仪是否响应点名,如未响应,那么进行下一监护仪的点名;
B234. 对响应的监护仪,接收其发送的实时数据;
B235. 判断监护仪发送的实时数据是否有效,如无效,则丢弃该无效的实时数据;
B236. 对有效的实时数据进行解析。
5. 根据权利要求1所述的监护方法,其特征在于,在所述B23步骤中,工作模式为以太网,包括如下步骤:
B2311. 监听服务器端指定的端口;
B2312. 判断监护仪所发送的实时数据是否超时,若超时,那么回收为该监护仪所分配的服务器端资源;
B2313. 判断监护仪发送的实时数据是否有效,如无效,则丢弃该无效的实时数据;
B2314. 判断实时数据的类型;
B2315. 解析实时数据。
基于RIA的监护方法\n技术领域\n[0001] 本发明涉及医疗领域的监护仪的数据监护方法及系统,尤其涉及基于RIA的监护方法及系统。 \n背景技术\n[0002] 中央监护系统是基于PC平台的应用软件,该软件能够通过以太网或其它方式同其他监护仪相连,实现所有监护仪的病人生理信息集中显示,便于医生、护士同一时间监控多个病人情况。同时医生也能够通过中央站软件选择操作某一个病床的监护仪,例如手动启动一次血压测量。该类型的中央站软件已经在目前的医院大量使用。 \n[0003] 目前的中央监护系统均基于C/S架构,在特定的PC机上安装中央监护系统软件后,此计算机便作为服务器端,所有监护仪的数据均发送到该服务器端进行集中处理,以达到同一时间监控多个病人的目的。随着临床应用的不断深入,产生了新的需求:医生办公室及护士办公室均有对病人进行集中监控的需求,衍生出了观察站的功能,即对原有中央监护系统进行功能扩充以原有中央站作为服务器端,可以向其它系统共享实时数据。此方案在一定程度上解决了多用户同时进行中央监护的需求,但当用户数据增长后,系统的复杂度和成本将迅速增长,同时,系统的稳定性也会随之降低。 \n[0004] 为了克服上述缺陷,一些研究人员提出了基于B/S架构的中央监护系统设计。基于B/S架构来设计中央监护系统可以有效地克服上述缺陷,但由于技术的限制,B/S架构的中央监护系统难以达到传统C/S架构中央站的高性能与用户体验效果:基于B/S架构的中央监护系统是基于AJAX技术及微软的ActiveX控件来实现实时波形的绘制与界面的动态刷新,难以实现波形的平滑刷新及多监护仪同时监护(如32台监护仪数据同时更新),现有的客户端只能与现有中央监护系统配合,实现轻量级的观察站功能。 \n发明内容\n[0005] 为了解决现有技术中的问题,本发明提供了一种基于RIA的监护方法。 [0006] 本发明提供了一种基于RIA的监护方法,包括如下步骤: \n[0007] A.服务器与多个监护仪建立通信通道,终端机与服务器建立通信通道;\n[0008] B.安装在服务器中的中央监控单元并发处理业务逻辑处理步骤、实时数据推送步骤、实时数据接收步骤,所述中央监控单元向安装在终端机内的用户操作平台推送实时数据采用长连接的数据推送结合RTMP协议的方式。\n[0009] 作为本发明的进一步改进,防火墙上开放服务器的实时数据监听端口,支持TCP/IP协议的监护仪可以通过网络将实时数据远程发送给医院的服务器。 \n[0010] 作为本发明的进一步改进,所述业务逻辑处理步骤包括: \n[0011] B11. 启动业务逻辑处理模块,用于响应用户操作平台的业务逻辑请求;\n[0012] B12. 监听用户操作平台所发出的业务逻辑请求;\n[0013] B13. 判断业务逻辑请求;\n[0014] B14. 将处理结果发送给用户操作平台,并更新实时数据推送列表。\n[0015] 作为本发明的进一步改进,所述B13步骤包括: \n[0016] B131. 判断访问规则;\n[0017] B132. 判断用户操作平台是否需要进行升级;\n[0018] B133. 对用户进行认证;\n[0019] B134. 对用户操作平台进行初始化;\n[0020] B135. 接收对实时数据的订阅与退订。\n[0021] 作为本发明的进一步改进,在执行B131步骤至B134步骤时,每执行一个步骤,便将处理结果发送给用户操作平台;在执行B135步骤后,对实时数据推送列表进行更新。 [0022] 作为本发明的进一步改进,所述实时数据接收步骤包括: \n[0023] B21. 启动实时数据接收模块,用于接收监护仪发送的实时数据;\n[0024] B22. 判断工作模式;\n[0025] B23. 根据不同的工作模式,进行接收实时数据。\n[0026] 作为本发明的进一步改进,在所述B23步骤中,工作模式为总线型网络,包括如下步骤: \n[0027] B231. 初始化总线;\n[0028] B232. 对网络中的监护仪进行点名;\n[0029] B233. 判断当前监护仪是否响应点名,如未响应,那么进行下一监护仪的点名;\n[0030] B234. 对响应的监护仪,接收其发送送的实时数据;\n[0031] B235. 判断监护仪发送的实时数据是否有效,如无效,则丢弃该无效的实时数据;\n[0032] B236. 对有效的实时数据进行解析。\n[0033] 作为本发明的进一步改进,在所述B23步骤中,工作模式为以太网,包括如下步骤: \n[0034] B2311. 监听服务器端指定的端口;\n[0035] B2312. 判断监护仪所发送的实时数据是否超时,若超时,那么回收为该监护仪所分配的服务器端资源;\n[0036] B2313. 判断监护仪发送的实时数据是否有效,如无效,则丢弃该无效的实时数据;\n[0037] B2314. 判断实时数据的类型;\n[0038] B2315. 解析实时数据。\n[0039] 作为本发明的进一步改进,所述实时数据推送步骤包括: \n[0040] B31. 启动实时数据推送模块,用于向用户操作平台推送实时数据;\n[0041] B32. 判断是否满足实时数据的推送条件;\n[0042] B33. 根据实时数据推送列表,向在线的用户操作平台推送实时数据。\n[0043] 本发明还公开了一种基于RIA的监护系统,包括服务器、监护仪、终端机、以及安装在服务器中的中央监控单元、和安装在所述终端机内的用户操作平台,所述中央监控单元包括并发处理的业务逻辑处理模块、实时数据推送模块、实时数据接收模块,所述中央监控单元向安装在终端机内的用户操作平台推送实时数据采用长连接的数据推送结合RTMP协议的方式。 \n[0044] 本发明的有益效果是:中央监控单元采用多线程技术来并发处理监护仪实时数据的上传与解析、用户操作平台的业务逻辑请求、实时数据向用户操作平台的推送;对于实时数据的传输,采用基于长连接的数据推送方案+RTMP协议的方式进行数据传输,RTMP协议用于以保证数据的实时性,基于长连接的数据推送方案采用发布/订阅的模式,用于解决传统请求/应答模式下对频繁的网络请求对数据实时性的影响,同时,基于长连接的数据推送技术,可以有效地解决防火墙的穿透问题,使有用户位于私有网络下,通过NAT方式上网也可以使用中央监控单元。 \n附图说明\n[0045] 图1是本发明的方法流程图。 \n[0046] 图2是本发明的业务逻辑处理步骤方法流程图。 \n[0047] 图3是本发明的判断业务逻辑请求步骤方法流程图。 \n[0048] 图4是本发明的实时数据接收步骤方法流程图。 \n[0049] 图5是本发明的实时数据接收步骤的一实施例的方法流程图。 \n[0050] 图6是本发明的实时数据接收步骤的另一实施例的方法流程图。 \n[0051] 图7是本发明的实时数据推送步骤的方法流程图。 \n具体实施方式\n[0052] 本发明公开了一种基于RIA的监护方法,RIA是Rich Internet Applications的缩写,翻译为丰富互联网应用程序。RIA的目标是将桌面程序的表现力与浏览器的程序的方便、快捷结合在一起。开发者可以在浏览器程序上部署C/S客户端的程序,得到比传统HTML更强大的表现力。 \n[0053] 该系统综合了C/S架构系统功能强大,运行稳定的特点及B/S架构系统易于部署与维护、支持差异化功能支持下多用户并发访问的特点,为中央监护系统接入其它信息化系统及医疗信息的网络化、开放化提供了新的解决方案。 \n[0054] 为了实现上述目的,基于RIA的中央监护系统包括生理监护仪、中央监护系统服务器及支持浏览器的客户端操作系统,该客户端操作系统简称为客户端,该中央监护系统服务器简称为服务器。生理监护仪可以通过Internet、以太网、RS485总线或串口与服务器进行通讯,客户端通过Internet、3G网络或以太网方式访问服务器。 \n[0055] 所述的客户端是支持RIA程序(如Flex、Sliverlight)运行的平台,客户端可以安装在终端机内,该终端机可以是普通PC机、智能手机、平板电脑等。 \n[0056] 基于RIA技术的访问可以有两种方式:1.基于B/S架构的系统访问,用户无需安装客户端,通过浏览器访问服务器所对应的网址,便可获取原来C/S架构中央站的强大功能与用户体验;2.类似于C/S架构的系统访问方式,对于习惯于传统C/S架构使用的用户,可以选择进行相应的安装,使操作界面脱离于浏览器来运行,以更加适应用户的操作习惯。\n无论是通过客户端或者是未通过客户端对服务器进行访问,都需要在终端机内安装用户操作平台对服务器进行访问,该用户操作平台相当于B/S架构下的通过浏览器显示的界面,该用户操作平台也相当于C/S架构下的客户端。 \n[0057] 如图1所示,本发明的监护方法包括步骤S1和步骤S2:在步骤S1中,服务器与多个监护仪建立通信通道,终端机与服务器建立通信通道。在步骤S1中,服务器与多个监护仪建立通信通道是指服务器与监护仪之间通过以太网或总线型网络建立了一种物理上的通信通道,但不意味着监护仪与服务器已开始进行通讯,也就是说通信通道是服务器与监护仪进行通讯的保障;同理,终端机与服务器建立通信通道也是指通信通道是服务器与终端机进行通讯的保障。在步骤S2中,安装在服务器中的中央监控单元并发处理业务逻辑处理步骤、实时数据推送步骤、实时数据接收步骤,所述中央监控单元向安装在终端机内的用户操作平台推送实时数据采用长连接的数据推送结合RTMP协议的方式。在步骤S2中,中央监控单元可以是一个平台,或者可以直接认为是一个软件;因为中央监控单元并发处理业务逻辑处理步骤、实时数据推送步骤、实时数据接收步骤,所以处理以上三个步骤时并无时间上的执行顺序,可以同时处理业务逻辑处理步骤、实时数据推送步骤、实时数据接收步骤;也可以是先进行业务逻辑处理步骤,再进行实时数据接收步骤,最后执行实时数据推送步骤。 \n[0058] RTMP协议用于以保证数据的实时性,基于长连接的数据推送方案采用发布/订阅的模式,用于解决传统请求/应答模式下对频繁的网络请求对数据实时性的影响。同时,基于长连接的数据推送技术,可以有效地解决防火墙的穿透问题,使有用户位于私有网络下,通过NAT方式上网也可以访问中央监控单元。 \n[0059] 本发明所称实时数据是监护仪所监测到的生理参数信息,该生理参数信息包括心电、血氧、有创血压、麻醉实时波形数据,呼吸、血氧、无创血压、心率、CTG、ST1~12等各种监护仪所上传的生理参数信息。服务器与监护仪建立通信通道过程可以视为服务器与监护仪连接的过程,服务器与监护仪进行连接可以采用以太网、Internet、3G网络、RS485总线等多种连接方式,经过服务器内的中央监控单元对监护仪发送过来的实时数据进行数据处理后,通过TCP/IP协议实现与安装在终端机内的用户操作平台的通讯,使得在系统安全性允许的情况下,用户可以从任何地方访问服务器内的中央监控单元,将中央监控单元的访问从医院内部的固定位置延伸到可以访问服务器的任何位置,极大扩充了服务器的使用范围。 \n[0060] 同时,通过在医院防火墙上开放服务器的实时数据监听端口,支持TCP/IP协议的监护仪可以通过网络将实时数据远程发送给医院的服务器,为远程医疗提供了新的解决方案。 \n[0061] 如图2所示,业务逻辑处理步骤包括步骤W1至步骤W4,在步骤W1中,启动业务逻辑处理模块,用于响应用户操作平台的业务逻辑请求。在步骤W2中,监听用户操作平台所发出的业务逻辑请求。在步骤W3中,判断业务逻辑请求,对业务逻辑请求进行判断,以便进行不同的处理。在步骤W4中,将处理结果发送给用户操作平台,并更新实时数据推送列表。 [0062] 如图3所示,在步骤W3中包括步骤Q1至步骤Q5,在步骤Q1中,判断访问规则。在步骤Q2中,判断用户操作平台是否需要进行升级。在步骤Q3中,对用户进行认证。在步骤Q4中,对用户操作平台进行初始化。在步骤Q5中,接收对实时数据的订阅与退订。 [0063] 在执行步骤Q1至步骤Q4时,每执行一个步骤,便将处理结果发送给用户操作平台;在执行步骤Q5后,对实时数据推送列表进行更新。例如:在执行步骤Q1后,通过用户的IP地址等信息,通过访问规则对用户的访问请求进行判断,若符合访问规则,则允许用户访问中央监控单元,否则拒绝提供服务;在执行步骤Q2后,判断用户操作平台是否需要进行升级,浏览器会自动对用户计算机缓存的用户操作平台进行判断,以确定其是否需要下载新的用户操作平台,若用户尚未访问过中央监控单元,或是缓存的用户操作平台版本比较旧,则自动请求新的用户操作平台,对于需要进行用户操作平台升级的用户,浏览器自动下载服务器上最新的用户操作平台;在执行步骤Q3后,对用户的身份、用户操作平台的合法性进行在服务器端进行认证,通过用户所输入的用户名、密码及系统中该用户的访问规则(如允许登录IP),对用户身份进行认证,明确了用户的权限;在执行步骤Q4后,用户操作平台的初始化包括系统信息(如医院名称、科室名称)、用户信息(当前用户名称、姓名等)以及界面布局的自动排布,界面布局的自动排布主要是根据当前在线的监护仪的种类、数量信息,结合界面可用部分的大小以及用户有权使用的功能,采用自适应算法生成相应的界面,并要判断用户操作平台的初始化是否正常结束;在执行步骤Q5后,判断用户是否上线,如上线,那么进行实时数据的订阅,如下线,那么取消实时数据的订阅,避免浪费服务器的资源。通过执行步骤Q2后,使得可以在无须用户手动参与的情况下完成用户操作平台的升级,大大降低了系统的维护及升级成本。用户通过浏览器或其它方式访问中央监控单元的服务器地址,与传统C/S架构中央站系统相比,本方法采用基于B/S架构的方式来进行中央监控单元的访问,无须安装客户端软件,克服了以往中央监护只能在安装有客户端的计算机上访问的限制,使得系统的使用范围进一步扩充,系统的升级与维护也更加灵活;与其它B/S架构方案相比,基于RIA的中央监护方法,由于其强大的运行时环境支持,界面表现能力接近于传统的C/S架构程序,使得系统可以实现传统C/S架构程序才能实现的复杂界面表现效果以复杂业务逻辑处理能力,克服了传统B/S架构方案只能实现一些简单功能,界面表现力较弱的缺陷。 \n[0064] 如图4所示,实时数据接收步骤包括步骤X1至步骤X3,在步骤X1中,启动实时数据接收模块,用于接收监护仪发送的实时数据。在步骤X2中,判断工作模式,根据服务器与监护仪通讯方式的不同,判断服务器工作于何种模式下。在步骤X3中,根据不同的工作模式,进行接收实时数据。 \n[0065] 如图5所示,在步骤X3中,工作模式为总线型网络,包括如下步骤Y1至步骤Y6,在步骤Y1中,初始化总线,服务器首先初始化整个总线网络的状态。在步骤Y2中,对网络中的监护仪进行点名,对连接在总线型网络中的监护仪进行点名,通过点名,查找在线的监护仪,并控制其数据收发。在步骤Y3中,判断当前监护仪是否响应点名,如未响应,那么进行下一监护仪的点名。在步骤Y4中,对响应的监护仪,接收其发送送的实时数据。在步骤Y5中,判断监护仪发送的实时数据是否有效,如无效,则丢弃该无效的实时数据。在步骤Y6中,对有效的实时数据进行解析。 \n[0066] 作为步骤X3的另一实施例,如图6所示,在步骤X3中,工作模式为以太网,包括步骤Z1至步骤Z5,在步骤Z1中,监听服务器端指定的端口,当服务器与监护仪采用以太网方式进行通讯时,实时数据接收模块开始监听服务器端所指定的端口。在步骤Z2中,判断监护仪所发送的实时数据是否超时,若超时,那么回收为该监护仪所分配的服务器端资源; 实时数据接收模块判断监护仪发送数据是否已经达到其超时设定,若满足条件,则认为该监护仪离线,并回收为该监护仪数据接收与解析所分配的服务器端资源,否则继续进行实时数据监听。在步骤Z3中,判断监护仪发送的实时数据是否有效,如无效,则丢弃该无效的实时数据。在步骤Z4中,判断实时数据的类型,若属于监护仪新接入或断开与服务器的连接,则执行服务器端资源的分配或回收工作。在步骤Z5中,解析实时数据,对于接收到的实时数据,按照其编码方式进行解码,获得监护仪发送的实时数据。分配或回收服务器资源:\n当监护仪连接到服务器,或与服务器断开连接时,完成针对监护仪数据接收与解码的服务器端资源分配与回收,避免服务器端资源的浪费。 \n[0067] 如图7所示,实时数据推送步骤包括步骤K1至步骤K3,在步骤K1中,启动实时数据推送模块,用于向用户操作平台推送实时数据。在步骤K2中,判断是否满足实时数据的推送条件,根据从监护仪端接收到的数据和服务器的用户在线情况,判断是否满足实时数据的推送条件。在步骤K3中,根据实时数据推送列表,向在线的用户操作平台推送实时数据。步骤K2和步骤K3为本发明所采用的数据推送机制所特有的实时数据传输方式,实时数据依托RTMP协议进行传输;发布/订阅模式的采用,克服了传统B/S架构系统下请求/应答方式下,只能由客户端发出请求,服务器无法主动向客户发送信息为系统部分业务需求的实现带来的影响。在减少数据请求的数量的同时,克服了用户访问设置位于防火墙之后造成的服务器无法主动发送数据的问题。 \n[0068] 本发明还公开了一种基于RIA的监护系统,包括服务器、监护仪、终端机、以及安装在服务器中的中央监控单元、和安装在所述终端机内的用户操作平台,所述中央监控单元包括并发处理的业务逻辑处理模块、实时数据推送模块、实时数据接收模块,所述中央监控单元向安装在终端机内的用户操作平台推送实时数据采用长连接的数据推送结合RTMP协议的方式。 \n[0069] 该基于RIA的监护系统综合了C/S架构系统功能强大,运行稳定的特点及B/S架构系统易于部署与维护、支持差异化功能支持下多用户并发访问的特点,为系统接入其它信息化系统及医疗信息的网络化、开放化提供了新的解决方案。 \n[0070] 以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。
法律信息
- 2013-12-04
- 2012-05-23
实质审查的生效
IPC(主分类): A61B 5/00
专利申请号: 201110352158.1
申请日: 2011.11.09
- 2012-04-11
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有引用任何外部专利数据! |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |