CN106027566A - 基于sip传输协议的移动心电采集及诊断系统 - Google Patents

基于sip传输协议的移动心电采集及诊断系统 Download PDF

Info

Publication number
CN106027566A
CN106027566A CN201610547775.XA CN201610547775A CN106027566A CN 106027566 A CN106027566 A CN 106027566A CN 201610547775 A CN201610547775 A CN 201610547775A CN 106027566 A CN106027566 A CN 106027566A
Authority
CN
China
Prior art keywords
data
server
proxy server
electrocardiogram
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201610547775.XA
Other languages
English (en)
Other versions
CN106027566B (zh
Inventor
周蒨
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Innovation Medical Technology Co Ltd
Original Assignee
Shanghai Innovation Medical Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Innovation Medical Technology Co Ltd filed Critical Shanghai Innovation Medical Technology Co Ltd
Priority to CN201610547775.XA priority Critical patent/CN106027566B/zh
Publication of CN106027566A publication Critical patent/CN106027566A/zh
Application granted granted Critical
Publication of CN106027566B publication Critical patent/CN106027566B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本发明属于物联网技术领域，具体为一种基于SIP传输协议的移动心电采集及诊断系统。本发明系统包括心电采集工作站、心电数据传输与控制、心电会诊工作站、心电数据库、和心电信息管理系统。系统是基于通讯SIP传输协议的集心电图采集、查看、会诊及管理为一体的平台；通过业务系统事件触发集成整个过程，系统可与HIS系统及其他第三方系统对接，实现数据交换。心电数据的传输使用SIP会话协议，用于注册、会话、传输、控制和释放会话，该协议采用询问、应答机制的方式实现实时心电数据的传输。本发明可用于医疗物联网，系统技术成熟、安全可信、部署快速便捷、有助于推动移动医疗的发展，拥有广阔的应用前景。

Description

基于SIP传输协议的移动心电采集及诊断系统
技术领域
本发明属于物联网技术领域，具体涉及基于SIP通讯协议传输数据的移动心电采集及诊断系统。
背景技术
SIP（Session Initiation Protocol会话初始协议）是一个在IP网络上进行多媒体通信的应用层控制协议，它被用来创建、控制、结束一个或多个参加者参加的会话进程。这些会话包括文本、视频、语音、远程医疗等。即所有的因特网上交互式两方或多方多媒体通信活动，统称为多媒体会话。SIP 协议是Internet制定设计的协议，采用UTF-8 字符集来进行编码的文本协议，采用询问与应答机制，参加会话的成员可以通过组播方式、单播联网方式或者两者结合的方式进行通信。它是一种应用层协议，独立于传输层协议，可以承载在不同的传输协议上。如图1所示。
1、SIP协议支持终端用户能够在任何地方、任何时间请求和获得服务会话启动协议， SIP协议功能实体，如下几种：
定位服务（Location Service）：SIP重定位服务器或代理服务器用来获得被叫位置的一种服务，可由定位服务器提供，但SIP协议不规定SIP服务器如何请求定位服务。
代理服务器（Proxy sever）：用于代表其他用户发出请求的中间程序。它既是客户机也是服务器。用户请求可以直接被代理服务器处理或被转发给别的代理服务器。代理服务器在转发之前要对消息进行解析 ，必要时还会改写请求。
重定向服务器（Redirect Server）：用来接收SIP请求，将其地址映射成零个或多个新地址，并把结果返回给客户。收到主叫用户的INVITE邀请消息，它通过查找定位服务器发现该请求应该被重新定向（重定向主要原因为：位置改变、负荷分担等），就构造一个重定向响应消息（状态码为3xx），将新的目标地址回送给主叫用户。主叫用户收到重定向响应消息后，将逐一向新的目标地址发送INVITE邀请，直至收到成功响应并建立关联。
注册员（Register）：用来接收 REGISTER 请求消息的服务器，常与代理或重定向服务器在同一位置，可以提供定位服务。
用户代理客户端（User Agent Client）：用来发起SIP请求的客户程序。
用户代理服务器（User Agent Server):收到SIP请求后负责与用户联系并代表用户回送响应的服务程序。该响应可以表示接受、拒绝或重定向请求消息。
SIP 设计采用客户端/服务器架构，其逻辑实体如图2所示。
2、SIP协议其结构化的层次关系，如图3所示。
SIP 消息采用文本方式编码，消息包括两类：请求消息和响应消息。消息（Message）是SIP协议的基本单位，客户端和服务器端的基本交互单元，如图4所示。
SIP消息有两种：客户机到服务器的请求（Request）, 服务器到客户机的响应（Response）。
SIP消息由一个起始行（start-line）、一个或多个字段（field）组成的消息头、一个标志消息头结束的空行（CRLF）以及作为可选项的消息体（message boby）组成。
CRLF:回车换行（carriage return/line feed）CRLF是一个标志消息头结束的空行。
A、请求消息：用于客户端为了激活按特定操作而发给服务器的SIP 消息。请求消息类型包括： INVITE，ACK，OPTIONS，BYE，CANCEL 和 REGISTER 消息等，见表1。
表1
Request = Request-Line *(general-header | request-header | entity-headerCRLF [message-body]
请求行（Request-Line）以方法（method）标记开始，后面是Request-URI和协议版本（SIP-Version）,最后以回车键结束，各个元素间用空格键字符间隔。
Request-Line = Method SP Request-URI SP SIP-Version CRLF SIP 。例如：INVITE sip:info@sidmedical.cn SIP/2.0
用术语“method”来对说明部分作以描述，Method标识是区分大小写的。SIP定义了以下几种方法（methods）。
Method = “INVITE” | “ACK” | “OPTIONS” | “BYE” | “CANCEL” |“REGISTER” | “INFO”。
B、响应消息：用于对请求消息进行响应，指示呼叫的成功或失败状态。响应消息由状态码来区分,状态码包含三位整数，状态码的第一位用于定义响应类型，另外两位用于进一步对响应进行更加详细的说明，包括：1xx,2xx,3xx,4xx,5xx,6xx，见表2。
表2
Response = Status-Line *(general-header | response-header | entity-headerCRLF [message-body] 。
状态行（Status-Line）以协议版本开始，接下来是用数字表示的状态码（Status-Code）及相关的文本说明，最后以回车键结束，各个元素间用空格字符（SP）间隔，除了在最后的CRLF序列中，这一行别的地方不允许使用回车或换行字符。
Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF。
SIP协议中用三位整数的状态码（Status Code）和原因值（Reason Code）来表示对请求的作出回答，状态码用于机器识别操作，原因短语（Reason-Phrase）是对状态码的简单文字描述，用于人工识别操作。
例如：SIP/2.0 200 OK
Status-Code = 1xx (Information) | 2xx (Success) | 3xx (Redirection) | 4xx(Client-Error) | 5xx (Service-Error) | 6xx (Global-Failure) | extension-code。
3 基本数据类型
。
4、SIP消息：
SIP消息（Message）采用文本方式编码，任一SIP消息都由起始行、头域和消息体组成，头域都必须以CRLF（回车换行）结尾。如图5所示。
（1）SIP起始行分请求行（Request-Line）和状态行（Status-Line）两种，其中请求行是请求消息的起始行，状态行是响应消息的起始行。如：
请求行：REGISTER sip：registrar.bplace.com SIP/2.0
状态行：SIP/2.0 200 OK
（2）头域(SIP Header)
携带SIP实体的属性、消息体的属性等。头域必须以CRLF结尾，头域的基本结构，如：
头域名：头域值；头域参数
说明：头域参数不是必备的，有些头域不存在头域参数
举例：
From: sip:sc@sidmecical.cn；tag=1234567890
To: sip:info@ sidmecical.cn;
Call-ID: info@sidmecical.cn
头域－单值与多值:
单值：消息里面只能出现一次，如From，To等
多值：消息里面可以多次出现，如Via，Route等
头域－域值的顺序
顺序有关的： Via， Route，Record-Route
顺序无关的： Allow，Require
重要的头域:如下的5个头域必须包含在每个SIP消息中。
Via ：用于表示请求经过的SIP实体和路由响应；
例如：Via：SIP/2.0/UDP sidmedical.cn;branch=z9hG4bKkjshdyff
From：用于标识请求的发起者；以呼叫为例，可能是主叫也可能是被叫；
格式为：From：显示名 <sip-URL> ;tag=××××
To：用于表示请求的接收者；
格式为：To：显示名 <sip-URL> ;tag=××××
Call-ID ：用于唯一标识一次邀请或者一次注册；
格式为：Call-ID：本地标识@主机
CSeq：用于表示请求的顺序号；
例如：CSeq：4711 INVITE
（3）消息体(SIP Body)
MIME类型的消息体，可以支持任何类型的消息体（文本/二进制）和复合消息体（包含多个单消息体）
消息体的属性通过Content头域来描述：
Content-Type：消息体的类型，可以是SDP/Text或者其他
Content-Length ：消息体的长度，对于UDP不是必须，对于TCP则是必须
Content-Language：消息体的语言类型
Content-Encoding：消息体的编码类型，如是否进行了zip压缩
Content-Disposition：对于消息体的处理方法。
发明内容
本发明的目的在于提供一种基于SIP传输协议的集心电实时采集、传输、显示、远程会诊为一体的移动心电采集及诊断系统。
本发明提供的移动心电采集及诊断系统，使用SIP协议传输数据，通过业务系统事件触发集成过程，将采集系统的心电图数据实时传输至心电会诊工作站，在采集端和会诊端实时查看心电图，进行心电诊断，并统一将业务数据存储至数据库。
一、SIP事务定义
一个SIP事务（ Transaction ）包含：
SIP事务（ Transaction ）由一个单一的请求和对这个请求的任何响应（包括零或多个临时响应以及一个或多个最终响应）组成。事务中的请求是INVITE（称为INVITE 事务）时，只有最终响应不是2xx 响应时这个事务才包括ACK。如果最终响应是2xx，那么不应将ACK视为事务的一部分。该ACK视为单独事务。事务可以分为两大类：
1、INVITE事务：INVITE 事务由一个三向握手组成。客户端事务发送INVITE，服务器事务发送响应，客户端事务还要发送一个ACK。对于INVITE的成功响应，ACK不属于INVITE事务，而是单独的事务。如图6所示。
2、非INVITE事务：两次握手 （如BYE）
非INVITE 事务不使用ACK。它们是简单的请求--响应交互，对于非INVITE事务，一般不存在临时响应，对于最终响应的处理也是一样的。如图7所示。
3、特殊的事务
ACK事务：对于200 of INVITE的确认（ACK）事务，是一个单独的事务。也就是说一个消息就是一个事务；
CANCEL事务：CANEL事务只能用于CANCEL INVITE事务，而不能用于CANCEL 非INVITE事务；CANCEL事务的 branch 参数和 INVITE是相同的，CANCEL事务只能在收到INVITE的临时响应后（包括100），最终响应之前发送。如图8所示。
4、事务的可靠性——消息重传
可靠传输上的请求/响应消息不会重传，SIP协议可以承载在非可靠的UDP传输协议之上，所以在SIP协议中引入了超时重传机制来保证可靠性，对于INVITE事务和非INVITE事务，定义了不同的重传方法：
INVITE事务
（1）对不可靠的传输，客户端事务会在时间间隔T1 后重传请求，每次重传后该时间翻倍。T1 是对往返时间（RTT）的估计，其缺省值为500ms。对于T1 的缺省值来说，这将会产生500ms、1s、2s、4s、8s、16s的时间间隔；
（2）接收到一个1xx 响应后，任何重传都停止，客户端会等待进一步的响应；
（3）对客户端事务接收到的每一个最终响应，客户端事务都会发送一个ACK，其目的是结束响应的重传。
非INVITE事务
（1）对于不可靠的传输，请求在一个时间间隔（时间间隔起始值为T1，在到T2 前该时间间隔每次翻倍）内进行重传。如果接收到一个临时响应，那么对不可靠传输而言，将继续重传（但时间间隔在T2 内）。对于T1 和T2 的缺省值来说，这将会产生500ms、1s、2s、4s、4s、4s的时间间隔；
（2）服务器事务只有在接收到重传请求时，才会重传它发送的最后一个响应，这个响应可以是临时响应，也可以是最终响应。这就是即使在临时响应之后，仍需继续重传请求的原因：它们是为了确保可靠的传输最终响应。
二、SIP对话
对话（Dialog）是两个UA 间持续一段时间的对等SIP 关系，对话是由To 标签、From 标签和Call-ID 一起定义UAC和UAS间对等的SIP 关系。
对话不关心任何消息体的信息，由 Call-ID，From Tag，To Tag 唯一标识；建立后不能被修改。当收到带To Tag的 1xx 响应（非100）时，进入Early Dialog 状态；被叫发送200 OK且主叫收到 200 OK后，进入了Confirmed状态。如图9所示。
在Early 状态下，主叫可以通过发送BYE或CANCLE来终结Dialog；
在arly 状态下，或者通过被叫的失败应答来终结Dialog；
在Early 状态下，被叫是不能发送BYE来终结Dialog的；
Confirmed状态下，主叫和被叫都能通过BYE来终结Dialog。
三、通信流程
1、SIP消息注册
用户每次开机时，都需要向服务器注册，当SIP Client的地址发生改变时需要重新注册，注册信息必须定期刷新，通常Register将注册信息保存到Location Server中，作用是将AOR地址绑定到某个Contact地址上，便于Proxy在呼叫时查找被叫的地址。如图10所示，说明如下：
（1）用户代理客户端（UAC）向用户代理服务器（UAS）发起注册请求；
（2）用户代理服务器（UAS）向用户代理客户端（UAC）返回401，即该用户无权限；
（3）户代理客户端（UAC）授权，再次向用户代理服务器（UAS）发起注册请求；
（4）用户代理服务器（UAS）注册成功向用户代理服务器（UAC）返回200 OK消息。
UAC：User Agent Client即用户代理客户端。一个address-of-record(AOR)是一个SIP或者SIPS URI，它指向了一个具有定位服务的主机，这个主机可以把URI映射成为用户真正物理位置的URI。
UAS：User Agent Server即用户代理服务器。
2、直接传输
当主叫用户代理客户端（UAC）知道被叫的当前的位置时，可以通过INVITE消息直接向被叫用户代理服务器（UAS）发出呼叫请求。直接呼叫最为简单，并且也是其他呼叫方式的基础。如图11所示，说明如下：
（1）用户代理客户端（UAC）向用户代理服务器（UAS）发起INVITE请求；
（2）用户代理服务器（UAS）向用户代理客户端（UAC）返回100，即表示已经接收到请求消息，正在对其进行处理；
（3）用户代理服务器（UAS）向用户代理客户端（UAC）返回200 OK消息；
（4）用户代理客户端（UAC）向用户代理服务器（UAS）返回ACK消息；
（5）用户代理客户端（UAC）和用户代理服务器（UAS）之间数据传输。
3、代理传输
随着后期用户数量的增加，应用并发量逐步扩大，可以逐步增加接入心电服务器，并使用代理服务器或重定向服务器来负荷分担，使得系统更有效使用与资源分配。所述服务器端（重定向服务器、代理服务器）：用户客户端向服务器端进行注册前，所述服务器端根据各服务器运行情况，分配负荷最小的一个可用SIP注册服务器给所述用户客户端。
当主叫用户代理客户端（UAC）不知道被叫的当前的位置时，UAC可通过网络中间的服务器设备的转发，最终到达UAS。即用户代理客户端（UAC）可以向代理服务器（ProxyServer）发起INVITE请求，再由代理服务器（Proxy Server）向用户代理服务器（UAS）发出呼叫请求。如图12所示，流程如下：
（1）用户代理客户端（UAC）向代理服务器（Proxy Server）发起INVITE请求；
（2）代理服务器（Proxy Server）向用户代理客户端（UAC）返回100，即表示已经接收到请求消息，正在对其进行处理；
（3）代理服务器（Proxy Server）向用户代理服务器（UAS）发起INVITE请求；
（4）用户代理服务器（UAS）向代理服务器（Proxy Server）返回200 OK消息；
（5）代理服务器（Proxy Server）向用户代理客户端（UAC）返回200 OK消息；
（6）用户代理客户端（UAC）向代理服务器（Proxy Server）返回ACK消息；
（7）代理服务器（Proxy Server）向用户代理服务器（UAS）返回ACK消息；
（8）用户代理客户端（UAC）、代理服务器（Proxy Server）、用户代理服务器（UAS）之间数据传输。
4、重定向传输
流程如图13所示，说明如下：
（1）用户代理客户端（UAC）向重定向服务器（RedirectServer）发起INVITE请求；
（2）重定向服务器（RedirectServer）向用户代理客户端（UAC）返回301，即表示永久迁移；
（3）用户代理客户端（UAC）向重定向服务器（RedirectServer）返回ACK消息；
（4）用户代理客户端（UAC）向用户代理服务器（UAS）发起INVITE请求；
（5）用户代理服务器（UAS）向用户代理客户端（UAC）返回200 OK消息；
（6）用户代理客户端（UAC）向用户代理服务器（UAS）返回ACK消息；
（7）用户代理客户端（UAC）和用户代理服务器（UAS）之间数据传输。
5、重定向代理传输
流程如图14所示，说明如下：
（1）用户代理客户端（UAC）向重定向服务器（RedirectServer）发起INVITE请求；
（2）重定向服务器（RedirectServer）向用户代理客户端（UAC）返回302，即表示临时迁移；
（3）用户代理客户端（UAC）向重定向服务器（RedirectServer）返回ACK消息；
（4）用户代理客户端（UAC）向代理服务器（Proxy Server）发起INVITE请求；
（5）代理服务器（Proxy Server）向用户代理客户端（UAC）返回100，即表示已经接收到请求消息，正在对其进行处理；
（6）代理服务器（Proxy Server）向用户代理服务器（UAS）发起INVITE请求；
（7）用户代理服务器（UAS）向代理服务器（Proxy Server）返回200 OK消息；
（8）代理服务器（Proxy Server）向用户代理客户端（UAC）返回200 OK消息；
（9）用户代理客户端（UAC）向代理服务器（Proxy Server）返回ACK消息；
（10）用户代理客户端（UAC）、代理服务器（Proxy Server）、用户代理服务器（UAS）之间数据传输；
（11）用户代理服务器（UAS）向代理服务器（Proxy Server）发送BYE消息；
（12）代理服务器（Proxy Server）向用户代理客户端（UAC）发送BYE消息；
（13）用户代理客户端（UAC）向代理服务器（Proxy Server）返回200消息；
（14）代理服务器（Proxy Server）向用户代理客户端（UAC）返回200 OK消息。
上述SIP消息注册、直接传输、代理传输、重定向传输、重定向代理传输等流程中出现的：401，100，200 ，301，302，等等，其数字标号的含义参见表2；INVITE、ACK、BYE，等等，其含义参见表1。
6、心电数据传输
当心电工作站向服务器请求发送心电图数据时，心电工作站SIP模块发送数据时即触发系统整个流程：首先，心电采集工作站采集心电图数据，并将心电图数据传输给服务器，服务器SIP模块接收数据，并对接收的心电图数据拆包并进行解析，然后将数据发送给心电会诊工作站，再向移动心电工作站发送响应消息。另外服务器同时将接收的心电图数据转储至数据库。心电会诊工作站SIP模块通过SIP协议接收服务器发送的数据，对数据进行解析后在心电会诊工作站实时显示移动心电采集的心电图，医生可以在会诊工作站进行会诊相关操作。
1）心电采集
流程如图15所示，说明如下：
（1）采集客户端（MIEC）向心电服务器（MIESERVER）发送邀请；
（2）心电服务器（MIESERVER）创建直播间；
（3）心电服务器（MIESERVER）返回成功消息给心电采集客户端（MIEC）；
（4）采集客户端（MIEC）发送心电数据给心电服务器（MIESERVER）；
（5）心电服务器（MIESERVER）将数据转发至直播间；
（6）心电服务器（MIESERVER）向心电采集客户端（MIEC）发送接收到数据响应；
（7）采集客户端（MIEC）向心电服务器（MIESERVER）发送链接终止命令；
（8）心电服务器（MIESERVER）通知直播间心电采集客户端（MIEC）退出；
（9）心电服务器（MIESERVER）向心电采集客户端（MIEC）终止连接的应答。
2）心电采集发送
IOCP（I/O Completion Port）,常称I/O完成端口。 IOCP模型属于一种通讯模型，适用于(能控制并发执行的)高负载服务器的一个技术。用于高效处理很多很多的客户端进行数据交换的一个模型。或者可以说，就是能异步I/O操作的模型。流程如图16所示，说明如下：
（1）心电采集客户端（MIEC）向TCP的IOCPMODEL模块发送接入邀请；
（2）IOCPMODEL模块查找RoomMgr(房间列表)该（MIEC）采集端是否创建直播间；
（3）当没查找到房间，IOCPMODEL模块向RoomMgr(房间列表)创建直播间记录；
（4）创建直播间ROOM；
（5）IOCPMODEL模块为创建的直播间分配ROOM ID；
（6）当查找到房间则IOCPMODEL模块分配现有的ROOM ID；
（7）采集客户端（MIEC）向IOCPMODEL模块发送数据；
（8）IOCPMODEL模块在RoomMgr(房间列表)查找到直播间信息；
（9）IOCPMODEL模块将从采集客户端（MIEC）接收到的数据发送给直播间，直播间即可查看到心电图数据。
3）心电会诊连接
流程如图17所示，说明如下：
（1）会诊客户端（MIED）向心电服务器（MIESERVER）发送会话请求；
（2）经系统鉴权成功后，心电服务器（MIESERVER）将会诊客户端（MIED）加入选择的直播间；
（3）心电服务器（MIESERVER）向会诊客户端（MIED）返回成功消息；
（4）心电服务器（MIESERVER）向会诊客户端（MIED）发送数据，使会诊客户端（MIED）能看见采集客户端发来的心电数据；
（5）会诊客户端（MIED）向心电服务器（MIESERVER）发送接收数据响应；
（6）会诊客户端（MIED）向心电服务器（MIESERVER）发送链接终止命令；
（7）心电服务器（MIESERVER）通知直播间会诊客户端（MIED）退出；
（8）心电服务器（MIESERVER）向会诊客户端（MIED）终止连接的应答。
4）心电会诊接收
流程图18所示，说明如下：
（1）会诊客户端（MIED）向TCP的IOCPMODEL模块发送接入邀请；
（2）IOCPMODEL模块在RoomMgr查找房间；
（3）加入房间；
（4）房间发送心电数据给IOCPMODEL模块；
（5）IOCPMODEL模块将数据发送给会诊客户端（MIED）；
（6）ROOM模块发送终止连接，通知至IOCPMODEL模块；
（7）IOCPMODEL模块将终止连接发送至会诊客户端（MIED），数据接收终止。
四、移动心电采集及诊断系统的设计
本发明设计的移动心电采集及诊断系统，包括：移动心电采集工作站、心电数据传输与控制模块、心电数据库、心电信息管理系统、医生心电会诊工作站，通过心电采集事件触发集成整个业务过程，并将相关业务数据（如心电图、诊断报告等）存储至数据库。
所述移动心电采集工作站（MIEC），使用心电采集设备和平板电脑等，通过心电采集系统，主要为养老院、社区服务中心等采集心电图，以及救护车现场急救人员采集心电图使用，可进行病人信息添加、心电采集、存储，并可将信息数据发送到心电数据库、心电信息管理系统、医生心电会诊工作站，还可查询病人相关信息及历史记录（如心电图、急救记录等信息）。
该移动心电采集工作站还可提供刷医保卡，通过接口调用HIS系统获取病人的基本资料，如无法刷医保卡，可在系统中手动输入病人基本资料，既往病史等信息；通过心电采集盒采集心电数据，在移动设备上显示12导心电图信号。
所述心电数据传输与控制模块（MIESERVER），用于移动心电采集工作站、医生心电会诊工作站之间的数据传输。该模块主要使用SIP协议，用来传输移动心电采集工作站、心电会诊工作站的数据传输与控制，确保各个系统之间信息数据的传递，另外该模块还负责将采集的心电数据存储至数据库。该模块有以下几个子模块分别是：IOCPModel，RoomMgr、Room模块。IOCP（I/O Completion Port），常称I/O完成端口。 IOCP模型属于一种通讯模型，适用于(能控制并发执行的)高负载服务器的一个技术。用于高效处理很多很多的客户端进行数据交换的一个模型。或能异步I/O操作的模型。RoomMgr即房间列表，用于存放已建立的房间列表。ROOM即房间，该模块用于接收、查看心电图心电直播间。
所述心电数据库，用于存储病人基本信息、心电图数据、诊断报告、图片等等信息，并为移动心电采集工作站和医生心电会诊工作站提供数据对接，还有为心电信息管理系统提供统计、查询功能。
所述医生心电会诊工作站(MIED)，用于接收来自各移动心电采集工作站采集的心电采集信息，提供院内医生查看心电图信息，进行诊断，包括做出相应的测量、会诊，撰写诊断结论等；并将相关数据（包括诊断结论等）存储至心电数据库。可以通过电脑、平板、手机进行相关操作。
所述心电信息管理系统，提供对医院、医生、病人的人员信息管理，具有系统使用权限、心电图查看、会诊、撰写诊断报告、统计分析报表、历史记录查询及诊断报告打印等功能。可提供WEB服务，供全院相关医生浏览各种心电检查报告，实现远程会诊等。
系统部署结构如图19所示。
可以在急救中心/社区服务中心部署移动心电采集工作站，在医院部署心电会诊工作站，在云平台，实现数据的传输。心电图数据通过移动网络将心电图数据传送至心电数据传输与控制模块，心电数据传输与控制模块将获取的数据写至数据库，并根据选择将数据发送到选择的的医院，在医院内部医生登录心电会诊工作站，选择直播间进入即实时查看到病人的心电图信息，医生能对该心电图信息及时作出诊断意见。另外在心电采集工作站可以查看历史的诊断信息等。
本发明提供的移动心电采集及诊断系统，其集成流程见图20所示，具体如下：
（1）移动设备（平板、手机）通过蓝牙或者USB的方式与心电采集设备连接，使用移动心电采集工作站采集心电图。
（2）移动设备（平板）通过USB的方式与（采集盒，统一用心电采集设备）心电采集设备连接，采集心电图采用数字采集接口，从（采集盒）心电采集设备中获取心电数据。
注：蓝牙（采集盒）心电采集设备每次传输出来的数组总共18个元素，经过算法解析后转换成绘图所需要的16个元素。
（3）实时显示心电采集设备采集来的心电数据；
系统通过读取、解析采集来的数据，在移动设备上装有心电采集工作站中可实时查看心电图，并可实现3*4导联、12*1导联、2*6导联、2*6+1导联、3*4+2导联、1导联、60秒导联图形切换显示。系统可选择将心电数据发送至哪一家医院，由该医院给出心电诊断。
（4）心电数据传输
心电数据传输使用SIP协议传输数据，提供SIP注册、直接传输、代理传输、重定向传输、重定向代理传输几种传输模式；
心电采集工作站通过传输模块将采集的心电数据写入数组，当满足一定数量后（可配置16的倍数）通过SIP协议将数据发送至服务器；
心电采集工作站通过传输模块将采集的心电数据写入数组，当达到指定数据大小后，将采集的数据通过SIP协议传输至服务器。
数据发送的过程，设置连接地址，指定的端口号。将连接信息发送给服务器，其包含消息头（包含消息总长度，命令或响应类型，命令执行状态），消息主体（包括姓名，年龄，性别）。服务器验证正确性，进行连接。连接成功后，采集端的设备开始获取蓝牙采集盒发送过来的数组，调用绘图工具进行波形图的绘制，在页面显示波形。与此同时为保证数据的正确性和及时性，将每次采集的16个元素装载到定制好的容器数组当中。当容器装满时，进行处理，添加消息头，而消息的主体就是此容器中的数据。最后通过SIP传输协议将数据发送到服务器。
（5）服务器SIP协议模块接收移动心电采集工作站SIP模块传输的心电数据；
服务器SIP模块接收移动心电工作站传输过来的心电数据，主要分为两类：请求消息和响应消息。其中向心电会诊工作站发送请求，向移动心电工作站发送响应消息。
（6）服务器对接收的心电图数据进行解析；
服务器对接收的心电图数据拆包并进行解析。
（7）服务器SIP模块将接收的心电图数据转发给心电会诊工作站并将数据存储至数据库；
服务器对拆包解析的心电图数据同步存储至数据库，另外当使用心电会诊工作站时服务器会通过其SIP模块将数据发送至心电会诊工作站。
（8）心电会诊工作站SIP模块通过SIP协议接收服务器发送的数据；
医生选择需要查看的直播间即心电会诊工作站SIP模块开始接收心电数据。
数据接收的过程需要设置连接地址和指定的端口号。将信息发送给服务器，其包含消息头（包含消息总长度，命令或响应类型，命令执行状态），消息主体（用户登陆ID、消息类型、消息长度、消息内容（直播间编号）等信息）。服务器接收消息后验证正确性，验证成功后再发送连接响应。会诊端接收连接响应后判断消息头部，如果该消息是连接消息，则连接成功，否则，连接失败，下次重新连接。连接成功后，会诊端的设备开始接收心电采集工作站发送过来的数据，调用绘图工具进行波形图的绘制，在页面显示波形。为保证数据的正确性和及时性，会诊端每次接收数据后判断消息头部，如果该消息为数据消息，则接收它，否则重新接收。接收的缓冲区大小也设置为16（8个导联，每个2字节）的倍数，一般为1600（系统可配置），从而确保每组数据的完整。
（9）心电会诊工作站实时显示移动心电采集的心电图，医生可以通过软件进行查看、测量、诊断操作。
心电会诊工作站实时显示移动心电采集的心电图，医生可以通过软件进行查看、测量、诊断操作。
本发明为心电采集工作站和医生心电诊断工作站之间进行异步集成，具备以下特点：
（1）具有良好的信息数据接口
可通过“数据接口”无缝连接到相关的系统，实现多系统之间的数据交换，融合医院信息资源，消除信息孤岛，支撑医院构架网络化的医院信息管理体系。
（2）实现心电图的信息化管理，优化急救中心与医院拯救工作流程
心电信息综合管理系统已日益完善成熟，借助信息技术（IT）的强大功能实现心电信息的数字化存档、高速网络通讯、病历及报告相关数据库检索、管理等，真正实现有病历、有据可查的管理模式，通过与HIS融合，可实现心电图资源共享。此外，还可实现工作流程优化，改变和完善医院的管理水平，优化人员结构。
（3）电子档案全程控制管理
从建立基本信息到各种心电图报告输出，涉及数据信息与业务流程全程系统管理，规避第三方软件对数据信息的加工处理，分检、辅助设备检查、由系统驱动岗位责任人通过系统采集与处理，保证数据资料的真实性、可靠性和安全性。
（4）检查与诊断分开
可由临床医生即可进行心电检查，心电医生诊断，充分发挥网络、信息化的特点。
（5）操作界面简便实用
系统交互流程遵从医生日常工作习惯，安装及使用简单易懂，界面美观，减少业务处理录入工作量。
（6）应用便携
采集设备方便携带，具备抗撞击、抗震动，抗阳光直射功能，并带有触控笔，携带方便，操作简易的功能，具备GPS定位功能，能测算救护车到医院的距离以及时间。
附图说明
图1为SIP协议所属网络协议的位置。
图2为SIP逻辑实体。
图3为SIP层次关系。
图4为SIP消息分类。
图5为SIP消息格式。
图6为INVITE 事务 （三次握手），对于INVITE的成功响应，ACK不属于INVITE事务，而是单独的事务。
图7为非INVITE事务（两次握手）：对于非INVITE事务，一般不存在临时响应，对于最终响应的处理也是一样。
图8为特殊事务：ACK和CANCEL事务。
图9位SIP对话。
图10为SIP消息注册。
图11 SIP直接传输。
图12 SIP代理传输。
图13 SIP重定向传输。
图14 SIP重定向代理传输。
图15为心电数据采集时序。
图16为心电数据发送流程。
图17为心电会诊数据连接流程。
图18为心电会诊接收流程。
图19为本发明系统部署图示。
图20为系统使用流程图。
具体实施方式
产品生产线上的任何生产商均可部署此发明。
通过建设心电网络系统，在养老院/社区服务中心提供心电采集检查，当病人检测的心电图达到预警值时，或者在养老院/社区服务中心人员发生突发情况，系统提供智能向120预警。120急救中心根据预警的养老院/社区获取病人所在地址、基本信息，心电图数据等都发往120调度中心，可作为之后再救护车抢救及入院手术等电子信息，调度中心安排最近的救护车前往救护，另外在120救护车上部署心电采集工作站，急救医生可以在急救途中通过心电采集平板采集心电图数据，救护车心电采集设备与120医疗急救中心和医院之间进行心电及其他生命信息传输，建立心电信息存储服务器，并在救护车上配备心电采集工作站和平板用于心电采集与传输，在各大合作医疗机构急诊科及心内科安装心电会诊工作站。救护车上的医生在病人家中或车内采集心电图，利用3G/4G移动网络，在第一时间实时将采集心电数据传送到急救医生选择的医生工作站,如图19。
在养老院/社区服务中心/120救护车上将导联连接好后，心电采集工作站（MIEC）先与心电数据传输与控制模块（MIESERVER）建立连接，MIESERVER创建直播间并加入直播间列表，当开始采集心电时，在心电采集工作站（MIEC）可查看采集的心电图形，系统通过SIP传输协议将采集心电图数据发送给心电数据传输与控制模块（MIESERVER），当MIESERVER收到心电数据后将采集到的数据发送给直播间，医生用户使用医生心电会诊工作站(MIED)进入直播间即可查看远程采集的心电图形，直到直播间关闭。同时心电数据传输与控制模块MIESERVER将采集的心电图数据写入数据库，可供会诊、查询等使用，如图20。
本发明有效解决了现有技术中存在的使用HTTP协议所带来的实时性差和带宽资源浪费严重的问题；与现有技术相比，采用本发明所述方法能达到真正快速、实时地将救护车上采集的心电图数据实时传输，实现远程心电图显示、测量、诊断的目的，同时节约了网络带宽资源。
统一定义Web服务的接口可以使得数据的传输方式更加规范，从而利于更广泛的应用。同时Web服务支持高并发性，使得大规模产业链中的事件上传效率得到保证。

Claims (13)

1.一种基于SIP传输协议的移动心电采集及诊断系统，其特征在于，包括：移动心电采集工作站、心电数据传输与控制模块、心电数据库、心电信息管理系统、医生心电会诊工作站，通过心电采集事件触发集成整个业务过程，并将相关业务数据存储至数据库；其中：
所述移动心电采集工作站，使用心电采集设备和平板电脑，通过心电采集系统，用于养老院、社区服务中心等采集心电图，以及救护车现场急救人员采集心电图，具有病人信息添加、心电采集、存储功能，并可将信息数据发送到心电数据库、心电信息管理系统、医生心电会诊工作站，还可查询病人相关信息及历史记录；
所述心电数据传输与控制模块，用于移动心电采集工作站、医生心电会诊工作站之间的数据传输；该模块主要使用SIP协议，用于移动心电采集工作站、心电会诊工作站的数据传输与控制，确保各个系统之间信息数据的传递；另外该模块还负责将采集的心电数据存储至数据库；该模块有以下几个子模块，分别是：IOCPModel、RoomMgr、Room模块；IOCPModel是一种通讯模型，用于高效处理很多的客户端进行数据交换，或能异步I/O操作；RoomMgr即房间列表，用于存放已建立的房间列表；ROOM即房间，用于接收、查看心电图心电直播间；
所述心电数据库，用于存储病人基本信息、心电图数据、诊断报告、图片，并为移动心电采集工作站和医生心电会诊工作站提供数据对接，还有为心电信息管理系统提供统计、查询功能；
所述医生心电会诊工作站，用于接收来自各移动心电采集工作站采集的心电采集信息，提供院内医生查看心电图信息，进行诊断，包括做出相应的测量、会诊，撰写诊断结论；并将相关数据包括诊断结论存储至心电数据库；
所述心电信息管理系统，用于对医院、医生、病人的人员信息管理，具有系统使用权限、心电图查看、会诊、撰写诊断报告、统计分析报表、历史记录查询及诊断报告打印功能；还提供WEB服务，供全院相关医生浏览各种心电检查报告，实现远程会诊。
2.根据权利要求1所述的移动心电采集及诊断系统，其特征在于，所述移动心电采集工作站还提供医保卡刷卡服务，通过接口调用HIS系统获取病人的基本资料；或者在系统中手动输入病人基本资料，既往病史等信息；通过心电采集盒采集心电数据，在移动设备上显示12导心电图信号。
3.根据权利要求1所述的移动心电采集及诊断系统，其特征在于，所述的移动心电采集工作站部署在养老院、社区服务中心、急救中心；所述心电会诊工作站部署在医院；在云平台，实现数据的传输，心电图数据通过移动网络将心电图数据传送至心电数据传输与控制模块，心电数据传输与控制模块将获取的数据写至数据库，并根据选择将数据发送到选择的医院，在医院内部医生登录心电会诊工作站，选择直播间进入即实时查看到病人的心电图信息，医生能对该心电图信息及时作出诊断意见；另外在心电采集工作站可以查看历史的诊断信息。
4.根据权利要求1所述的移动心电采集及诊断系统，其特征在于，集成流程具体如下：
（1）移动设备包括平板和手机，通过蓝牙或者USB的方式与心电采集设备连接，使用移动心电采集工作站采集心电图；
（2）移动设备通过USB的方式与心电采集设备连接，采集心电图采用数字采集接口，从心电采集设备中获取心电数据；
（3）实时显示心电采集设备采集来的心电数据；系统通过读取、解析采集来的数据，在移动设备上装有心电采集工作站中可实时查看心电图，并可实现3*4导联、12*1导联、2*6导联、2*6+1导联、3*4+2导联、1导联、60秒导联图形切换显示；系统可选择将心电数据发送至哪一家医院，由该医院给出心电诊断；
（4）心电数据传输
心电数据传输使用SIP协议传输数据，提供SIP注册、直接传输、代理传输、重定向传输、重定向代理传输几种传输模式；
心电采集工作站通过传输模块将采集的心电数据写入数组，当满足一定数量后通过SIP协议将采集的数据通过SIP协议传输数据；
具体过程为：将连接信息发送给服务器，其包含消息头：包含消息总长度、命令或响应类型、命令执行状态，消息主体：包括姓名、年龄、性别；服务器验证正确性，进行连接，当连接成功后，采集端的设备开始获取蓝牙采集盒发送过来的数组数据，调用绘图工具进行波形图的绘制；在心电采集工作站显示波形，与此同时为保证数据的正确性和及时性，将每次采集的16个元素装载到定制好的容器数组当中，当容器装满数据时，对其进行处理，添加消息头，消息的主体就是此容器中的数据，最后通过SIP传输协议将数据发送到服务器；
（5）服务器SIP协议模块接收移动心电采集工作站SIP模块传输的心电数据
服务器SIP模块接收移动心电工作站传输过来的心电数据，主要分为两类：请求消息和响应消息，其中向心电会诊工作站发送请求，向移动心电工作站发送响应消息；
（6）服务器对接收的心电图数据进行解析
服务器对接收的心电图数据拆包并进行解析；
（7）服务器SIP模块将接收的心电图数据转发给心电会诊工作站并将数据存储至数据库
服务器对拆包解析的心电图数据同步存储至数据库，另外当使用心电会诊工作站时服务器通过其SIP模块将数据发送至心电会诊工作站；
（8）心电会诊工作站SIP模块通过SIP协议接收服务器发送数据
医生选择需要查看的直播间即心电会诊工作站SIP模块开始接收心电数据；
数据接收的过程需要设置连接地址和指定的端口号：将信息发送给服务器，其包含：消息头：包含消息总长度、命令或响应类型、命令执行状态，消息主体：用户登陆ID、消息类型、消息长度、消息内容；服务器接收消息后验证正确性，验证成功后再发送连接响应；会诊端接收连接响应后判断消息头部，如果该消息是连接消息，则连接成功，否则，连接失败，下次重新连接；连接成功后，会诊端的设备开始接收心电采集工作站发送过来的数据，调用绘图工具进行波形图的绘制，在页面显示波形；为保证数据的正确性和及时性，会诊端每次接收数据后判断消息头部，如果该消息为数据消息，则接收它，否则重新接收；
（9）心电会诊工作站实时显示移动心电采集的心电图，医生通过软件进行查看、测量、诊断操作。
5.根据权利要求1-4之一所述的移动心电采集及诊断系统，其特征在于，所述心电采集的流程为：
（1）采集客户端（MIEC）向心电服务器（MIESERVER）发送邀请；
（2）心电服务器（MIESERVER）创建直播间；
（3）心电服务器（MIESERVER）返回成功消息给心电采集客户端（MIEC）；
（4）采集客户端（MIEC）发送心电数据给心电服务器（MIESERVER）；
（5）心电服务器（MIESERVER）将数据转发至直播间；
（6）心电服务器（MIESERVER）向心电采集客户端（MIEC）发送接收到数据响应；
（7）采集客户端（MIEC）向心电服务器（MIESERVER）发送链接终止命令；
（8）心电服务器（MIESERVER）通知直播间心电采集客户端（MIEC）退出；
（9）心电服务器（MIESERVER）向心电采集客户端（MIEC）终止连接的应答。
6.根据权利要求1-4之一所述的移动心电采集及诊断系统，其特征在于，所述心电采集发送的流程为：
（1）心电采集客户端（MIEC）向TCP的IOCPMODEL模块发送接入邀请；
（2）IOCPMODEL模块查找RoomMgr(房间列表)该（MIEC）采集端是否创建直播间；
（3）当没查找到房间，IOCPMODEL模块向RoomMgr(房间列表)创建直播间记录；
（4）创建直播间ROOM；
（5）IOCPMODEL模块为创建的直播间分配ROOM ID；
（6）当查找到房间则IOCPMODEL模块分配现有的ROOM ID；
（7）采集客户端（MIEC）向IOCPMODEL模块发送数据；
（8）IOCPMODEL模块在RoomMgr(房间列表)查找到直播间信息；
（9）IOCPMODEL模块将从采集客户端（MIEC）接收到的数据发送给直播间，直播间即可查看到心电图数据。
7.根据权利要求1-4之一所述的移动心电采集及诊断系统，其特征在于，心电会诊连接的流程为：
（1）会诊客户端（MIED）向心电服务器（MIESERVER）发送会话请求；
（2）经系统鉴权成功后，心电服务器（MIESERVER）将会诊客户端（MIED）加入选择的直播间；
（3）心电服务器（MIESERVER）向会诊客户端（MIED）返回成功消息；
（4）心电服务器（MIESERVER）向会诊客户端（MIED）发送数据，使会诊客户端（MIED）能看见采集客户端发来的心电数据；
（5）会诊客户端（MIED）向心电服务器（MIESERVER）发送接收数据响应；
（6）会诊客户端（MIED）向心电服务器（MIESERVER）发送链接终止命令；
（7）心电服务器（MIESERVER）通知直播间会诊客户端（MIED）退出；
（8）心电服务器（MIESERVER）向会诊客户端（MIED）终止连接的应答。
8.根据权利要求1-4之一所述的移动心电采集及诊断系统，其特征在于，心电会诊接收流程为：
（1）会诊客户端（MIED）向TCP的IOCPMODEL模块发送接入邀请；
（2）IOCPMODEL模块在RoomMgr查找房间；
（3）加入房间；
（4）房间发送心电数据给IOCPMODEL模块；
（5）IOCPMODEL模块将数据发送给会诊客户端（MIED）；
（6）ROOM模块发送终止连接，通知至IOCPMODEL模块；
（7）IOCPMODEL模块将终止连接发送至会诊客户端（MIED），数据接收终止。
9.根据权利要求4所述的移动心电采集及诊断系统，其特征在于，所述的SIP消息注册，是当用户每次开机时，要向服务器注册，当SIP Client的地址发生改变时需要重新注册，注册信息必须定期刷新，通常Register将注册信息保存到Location Server中，作用是将AOR地址绑定到某个Contact地址上，便于Proxy在呼叫时查找被叫的地址；具体流程为：
（1）用户代理客户端（UAC）向用户代理服务器（UAS）发起注册请求；
（2）用户代理服务器（UAS）向用户代理客户端（UAC）返回401，即该用户无权限；
（3）户代理客户端（UAC）授权，再次向用户代理服务器（UAS）发起注册请求；
（4）用户代理服务器（UAS）注册成功向用户代理服务器（UAC）返回200 OK消息。
10.根据权利要求4所述的移动心电采集及诊断系统，其特征在于，所述的直接传输，是当主叫用户代理客户端（UAC）知道被叫的当前的位置时，通过INVITE消息直接向被叫用户代理服务器（UAS）发出呼叫请求；具体流程为：
（1）用户代理客户端（UAC）向用户代理服务器（UAS）发起INVITE请求；
（2）用户代理服务器（UAS）向用户代理客户端（UAC）返回100，即表示已经接收到请求消息，正在对其进行处理；
（3）用户代理服务器（UAS）向用户代理客户端（UAC）返回200 OK消息；
（4）用户代理客户端（UAC）向用户代理服务器（UAS）返回ACK消息；
（5）用户代理客户端（UAC）和用户代理服务器（UAS）之间数据传输。
11.根据权利要求4所述的移动心电采集及诊断系统，其特征在于，所述的代理传输，是
用户客户端向服务器端进行注册前，所述服务器端根据各服务器运行情况，分配负荷最小的一个可用SIP注册服务器给所述用户客户端；
当主叫用户代理客户端（UAC）不知道被叫的当前的位置时，UAC通过网络中间的服务器设备的转发，最终到达UAS；即用户代理客户端（UAC）可以向代理服务器（Proxy Server）发起INVITE请求，再由代理服务器（Proxy Server）向用户代理服务器（UAS）发出呼叫请求；
具体流程为：
（1）用户代理客户端（UAC）向代理服务器（Proxy Server）发起INVITE请求；
（2）代理服务器（Proxy Server）向用户代理客户端（UAC）返回100，即表示已经接收到请求消息，正在对其进行处理；
（3）代理服务器（Proxy Server）向用户代理服务器（UAS）发起INVITE请求；
（4）用户代理服务器（UAS）向代理服务器（Proxy Server）返回200 OK消息；
（5）代理服务器（Proxy Server）向用户代理客户端（UAC）返回200 OK消息；
（6）用户代理客户端（UAC）向代理服务器（Proxy Server）返回ACK消息；
（7）代理服务器（Proxy Server）向用户代理服务器（UAS）返回ACK消息；
（8）用户代理客户端（UAC）、代理服务器（Proxy Server）、用户代理服务器（UAS）之间数据传输。
12.根据权利要求4所述的移动心电采集及诊断系统，其特征在于，所述的重定向传输，具体流程为：
（1）用户代理客户端（UAC）向重定向服务器（RedirectServer）发起INVITE请求；
（2）重定向服务器（RedirectServer）向用户代理客户端（UAC）返回301，即表示永久迁移；
（3）用户代理客户端（UAC）向重定向服务器（RedirectServer）返回ACK消息；
（4）用户代理客户端（UAC）向用户代理服务器（UAS）发起INVITE请求；
（5）用户代理服务器（UAS）向用户代理客户端（UAC）返回200 OK消息；
（6）用户代理客户端（UAC）向用户代理服务器（UAS）返回ACK消息；
（7）用户代理客户端（UAC）和用户代理服务器（UAS）之间数据传输。
13.根据权利要求4所述的移动心电采集及诊断系统，其特征在于，所述的重定向代理传输的具体流程为：
（1）用户代理客户端（UAC）向重定向服务器（RedirectServer）发起INVITE请求；
（2）重定向服务器（RedirectServer）向用户代理客户端（UAC）返回302，即表示临时迁移；
（3）用户代理客户端（UAC）向重定向服务器（RedirectServer）返回ACK消息；
（4）用户代理客户端（UAC）向代理服务器（Proxy Server）发起INVITE请求；
（5）代理服务器（Proxy Server）向用户代理客户端（UAC）返回100，即表示已经接收到请求消息，正在对其进行处理；
（6）代理服务器（Proxy Server）向用户代理服务器（UAS）发起INVITE请求；
（7）用户代理服务器（UAS）向代理服务器（Proxy Server）返回200 OK消息；
（8）代理服务器（Proxy Server）向用户代理客户端（UAC）返回200 OK消息；
（9）用户代理客户端（UAC）向代理服务器（Proxy Server）返回ACK消息；
（10）用户代理客户端（UAC）、代理服务器（Proxy Server）、用户代理服务器（UAS）之间数据传输；
（11）用户代理服务器（UAS）向代理服务器（Proxy Server）发送BYE消息；
（12）代理服务器（Proxy Server）向用户代理客户端（UAC）发送BYE消息；
（13）用户代理客户端（UAC）向代理服务器（Proxy Server）返回200消息；
（14）代理服务器（Proxy Server）向用户代理客户端（UAC）返回200 OK消息。
CN201610547775.XA 2016-07-13 2016-07-13 基于sip传输协议的移动心电采集及诊断系统 Active CN106027566B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610547775.XA CN106027566B (zh) 2016-07-13 2016-07-13 基于sip传输协议的移动心电采集及诊断系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610547775.XA CN106027566B (zh) 2016-07-13 2016-07-13 基于sip传输协议的移动心电采集及诊断系统

Publications (2)

Publication Number Publication Date
CN106027566A true CN106027566A (zh) 2016-10-12
CN106027566B CN106027566B (zh) 2018-10-30

Family

ID=57109357

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610547775.XA Active CN106027566B (zh) 2016-07-13 2016-07-13 基于sip传输协议的移动心电采集及诊断系统

Country Status (1)

Country Link
CN (1) CN106027566B (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108632636A (zh) * 2018-04-13 2018-10-09 上海翼得营销策划有限公司 一种应用于医药领域的视频直播方法及系统
CN109411042A (zh) * 2018-02-24 2019-03-01 深圳市凯沃尔电子有限公司 心电信息处理方法和心电工作站
WO2019161610A1 (zh) * 2018-02-24 2019-08-29 乐普（北京）医疗器械股份有限公司 心电信息处理方法和心电工作站系统
CN113014537A (zh) * 2020-08-24 2021-06-22 深圳市欧博科技有限公司 一种利用会话协议实现公共广播系统控制的方法
CN114203289A (zh) * 2021-12-13 2022-03-18 杭州佑医科技有限公司 与院内急诊系统实时通信的方法及装置

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060026288A1 (en) * 2004-07-30 2006-02-02 Arup Acharya Method and apparatus for integrating wearable devices within a SIP infrastructure
CN101815065A (zh) * 2010-01-21 2010-08-25 清华大学 基于IPv6网SIP协议的远程医疗实时信息交互方法
EP2238897A1 (fr) * 2009-04-06 2010-10-13 Sorin CRM SAS Dispositif médical actif comprenant des moyens de reconstruction d'un électrocardiogramme de surface à partir d'un électrogramme endocavitaire
US8019409B2 (en) * 2008-06-09 2011-09-13 Pacesetter, Inc. Cardiac resynchronization therapy optimization using electromechanical delay from realtime electrode motion tracking
CN102188239A (zh) * 2010-03-02 2011-09-21 上海岱嘉医学信息系统有限公司 一种适用于不同心电采集盒的采集处理方法
CN102908135A (zh) * 2012-10-08 2013-02-06 中国科学院深圳先进技术研究院 心电诊断系统及其操作方法
CN103598884A (zh) * 2013-12-03 2014-02-26 北京信息科技大学 一种基于移动平台的便携式远程心电检测系统
US20140073894A1 (en) * 2009-03-25 2014-03-13 Sorin Crm S.A.S. Non-linear filtering for the reconstruction of a surface electrocardiogram from an endocardial electrogram
CN103892823A (zh) * 2013-05-10 2014-07-02 苏州市职业大学 一种基于物联网的动态心电监护系统

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060026288A1 (en) * 2004-07-30 2006-02-02 Arup Acharya Method and apparatus for integrating wearable devices within a SIP infrastructure
US8019409B2 (en) * 2008-06-09 2011-09-13 Pacesetter, Inc. Cardiac resynchronization therapy optimization using electromechanical delay from realtime electrode motion tracking
US20140073894A1 (en) * 2009-03-25 2014-03-13 Sorin Crm S.A.S. Non-linear filtering for the reconstruction of a surface electrocardiogram from an endocardial electrogram
EP2238897A1 (fr) * 2009-04-06 2010-10-13 Sorin CRM SAS Dispositif médical actif comprenant des moyens de reconstruction d'un électrocardiogramme de surface à partir d'un électrogramme endocavitaire
CN101815065A (zh) * 2010-01-21 2010-08-25 清华大学 基于IPv6网SIP协议的远程医疗实时信息交互方法
CN102188239A (zh) * 2010-03-02 2011-09-21 上海岱嘉医学信息系统有限公司 一种适用于不同心电采集盒的采集处理方法
CN102908135A (zh) * 2012-10-08 2013-02-06 中国科学院深圳先进技术研究院 心电诊断系统及其操作方法
CN103892823A (zh) * 2013-05-10 2014-07-02 苏州市职业大学 一种基于物联网的动态心电监护系统
CN103598884A (zh) * 2013-12-03 2014-02-26 北京信息科技大学 一种基于移动平台的便携式远程心电检测系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
曾凡俊: "SIP协议及其在远程医疗系统中的应用研究", 《中国优秀硕士学位论文全文数据库 信息科技辑》 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109411042A (zh) * 2018-02-24 2019-03-01 深圳市凯沃尔电子有限公司 心电信息处理方法和心电工作站
WO2019161610A1 (zh) * 2018-02-24 2019-08-29 乐普（北京）医疗器械股份有限公司 心电信息处理方法和心电工作站系统
CN109411042B (zh) * 2018-02-24 2021-06-25 上海乐普云智科技股份有限公司 心电信息处理方法和心电工作站
EP3698709A4 (en) * 2018-02-24 2021-08-18 Shanghai Yocaly Health Management Co., Ltd. ELECTROCARDIOGRAM INFORMATION PROCESSING AND ELECTROCARDIOGRAM WORKPLACE SYSTEM
US11350868B2 (en) 2018-02-24 2022-06-07 Shanghai Lepu CloudMed Co., LTD Electrocardiogram information processing method and electrocardiogram workstation system
CN108632636A (zh) * 2018-04-13 2018-10-09 上海翼得营销策划有限公司 一种应用于医药领域的视频直播方法及系统
CN113014537A (zh) * 2020-08-24 2021-06-22 深圳市欧博科技有限公司 一种利用会话协议实现公共广播系统控制的方法
CN114203289A (zh) * 2021-12-13 2022-03-18 杭州佑医科技有限公司 与院内急诊系统实时通信的方法及装置

Also Published As

Publication number Publication date
CN106027566B (zh) 2018-10-30

Similar Documents

Publication Publication Date Title
CN106027566B (zh) 基于sip传输协议的移动心电采集及诊断系统
US10229203B2 (en) Social media bot to representational state transfer (REST) proxy for data systems
Jang-Jaccard et al. WebRTC-based video conferencing service for telehealth
US10210226B2 (en) Interactive social media access to data systems
Masek et al. Implementation of true IoT vision: survey on enabling protocols and hands-on experience
CN101815065B (zh) 基于IPv6网SIP协议的远程医疗实时信息交互方法
CN102771082B (zh) 具有混合能力的设备和接口之间的通信会话
CN100592744C (zh) 多传感器通信系统
CN104995655B (zh) 用于与联络中心基于网页实时通信的系统和方法
CN102571947B (zh) 一种代理处理数据的方法、装置和系统
CN110187983A (zh) 一种远程调用方法、装置及电子设备
US20100004950A1 (en) System and method for usage of personal medical records in mobile devices
US8503429B2 (en) Processing requests and generating responses in session initiation protocol (SIP)
CN1659847B (zh) 用于支持并行应用互操作性的系统和方法
CN105933555A (zh) 一种与呼叫中心的通信方法、系统及相关装置
CN111885252A (zh) 一种手机扩展使用方法
CN109189502A (zh) 一种基于即时通讯公众平台的消息处理方法和相关设备
CN106789566A (zh) 基于手机操作系统的不同im应用消息共享方法和系统
CN108447549A (zh) 一种协作阅览影像的方法及装置
CN103701877A (zh) 交互式远程会诊系统和交互式远程会诊方法
CN102984272A (zh) 一种远程控制移动终端通信能力的系统及其方法
JP2007013353A (ja) 文字／データ送受信システム、端末管理装置及びそれらに用いる文字／データ送受信方法並びにそのプログラム
CN102165484B (zh) 角色独立的上下文交换
Izadi et al. The FUSE platform: supporting ubiquitous collaboration within diverse mobile environments
Hsieh et al. An integrated healthcare enterprise information portal and healthcare information system framework

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant