具体实施方式

患者自控镇痛泵可以允许患者直接控制药物的递送，而不必依靠医疗专业人员通过肌肉注射或静脉内注射施用阿片类止痛药。例如，响应于患者按下与患者自控镇痛泵连接的手持机上的按钮，患者自控镇痛泵可以向患者递送一个或更多个剂量的药物。为了确保及时、有效且安全的患者护理，使用患者自控镇痛泵递送药物可能仍然需要医疗专业人员频繁监督。当患者自控镇痛泵用于递送如阿片类止痛药的受控物质时尤其如此，所述受控物质易于被滥用和转移并且可能产生不利影响，如过度镇静和呼吸率低、运动功能丧失和/或呼吸暂停。如此，在一些示例实施例中，追踪引擎可以配置成追踪向患者递送和/或拒绝向患者递送/拒绝用于向患者递送的药物的剂量以及来自患者的相应的反应(例如，生命体征)。例如，追踪引擎可以追踪患者尝试、向患者递送和/或拒绝向患者递送的药物剂量的数量、患者尝试、向患者递送和/或拒绝向患者递送的药物剂量的速率以及患者的生命体征，患者的生命体征包括例如呼吸率、血氧饱和度、心率、疼痛程度、运动移动(例如，腿部移动)等。

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

泵120可以是患者自控镇痛(PCA)泵，所述患者自控镇痛(PCA)泵配置成向患者140递送药物。然而，应当理解，泵120可以是如下配置的任何输注系统，该输注系统通过例如静脉内输注、皮下输注、动脉输注、硬膜外输注等向患者的循环系统或硬膜外腔递送物质(例如，流体、营养素、药物等)。或者，输注系统可以配置成通过鼻胃管(NG)、经皮内镜胃造口管(PEG)、鼻空肠管(NJ)等向患者的消化系统递送物质(例如，流体、营养素、药物等)。泵120可以配置成接收一个或更多个含有药物的注射器，所述药物例如阿片类止痛药(例如，吗啡、氢吗啡酮、芬太尼等)。此外，泵120可以向患者140递送一个或更多个剂量的药物，该剂量包括例如患者需求剂量、临床医生剂量、装载剂量和/或维持剂量。例如，患者140可以通过至少按下与泵120连接的手持机中的按钮来触发患者需求剂量的递送。另外地和/或可替代地，患者自控镇痛泵可以以设定时间间隔向患者递送一个或更多个剂量的药物。在一些实施方案中，泵120可以用于家庭环境、临床环境、康复护理环境等。

泵120可以包括剂量控制器125，所述剂量控制器125配置成检测泵120处的一个或更多个剂量事件，包括例如患者140尝试触发递送一定剂量的药物、向患者140递送一定剂量的药物、患者140拒绝递送的一定剂量的药物等。剂量控制器125可以向追踪引擎110报告在泵120处检测到的一个或更多个剂量事件。在一些示例实施例中，追踪引擎110可以至少基于由剂量控制器125报告的一个或更多个剂量事件来确定泵120的剂量模式。例如，追踪引擎110可以确定尝试触发递送一定剂量的药物、向患者140递送一定剂量的药物(例如，响应于尝试触发递送一定剂量的药物或以设定的时间间隔递送一定剂量的药物)和/或拒绝向患者140递送一定剂量的药物的数量和/或频率。如本文所使用的，尝试触发递送一定剂量的药物可以指患者140例如通过按下与泵120连接的手持机上的按钮来请求泵120递送一定剂量的药物。同时，拒绝递送一定剂量的药物可以指尽管患者140请求递送一定剂量的药物，但是泵120阻止向患者140递送一定剂量的药物。在泵120的锁定时间段期间，可能拒绝向患者140递送一定剂量的药物。例如，向患者140递送一个或更多个剂量的药物可以触发泵120的后续锁定时间段，以通过药物剂量的频率防止向患者140递送过量药物。

