具体实施方式

患者自控镇痛泵可以允许患者直接控制药物的递送，而不必依靠医疗专业人员通过肌肉注射或静脉内注射施用阿片类止痛药。例如，患者控制的镇痛泵可以包含多剂量药物的注射器，可以以一个或更多个患者需求剂量、临床医生剂量、装载剂量和/或维持剂量向患者施用所述药物。此外，在治疗过程期间，患者可以接受多个注射器的药物。因此，可能难以追踪向患者递送的实际药物的体积，由此导致药物有可能被滥用或转移到没有合法授权接受、拥有和/或消费药物的第三方。如此，在一些示例实施例中，追踪引擎可以配置成确定通过向患者施用的药物的多种剂量和/或多个注射器向患者递送的药物的实际体积。追踪向患者递送的实际药物量可以减少和/或消除滥用或转移的机会。

图1A描绘了示出根据一些示例实施例的药物追踪系统100的系统图。参考图1A，药物追踪系统100可以包括追踪引擎110、泵22和客户端130。如图1A所示，追踪引擎110、泵22和/或客户端130可以通过网络150通信地连接。客户端130可以是移动装置，如智能手机、平板电脑、可穿戴设备等。然而，应当理解，客户端130可以是任何基于处理器的装置，包括例如，台式计算机、笔记本电脑、工作站等。同时，网络150可以是任何有线和/或无线网络，包括例如公共陆地移动网络(PLMN)、局域网(LAN)、虚拟局域网(VLAN)、广域网(WAN)、互联网等。另外地和/或可替代地，追踪引擎110和/或客户端130可以形成泵22的至少一部分。

泵22可以是配置成向患者递送药物的患者控制的镇痛(PCA)泵。然而，应当理解，泵22可以是如下配置的任何输注系统，该输注系统通过例如静脉内输注、皮下输注、动脉输注、硬膜外输注等向患者的循环系统或硬膜外腔递送物质(例如，流体、营养素、药物等)。或者，泵22可以是配置成通过鼻胃管(NG)、经皮内镜胃造口管(PEG)、鼻空肠管(NJ)等向患者的消化系统递送物质(例如，流体、营养素、药物等)的输注系统。此外，泵22可以是包括一个或更多个另外的泵的患者护理系统的一部分。

如图1A所示，泵22可以配置成容纳包含例如阿片类镇痛药物(例如，吗啡、氢吗啡酮、芬太尼等)的药物的一个或更多个注射器。例如，可以将包含第一药物的第一注射器140a插入到泵22中，使得泵22可以以一个或更多个剂量(剂量包括例如患者需求剂量、临床医生剂量、装载剂量和/或维持剂量)向患者递送第一药物。例如，当第一注射器140a中剩余阈值量的第一药物时、当从第一注射器140a向患者递送了阈值量的第一药物时等，可以从泵22中取出第一注射器140a并且替换为包含第一药物或第二药物的第二注射器140b。

在一些示例实施例中，追踪引擎110可以配置成确定通过多个药物注射器(注射器包括例如第一注射器140a、第二注射器140b等)经由泵22向患者递送的一种或多种药物的体积。例如，追踪引擎110可以响应于第一注射器140a被插入到泵22中和/或向患者递送来自第一注射器140a的第一药物来追踪向患者递送的第一药物的体积。可替代地和/或另外地，追踪引擎110可以响应于第二注射器140b被插入到泵22中和/或向患者递送来自第二注射器140b的第二药物来追踪向患者递送的第二药物的体积。为了进一步说明，图2A描绘了根据一些示例实施例的向患者施用的相同药物的多个注射器的体积追踪。例如，在向患者递送了来自第一注射器的药物之后，追踪引擎110可以追踪由第一注射器(例如，第一注射器140a)和第二注射器(例如，第二注射器140b)递送的药物的体积。如以下更详细地描述的，追踪引擎110可以向例如具有客户端130和/或泵22的用户界面的显示器的装置(见图4)报告追踪到的由每个注射器递送的药物的体积。

此外，追踪引擎110可以追踪以不同的药物剂量从第一注射器140a和/或第二注射器140b向患者递送的一种或多种药物的体积。例如，追踪引擎110可以追踪以患者需求剂量、临床医生剂量、装载剂量、维持剂量等向患者递送的第一药物和/或第二药物的剂量。为了进一步说明，图2B描绘了根据一些示例实施例的向患者施用的相同药物的多种剂量的体积追踪。如以下更详细地描述的，追踪引擎110可以向例如具有客户端130和/或泵22的用户界面的显示器的装置(见图4)报告与每种剂量类型相对应的追踪到的由每个注射器递送的药物的体积。

如本文所使用的，患者需求剂量可以是指泵22响应于来自患者的请求而向患者递送的药物的单次剂量，而临床医生剂量可以是指泵22响应于来自医疗专业人员的请求而向患者递送的药物的单次剂量。同时，装载剂量可以是指在治疗开始时泵22向患者递送的药物的较高剂量，而维持剂量可以是指在一个或更多个装载剂量之后泵22向患者递送的药物的较低剂量。可以例如以固定大小部分和/或以设定速率向患者递送维持剂量的药物。

