CN104822310A - 用于提供病人护理的系统和方法 - Google Patents

Abstract

用于提供病人护理的系统包括使用手机平台以及非专用硬件和软件模块获取、合并、分发、存储和显示医疗数据。该系统包括感测设备、获取设备、网络装置、云计算和存储设备以及呈现设备。感测设备经由有线或者无线连接连接到获取设备。感测获取设备可以在护理者设施和院外环境中使用并且可以经由手机(3G/4G)网络连接到云。临床数据以仅具有使用标准脚本语言(诸如Lua)编码的首部的加密消息发送。呈现设备包括计算机、平板电脑、手机和壁挂式显示器并且可以定位在任何地方，以使得护理者对病人数据的更大可访问性成为可能。

Description

用于提供病人护理的系统和方法

技术领域

本说明书涉及医疗系统。更具体地，本说明书涉及使得现有手机网络、基于云的服务、消费者电子设备和与标准网络的连接性能够获取、合并、分析、分发、存储和显示医疗数据的用于提供病人护理的分布式病人监视系统和方法。

背景技术

通常在医院环境中使用的用于提供病人护理的标准系统包括用于获取、合并、分发、存储和显示病人医疗数据的模块。这种模块包括通常由信息网络连接的运行多个软件程序的各种硬件组件。当前可用的用于提供病人护理的系统使用专有硬件，由此限制限制用于扩展的选项并且约束系统的使用。在多数情况下，系统仅允许已经按照系统运行要求设计的特定应用。此外，由于周期性升级和更新，医院环境经常具有在它们的系统上操作的硬件和软件二者的多个版本。因此，这些系统趋于可以仅定制为有限程度的相似的封闭箱。随着技术进步，医院遭遇将新功能整合到现有系统的日益增加的困难。典型地，需要现场信息技术(IT)人员执行手动升级和排错。

用于提供病人护理的当前系统包括利用传统通信协议的网络，传统通信协议必须严格定义包括该协议的消息的格式、方案和编码。这些定义形成系统内的信息的传送器和信息的接收器之间的合同，并且典型以严格“比特-级”编码或者更高级编码(诸如可扩展标记语言(XML))的形式。“比特-级”编码涉及二进制级的每个消息的每个比特和字节的精确布局，并且由此严格地定义协议中的所有消息的准确格式和内容。在因特网上使用的TCP/IP协议是“比特-级”编码的示例。XML编码使用对层的协议特定方案(用以定义消息的布局的标准化格式(XML)上的必要规则)。超文本标记语言(HTML)网页标准是XML编码的示例。

这两种类型的编码要求传送器和接收器对同一协议达成一致。期望XML数据的接收器将不能依据传送器处理二进制数据，并且反之亦然。因此，在正同时更新传送器和接收器的情况下，对协议的改变和增强必须以锁定步骤进行。通常广泛部署当前系统，以使得这种同时更新不现实并且导致协议变得以很小的演进“锁定”。

此外，经由标准协议的信息的传输涉及几个转换步骤。传送器必须在将数据发送之前编码该数据并且接收器必须解码该数据以将其恢复。数据的持续编码和解码可能是复杂的并且可以显著增加开销。对潜在协议进行改变典型要求编码和解码阶段二者的重做，也导致增加的成本。

典型网络的通信协议以以下两种基本类型进行：面向连接和无连接。面向连接协议在数据交换可以发生之前要求两个通信方之间的握手过程，而无连接协议允许数据交换，而不需要前面的设置或者握手。

典型使用加密执行安全通信，并且加密的所有现存形式要求通信方具有典型以允许它们加密和解密消息的密钥的形式的共享秘密。虽然存在很多用于共享密钥的技术，所有都涉及面向连接协议的使用，以使得可以在连接的设置期间交换密钥。另外，每个个别连接必须规定唯一的秘密集合。由此，如果第一代理与100个其他代理通信，则每个个别会话涉及个别加密连接，以要求第一代理管理100个同时连接和相关联的密钥。这样，在很多代理与很多其他代理交谈的系统中，连接的总数量成指数地增加。这将增加成本并且使系统变慢。

为了克服这一点，很多系统使用路由代理之间的通信的单个中心“交换”。然后连接的总数量等于代理的数量，这是因为每个代理仅需要连接到共享的中心交换。然而，除非信任交换，代理必须仍保持对于每对通信代理的个别密钥对。由此，代理必须仍“连接”到交换密钥。

在传送器和接收器之间发送的消息将从不重要到关键在重要性和优先级方面变化。因为一般极难或者不能保证给定消息的递送，接收器向数据的发送者确认回执经常是有用的。因为这个回执生成消耗网络带宽(对于每个接收到的消息由接收器生成至少一个新消息)，所以经常对于最高重要性的消息保留。

如同消息编码，传统通信协议形成传送器和接收器之间的合同，并且必须依赖于对于接收器生成并且发送递送回执的规范严格定义的规则。典型地，协议将规定必须被解码以确定是否要生成回执消息的一个字段或者一系列字段。附加字段定义回执消息的格式和发送者的网络地址。为了传统网络系统有效地保证回执生成，网络上的所有代理必须运行兼容的协议版本，以使得消息回执请求、格式描述符和地址指定都以兼容格式。

此外，传统消息回执生成相当有限制性，这是因为由以接收器软件栈编码的功能确定回复回执的格式。如果复杂序列的动作期望消息的具体种类的回执，则必须以每个网络代理的软件栈编码。

例如，一类关键消息要求不仅标准回执被生成(被回复发送者的消息)，而且辅助消息回执通知被发送到数据登录服务器(其跟踪所有高优先级消息回执)。在传统系统中，这个行为将不得不建立为消息协议，以使得附加可选数据字段(辅助回执通知启用、辅助通知服务器的地址，在辅助服务器不可用的情况下的规定的行为等)将用于实现。这是对难于以传统协议编码的消息回执的复杂响应。效果是增长所有消息的大小并且使得协议逐步地更复杂、更慢并且难于使用和维护。

利用以这个方式以协议编码的每个新行为，所有网络代理上的网络软件栈增长复杂性和存储器消耗，并且变得效率更低。此外，不能使用这种特征，直至所有网络代理正在运行支持该特征的兼容的协议版本为止。

当发送消息时，典型网络也依赖于多种协议以确定数据分组的最佳路由。这些协议使用静态成本度量确定端点之间的最佳路径。大多数基于Dijkstra算法、解决具有非负边缘路径成本的图形的单个源最短路径问题，以确定两个顶点之间的最短路径的图形搜索算法。每个链路被分配基于通常是可用带宽的特定属性的成本。

路由协议开放最短路径优先(OSPF)是路由确定协议的普通示例。虽然其他属性可用，但是OSPF通常配置为向每个可用网络链路分配成本10^∧8/带宽。100M比特/s带宽的链路将具有成本1并且10M比特/s的链路将具有成本10。在选择两个网络之间的路径时，OSPF将选取具有最低成本的路径。

生成树协议(STP)，链路层协议，也使用默认成本表基于可用接口带宽来选择用于网络的最佳路径。对于STP，10M比特/s被给定成本100，而100M比特/s被给定成本19。在最低成本路径被选取用于该网络上的通信的情况下，每个路径上的所有链路的总和被用以确定路径成本。

在这些协议中，根据对于每个接口的协商链路速度确定路径成本。然而，可能由网络拥塞、分组损失和队列延迟实时影响实际传输速度。这些属性动态地改变并且当使用静态成本度量计算最优路径时不被考虑。

典型网络使用用以从一个或者很多传送器向很多其他接收器传递数据的各种协议。从一个或者很多发送者同时向多个接收者传递数据被称为多播。与协议无关的多播(PIM)是不包括它们自己的拓扑发现机制但使用由其他协议提供的路由信息的协议的组。因特网组管理拓扑(IGMP)由网络上的主机和路由器使用，以建立多播组成员资格。当使用IGMP在典型网络上操作时，无论设备何时漫游，该设备必须与主机或者路由器重新同步状态或者重新建立连接。在漫游期间跨越路由器保持状态要求系统在多个请求期间保持设备的会话信息或者状态。这使系统慢下来并且增加附加存储器存储设备的需要。

很多典型网络中传递消息的传送器和接收器是移动电话。这些设备经常具有有限的数据传输的功率预算。它们一般由电池供电，并且无线电传输(蓝牙、802-11无线、3G、4G、LTE等)使用大百分比的电池中的可用功率和总能量不少见。在设备正在连续发送数据(如用作医疗监视系统的移动设备中可能见到)的情况下，这个问题特别尖锐。

当复制消息由传送器发送时出现当通过移动网络多播时遇到的另一问题。当使用射频(RF)传输发送消息时，如上面描述，系统由可用带宽量和移动设备的电池功率限制它们可以传递的数据量。要求用于RF互连的更多带宽与系统的总体成本的增长相关联。复制消息发送不仅消耗更多的带宽而且导致移动设备上的不必要的电池耗尽。

当警报时，用于提供病人护理的传统系统典型配置为首先在与病人连接的设备处通告警报。由与病人连接的设备生成的警报经常被复制并且显示在诸如中心工作站处的物理设备。中心工作站是典型由观察多个病人的状态的单个护理者使用的大型显示器。此外，移动警报设备可以在护理者关于病房(unit)移动时由他们佩戴。这些设备能够通知看护者他们的病人之一是否有警报事件。

这些警报方法全都提供对典型遵循以下的路径的警报条件的编程响应：1)在连接到病人的设备处警报；2)在中心或者远程显示器处警报；3)向护理者通知警报；以及4)如果护理者不响应，则基于预定义的逐步升级通知另一护理者，直至护理者响应为止。虽然有效，但是传统警报放案不考虑可能导致警报响应的延迟的病人或者最近的护理者的物理位置。

