CN107580706A - 用于协调和控制输液泵的系统和方法 - Google Patents

Abstract

一种用于实时控制至少一个输液泵的实时嵌入式服务器系统。所述嵌入式服务器系统包括存储器和处理器的嵌入式服务器，所述处理器电耦合到所述存储器并且被配置成实施：被配置成向至少一个输液泵发布控制命令的控制引擎，被配置成向至少一个输液泵发布消息并且从所述至少一个输液泵接收消息的信息传送引擎，被配置成聚合与所述至少一个输液泵的所述操作相关的数据的聚合引擎，和被配置成控制所述嵌入式服务器和所述至少一个输液泵的网络接入的联网引擎。一种患者护理系统包括被配置成做出患者‑特定护理决策的至少一个嵌入式服务器控制装置和可操作地耦合到患者并且被配置成由所述至少一个控制装置控制的相关联的装置网络。

Description

用于协调和控制输液泵的系统和方法

技术领域

本发明的主题大体上涉及医疗装置，并且更具体地说涉及用于协调和控制输液泵的系统和方法。

背景技术

输液泵是用于向患者提供规定的流体、药物和其它治疗的有用的医疗装置。举例来说，药品(如抗生素、化学治疗药物、麻醉剂和疼痛缓解剂)通常经由输液泵递送到患者，同样的为营养物和其它补充剂。输液泵已经用于医院、疗养院，和其它短期和长期医疗机构，以及用于家庭护理。输液泵可尤其适用于需要延长其投予时间段的医学治疗的递送。存在许多类型的输液泵，包含大容量、患者控制的镇痛(PCA)、弹性、针筒、肠内和胰岛素泵。输液泵通常适用于多种药品递送路线，包括静脉内、动脉内、皮内、皮下、腹膜内、非常接近于神经且进入手术中的部位、硬膜外空间或蛛网膜下隙中。

传统地，输液泵经由单个输液泵的编程本地控制，这通常在泵自身上完成。举例来说，医生可对输液泵进行配置以实行对应于患者的处理需求的递送配置文件，或者患者可在预定限制内根据其个人需求在没有医生参与的情况下对输液泵进行配置。医生或患者可根据某些生理、药物代谢动力学和通常预定的操作参数或界限值通过泵介面的物理操控编程或配置输液泵。

计算机网络技术的近来的发展已导致并入与输液泵接口的远程服务器。传统地，远程服务器为非实时的。即，操作人员通常需要“在循环中”以运行泵和其相关联系统。虽然大多数非实时服务器可被配置成处置信息传送和编程数据，但是它们通常不具有快速、可靠的响应时间。经配置用于与输液泵一起使用的传统的远程服务器通常不控制泵送的速率或提供其它直接操作控制。实际上，传统的远程服务器通常提供用于使用的泵的初始设定或初始配置编程。传统的远程服务器还可并入泵数据用于医院信息系统(HIS)记录。然而，一般来说，传统的远程服务器控制不足够可靠以自主地控制输液泵，这是由于耦合的网络的不定性、服务器-网络系统的固有时延、控制的远程源的患者护理暗示，以及其它问题，包括实践形式和安全问题。如在整个本公开中所使用的，术语“远程服务器”旨在包括被配置成实时协调和控制的外部和网络-耦合计算装置、用于患者护理的一个或多个输液泵或相关联医疗装置。

此外，多种医疗装置通常耦合到患者用于患者护理的各种方面。举例来说，患者可耦合到一个或多个输液泵、脉搏血氧定量计、血压监测器等。这些装置通常独立于彼此起作用并且通常不彼此连接。因此，患者护理通常特用或通过历史静态协定驱动。此外，国际疾病统计分类(ICD)编码，出于流行病学、健康管理、计费和保险覆盖范围测定和临床目的的国际标准诊断工具一般来说，通常在已提供护理之后为静态和指定的。

计算技术近来的进展已导致所谓的“智能”装置，其包括用于临床决定支持使得装置不再“非智能”(并且因此不需要操作人员如先前装置一样深入地编程)的咨询和信息软件。然而，将泵“智力”放置在耦合到患者的每个装置上可过分地昂贵。另外，可不可管理以具有与外部网络或外部服务器或装置通信的多种装置，因为这可引起多次点击网络，导致延迟和网络过载以及其它令人讨厌的低效，或甚至在患者护理中的延迟、省略，或错误的潜在危险源。

另外，关于单个患者的多种医疗数据系统(例如多种医疗装置的电子医疗记录(EMR)、医院信息系统(HIS)和信息技术(IT)系统)通常不互连并且独立于彼此起作用以与这些装置接口。这类缺乏在系统中的协调还可便于损害执业医生工作负荷、低效率和如前述对患者的潜在危险的提高。举例来说，最近已观察到单个数据系统或控制用于单个患者的若干输液泵的协调的多种数据系统在其中药物用于抵消另一种药物的副作用情况下可为有利的。否则，如果向患者递送药物被独立地控制，那么两种药物可有害或甚至危险地冲突或彼此反应。

因此，需要用于协调和控制输液泵的系统和方法，如被配置成协调和聚合一个或多个输液泵的实时嵌入式服务器。另外，需要被配置成由充当嵌入式服务器的联网的装置中的一个控制的相关联的患者护理装置网络的系统和方法。

发明内容

在本文中描述或另外涵盖的实施例基本上满足前述需求。用于协调和控制输液泵的系统和方法的实施例提供被配置成协调和聚合一个或多个输液泵的实时嵌入式服务器。在一个实施例中，实时嵌入式服务器系统包括在与患者相同房间中的服务器(和一个或多个泵)，代替如在传统的服务器实施方案中服务器被远程安置并且经网络连接。实时系统的实施例克服传统的非实时服务器的时延和可靠性问题。此外，实施例不仅提供用于便于多个泵的用户接口控制的中央控制或“大脑”，而且提供系统，通过所述系统装置的全部患者护理套件可通信和被控制。实施例执行为实时系统，包括状态共享和控制。根据实施例，嵌入式装置可包括在对于特定应用是唯一的特定硬件上可实行的任何装置。嵌入式软件可包含用于特定硬件的控制指令。在一个实施例中，服务器在一个泵或多个泵的外部，但是安置在泵的支架中。因此，这类实时嵌入式服务器可协调多个泵，包括例如管理药物、过敏和途径相互作用。另外，可协调切换中继、主从和其它泵/输液相互作用。此外，嵌入式服务器提供借助于常见支架耦合的泵的操作控制以及泵的初始设定和初始配置编程。在支架内实施的实时嵌入式服务器的实施例另外提供如机械稳定性、配电、实时通信的益处，并且促进仅在正确的泵之间，即，仅在实际旨在用于通信的那些泵之间的通信。此外在实施例中，可能有利的是在一个泵或多个泵外部但是在泵的支架中提供嵌入式服务器，使得出于能量考虑(例如，一个泵或多个泵的电池电源对支架的市电)，嵌入式服务器可能够具有更大处理功率和存储能力，并且因此能够执行更复杂的处理算法。在一个实施例中，嵌入式服务器可以使得其将被阻止变得或正在表征自身为医疗装置的方式具体实施，使得嵌入式服务器的安全可更容易并且快速地更新为可在特定护理设定中期望的。

在用于实时控制至少一个输液泵的嵌入式服务器系统的一个实施例中，系统包含多个输液泵，其中输液泵中的每个包括被配置成接收控制命令并且控制其对应的泵送机理的操作的泵送机构和可编程回路。在这类实施例中，每个泵可向患者递送不同输注液。替代地，在这类实施例中，泵中的一些可被配置成在相同处方下以输液中继方案或技术向患者递送相同输注液。实时嵌入式服务器包括存储器和处理器，所述处理器电耦合到存储器并且被配置成实施：被配置成向至少一个输液泵发布控制命令的控制引擎，控制命令与至少一个输液泵的操作相关，被配置成向至少一个输液泵发布消息并且从其接收消息的信息传送引擎，被配置成聚合与至少一个输液泵的操作相关的数据的聚合引擎，和联网引擎；和可操作地耦合多个输液泵和嵌入式服务器的网络，其中联网引擎被配置成控制嵌入式服务器和至少一个输液泵的网络接入。

在一个实施例中，用于用实时嵌入式服务器控制多个输液泵的方法包含实施实时嵌入式服务器，嵌入式服务器包括控制引擎，控制引擎被配置成向至少一个输液泵发布控制命令，控制命令与至少一个输液泵的操作相关；实施至少一个输液泵，至少一个输液泵被配置成从嵌入式服务器接收控制命令；实施可操作地耦合嵌入式服务器和至少一个输液泵的网络；将来自控制引擎的控制命令向至少一个输液泵发布；和基于控制命令实行至少一个输液泵的操作模式。

在一个实施例中，用实时嵌入式服务器聚合与多个输液泵相关的数据的方法包含用实时嵌入式服务器从第一输液泵接收第一数据，第一数据包含与第一输液泵的操作相关的数据；存储接收的第一数据；用嵌入式服务器从第二输液泵接收第二数据，第二数据包含与第二输液泵的操作相关的数据；存储接收的第二数据；和对存储的第一数据和存储的第二数据执行聚合算法。

在实施例的特征和优点中，系统用实时服务器实施输液泵的网络耦合，使得降低或去除传统网络的不确定性。举例来说，在实施例的私网中，网络不经历传统联网的服务器的中断、外部安全弱点和数据过载。通过实施专属服务器和泵的网络，这些资源可集中在其对应的泵-特定任务上，可能没有中断。

在实施例的另一个特征和优点中，系统可以最小时延实施。举例来说，通过利用用于输液泵的管理的网络和服务器带宽，相较于传统联网的服务器(其通常需要处置非输液泵相关数据和任务)降低时延。另外，如本文所描述的用于输液泵的管理单独实施的专用服务器比传统联网的服务器较不易错。

在实施例的另一个特征和优点中，最小化中断医疗人员的惯例。举例来说，执业医生(如经过授权的护士)可在单个护理点的单个位置处控制用于一个患者或多个患者的所有的泵。这类系统可被配置成类似于其中医疗人员习惯的工作流程执行，这有助于培训和实施接受性和顺从性。

在实施例的另一个特征和优点中，相较于传统联网的服务器，降低安全问题。在实施例中，服务器在被设计成通过外部装置和外部网络不可接入的闭路或私网上实施。因此，在这类实施例中，对于恶意用户接入服务器、网络和泵将为困难的。

在实施例的另一个特征和优点中，实时嵌入式服务器被配置成协调和聚合多种类型的输液泵。举例来说，在一个实施例中，实时嵌入式服务器可被配置成协调SmithsMedical MEDFUSION泵，其可各自具有其自身控件、协定和用户接口。在实施例中，实时嵌入式服务器可被配置成协调除Smiths Medical MEDFUSION泵之外的泵，其同样地可各自具有其自身控件、协定和用户接口。