在一些示例实施例中，追踪引擎110可以至少通过识别注射器中包含的药物来响应药物的注射器被插入到泵中。例如，追踪引擎110可以至少通过识别第一注射器140a中包含的药物来响应第一注射器140a被插入到泵22中。可替代地和/或另外地，追踪引擎110可以至少通过识别第二注射器140b中包含的药物来响应第二注射器140b被插入到泵22中，以例如替代第一注射器140a。如果追踪引擎110确定第二注射器140b包含与第一注射器140a相同的第一药物，则追踪引擎110可以继续追踪从第二注射器140b向患者递送的第一药物的体积。相比之下，如果追踪引擎110确定第二注射器140b包含第二药物而非第一注射器140a中包含的第一药物，则追踪引擎110可以开始追踪从第二注射器140b向患者递送的第二药物的体积。

如图1A所示，泵22可以包括标签读取器122，所述标签读取器122配置成读取与第一注射器140a相关的第一标识符标签145a和/或与第二注射器140b相关的第二标识符标签145b。例如，第一标识符标签145a和/或第二标识符标签145b可以是条形码、快速响应(QR)码、射频识别(RFID)标签等。在一些示例实施例中，第一标识符标签145a和/或第二标识符标签145b可以存储用于标识第一注射器140a和/或第二注射器140b中包含的药物的数据。可替代地和/或另外地，第一标识符标签145a和/或第二标识符标签145b可以存储用于标识与第一注射器140a和/或第二注射器140b关联的患者、医疗专业人员、配混设施和/或治疗设施的数据。因此，追踪引擎110可以基于来自泵22处的标签读取器122的输出来识别与第一注射器140a和/或第二注射器140b的每个关联的药物、患者、医疗专业人员、配混设施和/或治疗设施。

在一些示例实施例中，追踪引擎110可以维持一个或更多个计数器，以追踪通过多种剂量(剂量包括例如患者需求剂量、临床医生剂量、装载剂量和/或维持剂量)向患者递送的药物的体积。再次参考图1A，追踪引擎110可以维持多个计数器，所述多个计数器的每个计数器配置成追踪以对应的剂量类型向患者递送的药物的体积。例如，追踪引擎110可以维持第一剂量计数器115a和第二剂量计数器115b，所述第一剂量计数器115a配置成追踪以一个或更多个维持剂量递送的药物的体积，所述第二剂量计数器115b配置成追踪以一个或更多个患者需求剂量递送的药物的体积。追踪引擎110可以基于来自体积装置(例如在泵22处或与泵22通信地连接的体积计124)的输出来更新第一剂量计数器115a和/或第二剂量计数器115b。

体积计124可以配置成响应于一个或更多个事件(事件包括例如插入注射器、施用一个或更多个剂量的药物等)来向追踪引擎110报告第一注射器140a和/或第二注射器140b中的药物的体积。第一剂量计数器115a和/或第二剂量计数器115b可以至少基于由体积计124报告的从第一注射器140a和/或第二注射器140b递送的药物的体积来进行更新。例如，当第一注射器140a和/或第二注射器140b首次插入到泵22时，体积计124可以向追踪引擎110报告第一注射器140a和/或第二注射器140b中存在的药物的初始体积。可替代地和/或另外地，在施用每个剂量的药物之后，体积计124可以向追踪引擎110报告从第一注射器140a和/或第二注射器140b递送的药物的体积。例如，在施用患者需求剂量、临床医生剂量、装载剂量和/或维持剂量之后，体积计124可以向追踪引擎110报告由第一注射器140a和/或第二注射器140b递送的药物的体积。为了确定注射器中的初始体积，体积计124可以接收用于输注的编程信息，如待输注的总体积。在一些实施方案中，体积计124可以使用图像来检测注射器上的标识符或注射器内的药物水平。基于对一个或更多个图像的分析，可以确定体积。分析可以包括识别注射器内的液位、识别注射器上的标记(例如，体积刻度标记、结构参考、可扫描代码)或其它可检测的特征。例如，如果可以在特定的体积标记处识别流体线，从而提供注射器内的体积。作为另一个示例，图像可以示出标识注射器的信息，如条形码或序列号。该信息可以用于查询数据库，以标识由注射器制备者(例如，药房医生、处方医生)包含的药物的体积。在一些实施方案中，所述信息可以标识注射器的几何形状，所述几何形状然后可以用于产生注射器的体积。

体积计124可以追踪递送的药物的具体体积。在一些实施方案中，体积计124可以提供递送的估算体积。可以至少部分地基于流速、待输注的体积(“VTBI”)和输注的持续时间中的一个或更多个来产生该估算。