警报疲劳是使用传统病人护理系统的护理者遇到的另一问题。当病人监视器检测到对于其将创建警报的条件时，将创建对于护理者的通知，诸如很大的可听重复音调、设备或者显示器上的闪烁警报、描述警报的文本消息等。在护理者在位移期间响应用于多个不同病人的多个警报之后，护理者可能变得对警报音调不敏感。如果重要的警报被护理者忽略或者不适当地禁用，这能够导致病人伤害。现有病人监视系统试图通过在特定情况期间使得护理者能够使警报“消音”，最小化警报疲劳。使警报消音不将警报关断，而是将典型地关断音频警报音调一段时间，所以护理者在看护病人的同时不被分心。

“警报消音”是在可选时间段内关断音频警报的消音的形式。“警报确认”(正在进行警报)在警报情况的持续时间期间减小警报通知的强度。如果在任何时间，警报条件消失，则“警报确认”状态清除并且相同类型的新警报将使得最高警报(full alarm)再次出现。例如，对于诸如房颤(其不仅典型威胁生命并且可能在长期时间段内继续)的警报条件，警报确认行为可以为停止闪烁并且停止可听警报，但仍指示警报正伴随指示护理者已经确认警报条件的图标在参数区中出现。该状态将持续，直至警报被重置为止或者直至条件被解决为止。如果病人在至少最短规定时间段内不房颤并且然后再次房颤，则适用于房颤的最高警报再次启动。

“警报确认”(锁定警报)用于足够重要的警报情况：如果它们出现，则必须通知护理者。如果锁定警报出现，则病人监视器将甚至在警报条件不再呈现之后继续警报，直至护理者“确认”已经注意到该警报为止。一旦确认，则警报将在条件不再出现的情况下关断。虽然这些警报消音方案有效，但是它们可以被改进为更好地被分发并且面向护理者团队方法。

另外，当前的系统通常被固定并且一旦病人已经离开医院环境不能用以提供病人护理。一旦病人已经出院但仍需要医疗看护，这种系统不提供用于病人和他们的护理者连接到内科医师和健康护理专业人士的方法。

因此，所需要的是不限于使用专用技术的提供病人护理的灵活并且鲁棒的系统。该新系统应该足够灵活以提供几年的支持，而不需要替换基本模块。该系统也应该很少需要现场技术专家。这种系统将使用软件即服务(SaaS)原理操作，其中，病人和家庭访问在云上存储的程序和数据。云提供系统的计算和存储要求，将使用从本地存储程序和数据的胖客户机移走。云计算将减少成本并且增加系统的灵活性。

也需要这样的系统，在该系统中，以更高效和成本效益的方式处理消息编码。具体地，所需要的是简化那些编码和解码步骤并且在不需要同时升级系统组件的情况下允许增强系统的灵活编码协议。这种编码系统也将简化包括消息传输中的可执行程序，诸如递送回执程序。

此外，存在对于无连接交换的需要，该无连接交换用于在不需要双方在交换消息之前协商密钥或者其他秘密的情况下，在双方之间发送加密消息。所需要的是跨越网络的消息的无连接传输的中心、受信交换。

也需要的是当确定最快的路由时将考虑实时网络使用(诸如，拥塞、分组丢失和队列延迟)的消息路由协议。

也需要能够高效多播的系统，其中，设备可以在不需要与路由器重新同步的情况下进入漫游，以保持路由器无状态操作。这种系统将减小设备上的电池消耗，并且减轻网络上的需求。此外，也需要将通过复制消息发送的发生最小化带宽和移动设备电池消耗的系统。

也需要控制通过网络的消息的流动以最小化传送器中的功率消耗的方法。与在传送与多个更小的数据块相同的字节的情况下相比，当无线设备传送特定数量的字节的单个数据块时，无线设备一般效率更高。因此，所需要的是一起在单个块中而不是作为多个更小的消息发送多个消息的方法。

需要基于病人和看护者二者的位置和呈现信息的警报优先级路。也需要考虑分布的护理者团队的用于警报消音的方法。

也需要这样的系统，在该系统中，各个硬件模块足够小并且可移动以允许跨越医院科室传递并且在出院之后在有限时间内被与病人发送回家。

存在需要这样的系统，在该系统中，各个硬件模块被配置为与不同类型的传感器接口连接以从医院环境向院外设置(outpatient setting)提供用于病人的护理。

也需要的是这样的系统，该系统通过允许病人、他们的家庭和护理者以安全和可靠的方式连接来提供无所不在的病人预警。也存在需要这样的用于提供病人护理的系统，该系统通过将该系统适配为接收来自第三方设备的病人生理数据和从数据的分析生成的其他信息来支持第三方解决方案，由此鼓励创新。

发明内容

本发明针对用于提供病人护理的系统，包括：第一计算设备，具有第一易失性或者非易失性计算机可读介质，不包括用于传送波的传输介质，其中，所述第一介质包括：第一多个程序化指令，其中，当由所述第一计算设备执行时，所述第一多个程序化指令：使用标准脚本语言加密可执行程序并且将所述加密的程序附连至消息的首部；以及，经由无线连接从第一计算设备向第二计算设备传送所述消息；第二计算设备，具有第二易失性或者非易失性计算机可读介质，不包括用于传送波的传输介质，其中，所述第二介质包括：第二多个程序化指令，其中，当由第二计算设备执行时，所述第二多个程序化指令：从所述第一计算设备接收所述消息；依据所述消息确定意图接收所述消息的至少一个目标计算设备；以及经由无线连接从所述第二计算设备向所述至少一个目标计算设备传送所述消息；以及，至少一个目标计算设备，具有第三易失性或者非易失性计算机可读介质，不包括用于传送波的传输介质，其中，所述第三介质包括：第三多个程序化指令，其中，当由第三计算设备执行时，所述第三多个程序化指令：从所述第二计算设备接收所述消息；解密所述可执行程序；以及，执行所述可执行程序并且由此接收所述消息；其中，所述第二计算设备包括基于云的计算设备。

本说明书针对用于提供病人护理的系统，包括：至少一个感测设备，配置为检测并且报告病人的至少一个生理参数；至少一个获取设备，耦合到所述至少一个感测设备，其中，所述获取设备从所述至少一个感测设备接收电子病人数据，并且包括能够存储所述病人数据的存储器；至少一个网络装置，耦合至所述至少一个获取设备，其中，所述网络装置配置为从所述获取设备接收所述病人数据；网络，用于提供云计算，其中，所述至少一个网络装置耦合到所述网络，并且其中，所述网络包括用于存储所述病人数据的数据库，以使得所述病人数据可跨越所有网络设备访问；以及至少一个呈现设备，耦合到所述网络，其中，所述呈现设备配置为访问所述病人数据并且在图形用户界面上显示所述病人数据，其中，跨越所述网络的所述电子病人数据的传输包括通过使用标准脚本语言编码可执行程序并且将所述程序附连至包括所述病人数据的消息来加密所述病人数据。

在一个实施例中，网络装置定位接近病人。在另一个实施例中，网络装置定位远离病人。

在一个实施例中，感测设备经由有线连接耦合到所述至少一个获取设备。在另一个实施例中，感测设备经由无线连接耦合到所述至少一个获取设备。

在一个实施例中，所述至少一个感测设备和所述至少一个获取设备可以经由3G/4G连接连接到网络。

在一个实施例中，所述脚本语言是Lua。

在一个实施例中，呈现设备包括传统PC、平板电脑、智能电话或者壁挂式显示器中的任一个。

在一个实施例中，获取设备也用作呈现设备。

在一个实施例中，获取设备复制并且在所述存储器上存储所述病人的临床数据，并且在系统故障时用作独立监视器。

在一个实施例中，获取设备是护理者设施处的固定设备。在另一个实施例中，获取设备是一旦出院并且为了院外护理与所述病人留在一起的移动设备。

在一个实施例中，用于提供病人护理的系统还包括通过在实际使用期间直接测量当前网络性能，计算最有效的消息路由的基于成本的路由算法。

在一个实施例中，用于提供病人护理的系统还包括基于所述病人和护理者二者的位置和呈现信息路由警报优先级的警报路由协议。在一个实施例中，护理者可以消音或者在音量上减小分配给所述病人的所有设备的可听警报。

在一个实施例中，用于提供病人护理的系统还包括建立交换和每个消息传送器和接收器之间的每个设备一个的加密链路的中心受信消息交换。在一个实施例中，中心消息交换群集要周期性发送的非紧急消息。在一个实施例中，消息传送器配置为每个消息仅发送一次，并且所述中心消息交换配置为基于所述消息的首部中包括的订阅列表复制每个消息并且发送每个消息给多个接收者。

本说明书也公开用于提供病人护理的方法，该方法包括以下步骤：提供病人护理系统，该病人护理系统包括：至少一个感测设备，配置为检测并且报告病人的至少一个生理参数；至少一个获取设备，耦合到所述至少一个感测设备，其中，所述获取设备从所述至少一个感测设备接收电子病人数据，并且包括能够存储所述病人数据的存储器；至少一个网络装置，耦合至所述至少一个获取设备，其中，所述网络装置配置为从所述获取设备接收所述病人数据；网络，用于提供云计算，其中，所述至少一个网络装置耦合到所述网络，并且其中，所述网络包括用于存储所述病人数据的数据库，以使得所述病人数据可跨越所有网络设备访问；以及至少一个呈现设备，耦合到所述网络，其中，所述呈现设备配置为访问所述病人数据并且在图形用户界面上显示所述病人数据，使用所述至少一个感测设备检测并且报告所述至少一个病人生理参数；向所述获取设备传送表示所述至少一个生理参数的电子数据；通过使用标准脚本语言编码可执行程序并且将所述程序附连至包括所述病人数据的消息来加密所述病人数据；向所述网络装置传送所述加密数据；使用云计算在所述网络上存储所述数据；使用所述呈现设备访问、解密和显示所述数据。

将在附图和下面提供的详细描述中更深入地描述本发明的前述和其实施例。

附图说明