再次参照图1，患者监测器130可以包括一个或更多个传感器，包括例如第一传感器135a、第二传感器135b等。第一传感器135a和/或第二传感器135b可以是有线和/或无线传感器，所述有线和/或无线传感器配置成测量与患者140相关的一个或更多个生命体征，包括例如呼吸率、血氧饱和度、二氧化碳浓度、心率、疼痛程度、运动移动(例如，腿部移动)、每个生命体征的变化率等。例如，第一传感器135a和第二传感器135b的至少一个可以是运动传感器，所述运动传感器配置成检测运动移动的存在和/或不存在(例如，当通过患者140的硬膜外腔施用药物时，检测患者140下肢的运动移动的存在和/或不存在的情况)。如此，第一传感器135a和第二传感器135b的至少一个可以位于患者140的下肢上或附近，如患者140的腿上。同时，患者监测器130可以配置成向追踪引擎110报告与患者140相关的一个或更多个生命体征。

根据一些示例实施例，追踪引擎110可以配置成追踪与患者140相关的一个或更多个生命体征以及在泵120处观察到的相应的剂量模式。追踪引擎110可以将与患者140相关的一个或更多个生命体征与在泵120处观察到的剂量模式关联。例如，当患者140经受某一剂量模式时，追踪引擎110可以确定患者140的呼吸率、血氧饱和度、二氧化碳浓度、心率、运动移动、疼痛程度和/或生命体征的变化率。如上所述，在泵120处观察到的剂量模式可以包括尝试触发递送一定剂量的药物、向患者140递送一定剂量的药物和/或拒绝向患者140递送一定剂量的药物的数量和/或频率。

在一些示例实施例中，追踪引擎110可以配置成基于在泵120处观察到的剂量模式和/或由患者监测器130报告的患者140的生命体征来调整泵120的剂量模式。可以通过至少修改向患者140递送的药物剂量的数量和/或频率来调整泵120的剂量模式。

在一些示例实施例中，追踪引擎110可以通过至少改变泵120处的活动时间段、非活动时间段和/或锁定时间段的持续时间来调整泵120的剂量模式。活动时间段可以出现在向患者140递送药物时。非活动时间段可以出现在没有向患者14递送药物，也没有阻止向患者140递送药物(例如，在锁定时间段期间)时。增加泵120的活动时间段的持续时间和/或减少泵120的非活动时间段和/或锁定时间段的持续时间可能导致向患者140递送的药物的量增加。可替代地和/或另外地，追踪引擎110可以通过至少修改泵120的维持剂量来调整泵120的剂量模式。例如，追踪引擎110可以通过调整与给定时间段(例如，一小时或不同时间段)相关的最大剂量限制来调整泵120的剂量模式，以增加或减少在所述时间段期间向患者递送的药物的数量。追踪引擎110还可以通过中断向患者递送药物来调整泵120的剂量模式。

如本文所使用的，维持剂量可以指持续施用于患者140的最小的药物量。因此，修改泵120的维持剂量可以触发向患者140递送和/或拒绝向患者140递送的药物剂量的数量和/或频率的相应变化。

在一些示例实施例中，追踪引擎110还可以配置成基于在泵120处观察到的剂量模式和/或由患者监测器130报告的患者140的生命体征来生成一个或更多个电子警报。一个或更多个电子警报可以包括无线警报消息，例如推送通知、短消息服务(SMS)消息等。此外，一个或更多个电子警报可以包括在泵120处观察到的剂量模式和/或由患者监测器130报告的患者140的生命体征中出现的异常类型的指示。异常可以包括例如呼气末CO₂(ETCO2)过高、无呼吸、呼吸率低、被拒绝的患者需求剂量数量超过限制、生命体征的变化率超过限制、生命体征值超过限制、心率高、使疼痛程度没有改善或改善有限的患者需求剂量的数量等。可替代地和/或另外地，一个或更多个电子警报可以包括患者标识符、药物标识符和/或向患者递送的药物的数量。例如，一个或更多个电子警报可以指定向患者递送的药物量、剂量的数量、所递送的剂量的速率和/或剂量类型(例如，患者需求剂量、临床医生剂量、装载剂量、维持剂量等)。