如所指出的，追踪引擎110可以至少基于由追踪引擎110维持的一个或更多个计数器的值来确定经由泵22向患者递送的第一药物和/或第二药物的体积。例如，追踪引擎110可以至少通过存储第一剂量计数器115a和/或第二剂量计数器115b的当前值来维持第一剂量计数器115a和/或第二剂量计数器115b。此外，追踪引擎110可以更新第一剂量计数器115a和/或第二剂量计数器115b的当前值以反映从包含第一药物的第一注射器140a以一个或更多个维持剂量和/或患者需求剂量向患者递送的药物的体积。例如，当从第一注射器140a向患者递送一个或更多个维持剂量和/或患者需求剂量时，追踪引擎110可以使第一剂量计数器115和/或第二剂量计数器115b的当前值递增。

在一些示例实施例中，当用包含第二药物的第二注射器140b替代包含第一药物的第一注射器140a时，追踪引擎110可以重置第一剂量计数器115a和/或第二剂量计数器115b。例如，当追踪引擎110确定第二注射器140b包含第二药物而非第一注射器140a中包含的第一药物时，追踪引擎110可以至少通过将第一剂量计数器115a和第二剂量计数器115b的当前值设定为零来重置第一剂量计数器115a和第二剂量计数器115b。可以重置第一剂量计数器115a和第二剂量计数器115b，以避免从第一注射器140a向患者递送的第一药物的体积与从第二注射器140b向患者递送的第二药物的体积混淆。

可替代地和/或另外地，追踪引擎110可以响应于患者与泵22解除关联和/或不同的患者与泵22关联来重置第一剂量计数器115a和/或第二剂量计数器115b。例如，当追踪引擎110确定患者与泵22解除关联和/或不同的患者与泵22关联时，追踪引擎110可以将第一剂量计数器115和第二剂量计数器115b的当前值设定为零。在该情况下，可以重置第一剂量计数器115a和第二剂量计数器115b，以避免递送到不同患者的药物的体积混淆。

在一些示例实施例中，追踪引擎110可以配置成基于通过多种剂量和/或注射器向患者递送的药物的体积来生成一个或更多个电子警报。例如，追踪引擎110可以响应于向患者递送的药物的体积大于和/或小于阈值而生成一个或更多个电子警报。一个或更多个电子警报可以包括无线警报消息，例如，推送通知、短消息服务(SMS)消息等。此外，一个或更多个电子警报可以包括异常类型的指示，所述异常类型包括例如，递送的药物的体积大于阈值、递送的药物的体积小于阈值等。可替代地和/或另外地，一个或更多个电子警报可以包括患者标识符、药物标识符和/或向患者递送的药物的量。例如，一个或更多个电子警报可以规定向患者递送的药物的体积、剂量的量和/或剂量的类型(例如，患者需求剂量、临床医生剂量、装载剂量、维持剂量等)。

例如，追踪引擎110可以检测从第一注射器140a和/或第二注射器140b向患者递送的药物体积中存在的一个或更多个异常。可替代地和/或另外地，追踪引擎110可以检测以一个或更多个患者需求剂量、临床医生剂量、装载剂量和/或维持剂量向患者递送的药物体积中存在的一个或更多个异常。一个或更多个异常可以包括向患者递送的药物的体积大于和/或小于一个或更多个阈值。图3描绘了根据一些示例实施例的与药物追踪系统100相关的警报阈值的示例。响应于检测到存在一个或更多个异常，追踪引擎110可以生成可发送到与客户端130关联的医疗专业人员的一个或更多个警报。

图1B描绘了示出根据一些示例实施例的药物追踪系统100的框图。参考图1A-B，药物追踪系统100的追踪引擎110可以配置成维持一个或更多个计数器，所述一个或更多个计数器包括例如第一剂量计数器115a、第二剂量计数器115b等。响应于以一个或更多个患者需求剂量、临床医生剂量、装载剂量和/或维持剂量将药物从第一注射器140a向患者施用，可以通过追踪引擎110更新第一剂量计数器115a和/或第二剂量计数器115b的值。如果追踪引擎110至少基于由泵22处的标签读取器122读取的第一标识符标签145a和/或第二标识符标签145b确定出与第二注射器140b关联的药物和患者至少和与第一注射器140a关联的药物和患者相同，则当用第二注射器140b替代第一注射器140a时，追踪引擎110可以继续更新第一剂量计数器115a和/或第二剂量计数器115b(例如，使其递增)。

可替代地和/或另外地，图1B示出了如果追踪引擎110至少基于由泵22处的标签读取器122读取的第一标识符标签145a和/或第二标识符标签145b确定出与第二注射器140b关联的药物和/或患者和与第一注射器140a关联的药物和/或患者不同，则追踪引擎110可以配置成将第一剂量计数器115a和第二剂量计数器115b重置为指定的起始值。例如，如果追踪引擎110确定第二注射器140b包含的药物与第一注射器140a包含的药物不同，则可以重置第一剂量计数器115a和第二剂量计数器115b，以避免向患者递送的不同药物的体积混淆。可替代地和/或另外地，如果追踪引擎110确定与第二注射器140b关联的患者和与第一注射器140a关联的患者不同，则可以重置第一剂量计数器115和第二剂量计数器115b，以避免向不同患者递送的药物的体积混淆。