本发明的这些和其他特征和优点将进一步被认识到，因为它们当结合附图被考虑时通过参考详细的描述将变得更好理解，在附图中：

图1A是图示本说明书的医疗数据信息系统的工作流的一个实施例的图；

图1B图示医院的重症监护室(ICU)的本发明的示例性使用场景；

图1C图示医院的普通病房中的本说明书的系统的示例性使用场景；

图1D图示在“家”场景中的本说明书的系统的示例性使用场景；

图2是图示本说明书的医疗数据信息系统的一个实施例的示例性物理拓扑的框图；

图3是图示系统门户应用的一个实施例的软件架构的框图；

图4是图示涉及初始化本说明书的医疗数据信息系统中的获取设备的步骤的流程图；

图5是图示涉及两个应用之间的示例性信息交换的步骤的一个实施例的流程图；以及

图6是图示依据本说明书的医疗数据信息系统的一对应用的消息的流的一个实施例的流程图

具体实施方式

本说明书针对通过使用手机平台以及非专用硬件和软件模块获取、合并、分发、存储和显示医疗数据的用于提供病人护理的系统。在一个实施例中，本说明书的系统使用以下来实现：两个或者更多计算机或者计算设备，其中，计算机或者计算设备执行至少一个多个编程指令；在所述计算设备之间传递数据的部件；以及设计为便于所述计算设备之间的数据的传递的至少一个协议。

此外，本领域的技术人员将认识到，本申请中描述的特征可以操作在任何计算平台上，包括但不限于：膝上型计算机或者平板计算机；个人计算机；个人数字助理；手机；服务器；嵌入式处理器；数字信号处理器(DSP)芯片或者能够执行编程指令或者代码的专用成像设备。

还应该认识到，该平台通过使用一个或者多个处理器执行存储在一个或者多个非易失性存储器中的多个编程指令提供本申请中描述的功能，并且在与一个或者多个有线或者无线网络数据通信时呈现和/或通过收发器接收数据。

应该进一步认识到，每个设备具有无线和/或有线接收器和能够发送和传送数据的传送器，能够处理编程指令的至少一个处理器、能够存储编程指令的存储器和包括用于执行这里描述的处理的多个编程指令的软件。此外，编程代码可以被汇编(预编汇编或者适时(“just-in-time”)汇编)为在单个计算机上操作的单个应用或者本地或者相互远程操作的几个不同计算机之中分发。

本说明书的系统提供从病人收集生理数据的一个或者多个感测设备，并且将感测到的数据传送到然后将该数据发送到互联系统的组件的云的获取设备。云将数据合并，然后将该数据分发到一个或者多个显示器或者呈现设备。

系统使得第三方能够改革并且开发应用，由此快速利用新技术。另外，本系统容易安装、排错和服务，并且不需要特定硬件、联网或者IT员工。此外，系统能够在非鲁棒网络基础设施上工作，并且具有以后退“安全”模式操作的能力。另外，用于提供病人护理的系统包括病人监视模块，该病人监视模块可以附连到病人并且一旦从医院出院可以由病人携带并且用于院外护理。

在一个实施例中，系统使用通信协议，其中当发送消息时，传送器包括以工业标准脚本语言编写的小型计算机程序。当接收器接收到消息时，其执行该程序，以产生可使用形式的消息数据。这消除严格编码消息本身的需要，并且提供消息编码的大大增强的灵活性。在一个实施例中，脚本语言是Lua。在一个实施例中，传送器另外能够通过在所包括的程序中插入可执行递送回执代码来创建其自己的回复回执。接收器将执行代码并且一旦接收到原始消息的回执就发送递送回执。

在一个实施例中，系统包括使用基于成本的路由算法的消息交换(exchange)，基于成本的路由算法通过在实际使用期间直接测量当前网络性能使用包括的多个因素计算效率最高的消息路由。

在一个实施例中，系统通过消除传送器和接收器在消息传递之前协商密钥和其他秘密的需要，来提供用于加密消息的无连接交换。这通过提供建立交换和每个传送器和接收器之间的每个设备一个的加密链路的中心受信消息交换来完成。

在一个实施例中，系统提供用于群集要周期性而不是连续发送的非紧急消息的机制，由此节约移动设备电池功率和带宽使用。此外，系统指示意图用于多个接收者的消息仅由传送器发送一次。每个消息在其首部内包括具有所有接收者的完整的订阅列表。然后系统路由器复制消息并且将其发送到每个接收者。这也帮助减小电池消耗和整个带宽使用。

在一个实施例中，系统基于病人和护理者二者的位置和呈现信息路由警报优先级。警报在负责的护理者的位置处和病人最近的至少一个护理者或者基于警报的特定类型指定为提供最好的护理的护理者的位置处二者，发出声音。

在一个实施例中，系统允许护理者“熄灭”警报，这导致可听警报被消音或者减小分配给特定病人的所有设备的音量。

本发明针对多个实施例。提供以下公开以使得具有本领域普通知识的人能够实践本发明。本说明书使用的语言不应该解释为任何一个特定实施例的一般否定或者用以限制超出其中使用的术语的含义的权利要求。这里定义的总的原理可以应用于其它实施例和应用，而不脱离本发明的精神和范围。此外，使用的术语和措辞用于描述示例性实施例的目的并且不应该视为限制性。由此，本发明要符合包含与公开的原理和特征一致的众多替代、修改和等效的最宽范围。为了清楚的目的，与涉及本发明的技术领域中已知的技术材料有关的细节没有被详细描述，以免不必要地模糊本发明。

系统概述

图1A是图示本说明书的医疗数据信息系统的工作流100的一个实施例的图。步骤102表示经由在各种实施例中包括商用、不用定制(COTS)传感器、传统设备(仅用于输入)和第三方设备的感测设备113获取医疗数据。在各种实施例中，系统包括由一个或者多个应用提供商使得可用的多个即插即用应用。该系统包括至少一个感测设备113、至少一个获取设备112、网络设备GHC/云114和呈现/显示器设备116。在一个实施例中，该至少一个感测设备113可以经由有线或者无线连接连接至该至少一个获取设备112。感测设备113可以在院外环境下与获取设备112一起使用，并且在一个实施例中，可以经由手机(3G/4G)网络连接至云。在一个实施例中，获取设备112提供医疗信息平台，包括生态系统、应用编程接口(API)、模板等，用于使得健康护理域的任何应用、设备或者服务的开发成为可能。在一个实施例中，获取设备112支持开放源和专用产品。因为获取设备112提供为与美国健康保险流通与责任法案(HIPPA)兼容地建立，所以提供关于健康护理相关的应用的独立平台。在一个实施例中，提供多个API，以使得能够同步医疗设备以及医疗软件的开发与获取设备112。在各种实施例中，获取设备112从多个第三方生理参数输入源和诸如呼吸机、IV泵、病人参数传感设备等之类的医疗设备接收到数据。获取设备连接到网络装置GHC，网络装置GHC连接至云114。在一个实施例中，获取设备112也能够操作为呈现设备。因此，获取设备112使得系统能够用作病人监视系统并且同时利用多个第三方应用。

在一个实施例中，获取设备能够提供第二通信技术(即，诸如3G/4G之类的手机技术)，其提供警报消息给护理者。在另一实施例中，获取设备具有仅提供诸如病人id号或者床号和警报类型(心率、呼吸等)之类的关键警报信息的可视指示器(诸如，灯指示器)或者音频指示器。

在步骤104获取的数据由云114合并并且分发。在一个实施例中，云是虚拟的并且包括所有域。在其他实施例中，云共处一地并且包括一个或者多个域。云114提供用于算法运行在获取设备112上的处理力，由此充当本地网络中心(hub)。现有的基于手机的平台的使用使得利用消费者技术成为可能，由此减少独立参数合并平台的制造/开发成本。在各种实施例中，云114使得移动设备能够连接到病人并且操作为医院环境内的病人监视器。在一个实施例中，云114也使得移动设备能够由护士和内科医生使用，以监视和护理非医院环境中的病人。在另一实施例中，云114使得移动设备能够经由多个医疗应用和设备(特别是感测设备)将家庭病人连接到护理者。在另一个实施例中，云114使得移动设备能够将养老院中的亲人连接到护理者。

在各种实施例中，云114使得系统高效地操作，甚至当底层网络不能适当地起作用。另外，云114能够在任何现有网络基础设施上操作并且不需要要安装用于操作的任何特定或者专用硬件/软件。系统设计为以安全模式操作，在安全模式中，至少一个病人监视设备在网络故障的情况下可操作。在操作的安全模式中，即使中心监视不可用，至少对于病人是本地的警报将操作。在到GHC或者网络的连接不可操作的事件中，获取设备和可选的GHC能够分析和存储病人生理数据并且在病人位置处提供警报消息。该设备存储数据，并且当恢复网络操作时，数据传送到GHC云。存储的信息可以是对于警报和其他信息生成的连续病人生理信号或者消息分组。获取设备也可以适配为接收并且呈现完整的病人生理数据。

在各种实施例中，云114包括从医院或者医疗中心的每个远程存储的来自一个或者多个医院或者医疗中心的数据。在云114中存储病人数据消除与组织中安装的正规数据库管理系统相关联的处理延迟。因此，云114使得第三方顾问以及处于远程的护理者能够分析在其中存储的数据。云也使得第三方应用能够分析云114中存储的数据，以允许来自多个源的生理和其他病人数据的处理。此外，云114使得能够远程分流病人。该特征可以在军事冲突地区和灾区中以及新兴和发展的市场中找到很大用途。

在分发之后，数据在步骤106呈现在显示器设备116(在各种实施例中，包括传统PC、平板电脑、智能手机以及壁挂式显示器)上。在各种实施例中，医疗数据可以显示在系统100基础设施中可用的任何显示器设备上。该系统不限制数据显示器为专用显示器设备。该系统也允许病人数据同时呈现给位于多个位置中的多个显示器设备。