例如，追踪引擎110可以检测在泵120处观察到的剂量模式和/或由患者监测器130报告的患者140的生命体征中的一个或更多个异常的存在。一个或更多个异常可以包括向患者140递送的药物量大于或等于最大阈值和/或小于或等于最小阈值。可替代地和/或另外地，一个或更多个异常可以包括患者140的一个或更多个生命体征大于或等于最大阈值和/或小于或等于最小阈值。可替代地和/或另外地，一个或更多个异常可以包括患者140的一个或更多个生命体征的变化率大于或等于最大阈值和/或小于或等于最小阈值。可替代地和/或另外地，一个或更多个异常可以包括使疼痛程度没有改善或改善有限的向患者140递送的药物的数量大于或等于最大阈值和/或小于或等于最小阈值。阈值可以是患者专用的(例如，基于多种因素的预定值，多种因素如患者的病史、患者对某些类型的药物的耐受性、患者先前对药物的暴露等)，和/或可以根据剂量模式、患者生命体征等动态地计算。例如，如果患者的病史包括对某些类型的药物的更大耐受性和/或先前对药物的暴露，则最大和/或最小阈值可以更大。

为了进一步说明，图2A描绘了示出根据一些示例实施例的对向患者递送的药物和患者反应的追踪的时序图200。参照图1和图2A，追踪引擎110可以至少基于在泵120处观察到的剂量模式来确定患者140在下午12:00时经历不良症状(例如，疼痛)。可替代地和/或另外地，追踪引擎110还可以至少基于由患者监测器130报告的患者140的一个或更多个生命体征来确定患者140在下午12:00时经历不良症状(例如，疼痛、呼吸抑制、呼吸暂停、运动移动减少等)。追踪引擎110可以至少基于在泵120处观察到的剂量模式和/或患者140的生命体征中的一个或更多个异常的存在来确定患者140在下午12:00时经历不良症状。如上所述，一个或更多个异常可以包括向患者140递送的药物量大于最大阈值和/或小于最小阈值。在图2A所示的示例中，追踪引擎110可以基于泵120施用于患者的药物剂量的数量来确定患者140可能处于疼痛中。可替代地和/或另外地，一个或更多个异常可以包括患者140的生命体征大于最大阈值和/或小于最小阈值。图2B描述了与根据一些示例实施例的追踪系统100相关的警报阈值的示例。

例如，追踪引擎110可以至少基于患者140尝试触发从泵120递送一个或更多个剂量的药物来确定患者140在下午12:00时经历不良症状。响应于确定患者140经历不良症状，追踪引擎110可以配置成例如通过修改向患者140递送的药物剂量的数量和/或频率来调整在泵120处观察到的剂量模式。可替代地和/或另外地，追踪引擎110可以通过至少生成电子警报(例如，推送通知、短消息服务(SMS)消息等)来对经历不良症状的患者140做出响应。电子警报可以发送到与医疗专业人员关联的客户端150，使得医疗专业人员可以对患者140进行评估和/或例如通过修改向患者140递送的药物剂量的数量和/或频率来调整在泵120处观察到的剂量模式。电子警报在某些情况下可能特别有用，如当患者140的疼痛程度没有改善或改善有限时，甚至在调整剂量模式之后和/或患者继续尝试触发从泵120递送一个或更多个剂量的药物。

在一些示例实施例中，追踪引擎110可以配置成确定在泵120处观察到的剂量模式与患者140的生命体征之间的相关性。为了进一步说明，图3A-图3D描绘了示出剂量模式与患者反应之间的关系的曲线图。例如，图3A-图3B所示的曲线图示出施用于患者140的剂量的频率与患者140的呼吸率之间的关系。向患者140递送的药物剂量的数量和/或频率可能影响患者140的呼吸率。例如，图3A示出七个单位时间内的四个剂量。图3A示出了检测到的每分钟心跳(BPM)趋向于呼吸率阈值(RR低)逐渐减少。在图3B中，与图3A所示的BPM相比，在十一个单位时间内施用三个剂量维持了更高的BPM。