此外，图1B示出了追踪引擎110可以配置成生成可发送到与客户端130关联的医疗专业人员的一个或更多个警报。追踪引擎110可以响应于追踪引擎110检测到例如从第一注射器140a和/或第二注射器140b向患者递送的药物的体积中存在一个或更多个异常而生成一个或更多个警报。如图3进一步示出的，追踪引擎110可以响应于异常而生成一个或更多个警报，所述异常包括向患者递送的药物的体积大于最大阈值和/或小于最小阈值。最大阈值和/或最小阈值可以与时间间隔关联，从而如果在一定时间间隔(例如，24小时等)内向患者递送过量体积和/或不足量体积的药物，则追踪引擎110可以生成一个或更多个警报。例如，如图2A所示，如果在设定的时间间隔内向患者递送不足量体积的药物，则追踪引擎110可以生成一个或更多个警报，如阻塞警报。在一些实施例中，当递送的药物的体积小于期望剂量药物的体积和/或注射器(例如，第一注射器140a和/或第二注射器140b)的体积时，递送的药物的体积是不足量的。

图4描绘了包括用户界面300的示例显示器。用户界面300可以形成客户端130和/或泵22的一部分。用户界面300示出了经由代表泵22的第一泵通道(例如，通道A)的药物递送的各个方面的示例状态汇总。

用户界面300可以接收并显示从追踪引擎110和/或流量计124接收到的数据。例如，用户界面300可以显示通过与泵22连接的每个注射器(例如，第一注射器140a、第二注射器140b等)的药物递送的开始时间、通过与泵22连接的每个注射器的药物递送的结束时间、向患者递送的药物的平均递送速率、当前递送速率和/或期望递送速率、VTBI、通过连接的注射器已经向患者输注的药物的体积以及向患者递送的药物的累积体积。如上所述，可以至少部分地基于流速、VTBI、输注的持续时间、由追踪引擎110维持的一个或更多个计数器的值、经由泵22向患者递送的第一药物和/或第二药物的体积等中的一个或更多个来生成累积体积。用户界面300可以允许和/或接收对累积体积的一个或更多个时间段(时间段例如1小时、12小时、48小时和/或介于它们之间的其它时间间隔)的选择。

确定和显示各个时间段内的累积体积可以有助于确保向患者递送了适当量的药物，有助于限制或防止药物转移，和/或可以在将患者转换为如逐渐减少的方案、药丸等另一种治疗形式时帮助用户。例如，用户界面300可以向用户提供关于从特定注射器的药物递送的开始时间和结束时间以及更换注射器的时间。用户界面300还可以显示递送的药物的累积体积和待向患者递送的剩余药物的体积。因此，通过用户显示器300，用户可以容易地确定是否从泵22不当地转移了一定体积的药物。另外地和/或可替代地，基于所确定和/或所显示的累积体积，用户可以改变当前的治疗计划和/或逐渐减少向患者递送的药物。

图5描绘了示出根据一些示例实施例的用于追踪向患者递送的药物的体积的方法400的流程图。参考图5，方法400可以由药物追踪系统100执行。

在402处，药物跟踪系统100可以至少通过维持第一计数器(其响应于以第一剂量类型向患者施用第一药物而更新)和第二计数器(其响应于以第二剂量类型向患者施用第一药物而更新)的来追踪从插入泵22中的第一注射器向患者递送的第一药物的第一体积。例如，追踪引擎110可以至少通过维持一个或更多个计数器(包括例如第一剂量计数器115a、第二剂量计数器115b等)来追踪从泵22中的第一注射器140a向患者递送的第一药物的体积。每个计数器可以与可向患者施用的一种剂量类型关联，所述剂量类型包括例如患者需求剂量、临床医生剂量、装载剂量和/或维持剂量。如此，可以响应于以对应的剂量类型向患者递送第一注射器140a中的药物来更新每个计数器的值。例如，每当从第一注射器140a向患者施用维持剂量的第一药物时，就可以更新第一剂量计数器115a，而每当从第一注射器140a向患者施用患者需求剂量的第一药物时，就可以更新第二剂量计数器115b。

在404处，药物追踪系统100可以至少基于第一计数器和/或第二计数器来确定向患者递送的第一药物的第一体积。例如，追踪引擎110可以至少基于第一剂量计数器115a和第二剂量计数器115b的各个值来确定以维持剂量向患者施用的第一药物的体积，以患者需求剂量向患者施用的第一药物的体积，和/或通过所有剂量类型向患者施用的第一药物的总体积。