在一个实施例中，本说明书的系统提供基于多个云的服务，诸如：病人解析器、设备解析器、策略引擎、编制和管理之类。例如，病人解析器或者设备解析器服务确定在离需要医疗看护的病人最近的位置处的护理者和/或医疗专业人士。在各种实施例中，病人解析器服务包括诸如“病人编目”、“病人ID图”、“PHI管理”和“会话图”之类的特征。设备解析器服务包括诸如“设备管理”和“会话编目”之类的特征。策略引擎服务包括诸如“分发”、“安全策略”、“访问控制”和“警报逐步升级”之类的特征。编制服务包括诸如“工作流”和“数据流”之类的特征。管理服务包括诸如“域管理”、“配置”、“升级管理”之类的特征。中心仪表板使得健康护理提供者组织能够基于组织的特定策略跨越组织的所有设施配置病人解析器、设备解析器和策略引擎。中心仪表板确保所有设备符合策略并且建立用于病人的护理的统一标准。基于云的服务基于位置、接近性、可用性和技能集合提供病人警报信息到适当护理者的智能映射。

在一个实施例中，本说明书的系统提供多个网络应用，诸如：卫生系统7(HL7)网关(双向)、病人和家庭应用、护理者应用、存档和打印应用以及管理和仪表板应用之类。

在步骤102，获取设备112主动地从病人获取临床数据。此外，获取设备112在系统整个故障的事件下用作后备。包括获取设备112作为内置备用帮助降低系统成本并且最小化系统复杂性。在步骤104的云114的功能包括但不限于设备和服务发现、数据分发和存储、安全和策略控制、病人护理报告生成以及系统度量和工作流。云系统使得能够依据云(市场)许可设备、应用和特征，并且然后，当使用设备和应用时计量并且记录设备和应用的使用。示例包括附连到特定病人的参数的数目和类型，以及对于什么时间段，网络上活动的设备的数目，以及使用具体特征的次数。知晓设备、应用和特征的实际使用使得新的并且唯一的账单模型成为可能。示例可以包括特定分析的按次计费、基于由系统监视的病人的数目的可伸缩账单、基于病人的敏锐等级(即，正监视的参数的数目)的可伸缩账单。传统病人监视系统被作为重要的设备项目销售。云系统的能力将传统的重要设备购买出售为服务模块。在步骤106包括的显示器设备116提供用于临床数据、警报表达和整个病人监管的显示器。此外，在一个实施例中，每个显示器设备116包括图形用户接口(GUI)以允许护理者执行文书工作。

在一个实施例中，获取设备112位于护理者设施处和病人的家处二者，并且可扩展为适应独立硬件供应商设备和国外系统导入。在一个实施例中，网络装置GHC位于护理者设施并且可扩展为适应独立软件供应商(ISV)应用和国外系统接口。在一个实施例中，显示器设备116可以位于任何地方并且可扩展为适应ISV应用。

图1B图示在医院的重症监护室(ICU)101中的本发明的示例性使用场景。能够经由感测设备113检测多个参数的获取设备112用以测量和收集病人数据。床边监视显示器122经由以太网连接与获取设备112耦合，以显示病人的至关重要的统计。获取设备112也与多个监视器(诸如，护士的监视器124、病人的房间126之外的专用监视显示器、紧急事故指挥系统(ICS)监视器128和中心站监视器129)耦合。获取设备112和多个显示器与由本说明书提供的云114耦合。云114反过来与用于存储与病人相关的数据的数据存储平台耦合。云114使得护理者152能够经由移动显示器设备116访问病人的记录，并且也使得病人的家庭154能够在远离医院环境的位置处经由移动显示器设备116监视病人的状态。云114也使得依据随时间收集的多个生理数据的组合分析成为可能。这包括开发为系统的一部分的传感器设备和第三方传感器设备。

图1C图示医院的普通病房103中的本说明书的系统的示例性使用场景。获取设备112用作接收诸如心率(HR)、呼吸率等之类的病人的医疗数据的参数合并平台。在画出的实施例中，获取设备112也充当病人的床边监视器。获取设备112与由本说明书的系统提供的云114无线地耦合。云114反过来与用于存储与病人相关的数据的数据存储平台114耦合。此外，云114与用于显示在普通病房中住院的所有病人的至关重要的统计的监管单元136耦合。云114使得护理者152能够经由移动显示器设备116访问病人的记录并且也使得病人的家庭能够在远离医院环境的位置处经由移动显示器设备116监视病人的状态。云系统提供用于家庭访问病人护理信息并且查看病人护理历史、工作流、确认和接收对出院指令的更新以及账单查看的能力，由此潜在地减少病人护理错误。

图1D图示在“家”105场景中的本说明书的系统的示例性使用场景。诸如手机或其他、独立设备之类的移动获取设备112安装在病人的家，以用作接收诸如心率(HR)、呼吸率、血糖等之类的病人的医疗数据的参数合并平台。获取设备112也充当病人的家庭监视产品(dock)。获取设备112与由本说明书的系统提供的云114无线地耦合。云114反过来与用于存储与病人相关的数据的数据存储平台114耦合。云114也与用于基于实时显示病人的至关重要的统计的诸如护士的监视器124、ICS监视器128和中心站监视器129之类的多个监视器耦合。云114使得护理者152能够经由移动显示器设备116访问病人的记录并且监视病人的健康，并且也使得病人的家庭154能够在远离医院环境的位置处经由移动显示器设备116监视病人的状态。

系统拓扑

图2是图示本说明书的医疗数据信息系统200的一个实施例的示例性物理拓扑的框图。在一个实施例中，系统200包括用于获取病人数据的感测/获取设备212(对应于图1A的感测设备112和/或获取设备113)和用于呈现病人数据的显示器设备216(对应于图1A的显示器设备116)。在另一实施例中，系统200包括能够获取数据和呈现数据二者的设备。传统病人监视器可以用作获取设备和呈现设备二者。系统200也包括云214，云214包含负责合并和分发病人数据的多个全局健康连接器(GHC)213、215。GHC是具有附连到网络的集成软件的网络硬件装置。在一个实施例中，系统200包括与护理者设施(例如，医院220)共置(co-locate)的GHC 215和置于云214内的GHC 213二者。GHC 213和215进行连接到系统200的获取设备212和显示器设备216。在一个实施例中，获取设备212和显示器设备216经由新介质或者消息交换开关结构连接。云214连接所有GHC 213、215作为冗余可路由主干网络中的对等，并且绑定所有感测设备212和显示器设备216，以建立全局病人预警。换言之，所有病人数据由云聚集并且分发，以使得一直并且在给定适当访问的情况下，任何显示器设备可以跨越系统呈现任何病人的数据。

如图2中所示，感测设备212可以位于医院220、诊所222和病人的家224。显示器设备可以位于医院220、诊所222并且有护理者226。医院220和诊所222中的感测设备212和显示器设备216分别经由医院网络230和诊所网络232连接，并且所有设备经由因特网234通过云215互连。

在一个实施例中，感测设备被称为系统获取设备并且包括获取数据并且发布数据为系统会话格式的任何设备。这种设备包括但不限于传统固定床边监视器、小型化可佩戴设备和虚拟设备(诸如数字数据记录仪和国外系统导入)。信息的流以提供原始格式数据到系统获取设备的传感器开始。获取设备中的驱动应用处理原始格式数据为参数数据。然后参数数据由获取设备发布为系统会话格式并且上载至网络。系统会话格式是由被分发到显示器设备的由云可标识的参数数据的形式。

在一个实施例中，单个系统获取设备被分配给单个病人并且不存在由病人共享获取设备。多个传感器和参数由单个获取设备编组为对于单个病人唯一的会话。在一个实施例中，获取设备具有本地存储器，用于存储至少5天的病人数据。本地存储的数据是上载到云的数据的准确复制品并且经由复制模型发布。在一个实施例中，系统包括对等传递数据复制。使用对等模型跨越多个位置复制网络内的大部分有意义的数据库。对等模型自动地基于成本/效益启发处理传递复制和选择复制。本地存储器在整体系统故障时提供数据历史和备份。

在一个实施例中，显示器设备称为系统呈现设备并且包括显示数据和可选地包括警报的任何设备。这种设备包括但不限于传统PC、平板电脑、智能手机和壁式监视器。呈现设备基于浏览器，以支持任何地方环境下的工作。在一个实施例中，系统呈现设备包括GUI并且提供护理者工作站功能。例如，在各种实施例中，呈现设备的GUI提供警报管理和熄灭、病人管理(住院/出院)、病人/会话相关联以及回顾性数据分析功能。在一个实施例中，所有呈现设备包括具有超文本标记语言5(HTML5)的共用用户接口作为接口基础。

再次参考图2，系统云214包括全部被连接以形成系统云主干网的共置全局健康连接器(GHC)215和云GHC 213。每个共置GHC 215是被插入护理者设置、在护理者设备上被接通并且在护理者设备中使用的小型网络装置。在一个实施例中，接近200-500个床被分配给每个共置的GHC。云GHC 213确保主干网的全局到达并且在一个实施例中，接近500，000个床被分配给每个云GHC群集(8个云GHC)。系统云215托管消息交换目录。在一个实施例中，所有GHC 213、215是对等并且所有获取设备212和呈现设备216可以连接至任何GHC213、215。每个GHC 213、215合并来自获取设备212的会话数据，并且分发该数据到呈现设备216。系统云包括由账号、病人和资产组织的域编目。此外，在一个实施例中，GHC完全被复制用于真实的故障转移冗余。