在实施例的另一个特征和优点中，实时嵌入式服务器还可被配置用于处置在泵和外部系统之间的信息传送业务量。举例来说，实时服务器可协调或聚合从泵到医院信息系统(HIS)或其它外部系统或子系统的通信。在实施例中，实时服务器可被配置成聚合关于从泵到HIS的输液的数据。

在实施例的另一个特征和优点中，实时嵌入式服务器在实时环境中实施。举例来说，在无传统网络的前述延迟的情况下，服务器可紧接着响应(或几乎如此)于所述服务器可操作地耦合和控制的输液泵。在实施例中，实时嵌入式服务器实施从输液泵到所述服务器可操作地耦合以向患者提供响应性护理的输液泵的反馈回路。通过实时服务器实施的算法或工作流程可根据系统和泵的状态或患者的病况评估来自对应的输液泵或多个泵的信息传送，通知医疗人员系统的当前状态或操作状态，或建议执业医生将采用的推荐动作，或甚至调节或改变对于那些泵的控制。

根据另一个实施例，患者护理系统包含被配置成做出患者-特定护理决策的至少一个控制装置和可操作地耦合到患者并且被配置成由至少一个控制装置控制的相关联的装置网络。

在另一个实施例中，电子患者护理系统包含至少一个医疗装置、嵌入式实时服务器和包括电子医疗记录(EMR)系统或医院信息系统(HIS)中的至少一种的至少一个信息技术(IT)系统，其中嵌入式实时服务器提供在至少一个医疗装置和至少一个IT系统之间的通信桥，因此至少一个医疗装置和至少一个IT系统选择性地互连以为患者提供通知和建议治疗。

在实施例的特征和优点中，将所谓的“智力”添加到以前“非智能”装置为有成本效益的。举例来说，“非智能”装置网络可根据患者的护理需求相对简单并且便宜地实施。装置中的一个可用用于自身和多个非智能装置的控制逻辑智力实施。这类系统比单独包含“智能”装置的联网系统或并入昂贵服务器以与非智能装置接口的系统价格低廉。

在实施例的另一个特征和优点中，具有一个控制装置的系统比具有带有控制能力的多个装置的传统系统更简单地控制。单个控制点减轻医学专业人员的记录负荷或“知道”耦合到患者的所有装置和每个装置对应的进展。单个控制装置的实施例可被配置成自动评估患者和耦合到患者的装置以及对患者的对应的输液或治疗。

在实施例的相关特征和优点中，可实施耦合到患者的多个装置的动态控制。与其中所有的装置独立于彼此起作用并且通常不彼此连接的传统系统相比，动态控制允许在通知建议内容中实时修改在耦合到患者的装置中的患者的推荐改变治疗或改变监测。在一个实施例中，所有装置可修改或推荐修改。在另一个实施例中，耦合的装置的子集可修改或推荐修改。因此实施例另外与传统系统对比，由此患者护理为特用或通过历史静态协定驱动。

在实施例的另一个特征和优点中，单个控制装置被配置成与医院的多种外部医疗数据系统或患者护理网络接口。因此，由控制装置报导的数据可有助于来自外部医疗数据系统的患者护理。因此获得系统的更简化的(streamlined)网络，因为单个控制装置可被配置成通过单独的嵌入式服务器或直接与外部系统接口，代替在网络中的患者护理装置中的每个被配置成与外部系统中的每个接口。此外，通过接口到网络或嵌入式实时服务器的单个控制装置，代替多个装置，可避免传统系统的多次网络点击、延迟和网络过载。

在实施例的另一个特征和优点中，从“非智能”装置过渡到“智能”装置通过如本文中所公开的控制装置和嵌入式实时服务器的实施例促进。举例来说，服务器-泵系统可用被配置成用于协调和控制在患者房间中的多个“非智能”装置的实时服务器实施。随后，医院或临床工作流程期望的是，“非智能”装置中的一个可退除并且被被配置成协调和控制剩余的多个“非智能”装置的相对应的控制装置替换。因此，在患者房间中分散的实时服务器可退除。

以上发明内容并不旨在描述每个说明的实施例或此处主题的每一种实施方案。附图和下文具体实施方式更具体地举例说明这些实施例。

附图说明

考虑以下结合附图的各种实施例的详细描述可更全面地理解本发明主题，其中：

图1A为根据实施例的针筒型输液泵的实例的透视图。

图1B为根据实施例的步行型输液泵的控制模块的实例的正视图。

图2为根据实施例的并入实时嵌入式服务器的输液泵系统的框图。

图3为根据实施例的用于多个输液泵的实时嵌入式服务器系统的框图。

图4为根据实施例的包括实时嵌入式服务器和多个输液泵的输液泵支架系统的框图。

图5为根据实施例的实时嵌入式服务器的框图。

图6为根据实施例的实时嵌入式服务器系统和外部医院信息系统的框图。

图7A为根据实施例的包括在嵌入式服务器和输液泵之间信息传送业务量的实时嵌入式服务器系统的框图。

图7B为根据实施例的描绘图7A的信息传送业务量的存储的图7A的嵌入式服务器的框图。

图8为根据实施例的用实时嵌入式服务器控制多个输液泵的方法的流程图。

图9为根据实施例的用实时嵌入式服务器聚合与多个输液泵相关的数据的方法的流程图。

图10为根据实施例的患者护理网络的系统的框图。

图11为根据实施例的分散型嵌入式服务器系统的框图。

图12为根据实施例的通知-建议-控制医疗装置方案的流程图。

图13为根据实施例的与期望和实际患者特征值组合的相对于时间的药品投予的图。

图14为根据实施例的包括至少一个嵌入式服务器控制装置的患者护理系统的框图。

图15为根据实施例的用于患者护理系统的实例通信接口的框图。

虽然实施例容许各种修改和替代形式，但其细节已借助于实例在附图中示出且将详细地描述。然而，应理解，并非打算将此处的主题限于所描述的特定实施例。相反地，打算涵盖属于此处根据所附权利要求书的主题的精神和范围内的所有修改、等效物和替代方案。

具体实施方式

图1A和1B分别示出输液泵100和150(在本公开中更一般地还由数字100表示)的实例，所述输液泵可用来实施本文中论述的系统和方法的实施例。一般来说，输液泵100为可用来递送广泛范围的输注液、药物疗法和治疗的针筒型泵。输液泵100包括药品容器或针筒110，所述药品容器或针筒110通过夹具130分别支撑在外壳120上并紧固到所述外壳120。在实施例中，针筒110可由泵100单独供应。在其它实施例中，针筒110为泵100的集成部件。针筒110包括柱塞140，所述柱塞140迫使流体经由连接到患者的输液管线160从针筒110向外流出。在泵100的外壳120的内部的马达和导螺杆布置协作致动推动器或柱塞驱动器机构170以移动柱塞140。在实施例中，传感器(未示出；其通常为柱塞驱动器机构170所固有)根据系统说明书监测针筒中的力和/或柱塞位置。在实施例中，柱塞在针筒中的位置可在除柱塞驱动机构170之外的部件的位置处或借助于所述位置监测。

在图1B中所示的输液泵150为可用于递送广泛范围的输注液、药物疗法和治疗的步行输液泵控制模块的实例。这类步行泵可由用户舒适地穿戴或以其它方式借助于皮带、绑带、夹具或其它简易紧固装置可移除地耦合到用户以用于家庭步行护理，且替代地还可设置于医院和其它药物护理设施内的安装在杆上的步行布置中。输液泵150通常包括蠕动型输液泵机构，其控制从耦合到泵150的控制模块的流体的储层(在图1B中未示出)通过来自储层的导管的药品流动，所述导管沿泵150的控制模块的底表面180以配合方式传递。储层可包含在表面180处附接到泵150的底部的盒，或者在表面180处经由适配器板(未示出)以类似方式连接到泵150的IV袋或其它流体源。具体地说，泵150使用阀和位于或靠近底表面180的冲出器以选择性地挤压连接到储层的流体管道(未示出)，从而实现由储层供应的流体以蠕动泵送的方式移动通过管道并到达患者。输液泵100和150为适合与本文中论述的实施例一起使用的输液泵的两个实例，尽管其它泵和装置可用于利用本文的主题的输液系统的其它实施例。

图2为输液泵系统200的实例的示意图。系统200通常包括输液泵210和实时嵌入式服务器215。在其它实施例中，如将描述，多个输液泵210可可操作地与嵌入式服务器215耦合。

在一个实施例中，输液泵210包括泵控制系统245，所述泵控制系统245具有处理器250和存储器255，所述泵控制系统245可由选定协议、配置文件、配置文件片段和其它设置进行编程以控制泵送机构260(例如，前述针筒和步行型或蠕动型机构)的操作。

在一个实施例中，处理器250可为接受数字数据作为输入的任何可编程装置，其被配置成根据指令或算法处理所述输入并提供结果作为输出。在一个实施例中，处理器250可为被配置成执行计算机程序的指令的中央处理单元(CPU)。在另一个实施例中，处理器250可为应用专用集成电路(ASIC)。在另一个实施例中，处理器250可为现场可编程门阵列(FPGA)。处理器250因此被配置成执行基本算术、逻辑和输入/输出操作。

存储器255根据已耦合处理器250的需要可包括易失性或非易失性存储器以不仅提供实行指令或算法的空间，而且还提供存储指令本身的空间。在实施例中，易失性存储器可包含例如随机存取存储器(RAM)、动态随机存取存储器(DRAM)或静态随机存取存储器(SRAM)。在实施例中，非易失性存储器可包含例如只读存储器、快闪存储器、铁电RAM、硬盘、软盘、磁带或光盘存储装置。前述列表决不限制可使用的存储器的类型，因为这些实施例仅借助于实例给出而并不意欲限制本发明的主题的范围。

输液泵210还可包括控制模块220(例如，用户接口)以用于将命令中继到泵控制系统245。控制模块220包括利用操作员输入技术的至少一个用户接口230，所述用户接口230包括与显示器225一起工作的(一个或多个)输入机构235。在一些情况下，显示器225将被视为(一个或多个)用户接口230的一部分。用户接口230通常允许用户键入各种参数，包含但不限于名称、药物信息、限制、递送形状、关于医院设施的信息、以及各种用户特定参数(例如，患者年龄和/或体重)。在其它实施例中，如将描述，控制模块220可与来自嵌入式服务器215的输入、命令或其它编程联合操作。在其它实施例中，控制模块220可被来自嵌入式服务器215的编程绕过。在其它实施例中，控制模块220可从输液泵210物理地省略，使得控制通过嵌入式服务器215经由I/O端口240进行。

输液泵210可包括双向串行通信端口，例如USB端口、网络通信端口，或用于将输液泵210连接到嵌入式服务器215或另外建立在它们之间的通信路径或多个路径的其它适当接口输入/输出(I/O)端口240。在实施例中，I/O端口240可被配置成用于有线或无线通信，如通过例如一种或多种有线或无线连网技术，包括乙太网、一个或多个802.11标准、蓝牙和超宽带联网技术。虽然在图2中未说明，但是应理解，向输液泵210提供功率可通过例如AC或DC电源线或电源，或内部提供的电池源实现。实施例还可包括无线电源。