在406处，药物追踪系统100可以响应于包含第二药物的第二注射器被插入到泵22中以替代第一注射器而重置第一计数器和第二计数器。例如，当插入到泵22中以替代第一注射器140a的第二注射器140b包含的药物与第一注射器140a包含的药物不同时，追踪引擎110可以重置第一剂量计数器115a和第二剂量计数器115b。可替代地和/或另外地，如果与第二注射器140b关联的患者和与第一注射器140a关联的患者不同，也可以重置第一剂量计数器115a和第二剂量计数器115b。如果第二注射器140b包含的药物与第一注射器140a包含的药物相同并且与第二注射器140b关联的患者和与第一注射器140a关联的患者相同，则追踪引擎110可以继续更新第一剂量计数器115a和/或第二剂量计数器115b，而不重置第一剂量计数器115a和/或第二剂量计数器115b。可以响应于以维持剂量从第二注射器140b向患者施用第一药物来更新第一剂量计数器115a，可以响应于以患者需求剂量从第二注射器140b向患者施用第一药物来更新第二剂量计数器115b。

在408处，药物追踪系统100可以至少通过响应于以第一剂量类型向患者施用第二药物而更新第一计数器和/或响应于以第二剂量类型向患者施用第二药物而更新第二计数器来追踪从插入泵22中的第二注射器向患者递送的第二药物的第二体积。例如，当包含第二药物的第二注射器140b被插入到泵22中时，追踪引擎110可以开始追踪从第二注射器140b向患者递送的第二药物的体积。追踪引擎110可以至少通过每当从第二注射器140b向患者施用维持剂量的第二药物时就更新第一剂量计数器115a，并且每当从第二注射器140b向患者施用患者需求剂量的第二药物时就更新第二剂量计数器115b来追踪向患者递送的第二药物的体积。

在410处，药物追踪系统100可以至少基于第一计数器和/或第二计数器来确定向患者递送的第二药物的第二体积。例如，追踪引擎110可以至少基于第一剂量计数器115a和第二剂量计数器115b的各个值来确定以维持剂量向患者施用的第二药物的体积，以患者需求剂量向患者施用的第一药物的体积，和/或通过所有剂量类型向患者施用的第一药物的总体积。

在412处，药物追踪系统100可以响应于检测到向患者递送的第一药物的第一体积和/或向患者递送的第二药物的第二体积中的一个或更多个异常来生成电子警报并向客户端130发送所述电子警报。例如，追踪引擎110可以检测这样的一个或更多个异常，所述异常包括向患者递送的第一药物的第一体积和/或向患者递送的第二药物的第二体积大于、小于或等于阈值。另外地和/或可替代地，追踪引擎110可以检测这样的一个或更多个异常，所述异常包括检测到的转移事件，如当向患者递送的药物量与仍有待向患者递送的药物量之间存在差异时。追踪引擎110可以生成电子警报，所述电子警报包括例如无线警报消息，例如，推送通知、短消息服务(SMS)消息等。可以将电子警报发送到可与医疗专业人员关联的客户端130。

图6描绘了示出与当前主题的实施方案一致的计算系统500的框图。参考图1和图5，计算系统500可以用于实施追踪引擎110和/或其中的任何组件。

如图6所示，计算系统500可以包括处理器510、存储器520、存储装置530和输入/输出装置540。处理器510、存储器520、存储装置530和输入/输出装置540可以通过系统总线550互连。处理器510能够处理用于在计算系统500内执行的指令。此类执行的指令可以实施例如追踪引擎110的一个或更多个组件。在一些示例实施例中，处理器510可以是单线程处理器。或者，处理器510可以是多线程处理器。处理器510能够处理存储在存储器520中和/或存储装置530上的指令，以显示通过输入/输出装置540提供的用户界面的图形信息。

如本文所使用的，“用户界面”(也称为交互式用户界面、图形用户界面或UI)可以指基于网络的界面，包括用于接收输入信号或提供电子信息和/或响应于任何接收到的输入信号向用户提供信息的数据字段和/或其它控制元件。控制元件可以包括拨号盘、按钮、图标、可选区域或其它通过UI呈现的可感知标记，当与其交互(例如，点击、触摸、选择等)时，启动呈现UI的装置的数据交换。可以使用如超文本标记语言(HTML)、FLASHTM、JAVATM、NETTM、web服务或丰富站点摘要(RSS)的技术整体或部分地实施UI。在一些实施方案中，UI可以包括在独立客户端(例如，厚客户端、胖客户端)中，所述独立客户端配置成根据所描述的一个或更多个方面进行通信(例如，发送或接收数据)。通信可以是到与其通信的医疗装置、诊断装置、监测装置或服务器或来自与其通信的医疗装置、诊断装置、监测装置或服务器。

存储器520是计算机可读介质，如在计算系统500内存储信息的易失性或非易失性计算机可读介质。例如，存储器520可以存储表示配置对象数据库的数据结构。存储装置530能够为计算系统500提供永久存储。存储装置530可以是软盘装置、硬盘装置、光盘装置或磁带装置、或其它合适的永久存储装置。输入/输出装置540为计算系统500提供输入/输出操作。在一些示例实施例中，输入/输出装置540包括键盘和/或定点装置。在各种实施方案中，输入/输出装置540包括用于显示图形用户接口的显示单元。