同时，图3C-图3D所示的曲线图示出了拒绝用于患者140的剂量频率与患者140的疼痛程度之间的关系。拒绝用于患者140的药物剂量的数量和/或频率可能对患者140经历的疼痛程度和/或安全性(例如，过度镇静、低呼吸率和/或呼吸暂停)产生影响。例如，如图3C-图3D所示，当泵120拒绝向患者140递送药物时，患者140可能经历疼痛程度增加。相比之下，患者140在泵120递送药物之后可能会经历疼痛程度降低。

图3C-图3D进一步示出了当患者140经受不同的剂量模式时患者140所经历的疼痛程度。参照图3C-图3D，与利用图3D所示的剂量模式相比，利用图3C所示的剂量模式患者140可能被更频繁拒绝递送药物。例如，在同一时间段内，利用图3D所示的剂量模式，可以向患者140提供三个剂量的药物，而利用图3C所示的剂量模式仅提供两个剂量的药物。因此，利用图3C所示的剂量模式，患者140可能被给予了不足量的药物，因为患者140的疼痛程度飙升到了接近指示药物不足的疼痛程度(例如，9)的程度(例如，8)。相比之下，利用图3D所示的剂量模式，患者140的疼痛程度保持相对较低(例如，介于1与3之间)，并且没有接近与药物不足相关的疼痛程度(例如，9)。

如上所述，在泵120的锁定时间段期间，患者140可能被拒绝递送一定剂量的药物。为了防止向患者140递送过量的药物(通过递送剂量的频率)，泵120可能在向患者140递送一个或更多个剂量的药物之后经历锁定时间段。为了进一步说明，图3E描绘了示出根据一些示例实施例的剂量模式300的示例的曲线图。如图3E所示，泵120可以与活动状态关联，在活动状态期间，泵120通过向患者140递送一定剂量的药物来对来响应来自患者140的触发一定剂量的药物递送的至少一些尝试。相比之下，当泵120处于非活动状态时，泵120可以拒绝来自患者140的触发一定剂量的药物递送的所有尝试。此外，图3E示出泵120可以在每个成功的患者需求剂量之后经历锁定时间段。例如，在响应于来自患者140的请求而向患者140递送一定剂量的药物之后，泵120可以经历锁定时间段，在锁定时间段期间，患者140触发另一剂量的药物递送的任何尝试都会被拒绝。

图4描绘了示出根据一些示例实施例的用于追踪剂量模式和患者反应的方法400的流程图。参照图4，方法400可以由追踪系统100执行。

在402处，追踪系统100可以至少基于泵120处的一个或更多个剂量事件来确定用于向患者递送药物的泵120的剂量模式。在一些示例实施例中，泵120的剂量控制器125可以检测并向追踪引擎110报告泵120处的一个或更多个剂量事件，包括例如患者140尝试触发递送一定剂量的药物、向患者140递送一定剂量的药物、拒绝向患者140递送一定剂量的药物等。追踪引擎110可以至少基于泵120处的一个或更多个剂量事件来确定泵120的剂量模式，所述剂量模式可以包括例如尝试触发递送一定剂量的药物、向患者140递送一定剂量的药物和/或拒绝向患者140递送一定剂量的药物的数量和/或频率。

在404处，追踪系统100可以从患者监测器130接收与患者相关的一个或更多个生命体征。在一些示例实施例中，第一传感器135a和/或第二传感器135b可以配置成测量并向追踪引擎110报告与患者140相关的一个或更多个生命体征，包括例如呼吸率、血氧饱和度、心率、疼痛程度、运动移动等。

