用于服务器与多个医疗设备之间的通信的方法和系统.pdf

用于服务器与多个医疗设备之间的通信的方法和系统。该方法包括：对每个医疗设备编程以具有第一共有元数据，通过第一共有元数据传递相应医疗设备的被定义的设备标识符；对每个医疗设备编程以具有相应第二元数据，通过相应第二元数据传递由医疗设备收集的操作数据；从相应医疗设备发送信息包，每个包至少包括：第一元数据和医疗设备的设备标识符；以及第二元数据和由医疗设备收集的操作数据的至少一部分；在所述服务器处接收来自相应医疗设备的信息包，并且在服务器处，对于所接收的每个信息包，处理信息包以确定用第一元数据传递的被定义的设备标识符，在被定义的设备标识符与已知医疗设备匹配的情况下，还确定用第二元数据传递的操作数据。

权利要求书一种在服务器和多个医疗设备之间通信的方法，其中每个所述医疗设备具有被定义的设备标识符并且适合于收集与所述医疗设备的使用相关联地产生的操作数据，所述方法包括：
对每个医疗设备编程以具有第一共有元数据，通过所述第一共有元数据传递相应医疗设备的所述被定义的设备标识符；
对每个医疗设备编程以具有相应第二元数据，通过所述相应第二元数据传递由所述医疗设备收集的所述操作数据，所述相应第二元数据是标识所收集的所述操作数据的项；
从相应医疗设备发送信息包，每个包至少包括：所述第一元数据和所述医疗设备的所述被定义的设备标识符；以及所述第二元数据和由所述医疗设备收集的所述操作数据的至少一部分；
在所述服务器处接收来自所述相应医疗设备的所述信息包，并且在所述服务器处，对于所接收的每个信息包，处理所述信息包以确定用所述第一元数据传递的所述被定义的设备标识符，在所述被定义的设备标识符与已知医疗设备匹配的情况下，还确定用所述第二元数据传递的所述操作数据。
根据权利要求1所述的方法，还包括：在所述被定义的设备标识符不与已知医疗设备匹配的情况下，隔离来自所述医疗设备的所述信息包。
根据权利要求1所述的方法，还包括：
在服务器处，基于医疗设备的所述设备标识符选择医疗设备；以及
向被选择的医疗设备发送信息包，所述信息包包括传递所述设备标识符的所述第一共有元数据。
根据权利要求1所述的方法，还包括：从一个医疗设备制造商获得所述多个医疗设备中的第一个医疗设备，以及从另一个不同的医疗设备制造商获得所述多个医疗设备中的第二个医疗设备。
根据权利要求1所述的方法，还包括：
其中，在服务器处接收来自所述相应医疗设备的所述信息包包括：在所述服务器处接收来自第一医疗设备的第一信息包，其中，与所述第一医疗设备相关联的所述第一共有元数据传递所述第一医疗设备的所述设备标识符，而与所述第一医疗设备相关联的所述第二元数据传递所述操作数据；
将来自所述第一医疗设备的所述操作数据与预定限制进行比较；以及
在来自所述第一医疗设备的所述操作数据在所述预定限制之外的情况下，在所述服务器处触发警报。
根据权利要求5所述的方法，还包括：在来自所述第一医疗设备的所述操作数据在所述预定限制之外的情况下，向所述第一医疗设备发送信息包，该信息包包括传递所述设备标识符的所述第一共有元数据以及第三元数据，通过所述第三元数据传递指示所述第一医疗设备的所述操作数据在所述预定限制之外的警报数据。
根据权利要求5所述的方法，还包括：在来自所述第一医疗设备的所述操作数据在所述预定限制之外的情况下，向联网的计算系统发送信息包，该信息包包括传递所述设备标识符的所述第一共有元数据以及第三元数据，通过所述第三元数据传递指示所述第一医疗设备的所述操作数据在所述预定限制之外的警报数据。
根据权利要求1所述的方法，还包括：
将来自第一医疗设备的所述操作数据与预定限制进行比较；以及
在来自所述第一医疗设备的所述操作数据在所述预定限制之外的情况下，向所述第一医疗设备发送信息包，该信息包包括传递所述设备标识符的所述第一共有元数据以及第三元数据，通过所述第三元数据传递指示所述第一医疗设备的所述操作数据在所述预定限制之外的警报数据。
根据权利要求1所述的方法，还包括
将来自第一医疗设备的所述操作数据与预定限制进行比较；以及
在来自所述第一医疗设备的所述操作数据在所述预定限制之外的情况下，向联网的计算系统发送信息包，该信息包包括传递所述设备标识符的所述第一共有元数据以及第三元数据，通过所述第三元数据传递指示所述第一医疗设备的所述操作数据在所述预定限制之外的警报数据。
根据权利要求1所述的方法，其中，对每个医疗设备编程以具有相应第二元数据包括：对至少一些所述相应医疗设备编程不同的第二元数据，从而所述至少一些所述相应医疗设备的所述第二元数据不是在其间共有的。
根据权利要求1至10中任一项所述的方法，其中，所述操作数据选自以下数据：基础速率；团注速率；治疗阈值；呼吸率；心率；血氧水平；血糖水平；患者疼痛水平；电源事件；警报事件；故障事件；维护事件；遥测事件；治疗事件；治疗改变事件；定制事件；患者数据；用户数据；控制数据；药物数据；以及位置数据。
一种包括服务器和多个医疗设备的系统，其中所述服务器通信连接到所述医疗设备，其中：
所述医疗设备中的每个：（a）具有被定义的设备标识符；（b）适合于收集与所述医疗设备的使用相关联地产生的操作数据；（c）被编程为具有第一共有元数据，通过所述第一共有元数据传递所述医疗设备的所述被定义的设备标识符；并且（d）被编程为具有相应第二元数据，通过所述相应第二元数据传递所述医疗设备的操作数据；并且
所述服务器具有：存储器，其被配置为存储操作数据；以及可编程电路，其操作连接到所述存储器，并且被配置为执行程序指令以：（a）从每个医疗设备接收信息包，所述信息包包括（i）所述第一元数据和所述医疗设备的被定义的设备标识符和（ii）所述第二元数据和所述医疗设备的操作数据，以及（b）处理每个信息包以基于所述第一元数据确定所述被定义的设备标识符，以及，至少在所述设备标识符与已知医疗设备匹配的情况下，基于所述第二元数据确定所述操作数据。
根据权利要求12所述的系统，所述可编程电路还被配置为执行程序指令以在所述存储器中存储所确定的操作数据。
根据权利要求12所述的系统，所述可编程电路还被配置为执行程序指令以在所述设备标识符不与已知医疗设备匹配的情况下隔离来自特定医疗设备的信息包。
根据权利要求12所述的系统，所述可编程电路还被配置为执行程序指令以基于医疗设备的所述设备标识符选择医疗设备，以及使得向被选择的医疗设备发送信息包，所述信息包包括传递所述设备标识符的所述第一共有元数据。
根据权利要求12所述的系统，其中，所述多个医疗设备中的第一个医疗设备来自一个医疗设备制造商，而所述多个医疗设备中的第二个医疗设备来自另一个不同的医疗设备制造商。
根据权利要求12所述的系统，所述可编程电路还被配置为执行程序指令以将来自所述医疗设备的至少之一的所述操作数据与预定限制进行比较，并且在来自所述医疗设备的所述操作数据在所述预定限制之外的情况下在所述服务器处触发警报。
根据权利要求17所述的系统，所述可编程电路还被配置为执行程序指令以使得：在来自所述医疗设备的所述操作数据在所述预定限制之外的情况下，向所述医疗设备发送信息包，该信息包包括传递所述设备标识符的所述第一共有元数据以及第三元数据，通过所述第三元数据传递指示所述医疗设备的所述操作数据在所述预定限制之外的警报数据。
根据权利要求17所述的系统，所述可编程电路还被配置为执行程序指令以使得：在来自所述医疗设备的所述操作数据在所述预定限制之外的情况下，向联网的计算系统发送信息包，该信息包包括传递所述设备标识符的所述第一共有元数据以及第三元数据，通过所述第三元数据传递指示所述医疗设备的所述操作数据在所述预定限制之外的警报数据。
根据权利要求12所述的系统，所述可编程电路还被配置为执行程序指令以使得：在来自所述医疗设备的所述操作数据在所述预定限制之外的情况下，向所述医疗设备发送信息包，该信息包包括传递所述设备标识符的所述第一共有元数据以及第三元数据，通过所述第三元数据传递指示所述医疗设备的所述操作数据在所述预定限制之外的警报数据。
根据权利要求12所述的系统，所述可编程电路还被配置为执行程序指令以使得：在来自所述医疗设备的所述操作数据在所述预定限制之外的情况下，向联网的计算系统发送信息包，该信息包包括传递所述设备标识符的所述第一共有元数据以及第三元数据，通过所述第三元数据传递指示所述医疗设备的所述操作数据在所述预定限制之外的警报数据。
根据权利要求12所述的系统，与每个相应医疗设备相关联的所述相应第二元数据包括与至少一些所述相应医疗设备相关联的不同的第二元数据，从而所述至少一些所述相应医疗设备的所述第二元数据不是在其间共有的。
根据权利要求12至22中任一项所述的系统，其中，所述操作数据选自以下数据：基础速率；团注速率；治疗阈值；呼吸率；心率；血氧水平；血糖水平；患者疼痛水平；电源事件；警报事件；故障事件；维护事件；遥测事件；治疗事件；治疗改变事件；定制事件；患者数据；用户数据；控制数据；药物数据；以及位置数据。