根据一些示例实施例，输入/输出装置540可以为网络装置提供输入/输出操作。例如，输入/输出装置540可以包括以太网端口或其它网络端口，以与一个或更多个有线和/或无线网络(例如，局域网(LAN)、广域网(WAN)、互联网)通信。

在一些示例实施例中，计算系统500可以用于执行各种交互式计算机软件应用程序，所述交互式计算机软件应用程序可以用于以各种格式组织、分析和/或存储数据。或者，计算系统500可以用于执行软件应用程序。这些应用程序可以用于执行各种功能，例如规划功能(例如，生成、管理、编辑电子表格文档、文字处理文档和/或任何其它对象等)、计算功能、通信功能等。应用程序可以包括各种附加功能，或者可以是独立计算产品和/或功能。一旦在应用程序内启用，这些功能就可以用于生成通过输入/输出装置540提供的用户接口。用户接口可以由计算系统500(例如，在计算机屏幕监视器等上)生成并呈现给用户。

在一些示例实施例中，泵22可以是图7A所示的患者护理系统20的一部分。参照图7A，患者护理系统20可以包括泵22以及另外的泵24、26和28。如图7A所示，泵22、24、26和28的每一个可以分别与上游流体管线30、32、34和36流体连接。此外，四个泵22、24、26和28的每一个也可以分别与下游流体管线31、33、35和37流体连接。流体管线可以是任何类型的流体导管，如流体可以流过的管道。一个或更多个流体管线的至少一部分可以使用如本文所述的多层配置构造。

流体供应装置38、40、42和44(可以采用各种形式，但在此情况下示出为瓶子)倒置并悬挂在泵上方。流体供应装置也可以采用袋子、注射器或其它类型的容器的形式。患者护理系统20和流体供应装置38、40、42和44两者安装在辊支架或静脉内(IV)杆46上。

可以使用单独的泵22、24、26和28将流体供应装置的每种流体输注到患者体内。泵22、24、26和28可以是流量控制装置，所述流量控制装置将作用于相应的流体管线以使流体从流体供应装置通过流体管线移动到患者48。由于使用了单独的泵，因此每个泵都可以被单独设置为以医师针对所述流体规定的特定速率将特定医疗流体从相应的流体供应装置输注到患者体内所需的泵送或操作参数。此类医疗流体可以包括药物或营养素或其它流体。

通常，医疗流体施用装置的部件比图7A中所示的部件多。许多具有止回阀、滴注室、带阀端口、连接器和本领域技术人员熟知的其它装置。为了保持图示的清晰度，这些其它装置未包括在附图中。另外，应注意的是，图7A的图示不按比例缩放，并且为了清晰起见，距离已压缩。在实际设置中，瓶子38、40、42和44与泵模块22、24、26和28之间的距离可能要大得多。

现在参照图7B，示出了患者护理系统20前部的放大视图。泵22可以包括前门50和把手52，所述把手52操作以将门锁定在关闭位置以进行操作，并且解锁和打开门以进入内部泵送和感测机构并装载泵的施用装置。当门打开时，管可以与泵连接，如图7C示出的。当门关闭时，管与泵送机构、上游和下游压力传感器以及泵的其它设备进行操作接合。在此实施例中，显示器54(如LED显示器)位于门的平面视图中，并且可以用于视觉传达与泵相关的各种信息，如警报指示(例如，警报消息)。控制键56存在以根据需要对编程和控制泵的操作。泵22还包括扬声器形式的音频报警设备(未示出)。

在所示实施例中，编程模块60附接到泵22的左侧。其它装置或模块(包括另一个泵)可以附接到泵22的右侧，如图7A所示。在该系统中，每个所附接的泵代表整个患者护理系统20的泵通道。在一个实施例中，编程模块用于提供泵22与外部装置之间的界面，并且为泵22提供大部分操作人员界面。

编程模块60包括用于视觉传达各种信息的显示器62(其可以包括用户界面300)，如泵22的操作参数以及警报指示和报警消息。编程模块60还可以包括扬声器以提供声音警报。在该实施例中，编程模块或任何其它模块还具有各种输入装置，包括控制键64和条形码或其它扫描仪或读取器，以扫描来自与输注、患者、护理者等相关的电子数据标签的信息。编程模块还具有通信系统(未示出)，编程模块可以通过该通信系统与外部设备(如医疗设施服务器或其它计算机)以及便携式处理器(如手持便携式数字助理(“PDA”)或笔记本电脑)或其它信息装置(其为护理者可能需要传递信息并将药物库下载到编程模块或泵的装置)进行通信。在一些实施方案中，泵22可以向编程模块60提供体积数据，编程模块60进而可以维持计数器和/或使得与检测到的异常相关的警报消息发送。在该实施方案中，编程模块60可以与追踪引擎110通信，包括追踪引擎110或实施本文所描述的追踪引擎110的特征。

通信系统可以采用射频(“RF”)(射频)系统、如红外的光学系统、蓝牙系统或者其它有线或无线系统的形式。条形码扫描仪和通信系统可以可替代地整体包括有泵22，如在不使用编程模块的情况下或除了使用编程模块的情况之外。进一步地，信息输入装置不需要硬连线到医疗器械，信息也可以通过无线连接传递。