在一个实施例中，系统云包括至少一个系统云域和多个系统云科室。域逻辑地隔离系统云的顶层并且不提供域间访问。域典型地对应于医院，并且可以与床的数目对应的成本从10个床缩放至超过1000个床。信息系统的所有一天又一天功能(day-to-day functions)出现在域中。域的每个用户的观点是系统的整个“世界”。换言之，每个用户是唯一的并且被隔离，并且如果给定适当访问，则可以看见在相同域内的所有其他用户。所有GHC、获取设备和呈现设备属于域。在一个实施例中，外部设备可以用在域中，但其必须被授权工作在该域。系统云域包含所有医院数据(医院数据包括但不限于所有护理者的账户、病人受保护的健康信息(PHI)、病人会话数据、资产记录、系统云科室信息)，并且预设以定义医院所需的参数设置。

每个系统云科室代表域内的分支，并且用作在工作流中帮助。每个科室典型地与医院病房对应并且在几乎对跨科室访问不限制的情况下被视为“软”分支。护理者、病人和设备所有全都具有“家”科室，以使得护理者可以快速地聚焦在他们的科室的病人。多数科室是非限制性的并且不存在系统中的强制，所以护理者可以按希望切换科室。所有设备在开机时继承由登录的护理者的科室确定的科室。在一个实施例中，确定科室被限制并且在由护理者首次访问之前需要在先授权。例如，护理者在没有首先获取授权的情况下将不能够访问精神病护理科室。每个科室附加地跟踪用于预算的账单事件。

在一个实施例，系统云另外包括用于合并用于多个域的合并账单的系统云组织。

系统安全性

本说明书的医疗数据信息系统的每个域被设计为“围墙花园”。每个域将包括严格限制的访问，但一旦在内部，用户将能够自由地移动。系统的安全性建立为具有所有活动的普遍审计和记录的许可模型。系统中的不寻常的请求将在“打破玻璃”场景中被处理。例如，在一个实施例中，在进行之前在审计预警之后将向请求不寻常的访问的用户呈现“你确定么？”型问题。虽然系统向用户提供广泛请求，但是仍在需要的地方有一些限制。例如，护士将不能删除所有帐户。设计本说明书的医疗数据信息系统的安全性，以使得其绝不能妨碍护理者提供病人护理。这样，系统将不依赖IT安全性、加密、虚拟私人网络(VPN)或者操作系统(OS)平台。

将需要护理者和管理员将被要求具有带有用户名和密码证书的帐户，以经由获取设备、呈现设备和因特网访问系统。在一个实施例中，病人和亲属将具有经由因特网的特殊、受限访问，并且将不需要帐户。在一个实施例中，具有帐户的用户也提供有PIN作为短形式证书。PIN意图用于将尴尬于诸如在一个数字键盘上输入全证书的用户。PIN被硬连线至分配的角色并且用以当多个用户登录到获取或者呈现设备上时切换帐户。此外，PIN在所有设备上被高速缓冲用于当网络中断时的应急访问。

每个帐户被分配允许的角色的集合。每个角色定义由管理建立的许可的命名集合。用户选取角色，因此在登录期间允许。在一个实施例中，角色也规定允许的应用的列表。角色可以仅通过注销并且然后重新登录来改变。到单个系统设备的多个登录必须全都共享相同的角色。分配给每个角色的许可包括但不限于访问PHI，让病人住院和查看数据。每个帐户接收仅通过被分配角色接收许可。换言之，不存在帐户登记权限。活动的目录联合将目录组映射到角色，以允许大部分帐户管理在活动的目录中执行。

使用先进加密标准256(AES-256)加密所有数据(包括消息和网络通信量)。此外，在连接到系统云之前使所有系统设备有效。在一个实施例中，解密点在设备消息交换连接点，因为设备OS不被视为由系统信任。为了防止敏感信息的不期望访问，PHI数据与独立加密数据库中的临床数据或者会话分离。对单个数据库的未授权访问将不折衷由HIPAA保护的PHI。系统包括鲁棒密钥管理和密钥托管，其中，主要密钥被锁定在对证书加密钥的电子库中。即使当网络中断时，被高速缓冲的电子库许可登录。云和本地网络利用相同的加密并且云备也被加密。

在由于网络故障、由软件病毒或其他源的攻击的应急情况下，系统能够关闭到GHC的连接并且操作为独立设备，以获取并且呈现具有本地警报消息的生理数据。

系统利用Lua编码和虚拟机(VM)，如图3所示，以实现可靠安全性的闭合系统和可由第三方扩展的便携式系统。VM创建隔离应用，其中，如果恶意输入软件通过获取设备连接到系统，则软件包含至与系统软件和硬件隔离的虚拟机。在攻击的情况下，系统关闭VM，同时系统可以继续操作对于其他病人监视应用。

系统应用

本说明书的医疗数据信息系统的所有设备运行系统门户应用，该系统门户应用是系统的基本软件栈。每个OS平台(PC、Mac、iOs、Android)具有对于由OS特定部件(例如，iTune)递送到设备的该OS建立的特定门户应用。系统门户应用被封装为对于每个目标OS平台的单片机二进制(monolithicbinary)。简单地运行系统门户应用使得设备作为系统获取设备、系统呈现设备或者二者。系统门户应用也用在GHC和网络服务器中。

在可以使用系统门户应用之前需要设备注册。注册在系统域中创建对于设备和系统应用门户应用的组合的资产记录。注册也分配域消息交换连接ID用于消息寻址，并且分配密钥和托管电子库用于加密本地存储设备。注册可以在许可的情况下离线地执行或者直接在设备上执行。允许外部设备，但需要注册以确保设备不被污染。

图3是图示系统门户应用的一个实施例的软件架构300的框图。门户应用是加载为OS处理的单片机应用。门户应用包括门户应用基310，其举例说明用以按需要托管系统应用的多个集成临床引擎块320。

基310包含OS抽象层(OSAL)311，其隔离门户应用与操作系统305特异性并且处理启动、存储和其他OS接口。OSAL 311仅是最小化代码重用的OS特定的门户应用的一部分。基310也包括在一个实施例中提供以Lua编程语言编写的用于可执行应用的功能支持的多个库312。库312包括安全/加密、标准查询语言精简版(SQLite)、zlib、用户界面/用户体验(UI/UX)和其他库。本领域的技术人员将认识到，Lua是设计为与可扩展语义相比相对简单的脚本语言的轻量级跨平台编程语言。也包括在基310中的是用于执行集成临床引擎块320中的Lua应用代码的Lua引擎313。Lua引擎313也管理用于共享代码块的Lua块池。基310也包含集成临床引擎块管理器和完全消息交换协议栈315。门户应用基310基本用作复杂的Lua主机并且不包含活动的代码。

每个集成临床引擎块320用作用以执行系统应用的站点。系统获取设备和系统呈现设备每个举例说明单个集成临床引擎块320。网络服务器举例说明具有经由每个服务器的ID池的连接点ID的特定处理的每个活动的网络连接的一个块。每个块320包含其自己的消息交换连接点321，以使得每个块作为系统设备由云“看见”。此外，每个块具有其自己的TCP/IP连接、登录和许可。每个块320还包括由门户应用集310的Lua引擎313执行的多个各个Lua应用322，包括引导和系统应用。基310保持线程池以执行块320中的Lua应用322。线程按需要分派给Lua实例。Lua应用322被事件驱动。所有非Lua代码跨越所有系统门户应用相同。

Lua引导应用绑定至系统门户应用并且定义设备的类型(获取或者呈现)。引导应用仅是门户应用二进制之内装载的应用，并且其唯一的功能是登录到云并且加载系统应用。系统应用包含门户应用的实际功能，并且服务为按期望加载Lua应用。

Lua应用在在线市场上销售，并且存储为资产。所有应用被递送到设备上的门户应用，被准时(JIT)加载并且经由消息交换执行。Lua应用升级放置在资产编目中并且与更多麻烦的门户应用升级去耦合。

图4是图示涉及初始化本说明书的医疗数据信息系统中的获取设备的步骤的流程图。在步骤402。预加载的引导应用加载适当的获取设备系统应用。然后，在步骤404，获取设备系统应用通过注册传感器检测事件并且加载适当预设来初始化设备。在步骤406连接新传感器并且系统应用接收传感器连接的事件，以使得系统应用查询标识的传感器以确定传感器种类和类型。系统应用也查询域中的资产编目，以匹配应用驱动，并且然后依据编目加载驱动或者使用高速缓冲的副本。在步骤408，新驱动连接至传感器，以依据预设初始化设置并且在目录中注册参数。在步骤410，参数数据被本地记录并且可用于订阅。这包括即插即用能力，其中，系统自动地检测传感器设备的类型，并且配置该设备为与获取设备、系统警报和生理数据呈现接口连接。

消息交换协议

本说明书的用于提供病人护理的系统使用用于编码要跨越网络传送的消息的唯一协议。当经由系统消息交换协议发送消息时，传送器使用工业标准脚本语言以小型计算机程序发送消息。在一个实施例中，脚本语言是Lua。当接收器接收到消息时，其执行包含的程序并且作为执行的结果，接收到期望的数据。消息的执行自然地产生已经被完全解码并且在不需要进一步的处理的情况下准备好由接收器使用的数据。消息交换协议标准化接收器上的消息的执行，而不是标准化消息的实际内容。通过以这样的方式操作，消息交换协议从定义消息的内容到定义执行消息的结果来改变传送器和接收器之间的合同。

只要程序的最终执行产生预期数据，消息交换协议通过当发送消息时允许传送器创建它希望的无论什么程序，提供消息编码的更大灵活性。此外，新消息封装可以在接收器不需要注意到它们的情况下被开发，由此避免传送器和接收器不得不同时被升级的问题。一旦已经执行包含的程序，消息交换也通过以有用的形式提供最终数据来消除解码开销。