嵌入式服务器215包含在输液泵210外部但是被配置成用于通过I/O端口240与输液泵210通信的装置。在实施例中，嵌入式服务器215包含被配置成接口到多个输液泵和/或外部系统的专用、非通用计算机软件。举例来说，嵌入式服务器215被配置成协调输液泵210用于泵送操作。在一个实施例中，嵌入式服务器215另外被配置成处置在输液泵210和一个或多个外部系统(在图2中未说明)例如医院信息系统(HIS)或电子医疗记录(EMR)系统之间或在泵之间的信息传送业务量。在实施例中，嵌入式服务器215另外被配置成用于聚合在输液泵210和一个或多个外部系统之间的信息传送业务量。

如图2中所描绘，输液泵210经由泵送机构260可操作地耦合到储层265。在实施例中，储层265可包含任何合适的输注液供应装置，如IV袋、针筒、连续供应装置或其它输注液存储装置。在一个实施例中，储层265通过适合于将存储在储层265中的输注液转移到泵送机构260的插管或管耦合到泵送机构260。虽然在图2中未描绘，但是还应了解，通过泵送机构260起作用的储层265的内容物将随后通过任何合适的部件，例如IV输液管线递送到患者。

参考图3，描绘用于多个输液泵304a到304c的实时嵌入式服务器系统300的实例的框图。系统300通常包含嵌入式服务器302、多个输液泵304a到304c和私网306。

如下文将另外描述，嵌入式服务器302通常包含专用、非通用计算机软件，其被配置成接口到多个输液泵和/或与输液泵和/或患者护理相关联的外部系统。在一个实施例中，嵌入式服务器302在所选特征上可部分或全部类似于嵌入式服务器215。在一个实施例中，嵌入式服务器302或嵌入式服务器302的部件可在输液泵304a到304c中的一个内实施。在另一个实施例中，嵌入式服务器302可在另一个输液泵(未示出)内实施。

输液泵304a、304b和304c各自包含用于向一个或多个患者提供规定的流体、药物和其它治疗和输注液的输液泵。举例来说，在一个实施例中，输液泵304a可可操作地耦合到第一患者。同时，输液泵304b和304c可可操作地耦合到第二患者。在另一个实施例中，输液泵304a可可操作地耦合到第一患者，输液泵304b可可操作地耦合到第二患者，并且输液泵304c可可操作地耦合到第三患者，其条件是在这类实施方案中解决合适的安全问题。举例来说，在一些患者护理情形中，可不谨慎交叉或分配在单独患者之间的泵和传感器的一个特定本地子网的信号。在另一个实施例中，所有三个泵304a到304c可可操作地耦合到患者。因此，嵌入式服务器302可控制到一个患者或若干患者的输液泵304a到304c的配置的任何组合。

在实施例中，一个或多个输液泵304a到304c可各自包括其自身控件，如控制模块220，再次参考图2。在这类实施例中，输液泵304a到304c的控件可被来自嵌入式服务器302的编程绕过。在其它实施例中，一个或多个输液泵304a到304c可在无控制模块的情况下并且实际上依赖于通过嵌入式服务器302发布的控制命令实施。在其它实施例中，一个或多个输液泵304a到304c可各自包括其自身控件，如在图2中的控制模块220。在这类实施例中，输液泵304a到304c的控件可被来自嵌入式服务器302的编程绕过。在其它实施例中，一个或多个输液泵304a到304c可在无控制模块的情况下并且实际上依赖于通过嵌入式服务器302发布的控制命令实施。

虽然描绘三个输液泵304a、304b和304c，但是如通过实例所描述或在本文中另外涵盖的系统的实施例可包含附加或较少输液泵。应理解和了解，系统300可容易地可扩展多个输液泵。另外，例如输液泵304a可具有与输液泵304b不同的类型。在其它实施例中，所有的输液泵304a到304c可具有相同类型或不同类型。单个泵识别可通过嵌入式服务器302进行。另外，嵌入式服务器302可确定泵类型、功能性和其它状态，以便协调在多个泵之间的一个患者或多个患者的护理。

在一个实施例中，如图3所描绘，嵌入式服务器302经由网络306可操作地耦合到输液泵304a到304c。在一个实施例中，用于安全和保密，网络306为单独利用以将嵌入式服务器302耦合到输液泵304a到304c的闭路私网。在一个实施例中，网络306可实施任何合适的有线或无线联网技术，包括乙太网、802.11标准中的一个或多个、蓝牙和超宽带联网技术等等。在其它实施例中，网络306通过硬件或软件分离，使得网络306的第一部分为私人的以可操作地将嵌入式服务器302耦合到输液泵304a到304c，并且网络306的第二部分为半私人的(但是仍然受限制)以可操作地将嵌入式服务器302耦合到外部网络或系统。在一个实施例中，路由器或集线器可在网络306上实施以提供这类分离。在一个实施例中，网络306因此提供在嵌入式服务器302之间的连接以接口到输液泵304a到304c并且提供输液泵304a到304c的实时控制。

在一个实施例中，嵌入式服务器302可被配置成发送通过网络306路由到全部可操作地耦合的输液泵的一个命令。在其它实施例中，单个消息或命令路由到特定泵或从特定泵路由。举例来说，嵌入式服务器302可经网络306发布泵识别请求以发现连接到网络的输液泵并且因此通信地耦合。在其它实施例中，泵标识可经网络306被传输到嵌入式服务器302，而不从嵌入式服务器302请求。举例来说，输液泵304a到304c可被配置成一旦在网络306上激活就传输识别信息。在实施例中，网络306可包括路由信息，使得一旦由嵌入式服务器302发布网络306就可将特定消息或命令转发到特定输液泵。

参考图4，描绘包括实时嵌入式服务器402和多个输液泵的输液泵支架系统400的实例的框图。在一个实施例中，输液泵支架400含有、包含或以其它方式可操作地耦合到服务器402和输液泵404a到404g。应理解，在实施例中，类似于相对于图4的嵌入式服务器302的讨论，在一个实施例中，嵌入式服务器402或嵌入式服务器402的部件可在输液泵404a到404g中的一个内实施。在另一个实施例中，嵌入式服务器402可在另一个输液泵(未示出)内实施。

举例来说，输液泵支架400通常包含主体408、多个泵安装部分410a到410g，和至少一个服务器安装部分412。如图4所描绘，泵安装部分410a提供孔隙以定位和将输液泵404a可操作地耦合到支架400。同样地，泵安装部分410b提供孔隙以定位和将输液泵404b可操作地耦合到支架400。泵安装部分410c提供孔隙以定位和将输液泵404c可操作地耦合到支架400等，其中泵安装部分410d到410g分别提供孔隙以定位和将输液泵404d到404g可操作地耦合到支架400。输液泵404a到404g到单个支架400或在单个支架400内的这类物理和通信耦合允许输液泵404a到404g专用实施和独特输液，如相对于彼此的捎带和接管模式。

服务器安装部分412提供孔隙以定位和将服务器402可操作地耦合到支架400。在实施例中，可包括附加服务器安装部分用于将附加服务器耦合到输液泵支架400。显示器406可任选地耦合到输液泵支架400。虽然在图4中未明确说明，但是应理解，在一些实施例中，显示器406电子地耦合到服务器402。在实施例中，显示器406电子地耦合到服务器402可包含任何合适的通信软件或硬件实施方案，如通过硬件有线、无线(包括光(红外线))或其它合适的耦合。服务器402可因此被配置成操作地控制在输液泵支架400内的全部的输液泵404a到404g；并且在一些实施例中，这类操作控制可包括用户输入到显示器406和/或从显示器406输出。

输液泵支架400可进一步包含管或插管(未示出)用于将输液泵404a到404g中的任一个耦合到一个或多个患者。这类管或插管可另外彼此耦合输液泵404a到404g的任何组合。

在一个实施例中，输液泵支架400可安置在患者的房间中。在实施例中，输液泵支架400可安置在患者的床边处用于床边控制和相互作用。

参考图5，根据实施例描绘实时嵌入式服务器500的实例的框图。嵌入式服务器500通常包含处理器502和存储器504。多个引擎可通过或根据处理器502和存储器504实施，包括控制引擎506、信息传送引擎508、聚合引擎510和联网引擎512。在实施例中，嵌入式服务器500在所选特征上可部分或全部类似于嵌入式服务器215、嵌入式服务器302和嵌入式服务器402。

在一个实施例中，处理器502可为接受数字数据作为输入的任何可编程装置，其被配置成根据指令或算法处理所述输入并提供结果作为输出。在一个实施例中，处理器502可为被配置成执行计算机程序的指令的中央处理单元(CPU)。在另一个实施例中，处理器502可为应用专用集成电路(ASIC)。在另一个实施例中，处理器502可为现场可编程门阵列(FPGA)。处理器502因此被配置成执行基本算术、逻辑和输入/输出操作。

存储器504根据已耦合处理器502的需要可包括易失性或非易失性存储器以不仅提供实行指令或算法的空间，而且还提供存储指令本身的空间。在实施例中，易失性存储器可包含例如随机存取存储器(RAM)、动态随机存取存储器(DRAM)或静态随机存取存储器(SRAM)。在实施例中，非易失性存储器可包含例如只读存储器、快闪存储器、铁电RAM、硬盘、软盘、磁带或光盘存储装置。在一个实施例中，存储器504可包含数据库。在一个实施例中，存储器504包含用于处理器的操作的存储器和用于存储与系统相关的记录的单独的数据库。前述列表决不限制可使用的存储器的类型，因为这些实施例仅借助于实例给出而并不意欲限制本发明的主题的范围。

本文所述的引擎可构造、编程、配置或以其它方式适配以自主地执行功能或功能集合。如在整个本文中所使用的术语引擎被定义为现实世界装置、部件或使用硬件实施的部件的布置，如通过例如专用集成电路(ASIC)或现场可编程门阵列(FPGA)，或如硬件与软件的组合，如通过微处理器系统和致使引擎实施特定功能性的程序指令集合，其(在被实行时)将微处理器系统转变成专用装置。引擎还可被实施为以上两种的组合，其中某些功能由硬件单独促进，而其它功能由硬件与软件的组合促进。在某些实施方案中，至少一部分和在一些情况下，全部的引擎可在一个或多个计算平台的(一个或多个)处理器上实行，所述计算平台由硬件(例如一或多个处理器、数据存储装置，如存储器或驱动存储、输入/输出设备，如网络接口装置、视频装置、键盘、鼠标或触摸屏装置等)组成，其实行操作系统、系统程序和应用程序，同时还使用多任务、多线程、在适当时分配(例如丛集、对等体-对等体、云等)处理或其它这类技术实施。因此，每个引擎可以多种物理上实施的配置实现，且应大体上不限于本文例示的任何特定实施方案，除非明确指出这类限制。另外，引擎自身可由超过一个子引擎组成，每个子引擎可被看作就是一个引擎。此外，在本文所描述的实施例中，多种引擎中的每个对应于限定的自主功能；然而，应理解，在其它已涵盖实施例中，每个功能可分配给超过一个引擎。同样地，在其它已涵盖实施例中，多个限定功能可由执行那些多个功能的单个引擎实施，所述多个功能可能地并联或串联和/或与其它功能互补、或者与本文的实例中具体说明的不同方式分布在引擎集合中。