图7B包括连接到编程模块60的第二泵26。如图7A所示，可以连接更多泵模块。此外，其它类型的模块可以连接到泵模块或编程模块。在该实施方案中，追踪引擎110可以为每个泵(例如，泵22和泵26)维持对应的剂量类型的计数器。

现在转到图7C，泵22以透视图示出，其中前门50打开，示出上游流体管线30和下游流体管线31与泵22有效接合。泵22直接作用于管66(也称为泵区段)，管66将上游流体管线30连接到下游流体管线31，以形成从相应的流体供应装置38(图7A)延伸到患者48的连续流体导管，泵通过所述连续流体导管作用于流体以使流体向下游移动到患者。具体而言，泵送机构70用作泵的流量控制装置，以使流体移动通过导管。上游和下游流体管线和/或管66可以连接到泵盒或筒，所述泵盒或筒配置成连接到泵22，如通过引用并入本文的共同未决的美国专利申请序列号13/827,775中描述的类型。

泵送机构的类型可以变化，并且可以是例如多指泵送机构。例如，泵送机构可以属于“四指”类型，并且包括上游阻塞指72、主泵送指74、下游阻塞指76和辅助泵送指78。通过泵送指和阀指72、74、76和78之后的凸轮依次按压流体导管的区段来操作“四指”泵送机构和其它线性蠕动泵中使用的机构。压力施加在导管的顺序位置，从泵送机构的上游端开始并且朝向下游端工作。至少一个指始终用力按压，以足够阻塞导管。实际上，阻塞管道的一个指直到下一个指依序已经阻塞导管才缩回；因此在任何时候都没有从流体供应装置到患者的直接流体路径。本领域技术人员熟知包括四指泵在内的蠕动泵的操作，并且在此不提供另外的操作细节。

在该特定实施例中，图7C进一步示出了泵22中包括的下游压力传感器82，所述下游压力传感器82相对于泵送机构位于下游位置。下游压力传感器82安装到流量控制装置70，并且位于流量控制装置附近且在流量控制装置的下游。下游压力传感器位于流量控制装置的下游，即患者48(图7A)与流量控制装置之间的位置，从而可以在将任何流体泵送到患者之前验证正确的液体供应装置与正确的泵的连接。

仍然参照图7C，上游压力传感器80也可以包括在泵22中。上游压力传感器被分配给流量控制装置或泵送机构70，并且在该实施例中，被进一步设置为泵22的一体部分。上游压力传感器安装到流量控制装置70，并且位于流量控制装置附近且在流量控制装置的上游。上游压力传感器位于流量控制装置的上游，即位于流体供应装置38(图7A)与流量控制装置之间的位置，从而在将任何流体泵送到患者之前验证正确的流体供应装置与正确的泵的连接。在源为注射器的实施方案中，流量控制装置70可以配置成按下注射器的柱塞以根据编程参数提供输注。

本文描述的主题的一个或更多个方面或特征可以在数字电子电路、集成电路、专门设计的ASIC、现场可编程门阵列(FPGA)、计算机硬件、固件、软件和/或其组合中实现。这些各个方面或特征可以包括在一个或更多个计算机程序中实施，一个或更多个计算机程序是可在可编程系统上执行和/或解译的，可编程系统包括至少一个可编程处理器，至少一个可编程处理器可以出于专用或通用目的被连接以从存储系统、至少一个输入装置和至少一个输出装置接收数据和指令并将数据和指令发送到存储系统、至少一个输入装置和至少一个输出装置。可编程系统或计算系统可以包括客户端和服务器。客户端和服务器通常彼此远离并且典型地通过通信网络交互。客户端与服务器的关系借助于在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序产生。

这些计算机程序(也可以被称为程序、软件、软件应用程序、应用程序、组件或代码)包括用于可编程处理器的机器指令并且可以以高级程序性和/或对象取向性编程语言以及/或者以汇编/机器语言实施。如本文所使用的，术语“机器可读介质”是指包括接收机器指令作为机器可读信号的机器可读介质并用于向可编程处理器提供机器指令和/或数据的任何计算机程序产品、设备和/或装置(例如，磁盘、光盘、存储器和可编程逻辑装置(PLD))。术语“机器可读信号”是指用于向可编程处理器提供机器指令和/或数据的任何信号。机器可读介质可以非易失性地存储此类机器指令，例如将如非易失性固态存储器或磁性硬盘驱动器或任何等效存储介质一样。可替代地或另外地，机器可读介质可以以暂时性方式存储此类机器指令，例如将如处理器高速缓存或与一个或更多个物理处理器核相关的其它随机存取存储器一样。