在406处，追踪引擎110可以至少基于泵120的剂量模式以及与患者相关的一个或更多个生命体征来调整泵120的剂量模式。在一些示例实施例中，追踪引擎110可以配置成基于在泵120处观察到的剂量模式和/或由患者监测器130报告的患者140的生命体征来调整泵120的剂量模式。例如，追踪引擎110可以通过至少修改向患者140递送的药物剂量的数量和/或频率来调整泵120的剂量模式。向患者140递送和/或拒绝向患者140递送的药物剂量的数量和/或频率可以通过至少改变在泵120处实施的活动时间段、非活动时间段和/或锁定时间段的持续时间来修改。

在408处，追踪系统100可以响应于检测到泵120的剂量模式和/或与患者相关的一个或更多个生命体征中的一个或更多个异常来生成电子警报并向客户端150发送电子警报。在一些示例实施例中，追踪引擎110可以配置成追踪与患者140相关的一个或更多个生命体征以及在泵120处观察到的相应的剂量模式。例如，追踪引擎110可以将与患者140相关的一个或更多个生命体征与在泵120处观察到的剂量模式关联。此外，当追踪引擎110检测到泵120的剂量模式和/或与患者140相关的一个或更多个生命体征中的一个或更多个异常时，追踪引擎110可以生成电子警报(例如，推送通知、短消息服务(SMS)消息等)并向与医疗专业人员关联的客户端150发送电子警报。一个或更多个异常可以包括向患者140递送的药物量(例如，药物剂量)大于最大阈值和/或小于最小阈值。可替代地和/或另外地，一个或更多个异常可以包括患者140的一个或更多个生命体征大于最大阈值和/或小于最小阈值。电子警报可以发送到客户端150，使得与客户端150关联的医疗专业人员可以对患者140进行评估和/或例如通过修改向患者140递送的药物剂量的数量和/或频率来调整在泵120处观察到的剂量模式。

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

如图5所示，计算系统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(例如，在计算机屏幕监视器等上)生成并呈现给用户。

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

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

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

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

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

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

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

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

图6B包括连接到编程模块60的第二泵26。如图6A所示，可以连接更多泵模块。此外，其它类型的模块可以连接到泵模块或编程模块。在该实施方案中，追踪引擎110可以追踪在每个泵(例如，泵120、泵26等)处尝试触发递送一定剂量的药物、将一定剂量的药物向患者递送和/或拒绝向患者递送一定剂量的药物的数量和/或频率。另外地和/或可替代地，追踪引擎110可以追踪每个泵(例如，泵120、泵26等)处的患者的生命体征。另外地和/或可替代地，追踪引擎110可以确定在患者自控镇痛泵处观察到的剂量模式与在每个泵(例如，泵120、泵26等)处的患者反应之间的相关性。在一些实施方案中，当在每个泵(例如，泵120、泵26等)处观察到的剂量模式中检测到一个或更多个异常时，追踪引擎110可以生成电子警报。追踪引擎110可以提供另外的或替代性控制消息，以至少部分地基于检测到的剂量模式来调整泵的一个或更多个元件的功能。例如，追踪引擎110可以禁用连接到患者自控镇痛模块的分配按钮。作为另一示例，追踪引擎110可以发送控制消息以调节通过电机泵送的速率(例如，增加速率、降低速率或停止泵送)。作为另一示例，追踪引擎110可以调整泵的配置，如允许的给药模式(例如，PCA锁定持续时间或频率)。

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

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

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

仍然参照图6C，上游压力传感器80也可以包括在泵120中。上游压力传感器被分配给流量控制装置或泵送机构70，并且在该实施例中，被进一步设置为泵120的一体部分。上游压力传感器安装到流量控制装置70，并且位于流量控制装置附近且在流量控制装置的上游。上游压力传感器位于流量控制装置的上游，即位于流体供应装置38(图6A)与流量控制装置之间的位置，从而在将任何流体泵送到患者之前验证正确的流体供应装置与正确的泵的连接。在源为注射器的实施方案中，流量控制装置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文档、固定字段消息、逗号分隔消息等。在一些实施方案中，消息可以包括用于发送信息的一个或更多个表示的信号。虽然以单数形式叙述，但应当理解，消息可以由多个部分构成、发送、存储、接收等。

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

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

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