控制引擎506被配置成实行控制一个或多个输液泵用于操作的功能或功能集合。在一个实施例中，控制引擎506可将命令发布到一个或多个输液泵以控制用于一个或多个输液泵的输液参数。在一个实施例中，控制引擎506可从一个或多个输液泵接收与一个或多个输液泵的操作相关的数据、应答或的其它信息。在实施例中，控制引擎506可利用接收的数据、应答或其它信息以便做出关于输液的决策。举例来说，用于一个或多个输液泵的输液参数可在从一个或多个输液泵接收数据、应答或其它信息之后通过控制引擎506调节。反馈或半反馈系统由此通过嵌入式服务器500和输液泵产生。当从一个或多个输液泵的输出反馈为输入作为用嵌入式服务器500形成反馈或半反馈电路的一系列致使-和-影响的一部分时，由此出现反馈。

在一个实施例中，控制引擎506被配置成命令多个泵用于主要输液和次要输液(有时在本领域中被称为“捎带”)。举例来说，控制引擎506可命令第一泵向患者投予第一药品、溶液或其它输注液。控制引擎506可另外命令第二泵沿相同管线、管或插管向患者投予第二药品、溶液或其它输注液，使得第二输注液捎带有第一输注液。在实施例中，控制引擎506可用第一泵控制第一输注液的流动。在实施例中，控制引擎506可用第二泵控制第二输注液的流动。在实施例中，控制引擎506可用第一泵或第二泵任一者控制第一输注液和第二输注液两者。在实施例中，控制引擎506可停止第一输注液的主要输液并且允许第二输注液被输液。在完成捎带过程之后，控制引擎506可命令第一泵重新起动第一输注液的输液。

举例来说，虽然患者接收流体的输液，但是抗生素的袋可代替流体悬挂并且向患者递送直到袋排空，随后恢复流体传递。这非常类似于在注射泵上“冲洗”。此外，此类型的配置可用于“药物的混合”。举例来说，主泵可递送D5W(于水中的5％右旋糖)，并且后续泵可以混合到恰当的比率的速率引入药物。这可产生“75％D5W、10％异丙酚、10％瑞芬太尼和5％氯胺酮的常规药物混合物，其为用于较长持续时间手术的药物的常见组合。

在一个实施例中，控制引擎506被配置成命令多个泵用于接管模式。举例来说，控制引擎506可命令第一泵向患者投予第一药品、溶液或其它输注液。控制引擎506可另外命令第二泵接管第一泵并且向患者投予第二药品、溶液或其它输注液。

控制引擎506可另外命令两个或更多个泵各自递送输注液同时实现组合治疗效果。在一个实施例中，在单独的针筒中包含两种药物的输液可与单个输液成正比管理或可不成比例地、有意地相对于其它管理。举例来说，在麻醉输液中，包含被设计成保持患者不移动的麻痹剂的第一药物可与包含保持患者不感觉疼痛的麻醉剂的第二药物同时递送。在实施例中，第一药物和第二药物可相对于彼此投予。

在实施例中，控制引擎506配置另外适用于递送在治疗患者中不可或不应停止的关键药物。举例来说，在一个泵正要用完时，可起动另一个泵。在这类可操作地耦合系统中，切换可通过相对应的患者参数证实。

控制引擎506另外被配置成建立用于治疗功效的及时控制。换句话说，控制引擎506可以时间敏感方式控制治疗以确保被投予的药物的功效。举例来说，一些药物具有非常短的半衰期或动作窗口。控制引擎506可有效地保证或至少提供相对高程度的可信度，药物(包括任何相互作用药品或输液)将根据半衰期、计划、时间表和实时有效投予。因而，当期望时或当最有效时，那些药物的影响可有利地应用于患者。

信息传送引擎508被配置成实行处置一个或多个输液泵的消息的功能或功能集合。在一个实施例中，信息传送引擎508可向一个或多个输液泵发布消息。在一个实施例中，信息传送引擎508可从一个或多个输液泵接收消息。在一个实施例中，信息传送引擎508可从第一泵接收消息，旨在用于第二泵。一旦接收消息，信息传送引擎508可将从第一泵接收的消息转发到第二泵。在另一个实例中，信息传送引擎508可从第一泵接收消息，旨在用于全部其它通信地耦合的泵。一旦接收消息，信息传送引擎508可将从第一泵接收的消息转发到全部其它这类耦合泵。在实施例中，信息传送引擎508被配置成评估接收的任何消息，以确定是否应采用任何动作，如转发到其它泵。在其它实施例中，信息传送引擎508可将消息转发到控制引擎506，其继而可做出在一些实施例中经受预定义或用户定义和实时标准或界限值的操作控制决策。

在实施例中，信息传送引擎508被配置成以实时或非实时任一者将消息转发到外部系统，如HIS和/或EMR，如前述。举例来说，信息传送引擎508可利用非实时数据分组以将消息中继到HIS或EMR。在另一实施例中，如具有实时协调的IV输液的气体麻醉系统，信息传送引擎508可利用实时数据分组以在时间上尽可能接近事件提供与事件相关的消息的递送。因而，信息传送引擎508包含消息时延管理，以保证响应时间和性能，并且进一步解决可用传统系统蠕变的时延的问题。在实施例中，信息传送引擎508可中继通过外部系统接收的消息。在其它实施例中，信息传送引擎508可确定要发送哪个消息，包括例如操作泵、在待用模式中的泵，或离线泵。借助于嵌入式服务器，被编程的泵可启动在待用模式中的泵或离线泵的显示器以使用泵的显示器硬件。举例来说，用户可将某些数据“拨动”到其它泵，使得用户可同时查看更多的编程参数，而不是单独限于操作泵的显示器。

聚合引擎510被配置成实行聚合与一个或多个输液泵的操作相关的数据的功能或功能集合。在一个实施例中，聚合引擎510包含与数据的存储相关的功能。举例来说，聚合引擎510可积累事件或与泵的事件相关的数据。在一个实施例中，聚合引擎510可包含永久日志或交互记录。这类日志或交互记录允许暂留和提供到HIS或EMR的可靠递送用于记录保持。虽然未在本文中具体说明，但是此外将理解和了解，在一个实施例中，嵌入式服务器500(如果充当桥，例如在低功率通信网络和HIS或EMR之间)可提供数据暂留，由此降低输液泵和/或在较低电力通信网络上操作的相关医疗装置的能量需求。

另外，聚合引擎510包含与评估数据相关的功能或算法。举例来说，可通过聚合引擎510作出最大值、最小值、平均值、标准差和其它统计计算。聚合引擎510因此被配置成聚合、汇总、或另外管理或评估与一个或多个输液泵的操作相关的数据。在一个实施例中，聚合引擎510有助于降低实时系统的时延。服务器500的实施例提供定时和时延两者的控制，使得聚合引擎510可及时完成期望治疗。

联网引擎512被配置成实行接入到一个或多个输液泵的网络的功能或功能集合。因而，联网引擎512可包含在嵌入式服务器500和一个或多个输液泵之间的软件和硬件接口。联网引擎512提供标准化联网功能，如消息转发、连接和断开连接。在实施例中，联网引擎512可经网络实施任何合适的协议层。如果需要，那么联网引擎512可发布用于输液泵和自身中的任一个的网络ID。联网引擎512可因此管理在网络上的装置的地址。

在实施例中，控制引擎506、信息传送引擎508、聚合引擎510和联网引擎512中的任一个可利用对应的其它引擎中的任一个相对于特定引擎实行本文所述的功能或作用集合。举例来说，控制引擎506可利用信息传送引擎508以消息的形式将命令传输到一个或多个输液泵。在另一个实例中，处理器502，并且具体来说，控制引擎506、信息传送引擎508和/或聚合引擎510可各自利用联网引擎512用于经由网络与一个或多个输液泵相互作用。在另一个实例中，信息传送引擎508可利用聚合引擎510聚合、汇总或另外管理或评估从一个或多个输液泵接收的消息。

同样地，控制引擎506、信息传送引擎508、聚合引擎510和联网引擎512中的任一个可利用存储器504存储或保留与对应的引擎相关的数据。举例来说，控制引擎506可将控制算法、待发布的控制命令或发布的控制命令存储在存储器504中。在另一个实例中，信息传送引擎508可将接收、传输或待传输的消息存储在存储器504中。在另一个实例中，聚合引擎510可将评估算法、原始数据和聚合的数据存储在存储器504中。在另一个实例中，前述算法、原始数据或聚合的数据中的一个可为用于特定患者的药物代谢动力学(PK)曲线，其条件是存在一些反馈以验证结果，如下相对于图11到14所述。

在另一个实例中，实施例可基于对于全部泵的总流动速率和对对于每个泵/药物的总流动速率的部分贡献计算最终所得药物浓度。在另外的实施例中，系统可计算和显示用于被投予的药物/药物组合的药物代谢动力学曲线，类似于用于目标控制输液(TCI)的药物代谢动力学(PK)模型。在另一个实例中，如果医学专业人员基于医院的标准程序调节药物投予，那么数据可考虑“证实”。在另一个实例中，联网引擎512可在存储器504中存储用于连接(或可能连接)的输液泵中的每个的网络地址或硬件信息。

参考图6，根据实施例描绘实时嵌入式服务器系统600和外部医院信息系统606的实例的框图。如所描绘，嵌入式服务器系统600通常包含嵌入式服务器500、第一输液泵604a和第二输液泵604b。医院信息系统606在嵌入式服务器系统600外部并且可可操作地耦合到嵌入式服务器500。另外，虽然图6描绘具有两个输液泵604a和604b，但是系统600可包含接口到嵌入式服务器500的一个或多个输液泵。在一个实施例中，输液泵604a和604b在所选特征上可部分或全部类似于上文所述的输液泵210。

举例来说，并且参考图5和图6两者，嵌入式服务器500可利用控制引擎506和联网引擎512将泵命令608发布到输液泵604a。泵命令608可包含输液操作或协议。输液泵604a可接收命令608并且将确认610传输回到嵌入式服务器500，命令608通过输液泵604a接收。确认610可通过服务器500的联网引擎512接收。随后或并行地，输液泵604a可实施通过命令608命令的输液操作。