为了提供与用户的交互，本文所描述的主题的一个或更多个方面或特征可以在具有显示装置(例如用于向用户显示信息的阴极射线管(CRT)或液晶显示器(LCD)或发光二极管(LED)监视器)以及键盘和定点装置(例如鼠标或轨迹球)的计算机上实施，用户可以通过键盘和定点装置向计算机提供输入。其它种类的装置也可以用于提供与用户交互。例如，提供给用户的反馈可以是任何形式的感觉反馈，例如视觉反馈、听觉反馈或者触觉反馈；并且可以用任何形式(包括声学、语音或者触觉输入)接收来自用户的输入。其它可能的输入装置包括触摸屏或其它触敏装置，如单点或多点电阻或电容追踪板、语音识别硬件和软件、光学扫描仪、光学指针、数字图像拍摄装置和相关的解译软件等。

在上文描述中以及在权利要求中，如“至少一个”或“一个或更多个”的短语可以出现在元素或特征的组合列表之前。术语“和/或”还可以出现在两个或更多个元素或特征的列表中。除非另有隐含或明确地与其使用的上下文相矛盾，否则该短语旨在意指单独列出的任何元素或特征，或与任意的其它记载的元素或特征相结合的任意记载的元素或特征。例如，短语“A和B的至少一个”、“A和B中的一个或更多个”以及“A和/或B”的每个都意指“单独A、单独B或者A和B一起”。类似的解释还适用于包括三个或更多项目的列表。例如，短语“A、B和C的至少一个”、“A、B和C中的一个或更多个”以及“A、B和/或C”的每个都意指“单独A、单独B、单独C、A和B一起、A和C一起、B和C一起、或者A和B和C一起。”在上文和权利要求中使用术语“基于”旨在意指“至少部分地基于”，从而也允许未记载的特征或要素。

如本文所使用的，术语“确定”或“确定了”涵盖各种各样的动作。例如，“确定了”可以包括无需用户干预的经由硬件元件的计算、运算、处理、导出、生成、获得、查找(例如，在表、数据库或另一数据结构中查找)、确认等。此外，“确定了”可以包括无需用户干预的经由硬件元件的接收(例如，接收信息)、访问(例如，访问存储器中的数据)等。“确定了”可以包括无需用户干预的经由硬件元件的解析、选择、挑选、建立等。

如本文所使用的，术语“提供”或“提供了”涵盖各种各样的动作。例如，“提供了”可以包括将值存储在存储装置的位置以供后续检索、经由至少一个有线或无线通信介质将值直接发送到接收者、发送或存储对值的引用等。“提供了”还可以包括经由硬件元件进行编码、解码、加密、解密、证实、验证等。

如本文所使用的，术语“消息”涵盖用于传送(例如，发送或接收)信息的多种格式。消息可以包括机器可读信息集合，如XML文档、固定字段消息、逗号分隔消息等。在一些实施方案中，消息可以包括用于发送信息的一个或更多个表示的信号。虽然以单数形式叙述，但应当理解，消息可以由多个部分构成、发送、存储、接收等。

如本文所使用的，术语“对应”或“对应于”涵盖两个或更多个对象、数据集、信息等之间的结构、功能、定量和/或定性相关性或关系，优选地其中对应性或关系可以用于翻译两个或更多个对象、数据集、信息等中的一个或更多个，以使其看起来相同或相等。可以使用阈值、值范围、模糊逻辑、模式匹配、机器学习评估模型或其组合中的一个或更多个来评估对应性。

在一些实施例中，数据可以被转发到“远程装置或位置”，其中“远程”意指除了执行程序的位置或装置之外的位置或装置。例如，远程位置可以是同一城市中的另一位置(例如，办公室、实验室等)、不同城市中的另一位置、不同州的另一位置、不同国家的另一位置等。如此，当指示一个项“远离”另一个项时，意味着这两个项可以在同一房间但分开，或者至少在不同的房间或不同的建筑物中，并且可以相隔至少一英里、十英里或至少一百英里。“传送”信息是指通过合适的通信信道(例如，专用网络或公共网络)将表示此信息的数据作为电信号发送。“转发”项是指通过物理方式运输此项或以其它方式(在可能的情况下)将此项从一个位置移至下一个位置的任何方式，并且至少在数据的情况下包括物理地运输承载数据的介质或传送数据。通信介质的示例包括无线电或红外传输信道以及到另一台计算机或联网装置的网络连接，以及互联网或包括电子邮件传输和记录在网站等上的信息。

根据期望的配置，本文所描述的主题可以体现在系统、设备、方法和/或制品中。前述描述中所阐述的实施方案并不代表与本文所描述的主题一致的所有实施方案。相反，所述实施方案只是与所描述的主题相关的方面一致的一些示例。尽管上文已经详细描述了许多变型，但其它修改或添加是可能的。具体地，除了本文阐述的特征和/或变型之外，还可以提供另外的特征和/或变型。例如，上文所描述的实施方案可以涉及所公开的特征的各种组合和子组合和/或上文所公开的若干另外特征的组合和子组合。另外，在附图中描绘的和/或本文所描述的逻辑流程不一定需要所示出的特定顺序或先后顺序来实现期望的结果。其它实施方案可以在所附权利要求的范围内。