说明书用于服务器与多个医疗设备之间的通信的方法和系统
本申请是申请日为2008年8月11日、申请号为“200880110784.6”、发明名称为“用于控制医疗设备的系统”的发明专利申请的分案申请。
本申请以史密斯医疗MD有限公司的名义作为PCT国际专利申请于2008年8月11日提交，对于除美国之外指定的所有国家以该公司作为申请人，而仅对于美国的指定以均为美国公民的尼克.罗伯特和李A.纽曼作为申请人，并且本申请要求2007年8月10提交的第60/964,444号美国临时专利申请的优先权。
技术领域
一般地，本发明涉及借助于用于使用和控制医疗设备的系统来治疗患者。更具体地，本发明涉及用于使用医疗设备治疗患者的软件。
背景技术
医院和其它护理中心的患者需要受控的治疗管理和监测。医院和护理中心使用多种类型和品牌的医疗设备来协助监测和治疗管理。例如，用于协助治疗管理的医疗设备可以包括医用输液泵、脉搏血氧计、心肺监测器和其它治疗提供设备和患者监测设备。多种类型和品牌的医疗设备分别通常使用不同的、专有的通信标准。
不同设备采用的专有标准限制了设备间的互用性，使得治疗管理困难。在使用一个或更多个医疗设备的过程中，看护者可能想进行与医疗设备有关的多种动作。例如，看护者可能希望基于所观察到的患者的特性来设置医疗设备中的参数。或者，看护者可能希望查看监测器采集的数据。由于多种医疗设备所用的专有标准，看护者可能采用多种类型的软件和硬件来访问由治疗患者所需要的医疗设备采集的信息。
医疗设备的协同使用也可能是困难的。单个医疗设备可以被编程用于管理不同的治疗并且可以位于医院内不同的位置。可能需要比较位于不同医院中的不同类型的多个医疗设备的使用记录。类似地，由于医疗设备经常位于看护者所在的位置之外的位置，因此可能难以监测医疗设备的状态。
发明内容
公开了患者治疗的方法和系统。该方法和系统包括利用医疗设备信息来修改和确认治疗以及这些治疗中所用的药物。在本发明的各个方面中，诸如医用输液泵的医疗设备与服务器连接以管理对患者的治疗。
在某些方面，采用医疗设备元数据定义医疗设备网络中的医疗设备。在另外的方面，消息在医疗设备和服务器之间传递以定义治疗和对该医疗设备的其它操作。在又一些方面，从医疗设备向医疗设备服务器传递操作和历史数据以允许对患者的治疗的管理的远程监测。在另外的方面，定时参数控制医疗设备和医疗设备服务器之间的通信和事件跟踪。
在特定方面，公开了一种医疗设备和服务器之间的通信方法。该方法包括将元数据与一个或更多个医疗设备关联，该元数据对应于医疗设备的属性。该方法还包括在服务器上存储元数据，服务器被配置为通过使用元数据与每个医疗设备通信。
根据一个实施例，所述元数据对应于所有所述医疗设备共有的属性。
根据一个实施例的方法还包括：将第二元数据与第二医疗设备关联，所述第二医疗设备与所述一个或更多个医疗设备不同；以及将所述第二元数据存储在所述服务器上，所述服务器被配置为通过使用所述元数据和所述第二元数据中的至少一个来与所述医疗设备和所述第二医疗设备中的每个进行通信。
根据一个实施例，其中，所述一个或更多个医疗设备包括来自两个或更多个医疗设备制造商的医疗设备。
根据一个实施例的方法还包括将第二元数据与所述多个医疗设备中的至少一个医疗设备关联，所述第二元数据对应于所述医疗设备的至少一个定制属性。
根据一个实施例，其中，所述元数据和所述第二元数据定义所述医疗设备的能力。
根据一个实施例，其中，将所述元数据存储在服务器上还包括将所述第二元数据存储在所述服务器上。
根据一个实施例，其中，所述元数据包括医疗设备标识符。
根据一个实施例，其中，所述元数据包括医疗能力变量。
根据一个实施例，其中，所述元数据包括所述医疗设备的名称。
根据一个实施例，其中，所述元数据对应于所述医疗设备的属性，所述属性选自由患者信息、用户信息、控制信息、药物信息和位置信息构成的组。
根据一个实施例，其中，所述元数据对应于由所述医疗设备跟踪的事件，所述事件选自由电源事件、警报事件、故障事件、维护事件、遥测事件、治疗事件、治疗改变事件和定制事件构成的组。
根据一个实施例，其中，所述第二元数据包括医用输液泵的属性。
根据一个实施例的方法还包括在所述服务器上使用所述元数据选择医疗设备。
根据一个实施例的方法还包括向所述医疗设备发送消息，所述消息包括元数据。
根据一个实施例，其中，使用XML构造所述元数据。
根据一个实施例的方法还包括使用所述元数据来区分所述多个医疗设备。
在第二方面，公开了一种用于与多个医疗设备通信的系统。该系统包括多个医疗设备以及与多个医疗设备通信连接的服务器。服务器包括被配置为存储描述医疗设备的元数据的存储器和操作连接到存储器的可编程电路。可编程电路被配置为执行程序指令以将元数据与一个或更多个医疗设备关联，元数据与医疗设备的至少一个属性相对应。可编程电路还被配置为执行程序指令以在服务器上存储元数据并与至少一个医疗设备传递包括元数据的信息。
根据一个实施例，其中，所述元数据对应于所有所述医疗设备共有的属性。
根据一个实施例，其中，所述多个医疗设备包括来自两个或更多个医疗设备制造商的医疗设备。
根据一个实施例，其中，所述可编程电路还包含程序指令以将第二元数据与所述医疗设备的至少一个医疗设备关联，所述第二元数据对应于所述医疗设备的至少一个定制属性。
根据一个实施例，其中，所述元数据和所述第二元数据定义所述医疗设备的能力。
根据一个实施例，其中，所述可编程电路还被编程为将所述第二元数据存储在所述服务器上。
根据一个实施例，其中，所述第一元数据包括医疗设备标识符。
根据一个实施例，其中，至少一个所述医疗设备是医用输液泵。
根据一个实施例，其中，所述第二元数据包括所述医用输液泵的属性。
根据一个实施例，其中，所述元数据对应于从由患者信息、用户信息、控制信息、药物信息和位置信息构成的组中选择的医疗设备的属性。
根据一个实施例，其中，所述元数据对应于由所述医疗设备跟踪的事件，所述事件选自由电源事件、警报事件、故障事件、维护事件、遥测事件、治疗事件、治疗改变事件和定制事件构成的组。
在第三方面，公开了一种在医疗设备和服务器之间通信的方法。该方法包括将元数据与多个医疗设备的每一个关联，该元数据与医疗设备共有的至少一个属性相对应。该方法还包括将第二元数据与多个医疗设备中的至少一个医疗设备关联，第二元数据与医疗设备的至少一个定制属性相对应。该方法还包括在服务器上存储元数据，服务器被配置为通过使用元数据与每个医疗设备通信。该方法还包括选择医疗设备和与医疗设备传递包括元数据的信息。
在第四方面，公开了一种在多个医疗设备和服务器之间通信的方法。该方法包括在医疗设备处生成给医疗设备服务器的消息，该消息包括用于识别该医疗设备的元数据。该方法还包括在医疗设备处接收来自医疗设备服务器的消息，该消息包括识别该医疗设备的元数据。
根据一个实施例，其中，所述多个医疗设备包括来自两个或更多个医疗设备制造商的医疗设备。
根据一个实施例的方法，还包括：将第二元数据与第二医疗设备关联，所述第二医疗设备与所述多个医疗设备不同；以及将所述第二元数据存储在所述服务器上，所述服务器被配置为通过使用所述元数据和所述第二元数据与所述医疗设备和所述第二医疗设备中的每个进行通信。
在另一个方面，公开了一种服务器，其包括被配置为存储关于位于不同客户地点的多个医疗设备的表识信息的存储器和操作连接到该存储器的可编程电路。可编程电路被配置为执行程序指令以接收来自位于一个或者更多个不同客户地点的医疗设备的数据，在存储器中存储与该一个或者更多个不同的客户地点关联的数据，并且将该数据的一部分与发送该部分数据的医疗设备关联。
根据一个实施例，其中，所述不同客户地点与不同客户关联。
根据一个实施例，其中，所述可编程电路还被编程为向一个或更多个所述医疗设备发送程序信息。
根据一个实施例，其中，所述服务器能够被所述不同客户地点处的一个或更多个工作站访问。
根据一个实施例，其中，所述可编程电路还被编程为向所述工作站提供与该客户地点关联的至少部分所述数据。
根据一个实施例，其中，所述可编程电路还被编程为将所述多个医疗设备与相应的不同客户地点关联。
根据一个实施例，其中，所述可编程电路还被编程为从客户地点处的工作站接收命令。
根据一个实施例，其中，所述可编程电路还被编程为确定从所述工作站接收的命令是否涉及所述客户地点处的医疗设备。
根据一个实施例，其中，所述可编程电路还被编程为在确定所述命令涉及所述客户地点处的医疗设备时，执行从所述工作站接收的所述命令。
根据一个实施例，其中，所述命令引导所述服务器对所述客户地点处的一个或更多个医疗设备重新编程。
根据一个实施例，其中，所述命令请求由所述服务器保持的事件日志数据，所述事件日志数据与所述客户地点处的一个或更多个医疗设备有关。
在又一个方面，公开了一种服务器网络。该网络包括位于不同客户地点处的多个医疗设备，以及操作连接到该多个医疗设备的服务器。该服务器包括被配置为存储关于位于不同客户地点的多个医疗设备的标识信息的存储器以及操作连接到该存储器的可编程电路。该可编程电路被配置为执行程序指令以接收来自位于一个或者更多个不同客户地点的医疗设备的数据，在存储器中存储与该一个或者更多个不同的客户地点关联的数据，并且将数据的一部分与发送该部分数据的医疗设备关联。服务器网络还包括位于其中一个客户地点的工作站，该工作站通信连接到该服务器并且被配置为请求与该客户地点有关的数据。
根据一个实施例，其中，所述不同客户地点与不同的客户关联。
根据一个实施例，其中，所述可编程电路还被编程为向一个或更多个所述医疗设备发送程序信息。
根据一个实施例，其中，所述可编程电路还被编程为将所述多个医疗设备与相应的不同客户地点关联。
根据一个实施例，其中，所述可编程电路还被编程为从工作站接收命令。
根据一个实施例，其中，所述工作站位于所述客户地点之一处。
根据一个实施例，其中，所述可编程电路还被编程为确定从所述工作站接收的命令是否涉及所述客户地点处的医疗设备。
根据一个实施例，其中，所述可编程电路还被编程以在确定所述命令涉及所述客户地点处的医疗设备时，执行从所述工作站接收的所述命令。
根据一个实施例，其中，所述命令引导所述服务器对所述客户地点处的一个或更多个所述医疗设备重新编程。
根据一个实施例，其中，所述命令请求由所述服务器保持的事件日志数据，所述事件日志数据与所述客户地点处的一个或更多个所述医疗设备有关。
根据一个实施例，其中，一个或更多个所述医疗设备是医用输液泵。
根据一个实施例，其中，所述命令选自由配置参数、药品库信息、软限制、硬限制、护理简档、固件更新和软件补丁构成的组。
根据一个实施例，其中，所述服务器通过有线网络连接操作连接到所述医疗设备。
根据一个实施例，其中，所述服务器通过至少部分无线的网络连接操作连接到所述医疗设备。
根据一个实施例，其中，所述服务器是应用服务器。
在另一个方面，公开了一种向医疗设备部署信息的方法。该方法包括将信息存储在服务器上的数据包中，该信息将要被传送到医疗设备。该方法还包括接收来自医疗设备的消息，并且响应于接收消息向医疗设备指示将要提供给医疗设备的信息位于该服务器上。该方法还包括接收对信息的请求，并且在接收请求时将数据包传送至医疗设备。
根据一个实施例，其中，所述信息在被存储在所述服务器上时被加密。
根据一个实施例，其中，所述信息在被传送到所述医疗设备的过程中被加密。
根据一个实施例，还包括在所述医疗设备上解密所述信息。
根据一个实施例，还包括在所述医疗设备服务器处解密所述信息。
根据一个实施例，还包括使用所述信息对所述医疗设备重新编程。
根据一个实施例，其中，所述数据包包括服务器可读头，所述服务器可读头缺少关于所述信息的内容的信息。
根据一个实施例，其中，所述数据包包括供应商头，所述供应商头包含与所述信息有关的数据结构信息和解密信息。
根据一个实施例，其中，所述供应商头包含所述信息的长度。
根据一个实施例，还包括接收有关所述数据包成功地被所述医疗设备接收的确认。
根据一个实施例，还包括选择要向所述医疗设备部署的信息。
根据一个实施例，其中，至少部分所述信息被使用所述信息中包含的杂凑值进行杂凑。
根据一个实施例，还包括存储包部署日志。
根据一个实施例，其中，所述包部署日志包括错误消息。
根据一个实施例，其中，由所述医疗设备服务器从所述医疗设备接收所述错误消息。
根据一个实施例，其中，所述错误消息由所述医疗设备服务器检测。
根据一个实施例，其中，所述包部署日志包括所述医疗设备的标识。
在另一个方面，公开了一种从服务器传送到医疗设备用于影响医疗设备的操作的数据包。该数据包包括具有数据结构的信息，该信息包括用于改变医疗设备的操作的数据。该数据包还包括服务器可读的头（header），其包括尺寸信息而缺少关于数据包的内容的信息。数据包还包括供应商定义的头，其包括与信息有关的数据结构信息。
根据一个实施例，其中，所述供应商头包含所述信息的长度。
根据一个实施例，其中，所述服务器可读头包括医疗设备标识信息。
根据一个实施例，其中，所述信息包括数据包加密信息。
根据一个实施例，其中，至少一部分所述信息被加密。
根据一个实施例，其中，所述信息包括影响所述医疗设备的操作的指令，所述指令选自由定义所述医疗设备的操作的固件、医疗设备配置信息、治疗命令信息、遥测请求信息和事件触发信息构成的组。
在又一个方面，公开了一种用于向医疗设备部署信息的系统。该系统包括被配置为存储数据包的存储器和与该存储器连接的可编程电路。该可编程电路被配置为执行程序指令以将信息存储在数据包中，该信息将要被传送到医疗设备。该可编程电路还被配置为执行程序指令以接收来自医疗设备的消息，并向医疗设备指示将要提供给该医疗设备的信息位于该存储器中。该可编程电路还被配置为执行程序指令以接收对信息的请求并且将数据包传送到该医疗设备。
根据一个实施例，其中，所述数据包中的所述信息用于对所述医疗设备重新编程。
根据一个实施例，其中，所述信息包括影响所述医疗设备的操作的指令，所述指令选自由定义所述医疗设备的操作的固件、医疗设备配置信息、治疗命令信息、遥测请求信息和事件触发信息构成的组。
在另一个方面，公开了一种由医疗设备接收信息的方法。该方法包括发起与医疗设备服务器的通信会话。该方法还包括接收医疗设备服务器已经存储了将要传送到该医疗设备的数据包的指示。该方法还包括请求数据包和接收数据包。
根据一个实施例，其中，所述医疗设备是医用输液泵。
根据一个实施例的方法还包括使用所述信息对所述医疗设备重新编程。
根据一个实施例的方法还包括在成功接收所述数据包时向所述医疗设备服务器发送确认消息。
在另一个方面，公开了一种包括分散在两个或者更多个时区上的多个医疗设备和操作连接到该医疗设备的服务器的医疗设备网络。该服务器包括被配置为保存事件日志数据的存储器和操作连接到该存储器的可编程电路。该可编程电路被配置为执行程序指令以从多个医疗设备接收事件日志数据并修改事件日志数据中的时区信息。可编程电路还被配置为执行程序指令以在存储器中存储事件日志数据。
根据一个实施例，其中，所述时区信息被修改为表示统一的时区信息。
根据一个实施例，其中，所述统一的时区信息对应于世界时间协议。
根据一个实施例，其中，修改所述事件日志数据包括修改所述事件日志数据中的时间戳。
根据一个实施例，其中，修改所述事件日志数据发生在将所述事件日志数据存储在所述存储器中之后。
根据一个实施例，还包括在修改所述时区信息时将所述事件日志数据传递给用户。
根据一个实施例，其中，所述可编程电路还被编程为将所述时区信息转换为与医疗设备的位置有关的本地时区信息。
根据一个实施例，其中，所述可编程电路还被编程为从所述事件日志数据得出报告。
根据一个实施例，其中，所述报告包含医疗设备的本地时区。
根据一个实施例，其中，所述可编程电路还被编程为使用所述时区信息跟踪全局事件。
根据一个实施例，其中，所述可编程电路还被编程为按照变换时间表分类所述事件日志数据中的事件。
在另一个方面，公开了一种协调位于两个或者更多个时区中的多个医疗设备中的事件日志时区信息的方法。该方法包括从多个医疗设备接收事件日志数据，并且修改事件日志数据中的时区信息。该方法还包括在存储器中存储事件日志数据。
根据一个实施例，其中，所述时区信息被修改为表示统一时区信息。
根据一个实施例，其中，所述统一时区信息对应于世界时间协议。
根据一个实施例，其中，修改所述事件日志数据包括修改所述事件日志数据中的时间戳。
根据一个实施例的方法还包括接收针对与医疗设备有关的事件日志数据的查询。
根据一个实施例的方法还包括将所述时区信息转换为与所述医疗设备的位置有关的本地时区信息。
根据一个实施例的方法还包括从所述两个或更多个时区之一中的工作站接收针对所述事件日志的查询。
根据一个实施例的方法还包括调整事件日志数据以表示所述工作站的时区内的时间。
根据一个实施例的方法还包括从所述事件日志数据得出报告。
根据一个实施例，其中，所述报告包含医疗设备的本地时区。
根据一个实施例的方法还包括使用所述时区信息跟踪全局事件。
根据一个实施例，其中，所述可编程电路还被编程为按照变换时间表分类所述事件日志数据中的事件。
在另一个方面，公开了一种协调位于两个或者更多个时区中的多个医疗设备中的事件日志时区信息的方法。该方法包括从多个医疗设备接收事件日志数据，并且修改事件日志数据中的时间戳以反映世界时间协议（Universal Time Protocol）。该方法还包括在存储器中存储事件日志数据，并且利用世界时间协议跟踪全局事件。该方法还包括接收对与医疗设备有关的事件日志数据的查询，并且将世界时间协议转换为与该医疗设备的位置有关的本地时区信息。
在另一个方面，公开了一种检索医疗事件日志结果的方法。该方法包括在服务器处接收由医疗设备生成的事件日志数据，并且将该事件日志数据存储在服务器的存储器中。该方法还包括接收对事件日志数据的子集的请求，事件日志数据的子集由至少一个特性定义。该方法还包括基于该特性过滤事件日志数据。
根据一个实施例的方法还包括输出所过滤的事件日志数据。
根据一个实施例，其中，所述特性是表示对所述医疗设备编程的看护者的看护者标识符。
根据一个实施例，其中，所述医疗设备是医用输液泵。
根据一个实施例，其中，所述特性是由所述医用输液泵提供的药物。
根据一个实施例，其中，所述特性是采集事件日志数据的时间范围。
根据一个实施例的方法还包括基于所过滤的事件日志数据生成报告。
根据一个实施例，其中，对事件日志数据的子集的请求接收自远离并且通信连接到所述服务器的工作站。
根据一个实施例的方法还包括向所述工作站发送所过滤的事件日志数据。
在另一个方面，公开了一种用于医疗事件日志结果的检索的系统。该系统包括被配置为存储具有多个特性的事件日志数据的存储器，以及操作连接到该存储器的可编程电路。该可编程电路被配置为执行程序指令以在服务器处接收由医疗设备生成的事件日志数据，并将该事件日志数据存储在服务器的存储器中。该可编程电路还被配置为接收对由至少一个特性定义的事件日志数据子集的请求，并且基于该特性过滤事件日志数据。
根据一个实施例，其中，所述可编程电路还被编程为输出所过滤的事件日志数据。
根据一个实施例，其中，所述特性是表示对所述医疗设备编程的看护者的看护者标识符。
根据一个实施例，其中，所述医疗设备是医用输液泵。
根据一个实施例，其中，所述特性是由所述医用输液泵提供的药物。
根据一个实施例，其中，所述特性是采集事件日志数据的时间范围。
根据一个实施例，其中，对事件日志数据的子集的所述请求接收自远离并且通信连接到所述服务器的工作站。
根据一个实施例，其中，所述可编程电路还被编程为向所述工作站发送所过滤的事件日志数据。
在另一个方面，公开了一种检索医疗事件日志结果的方法。该方法包括在服务器处接收由医用输液泵生成的事件日志数据，并将该事件日志数据存储在服务器的存储器中。该方法还包括从通信连接到服务器的远程工作站接收对事件日志数据的子集的请求，事件日志数据的子集由至少一个特性定义。该方法还包括基于该特性来过滤事件日志数据并将经过滤的事件日志输出至工作站。该特性是代表对医疗设备编程或操作的看护者的看护者标识符。
在另一个方面，公开了一种为医疗设备的维护制定时间表的方法。该方法包括在远离医疗设备的计算系统上存储医疗设备维护时间表，医疗设备维护时间表包括对医疗设备执行维护的提醒。该方法还包括将提醒从计算系统发送至医疗设备。
根据一个实施例的方法还包括显示所述提醒。
根据一个实施例，其中，所述医疗设备是医用输液泵。
根据一个实施例，其中，发送所述提醒响应于从所述医疗设备到所述计算系统的通信而发生。
根据一个实施例的方法还包括允许所述医疗设备在接收所述提醒之后继续操作。
根据一个实施例，其中，所述提醒禁用所述医疗设备。
根据一个实施例，其中，发送所述提醒在所述医疗设备的所需维护之前的预定时间发生。
根据一个实施例，其中，所述计算系统是通信连接到所述医疗设备的医疗设备服务器。
根据一个实施例，其中，发送所述提醒包括发送被配置为使能提醒的触发信号。
根据一个实施例，其中，所述提醒被存储在所述医疗设备上。
根据一个实施例，其中，所述医疗设备维护时间表被存储在所述计算系统上的医疗设备维护时间表的数据库中。
根据一个实施例的方法还包括在所述计算系统上存储与所述医疗设备关联的时间值。
根据一个实施例的方法还包括向所述医疗设备发送维护数据。
根据一个实施例，其中，所述维护数据包括所述医疗设备的配置参数。
根据一个实施例，其中，所述维护数据包括更新的操作软件。
在另一个方面，公开了一种用于管理医疗设备维护时间表的系统。该系统包括医疗设备和通信连接到该医疗设备的计算系统。该计算系统包括被配置为存储医疗设备维护时间表的存储器，该医疗设备维护时间表包括至少一个提醒。该计算系统还包括操作连接到该存储器的可编程电路。该可编程电路被配置为执行程序指令以存储医疗设备维护时间表并将提醒从计算系统发送至医疗设备。
根据一个实施例，其中所述医疗设备是医用输液泵。
根据一个实施例，其中，所述计算系统是通信连接到所述医疗设备的医疗设备服务器。
根据一个实施例，其中，所述可编程电路被配置为发送响应于从所述医疗设备到所述计算系统的通信而发生的所述提醒。
根据一个实施例，其中，所述医疗设备被配置为显示所述提醒。
根据一个实施例，其中，所述可编程电路还被编程为在所述计算系统上显示所述提醒。
根据一个实施例，其中，所述医疗设备被配置为在接收所述提醒之后继续操作。
根据一个实施例，其中，所述可编程电路被编程为将所述医疗设备的时间值存储在所述计算系统上。
根据一个实施例，其中，所述可编程电路被编程为在所述医疗设备的所需维护之前的预定时间发送所述提醒。
根据一个实施例，其中，所述可编程电路被编程为通过发送被配置为使能存储在所述医疗设备上的提醒的触发信号来发送所述提醒。
根据一个实施例，其中，所述提醒禁用所述医疗设备。
根据一个实施例，其中，所述可编程电路还被编程为将维护数据发送至所述医疗设备。
根据一个实施例，其中，所述维护数据包括所述医疗设备的配置参数。
根据一个实施例，其中，所述维护数据包括更新的操作软件。
在另一个方面，公开了一种用于管理医疗设备维护时间表的系统。该系统包括多个医疗设备和通信连接到该多个医疗设备的计算系统。该计算系统包括被配置为存储与每个医疗设备相对应的医疗设备维护时间表的存储器，每个医疗设备维护时间表包括至少一个提醒。计算系统还包括操作连接到该存储器的可编程电路。该可编程电路被配置为执行程序指令以存储医疗设备维护时间表，存储多个医疗设备的一个或者更多个时间值，并且选择医疗设备以根据与该医疗设备对应的医疗设备维护时间表发送提醒。该可编程电路还被配置为执行程序指令以将提醒从计算系统发送至医疗设备。
在另一个方面，公开了一种为医疗设备的维护制定时间表的方法。该方法包括在医疗设备处接收来自医疗设备服务器的提醒，该提醒与医疗设备的维护事件有关。该方法还包括在医疗设备的显示器上显示提醒。
根据一个实施例，其中，所述医疗设备是医用输液泵。
根据一个实施例，其中，所述提醒禁用所述医疗设备。
根据一个实施例，其中，所述医疗设备被配置为在接收所述提醒后继续操作。
根据一个实施例的方法还包括从所述医疗设备服务器接收维护数据。
根据一个实施例，其中，所述维护数据包括更新的操作软件。
在另一个方面，公开了一种跟踪医用输液泵中改变的参数的方法。该方法包括建立医用输液泵和医疗设备服务器之间的通信会话，并且从医用输液泵向医疗设备服务器传送初始参数值、更新参数值和最终参数值。该方法还包括在医疗设备服务器上存储原始参数值、更新参数值和最终参数值。与一个或者更多个参数值关联的元数据将该参数值识别到医疗设备服务器和医用输液泵。
根据一个实施例的方法还包括将所述最终参数值与所述服务器上存储的软限制相比较。
根据一个实施例的方法还包括在确定所述最终参数值在所述软限制以外时，在所述医疗设备服务器中触发警报。
根据一个实施例的方法还包括将所述警报传递到所述医用输液泵。
根据一个实施例的方法还包括将所述警报传递到医疗看护者。
根据一个实施例的方法还包括将所述警报传递到能够发出视觉或听觉警报的设备。
根据一个实施例的方法还包括在确定所述最终参数值在所述软限制以外时，将所述参数值存储在所述医疗设备服务器上的事件日志数据中。
根据一个实施例的方法还包括将所述最终参数值与所述服务器上存储的硬限制相比较。
根据一个实施例的方法还包括在确定所述最终参数值在所述硬限制以外时，在所述医疗设备服务器中触发警报。
根据一个实施例的方法还包括将所述警报传递到所述医用输液泵。
根据一个实施例的方法还包括将所述警报传递到医疗看护者。
根据一个实施例的方法还包括在确定所述最终参数值在所述硬限制以外时，将所述参数值存储在所述医疗设备服务器上的事件日志数据中。
在另一个方面，公开了一种用于跟踪医用输液泵中改变的参数的系统。该系统包括具有一个或更多个可编程参数的医用输液泵和通信连接到该医用输液泵的医疗设备服务器。该医疗设备服务器包括被配置为存储参数值的存储器和操作连接到该存储器的可编程电路。该可编程电路被配置为执行程序指令以建立医用输液泵和医疗设备服务器之间的通信会话，并且从该医用输液泵接收原始参数值、更新参数值和最终参数值。该可编程电路还被配置为执行程序指令以在存储器中存储初始参数值、更新参数值和最终参数值。与一个或者更多个参数值关联的元数据将该参数值识别到医疗设备服务器和医用输液泵。
根据一个实施例的方法还包括将所述最终参数值与所述服务器上存储的软限制相比较。
根据一个实施例的方法还包括在确定所述最终参数值在所述软限制以外时，在所述医疗设备服务器中触发警报。
根据一个实施例的方法还包括将所述警报传递到所述医用输液泵。
根据一个实施例的方法还包括将所述警报传递到医疗看护者。
根据一个实施例的方法还包括将所述警报传递到能够发出视觉或听觉警报的设备。
根据一个实施例的方法还包括在确定所述最终参数值在所述软限制以外时，将所述参数值存储在所述医疗设备服务器上的事件日志数据中。
根据一个实施例的方法还包括将所述最终参数值与所述服务器上存储的硬限制相比较。
根据一个实施例的方法还包括在确定所述最终参数值在所述硬限制以外时，在所述医疗设备服务器中触发警报。
根据一个实施例的方法还包括将所述警报传递到所述医用输液泵。
根据一个实施例的方法还包括将所述警报传递到医疗看护者。
根据一个实施例的方法还包括在确定所述最终参数值在所述硬限制以外时，将所述参数值存储在所述医疗设备服务器上的事件日志数据中。
在另一方面，公开了一种用于跟踪医用输液泵中改变的参数的系统。该系统包括多个医用输液泵，每个泵具有一个或更多个可编程的参数。该系统还包括通信连接到多个医用输液泵的医疗设备服务器。该医疗设备服务器包括被配置为存储参数值的存储器和操作连接到该存储器的可编程电路。该可编程电路被配置为执行程序指令以建立医用输液泵之一和医疗设备服务器之间的通信会话，并且从医用输液泵接收原始参数值、更新参数值和最终参数值。该可编程电路还被配置为执行程序指令以在存储器中存储原始参数值、更新参数值和最终参数值。与一个或者更多个参数值关联的元数据将该参数值识别到医疗设备服务器和医用输液泵。
在另一方面，公开了一种医疗设备服务器。该医疗设备服务器包括被配置为存储患者状态信息和命令信息的存储器以及操作连接到该存储器的可编程电路。该可编程电路被配置为执行程序指令以从第一医疗设备接收与患者有关的患者状态信息并确定对患者进行治疗的需要。该可编程电路还被配置为执行程序指令以将命令发送到被配置为提供治疗的第二医疗设备。
根据一个实施例，其中，发送命令发生在确认需要所述治疗时。
根据一个实施例，其中，确认需要所述治疗包括从看护者接收授权以继续进行由所述医疗设备服务器确定的治疗。
根据一个实施例，其中，发送命令发生在由所述服务器确定所述患者需要治疗时。
根据一个实施例，其中，所述第一医疗设备是患者监视器。
根据一个实施例，其中，所述第二医疗设备是医用输液泵。
根据一个实施例，其中，发送命令包括向医用输液泵发送一组泵参数。
根据一个实施例，其中，所述可编程电路还被编程为向第三医疗设备发送命令。
根据一个实施例，其中，对所述第二医疗设备编程包括对所述第二医疗设备编程以显示建议消息。
在另一个方面，公开了一种对医疗设备编程的方法。该方法包括从第一医疗设备接收患者状态信息，患者状态信息与患者有关。该方法还包括由医疗设备服务器确定对患者进行治疗的需要。该方法还包括对能够对患者实施治疗的第二医疗设备的编程。
根据一个实施例，其中，对所述第二医疗设备编程发生在确认需要所述治疗时。
根据一个实施例，其中，确认需要所述治疗包括从看护者接收授权以继续进行由所述医疗设备服务器确定的治疗。
根据一个实施例，其中，发送命令发生在由所述服务器确定所述患者需要治疗时。
根据一个实施例，其中，所述第一医疗设备是患者监测器。
根据一个实施例，其中，所述第二医疗设备是医用输液泵。
根据一个实施例，其中，发送命令包括向医用输液泵发送一组泵参数。
根据一个实施例的方法还包括向第三医疗设备发送命令。
根据一个实施例，其中，对所述第二医疗设备编程包括对所述第二医疗设备编程以显示建议消息。
在另一个方面，公开了一种医疗设备网络。该医疗设备网络包括多个医疗设备和操作连接到该多个医疗设备的医疗设备服务器。该医疗设备服务器包括被配置为存储患者状态信息的存储器和操作连接到该存储器的可编程电路。该可编程电路被配置为执行程序指令以从多个医疗设备中的第一医疗设备接收患者状态信息并且确定对患者进行治疗的需要。该可编程电路还被配置为执行程序指令以在确认需要治疗时将命令发送到多个医疗设备中的被配置为提供治疗的第二医疗设备。
根据一个实施例，其中，对所述第二医疗设备编程发生在确认需要该治疗时。
根据一个实施例，其中，确认需要该治疗包括从看护者接收授权以继续进行由所述医疗设备服务器确定的治疗。
在另一个方面，公开了一种确定医疗设备的在线状态的方法。该方法包括在预定时间段内等待来自医疗设备的通信，并且确定是否在预定时间段内从医疗设备接收到了消息。该方法还包括基于该确定步骤为医疗设备设立在线状态。
根据一个实施例，其中，如果在所述预定时间段内接收到消息，则确定所述医疗设备的在线状态包括确定所述医疗设备的在线。
根据一个实施例，其中，如果在所述预定时间段内没有接收到消息，则确定所述医疗设备的在线状态包括确定所述医疗设备的离线。
根据一个实施例的方法还包括使用所述消息中接收到的信息更新医疗设备服务器中的数据记录。
根据一个实施例的方法还包括基于所述消息中接收到的信息更新从医疗设备服务器输出的数据。
根据一个实施例，其中，所述消息包括由服务器从所述医疗设备接收的数据。
根据一个实施例，其中，所述消息包括医疗设备状态信息。
根据一个实施例的方法还包括基于所述医疗设备的所述在线状态更新工作站上的显示。
根据一个实施例，其中，所述工作站被配置为显示由所述医疗设备服务器接收的并且与所述医疗设备有关的遥测数据。
根据一个实施例，其中，所述医疗设备是医用输液泵。
根据一个实施例，其中，接收所述消息包括从所述医疗设备接收遥测数据。
在另一个方面，公开了一种医疗设备服务器，其包括被配置为存储关于医疗设备的在线状态信息的存储器和操作连接到该存储器的可编程电路。该可编程电路被配置为执行程序指令以在预定时间段内等待来自医疗设备的通信并确定是否在预定时间段内从医疗设备接收到了消息。该可编程电路还被配置为执行程序指令以基于该确定步骤为医疗设备设立在线状态。
根据一个实施例，其中，所述可编程电路还被编程为如果在所述预定时间段内接收到消息，则确定所述医疗设备在线。
根据一个实施例，其中，所述可编程电路还被编程为如果在所述预定时间段内没有接收到消息，则确定所述医疗设备离线。
根据一个实施例，其中，所述消息包括医疗设备状态信息。
根据一个实施例的医疗设备服务器还包括基于所述医疗设备的所述在线状态更新工作站上的显示。
根据一个实施例，其中，所述工作站被配置为显示由所述医疗设备服务器接收的并且与所述医疗设备有关的遥测数据。
根据一个实施例，其中，所述医疗设备是医用输液泵。
根据一个实施例，其中，接收所述消息包括从所述医疗设备接收遥测数据。
根据一个实施例，其中，所述可编程电路还被编程为使用所述消息中接收的信息来更新医疗设备服务器中的数据记录。
根据一个实施例，其中，所述可编程电路还被编程为基于所述消息中接收的信息来更新从医疗设备服务器输出的数据。
在另一个方面，公开了一种传送医疗设备的在线状态的方法。该方法包括在第一时刻发起与医疗设备服务器的通信，以及通过在第二时刻发起与医疗设备服务器的通信来建立在线状态，第二时刻在距离第一时刻的预定时间段内。
根据一个实施例，其中，所述医疗设备是医用输液泵。
根据一个实施例的方法还包括在发起与所述医疗设备服务器的通信时向所述医疗设备服务器传递事件日志数据。
根据一个实施例的方法还包括在发起与所述医疗设备服务器的通信时，向所述医疗设备服务器传递医疗设备状态信息。
在另一个方面，公开了一种同步医疗设备和医疗设备服务器之间的时钟的方法。该方法包括在通信连接到医疗设备的医疗设备服务器上维护服务器时间值，以及将服务器时间值从医疗设备服务器发送到医疗设备，该医疗设备保持设备时间值。该方法还包括用服务器时间值替换设备时间值。
根据一个实施例，其中，所述服务器时间值是基于所述世界时间协议的。
根据一个实施例，其中，所述设备时间值表示所述医疗设备所位于的时区。
根据一个实施例的方法还包括转换所述服务器时间值以反映所述医疗设备所位于的所述时区。
根据一个实施例，其中，转换所述服务器时间值发生在将所述设备时间值替换为所述服务器时间值之前。
根据一个实施例，其中，转换所述服务器时间值发生在将所述服务器时间从所述医疗设备服务器发送到所述医疗设备之前。
根据一个实施例的方法还包括在替换所述设备时间值时从所述医疗设备向所述医疗设备服务器发送确认信号。
根据一个实施例，其中，发送所述服务器时间值响应于来自所述医疗设备的请求而发生。
根据一个实施例，其中，所述医疗设备是医用输液泵。
在另一个方面，公开了一种医疗设备时间同步系统。该系统包括被配置为维护设备时间值的医疗设备和通信连接到该医疗设备的医疗设备服务器。该医疗设备服务器包括被配置为存储服务器时间值的存储器和操作连接到该存储器的可编程电路。该可编程电路被配置为执行程序指令以维护服务器时间值并将服务器时间值发送至医疗设备。该医疗设备还被配置为在接收到服务器时间值时用服务器时间值替换设备时间值。
根据一个实施例，其中，所述服务器时间值是基于所述世界时间协议的。
根据一个实施例，其中，所述设备时间值代表所述医疗设备所位于的时区。
根据一个实施例，其中，所述医疗设备服务器和所述医疗设备位于不同的时区中。
根据一个实施例，其中，所述医疗设备被配置为在将所述设备时间值替换为所述服务器时间值之前转换所述服务器时间值以反映所述医疗设备所位于的时区。
根据一个实施例，其中，所述医疗设备服务器被配置为在将所述服务器时间值发送到所述医疗设备之前转换所述服务器时间值以反映所述医疗设备所位于的时区。
根据一个实施例，其中，所述医疗设备被配置为在替换所述设备时间值时向所述医疗设备服务器发送确认信号。
根据一个实施例，其中，所述可编程电路被编程为响应于来自所述医疗设备的请求将所述服务器时间值发送至所述医疗设备。
根据一个实施例，其中，所述医疗设备是医用输液泵。
在另一个方面，公开了一种同步多个医疗设备和医疗设备服务器之间的时钟的方法。该方法包括在通信连接到多个医疗设备的医疗设备服务器上维护服务器时间值。该方法还包括将服务器时间值从医疗设备服务器发送到医疗设备，每个医疗设备维护设备时间值。该方法还包括用服务器时间值替换每个医疗设备的设备时间值，以及接收从医疗设备到医疗设备服务器的确认信号。
根据一个实施例，其中，所述医疗设备位于多个不同的时区中。
在另一个方面，公开了一种软件开发工具包。该工具包包括包含允许用户定义与医疗设备的一个或更多个特性有关的元数据的计算机可读指令的医疗设备安装软件。该工具包还包括数据包传送软件，其包括被配置为将数据包从服务器传送到医疗设备的计算机可读指令。该工具包还包括服务器软件，其包含用于在医疗设备服务器上执行的计算机可读指令，该服务器软件被配置为控制从服务器到医疗设备的通信。
根据一个实施例，其中，所述医疗设备是医用输液泵。
根据一个实施例的工具包还包括关于所述医疗设备安装软件、所述数据包传送软件或所述服务器软件的一个或更多个的使用的用户可读文件。
根据一个实施例的工具包还包括可以集成到所述医疗设备服务器或医疗设备中的一个或更多个消息模式，所述消息模式被配置为提供所述医疗设备服务器和所述医疗设备之间的通信。
根据一个实施例，其中，所述消息模式包括通信协议和元数据。
根据一个实施例，其中，使用所述医疗设备安装软件生成所述元数据。
根据一个实施例，其中，所述数据包包括：包括用于改变所述医疗设备的操作的数据的信息，所述信息具有数据结构；包括经加密的大小信息并且缺少关于所述数据包的内容的信息的服务器可读头；以及包括与所述信息有关的数据结构信息和解密信息的供应商定义头。
根据一个实施例，其中，所述医疗设备安装软件包含可以在医疗设备服务器上执行的计算机可读指令，所述计算机可读指令被配置为允许用户：将元数据与多个医疗设备的每个关联，所述元数据对应于所述医疗设备共有的至少一个属性；以及将所述元数据存储在服务器上，所述服务器被配置为通过使用所述元数据与每个所述医疗设备通信。
在另一个方面，公开了一种用于使得能够在医疗设备和医疗设备服务器之间进行通信的工具包。该工具包包括医疗设备安装软件，其包含允许用户定义与医疗设备的一个或者更多个特性有关的元数据的计算机可读指令，该医疗设备安装软件将元数据与医疗设备和医疗设备服务器的一个或者更多个特性关联。该工具包还包括数据包传送软件，该数据包传送软件包括被配置为将数据包从服务器传送到医疗设备的计算机可读指令，该数据包包含被配置为控制医疗设备的操作的计算机可读指令。该工具包还包括服务器软件，其包含用于在医疗设备服务器上执行的计算机可读指令，该服务器软件被配置为控制从服务器到医疗设备的通信。
根据一个实施例，其中，所述医疗设备是医用输液泵。
根据一个实施例的工具包还包括可以集成在所述医疗设备服务器或医疗设备中的一个或更多个消息模式，所述消息模式被配置为提供所述医疗设备服务器和所述医疗设备之间的通信。
根据一个实施例，其中，所述消息模式包括通信协议和元数据。
根据一个实施例，其中，使用所述医疗设备安装软件生成所述元数据。
根据一个实施例的工具包还包括关于所述医疗设备安装软件、所述数据包传送软件或者所述服务器软件的一个或更多个的使用的用户可读文件。
附图说明
图1示出了其中可以实施本发明的方面的示例性医疗设备网络；
图2是本发明的方面中可用的医疗设备的框图；
图3是用于医疗设备网络的软件架构的图；
图4是用于医疗设备网络的第二软件架构的图；
图5是用于远程管理由多个实体控制的医疗设备的方法和系统的流程图；
图6是用于基于服务器的医疗设备控制的方法和系统的流程图；
图7是医疗设备的远程控制的可能状态的状态图；
图8是医疗设备网络中使用的消息系统的功能图；
图9是用于医疗设备和医疗设备服务器之间的通信的方法和系统的流程图；
图10是用于医疗设备和医疗设备服务器之间的通信的另外的方法和系统的流程图；
图11至图16是包括可用于帮助医疗设备和医疗设备服务器的可扩展通信系统的元数据的数据模型；
图17是用于过滤医疗设备事件的方法和系统的流程图；
图18是用于管理医疗设备的维护的方法和系统的流程图；
图19至图24是包括可用于跟踪医疗设备中发生的事件的事件元数据的数据模型；
图25是被格式化以用于从医疗设备服务器向一个或者更多个医疗设备的传输的数据包的图；
图26是用于传送图25的数据包的方法和系统的流程图；
图27至图32是包括可用于帮助从医疗设备服务器到医疗设备的数据包传送的元数据的数据模型；
图33是包括可用于同步医疗设备网络中的时间的元数据的示意图；
图34是用于医疗设备网络中医疗设备的同步的方法和系统的流程图；
图35是用于事件日志数据的时间调整的方法和系统的流程图；
图36是根据本发明的可能的实施例的医疗设备服务器的功能单元的框图；
图37是医疗设备服务器管理系统的框图；
图38是可以从医疗设备服务器访问的实例医疗设备管理事件跟踪报告；
图39是可以从医疗设备服务器访问的实例安全事件跟踪报告；
图40是可以从医疗设备服务器访问的实例安全事件倾向报告；
图41是可以从医疗设备服务器访问的实例用户历史报告；
图42是用于医疗设备元数据的管理的用户界面；
图43是用于医疗设备元数据的安装的另一个用户界面；
图44是用于医疗设备网络中数据包分发的管理的用户界面；
图45是用于向医疗设备网络中的医疗设备部署数据包的另一个用户界面；
图46是确认向医疗设备的数据包部署的用户界面；
图47是指示从医疗设备服务器到医疗设备的错误数据传输的实例隔离报告；
图48是与图47的隔离报告相对应的实例详细隔离报告；
图49是显示从医疗设备服务器到医疗设备的数据包部署的实例包部署报告；
图50是显示从医疗设备服务器到医疗设备的错误数据包部署的实例包部署错误报告；
图51是显示医疗设备维护事件的实例维护报告；
图52是显示传递到医疗设备服务器的医疗设备故障的实例医疗设备故障报告；
图53是显示传递到医疗设备服务器的医疗设备故障的倾向的实例医疗设备故障倾向报告；
图54是用于从医疗设备服务器向医疗设备传递参数改变的方法和系统的流程图；
图55是包括来自医疗设备服务器的可用于帮助医疗设备的基于治疗的编程的元数据的示意图；
图56是用于医疗设备的基于治疗的编程的示例消息序列；
图57是用于跟踪传递到医疗设备服务器的改变的医疗设备参数的方法和系统的流程图；
图58是显示从医疗设备传递到医疗设备服务器的事件日志数据的实例医疗设备历史报告；
图59是显示从医疗设备传递到医疗设备服务器的治疗事件日志数据的实例治疗历史报告；
图60是显示根据从医疗设备传递到医疗设备服务器的治疗事件日志数据得出的治疗倾向的实例治疗倾向报告；
图61是显示从医疗设备传递到医疗设备服务器的治疗事件日志数据中的治疗的改变的实例治疗改变历史报告；
图62是显示根据从医疗设备传递到医疗设备服务器的治疗事件日志数据得出的治疗改变倾向的实例治疗改变倾向报告；
图63是用于确定医疗设备的在线状态的系统和方法的流程图；
图64是用于从医疗设备收集遥测数据的系统和方法的流程图；
图65是用于从医疗设备接收遥测数据的示例消息序列；
图66是包括可用于帮助从医疗设备到医疗设备服务器传递遥测数据的元数据的示意图；以及
图67是可用于显示与一个或更多个医疗设备有关的遥测数据的示例仪表板。
具体实施方式
将参照附图详细描述本发明的各个实施例，其中在几个附图中相同的附图标记代表相同的部件和组件。对各个实施例的引用不限制本发明的范围，本发明的范围仅由这里所附的权利要求限定。此外，本说明书中所列出的任何示例均不旨在是限制性的，而是仅仅列出了所要求保护的发明的多个可能的实施例中的一些。
这里所描述的本发明的各个实施例的逻辑操作实施为：（1）在计算机中的可编程电路上运行的一系列计算机实现的步骤、操作或过程；（2）在医疗设备中的可编程电路上运行的一系列计算机实现的步骤、操作或过程；和／或（3）可编程电路中的互连机器模块或程序引擎。
这里给出的描述讨论医疗设备网络中的各种医疗设备和医疗设备服务器的使用和编程。本领域的技术人员将理解很多种医疗设备用于管理对用户的治疗，诸如医用输液泵、脉搏血氧计、心肺监测器和其它治疗提供设备和患者监测设备。这些和其它的医疗设备可以用于本发明的医疗设备网络中。在本发明的各个方面中，术语医疗设备服务器指的是计算系统和用于系统的各其它部件的协作的消息处理和存储服务。此外，在医疗设备的上下文中术语“用户”通常适用于接受治疗的人。在很多其它上下文中，诸如医疗设备服务器的使用的上下文等，用户也可以指诸如操作医疗设备的看护者的任何其他人或者能够访问关于医疗设备的信息的计算机。
此外，本发明中考虑的医疗设备和互连的计算系统生成并且在用户界面和报告（也称作显示器）中显示信息和字段（field）。用户界面和报告可以包括字段、字母／数字字符串、时间和日期。字段（也称作单元）提示用户录入和/或选择信息。在各种计算系统和医疗设备上有各种类型的输入和显示设备可用。
本发明包含的各种类型的医疗设备执行或利用操作参数，操作参数定制或者个人化计算机实现的步骤、机器模块和程序的操作以满足各个医疗设备用户的要求。操作参数可以是数值、文本串、标记、自变量名称或者用户或看护者可以设置以控制医疗设备的操作的医疗设备编程的任何其它方面。在本发明的某些方面中，元数据向服务器和与医疗设备接口的其它计算系统指示医疗设备中各个操作参数的能力的文本定义。
I．硬件环境
一般地参照图1和2，描述一般化的硬件环境。图1示出了可以实施本发明的方面的示例性医疗设备网络100。医疗设备网络100提供一种方法，多个医疗设备和通信系统可以通过该方法相互通信。医疗设备网络100包括与多种类型的医疗设备互连的医疗设备服务器102。医疗设备可以包括主动医疗设备104、被动医疗设备106和被示出为医用输液泵108的多个示例性医疗设备。
主动医疗设备104指的是被配置为协助管理对患者的治疗的多个医疗设备中的任意一个。主动医疗设备包括用于传送流体治疗的医用输液泵或者其它提供治疗的装置。在一个实施例中，主动医疗设备104是诸如示出的医用输液泵108的医用输液设备。
被动医疗设备106指的是被配置为监测患者的状态而不主动地协助管理对该患者的治疗的多个观察设备中的任意一个。被动医疗设备的示例包括脉搏血氧计、心肺监测器或用于测量患者的生命体征（诸如呼吸、心率和心节律、血氧水平和其它健康指标）的其它患者观察系统。
医疗设备服务器102与医疗设备通信，并且是一个或更多个通用或专用计算系统。医疗设备服务器102被配置为存储和检索从各个医疗设备104、106、108接收的数据。医疗设备服务器102接收的数据可以包括事件日志数据、编程数据和从医疗设备104、106、108发送到服务器102的各种其它数据。
可选地，医疗设备网络100包括诸如工作站110和便携式计算系统112的被配置为允许通信连接到医疗设备服务器102的附加计算设备。工作站110和便携式计算系统112是具有允许访问医疗设备服务器的通信接口的通用计算系统或者瘦客户计算系统。工作站110和便携式计算系统112通常包括输入设备和显示器，以便当用户（即看护者）与患者不在同一地点时允许用户访问关于该患者的数据。用户可以经由工作站110或者便携式计算系统112访问医疗设备服务器102以检索从医疗设备收集的数据，并且可以指示医疗设备服务器102向一个或更多个医疗设备传递各种消息或软件包。
医疗设备网络100可选地包括网络基础设施部件，诸如开关114和无线接入节点116。网络基础设施部件被配置为提供各种医疗设备104、106、108、医疗设备服务器102和任何附加的计算系统110、112之间的通信基础设施。虽然医疗设备网络100需要网络中包括的各个部件之间的通信渠道，但是包括在给定医疗设备网络中的具体部件将根据医疗设备网络的特定基础设施和用户的需求而变化。因此，开关114和无线接入节点116旨在作为网络的各个部件之间的通信互连的实施的示例性部件。网络100中也可以采用其它类型的医疗设备、计算系统或网络部件。
图2示出了医疗设备200的示例性框图。医疗设备200是用于患者的治疗管理或者监测的多种类型的主动或被动医疗设备的任意一种。在一个可能的实施例中，医疗设备200是被配置为给患者注射药物和其它流体治疗的医用输液泵。其它类型的医疗设备也是可能的。
医疗设备200包括与存储器子系统接口的可编程电路202，存储器子系统包括例如随机存取存储器（RAM）204、闪存206和电可擦除可编程存储器（EEPROM）208。RAM 204存储医疗设备的操作参数以及关于操作数据或者指令的任何非关键存储。闪存206存储定义诸如泵程序、那些泵程序中所用的泵参数等泵操作的指令和/或数据存储或其它系统固件。EEPROM 208存储医疗设备200所用的并且在诸如由于断电、电池无电或其它未预料的事件引起的设备故障的情况下必须被保存的一组初始指令。EEPROM 208可选地包括在必要时可以被读取或复制到RAM204或闪存206中以运行的固件或指令。
在医疗设备200的各个实施例中，所用的存储器子系统的各个部件由医疗设备的需要支配。在某些设备中，不存在这里描述的存储器系统部件的一个或更多个。在这种设备中，设备中存储的数据和指令的一些或全部可以被存储在设备中存在的存储器子系统的另一个部件中。RAM也可以暂时地提供对关键操作数据或指令的存储。另外，可以提供可替选实施例，其中之前所述的闪存的内容和EEPROM存储器的内容可以互换，或者其中该内容可以完全存储在一种类型的非易失性存储器中而不存储在其它类型的存储器中。最后，可以替代地使用其它类型的非易失性存储器，诸如铁电存储器或者其它存储器。
医疗设备200还包括电池系统210，其被配置为当设备不能插入到墙壁电源出口或者某些其它AC电源时向医疗设备提供直流电源。在一个实施例中，电池系统210包括被配置为提供电源管理并根据AC电源的存在在DC和AC供电模式之间进行智能切换的可再充电锂离子智能电池系统。在另外的实施例中，电池系统210包括不同类型的电池系统，诸如包括镍‑镉电池的可再充电电池系统等。
医疗设备200包括连接到可编程电路202的输入设备212和输出设备214。输入设备212允许位于医疗设备处的用户调整设备的活动。输入设备212可以是例如鼠标、键盘、小键盘、轨迹球、触摸屏、控制按钮或其它用户可控制的设备。输出设备214可以是被配置为向设备外的用户和设备提供关于医疗设备的信息的任何类型的音频、视频或数据界面。在各种实施例中，输出设备214可以是到第二医疗设备的数据接口，或者可以是到外部监测器的连接，用于向用户显示关于医疗设备200的状态的信息。
医疗设备200还包括显示设备216和警报器218。显示设备216是能够向设备的用户显示信息的可视化设备。在医疗设备200的各种实施例中，显示设备216例如可以是诸如LCD、CRT或其它屏幕的显示设备。其它类型的显示设备也是可能的。此外，虽然医疗设备被示出为包括显示设备216，但是在替选实施例中不需要显示设备。警报器218可以被配置为向用户提供在用户或设备中检测的各种状况的各种类型的听觉指示。这些状况包括诸如不正常的低或高的心率或呼吸率的被检测到的健康状况，或者诸如指示药物供应快要用尽或者设备可能需要维护等与设备有关的警报。可选地，警报器基于除这里所列的之外的其它警报条件进行触发；所选择的警报通常与所实施的医疗设备的类型和设备所处状况有关。
有线通信接口220提供从与医疗设备服务器或其它通用计算设备连接的医疗设备200的数据通信连接。有线通信接口220与可编程电路202连接，并且从医疗设备200发送和接收数据。在各个实施例中，有线通信接口220可以是能够传递和接收数字数据的以太网或其它数据连接。
无线通信接口222提供有线通信接口220的可选通信接口，以使得当有线连接不可用或者不方便时医疗设备200可以基于该医疗设备的位置保持与医疗设备服务器或者其它计算系统的数据通信。无线通信接口222连接到可编程电路202，并且从医疗设备无线地发送和接收数据。对有线或无线通信接口之一或其两者的使用取决于医疗设备的位置和与医疗设备服务器的通信的需要。在一个实施例中，医疗设备向一个或两个接口提供持续数据流，从而访问医疗设备服务器的个体能够持续跟踪医疗设备的状态。在另外的实施例中，医疗设备周期性地或间歇地激活和/或使用一个或两个接口通信，以便更新医疗设备或医疗设备服务器保持的操作数据或其它信息。
医疗设备200还包括患者接口224。患者接口224控制监测或对用户提供的治疗的医疗设备200的机械部件。患者接口224根据设备的功能在不同类型的医疗设备间不同。在医疗设备200是监测器的情况下，患者接口224可以包括传感器或者其它物理检测装置。在医疗设备200是医用输液泵的情况下，患者接口可以包括驱动机械装置、闭塞传感器、流量传感器或者其它的药物控制或传送接口。其它医疗设备和相应的患者接口也是可能的。根据设备所针对的特定应用，所示出的部件以外的其它部件也可以包括在医疗设备200的各个实施例中。
II．整体软件环境
图3至图6示出了根据本发明的各个实施例的医疗设备网络100的整体软件环境及其部件。在两个部分中讨论这里公开的软件环境：（1）出现在第III部分中的与医疗设备和医疗设备服务器之间的通信有关的那些方面；以及（2）出现在第IV部分中的包括用户与医疗设备网络相互作用的方面，诸如查看与医疗设备活动有关的数据或者管理对医疗设备网络的改变或添加等。两个方面一般涉及医疗设备网络中医疗设备的协调，前面在图1至图2中描述了该医疗设备网络的主要物理特征。
这里所公开的包括第II‑IV部分中描述的元数据安装软件、包部署软件和服务器软件的各种软件下面可以用多种方式打包，并且针对多种不同的医疗设备网络进行组织。在一个可能的实施例中，各个软件方面包含在包括这里所描述的各种软件部件的一些或全部的软件开发工具包（SDK）中。在这种实施例中，医疗设备可以包括监测器和医用输液泵，并且软件可以包括可以在医疗设备和医疗设备服务器上使用的预先打包的元数据文件。也可以包括关于该软件的用户可读的文件。
此外，这里公开的和下面要求保护的各种软件可以包括在图1至图2的硬件环境中可操作的多种类型的计算系统的任意一种上。例如，计算设备通常包括至少某种形式的计算机可读介质。计算机可读介质可以是计算系统可以访问的任何可用介质。作为示例而不是限制，计算机可读介质可以包括计算机存储介质和通信介质。
计算机存储介质包括用任何方法和技术实现的用于存储诸如计算机可读指令、数据结构、程序模块或其它数据的易失性的和非易失性的、可移动的和不可移动的介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD‑ROM、数字多功能盘（DVD）或者其它光学存储器、磁盒、磁带、磁盘存储器或者其它磁存储设备、或者任何其它可以用于存储期望的信息并且可以由计算机系统访问的介质。
通信介质通常包括计算机可读指令、数据结构、程序模块或者以诸如载波或者其它传输机制的调制数据信号中的其它数据，并且包括任何信息传送介质。术语“调制数据信号”指的是在信号中以对信息编码的方式设置或改变其一个或者更多个特性的信号。作为示例而不是限制，通信介质包括诸如有线网络或直接线连接等的有线介质和诸如声音、RF、红外和其它无线介质等的无线介质。以上的任何组合也应该包括在计算机可读介质的范围内。计算机可读介质也可以称为计算机程序产品。
图3示出其中实施了本发明的方面的软件架构300。软件架构300提供操作环境，其中可以距离医疗设备远程地存储和管理医疗设备数据。软件架构300还提供扩展结构，其中多种类型的医疗设备可以工作。软件架构300使用与多个医疗设备通信连接的一个或更多个计算系统工作，并且其可配置为跨多个位置和不同商业实体工作。软件架构300在包括一个或更多个医疗设备和医疗设备服务器的医疗设备网络中工作。以上在图1中描述了软件架构在其中工作的医疗设备网络的可能配置。
在一个实施例中，使用微软公司发布的微软SQL Server 2005的关系和商业智能部件实现软件架构300的方面。在这种实施例中，可以使用诸如微软互联网信息服务（IIS）平台的web服务提供诸如web界面等的各种模块。在另外的可能的实施例中，采用微软SQL Server 2000、Oracle或其它数据库管理和商业智能产品，结合诸如基于Apache或者其它web服务器的各种web服务实现系统的方面。
软件架构300包括一个或者更多个医疗设备302、后台部件304和客户应用306。医疗设备302监测患者或向患者提供如看护者所进行的治疗。医疗设备302可以是诸如以上结合图1至图2讨论的多种可编程医疗设备的任何一个。
后台部件304包括一个或更多个医疗设备服务器308、管理模块310、事件跟踪模块312和操作模块314。医疗设备服务器308诸如通过在各种模块310、312、314和医疗设备302之间传递消息来管理和与后台部件304相关联的各种医疗设备302的通信。医疗设备服务器308创建医疗设备302和各种模块310、312、314可以理解的消息，以使得可以使用这些模块管理多种类型的医疗设备。采用发送到医疗设备302的消息，医疗设备服务器308从医疗设备收集历史信息、使各种维护操作自动化、协助用户床边的治疗设置并且提供医疗设备监测。在可能的实施例中，医疗设备服务器308诸如通过经由SOAP或另外的消息传递协议使用XML或者某种其它类型的元数据或标记语言来管理用于与多种类型的医疗设备通信的基于元数据的消息系统。
在一个可能的实施例中，医疗设备服务器308存在于计算系统，该计算系统还托管其它后台部件304。在另一个实施例中，医疗设备服务器存在于与其它后台部件分离的计算硬件上。在这种系统中，医疗设备服务器308可以被置于与其它后台部件不同的位置，或者可以由与其它后台部件不同的实体进行管理，如下面的图4至图5所述。为了简明，贯穿对软件方面的描述，根据所选择的具体实施，术语医疗设备服务器旨在包括医疗设备服务器308或者作为整体包括后台部件304。在某些实施例中，医疗设备服务器308可以被置于一个或更多个物理计算平台上，导致存在多个医疗设备服务器。
管理模块110提供到管理数据316的接口，医疗设备服务器308和客户应用306可以因为各种理由（诸如下面描述的为了允许访问事件或操作数据）请求管理数据316。管理数据316包括诸如用户名、密码、IP认证或者其它用户验证的用户验证信息，以及限定与该用户相关联的访问权限的权限信息。例如，管理数据316可以将用户名和密码关联，并且要求用户提供正确的用户名和密码以接收验证权限。用户名和密码信息转而可以与访问权限信息相关联，访问权限信息限定对该用户允许的特定数据类别、医疗设备的子集或者命令类型。其它的访问权限可以在管理数据316中定义并且也由管理模块310管理。
管理数据316还通过定义操作参数来定义环境300中管理的各种医疗设备302的能力，医疗设备服务器308通过该操作参数与医疗设备302连接。例如，被配置为监测患者的医疗设备可以包括与监测功能有关的多种定义的参数，但是将不包括与提供治疗有关的参数。在通过设置管理数据中的操作参数以允许多种可能的医疗设备能力的用户定义时，环境300提供一组用户可扩展的后台部件，该组后台部件可以用具有各种能力的、由不同的实体制造的并且在不同位置使用的多种医疗设备来配置。
在特定实施例中，管理模块310生成可以访问多种用户应用界面的web界面以远程验证希望访问一个或更多个后台部件304中保持的数据的用户或看护者。在另一个实施例中，管理模块提供允许远程应用访问由后台部件304管理的数据的界面。
事件跟踪模块312提供到医疗设备服务器308的接口，并且组织和管理事件数据318。事件数据318对应于关于医疗设备302中发生的各种事件的历史数据，其由医疗设备服务器308收集并路由。事件数据318将医疗设备标识符与事件标识符和关于该医疗设备中发生的事件的附加描述信息相关联。使用事件跟踪模块312跟踪的事件的示例包括各种医疗设备中的电源事件、警报事件、维护事件、遥测事件、治疗事件或治疗改变事件。下面结合图19至图24讨论各种事件和用于跟踪这些事件的方案的示例。在特定实施例中，事件跟踪模块312生成可以由医疗设备服务器308访问的web界面以将数据传输至事件数据318的存储位置。
操作模块314管理系统的各种操作特性，诸如系统操作信息、治疗命令、维护工作和用于影响与环境300相关联的各种医疗设备302的操作的其它信息。操作模块314还提供到医疗设备服务器308的web接口以用于管理各种类型的操作数据320，以及到各种外部计算系统的web接口以允许那些系统查看操作数据320并且将软件架构300内的命令发送到诸如各种医疗设备302。
可选的数据仓库322集合并整理包括管理数据、事件数据和操作数据的各种预定的和收集的数据，以供各种客户应用使用。在所示出的实施例中，报告应用从集合来自管理数据316、事件数据318和操作数据320的各种数据的数据仓库322接收数据。数据仓库322提供可用于基于一个或更多个这些类型的数据生成报告的便利的静态库。下面结合第IV部分中描述的用户到服务器通信系统描述示例报告。可以采用多个相关或者在线分析处理产品（诸如SQL Server Analysis Services、Hyperion Essbase、Oracle OLAP或者其它被配置为允许查询或访问数据的各种组合的数据存储器）中的任何一种来形成数据仓库322。对于没有可选的数据仓库322的那些实施例来说，这里所描述的其功能可以由管理、事件跟踪、操作数据库及它们对应的模块提供，如这里所述。
客户应用306通常访问数据源316、318、320、322中的一个或更多个以生成向看护者或者其他用户指示关于看护者或用户可访问的医疗设备的当前和历史信息的用户输出表。访问后台部件304的客户应用306包括管理应用324、报告应用326、仪表板328、维护表330和各种附加的外部应用332。
管理应用324向用户提供对包括多种管理web表的管理数据316的访问，以定义针对试图访问后台部件304的其他用户的使用权限，以及定义医疗设备302的操作参数。也可以包括其它的管理web表。
报告应用326基于管理数据316、事件数据318和操作数据320提供多个标准报告。在后台部件304包括数据仓库322的实施例中，报告可以基于数据仓库中的信息。采用后台部件304中跟踪的各种类型的数据而建立的报告的示例包括安全报告、用户历史、软件部署报告、医疗设备编程报告、维护报告、设备历史报告、治疗报告和其它报告。下面的第IV部分中描述了报告的另外的示例。
仪表板328允许看护者或用户查看医疗设备302的状态。仪表板328基于操作数据并且连接到操作模块310。环境300中可用的仪表板328对应于能够频繁地向后台部件304发送数据的各种医疗设备302。仪表板328接收关于医疗设备的操作数据，诸如设备提供的最近的治疗。该信息反映在看护者或用户可以访问的计算系统的显示设备上显示的仪表板用户界面上。在一个可能的实施例中，仪表板328复制相应的医疗设备的视觉界面，但是以web入口的格式。
维护表330向看护者或医疗设备302的其他用户显示维护信息。维护表330显示操作数据320中包括的跟踪维护信息，诸如执行的维护、预定的维护、建议的维护和维护倾向等。维护表330还允许用户向医疗设备302部署各种更新，诸如固件更新和其它软件部署。在可能的实施例中，操作数据320包括可以由用户经由维护表访问的维护时间表信息。在这样的实施例中，维护表330向用户显示维护时间表，包括各种医疗设备302需要的未来的维护以及操作数据320中跟踪的历史维护事件。
各种外部应用332通过与操作模块314通信来扩展软件环境300的功能。外部应用332包括可以用于扩展软件环境300的功能的任何应用。
图4示出了图3中所示的软件架构的替代软件基础结构400，并且可以用于由除医疗设备工作处的设施以外的实体管理对来自医疗设备的数据的存储的情况。例如，医疗设备302和医疗设备服务器308可以存在于由诸如国家或私人实体的一个或更多个保健实体管理的一个或更多个医院或保健设施404处。但是，来自那些设备的数据的存储可以由健康管理组织或者订约的其它组织405来管理，以管理非现场位置处的各种设施的数据。实体能够从也位于该设施处的医疗设备服务器308收集信息，其继而将数据适当地传递至上述基于web的模块310、312、314之一。这样的设置允许医院将来自其医疗设备的数据集合在医疗设备服务器处，并且允许第三方来管理计算基础设施和执行与数据的长期存储、管理、访问和／或报告有关的维护任务。
图5示出了诸如图4中所示的用于管理软件基础设施的系统和方法，其中第三方处理与从位于多个位置或者用户地点处的多个保健组织中并且由其控制的医疗设备收集的数据有关的数据管理任务。图5的系统500内的操作流程在开始操作502开始，其对应于系统500的初始化，诸如通过操作连接到医疗设备服务器的各种医疗设备的操作。
数据接收模块504接收由诸如医院、诊所或者其它健康管理组织的一个或更多个实体管理的医疗设备生成的数据。在一个实施例中，数据接收模块504对应于来自医疗设备服务器或客户应用的各种管理数据、事件数据或操作数据的接收，如图4的后台部件304中所示。
关联模块506将数据接收模块504中接收的数据与从所接收的数据所来自于的医疗设备相关联。在一个可能的实施例中，关联模块506将数据与医疗设备位于的各个位置相关联，或者与控制该设备的各个实体相关联，如管理数据316中所定义的。数据关联可以是诸如可以在文件、表或数据库中找到的数据之间的逻辑关系或物理关系。
关联模块506准备数据，以便当来自特定医院或位置的用户寻求关于医疗设备的信息时，后台部件可以根据关联模块506的特定实施仅向用户提供关于与用户在同一位置或者与用户在同一实体内的医疗设备的信息。例如，单个医院或者医院的病房可以具有多种医疗设备，其数据由第三方收集和管理。在该医院或病房中工作的医生、护士或其他看护者可以从不是由该病房或医院控制的远程服务器访问与该病房中的特定医疗设备相关的信息。
可选程序模块508基于与该实体或位置有关的特定指令将数据或指令从后台部件分发至医疗设备。例如，医院或者病房可以请求对他们的医疗设备的软件更新，后台部件将医院请求的特定软件更新仅导引至该实体的设备或者仅导引至该特定类型的设备，而排除与后台部件相关联的或者由后台部件监测的其它设备。
在另外的示例中，医院或者其它保健位置处的工作站可以诸如通过执行以上数据接收模块504和关联模块506来查看关于该位置处的医疗设备的状况信息。在该示例中，工作站的用户可以可选地选择对医疗设备重新编程，并且可以通过向与用户关联的位置处的特定类型的所有医疗设备发出全局命令来完成重新编程。后台部件可以向适当的医疗设备服务器发送有必要向该位置的医疗设备分发的特定指令，而不向由后台部件管理的其它位置处的相同医疗设备发送那些指令。
操作流程终止于结束操作510，结束操作510对应于与一个或更多个医疗设备的通信会话的完成。
图6示出了图1的医疗设备网络内可运行的系统和方法，该医疗设备网络中医疗设备行动是互连的。系统600具体地与特定位置处的不同类型的医疗设备（诸如全部与单个患者相关联的一组医疗设备）的互连有关。系统600包括在医疗设备服务器或其它后台部件上运行的多个规则，以便基于由医疗设备服务器或者后台部件接收的使用第一医疗设备观察到的患者的活动来确定任何附加的可建议的治疗或者使用第二医疗设备进行的监测活动。
系统600内的操作流程以开始操作602开始，其对应于使用连接到医疗设备网络的多个医疗设备对患者进行的初始监测。开始操作602还可选地对应于接收与患者相关联的第一医疗设备记录在医疗设备服务器上的至少一个事件。
状态接收模块604从用于监测或者管理对患者的治疗的第一医疗设备接收该患者的状态。在一个示例中，状态接收模块604可以从与患者相关联的医疗设备接收该患者的状态。患者的状态可以包括心跳或呼吸的速率或规律性、患者正在经受疼痛的指示、患者的血糖水平、或者给予该患者的一个或更多个治疗的过程。患者的状态可选地还包括由监测或提供对该患者的治疗的医疗设备生成的警报。
确定模块606基于从第一医疗设备接收的患者的状态执行一个或更多个规则。该一个或更多个规则定义针对该患者是否需要另外的行动，诸如患者的另外或者改变的治疗或监测。确定模块606将各个规则与能够执行该改变的治疗的特定医疗设备相关联。只执行那些对应于当前对患者监测或提供治疗的起作用的医疗设备的规则。在确定模块606的执行的一个示例中，可以存在其中监测器感测或者被告知患者正在经历疼痛的情况。在这中情况中，执行一个或更多个规则以确定对于该患者而言疼痛管理治疗是否可用，并且如果这种治疗可用则确定要给予该患者的适当的治疗。例如，如果医用输液泵与该患者相关联，则确定模块606断定该泵能够提供疼痛管理治疗并且计算适当的泵参数以将适当的治疗提供给患者。
程序模块608产生对确定模块606中确定的能够提供改变的或者附加的治疗或监测的目标医疗设备的编程。程序模块608将治疗的改变或添加传递到患者的看护者可以访问的工作站或者能够管理治疗的医疗设备。在一个实施例中，编程模块608请求看护者同意确定模块606中确定的建议的治疗。在另一个实施例中，编程模块608直接对能够提供治疗的医疗设备编程，以使得可以提供治疗而不需要任何额外的看护者同意或干涉。
操作流程终止于结束操作610。结束操作610对应于医疗设备服务器完成将所确定的治疗传递给工作站或者医疗设备。
III．医疗设备到服务器的通信
图7至图35一般地描述了用于如图1至图2中所示的医疗设备和医疗设备服务器或者其它后台部件之间的通信的各种系统和方法。该部分中描述的系统和方法涉及可能跨越一个或更多个设施、组织、时区或其它逻辑实体的医疗设备网络中的医疗设备的协调。这些系统可以在下面的第IV部分中描述的用户与医疗设备网络相互作用的过程中使用，在该用户的牵涉中涉及医疗设备的协调以及对来自医疗设备网络中的医疗设备的数据的收集和通信。
现在参照图7至图8，描述了医疗设备服务器和多种类型的医疗设备之间的通信。医疗设备服务器和医疗设备所使用的通信方法提供了一种可扩展系统，其允许医疗设备服务器与由多种不同的医疗设备制造商制造的分别具有不同的通信协议、能力和其它特性的多种不同类型的医疗设备进行通信。
图7示出了示例性可扩展系统700，其中医疗设备服务器与远端设置的医疗设备相关联。系统700跟踪与医疗设备服务器相关联的医疗设备的状态，并且用于将新的现有的医疗设备与医疗设备服务器关联，以提供一种允许位于多个不同的医院或者医院内的位置处的多种类型和品牌的医疗设备的相互通信的可扩展医疗设备网络。在系统700中，被医疗设备服务器识别的每个医疗设备将具有保持在服务器上的表中的相关联的状态。因此，系统700将针对与服务器相关联的每个医疗设备在服务器上独立地执行。系统700以开始节点702开始，其对应于医疗设备到包括医疗设备服务器的医疗设备网络（诸如图1中所示的）的连接。
在连接医疗设备时，医疗设备服务器必须确定该医疗设备是否是已知的类型。如果该医疗设备是未知的类型，则操作流程前进到对应于接收关于该医疗设备的能力的信息的已知状态704，以使得该医疗设备能够被添加到医疗设备网络。已知状态704可以由描述医疗设备的操作能力的接收用户输入产生，或者可以包括医疗设备和医疗设备服务器之间的通信或者测试。当医疗设备服务器认为设备处于与已知状态704对应的已知状态时，医疗设备服务器将该医疗设备作为已识别的设备对待，但是其没有被供电或者以其它方式被系统识别。如果医疗设备是已知类型，则操作流程前进到对应于确定医疗设备的状态的确定节点706。
从医疗设备服务器的角度，四个操作状态定义医疗设备的操作：上电状态708、治疗状态710、故障状态712和警报状态714。上电状态708对应于通电并且正在进行正常操作而当前没有被用于监测或对患者提供治疗的医疗设备。当医疗设备向医疗设备服务器发送其已经开机的指示时，从已知状态704或确定节点706进入上电状态708。当医疗设备服务器接收到医疗设备已经清除了使服务器将医疗设备与剩余的操作状态（即治疗状态710、故障状态712和警报状态714）之一相关联的条件的指示时，从那些状态进入上电状态。
治疗状态710对应于当前正在操作、提供治疗或者监测患者的与医疗设备服务器通信的医疗设备。医疗设备所采取的特定动作将由特定医疗设备的特性支配，但是医疗设备服务器只需要识别医疗设备当前处于操作中。系统700可以从其它操作状态708、712、714的任何状态或者从确定节点706进入治疗状态。当医疗设备成功完成治疗时，它向医疗设备服务器传达这一事件，医疗设备服务器将与该设备相关联的表条目返回至上电状态708。如果医疗设备由于故障或者警报事件而没能完成治疗，则它将向医疗设备服务器传达这一事件，医疗设备服务器将与该设备关联的表条目改变为适当的操作状态。
故障状态712对应于医疗设备中发生的错误，诸如在监测和提供治疗的过程中设备操作中的故障。可以从上电状态708或治疗状态710进入故障状态712，并且也可以从确定节点706进入。在可能的实施例中，故障状态712能够向控制医疗设备的看护者触发发生故障的通知。在另一个实施例中，当医疗设备服务器接收在表中生成故障状态条目的指示时，服务器能够确定医疗设备中发生的故障并且能够改正该错误。在清除故障状态时，医疗设备向医疗设备服务器发送它已经返回到前一操作状态、或者进入上电状态708（如果从确定节点706返回）的指示。由跟踪医疗设备的状态的医疗设备服务器保持的表被适当地更新以反映医疗设备的状态。
警报状态714对应于医疗设备服务器从医疗设备接收在医疗设备中发生需要医生、护士或者其它看护者注意的事件的指示。例如，医疗设备可以是已经用完所要提供的药的医用输液泵。在另一个示例中，医疗设备是心跳速率监测器，而事件是不正常的低或高的心率的监测和检测。可以从上电状态708或治疗状态710进入警报状态714，并且还可以从确定节点706进入。在清除警报事件时，医疗设备向医疗设备服务器发送它已经返回其前一操作状态的指示，并且表被适当地更新。
可以从包括上电状态708、治疗状态710、故障状态712或警报状态714的有效状态中的任意一个进入无操作状态716。无操作状态716对应于服务器不能确定医疗设备是否有效或者医疗设备处于何种状态。无操作状态716向医疗设备服务器的用户指示可能需要注意该医疗设备以便适当地将该医疗设备关联到医疗设备服务器。
在系统700的操作的示例中，当将医疗设备被引入医疗设备网络中时，医疗设备服务器可能知道或可能不知道如何与其通信。假设它是当前没有上电的已知设备，则医疗设备服务器将最终进入已知状态704。当医疗设备开启时，医疗设备将向服务器发送通电消息，服务器将更新表以指示医疗设备处于上电状态708。医疗设备将在医疗设备提供治疗时向服务器发送消息，并且医疗设备服务器将会将该医疗设备与治疗状态710相关联。当医疗设备成功完成提供该治疗时，医疗设备将向服务器发送消息，服务器将该设备的表条目从治疗状态710改变为上电状态708。如果医疗设备因为某些原因失败，则它将向服务器传达故障消息，服务器会将该医疗设备与故障状态712相关联。
如果医疗设备用完药品或检测到患者的危险情况，则设备将向服务器传达警报消息，服务器将医疗设备与警报状态714相关联。当设备完成提供治疗时，它向服务器发送完成提供治疗的消息，服务器将医疗设备与上电状态708相关联。然后看护者可以关掉医疗设备，并且在关闭之前医疗设备向服务器发送消息，服务器继而将医疗设备与已知状态704相关联。
图8显示了包括医疗设备服务器和医疗设备的示例性通信系统800的图。通信系统800被配置用于对来自诸如医疗设备的外部设备的输入消息的接收、处理和存储。在一个实施例中，通信系统800使用诸如SOAP协议的基于元数据的通信协议。在这种系统中，医疗设备服务器使用消息模式文件来确认从医疗设备接收的消息。
将通信系统800配置为使得从医疗设备802发送的消息被包括设备服务器对象806、消息处理器808和数据层810的服务器804接收。医疗设备802可以是能够与医疗设备服务器通信的多个医疗设备中的任意一个。以上结合图2描述了医疗设备的多个实施例。
医疗设备服务器804可以是被配置为从医疗设备收集数据并协助医疗设备设置和监测的多个通用计算系统中的任意一个。医疗设备服务器804包含设备服务器对象806，其处理从医疗设备服务器发送和接收的消息并且解析该消息以确定它们包括医疗设备服务器作用于该消息所需要的信息。例如，设备服务器对象能够解析消息中包含的多种元数据标签以及与该元数据相关联的数据，以验证消息类型、源或目标设备识别或网络识别，以及消息数据。也可以确定消息的其它成分。
示例性消息内容描述设备服务器对象806以及系统中包含的各种设备处理器的各种特征。一个设备服务器对象定义的实例如下：
<Feature>
<Id>XXXXXXXX‑XXXX‑XXXX‑XXXX‑XXXXXXXXXXXX<／Id>
<LicenseId>XXXXXXXX‑XXXX‑XXXX‑XXXX‑XXXXXXXXXXXX<／LicenseId>
<Name>Medical Device Secured Server<／Name>
<Provider>MedicalDeviceServer．MedicalDeviceSoapTcpServer,
MedicalDeviceServer．MedicalDeviceSoapTcpServer．
MedicalDeviceSoapSecureTcpServer<／Provider>
<Description>Receives inbound connection over SSL secured TCP／IP
networks.<／Description>
<Type>Server</Type>
<／Feature>
在该示例中，特征标签将对象定义为设备服务器对象的特征。Id标签定义GUID或者用于识别特征的统计上唯一的数。LicenseID标签识别包含所定义的特征的证书。Name标签提供特征的名称。Provider、Description和Type标签定义对象的各种实施细节。也可以包括另外的实施细节。
一个或更多个消息处理器808从设备服务器对象806以消息的原始格式接收消息，并且以将消息转换为医疗设备服务器804的数据层810可以理解并存储的格式的方式来处理该消息。基于所接收的消息的类型为各个处理器分配消息，每个处理器以给定方式处理特定类型的消息。在一个实施例中，消息处理器包括警报处理器、故障处理器、维护处理器、电源处理器、请求处理器、各种遥测处理器和各种治疗处理器。根据医疗设备服务器804管理的多种类型的消息也可以有额外的或者较少的处理器。
第二示例服务器对象定义描述了消息处理器808的各种特征：
<Feature>
<Id>XXXXXXXX‑XXXX‑XXXX‑XXXX‑XXXXXXXXXXXX<／Id>
<LicenseId>XXXXXXXX‑XXXX‑XXXX‑XXXX‑XXXXXXXXXXXX<／LicenseId>
<Name>Medical Device Event Handler<／Name>
<Provider>Informatics.BackOffice.MedicalDeviceServer<／Provider>
<Description>Validates received events and stores them in the Operation
database<／Description>
<Type>Handler</Type>
<／Feature>
消息处理器808的示例类似于描述设备服务器对象806的示例，但是采用Provider标签定义，Provider标签指示元数据定义被配置为定义特征的处理器。消息处理器808可以采用以下代码与设备服务器对象806相关联：
<Handler>
...
<FeatureId>XXXXXXXXXXXX‑XXXX‑XXXX‑XXXXXXXXXXXX<／FeatureId>
<HandlerId>XXXXXXXXXXXX‑XXXX‑XXXX‑XXXXXXXXXXXX<／HandlerId>
...
<／Handler>
通过将特征806联系到处理器808，医疗设备服务器804可以将特定类型的数据路由到适当的处理器。
数据层810从消息处理器808接收消息用于存储，并且还通过向请求消息处理器808提供数据以用于基于SOAP的消息的形成或者经由设备服务器对象806向医疗设备的发送来响应对数据的请求。
A．元数据编程和通信
现在参照图9至图16，公开了一种列出用于定义多种医疗设备的操作特性的元数据的编程方案。元数据还允许医疗设备服务器与诸如医用输液泵或者其它治疗提供或监测设备的很多种医疗设备通信。通过在医疗设备服务器中按照医疗设备的操作特性而不是具体的专用接口来定义医疗设备，医疗设备服务器不需要理解每种类型的医疗设备的内部工作。相反，服务器将理解如何基于该设备的期望的操作与医疗设备通信。通常，所公开的元数据方案采用XML协议和以上在图8中所描述的基于SOAP的消息系统工作。但是，也可以使用其它标准的通信方法。
图9示出用于医疗设备和医疗设备服务器之间的通信的系统和方法。所示出的系统900被配置为向多种类型和品牌的医疗设备提供可扩展性，如以上在图2中所述。医疗设备服务器可以通过针对每个医疗设备定义预定元数据集和相关联的参数来与医疗设备进行通信。系统900以对应于将医疗设备通信连接到医疗设备服务器的开始操作902作为例示。在一个实施例中，通信连接对应于将医疗设备引入包括医疗设备服务器的医疗设备网络（诸如图1中所示的网络）。在另一个实施例中，通信连接对应于使用软件开发工具包中提供的或以其它与本发明一致的方式提供的用于安装元数据通信层的软件来将相应的元数据包安装到医疗设备上。
关联模块904在医疗设备服务器的数据库中将元数据与各种医疗设备相关联。医疗设备存储相应的元数据，以使得所关联的元数据对应于设备上设置的元数据。元数据对应于医疗设备所共有的至少一个属性或操作特性，并且可以用于区分、识别医疗设备网络中各种医疗设备通信并与之通信。在各种可能的实施例中，由元数据定义的操作特性包括患者信息、用户或者看护者信息、控制信息、药物信息或者位置信息。也可以包括另外的操作特性，诸如在图11至图16的方案的一个或者更多个中描述的那些。元数据还对应于医疗设备中发生的各种事件，诸如电源事件、警报事件、维护事件、遥测事件、治疗事件、治疗改变事件或其它事件。下面在图17至图33中描述另外的事件。
存储模块906在医疗设备服务器或后台部件上存储元数据。医疗设备服务器被配置为通过使用元数据和以上结合图8描述的基于元数据的消息系统与每个医疗设备通信。操作流程前进到结束操作908，其对应于完成建立医疗设备和医疗设备服务器之间的通信方案。
图10示出了用于医疗设备和医疗设备服务器之间的通信的另外的系统和方法。图10的系统1000存储医疗设备网络中所有医疗设备共有的元数据，并且还存储特定于医疗设备的子集的信息，以允许医疗设备和医疗设备服务器之间的定制通信。系统1000的操作流程以开始操作1002开始，开始操作1002再次对应于将医疗设备通信连接到医疗设备网络中的医疗设备服务器。
在开始操作1002之后，操作流程前进到通用关联模块1004。通用关联模块1004对应于图9的关联模块904，在于它通过针对每个医疗设备定义预定元数据集以及相关的参数来关联定义医疗设备网络中的每个医疗设备的特性的元数据。定制元数据模块1006将元数据与一个或更多个医疗设备相关联，该元数据特定于该设备。定制元数据的示例包括特定类型的医疗设备中发生的特定电源事件、那些设备所支持的特定通信类型、或者针对少于医疗设备网络中包括的全部设备定义的其它操作参数。存储模块1008一般地对应于图9的存储模块906，并且在服务器上存储通用元数据和定制元数据。
设备选择模块1010基于医疗设备服务器中存储的定义医疗设备的元数据来选择医疗设备网络中的一个或更多个医疗设备以与之通信。在一个实施例中，设备选择模块在从医疗设备接收到消息时执行。在另一个实施例中，医疗设备服务器在不从医疗设备之一接收在前的信令通信的情况下选择一个或更多个医疗设备并且与之通信。
通信模块1012将消息发送到在设备选择模块1010中确定的被选择的医疗设备。通信模块形成基于SOAP的消息以发送到医疗设备，包括识别医疗设备的目的信息以及要发送到医疗设备的数据。该消息包括通过以系统1000所理解的方案定义的元数据标签识别的各种信息，诸如以下在图11至图16和图19至图24中描述的那些。操作流程终止于结束操作1014，其对应于完成向医疗设备发送消息。
图11至图16示出包括可以用于方便用于医疗设备和医疗设备服务器的可扩展通信系统的元数据的各种方案。该方案用于图1的医疗设备网络中以将多种医疗设备识别到医疗设备服务器，并且允许医疗设备服务器与设备通信。该方案包括与网络中的所有医疗设备所共有的或者一个或更多个医疗设备所特有的各种操作参数或属性有关的元数据。通过使用所公开的各种方案，医疗设备服务器可以通过（1）知道设备的能力和极限以及（2）与其它医疗设备共享可扩展通信协议来识别医疗设备、识别设备的特性并且知道如何与设备交互工作。
图11示出了用于识别与医疗设备服务器通信关联的每个医疗设备的各种操作特性的身份方案1100。身份方案1100包括：主表1102，其包括多种全局参数；网络表1104；访问表1106；以及一个或更多个包表1108。主表1102包括与多种通用设备识别特性（包括设备类型、设备标识符、会话标识符、网络标识符、访问标识符和包验收）相关联的元数据。设备类型涉及诸如设备的制造商和型号的医疗设备的类型的识别，而设备标识符对于每个设备是唯一的。会话、网络和访问标识符定义连接字符串以允许消息被正确地路由到医疗设备。包标识符指示医疗设备是否被配置为从医疗设备服务器接收包，并且可以链接到指示在每个设备上被使能的当前包的表。
包括网络表1104、访问表1106和包表1108的剩余的表提供与医疗设备的链接和能力有关的附加信息，并且通过主表1102中的网络标识符、访问标识符和包标识符链接到主表。网络表1104包括通过互联网连接定义到医疗设备的连接所需的主机、域、IP地址和端口信息。访问表1106包括与对应于物理设备到IP地址的特定联网连接相对应的IP地址和物理Id。包表1108描述医疗设备使用的软件或固件包的附加细节，诸如软件包的名称和版本等。下面结合图25至图33描述关于对医疗设备的包部署的附加细节。
图12示出控制表1200，包括描述发送消息的后勤（logistics）的单元以及在医疗设备和医疗设备服务器之间跟踪那些单元。所示出的控制表1200包括消息标识符、时间戳和响应元数据。消息标识符提供用于跟踪消息的识别字符串，并且对应于医疗设备的身份。时间戳指示从医疗设备服务器或医疗设备发送消息的时刻。响应提供消息是从医疗设备发起的还是来自服务器的响应的布尔指示（Boolean indication）。控制表中也可以包括与消息跟踪有关的另外的元数据。
图13示出用于跟踪用于与医疗设备相关联的患者信息的患者表1300。患者表1300包括标识符和姓名单元。姓名单元保持与患者的姓名有关的元数据，并且标识符关联到统计唯一的标识符以与该患者相关联。也可以包括其它与患者有关的元数据。
图14示出用于指示患者位置的位置表1400。位置表1400包括定义别名单元和描述单元的元数据。描述单元指的是患者位置的语言描述，诸如“医院X，新生儿科，房间1”或者类似的条目。别名单元提供用于将位置与医疗设备相关联的缩写码。位置表1400中也可以包括描述患者或者医疗设备的位置的附加元数据。
图15示出用于在存在与医疗设备相关联的药物时指示药物的药物表1500。由于只有一些医疗设备能够向患者提供基于药物的治疗这一事实，可能或者可能不对每个医疗设备生成药物表1500。药物表包括与药物标识符、药物名称和药物浓度有关的元数据。可以采用另外的元数据条目来进一步识别或描述医疗设备所用的药物。
图16示出与当前控制医疗设备的医生、护士或者其它看护者对应的用户表1600。用户表1600包括与用户标识符和用户名称以及对于系统操作来说用户需要的任何另外的识别特性有关的元数据。
B．事件日志和维护
现在参照图17至图24，公开图1的医疗设备网络中使用的用于跟踪与医疗设备服务器相关联的各种医疗设备的事件和维护信息的系统、方法和方案。这些基于事件的方案可以用于跟踪医疗设备网络中的医疗设备的当前和历史性能，以及用于维护医疗设备。下面描述的方案定义消息系统和医疗设备服务器或医疗设备网络的其它后台部件存储的事件或操作数据的命令。与以上第II.A部分中描述的涉及医疗设备或服务器的相对恒定的操作特性的方案相比，事件日志和维护跟踪方案定义医疗设备网络中发生的特定事件或任务。
图17示出用于采用图19至图24中公开的各种基于事件的消息模式从医疗设备服务器或后台部件接收事件日志结果的方法和系统。系统1700通常在医疗设备服务器或医疗设备网络的其它后台部件上执行，并且向看护者或其它用户提供由那些部件管理的一个或更多个数据库中存储的事件日志数据。
系统1700中的操作流程以对应于医疗设备网络的初始操作的开始操作1702开始。操作流程前进到从与医疗设备服务器相关联的各种医疗设备接收事件日志数据的事件接收模块1704。事件日志数据代表医疗设备中发生的事件，并且可以是多种类型的事件中的任意一个，诸如电源事件、遥测事件、警报事件、治疗事件、维护事件或者其它事件，诸如图19至图24的方案中定义的那些。
实例消息主体示出从医疗设备到医疗设备服务器的事件的通信，诸如由事件接收模块1704接收。在该示例中，医疗设备是医用输液泵，其向医疗设备服务器发送指示该泵已开启的电源事件：
<env:Body><mds:PowerEvent xmlns:mds=’mds:xml‑schema:soap 11’>
<Trigger>on</Trigger>
<Message>Normal Power Up Complete<／Message>
<Timestamp>1900‑01‑01T00:00:08</Timestamp>
<Medfusion4000_Power>
<Source>AC</Source>
<Capacity>90.0%</Capacity>
<／Medfusion4000_Power>
</mds:PowerEvent></env:Body>
该消息部分标识出这是消息的主体，以及它采用SOAP 1.1消息协议。从泵发送的消息指示已经完成了上电过程，并且包括由泵分配的时间戳。各种电源参数对应于下面的图19的电源事件表中包括的那些参数，并且与医用输液泵的特定值相关联。由医疗设备服务器从医用输液泵接收该消息，并且值被存储在对应于电源事件方案的适当的数据库表中。
在与医疗设备网络中跟踪的其它类型的事件有关时，如这里所述，类似的消息被从医疗设备发送至医疗设备服务器，并且响应被从服务器发送回到医疗设备。
存储模块1706在与从医疗设备到服务器的消息中定义的正确元数据相关联的数据库中存储事件日志数据。在一个实施例中，存储模块1706在图3至图4的事件数据318中存储事件日志数据。
请求接收模块1708接收对医疗设备服务器或其它后台部件中存储的事件日志数据的子集的请求。所接收的请求可以来自工作站、便携式计算设备或其它类型的计算系统。请求包括一个或更多个窄化参数，诸如日期范围、看护者姓名或标识符、患者姓名或标识符、药物名称或标识符、特定设备或者与事件日志数据相关联的其它类型的信息。在一个示例中，请求接收模块1708接收对与医用输液泵进行的特定药物的提供有关的事件日志数据的请求。
结果生成模块1710诸如通过基于请求的窄化参数对医疗设备服务器或者后台部件所保持的事件日志数据进行过滤来基于请求接收模块1708接收的特定请求来生成结果。结果生成模块1710还可选地将结果发送至请求计算系统。采用请求接收模块1708中描述的示例，医疗设备服务器生成查询，其被配置为返回与经识别的泵所识别的药物的提供有关的事件日志数据。该查询可以用SQL或某种其它数据库查询语言形成，以使得与医疗设备服务器相关联的数据库管理系统返回查询结果。
操作流程终止于结束操作1712，其对应于生成结果并将结果发送至请求计算系统的完成。
图18示出用于向医疗设备传递预防性维护数据的系统的方法。系统1800使用图11至图16的元数据以及图19至图24的附加的事件元数据以跟踪和传递要在医疗设备网络中的一个或更多个医疗设备上执行的维护任务。结合图17描述的各种消息发送原理允许通信发生。
系统1800以对应于医疗设备网络的初始操作的开始操作1802开始。操作流程前进到存储模块1804，其在与一个或更多个医疗设备相关联的医疗设备服务器上存储维护时间表。维护时间表被存储在医疗设备服务器或后台部件的数据库中，并且包括针对时间表中包括的维护提醒事件和针对医疗设备的时间值。维护时间表还可选地涉及维护数据，诸如需要的操作软件更新或者各种其它的配置参数等。
在一个示例中，存储模块1804存储包括针对一系列医用输液泵推荐的定期重新校准或者针对特定医用输液泵的指示的维护表。在这样的示例中，存储模块1804可以存储由医用输液泵的用户或制造商提供的维护时间表，以便在所指示的维护预定时向泵的用户提供提醒。
发送模块1806在维护事件发生时向与维护时间表关联的一个或更多个医疗设备发送提醒。提醒可以是显示在与医用输液泵相关联的显示器上的用户可读消息，向看护者指示建议进行重新校准。或者，提醒可以是医疗设备上存储的用户可读消息的触发。
发送模块1806还可选地发送与维护提醒相关联的维护数据。在系统1800的一个实施例中，发送模块1806发送的提醒禁用医疗设备。在另一个实施例中，提醒允许医疗设备继续操作。在又一个实施例中，在执行医疗设备所需要的维护之前的预定时间发送提醒。
继续以上来自存储模块1804的医用输液泵的示例，维护事件被发送到医用输液泵。维护事件向医用设备指示设备需要维护，并且包括显示在医用输液泵的显示设备上的提醒消息，诸如“需要维护‑请联系制造商”或者需要维护的某些其它指示。在某些配置中，维护事件允许医疗设备继续操作直到看护者联系可能具有关于医疗设备的维护和保养的特定指令的制造商为止。
操作流程终止于对应于完成向医疗设备发送维护提醒和任何相应的维护数据的结束操作1808。
图19至图24示出用于医疗设备和医疗设备服务器之间的通信和响应的基于事件的方案。所公开的方案可以用于图1的医疗设备网络中，以允许医疗设备服务器和后台部件收集和存储事件日志数据以及向医疗设备发送消息。网络的医疗设备和医疗设备服务器使用下面描述的元数据发送消息和事件数据以识别消息的内容。医疗设备服务器或后台部件存储与元数据相符的事件数据。
图19示出电源事件表1900和电源事件响应表1910。表1900、1910定义用于跟踪医疗设备中各种电源事件（诸如开启设备、关闭设备、电源警告和其它电源相关的事件）的元数据。电源事件表1900包括与触发、消息和时间戳有关的元数据。触发对应于医疗设备中改变的事件，诸如开启、关闭设备或者更新设备的供电状况等。消息描述医疗设备中发生的特定事件，诸如低电池警告、通电事件的发生、断电事件的发生或者某些其它电源相关的事件。时间戳指示医疗设备经历电源事件的时刻。
电源事件响应表1910包括定义对医疗设备服务器所接收的电源事件的各种可能响应的元数据。例如，当医疗设备服务器接收通电事件时，服务器可以响应需要特定的维护任务或者可以获得要下载的软件和固件。电源事件响应表包括结果、消息、会话、间隔和包元数据。结果元数据涉及电源事件的结果，诸如医疗设备的改变的状态或者接收的事件的服务器识别的各种其它结果。消息元数据包括要发送到医疗设备的消息，诸如为了描述用于在与医疗设备关联的显示设备上显示的响应消息的内容。会话元数据包括与设备和服务器之间的通信会话有关的信息。间隔元数据包括与从医疗设备到服务器的通信之间的预期间隔有关的信息，其与下面在第IV部分中描述的医疗设备的在线状况的服务器检测有关。包元数据向设备提供关于该设备是否有新的包信息可以获得的指示，该指示可以经由图25至图33的包部署方法和系统传递。响应表1910和相应的响应消息中可以包括另外的元数据。
图20示出警报事件表2000和警报事件响应表2010。警报事件涉及医疗设备中触发的警报的激活或清除，以及设备生成并被传递到医疗设备服务器的相应的消息。医疗设备中警报的激活或清除可能涉及医疗设备检测到的患者状况的检测，或者可以涉及警报事件表2000，警报事件表2000对应于电源事件表1900，在于它也包括触发、消息和时间戳元数据。在警报事件表2000的情况中，触发元数据涉及激活、清除或更新警报消息。与电源事件表1900的对应字段类似地使用消息和时间戳元数据。
警报事件响应表2010对应于电源事件响应表1910。响应于警报事件消息的接收将使用警报事件响应表元数据生成的消息传递到医疗设备。因此警报事件响应表2010通常包括与电源事件响应表1910不同的响应，并且传递与警报事件有关的消息、包或其它指令。
图21示出了维护事件表2100和维护事件响应表2110。维护事件对应于医疗设备对需要维护的指示的特定反应，诸如请求更新的操作软件、校准软件或者指示需要的维护的通知消息。对于维护需要软件更新或者某些其它远程控制维护事件的情形，维护事件表2100对应于在来自准备好结合医疗设备服务器执行维护的医疗设备的消息中接收的数据。维护事件表2100对应于电源事件表1900，在于它也包括触发、消息和时间戳元数据。在维护事件表2100的情况中，触发元数据涉及所应用的更新或包。与电源事件表1900的对应字段类似地使用消息和时间戳元数据。
维护事件响应表2110也对应于电源事件响应表1910，并且由医疗设备服务器或其它后台部件生成。采用维护事件响应表元数据生成的消息响应维护事件消息的接收而被传递到医疗设备，并且涉及响应于维护事件而发生的消息、包或其它指令，诸如关于需要的维护的另外的细节、维护时间表信息、要由医疗设备显示的关于所需要的维护的信息等。
图22示出遥测事件表2200和遥测事件响应表2210。遥测指的是从医疗设备到医疗设备服务器的事件数据的接近连续的流传输，以使得能访问医疗设备服务器的用户可以以接近实时的方式远程监测医疗设备的操作。遥测事件表2200对应于电源事件表1900，在于它也包括触发、消息和时间戳元数据。在遥测事件表2200的情况中，触发元数据涉及关于从医疗设备接收的遥测的更新事件。与电源事件表1900的对应字段类似地使用消息和时间戳元数据。
遥测事件响应表2210也对应于电源事件响应表1910，但是其由服务器生成。采用遥测事件响应表元数据生成的消息响应于遥测事件消息的接收而被传递到医疗设备，并且响应于遥测事件传递消息、包或其它指令。
图23示出治疗事件表2300和治疗事件响应表2310。治疗事件通常涉及治疗的开始和停止或者监测医疗设备中的过程。被开始或停止的特定治疗取决于所用的医疗设备的类型，并且可以包括监测、药物提供或其它治疗。治疗事件表2300对应于电源事件表1900，在于它也包括触发、消息和时间戳元数据。在治疗事件表2300的情况中，触发元数据涉及与医疗设备的治疗的初始化或结束有关的设置、开始、结束或更新治疗事件。与电源事件表1900的对应字段类似地使用消息和时间戳元数据。
治疗事件响应表2310也对应于电源事件响应表1910，但是其由服务器生成。采用治疗事件响应表元数据生成的消息响应于治疗事件消息的接收而被传递到医疗设备，并且响应于治疗事件传递消息、包或其它指令。
图24示出治疗改变事件表2400和治疗改变事件响应表2410。治疗改变事件通常涉及在医疗设备上进行的治疗的改变，并且涉及上面讨论的治疗事件。治疗改变事件包括例如与治疗的监测或提供有关的参数改变，诸如改变药物提供速率。治疗改变事件表2400对应于电源事件表1900，在于它也包括触发、消息和时间戳元数据。在治疗改变事件表2400中，触发元数据涉及与治疗改变有关的撤销（override）、警告、放弃或更新事件。与电源事件表1900的对应字段类似地使用消息和时间戳元数据。
治疗改变事件响应表2410也对应于电源事件响应表1910，但是其由服务器生成。采用治疗改变事件响应表元数据生成的消息响应于治疗事件消息的接收而被传递到医疗设备，并且响应于治疗改变事件传递消息、包或其它指令。
C．包部署
返回参照图11，存在各种系统和方法用于将包从医疗设备服务器部署到医疗设备。所部署的包可以包括固件更新、维护信息、新的或改变的治疗参数或者对医疗设备网络中的医疗设备的其它软件更新或改变。在一个可能的实施例中，可以使用具有任何可能的包数据类型的包对它要发送到的医疗设备进行重新编程。能够接收包数据的医疗设备在主表1102和包表1108中指示该能力。主表1102指示设备接收包的能力，并且包表1108包括与存储在医疗设备处用于医疗设备的操作的当前包信息有关的信息。如下面更详细的讨论的，包传送响应于消息而发生，并且使用事件响应表1910‑2410中的包数据标识符发起以向医疗设备指示包可用于传送。
现在参照图25，示出在对医疗设备部署信息中使用的包2500的示例结构。包2500包括要传送到医疗设备的服务器头2502、供应商头2504和信息2506。服务器头2502是医疗设备服务器理解的包的部分。服务器头2502对于所有的包有共同的格式，并且包含与被配置为接收该包的设备类型有关的标识信息以及包的源。服务器头2502中也可以包括诸如包大小、加密格式或者密钥位置信息的附加信息。在一个实施例中，服务器头2502是包含在包中的256字节块。
供应商头2504包括与接收包的医疗设备中的包的使用有关的供应商特定信息。向医疗设备服务器提供包的供应商通常是制造商或者与要接收该包的医疗设备相关联的维护公司，因此供应商将以它制造的医疗设备可以理解的方式格式化供应商头2504。供应商头通常包括与信息2506的大小以及信息内加密信息2508的位置有关的信息。加密信息2508可以由医疗设备用于解密通常以加密形式存储在医疗设备中的信息。
信息2506通常包括要从医疗设备服务器传输到医疗设备的任何软件，诸如固件更新、包括治疗参数的文件或其它二进制数据。包传递系统2500不依赖于供应商头2504或信息2506的具体格式。信息2506通常以加密形式存储在医疗设备服务器上。当传输到医疗设备时，通过基于供应商头2504中的信息定位加密信息2508来由医疗设备解密信息2506。
图26示出用于从医疗设备服务器向医疗设备部署包数据的系统和方法。系统2600被配置为响应于从医疗设备接收的消息向医疗设备分发诸如图5的包2500的包。
系统2600中的操作流程以开始模块2602开始，开始模块2602对应于从医疗设备的供应商、医疗设备的管理员或熟悉医疗设备的操作的另外的实体接收包信息。存储模块2604将所接收的包存储在医疗设备服务器中。存储模块2604还可以为医疗设备设置警报或其它变量，以使得在下一次医疗设备与服务器通信时在对医疗设备的响应中包括包的存在的指示。在一个实施例中，存储模块2604在存储在医疗设备服务器或后台部件上时加密包，并且当要使用或发送该包时，医疗设备服务器或医疗设备本身解密该消息。在另一个实施例中，当包被存储在医疗设备服务器或后台部件上时，存储模块2604不对包加密。
消息接收模块2606在医疗设备服务器处从医疗设备接收消息。消息可以是多种类型的消息中的任何一种，诸如上面在图19至图24中描述的电源、维护、警报、遥测、治疗或者治疗改变事件消息。另外的消息类型也是可能的。
指示模块2608向医疗设备指示有包要传递到该设备。在一个实施例中，指示模块2608在指示包的存在的消息响应中设置参数。例如，指示模块2608可以在图19至图24的事件响应消息1910‑2410中包括的包元数据中设置参数。其它指示包存在的方法也是可能的，诸如与包部署有关的特定消息的发送、医疗设备的包请求或者其它方法。
请求模块2610从医疗设备接收请求以接收包。请求模块2610可以包括请求关于包的信息的一个或者更多个步骤，以在医疗设备处验证是否应该接受该包。在一个可能的实施例中，请求模块2610使用如图27所示的元数据发送包信息请求消息。在这样的实施例中，请求模块2610可选地还发送与包信息请求消息分开的包数据请求消息，在从医疗设备服务器接收描述包内容的包信息之后发送包数据请求消息。在另外的实施例中，请求模块2610接收如图29或图31所示的请求。
传递模块2612将所请求的包传递至医疗设备。包传递消息的格式可以如图30或图32所示。操作流程终止于对应于完成向医疗设备的包发送的结束操作2614。
图27至图32示出用于从医疗设备服务器向医疗设备部署包的包括诸如图1所示的医疗设备网络中的消息和表中所用的元数据的方案。该方案显示各种请求和响应场景，其中医疗设备请求包信息的传递并且接收作为响应的所请求的信息。可以在传递包及其所附的数据之前在医疗设备和医疗设备服务器之间发送一个或更多个消息。
图27示出包信息请求表2700，其包括用于请求关于可用于向医疗设备部署的包的请求信息的元数据。基于作为医疗设备服务器中的主表1102或者与该设备有关的包表1108中的反应信息的来自医疗设备服务器的先前响应，医疗设备被通知有可用的包。表2700中的元数据包括包标识符，其被医疗设备用来识别关于其内容的包和请求信息。表2700和来自医疗设备的消息中也可以包括与包有关的另外的元数据。
图28示出包括用于描述可用的要被部署到医疗设备的包的元数据的包信息请求响应表2800。表2800中的元数据包括与包信息请求表2700中的包标识符对应的包标识符，并且还包括包信息元数据。包信息元数据链接到包含名称和版本元数据的包信息表2802。与名称和版本元数据相关联的值描述该包，以使得医疗设备能够确定是否要请求该包的部署。
图29示出包括用于从医疗设备服务器请求包数据的元数据的包数据请求表2900。包数据请求表2900包括包标识符和响应类型元数据。包标识符代表可用于部署到医疗设备的包的唯一标识符。响应类型代表指示包数据的期望的传递格式的标识符。在一个实施例中，包数据可以以纯文本格式或采用xop格式传递到医疗设备。
图30示出包括用于将包部署到医疗设备的元数据的包数据请求响应表3000。包数据请求响应表3000中包括的元数据包括包标识符和包二进制数据字段。包标识符识别图29中所涉及的包，包二进制数据字段表示代表被传递到医疗设备的包的二进制数据。包二进制数据字段可以可选地链接到包含用于传递到医疗设备的包二进制数据的单独的包二进制数据表3002。在一个实施例中，传递到医疗设备的包是图25的包2500。
图31示出包请求表3100。包请求表3100对应于与图27的包信息请求表2700结合的图29的包数据请求表2900。包请求表3100可以被医疗设备用于这样的例子中，其中在下载包之前医疗设备不需要验证包信息。类似于包数据请求表2900，包请求表3100包括包标识符和响应类型，但是通过请求整个包指示包信息和包数据消息不需要分开。
图32示出包请求响应表3200，代表响应于由图31的包请求表3100反映的形式的消息从医疗设备服务器发送的消息的方案。包请求响应表包括包标识符、包信息和包二进制元数据。包信息元数据链接到包含关联到元数据的名称和版本元数据的包信息表3202。包二进制元数据链接到包二进制表3204，其包括对应于要部署到医疗设备的包的元数据。
D．时间管理
现在参照图33至图35，其示出用于医疗设备网络中的时间管理的系统和方法。因为医疗设备网络可以在大小和配置上改变，因此所描述的时间管理系统被配置为在多个商业实体、多个位置和多个时区上扩展。所描述的系统和方法提供了一种一致的方式以同步医疗设备和位于一个或更多个位置或时区中的医疗设备服务器中的时间跟踪。
图33示出可以用于在医疗设备服务器处跟踪医疗设备时间的时间消息模式3300，并且还在医疗设备和医疗设备服务器之间传输时间同步消息。时间模式3300包括时间请求表3302、时间请求响应表3304和系统时间表3306。时间请求表3302可选地不包括元数据，而是代表从医疗设备发送至医疗设备服务器以用于将医疗设备时间与存储在服务器或后台部件中的时间进行同步的时间请求响应。时间请求响应表3304包括与医疗设备服务器上存储的系统时间值相关联的系统时间元数据。系统时间元数据可选地链接到系统时间表3306，其包含可以用于将医疗设备的时间与从医疗设备服务器接收的时间进行同步的时间值。也可以使用可用于协助时间同步的另外的元数据或其它信息。
图34示出用于医疗设备网络中的医疗设备和医疗设备服务器的时间同步的方法和系统。系统3400中的操作流程以对应于医疗设备网络的初始操作的开始操作3402开始。服务器时间维护模块3404在服务器中维护要用于同步通信连接到该服务器的医疗设备的时间值的全局时间值。
服务器时间发送模块3406将服务器时间发送到医疗设备网络中的一个或更多个医疗设备。在一个实施例中，服务器时间发送模块3406响应于来自医疗设备的请求消息将服务器时间值发送至该医疗设备。在这样的实施例中，请求消息可以是上面的图33的时间请求表3302中示出的形式。
在另一个实施例中，发送模块3406基于医疗设备的位置的时区将服务器时间值转换为本地服务器时间值。如果服务器与医疗设备位于不同的时区，则该转换可能发生。从而服务器和医疗设备具有转换到适当的时区的同步的时间值。该实施例的一种可能的实施在从服务器发送时将所有时间转换为世界时间协议，并且目标医疗设备将该时间值重新转换为目标设备的位置处的本地时间。诸如从医疗设备服务器的本地时间到医疗设备的本地时间的其它时区转换也是可能的。
替换模块3408将医疗设备中的设备时间替换为从医疗设备服务器接收的服务器时间值。替换模块3408使用时间调整的服务器时间值，其被配置为在医疗设备的位置处使用。可选的确认模块3410向医疗设备服务器发送指示医疗设备成功同步到服务器的确认消息，允许服务器跟踪哪些医疗设备已经成功地与服务器同步。操作流程终止于对应于时间同步过程的完成的结束操作3412。
现在参照图35，公开了用于同步事件日志数据的方法和系统。系统3500容纳从位于多个时区中的不同位置处的医疗设备接收的事件日志数据。配置事件日志数据以使得事件日志数据的本地时间戳代表设备所位于的时区，所以来自不同时区的具有相同时间戳的事件日志实际上发生在不同的时刻。系统3500在存储事件日志数据时以及在将其提供给用户检查时补偿这一差异。系统3500内的操作流程以对应于从医疗设备到医疗设备服务器的事件数据的初始传递的开始操作3502开始。
接收模块3504对应于医疗设备服务器从一个或更多个医疗设备接收事件日志数据。如上所述，事件日志数据包括关于各种类型的事件（诸如治疗事件、警报事件、维护事件、遥测事件或其它类型的事件等）的各种细节，其中每个事件与反映医疗设备的当前时间值的时间戳相关联，反映该设备的本地时区。时区修改模块3506将时间戳信息从医疗设备的本地时区转换为恒定时区。在一个实施例中，时区修改模块3506将时间戳转换为世界时间协议（UTP）。存储模块3508将经转换的时间戳和相关联的事件日志数据存储在医疗设备服务器或后台部件中。
可选的全局跟踪模块3510使用统一的时区信息跟踪全局事件。例如，期望跟踪在单个瞬时时刻所有时区上发生的事件的用户可以使用在所有时区上保持标准时间的世界时间协议来跟踪全局事件。用户发送对于与服务器上存储的全局事件有关的事件日志数据的请求，并且接收带有具有恒定时区信息的时间戳的事件日志信息。
请求本地事件模块3512接收对于包括与事件发生的时区相关联的事件数据的类型的本地事件数据的请求。时区特定事件的示例可以包括定时发生在医院轮班的开始或结束时的事件或者其它本地事件。请求本地事件模块3512生成对于所请求的事件数据的查询，并且返回包括事件日志数据的结果。转换模块3514基于从其记录事件日志数据的医疗设备的位置将统一的时区信息转换为本地时区信息。转换模块3514可选地根据事件日志数据生成包括补偿本地时间的事件日志的报告以分发给请求用户。系统3500内的操作流程终止于对应于转换模块3514的完成的结束操作3516。
IV．远程用户到服务器的通信
现在参照图36至图66，公开了一种通用web服务架构，其管理用户访问诸如图1中所示的医疗设备网络中的医疗设备服务器。Web服务架构允许远程用户到服务器的通信，以提供与图1的医疗设备网络中的医疗设备有关的数据访问和编程能力。例如，用户可以在远离设备的位置执行管理任务、管理对医疗设备的软件更新、访问事件和操作记录、执行维护、改变治疗以及查看医疗设备的近实时操作。下面描述这些及其它功能。
图36示出作为图3至图4中的医疗设备网络的可能的软件架构的子系统示出的一种整体web服务架构3600。该web服务架构包括被配置为验证用户和提供对医疗设备服务器上存储的数据的访问的各种web模块或服务。在一个可能的实施例中，以使用微软公司的互联网信息服务器（Internet Information Server）的.NET架构实现web服务架构。
Web服务架构3600包括管理web服务3602、操作web服务3604和事件跟踪web服务3606。管理web服务3602验证医疗设备服务器的用户，并且包括用于登入、登出或改变用户密码的功能界面。管理web服务3602跟踪与产品、客户、联系信息、与客户相关联的医疗设备、与客户相关联的用户账户以及其它变量有关的信息。管理web服务3602使用该跟踪的信息来验证特定用户，每个用户与特定保健机构相关联，在管理web服务中称为客户。在下面的第IV．A部分中描述管理web服务3602的具体实现类。
操作web服务3604提供对医疗设备的操作数据（诸如关于治疗提供的操作数据或监测数据）的访问。操作web服务3604跟踪医疗设备中发生的各种治疗状态，并且使能可以发生以触发或跟踪医疗设备中的治疗事件的消息序列。在下面的第IV．B部分中描述操作web服务3604的具体实现。
事件跟踪web服务3606跟踪医疗设备中发生的各种事件数据，诸如医疗设备服务器接收的遥测数据。事件跟踪web服务3606使用户能够在位于远离医疗设备的位置时查看医疗设备的近实时活动，并且允许用户确定医疗设备的在线状况。在下面的第IV．C部分中描述事件跟踪web服务3606的具体实现。
A．管理
现在参照图37至图41，示出了用于管理web服务的定义和使用的系统和报告。图37示出定义管理web服务3700的示例类结构。管理web服务3700提供图36的管理web服务3602的一种可能实施例，并且可以经由诸如图3的管理web表324的多个用户界面的任意一个访问。管理web服务3700包括认证类3702、授权类3704、用户类3706、角色类3708、证书类3710、资源类3712、元数据类3714和实体设置类3716。每个类包括可以经由互联网和基于web的用户接口远程访问的若干功能以执行管理任务。下面描述各个类的功能。
认证类3702提供对管理web服务3700的初始访问，并且包括登入和登出功能。授权类3704包括多种资源控制功能以保证两个用户不同时对同一数据读取和写入，否则会引起数据冲突。授权类3704中包含的资源控制功能包括读、写、创建、删除和访问允许功能。其它功能也可以包含在授权类3704中。
每个其它类链接到授权类3704，并且每个请求对授权类3704保护的数据的读或写访问。用户类3706允许系统执行各种用户管理任务，诸如创建新用户、编辑用户信息、改变密码、删除用户、定义用户角色和检索用户历史等。其它功能也是可能的。任务类3708定义可以分配给用户的角色，并且包括创建、更新、删除或者检索管理数据中定义的各种角色的能力。角色可以对应于可以访问由医疗设备服务器或后台部件管理的数据的各种个体类别，诸如医生、护士或保健管理员等。角色还可以对应于个体所关联的各种实体。
证书类3710定义被安装到系统中以控制一次能够登入的用户的数目、以及针对各个账户定义使用模型的证书。例如，特定账户可以允许一次只有有限数目的个体查看遥测数据或访问治疗记录，或者可以定义一种针对医疗设备服务器或后台部件的跟踪使用向客户收费的方式。
资源类3712允许管理员添加或删除对应于医疗设备的特定功能区域的资源。元数据类3714提供用于将诸如对应于新引入的医疗设备的定制元数据的元数据安装到管理系统中或者安装到新引入的医疗设备本身中的基础功能。以下在图42至图43中示出用于元数据安装的示例界面。实体设置类3716允许实体设置的写入和检索。包括另外的类的另外的管理功能也可以被包含在管理web服务3700中。
图38至图41展示了用户可以访问的管理报告实例。图38至图41的管理报告对应于图3至图4中示出的报告326，并且从数据仓库322中存储的与由医疗设备服务器记录的管理事件有关的信息中得出。在本发明的一个可能的实施例中，使用微软公司的SQL服务器报告服务（Server Report Service）生成各种报告。也可以使用其它的报告和商业智能软件。
图38展示了管理跟踪事件报告3800。管理跟踪事件报告展示关于管理事件（诸如用户对医疗设备服务器的访问和连接）的详细信息。报告中实体的数目和内容对应于来自图3的管理数据316的与提交给管理web服务的查询匹配的数据。管理跟踪事件报告包括时间和日期信息3802、应用信息3804和消息信息3806。诸如代码信息、时区指示器和其它信息的另外的信息也可以可选地包括在报告3800中。
时间和日期信息3802显示与管理模块跟踪的事件有关的时间戳信息。取决于用户是选择本地时区选项还是GMT标准时间选项，时间和日期信息3802在报告上以不同的格式显示。在示出的报告3800中，选择了本地时区选项。
应用信息3804指示访问的服务或处理器，消息3806指示关于该服务或处理器所作的动作。在示出的示例中，针对标签为“MDS:Mds01”和“MDS:Mds02”的两个医疗设备服务器示出了示例连接事件。
图39展示安全事件报告3900。安全事件报告3900通常对应于管理跟踪事件报告3800，但是包括与医疗设备服务器的安全而不是对其访问有关的事件。安全事件报告3900包括时间和日期信息3902、应用信息3904和消息信息3906，每个均具有与管理跟踪事件报告3800中相同的功能。
图40展示安全事件倾向报告4000。安全事件倾向报告4000显示安全相关的事件对时间的图表。在所示出的实施例中，安全事件倾向报告4000显示按月示出安全事件的频率的条形图。显示安全事件的倾向的其它配置也是可能的。
图41展示用户历史报告4100。用户历史报告显示按时间先后顺序排列的关于一个或更多个用户的日志事件的列表。列表中每个条目包括时间和日期信息4102、分类码4104、对应于有效用户的用户名4106以及与该用户所采取的行动有关的消息4108。可选细节条目4110在原始表中显示与历史信息相关联的另外的信息，诸如会话密钥、位置、姓名、位置或用户历史中发生的其它活动。
1．元数据和包部署界面
现在参照图42至图50，示出采用元数据、固件或其它二进制数据对医疗设备服务器和医疗设备编程的各种方法。图42至图46展示可以用于在医疗设备服务器中执行各种管理任务（诸如提供或移除元数据或包）的管理表，管理表分别用于医疗设备服务器或医疗设备的配置。管理表可以对应于图3至图4的管理应用324生成的表。图47至图50展示显示元数据和包的安装结果的报告，并且是可以从图3至图4的数据仓库322中获得的报告326的子集。
图42至图43展示被配置为允许管理用户管理安装在医疗设备服务器中的元数据的用户接口，如以上在第III.A和III.B部分中所述的。图42示出初始用户界面4200，其示出当前安装到医疗设备服务器中的或者可用于安装的元数据包。列表区域4202列出包，在这种情况下显示为“虚拟输液泵”、“虚拟患者监测器”和“Medfusion 4000”。列表区域中的复选框4204允许用户选择一个或更多个安装的包，安装按钮4206将包安装到医疗设备服务器中，卸载按钮4208从医疗设备服务器中移除元数据包。
图43展示被配置为允许用户浏览元数据文件并将该文件安装到医疗设备服务器上的元数据安装界面4300。在用户界面4200中选择系统中存在的医疗设备类型之一后出现元数据安装界面4300，并且允许用户使用初始用户界面4200选择和安装与元数据的先前选择相关联的元数据文件。
图44展示提供用于分发到一个或更多个医疗设备的包的部署的包部署界面4400，如上在第III.C部分中所述的。包部署界面4400通常对应于图42的元数据安装界面4200，但是涉及要安装到医疗设备上而不是医疗设备服务器中的软件。列表区域4402列出包，在此情况中显示为“简单输液泵”或者“测试包”。列表区域中的复选框4404允许用户选择一个或更多个安装的包，部署按钮4406将包部署到医疗设备服务器中，卸载按钮4408从医疗设备服务器移除包。
在选择部署按钮4406时，显示图45中所示的用户界面4500。用户界面4500允许系统管理员在名称字段4502中录入包部署名称，并且还允许管理员分别在开始字段和结束字段4504、4506中录入开始时间和结束时间。用户界面还允许系统管理员选择包部署文件以在包部署文件选择字段4508中使用。系统管理按下部署按钮4510以部署包，或者取消按钮4512以取消部署。
在选择部署按钮4510时，显示在图46中示出的另外的用户界面4600以允许用户验证正确的包已经被选择以用于下载到医疗设备。用户界面4600在包信息字段4502中显示包部署细节，包括在先前的用户界面4400、4500中录入的所选择的开始时间、结束时间和目标类型。用户界面4600还在供应商字段4504中显示供应商属性，诸如供应商标识符、名称和供应商包的版本。
图47至图50展示从图3至图4的数据仓库322生成的与元数据定义的事件消息或包部署有关的各种报告。图47至图48涉及消息处理和从医疗设备接收的有错误的消息的调试。图49至图50展示包部署报告，包含对医疗设备成功的和不成功的软件或其它二进制数据的部署的记录。
图47展示隔离报告4700，其展示医疗设备服务器接收的隔离消息的按时间先后顺序的列表。隔离报告4700包括时间和日期信息4702、状态信息4704和消息信息4706。时间和日期信息4702显示与医疗设备服务器跟踪的隔离事件有关的时间戳信息。根据用户选择了本地时区选项还是GMT标准时间选项，时间和日期信息4702以不同的格式在报告上显示。在所示出的报告4700中，选择了本地时区选项。
状态信息4704涉及隔离消息的状态，诸如它是否是新消息、放弃的消息或者重新插入的消息。新消息指的是新定位的有问题的消息，而放弃的消息对应于不能被解决而必须放弃的消息。重新插入的消息指的是在医疗设备等待来自服务器的响应的情况下被重新引入消息服务器的那些消息。
消息信息4706描述消息传递中发生的错误。各种错误消息是可能的，通常涉及医疗设备服务器理解来自医疗设备的消息的能力。
图48展示被配置为显示医疗设备服务器接收的特定隔离消息的细节的隔离细节报告4800。隔离细节报告包括错误字段4802和源字段4804用于用户调试或者改正医疗设备服务器中的消息活动，其中错误字段4802包括显示在隔离报告4700上的错误信息，源字段4804显示消息中包括的元数据和值。也可以显示关于隔离消息的另外的信息。
图49展示包部署报告4900，其用各种类型的医疗设备和对每个医疗设备的包部署状态的关联表示出医疗设备服务器已知的包部署。包部署报告包括一个或更多个包部署条目4902，每个包括与被部署到该类型的设备的特定包有关的名称和版本信息。每个包条目包括设备子条目4904，其中每个与具有通用包部署资格的特定设备相关。子条目每个包括主机名称信息4906、物理标识信息4908、通知信息4910、传递信息4912和完成信息4914。主机名称信息4906对应于向设备提供包的医疗设备服务器。物理标识信息4908显示与医疗设备相关联的唯一的标识符。通知信息4910显示通知医疗设备可以获得该包的日期和时间。传递信息4912显示包被成功传递到医疗设备的日期和时间。完成信息4914显示包被成功应用到医疗设备的完整的日期和时间。
可以针对每个包部署跟踪另外的信息。例如，在包不能被部署的情况下，错误指示4916显示错误的指示以及错误的结果。
图50展示包部署错误报告5000。包部署错误报告5000提供针对特定包和该包部署失败的相应设备的详细事件历史。包部署错误报告5000显示包括目标医疗设备类型和包标识符的标题5002。标题还可选地显示与包部署相关联的名称。
包部署错误报告5000显示时间和日期信息5004、可选主机信息5006、物理标识符信息5008和消息信息5010。时间和日期信息5004指示包部署中的错误何时发生。可选主机名称信息5006显示医疗设备所位于的网络名称。物理标识符信息5008包括与医疗设备关联的标识符。消息信息5010显示与包部署错误相关联的消息。报告5000中也可以包括关于部署错误的另外的信息。
2．维护／故障
现在参照图51至图53，示出了与医疗设备的维护和故障有关的报告。该报告向用户提供对医疗设备上执行的维护的记录以及与医疗设备故障和那些故障的倾向有关的信息的访问。与维护或故障有关的另外的报告也可以包含在内，并且对应于医疗设备服务器收集的维护事件数据，如上在第III.B部分中所述。在一个可能的实施例中，图51至图53的报告的一个或更多个对应于图3至图4的维护表330。
图51示出列出针对各个医疗设备的维护记录的医疗设备维护报告5100。医疗设备维护报告5100包括对应于各种类型的医疗设备的类型条目5102以及对应于特定医疗设备的设备子条目5104。在示出的实施例中，类型条目5102是“MedFusion 4000”和“Titan”条目，而设备子条目5104是各个类型内的单独的行。
在每个子条目5104中，存在主机名称信息5106、物理标识符信息5108、版本信息5110、包信息5112和预防性维护日期信息5114。主机信息5106显示与医疗设备相关联的网络。物理标识符5108显示与医疗设备相关联的唯一的标识符。版本信息5110显示与医疗设备相关联的一个或更多个版本号。包信息5112显示医疗设备使用的包。预防性维护信息5114显示医疗设备预定进行预防性维护的日期。在每个子条目5104中也可以显示另外的信息。
图52示出医疗设备故障报告5200。医疗设备故障报告5200显示与传递到医疗设备服务器的医疗设备故障有关的事件，诸如由于故障电池、马达或者其它机械部件所引起的。医疗设备故障报告5200包括时间和日期信息5202、主机信息5204、物理标识符信息5206和消息信息5208。信息5202‑5208的使用类似于图50的包部署错误报告5000中的对应单元，但是涉及医疗设备故障事件。例如，在医疗设备故障报告5200中，消息信息包括设备故障事件信息，诸如医疗设备的马达、电池或者其它机械故障。
图53示出医疗设备故障倾向报告5300。医疗设备故障倾向报告5300显示医疗设备故障相关事件随时间的的图表。医疗设备故障倾向报告5300向用户提供医疗设备中重复的错误的指示，或者医疗设备故障中其它可检测的倾向。在所示出的实施例中，医疗设备故障倾向报告5300显示按月示出设备故障事件的频率的条形图。显示设备故障事件的倾向的其它配置也是可能的。
B．操作web服务：治疗状态的操作和控制
图54至图62公开了图36的操作web服务3604的各个方面。具体地，图示出了用于医疗设备网络中的医疗设备的远程操作的系统、方法和报告。在一个可能的实施例中，系统和方法通过跟踪医疗设备的原始的、更新的和最终的参数来描述对改变的治疗参数的跟踪。
图54示出用于在医疗设备服务器中跟踪治疗命令状态的方法和系统的流程图。治疗命令指的是对医疗设备的向患者提供治疗的命令。系统5400包括与治疗命令的执行过程中医疗设备中经历的各种可能状态相对应的状态。
系统5400中的操作流程以对应于向医疗设备或医疗设备服务器中引入新的治疗命令的开始节点5402开始。一旦引入治疗命令，则系统5400进入新状态5404，其指示治疗命令是新引入的并且还没有被医疗设备运行。当系统5400处于新状态5404时，用户具有取消治疗命令的选项。如果用户选择取消治疗命令，则系统5400中的操作流程前进到取消状态5406。操作流程从取消状态前进到对应于治疗模块的完成的结束节点5408。在结束节点5408，操作流程终止，并且使用医疗设备服务器跟踪的治疗提供事件继续被存储以供用户查看。
如果在系统5400处于新状态时用户选择不取消治疗命令，则操作流程前进到协助设置状态5410。协助设置状态5410试图协助设置治疗参数。如果协助设置不成功，则操作流程分支到失败状态5412。失败状态5412存储指示协助设置过程失败的错误消息。操作流程从失败状态5412前进到结束节点5408。
如果协助设置状态5410成功设置治疗参数，则操作流程分支到设置状态5414。设置状态5414指示在医疗设备中治疗被成功设置，并且准备好向患者提供。
可选地从医疗设备服务器发送或者在医疗设备处产生的开始治疗事件触发系统5400以前进到对应于在医疗设备中开始治疗提供的启动状态5416。从医疗设备或医疗设备服务器接收的结束治疗事件使系统5400中的操作流程前进到完成状态5418，其指示完成了治疗的提供。操作流程接下来前进到结束节点5408。
图55示出定义治疗服务5500的示例性类结构。治疗服务5500示出操作web服务模块3604的功能的部分。治疗服务5500链接到并使用来自图37的管理web服务3700的多种功能。
治疗服务5500包括治疗命令类5502、治疗命令规则效用（rule utility）5504和治疗命令行动列举5506。治疗命令类5502包括多种治疗命令操作，用于开始、停止和定义要由治疗服务5500在其中工作的医疗设备网络中的医疗设备提供的各种治疗。治疗命令操作包括治疗创建、治疗更新、治疗取消、治疗执行和治疗恢复操作。治疗命令类5502中也可以包括另外的治疗命令操作。
治疗命令规则效用5504提供与治疗命令的执行有关的表达和行动，包括治疗的执行所需要的各种参数和命令。治疗命令行动列举5506提供在治疗命令的选择和／或执行期间所用的提示消息。
图56展示在治疗命令管理应用5602、诸如图36中所示的操作web服务5604、如以上在图3至图4中公开的医疗设备服务器5606和诸如图2中所示的医疗设备5608之间执行的示例性的消息交换过程5600、5620、5640和5660。治疗命令管理应用5602可以是被配置为与操作web服务接口的任何应用，以将治疗命令和其它消息传递到操作服务5604和医疗设备服务器5608。
第一消息交换过程5600示出治疗命令管理应用5602，其将创建治疗命令消息5610发送到操作web服务5604。操作web服务5604验证治疗消息并将治疗命令存储在操作数据中。操作web服务5604还通过指示消息的成功或失败来响应5612。
第二消息交换过程5620示出治疗命令管理应用5602在时间上随后发送治疗命令更新消息或治疗命令取消消息5622。操作web服务5604验证治疗信息并且根据该消息更新或取消治疗命令。操作web服务5604也通过指示消息的成功或失败来响应5624。
在第一消息交换过程5600之后发生的第三消息交换过程5640示出治疗命令管理应用5602发送指示应该执行治疗命令的消息5642。治疗命令管理应用5602发送执行治疗命令消息5642到操作web服务5604，操作web服务5604验证治疗命令并且继而将治疗命令消息5642转发至医疗设备服务器5606。医疗设备服务器5606将治疗命令消息5642传递至医疗设备5608。
医疗设备5608发送指示治疗命令消息5642的接收成功或失败的消息5644。医疗设备服务器5606和操作web服务5604将消息5644传递回命令触发应用5602。
在医疗设备发送消息5644之后的一时刻，医疗设备5608发起第四消息过程5660，其中医疗设备发送治疗开始消息5662至医疗设备服务器5608，指示医疗设备已经开始向患者提供治疗。医疗设备服务器5608发送消息5662至更新治疗命令状态的操作web服务5604。医疗设备服务器还传递消息5662至诸如图36中的事件跟踪web服务5605以将治疗提供事件存储在事件历史日志中。事件跟踪web服务5605和操作web服务5604均发送指示治疗开始消息5662的接收成功或失败的响应消息5664。
由医疗设备触发的另外的事件（诸如治疗完成事件或警报）类似于消息过程5660地在部件5602‑5608间传输。此外，也可以包括另外的消息模式。
图57示出用于跟踪诸如医用输液泵的医疗设备中改变的参数的方法和系统。系统5700使用这里所描述的元数据传递用于医疗设备的操作的初始的、更新的和最终的参数，以识别参数中的各种改变。系统5700以对应于医疗设备中治疗的发起的开始操作5702开始。医疗设备中发起的治疗包括需要参数值定义治疗的各个方面的参数。例如，在由医用输液泵提供的治疗中，各种参数包括基础速率、团注速率、阈值和各种其它参数。
初始参数接收模块5704从医疗设备接收原始参数值。原始参数是在医疗设备接收到不同的参数之前在医疗设备中设置的参数，可以是与医疗设备提供的治疗的提供或者监测有关的任何类型的操作参数。更新参数接收模块5706从医疗设备接收对应于从原始参数的改变的更新参数值。更新参数值是改变医疗设备的操作的新参数值。更新参数值涉及与原始参数相同的参数。最终参数接收模块5708从医疗设备接收最终参数值。最终参数值是在采用更新参数值对医疗设备重新编程之后医疗设备将用于治疗和监测的参数值。最终参数值可能与更新参数值相同，或者可以基于例如医疗设备中对于参数设置的各种硬限制和软限制而不同。在各种实施例中，接收模块5704‑5708可以同时发生或者顺序发生，并且可以被包括在从医疗设备到医疗设备服务器的一个或更多个消息中。
参数存储模块5710将原始的、更新的和最终的参数值存储在医疗设备服务器或其它后台部件的存储器中。系统5700中包括的可选的另外的步骤可以包括将最终参数接收模块5708中接收的最终参数值与医疗设备服务器中存储的硬限制或软限制相比较。如果最终参数值超过限制，则系统5700可以在医疗设备服务器中触发警报，并且可选地经由包部署或其它消息将警报传递回医用输液泵。在另外的实施例中，警报被传递到与医疗设备相关联的医疗看护者。
操作流程终止于对应于泵参数值的改变和在医疗设备服务器或其它后台部件中存储更新的泵参数值的完成的结束操作5712。
图58示出根据图57的方法和系统列出医疗设备的原始的、更新的和最终的操作参数值的医疗设备历史报告5800。医疗设备历史报告5800包括医疗设备标签5802、日期和时间信息5804、类信息5806、触发信息5808、消息信息5810、位置信息5812和药物信息5814。医疗设备标签5802对应于其历史记录显示在报告5800中的设备的医疗设备名称。日期和时间信息5804对应于包括在医疗设备历史报告中的各事件发生的时间。类信息5806描述事件的类型和严重程度。在治疗改变事件的情况中，类信息5806还包括改变的参数的原始值、代表用户录入的值的该参数的改变值以及指示医疗设备所用的最终设置值的参数的最终值。
触发信息5808显示与医疗设备事件相关联的触发。在所示出的示例中，警报分类中的事件具有高的关注级别，并且在触发信息5808中包括警告。但是，描述治疗改变的事件将不激活触发信息5808。
消息信息5810包括关于医疗设备的状态的信息，诸如电池寿命、治疗提供过程、治疗参数限制或设备的物理特性。位置信息5812包括与医疗设备的位置有关的信息，诸如部门、机构和控制医疗设备的实体。药物信息5814包括关于医疗设备要提供的药物或治疗的信息，并且可选地只包括在用于治疗改变的信息中。基于医疗设备服务器和操作web服务跟踪的信息，关于医疗设备的另外的信息可以显示在医疗设备历史报告5800中。
图59示出治疗历史报告5900。治疗历史报告5900显示与图58的医疗设备事件历史报告5800中显示的信息相同的信息，但是将只显示治疗事件信息。治疗历史报告5900包括医疗设备标签5902、日期和时间信息5904、类信息5906、触发信息5908、消息信息5910、位置信息5912和药物信息5914，每个与医疗设备事件历史报告5800中对应的条目类似地操作。
图60示出治疗倾向报告6000。治疗倾向报告6000显示随时间的治疗相关事件的图表。在所示出的实施例中，治疗倾向报告6000显示按月示出治疗事件的频率的条形图。显示治疗事件中的倾向的其它配置也是可能的。
图61示出治疗改变历史报告6100。治疗改变历史报告6100也显示与图58的医疗设备事件历史报告5800中的信息相同的信息，但是只显示治疗改变事件信息。治疗改变事件对应于在使用医疗设备提供治疗时改变的参数。治疗改变事件报告6100包括医疗设备标签6102、日期和时间信息6104、类信息6106、触发信息6108、消息信息6110、位置信息6112和药物信息6114，每个与医疗设备事件历史报告5800和治疗历史报告5900中对应的条目类似地操作。
图62示出治疗改变倾向报告6200。治疗改变倾向报告6200显示随时间的治疗改变事件的图表。在所示出的实施例中，治疗改变倾向报告6200显示按月示出治疗改变事件的频率的条形图。显示治疗改变事件中的倾向的其它配置也是可能的。
C．事件web服务：在线状态和设备活动的查看
现在参照图63至图66，描述图36的事件web服务的各种特征。事件web服务提供一种外部应用通过其从医疗设备服务器和后台部件收集事件数据的方法。具体地，事件web服务提供医疗设备的在线状况的指示，并且还为用户提供对遥测流的访问，允许访问关于在如图1和图3至图4中描述的医疗设备网络背景中的医疗设备的操作的近实时遥测信息。
图63是用于确定医疗设备的在线状态的方法和系统的流程图。系统6300在医疗设备服务器或其它后台部件上执行，并且在预定时间段内等待来自医疗设备的通信，以便保证设备和服务器之间的准确通信。
系统6300中的操作流程以对应于医疗设备和医疗设备服务器之间的初始通信的开始操作6302开始。操作流程从开始操作6302前进到等待模块6304。等待模块6304在医疗设备服务器和／或后台部件中设置期望的预定的时间段，医疗设备服务器将在该时间段中等待通信。
接收数据操作6306确定消息是否已经被医疗设备服务器接收。如果数据已经被医疗设备服务器接收，则操作流程分支出“是”到更新医疗设备的状态以指示设备在线的更新模块6308。
可选的输出更新模块6310基于消息中接收的信息更新从医疗设备服务器输出的数据。消息中接收的信息可以包括医疗设备状态信息、事件日志数据、遥测数据或各种其它类型的数据。在一个实施例中，消息指示遥测流的开始，并且响应于来自医疗设备的消息，医疗设备服务器和后台部件更新仪表板屏幕的外观以反映所接收的遥测数据。在另一个实施例中，输出更新模块在一个或更多个后台部件中更新医疗设备的状态信息。
只要医疗设备继续处于操作中并且接收数据操作6306确定医疗设备服务器在预定时间段内继续向医疗设备发送消息，则操作流程前进通过接收数据操作6306、更新模块6308和输出更新模块6310。
如果接收数据操作6306没能在预定时间段内接收到数据，则操作流程分支“否”到离线模块6312，离线模块6312在医疗设备服务器和／或后台部件中将医疗设备的状态改变为离线。操作进程前进到可选的输出更新模块6310，其更新输出以指示当前显示的数据不再被医疗设备服务器认为是当前的，直到接收到另外的消息为止。操作流程终止于对应于医疗设备网络的操作中止的结束模块6314。
图64至图66提供用于从医疗设备接收的遥测流的操作的方法和系统。这里所描述的遥测流提供从医疗设备到医疗设备服务器的近连续的通信，并且可以在仪表板或其它web入口上查看。
图64示出用于来自医疗设备的遥测信息的近实时显示的系统和方法的流程图。系统6400中的操作流程以对应于能够在医疗设备网络中发送遥测流的医疗设备的初始操作的开始节点6402开始。新状态6404指示遥测流先前没有流动。在新状态之后，流启动过程试图来使遥测流，如下面在图65中所示。如果流启动过程失败，则操作流程前进到对应于不能开始遥测流的失败状态6406。然后操作流程前进到结束节点6408。
如果流启动过程成功地开始，则操作流前进到对应于医疗设备服务器从医疗设备收集遥测数据的收集状态6410。在收集状态下，遥测数据可以被存储在医疗设备服务器或其它后台部件中，并且还可以被输出至仪表板或其它监测用户界面。
从收集状态6410，多种可能的选项影响系统6400的操作流程。如果包括遥测流消息的消息没有在医疗设备服务器或后台部件中设置的预期的预定时间内从医疗设备发送到医疗设备服务器，则操作流程前进到离线状态6412。离线状态6412对应于系统不再规则地接收遥测数据。如果之后收到遥测报告，则系统6400返回到收集状态6410。
如果遥测流被用户暂停，则操作流程前进到对应于只是暂时不接收遥测数据的系统的暂停状态6414。用户可以重新开始遥测流以将系统6400返回到收集状态。
可以通过用户终止流或者系统以另外的方式接收到医疗设备断电事件而从收集状态6410、离线状态6412或者暂停状态6414到达终止状态6416。终止状态6416对应于结束遥测流。在终止状态下，系统不再从医疗设备接收信息，并且不更新仪表板。在一个可能的实施例中，当系统6400处于终止状态时，仪表板或其它监测界面向用户指示当前没有收集数据。操作流程从终止状态前进到结束节点6408。
图65展示在仪表板6502（诸如图67中所示的那个）、事件跟踪web服务6504（诸如图36中所示的那个）、医疗设备服务器6506（如以上在图3至图4中公开的）和医疗设备6508（诸如图2中所示的）之间执行的示例遥测流消息序列6500、6520、6540和6560。第一遥测流消息序列6500示出发起从医疗设备到仪表板的遥测流的请求。消息序列6500通过仪表板6502向事件跟踪web服务6504发送开始遥测流消息6510而开始。事件跟踪web服务将消息6510传递到医疗设备服务器6506，医疗设备服务器6506继而将消息6510传递到医疗设备6508。医疗设备生成指示消息的成功或失败的响应消息6512。响应消息由医疗设备服务器6506和跟踪web服务6504传递回仪表板6502。
第二遥测流消息序列6520示出由医疗设备6508进行的遥测流的发起。医疗设备6508生成包括从医疗设备6508到医疗设备服务器6506的遥测数据的近连续通信的遥测事件6522，医疗设备服务器6506经由事件跟踪web服务6504将遥测数据传递到仪表板6502。仪表板6502以近实时方式向用户显示遥测数据。在一个实施例中，仪表板重建医疗设备的外观。仪表板将响应消息6524发送至事件跟踪web服务6504，指示遥测流的成功接收。
仪表板6502生成获得遥测窗口消息6526并且将该消息发送至事件跟踪web服务，事件跟踪web服务用指示命令的成功或失败的消息6528响应。在此时启动遥测窗口，并且仪表板或web入口将显示遥测数据。
此时如果医疗设备断电，则事件跟踪web服务6504将用失败消息响应并且终止遥测流。
第三遥测流消息序列6540示出通过关闭生成遥测流的医疗设备来结束遥测流。医疗设备6508生成断电事件消息6542并且将消息发送至医疗设备服务器6506。医疗设备服务器将终止遥测流消息发送至事件跟踪web服务6504。事件跟踪web服务6504生成指示消息6542的接收成功或失败的响应消息6544。医疗设备服务器6506将响应消息6544传递至医疗设备6508。
第四遥测流消息序列6560与序列6540相关并且示出通过在仪表板6502处中断遥测流来结束遥测流。仪表板6502生成从仪表板传递到事件跟踪web服务6504并且转而通过医疗设备服务器6506以传递到医疗设备6508的终止遥测流消息6562。医疗设备6508终止其遥测流并且生成指示消息6562的接收成功或失败的响应消息6564。医疗设备服务器将消息6564通过事件跟踪web服务6504传递到仪表板6502。为了使用根据本发明的医疗设备和仪表板开始和终止遥测流，另外的消息过程是可能的。
图66示出定义遥测流类6600的示例性类结构。遥测流结构6600示出事件web服务模块3606的功能的一部分。遥测流涉及并且使用来自图37的管理web服务3700的多种功能。
遥测流结构6600包括遥测流类6602和最新事件类6604。遥测流类6602包括多种遥测相关的操作，包括开始、终止、暂停和恢复可用的遥测流。在遥测流类6602中也可以包括另外的遥测流操作。最新事件类6604包括用于检索最新事件的功能，以便确定何时从医疗设备接收最近的事件，从而确定医疗设备的在线状况，以便确定可获得遥测流数据。最新事件类6604中可以包括另外的功能，并且可以向遥测流结构6600添加另外的类。
各种示例性仪表板可以用于在其它计算设备的工作站上查看遥测数据。图67中示出一个示例仪表板。仪表板6700显示涉及其所关联的泵的遥测数据（例如，当前或者接近当前的操作状态）。仪表板6700可以是被配置为以近实时方式接收并向用户显示遥测数据的多种仪表板应用中的任意一种，并且可以对应于例如逻辑上示出为图3至图4的仪表板328的仪表板。仪表板6700可以由遥测流更新，诸如以上在图61至图66中所述的。
在所示出的实施例中，仪表板6700关于与仪表板相关联的每个医疗设备跟踪名称6702、标识符6704、域6706、地址6708、端口6710和活动历史6712。名称6702对应于用户可以识别的设备的名称，其由设备本身或服务器分配。标识符6704提供服务器可以使用的唯一标识以验证医疗设备的身份。在各种实施例中，标识符可以对应于全局唯一的标识符（GUID）、硬件地址或医疗设备的其它标识。域6706指示医疗设备位于的网络的名称。地址6708提供关于如何从服务器与医疗设备通信的连接信息。在所示出的实施例中，地址6708示出为医疗设备的IP地址。端口6710列出医疗设备的入站通信端口。活动历史字段6712列出医疗设备上发生的并且传递到服务器的最近的事件的日期和时间。
仪表板6700图形地示出与其相关联的泵的操作状况。在所示出的实施例中，在仪表板6700中跟踪5个医疗设备，名为“MD0333”、“MD0444”、“MD0524”、“MD0324”和“MD0988”。第一、第四和第五设备（MD0333、MD0324和MD0988）被示出为上电的并且正在向患者提供治疗。第二设备（MD0444）被示出为处于警报状态，指示设备可能操作不正常或者与该设备所关联的患者有关的紧急情况。第三设备（MD0524）示出为处于故障状态，指示在该医疗设备中发生故障或者错误。在仪表板6700上也可以示出说明操作状况的其它状态。
可选地，在仪表板6700中可以包括允许用户过滤或显示不同类型的信息的另外的特征。在所示出的实施例中，暂停复选框6714和离线设备复选框6716允许用户可选择地修改仪表板。当选择暂停复选框6714时，它使仪表板“冻结”以暂时停止仪表板上的信息的更新以允许用户查看单个时刻仪表板的状态。当不选择暂停复选框6714时，只要从所关联的医疗设备接收数据，仪表板上的状况信息就可以持续更新。离线设备复选框6716使仪表板能够显示与该仪表板所关联的设备有关的信息，但是该设备不在线并且仪表板没有从其接收最近的状况信息。其它的显示特征和过滤器也可以包含在仪表板中，允许用户选择期望的设备组来监测并且允许用户查看从那些用户接收的遥测数据的特定部分。
以上描述的各个实施例只是为了说明而提供的，不应该被认为限制了本发明。本领域的技术人员将容易地认识到可以对本发明进行各种修改和改变，而不遵循这里所示出和描述的示例实施例和应用，并且不脱离在所附权利要求中阐明的本发明的真实精神和范围。