在一个实施例中，消息交换是建立本身和每个传送器和接收器之间的加密链路的中心、受信交换。消息交换和每个各个传送器和接收器之间的链路需要按传送器或者接收器仅建立一次。传送器本地加密消息，以用一次密钥(OTK)发送。然后传送器使用与消息交换交换的密钥用OTK发送加密消息。因为消息交换是受信交换，所以其知道双方的密钥并且将解密OTK，然后对于接收器重新加密。然后消息交换随着消息发送重新加密OTK到接收器。在一个实施例中，可以在不同位置跨越多个交换使用描述的交换。消息交换仅不得不解密并且加密OTK并且可以按原样通过消息，以导致交换处的更低开销。交换是无连接的，因为传送器和接收器不交换相互之间的密钥。密钥交换在受信消息交换处并且由受信消息交换完成，并且仅需要每个传送器或者接收器建立一次。消息密钥经由受信(点对点)消息交换结构被开隧道(tunnel)，而不需要建立端点连接，从而导致更高效的消息传递。

在一个实施例中，传送器在消息首部中嵌入其接收者列表并且将其发送至交换。消息交换复制接收者列表，然后传递该消息到所有意图的接收器。消息交换处理所有消息分发，以要求传送器不论接收者的数目仅发送消息一次。这使得传送器能够减小功率消耗。此外，因为接收者列表包括在每个消息的首部中，所以路由器操作能够保持稳定。因此，当设备漫游并且移动到新GHC中时，设备简单地继续发送数据到新GHC，而不需要重新同步。订阅列表已经附连在每个消息中。

因为来自传送器的代码正运行在接收器中，所以包含的程序能够执行接收器的执行空间中的任何合法动作。在一个实施例中，通过传送器发送包括回复回执的格式和生成的交换消息给数据的原始发送者作为消息中包含的代码的一部分，来完成回复回执的生成。当接收器执行脚本时，另一交换消息由接收器形成并且发送到原始数据发送者。在另一实施例中，回复回执的收集也被发送到数据收集服务器。在这个实施例中，由传送器发送的脚本程序包括针对传送器的回复回执生成程序和针对数据收集服务器的另一回复回执生成程序。

因此，通过使用诸如Lua之类的脚本语言，消息交换系统中的任何消息能够生成其自己的递送回执。这允许更高等级的协议以描述它们自己的递送有效语义，而不需要来自消息交换结构的附加支持。回复回执仅是如何使用交换消息来编码接收器中的复杂行为的一个示例，其不要求严格维持传送器和接收器之间的协议。

系统消息交换协议处理系统中的各个设备之间和设备和GHC之间的所有通信。交换在不需要其他网络准备的情况下使用TCP/IPv4或者TCP/IPv6以及DHCP。消息交换一直监视并且包括简单单个连接拓扑。每个设备维持到GHC的单个TCP/IP连接。GHC相互互连，以形成切换结构，从而使得设备到设备的消息传送无连接并且无状态。在不需要开放端口的情况下，外绑定所有防火墙连接。简单的拓扑导致具有低时延和瞬时切换的高性能系统。

每个系统门户应用的每个集成临床引擎块用作托管到GHC的实际TCP/IP连接的连接点。断开/重新连接和子网迁移对于其他应用透明。当设备和门户应用与系统一起注册时，建立连接点标识。典型地，单个设备包括具有一个集成临床引擎块的一个门户应用，以使得存在到系统的单个连接。连接点处理每个集成临床引擎块中的所有应用的所有消息。

消息端点总是应用。唯一的端点包括域ID、连接点ID和应用ID。因此，每个集成临床引擎块可以仅具有应用运行的一个实例。在一个实施例中，特定情况对于总是在本地GHC上的域编目存在。公知服务被映射到保留的多态连接点ID。在一个实施例中，应用可以向GHC注册服务，其中服务是意味着消息内容和顺序的全局ID。

图5是图示涉及两个应用之间的示例性消息交换的步骤的一个实施例的流程图。在集成的临床引擎数据块1530中，应用APPI1535创建用于应用APP4565的消息并且在步骤505发送消息到其消息交换连接点CP1532。应用APP1535是消息交换的第一端点EP1并且应用APP4565是消息交换的第二端点EP2。目标应用APP4565在集成临床引擎块2560内的消息交换连接点CP2562的第二端点EP2处寻址。在CP1532处的消息交换栈分割消息，并且在步骤510，发送消息片段给GHC1540。GHC1540检查目录并且在GHC2550上定位CP2562。在步骤515，GHC1540发送消息片段给GHC2550。在步骤520，GHC2550接收消息片段并且直接将它们发送到CP2562。CP2562处的消息交换栈接收片段并且重新装配消息。在步骤525，CP2562发送消息到目标应用APP4565。此外在图5中图示的是集成电路引擎块1530中的应用APP2537和集成电路块2560中的应用APP3567，应用APP2537和应用APP3567表示经由CP1532和CP2562连接的附加消息交换端点。

所有消息被分割、压缩和加密以进行传输。由连接点在每个末端执行所有消息的处理。GHC简单地切换不透明的数据。发送更小的消息片段允许在GHC中更高效的切换，并且防止大的、低优先级消息阻碍更高的优先级消息。片段从第一端点通过至少一个GHC发送，然后到第二端点。仅片段首部被加密并且解密为从一个GHC跳跃到另一GHC的片段。片段被一起阻止用于最佳网络框架并且标记有目标GHC以使得跳跃路由更快。

在一个实施例中，路由交换消息片段的GHC使用基于成本的路由算法，基于成本的路由算法使用加权的度量计算和选取最佳或者最快的路由。通过在实际使用期间的链路性能的直接测量自动计算度量。不需要初始设置或者调谐。路由协议自动对底层网络阻塞、运行中断和改变作出反应，以避免不必要的云成本，同时也保存网络故障的事件中的完全云后备。在操作期间，GHC交换路由成本度量以自动化通信量平衡。通过对实际链路性能的直接测量作出反应，系统高效地路由片段，同时最小化带宽使用。

在一个实施例中，本说明书的用于提供病人护理的系统将数据“捆绑”为合理尺寸的消息，以最小化用以传送给定数据体积的功率。一起“捆绑”数据为更大的消息导致当创建消息时和当该消息被发送到接收器时之间的延迟的增加，但需要来自传送器的更小功率。因为医院设置中的很多传送器可以是移动设备，所以“捆绑”消息有助于延长电池寿命。由传送设备连续获取的数据的示例包括ECG、血压和脉搏血氧定量波形(pulse oximetry waveform)。在非应急条件下，该数据可以一起被“捆绑”并且发送至保留电源。诸如威胁生命的临床警报或者危急系统消息之类的紧急消息将被分别并且立即发送。

因为消息由系统应用生成，所以它们在控制点处排队列。队列处理的一部分包括确定消息优先级。例如，在一个实施例中，消息被标注为系统、紧急、高、中间和低优先级，其中，最高优先级被首先发送。带宽预留避免低优先级消息互斥等待(starvation)。来自特定应用的非紧急消息总是按顺序发送，其中紧急和高优先级消息使得早IP缓冲刷新。在一个实施例中，“背景选项”推迟更低优先级消息，直至系统发送下一组“捆绑”消息为止。其中系统发送一组“捆绑消息”的每个实例被称为系统“心跳”。在一个实施例中，“心跳”以低频率(0.5至10Hz)出现。

在一个实施例中，系统实现发布和订阅(Pub/Sub)机制，发布和订阅(Pub/Sub)机制保证意图由多个订阅者或者接收者使用的数据将通过源设备或者传送器仅产生一次。例如，在系统中使用的移动监视设备具有设备的获取数据的多个消费者是常见的。典型移动监视器可能正生成由多个护理者(护士、管理护士、内科医生)使用的警报或者指标(vitals)，该多个护理者全都可以正监视不同设备(其一些可能是移动设备本身)上的同一病人。此外，指标和实时波形以及趋势可以连续显示在硬连线到网络的床边和中心监视器。

在这个实施例中，每个护理者的设备(和硬连线单元)将具有对正由移动监视器产生的数据的主动订阅。在该情况下，移动监视器从设备向最近的GHC传送监视数据一次。被传送的消息将包括设备的数据的所有接收者的地址。GHC将解释地址的列表并且确保复制数据被发送到所有接收者。

源设备上的CP将监视对数据的所有主动订阅并且确保对于每个订阅者的路由信息包括在被发送到GHC的单个消息分组中。当数据由GHC接收到时，将创建对于每个订阅设备绑定的新消息。注意，这个点处的数据的复制不再“昂贵”，这是因为GHC是具有快速网络连接的硬连线、壁式供电设备。

消息交换协议被优化用于低功率设备。在一个实施例中，输出流控制是可选的，因为其在不被功率约束的设备上不必要。背景选项通过以突发发送消息来减轻通信量并且优化WiFi无线电使用。此外，发布/订阅(Pub/Sub)数据仅从设备发送一次。减少总WiFi通信量改进设备电池寿命和网络上的负载。“心跳”处理当连接断开时的警告并且也发送状态、度量、安装列表和位置/呈现更新。

图6是图示来自本说明书的医疗数据信息系统的一对应用的消息的流的一个实施例的流程图。在步骤605，应用APP1630和应用APP2640每个发送消息到消息交换栈/连接点650用于递送到另一应用(未示出)。消息交换652压缩每个消息并且使用得出的密钥分别加密每个消息。然后消息交换652分割每个消息并且封装这些片段。在步骤610，消息交换652发送封装后的片段到连接点队列653。然后消息片段被优先化并且保存背景消息，直至下一“心跳”为止。加密片段首部并且一起级联这些片段。在步骤615，向OSTCP/IP栈660发送级联后的片段。从那里，片段在步骤620被发送到网络670并且到连接的GHC用于路由。

发布/订阅(Pub/Sub)是在集成临床引擎块中的连接点处处理的服务合同，并且因此由所有应用共享。连接点处理跟踪订户列表并且扩大具有订户端点的发布消息。连接点仅向具有订户列表的GHC发送消息片段一次。然后GHC按需要分叉片段以到达所有订户。这个消息片段的路由最小化网络通信量和发布者上的电池耗尽。当必要时，订户必须重新建立订阅，因为发布者不持续订阅。在发布者变黑以避免孤立订阅的情况下，订户应当重新订阅。