在另一个实例中，嵌入式服务器500可利用信息传送引擎508和联网引擎512将消息612发布到输液泵604b。消息612可例如被请求以提供与输液泵604b的操作相关的数据。作为响应，数据614可传输回到嵌入式服务器500。数据614可通过服务器500的联网引擎512接收。在另一个实施例(未示出)中，消息612可为来自输液泵604a的消息。在另一个实施例中(未明确示出)，消息612可为通过外部系统(如医院信息系统606)接收的待通过嵌入式服务器500传输到一个或多个输液泵(例如耦合的输液泵604b)的消息。

在一个实施例中，虽然未在附图中明确示出，但是联网引擎512被配置成接口到医院信息系统606。被传输到输液泵604a的泵命令608中的任一个或从输液泵604a接收的确认610可被传输到医院信息系统606。同样地，被传输到输液泵604b的消息612或从输液泵604b接收的数据614中的任一个可被传输到医院信息系统606。在另一个实施例中，可利用聚合引擎510以聚合命令608、确认610、消息612或数据614中的任一个，以为医院信息系统606提供更完整的通信或状态。

参考图7A，根据实施例描绘包括在嵌入式服务器702和输液泵704a和704b之间的信息传送业务量的实时嵌入式服务器系统700的实例的框图。在实施例中，嵌入式服务器702在所选特征上可部分或全部类似于嵌入式服务器215、嵌入式服务器302、嵌入式服务器402，或嵌入式服务器500。同样地，输液泵704a和704b在所选特征上可部分或全部类似于上文所述的输液泵210。在图7A的实例中定序时间式将从上到下读取，虽然此处的主题(如通过实例所描述或在本文中另外涵盖)不一定限于这类按时间顺序的序列。

在操作中，嵌入式服务器702可向输液泵704a发布命令706。在一个实施例中，命令706包含泵操作命令和状态请求。举例来说，状态请求可包含每10秒对输液数据的请求。作为响应，输液泵704a开始泵操作并且随后将在泵操作10秒时的输液数据708、在泵操作20秒时的输液数据710和在泵操作30秒时的输液数据712传输回到嵌入式服务器702。消息714随后从输液泵704a传输到嵌入式服务器702。

参考在嵌入式服务器702和输液泵704b之间的操作，消息716可用嵌入式服务器702起始信息传送。嵌入式服务器702可评估消息716并且随后发布命令718。在一个实施例中，命令718包含泵操作命令。作为响应，输液泵704b开始泵操作。在实施例中，嵌入式服务器不请求在命令718中的状态，因为嵌入式服务器702已确定输液泵704b在操作期间预配置成传输数据。因此，输液数据720和输液数据722从输液泵704b传输到嵌入式服务器702。作为响应，嵌入式服务器702被配置成评估输液数据720和输液数据722，并且发布更新输液泵704b的操作的命令724。举例来说，如果输液数据720和输液数据722指示患者不在以通过命令718的适当速率接收初始命令的药物，那么嵌入式服务器702可更新命令724的速率。输液泵704b随后更新其输液速率并且将消息726发布回到嵌入式服务器702。系统700的操作的这类实例示出通过嵌入式服务器702提供的实时控制。

在实施例中，具有输液泵704a和输液泵704b的嵌入式服务器702的操作可并行或串行。虽然图7A描绘具有两个输液泵704a和704b，但是系统700可包含接口到嵌入式服务器702的一个或多个输液泵。

参考图7B，根据实施例描绘图7A的实时嵌入式服务器702的实例的框图，其示出前述信息传送业务量的存储。在一个实施例中，嵌入式服务器702通常包含处理器752和存储器754。处理器752在所选特征上可部分或全部类似于处理器502。同样地，存储器754在所选特征上可部分或全部类似于存储器504。在一个实施例中，存储器754可包含用于处理器的操作的易失性存储器和用于存储与系统700相关的记录的单独的数据库。

存储器754可以被配置成存储在嵌入式服务器702和输液泵704a和704b之间转移的信息传送业务量、命令或数据。举例来说，输液数据708、输液数据710、输液数据712、输液数据720和输液数据722可在存储器754中作为单个记录存储、保存或另外记录。同样地，消息714、消息716和消息726可在存储器754中作为单个记录存储、保存或另外记录。命令706、命令718和命令724可在存储器754中作为单个记录存储、保存或另外记录。

如图7B所示，输液记录存储在一起，消息记录存储在一起，并且命令记录存储在一起。在实施例中，可存储输液记录、消息记录和命令记录使得它们在存储器754内互混。在这类实施例中，存储器754可单独被配置成将指针存储到对应的记录，使得分组或类别可有效地被检索。在其它实施例中，除了单个记录之外，汇总或聚合输液数据、消息数据和命令数据的汇总或聚合数据存储在存储器754中。在另一个实施例中，仅汇总的或聚合的数据存储在存储器754中。

虽然在图7B中未明确说明，但是类似地参考图5的部件，在包含控制引擎、信息传送引擎、聚合引擎和联网引擎的嵌入式服务器702的一个实施例中，这些引擎中的任一个可接入存储在存储器754中的记录。在其它实施例中，存储器754可受限制，使得引擎中的仅一个或一些可接入存储在存储器754中的记录。这类权限类接入允许输液泵-服务器数据的安全和保密存储。

参考图8，根据实施例描绘用实时嵌入式服务器控制多个输液泵的方法800的实例的流程图。

在810，实施具有控制引擎的实时嵌入式服务器。如相对于图5类似地描述，控制引擎被配置成向至少一个输液泵发布控制命令，其中控制命令涉及至少一个输液泵的操作。

在820，实施至少一个输液泵。至少一个输液泵被配置成接口到810的嵌入式服务器。

在830，实施网络耦合810的嵌入式服务器和820的至少一个输液泵。举例来说，输液泵在所选特征上可部分或全部类似于如相对于图2所描述的输液泵210。在实施例中，可实施多个输液泵。在一个实施例中，可经由相同网络实施多个嵌入式服务器。举例来说，第一服务器可接口到在网络上的第一输液泵，并且第二服务器可接口到在网络上的第二和第三输液泵。在这类实施例中，第一和第二服务器可彼此接口以控制第一、第二和第三输液泵。

在840，控制命令可从810的控制引擎发布到820的至少一个输液泵。控制命令经由830的网络从嵌入式服务器传输到至少一个输液泵。

在850，840的控制命令通过820的至少一个输液泵接收，并且至少一个输液泵的操作模式基于接收的控制命令实行。举例来说，控制命令可指示至少一个泵向患者投予第一药品或溶液。

任选地在860，消息从820的至少一个输液泵接收。在860从至少一个输液泵接收的消息可包含840的控制命令的确认。在实施例中，除非确认被接收，否则810的嵌入式服务器可取消或另外抑制预先发布的控制命令。在另一实施例中，从至少一个输液泵接收的消息可包含状态或操作数据以创建用于方法800的系统的反馈。在这类实施例中，状态或操作数据可并入到在840发布的附加控制命令中。举例来说，如图8所说明，从860，方法任选地返回到840，其中可发布另一个控制命令。

参考图9，根据实施例描绘用实时嵌入式服务器聚合与多个输液泵相关的数据的方法900的实例的流程图。在一个实施例中，并且再次类似地参考图5，方法900可例如通过控制引擎506、信息传送引擎508、聚合引擎510和联网引擎512的部分或全部实施。

在910，第一数据用嵌入式服务器从第一输液泵接收。在一个实施例中，第一数据包含消息。在另一实施例中，第一数据包含与第一输液泵的操作相关的数据。在其它实施例中，第一数据可包含网络状态数据。在其它实施例中，第一数据可包含与第一输液泵或接口到第一输液泵的任何耦合的部件相关的其它数据。

在920，第一数据通过910的嵌入式服务器存储。在一个实施例中，第一数据可存储在910的嵌入式服务器的电耦合存储器中。在另一个实施例中，第一数据可存储在可操作地耦合到嵌入式服务器的数据库中。

在930，第二数据用嵌入式服务器从第二输液泵接收。在一个实施例中，第二数据包含消息。在实施例中，第二数据可包含用于第一输液泵的消息。在另一个实施例中，第二数据包含与第二输液泵的操作相关的数据。在其它实施例中，第二数据可包含网络状态数据。在其它实施例中，第二数据可包含与第二输液泵或接口到第二输液泵的任何耦合的部件相关的其它数据。

在940，第二数据通过930的嵌入式服务器存储。在一个实施例中，第二数据可存储在930的嵌入式服务器的电耦合存储器中。在另一个实施例中，第二数据可存储在可操作地耦合到嵌入式服务器的数据库中。

在950，对920的存储的第一数据和940的存储的第二数据执行聚合算法。聚合算法包含与评估存储数据相关的功能或算法。举例来说，可通过聚合算法进行最大值、最小值、平均值、标准差和其它统计计算。聚合算法因此被配置成聚合、汇总或另外管理或评估存储的数据。

任选地，在960，在950执行的聚合算法的输出可被传输到外部系统。举例来说，操作910的第一输液泵和930的第二输液泵的状态可提供到医院信息系统。在一个实施例中，并且类似地参考图5和6，联网引擎被配置成接口到医院信息系统。

在一个实施例中，参考图10，描绘患者护理网络的系统1000的实例的框图。系统1000在图10中在所谓的“云”计算机/医疗装置架构中描绘(但是“云”部件、系统和架构在如所描述或在本文中另外涵盖的患者护理网络的系统的各种实施例中未必需要)，并且通常包含患者装置网络1002、EMR网络1004、大数据网络1006、医院网络1008、国家等级网络1010和世界等级网络1012。每个网络1002到1012可包含彼此通信耦合或通信耦合到其它网络的部分的一个或多个计算装置。举例来说，一个或多个服务器可可操作地耦合到因特网或特定内联网以表示特定网络。每个网络1002到1012可进一步包含被配置成存储对应于特定网络的数据的一个或多个数据库。为便于说明，图10描绘网络1002到1012作为层次，但是网络1002到1012可同样在非层次架构中实施。当然，系统1000可用比描绘的附加或较少网络或不同网络实施。此外，虽然数据已在组或等级上定义，但是可定义或利用任何合适的组、多个组、等级或多个等级。举例来说，大数据网络1006可是指数据的等级或任何其它合适的等级。

患者装置网络1002可包含可操作地耦合到多个医疗装置1016a到1016f的患者P。如下文将另外描述，医疗装置1016a到1016f可各自包含用于向患者P提供治疗或药品的装置。另外，医疗装置1016a到1016f可各自包含用于读取患者的状态或特征的装置，如传感器。

EMR网络1004可包含被配置成操控和存储电子医疗记录数据的一个或多个计算装置和/或数据库。大数据网络1006可包含被配置成操控和存储聚合装置等级和EMR数据的一个或多个计算装置和/或数据库。医院网络1008可包含被配置成操控和存储医院等级数据的一个或多个计算装置和/或数据库。国家网络1010可包含被配置成操控和存储国家等级数据的一个或多个计算装置和/或数据库。世界网络1012可包含被配置成操控和存储世界等级数据的一个或多个计算装置和/或数据库。在对应的网络等级下存储或操控的数据中的任一个可根据数据和应用从其它网络聚合或单独地存储或操控。

