的一部分。例如，场景可以包括用于输送流体(包括药物)至患者的各种系统/单元。一种特殊类型的医疗设备140为输注模块140A。输注模块140A可以包括各种类型的输注栗，其包括蠕动式输注栗、大容量输注栗以及注射式输注栗。输注模块140A可以与网络105直接连接，和/或它们可以与医疗设备140连接，而医疗设备140又与网络140连接。
[0022]除非特别指定，医疗设备140还可以包括具有通信接口的任意类型的设备或系统，该通信接口表征患者的一个或多个生理测量和/或患者的治疗。在一些情况下，医疗设备140通过对等的有线或无线通信方式与另一个医疗设备140通信(与网络105的通信情况相对)。例如，医疗设备140可以包括连接至其它的医疗设备140的床边生命体征监测器，即无线脉搏血氧计和有线血压监测器。医疗设备140的一个或多个操作参数可以由临床医生在本地控制、通过网络105由临床医生来控制、和/或它们可以通过服务器115、120、客户端125、MCD130和/或其它的医疗设备140中的一个或多个来控制。
[0023]计算场景100可以提供如在医疗护理环境中(诸如医院)可能所需的各种类型的功能。这是因为医疗设备140可以提供表征患者的一个或多个生理测量和/或患者的治疗的数据(例如，医疗设备140可以为输注管理系统等)。由医疗设备140产生的数据可以与其它的医疗设备140、服务器110、115、客户端120、MCD130进行通信，和/或被存储在数据存储系统125中。
[0024]计算场景100还可以包括至少一个药物订单系统145。药物订单系统145与网络连接，并且能够产生订单(例如，处方等)并进行监控。例如，药物订单系统145可以利用应用服务器115，通过客户端120和MCD130中的一个来访问。药物订单系统145可以指定多个药物和/或其它流体，该指定的多个药物和/或其它流体通过至少一个输注模块140A，在预定的时间段内并根据预定的顺序输注至患者。这些订单可以存储在数据存储设备125中和/或推送至其它的客户端120、MCD130和/或医疗设备140的一个或多个。在一些情况下，护理人员基于患者的反应(如通过各种生理传感器所测量的，等等)来更改这种药物输送的时序和顺序。
[0025]医疗设备140中的一个或多个(诸如输注模块140A)可以监控输送至患者的流体(例如，药物等)的量。流体输送至患者在本文中被称作为输注。除非另有特别说明，本文中所引用的药物也应当被解释为包括经由输注模块140A输送至患者的非药物的流体(例如，血液、生理盐水等)。
[0026]如上所述，容纳流体(诸如，药物)的容器通常与药剂师/开药者开出的容积不同。可以提供软件实现的输注管理平台150，其包括图形用户界面，该图像用户界面用于跟踪和监控一个或多个患者的输注。输注管理平台150通过网络105与输注模块140A通信。输注模块140A可以直接或间接地提供与特定的输注相关的各种属性(例如，患者标识符、药物容器标识符、药物类型、给药速率、输注模块标识符等)至输注管理平台150。可以例如经由从输注模块140A发送的消息来提供这些属性。在一些情况下，输注管理平台150从药物订单系统145中接收药物订单，然后将这些订单与特定的输注模块140A和/或特定的患者(该患者随后与输注t吴块140A相关联)相关联。
[0027]输注顺序(其可以通过输注管理平台150来监控)为可以包括输注开始、输注停止或者完成的一系列事件，并且包括在这期间发生的所有事件(报警、暂停、重新开始等)。各种事件通过输注管理平台150 (或者可替选地，在输注模块140A上)来一起分组，作为单个订单标识(ID)。订单ID可以通过例如条形码或者RIV0，由医院/院所来提供，或者在不利用条形码的情况下，由输注管理平台150本身产生(例如，PCU序列号+递增计数器)。
[0028]以下描述了通过输注管理平台150如何来分配针对输注的订单ID。每次输注可以具有订单ID。如果作为输注的一部分的将要输注的量(VTBI)改变，则可以分配新的订单ID0如果输注的药物改变，则可以分配新的订单ID。如果用于输注的药物的容器(例如，注射器等)改变，则可以分配新的订单ID。另外，停止并进而恢复/继续的输注应当利用原始的订单ID。
[0029]图2为示出了图1的不同视图的示意图200，其中，输注模块140A通过网络105连接至输注管理平台150 (或者如上所述直接地或间接地连接)。输注管理平台150包括数据分组逻辑210，其包括一组规则(这些规则中的至少一些是用户可配置的)，这组规则限定了如何基于由输注模块140A产生的数据来对输注事件进行分组。数据分组逻辑210可以被合并在输注管理平台150中，和/或其可以利用输注管理平台150通过网络服务器而被远程访问。
[0030]VTBI的变化不是必须地构成新输注的开始。如果输注袋里剩有药物或流体，则临床医生将进入新的VTBI，以完成剩余的药物或流体。利用更常规的输注系统，进入新的VTBI将导致新的订单ID分配，尽管这不是新的输注。本发明的主题通过基于输注的开始和结束的状态来将输注分组(利用例如数据分组逻辑210)解决了这种问题。
[0031]在一些实施方式中，输注管理平台150能够利用数据分组逻辑210使用系统产生的订单ID对输注进行分组。具有由医院提供的(通过条形码或者RIV0)订单ID的输注可以基于订单ID来进行分组。
[0032]参照图3中的图300，可以基于输注配置(infus1n profile)来对输注顺序进行分组。输注配置可以基于如下中的一个或多个:药品名称、患者ID、输注类型、PCU序列号以及设备模块编号，并且这些信息可以从输注模块140A中的一个或多个发送至输注管理平台150。在步骤310中，可以确定当前输注是否具有任意一些与之前输注相同的特性。例如，如果当前输注具有相同的药品名称、患者ID、输注类型、PCU序列号以及输注模块序列号，则可以做出确定。为了进行比较，不是需要所有的配置信息。例如，如果患者ID和药品名称是不可利用的，则输注模块序列号可以优先，接着是PCU序列号和输注类型。
[0033]可以形成可用的关于之前输注的各种类型的状态信息。例如，状态信息可以表示之前输注停止和开始(但不是完成)。这种状态信息可以通过来自输注模块140A的原因代码来获得。原因代码可以表示例如，输注开始和停止。
[0034]在步骤330中，可以确定当前输注的将要输注的量(VTBI)与之前输注的输注量之比。在步骤340中，如果该比值在预定的填充阈值百分比之上，则可以分配新的订单ID。例如，如果当前输注的VTBI超过之前输注的输注量的20%。否则，在步骤350中，如果该比值在预定的填充阈值百分比之下，则可以利用之前输注的订单ID。在步骤360中，如果状态指示出完成了之前的输注(而不是停止)，则在步骤370中，可以对当前输注分配新的订单ID0
[0035]在一些情况下，预定的填充阈值百分比可以变化，例如，该百分比可以变化20%至15%。在这些情况下，可以回顾性地分析历史输注数据，并且在许可的情况下分配新的订单ID0
[0036]可以利用各种类型的事件来更新状态，以指示出完成了之前的输注。可以存在明确的原因代码，其指定出完成输注过程、断电和开始新输注中的一个或多个。类似地，可以利用各种类型的事件来更新状态，以指示出之前的输注未完成。例如，可以存在明确的原因代码，其暗示了输注过程未完成，诸如报警状态、输注过程中止、输注过程重新开始、以及输注过程转换。
[0037]图4为处理流程图400，其中，在步骤410中，接收表征经由输注模块从容器至患者的流体的