消息交换的目录是由GHC维护的内存数据库并且由SQLite支持，以缩放至几百万条目。在一个实施例中，在2-5秒内跨越域中的所有GHC复制目录。复制触发(脏标志)稍带确认(piggyback)至“心跳”上。在一个实施例中，目录包括所有设备的寄存器、端点和服务的寄存器并且也维护设备位置。确定设备位置可以帮助护理者找到病人。在一个实施例中，当设备被刷新时，最后已知位置也持续为资产编目。目录也可延伸用于第三方设备发现。

在一个实施例中，经由交换发送的大部分消息作为Lua源代码。Lua的使用是安全的，因为控制通过网络和门户应用维护。Lua源编码提供简单消息解码。例如，在一个实施例中，用户可以调用消息内容上的“loadstring()”以获得值。此外，Lua源编码提供用于更快的系统，因为Lua分析器被优化用于数据集(在平板计算机上>300/秒)。Lua源代码的使用通过消除严格的固定格式消息并且通过使得合同对消息的影响基于接收和执行，改变消息服务合同的范例。通过在消息中添加代码生成消息的回复回执。

病人会话和临床数据

在本说明书的医疗数据信息系统中，病人会话是从病人收集的所有临床数据的容器。每个会话由系统获取设备当收集病人数据时创建。此外，每个会话由全局唯一标识符(GUID)按设备标识。会话是累积不变的，因为它们只能被附加。在一个实施例中，每个会话被划分为一个小时“带”，以避免悬空会话。会话本身是匿名的，不包含受保护的健康信息(PHI)。每个会话中的数据是限定的，包括所有数据，并且可以被重放，很象数字视频录像机。此外，在一个实施例中，每个会话包括所有临床数据和警报、设置改变和谁进行改变的记录。

在一个实施例中，会话在系统获取设备中发起并且存储和分发在GHC中。GHC使用复制协议收集所有会话带。复制中的迟滞典型仅是几秒钟，以使得回顾数据可迅速用于分析。在一个实施例中，云GHC仅按要求收集会话带。

与会话相关联的病人从会话生命周期去耦合。新会话可以创建用于病人，而不需要住院，并且相关联可以在会话的开始、会话期间或者会话之后完成。诸如语音注释之类的“面包屑”有助于会话相关联。在一个实施例中，针对时间跨度的注解保持在病人记录中。在一个实施例中，注解可以是手动的或者合成的(例如，从警报创建)。在会话存档和存储方面，在一个实施例中，在基本保存期之后，可以修剪会话。在一个实施例中，修剪会话涉及丢弃非警报和非注释波形数据。修剪后的会话被迁移至云并且从GHC被丢弃。通过移动修剪后的会话至云，系统依赖于客户决定支付多长时间用于存储，提供基本上无限存储。

警报路由和警报熄灭

在一个实施例中，本说明书的用于提供病人护理的系统，警报优先级路由方法基于病人和护理者二者的位置和呈现信息。在一个实施例中，警报优先级路由的方法类似于2011年11月18日提交的名称为“System and Methodfor Transfer of Primary Alarm Notification on Patient Monitoring Systems”并且转让给本发明的申请人的美国专利申请号13/300，434中公开的，通过引用将其全部内容并入本文。

在一个实施例中，本说明书的系统将路由主要警报至最近的可用响应者，由此最小化在警报和来自护理者的响应之间花费的时间。在一个示例性实施例中，第一护理者指定为病人的负责急救人员(operator)(直接负责所述病人)。第一护理者分配他的或者她的移动警报显示器设备以接收病人的警报。病人的危急警报通告在移动设备上。第一护理者在移动设备上看该显示，并且确定病人仍在床上，并且第二护理者(急救人员)已经在病人的床边。第一护理者在移动设备的显示上按压第二护理者的名字，并且立即处于与第二护理者的双向语音通信，以评定情况。

在另一示例性实施例中，遥测病人离开病房去散步。当离开病房时，病人心搏停止并且支持不住。由病人佩带的遥测监视器发出高优先级警报。基于知晓病人的物理位置的本说明书的系统警告遥测病房中的病人的负责急救人员和离病人的当前位置更近的两个额外急救人员来帮助。系统附加地将所有三个护理者置于经由他们的移动设备的通信中，直至情况被解决为止。

在另一实施例中，系统包括设备警告，其中，特定警报被递送至由预选护理者携带的手持设备。例如，系统可以发送警告至ICU/CCU中的医生或者护士的PDA。分布护理者的预定集合将接收到优先级警报。这个选择性通知意味着不是网络上的每个人获得警告。例如，如果护理者在房间5，则系统可以使警报以该护理者为目标。护理者位置信息也可以被规定给特定的技术组合。在一个实施例中，存在被通知所有警告以确保响应的主分派者。目标警报并且将其分配至所选护理者通过确保最适合的护理者将首先接收到警报，增强系统的响应效率。

在一个实施例中，本发明的用于提供病人护理的系统业提供管理警报的分布和护理者团队定向方法。该方法提供消音或“熄灭”警报。当由连接到病人的设备检测到警报条件时，系统将向病人的适当护理者通知正出现警报条件。具有这样做的适当权力的接收到警报消息的任一个急救人员可以“熄灭”警报。由急救人员熄灭警报使当前显示警报信息的所有设备进入“熄灭”状态，“熄灭状态”可以使设备消音或者具有与传统警报确认操作相同的行为。熄灭操作指示其他急救人员警报条件已经被注意到并且授权的急救人员正采取适当动作。

在一个实施例中，“警报熄灭”状态应用于与病人相关联的所有获取设备，并且将持续，直至超时时段流逝或者检测到具有比被熄灭更高的优先级的新警报条件。如果出现这些条件中的任一个，则清除警报熄灭状态，并且警报显示器设备都适当显示最高警报信号，用于呈现的警报条件的集合。

在一个实施例中，在已经在警报熄灭状态的同时发起熄灭将基于当前呈现的警报条件的集合重置超时并且重置警报熄灭优先级。在一个实施例中，任何急救人员具有取消警报熄灭状态并且将所有警报显示器设备返回至最高警报功能的能力。

可选特征

在各种实施例中，本说明书的用于提供病人护理的系统还包括以下可选特征的任何一个或者组合。

在一个实施例中，系统的显示器设备能够提供波形的对数显示。通过对数地压缩波形显示的最左边和最右边处的时间标度，系统提示用户附加数据可用。护理者可以自然地在这些区域“滑动”，以移动数据到波形的中心部分的焦点。护理者也可以在定位护理者将愿意更详细地查看的波形的一部分之后，切换到数据的线性视图。

在一个实施例中，系统设备除了传统“当”警报声音之外还包括语音警报。例如，添加到由护理者佩戴的头戴式耳机的语音合成提供附加警报细节，包括警报原因、病人位置(例如，房间、手术室等)和病人名字。

在一个实施例中，一旦出院或者为了院外护理，系统设备提供病人的院外护理方案。当病人为了院外护理在家采用监视设备，该设备能够提供护理的附加帮助，包括传统地口头给出出院、药物方案(包括内置日历提醒)、扫描处方药上的快速响应(QR)码以验证药方案的能力和其他类似任务的可读门诊指令。

在一个实施例中，QR码用以帮助定位服务。除了诸如Wi-Fi三角测量和近场通信(NFC)之类的前进技术之外，简单地打印QR码并且将它们传递到隔壁也提供便宜的具体可应用于新兴市场的位置感知的方法。护理者设备的摄像头用以快速拍摄码并且提供位置感知。

在一个实施例中，系统包括用以为病人和家庭提供病人信息和娱乐二者的智能壁上式显示器。病人房间中的显示器设备当护理者没有出现时充当娱乐网络中心，但只要护理者进入房间就自动切换为提供病人护理信息。在一个实施例中，系统提供双显示器配置，如2011年3月21日提交的名称“Multi-Display Bedside Monitoring System”并且转让给本发明的申请人的美国专利申请号13/052，883中描述，其全部内容以引用的方式并入本文。

系统提供双显示器监视器，该双显示器监视器可以设置在病人的床边以与病人的实时至关重要的统计一起提供与病人有关的聚集医疗信息。两个显示器之一连续显示实时病人监视信息，而另一个用以显示信息(诸如当药物被递送时，参考生命体征示出实验结果)，并且提供对其他远程医院应用的访问，典型地仅可经由独立数据终端访问。双显示器监视器连接到医院信息系统并且具有显示本地软件应用和经由远程显示软件(诸如，由Citrix^TM销售的软件)显示远程软件应用的能力。此外，双显示器监视器可以连接到中心监视器配置，该中心监视器配置包括至四个附加显示器。这些附加显示器可以用以监视更多的病人，显示附加数据和/或托管其他应用。

此外，在其他实施例中，在双显示器监视器上访问的本地和远程软件应用也包括与只是涉及提供病人监视功能的那些不同的应用。例如，这种软件可以是娱乐应用；因特网或者其他网络连接应用；或者病人教育应用或者电子邮件或者视频会议应用或者将有利地对于本领域的技术人员显而易见的任何其他增加价值的应用。

在一个实施例中，双显示器监视器可以以病人模式或者护理者模式启用。在病人模式中，不能改变临床设置，但是可以运行批准软件应用的受控列表(诸如，娱乐或者病人教育之类)。除非护理者在房间中，监视器在病人模式中。由此，例如，当病人在没有人看护的房间中时，监视器将典型地在病人模式。可以由护理者远程地改变该模式。为了改变为护理者模式，使得监视器能够采用证书、密码或者RFID标记卡。在一个实施例中，启用上下文敏感的禁用或者病人模式的最小化。由此，在改变临床状态的事件中[例如，特定警报种类(高优先级)]，禁用或者最小化病人的应用，直至由护理者清除为止。理想地，这将可由护理者通过警报类型或者警报种类配置。