后续网络中的每个可接入紧邻网络。如所说明，通过EMR网络1004接入患者装置网络1002可通过实时嵌入式服务器1018实施。嵌入式服务器1018可从EMR网络1004接收数据用于传输到患者装置网络1002。嵌入式服务器1018可另外从患者装置网络1002接收数据用于传输到EMR网络1004。

在另一个实例中，大数据1006可经合适的接口或桥1020接入EMR网络1004数据。桥1020可包含例如电子医疗记录服务器或系统，如CERNER或EPIC系统。桥1020可因此从大数据1006接收数据用于传输到EMR 1004。类似地，桥1020可从EMR 1004接收数据用于传输到大数据1006的收集。同样地，医院网络1008可经类似合适的接口或桥等接入大数据1006。为简单起见在图10中未描绘其它桥，但是本领域技术人员将容易地理解，接口概念通过嵌入式服务器1018和桥1020的实例提供作为类似地可适用于系统1000的其它部件。在其它实施例中，网络1002到1012可通过由对应的网络提供的数据库或接口接入不彼此紧邻(字面上或象征性地)的网络的数据。

如下文将另外描述，一旦患者装置网络1002包括对其它等级或网络的接入(例如通过嵌入式服务器1018和桥1020，等)，就可实施多种治疗。举例来说，效力或功效数据可跨网络比较用于实时更新用于患者装置网络1002的输液参数。在其它实施例中，可利用跨网络或在网络之间可获得的图案数据用于实时更新用于患者装置网络1002的输液参数。不同层次等级此外可提供不同数据的粒度、深度或细节。在医院等级处的数据(例如来自医院网络1008)可不同于在世界等级处的数据(例如在世界网络1012处)。数据的特定趋势或图案可根据需要或期望确定特定、治疗，或患者，或患者的分类。举例来说，实施例可跟踪在层次中的任何等级下特定药物的全部递送以评定组织风险。

在另一个实例中，变化等级的企业规则限制，如流动界限值、药物界限值、多种设定(例如安全界限值)、告警音类型等可根据接入到其它等级或网络协调或设定。多国医院系统可例如在所有医院中需要相同声音设定。

参考图11，根据实施例描绘分散型嵌入式实时服务器系统1100的框图。一般来说，系统1100包含外部服务器1106，如Smiths Medical PHARMGUARD服务器系统、数据库1108和患者装置网络1110。

外部服务器1106可包含被配置成操控和存储与患者装置网络1110和其它类似网络的输液治疗相关的数据的计算装置。在一个实施例中，外部服务器1106通信耦合到数据库1108。数据库1108被配置成存储与输液治疗相关的数据。举例来说，再次参考图10，外部服务器1106和数据库1108可按需要包含EMR网络1004或大数据1006，或医院1008的部分。在大多数实施例中，外部服务器1106和数据库1108包含“高于”图10的患者装置网络1002一个等级的架构。

图11的患者装置网络1110可基本上类似于如图10所描述的患者装置网络1002。如图11所描绘，患者装置网络1110通信耦合到外部服务器1106。在一个实施例中，患者装置网络1110包含嵌入式服务器1112和多个装置1114a到1114f。嵌入式服务器1112与任何医院网络分散，其实现装置1114a到1114f的实时、动态和患者特定告知的控制。嵌入式服务器1112可包含用于操控从外部服务器1106或装置1114a到1114f的输入或输出中的任一个的方程、算法或其它基于处理器的指令。在实施例中，嵌入式服务器1112可包含医疗装置、多个医疗装置、计算机、平板计算机、便携式电话支架，或适于插入到系统部件中的模块。

在一个实例中，装置1114a到1114c包含到嵌入式服务器1112的输入，同时装置1114d到1114f包含来自嵌入式服务器1112的输出。装置1114a到1114c各自为用于患者P的传感器或监测器。举例来说，装置1114a到1114c可分别包含呼吸传感器、血压传感器和心跳速率传感器。输入装置1114a到1114c中的每个因此被配置成从患者P感测数据或状态。装置1114d到1114f各自为用于患者P的递送装置。举例来说，装置1114d到1114f可各自分别包含输液泵。嵌入式服务器1112因此被配置成从输入装置1114a到1114c接收数据，并且分别基于来自输入装置1114a到1114c的输入和任何其它编程命令或来自外部服务器1106的输入编程装置1114d到1114f。此外考虑除输入装置1114a到1114c之外的反馈机构。

在一个实施例中，可下载软件模块可将附加特征、功能性或算法添加到本文所述的系统。可下载模块可登记到中心“规则引擎”，使得根据所定义规则接入模块功能。举例来说，当使用特定治疗时，可基于生命体征实行用具有自动递送改变的专门算法管理多种药物的命令或命令的序列。

系统1100可进一步包含显示器1116。在如图11所示一个实施例中，显示器1116可在患者装置网络1110外部。在其它实施例中，显示器1116可集成到患者装置网络1110中。可利用显示器1116以示出或说明包括多药物治疗(如TCI)的单个装置数据或聚合的数据。

虽然在本文中未具体说明，但是此外应理解和了解，嵌入式服务器1112可有利地被配置成或被设计成将来自用于患者P的多个类似或相关传感器和/或监测器的信息组合成单个和更多个精确或可靠数据流。

在其它实施例中，可根据实时服务器系统1100通过架构和接口达到大量通信方案。举例来说，对等通信可在装置1114a到1114f中的任一个之间，或在装置1114a到1114f和外部装置(在图11中未示出)中的任一个之间实施。在其它实施例中，可实施专用无线连通性，其中外部服务器1106称为对等体，并且另一个装置称为主控装置，如单个装置1114a或嵌入式服务器1112。

下文描述示出为接口到前述外部服务器1106和患者装置网络1110的处理步骤的系统1100的其它元件。

在操作中，进行在患者P上的进入1102。在一个实施例中，进入1102包含从患者P收集信息。在一个实施例中，进入1102可通过护士或其它执业医生手动地进行。在其它实施例中，可进行自动进入1102；例如通过外部服务器1106。

在1104，进行分诊以根据在进入1102接收的数据或信息确定患者P的病况。在一个实施例中，分诊1104包含护士或其它执业医生分析关于患者P的进入1102数据或信息。在另一个实施例中，通过计算装置(如外部服务器1106)对来自进入1102的数据或信息进行自动分诊1104。

根据分诊1104，患者P容许进入医疗机构或从医疗机构出院。如果患者P容许进入，那么例如来自进入1102的前述ICD编码以及数据或信息可输入到外部服务器1106。如果患者P出院，那么系统前进到最终状态。