在一个实施例中，系统提供增强并且流水线化设备之中收集的的数据的即插即用算法级联。当传感器连接到设备时，触发适当驱动应用的加载。这个驱动反过来发布来自设备的临床数据。这个数据被建模为虚拟传感器，该虚拟传感器使得另一个驱动应用加载进一步处理数据，由此使得按需要驱动“级联”负载。这允许智能警报驱动加载并且收集来自多个设备的数据。

在一个实施例中，系统通过描述医疗数据算法作为具有限定的输入和输出的功能块，提供自组装级联医疗数据流。当期望特定输出时，可以通过使用元数据来以反向(消费者提供)级联连接输入和输出自组装块的集合。这可应用于实时数据和回顾分析。此外，依据可用原始输入和算法置换容易地计算可用输出的集合。

在一个实施例中，系统设备可以自测试以确定是否能够充当警报显示器设备。在各种实施例中，不是所有的系统设备将能够充当警报显示器设备。设备中的限制可以是生成足够大的可听音调或者可视地显示足够大的消息以满足可用性要求的能力。通过安装在设备上的应用执行自测试并且由系统使用结果，以确定设备是否能够充当警报显示器设备。

在一个实施例中，系统提供用于聚集并且存储病人的数据在单个文件以使得其可以由任何护理者在病人留在医院期间的任何时间访问的部件。在一个实施例中，该部件包括能够在实时远程视图中显示多达64个病人的数据的基于单个PC的设备。该设备也可以耦合到四个附加显示器以改进观看。

该设备包括鲁棒的用户界面，以基于回顾呈现病人数据。该设备用作中心化远程站，用于仿佛数据嵌入到设备中那样观看所有的病人的数据。护理者能够从任何位置并且在任何时间观看临床数据。

此外，在一个实施例中，设备以病人记录管理器和会话跟踪器的形式提供用于病人相关联和标识。在常规病人监视系统的情况下，数据存储设备是以设备为中心，而不是以病人为中心。这样，病人数据可能甚至在病人已经出院之后仍驻留在房间的设备中。此外，在常规系统的情况下，医疗记录号(MRN)和标识号可能混淆。通过并入病人记录管理器和会话跟踪器，无论数据流在什么地方停止，新会话开始经受重新相关联。每个病人与电子序列号相关联。因此，当病人与一个监视设备断开并且重新连接到另一个监视设备时，病人重新关联到新设备。在一个实施例中，可以合并会话，以使得来个各种设备的所有病人数据可以完全被观看到。

病人可以经由多个相关联方法与不同的监视设备相关联。在各种实施例中，这些包括自动视网膜操作、生物计量病人标识和基于传感器的标识。例如，可以通过收集和分析DNA样本、分析指纹或者通过一些其他非侵入性过程完成相关联。每个相关联方法标识病人并且协调设备和来自该设备的数据与该病人。一旦建立，特定设备和单个病人之间的相关联总是呈现，并且绝没有建立复制相关联的任何问题。这也当RFID链(RFID)断开时避免丢失设备-病人相关联的问题。

在另一实施例中，每个病人通过在护理者之间传递的标签或者挂绳(lanyard)与设备相关联，并且将需要在病人的护理期间的任何给定时间被通知。

在一个实施例中，系统也提供用于护理者设备和病人数据之间的相关联。每个护理者可以基于那个人想要什么定制在手持设备上的显示。上面的示例仅仅是本发明的系统的很多应用的例示。虽然这里已经描述本发明的仅几个实施例，但是应该理解本发明可以在不脱离本发明的精神或者范围的情况下体现在很多其他特定形式中。因此，本示例和实施例被视为例示性而不是限制性，并且可以在所附权利要求的范围内修改本发明。

Claims (20)

1.一种用于提供病人护理的系统，包括：

a.第一计算设备，具有第一易失性或者非易失性计算机可读介质，不包括用于传送波的传输介质，其中，所述第一介质包括：

i.第一多个程序化指令，其中，当由所述第一计算设备执行时，所述第一多个程序化指令：

1.使用标准脚本语言加密可执行程序并且将所述加密的程序附连至消息的首部；以及，

2.经由无线连接从第一计算设备向第二计算设备传送所述消息；

b.第二计算设备，具有第二易失性或者非易失性计算机可读介质，不包括用于传送波的传输介质，其中，所述第二介质包括：

i.第二多个程序化指令，其中，当由第二计算设备执行时，所述第二多个程序化指令：

1.从所述第一计算设备接收所述消息；

2.依据所述消息确定意图接收所述消息的至少一个目标计算设备；以及

3.经由无线连接从所述第二计算设备向所述至少一个目标计算设备传送所述消息；以及，

c.至少一个目标计算设备，具有第三易失性或者非易失性计算机可读介质，不包括用于传送波的传输介质，其中，所述第三介质包括：

i.第三多个程序化指令，其中，当由第三计算设备执行时，所述第三多个程序化指令：

1.从所述第二计算设备接收所述消息；

2.解密所述可执行程序；以及，

3.执行所述可执行程序并且由此接收所述消息；

其中，所述第二计算设备是基于云的计算设备。

2.一种用于提供病人护理的系统，包括：

a.至少一个感测设备，配置为检测并且报告病人的至少一个生理参数；

b.至少一个获取设备，耦合到所述至少一个感测设备，其中，所述获取设备从所述至少一个感测设备接收电子病人数据，并且包括能够存储所述病人数据的存储器；

c.至少一个网络装置，耦合至所述至少一个获取设备，其中，所述网络装置配置为从所述获取设备接收所述病人数据；

d.网络，用于提供云计算，其中，所述至少一个网络装置耦合到所述网络，并且其中，所述网络包括用于存储所述病人数据的数据库，以使得所述病人数据可跨越所有网络设备访问；以及

e.至少一个呈现设备，耦合到所述网络，其中，所述呈现设备配置为访问所述病人数据并且在图形用户界面上显示所述病人数据，

其中，跨越所述网络的所述电子病人数据的传输包括通过使用标准脚本语言编码可执行程序并且将所述程序附连至包括所述病人数据的消息来加密所述病人数据。

3.如权利要求2所述的用于提供病人护理的系统，其中，所述网络装置定位接近病人。

4.如权利要求2所述的用于提供病人护理的系统，其中，所述网络装置定位远离病人。

5.如权利要求2所述的用于提供病人护理的系统，其中，所述至少一个感测设备经由有线连接耦合到所述至少一个获取设备。

6.如权利要求2所述的用于提供病人护理的系统，其中，所述至少一个感测设备经由无线连接耦合到所述至少一个获取设备。

7.如权利要求2所述的用于提供病人护理的系统，其中，所述至少一个感测设备和所述至少一个获取设备能够经由3G/4G连接连接到网络。

8.如权利要求2所述的用于提供病人护理的系统，其中，所述标准脚本语言是Lua。

9.如权利要求2所述的用于提供病人护理的系统，其中，所述呈现设备包括传统PC、平板电脑、智能电话或者壁挂式显示器中的任一个。

10.如权利要求2所述的用于提供病人护理的系统，其中，所述获取设备也用作呈现设备。

11.如权利要求2所述的用于提供病人护理的系统，其中，所述获取设备复制并且在所述存储器上存储所述病人的所有临床数据，并且在系统故障时用作独立监视器。

12.如权利要求2所述的用于提供病人护理的系统，其中，所述获取设备是护理者设施处的固定设备。

13.如权利要求2所述的用于提供病人护理的系统，其中，所述获取设备是一旦出院并且为了院外护理与所述病人留在一起的移动设备。

14.如权利要求2所述的用于提供病人护理的系统，还包括通过在实际使用期间直接测量当前网络性能，计算最有效的消息路由的基于成本的路由算法。

15.如权利要求2所述的用于提供病人护理的系统，还包括基于所述病人和护理者二者的位置和存在信息路由警报优先级的警报路由协议。

16.如权利要求2所述的用于提供病人护理的系统，其中，护理者能消音或者在音量上减小分配给所述病人的所有设备的可听警报。

17.如权利要求2所述的用于提供病人护理的系统，还包括建立在交换和每个消息传送器与接收器之间的每个设备一个的加密链路的中心受信消息交换。

18.如权利要求17所述的用于提供病人护理的系统，其中，所述中心消息交换群集要周期性发送的非紧急消息。

19.如权利要求17所述的用于提供病人护理的系统，其中，所述消息传送器配置为每个消息仅发送一次，并且所述中心消息交换配置为基于所述消息的首部中包括的订阅列表复制每个消息并且发送每个消息给多个接收者。

20.一种用于提供病人护理的方法，该方法包括以下步骤：

a.提供病人护理系统，该病人护理系统包括：

i.至少一个感测设备，配置为检测并且报告病人的至少一个生理参数；

ii.至少一个获取设备，耦合到所述至少一个感测设备，其中，所述获取设备从所述至少一个感测设备接收电子病人数据，并且包括能够存储所述病人数据的存储器；

iii.至少一个网络装置，耦合至所述至少一个获取设备，其中，所述网络装置配置为从所述获取设备接收所述病人数据；

iv.网络，用于提供云计算，其中，所述至少一个网络装置耦合到所述网络，并且其中，所述网络包括用于存储所述病人数据的数据库，以使得所述病人数据可跨越所有网络设备访问；以及

v.至少一个呈现设备，耦合到所述网络，其中，所述呈现设备配置为访问所述病人数据并且在图形用户界面上显示所述病人数据，

b.使用所述至少一个感测设备检测并且报告所述至少一个病人生理参数；

c.向所述获取设备传送表示所述至少一个生理参数的电子数据；

d.通过使用标准脚本语言编码可执行程序并且将所述程序附连至包括所述病人数据的消息来加密所述病人数据；

e.向所述网络装置传送所述加密数据；

f.使用云计算在所述网络上存储所述数据；

g.使用所述呈现设备访问、解密和显示所述数据。