再次返回到其中患者P从分诊1104容许进入的情况，可通过系统1100生成基于“通知-建议-控制”方案的一个或多个患者-特定治疗。参考图12(其中还继续参考图11)，根据实施例描绘通知-建议-控制医疗装置方案1200的流程图。举例来说，初始输液可向患者P投予。初始输液可根据进入1102数据或信息和外部服务器1106数据(存储在数据库1108上编程或规定，用于具有那些特定特性的患者。患者P的特定反应可通过输入装置1114a到1114c监测。因此，特定环境或特定患者的反应可与在数据库1108上存储的数据的期望环境或反应相比。在一个实施例中，当患者P进入时，嵌入式服务器1112可与患者相关联，并且相关联装置1114可根据其用途、连接点或其它功能性或数据项相关联，其中可采用先进算法以优化患者护理。

在“通知”步骤1202中，来自输入装置1114a到1114c的数据可通过嵌入式服务器1112收集。在一个实施例中，嵌入式服务器1112可从输入装置1114a到1114c聚合数据。此数据可通过嵌入式服务器1112传输到外部服务器1106并且通过外部服务器1106向患者P或护士或其它执业医生呈现。在另一实施例中，数据可呈现在装置1114a到1114f中的一个上。相对成功或失败指示可基于1114a到1114c的状态数据提供。另外，可另外提供相对警告或“软限制”指示。

在“建议”步骤1204中，来自图11的输入装置1114a到1114c的数据可通过外部服务器1106或嵌入式服务器1112并入以建议后续动作。经由在外部服务器1106和数据库1108之间的接口通信的来自数据库1108的数据可另外用于比较、对比或建议。在一个实施例中，在数据库1108中的数据可包含来自其它输入的数据，如呼吸机数据、体外膜氧合(ECMO)数据、实验室数据，或关于图10的网络描述的层次等级中的任一个，如装置等级数据、EMR数据、大数据、医院等级数据、国家等级数据和世界等级数据。后续动作可推荐或建议改变投予的药品。在此情况下，来自输入装置1114a到1114c的数据可指示通过在期望界限外部的患者P的反应。在另一个实例中，后续动作可在药品投予期间另外监测患者P并且因此建议护士或其它执业医生。

在任选的“控制”步骤1206中，图11的装置1114d到1114f可基于在“建议”步骤1204中进行的数据分析再编程或另外命令以重新投予或改变给定的输液。在一个实施例中，编程推荐在向患者P投予之前呈现给用户用于在“建议步骤”1204中或通过另一个合适的技术接受。如所描绘，从控制1206，可任选地进行“通知-建议-控制”方案1200回到通知1202，使得所述过程可迭代。迭代可以任何期望频率出现；例如在进入输液协议的某一时间段之后。在另一实施例中，迭代可在独立时间或标记下出现，如每一小时或每15分钟。因此可达到使用“通知-建议-控制”方案1200的输液的动态控制。

参考图13，根据实施例描绘与由药品产生的期望和实际患者特征值组合的相对于时间的药品投予的图1300。图1300描绘在x轴上的时间和在y轴上的相对值。如图所示，大丸剂1302在给定时间向患者递送。示出对于关于大丸剂1302的特定患者特征的期望值1304(并且例如可存储为在图11的数据库1108中的数据)。随后，如作为上文所述的图12的“通知-建议-控制”方案1200所测量，可测量特定患者特征的实际值1306。如果特定患者特征的实际值1306不同于期望值1304，那么对于药用的特定患者可采用矫正措施。如在图13的实例中所示，在值的形状和相对幅度两者上实际值1306不同于期望值1304。

参考图14，根据实施例描绘包括至少一个嵌入式服务器控制装置的患者护理系统1400的框图。在一个实施例中，患者护理系统1400包含用于治疗患者P的患者装置网络1402。

在一个实施例中，患者装置网络1402包含多个医疗装置1406a到1406f。医疗装置1406a到1406f可包含如例如相对于在图11中的装置1114a到1114f所描述的输入或输出装置。举例来说，每个医疗装置1406a到1406f可包含用于患者P的传感器或监测器或递送装置。

此外，患者装置网络1402包括具有嵌入式服务器的功能性的控制装置。在所描绘的实例中，医疗装置1406a为控制装置(在图14中通过加宽矩形边框表示)并且被配置成控制自身和医疗装置1406b到1406f。举例来说，医疗装置1406a可包括类似于图2的控制模块220的模块。医疗装置1406a因此被配置成视具体情况向患者P投予药品或感测关于患者P的数据；并且在一些实施例中，装置1406a还可提供和如相对于输液泵和其它相关联装置医疗装置1406b到1406f的前述全部“通知-建议-控制”方案。

举例来说，控制装置1406a可建立在治疗和药物之间的1-1关系，如麻醉的投予。在麻醉治疗实例中，医疗装置1406a到1406f中的一个可命令投予麻醉药物。在实施例中，传感器型医疗装置可命令感测与麻醉治疗相关的特性。

在另一个实例中，控制装置1406a可建立在药物之间的多个关系。举例来说，在流体负载和血压之间的关系需要关于血压监测的多个输液。如果期望多个输液，那么控制装置1406a可命令多个医疗装置1406b到1406f向患者P投予药品。然而，可考虑每个对应的输液并且其通过控制装置1406a适于其它，使得患者不过投予流体的总量。在这类实施例中，医疗装置1406b到1406f中合适的一个可命令监测关于多个输液的血压。

在一个实施例中，“控制”装置的层级可在医疗装置1406a到1406f之间协商。举例来说，控制装置1406a可指定另一个医疗装置1406b到1406f作为临时介质(agent)控制自身和剩余的医疗装置1406a到1406f。控制可随后在某一时间或当某一任务已完成时传递回到控制装置1406a。在另一个实施例中，控制装置1406a可被称为最高或主要控制装置。装置1406b到1406f的某些子集的控制可在患者-装置网络1402上传递到其它装置。举例来说，医疗装置1406b可被配置成用于控制医疗装置1406c到1406d，同时医疗装置1406e可被配置成用于控制医疗装置1406f。在这类实施例中，医疗装置1406b和医疗装置1406e可将状态数据传递回到最高或主要控制装置1406a。医疗装置1406a到1406f的这类组织本文中借助于实例描述。本领域技术人员将容易地理解，一旦患者-装置网络1402如本文所描述建立，就可实施任何数目的层次结构或通信结构。

参考图15，根据实施例描绘用于患者护理系统的实例通信接口的框图。患者护理系统1500通常包含到支架1502的多种通信接口。支架1502可包含，例如简单以太网交换机或控制器区域网络(CAN总线)到乙太网转换器，或任何其它任何合适的通信接口或协议，包括WiFi、蓝牙、CAN、乙太网等硬件、固件、软件或其组合。本领域技术人员将容易地理解，例如本文中仅描述特定接口或特定硬件组件，并且可利用任何合适的网络接口或协议，如WiFi专用、蓝牙PAN或其它合适的技术。

在一个实施例中，患者护理系统1500包含外部服务器1504，如前述SmithsMedical PHARMGUARD服务器(PGS)系统。在一个实施例中，外部服务器1504被配置成经由经乙太网/WiFi的SOAP信息传送与支架1502通信。

在一个实施例中，患者护理系统1500包含药品安全软件(MSS)系统1506。如所描绘，MSS可包括基于万维网的泵模拟器和用户接口(UI)子系统。在实施例中，基于万维网的泵模拟器可集成在MSS内并且可使用来自当前选择的MSS配置的数据。在一个实施例中，MSS系统1506被配置成使用经乙太网/WiFi的专用的Smiths Medical“CADD Solis NCS”通信协议与支架1502通信。在一个实施例中，通信可使用“可靠”子协议。

在一个实施例中，患者护理系统1500包含传输控制(TC)单元1508。在这类实施例中，TC单元1508被配置成使用前述经乙太网/WiFi的专用的CADD Solis NCS通信协议与支架1502通信。在一个实施例中，这类通信可使用“可靠”子协议。

在一个实施例中，患者护理系统1500包含可能客户/第三方控制系统1510。在这类实施例中，客户/第三方控制系统1510被配置成使用前述经乙太网/WiFi的专用的CADDSolis NCS通信协议与支架1502通信。在一个实施例中，这类通信可使用“可靠”子协议。

在一个实施例中，患者护理系统1500包含中央显示器1512。在这类实施例中，支架1502或耦合到支架1502的泵1518可以被配置成充当万维网服务器，由此命令中央显示器1512以合适的泵语言提供状态。在这类实施例中，中央显示器1512因此被配置成使用前述经乙太网/WiFi的专用的CADD Solis NCS通信协议与支架1502通信。在一个实施例中，这类通信可使用“可靠”子协议。

在一个实施例中，患者护理系统1500包含手持型或移动装置1514，如智能电话。在这类实施例中，支架1502或耦合到支架1502的泵1518可以被配置成充当万维网服务器，由此命令手持型或移动装置1514以合适的泵语言提供状态。在这类实施例中，手持型或移动装置1514因此被配置成使用前述经乙太网/WiFi的专用的CADD Solis NCS通信协议与支架1502通信。在一个实施例中，这类通信可使用“可靠”子协议。

在一个实施例中，患者护理系统1500包含泵模拟器1516如基于PC的调试台。在这类实施例中，泵模拟器1516可包含具有拆除或去除的驱动器的用户接口(UI)子系统、具有拆除或去除驱动器的马达处理器子系统，和模拟硬件驱动器。泵模拟器1516被配置成经由任何合适的通信接口或协议，包括WiFi、蓝牙、CAN、乙太网等与支架1502通信。

在一个实施例中，患者护理系统1500包含一个或多个泵1518。每个泵1518可包括“机器到机器”(M2M)接口模块、耦合到电池组的马达处理器子系统、用户接口(UI)子系统，和安全数字高容量(SDHC)卡。在实施例中，如所描绘，马达处理器子系统可经I2C沿SM总线与电池组通信。另外，马达处理器子系统可使用UART+信号交换与US子系统通信。在实施例中，马达处理器子系统可包含无人操作的泵。SDHC卡可包括一个或多个固件更新、一个或多个tech服务手册、一个或多个用户手册、历史日志数据、一个或多个仪器日志，和一个或多个仪器配置文件。SDHC卡可呈现为公开内容，如经USB的仿真大容量存储装置。在实施例中，每个泵被配置成经由任何合适的通信接口或协议，包括WiFi、蓝牙、CAN、乙太网等与支架1502通信。在一个实施例中，到支架1502的全部连接用直接到泵M2M接口模块的连接复制。

如图15所描绘，系统1500可进一步包含个人计算机(PC)1520。PC 1520可包括万维网浏览器和文件接入子系统。一个或多个泵1518可经USB连接与PC 1520通信。在这类实施例中，每个泵1518被配置成仿真标准USB大容量存储装置类别。每个泵1518可提供全部病史日志作为在仿真大容量存储装置文件系统中的纯ASCII文件。在实施例中，每个泵1518可接受呈拷贝所述仿真大容量存储装置的标准S-记录文件形式的固件升级。

患者护理系统1500可进一步包含Axeda个人计算机(PC)1522。Axeda PC 1522可被配置成使用前述经乙太网/WiFi的专用的CADD Solis NCS通信协议与支架1502通信。固件和配置更新可使用“Best Effort”子协议转移。在一个实施例中，PLexus乙太网固件更新器(PLEFU)接口小程序可由Smiths Medical的CADD Solis USN固件更新器(SUFU)产生。与具体实施例无关，应理解和了解，PC 1522可包含可任选地处于或具有例如一个或多个单独装置或所关注的物体或对患者护理系统1500的效用的“物联网”或“IoT”实施。

Axeda PC 1522被配置成使用前述经USB的专用的CADD Solis NCS通信协议与每个泵1518通信。每个泵1518因此被配置成另外实施标准USB虚拟的串口类别。在实施例中，PLexus Usb固件更新器(PLUFU)接口小程序可由Smiths Medical的CADD Solis USB固件更新器(SUFU)产生。

在另外的实施例中，患者护理系统1500进一步包含Axeda企业服务器1524。AxedaPC 1522可经由经因特网的HTTPS协议与Axeda企业服务器1524通信。固件或配置程序包1526可集成到外部服务器1504或Axeda企业服务器1524中。

在其它实施例中，支架1502在患者护理系统1500内为任选的。患者护理系统1500的部件，如外部服务器1504、MSS系统1506、TC单元1508、客户/第三方控制系统1510、中央显示器1512、手持型或移动装置1514、泵模拟器1516、泵1518、PC 1520，和/或Axeda PC 1522在无支架1502的情况下可通信。在这类实施例中，接口到单独部件的系统1500的每个部件可被配置成用于与部件或多个部件适当通信。

本文公开的实施例可用于与其它发明的系统和方法组合。举例来说，标题为“药物输液系统和用于其中使用的泵组合件(MEDICAMENT INFUSION SYSTEM AND PUMP ASSEMBLYFOR USE THEREIN)”的WIPO国际申请第PCT/US2015/038309号(其参照不是与本发明的描述不相容的程度在此并入)，和标题为“医疗装置客户化(MEDICAL DEVICE CUSTOMIZATION)”的WIPO国际申请第PCT/US16/22322号(其参照不是与本发明的描述不相容的程度在此并入)的概念可各自部分、全部、单独或彼此组合利用，其中用于协调和控制输液泵的系统和方法的实施如通过实例所描述或在本文中另外涵盖。前述公开内容的两者提供用于分离或辨别，例如IV泵与肠内泵与轴索泵的技术。

举例来说，“泵类型”知识可用于改变嵌入式服务器的动作过程。“泵类型”规则可告警或防止1mL针筒由于压力差在与60mL相同的管线上使用。在另一个实例中，用于大容量泵，“泵类型”规则可告警或禁止在相同管线上的单独LVP泵上的多个第二输液。

在另一个实例中，这类“泵类型”知识可用于改变嵌入式服务器的动作过程。举例来说，在图4中，假设410a到410e为IV泵410f为肠内泵并且410g为轴索泵，410a到410e将最可能与410f和410g不同地设置、编程或操作。在此实例中，嵌入式服务器可基于对于泵特定的输液途径限制药物的选择。在用户尝试将一次性错误(如通过例如前述“药物输液系统和用于其中使用的泵组合件”的装置或系统感测)放置到不正确泵(如通过前述“医疗装置客户化”的装置或系统感测)中的情况下，嵌入式服务器可使用此组合知识将用户导引到恰当的疗程。此外，在一个实施例中，来自公开于标题为“医学管检测和管理(MEDICAL TUBINGDETECTION AND MANAGEMENT)”的WIPO国际公开第WO 2013/074717A1号中(其参照不是与本发明的描述不相容的程度在此并入)中的系统的信息，可解析成嵌入式服务器，因此有助于输液错误的路线的最小化可能性。在此实例中，泵被标记用于输液的特定路线，一次性“键连”使得一次性将仅对恰当的泵起作用，并且歧管可确定哪些泵连接在一起。另外，与在标题为“输液规划系统(INFUSION PLANNING SYSTEM)”的WIPO国际公开第WO 2014/210465A1号(其参照不是与本发明的描述不相容的程度在此并入)和标题为“具有临床决定支持的输液规划系统(INFUSION PLANNING SYSTEM WITH CLINICAL DECISION SUPPORT)”的WIPO国际申请第PCT/US15/63710号(其参照不是与本发明的描述不相容的程度在此并入)以及标题为“药品安全装置和方法(MEDICATION SAFETY DEVICES AND METHODS)”的WIPO国际公开第WO 2014/116832 A1号(其参照不是与本发明的描述不相容的程度在此并入)中描述的系统和方法合并的这类系统和方法可有利地例如产生或实施有效地“习得”以确保患者安全的系统和方法。

与具体实施例无关，应理解和了解，新颖和本发明的嵌入式实时服务器装置、系统和方法-如通过实例所描述或在本文中另外涵盖-可(i)与已知系统相比提供相对快速和可靠的响应时间，(ii)在无延迟和网络过载的情况下能够处置在网络上的多次点击，和(iii)足够可靠以控制其自身输液泵。另外，如通过实例所描述或在本文中另外涵盖，嵌入式实时服务器装置、系统和方法可提供具体相对于其彼此连接通信地耦合的装置的所要功能性；并且这类装置、系统和方法可提供与例如不因此通信地耦合的部署用于单个患者的单个泵相比全部泵“智力”的期望提高。此外，具体来说，嵌入式实时服务器装置、系统和方法-如通过实例所描述或在本文中另外涵盖-可有效地帮助和有效地管理通信地耦合并且由此相对于彼此起作用的关于单个患者的多个医疗数据系统(例如多个医疗装置的电子医疗记录(EMR)、医院信息系统(HIS)和信息技术(IT)系统)。另外，嵌入式实时服务器装置、系统和方法，如通过实例所描述或在本文中另外涵盖，可提供用于流行病学、健康管理、计费和保险覆盖范围测定，和临床目的的有用工具一般来说，由于这类装置、系统和方法与例如不因此通信地耦合的部署用于单个患者的单个泵相比的相对迅捷和高效互连通信路径。

系统、装置和方法的各种实施例已经在本文中描述。这些实施例仅为了举例而给出且并非旨在限制本发明的主题的范围。此外，应了解，已经描述的实施例的各种特征可以按不同方式组合以产生许多附加实施例。此外，虽然已经描述用于公开的实施例的各种材料、尺寸、形状、配置和位置，但是可以利用除公开内容之外的其它内容，而这些不超过本发明的主题的范围。

相关领域中的普通技术人员将认识到，本发明的主题可包含比上述任何个别实施例中所示出更少的特征。本文所述的实施例并不意味着，可组合详尽地呈现本发明的主题的各种特征的方式。因此，实施例并非特征的相互排斥的组合；相反地，各种实施例可包含选自不同个别实施例的不同个别特征的组合，如所属领域的普通术人员所理解。此外，除非另外指出，否则关于一个实施例所述的元件可以在其它实施例中实施，即使在这类实施例中未描述。

虽然权利要求书中的从属权利要求可以是指与一或多项其它权利要求的特定组合，但是其它实施例还可包含从属权利要求与每一项其它从属权利要求的主题的组合，或者一或多个特征与其它从属或独立权利要求的组合。除非声明不希望特定组合，否则本文中建议这类组合。

上述文献的任何以引用方式的并入受到限制，使得与本文中的明确公开内容相反的主题不会被并入到本文中。上述文献的任何以引用方式的并入进一步受到限制，使得文献中所包括的权利要求不会被以引用方式并入本文中。上述文献的任何以引用方式的并入更进一步受到限制，使得文献中所提供的任何定义不会被以引用方式并入本文中，除非明确包括于本文中。

出于解释权利要求书的目的，明确地希望35U.S.C.§112(f)的条款不会被调用，除非权利要求中叙述特定术语“用于…的方式”或“用于…的步骤”。

Claims (30)

1.一种用于实时控制至少一个输液泵的实时嵌入式服务器系统，所述嵌入式服务器系统包含：

多个输液泵，其中所述输液泵中的每个包括泵送机构和被配置成接收控制命令和控制所述泵送机构的操作的可编程回路；

包括存储器和处理器的嵌入式服务器，所述处理器电耦合到所述存储器并且被配置成实施：

被配置成向至少一个输液泵发布控制命令的控制引擎，所述控制命令与所述至少一个输液泵的所述操作相关，

被配置成向所述至少一个输液泵发布消息并且从所述至少一个输液泵接收消息的信息传送引擎，

被配置成聚合与所述至少一个输液泵的所述操作相关的数据的聚合引擎，和

联网引擎；和

可操作地耦合所述多个输液泵和所述嵌入式服务器的网络，其中所述联网引擎被配置成控制所述嵌入式服务器和所述至少一个输液泵的网络接入。

2.根据权利要求1所述的实时嵌入式服务器系统，其中所述多个输液泵各自包括用于控制所述泵送机构的操作的控件，并且其中所述控件通过由所述控制引擎发布的控制命令覆盖。

3.根据权利要求1所述的实时嵌入式服务器系统，其中所述联网引擎进一步被配置成与医院信息系统通信。

4.根据权利要求1所述的实时嵌入式服务器系统，其中所述网络为闭路或私人的中的至少一种。

5.根据权利要求1所述的实时嵌入式服务器系统，其中所述联网引擎被配置成将网络识别符分配到所述多个输液泵中的每个。

6.根据权利要求1所述的实时嵌入式服务器系统，进一步包含输液泵支架，所述输液泵支架包含主体、多个泵安装部分，和至少一个服务器安装部分，其中所述多个输液泵中的每个安装到所述多个泵安装部分中的一个，并且所述嵌入式服务器安装到所述至少一个服务器安装部分。

7.根据权利要求1所述的实时嵌入式服务器系统，其中所述存储器包含被配置成存储所述控制命令、所述消息、与所述至少一个输液泵的所述操作相关的所述数据和网络数据的数据库。

8.根据权利要求1所述的实时嵌入式服务器系统，其中所述控制引擎被配置成发布与捎带模式和接管模式中的至少一种相关的控制命令。

9.根据权利要求1所述的实时嵌入式服务器系统，其中所述控制引擎、信息传送引擎和联网引擎中的至少一种利用所述聚合引擎以聚合与所述至少一个输液泵的所述操作相关的数据。

10.根据权利要求1所述的实时嵌入式服务器系统，其中所述嵌入式服务器位于患者的床边处。

11.一种用于用实时嵌入式服务器控制多个输液泵的方法，所述方法包含：

实施实时嵌入式服务器，所述嵌入式服务器包括控制引擎，所述控制引擎被配置成向至少一个输液泵发布控制命令，所述控制命令与所述至少一个输液泵的所述操作相关；

实施至少一个输液泵，所述至少一个输液泵被配置成从所述嵌入式服务器接收控制命令；

实施可操作地耦合所述嵌入式服务器和所述至少一个输液泵的网络；

将来自所述控制引擎的控制命令向所述至少一个输液泵发布；和

基于所述控制命令实行所述至少一个输液泵的操作模式。

12.根据权利要求11所述的用于用所述实时嵌入式服务器控制多个输液泵的方法，进一步包含从所述至少一个输液泵接收消息。

13.根据权利要求12所述的用于用所述实时嵌入式服务器控制多个输液泵的方法，其中所述消息包含证实所述至少一个输液泵的所述控制命令、状态或操作数据中的至少一种。

14.根据权利要求13所述的用于用所述实时嵌入式服务器控制多个输液泵的方法，进一步包含：

将来自所述控制引擎的第二控制命令向所述至少一个输液泵发布，所述第二控制命令基于所述接收的消息。

15.根据权利要求14所述的用于用所述实时嵌入式服务器控制多个输液泵的方法，进一步包含基于所述第二控制命令实行所述至少一个输液泵的第二操作模式。

16.一种用实时嵌入式服务器聚合与多个输液泵相关的数据的方法，所述方法包含：

用实时嵌入式服务器从第一输液泵接收第一数据，所述第一数据包含与所述第一输液泵的所述操作相关的数据；

存储所述接收的第一数据；

用嵌入式服务器从第二输液泵接收第二数据，所述第二数据包含与所述第二输液泵的所述操作相关的数据；

存储所述接收的第二数据；和

对所述存储的第一数据和所述存储的第二数据执行聚合算法。

17.根据权利要求16所述的用所述实时嵌入式服务器聚合与多个输液泵相关的数据的方法，进一步包含将所述聚合算法的输出传输到外部系统。

18.根据权利要求17所述的用所述实时嵌入式服务器聚合与多个输液泵相关的数据的方法，其中所述外部系统包含医院信息系统。

19.根据权利要求16所述的用所述实时嵌入式服务器聚合与多个输液泵相关的数据的方法，其中所述第一数据或所述第二数据为消息、操作数据或网络数据中的至少一种。

20.根据权利要求16所述的用所述实时嵌入式服务器聚合与多个输液泵相关的数据的方法，其中存储所述接收的第一数据或存储所述接收的第二数据包含将所述第一数据或所述第二数据存储在数据库中。

21.一种患者护理系统，包含：

被配置成做出患者-特定护理决策的至少一个控制装置；和

可操作地耦合到患者并且被配置成由所述至少一个控制装置控制的相关联的装置网络。

22.根据权利要求21所述的系统，其中所述至少一个控制装置为医疗装置、多个医疗装置、计算机、电话、支架，或适于插入到系统部件中的模块中的至少一种。

23.根据权利要求21所述的系统，其中所述患者-特定决策将装置与所述装置网络相关联。

24.根据权利要求21所述的系统，其中所述患者-特定决策与治疗和药物为一对一关系。

25.根据权利要求21所述的系统，其中所述患者-特定决策为在药物之间的多个关系。

26.一种电子患者护理系统，包含：

至少一个医疗装置；

嵌入式实时服务器；和

包括电子医疗记录系统或医院信息系统中的至少一种的至少一个IT系统，

其中所述嵌入式实时服务器提供在所述至少一个医疗装置和所述至少一个IT系统之间的通信桥，因此所述至少一个医疗装置和所述至少一个IT系统选择性地互连以为所述患者提供通知和建议治疗。

27.根据权利要求26所述的电子患者护理系统，其中通过所述系统生成的数据用ICD编码协调以建议特定治疗。

28.根据权利要求26所述的电子患者护理系统，其中通过所述系统生成的数据用在结果类报销系统下的大数据协调。

29.根据权利要求26所述的电子患者护理系统，其中所述嵌入式实时服务器通过具有微处理器、通信部件和存储器的医疗装置提供。

30.根据权利要求29所述的电子患者护理系统，其中所述医疗装置为泵、支架或患者生命体征监测器中的至少一种。