阅读说明：本技术 用于监测剂量模式和患者反应的系统 (System for monitoring dose pattern and patient response ) 是由 J·J·格拉 P·钦奈 R·S·吴 于 2020-01-10 设计创作，主要内容包括：一种用于追踪剂量模式和患者反应的方法可以包括：至少基于被配置成向患者递送药物的泵处的一个或更多个剂量事件来确定用于向患者递送药物的剂量模式。可以从患者监测器接收与患者相关的一个或更多个生命体征。可以至少基于泵的剂量模式和患者的一个或更多个生命体征来确定一个或更多个异常的存在。可以响应于确定出一个或更多个异常的存在而向移动装置发送电子警报。还公开了相关方法和制品,制品包括设备和计算机程序产品。(A method for tracking dose patterns and patient response may include: a dosage pattern for delivering a drug to a patient is determined based at least on one or more dosage events at a pump configured to deliver the drug to the patient. One or more vital signs related to a patient may be received from a patient monitor. The presence of one or more abnormalities may be determined based at least on a dosage pattern of the pump and one or more vital signs of the patient. An electronic alert may be sent to the mobile device in response to determining the presence of one or more anomalies. Related methods and articles of manufacture, including apparatus and computer program products, are also disclosed.)

1. A system, comprising:

at least one data processor; and

at least one memory storing instructions that when executed by the at least one data processor result in operations comprising:

determining a dose pattern for delivering the drug to the patient based at least on one or more dose events at a pump configured to deliver the drug to the patient;

receiving one or more vital signs related to a patient from a patient monitor;

determining the presence of one or more abnormalities based at least on a dosage pattern of the pump and one or more vital signs of the patient; and

an electronic alert is sent to the mobile device in response to determining the presence of the one or more anomalies.

2. The system of claim 1, wherein the one or more dose events comprise: the patient attempts to trigger, and/or reject delivery of a dose of the drug.

3. The system according to either of claims 1 or 2, wherein the one or more vital signs include: respiration rate, blood oxygen saturation, heart rate, pain level, and/or movement.

4. The system of any of claims 1 to 3, further comprising:

the dosage mode of the pump is adjusted based at least on the dosage mode of the pump and/or one or more vital signs of the patient.

5. The system of claim 4, wherein the dosage pattern is adjusted by at least modifying the amount and/or frequency of delivery and/or rejection of one or more doses of the drug to the patient.

6. The system according to any of claims 4 or 5, wherein the dosage pattern is adjusted by modifying at least the duration of the active time period, the inactive time period and/or the lock-out time period of the pump.

7. The system of any of claims 4 to 6, wherein the dosage pattern is adjusted by modifying at least a maintenance dose of the pump.

8. The system of any of claims 1 to 7, wherein the one or more abnormalities includes an amount of drug delivered to the patient being greater than a maximum threshold or less than a minimum threshold.

9. The system of any of claims 1 to 8, wherein the one or more abnormalities includes one or more vital signs of the patient being greater than a maximum threshold or less than a minimum threshold.

10. The system of any of claims 1 to 9, wherein the patient monitor comprises one or more sensors configured to measure one or more vital signs of a patient, wherein the one or more sensors comprise at least one motion sensor, and wherein the presence of one or more abnormalities is determined based on motion data measured by the at least one motion sensor.

11. A computer-implemented method, comprising:

determining a dose pattern for delivering the drug to the patient based at least on one or more dose events at a pump configured to deliver the drug to the patient;

receiving one or more vital signs related to a patient from a patient monitor;

determining the presence of one or more abnormalities based at least on a dosage pattern of the pump and one or more vital signs of the patient; and

an electronic alert is sent to the mobile device in response to determining the presence of the one or more anomalies.

12. The method of claim 11, wherein the one or more dose events comprise: the patient attempts to trigger, and/or reject delivery of a dose of the drug.

13. The method of any of claims 11 to 12, wherein the one or more vital signs include: respiration rate, blood oxygen saturation, heart rate, pain level, and/or movement.

14. The method of any of claims 11 to 13, further comprising:

the dosage mode of the pump is adjusted based at least on the dosage mode of the pump and/or one or more vital signs of the patient.

15. The method of claim 14, wherein the dosage pattern is adjusted by at least modifying the amount and/or frequency of delivery of one or more doses of the drug to the patient.

16. The method according to any of claims 14 or 15, wherein the dosage pattern is adjusted by modifying at least the duration of the active period, the inactive period and/or the lock-out period of the pump.

17. The method of any of claims 14 to 16, wherein the dosage pattern is adjusted by modifying at least a maintenance dose of the pump.

18. The method of any of claims 11 to 17, wherein the one or more abnormalities include an amount of drug delivered to the patient that is greater than a maximum threshold or less than a minimum threshold.

19. The method of any of claims 11 to 18, wherein the one or more abnormalities includes one or more vital signs of the patient being greater than a maximum threshold or less than a minimum threshold.

20. A non-transitory computer-readable storage medium including program code which, when executed by at least one data processor, causes operations comprising:

determining a dose pattern for delivering the drug to the patient based at least on one or more dose events at a pump configured to deliver the drug to the patient;

receiving one or more vital signs related to a patient from a patient monitor;

determining the presence of one or more abnormalities based at least on a dosage pattern of the pump and one or more vital signs of the patient; and

an electronic alert is sent to the mobile device in response to determining the presence of the one or more anomalies.

21. An apparatus, comprising:

means for determining a dose pattern for delivering the drug to the patient based on one or more dose events at a pump configured to deliver the drug to the patient;

means for receiving one or more vital signs related to a patient from a patient monitor;

means for determining the presence of one or more abnormalities based at least on a dosage pattern of the pump and one or more vital signs of the patient; and

means for sending an electronic alert to the mobile device in response to determining the presence of the one or more anomalies.

22. The apparatus of claim 21, comprising:

means for performing any of the functions of any of claims 12-19.

Technical Field

The subject matter described herein relates generally to dispensing of medications, and more particularly to a tracking system for medication delivery.

Background

Patient-controlled analgesia pumps may provide patients with direct control over the delivery of certain drugs, including, for example, opioid analgesics, which would otherwise be administered by a medical professional in a single dose by intramuscular or intravenous injection. A patient-controlled analgesia pump is a computerized pump that contains a reservoir of multidose medication and is connected directly to the patient's vein. The patient-controlled analgesia pump may be configured to deliver a constant flow of drug to the patient. Alternatively and/or additionally, a patient-controlled analgesia pump may allow a patient to self-administer individual doses of medication on an as-needed basis.

Disclosure of Invention

Systems, methods, and articles of manufacture, including computer program products, are provided for tracking dose patterns and patient responses of patient-controlled analgesic pumps. For example, a patient-controlled analgesia pump may be communicatively connected with a tracking engine configured to track the number and/or frequency of attempts to trigger delivery of a dose of medication, to deliver a dose of medication to a patient, and/or to deny delivery of a dose of medication to a patient. The tracking engine may be further configured to track vital signs of the patient including, for example, respiration rate, blood oxygen saturation, heart rate, pain level, movement, and the like. The tracking engine may determine a correlation between a dose pattern observed at the patient-controlled analgesia pump and patient response. Further, the tracking engine may generate an electronic alert when one or more abnormalities are detected in the dose pattern and/or patient vital signs observed at the patient-controlled analgesia pump.

According to some aspects, a method may include determining a dose pattern for delivering a drug to a patient based at least on one or more dose events at a pump configured to deliver the drug to the patient. The method may further include receiving one or more vital signs related to the patient from the patient monitor. The method may further include determining the presence of one or more abnormalities based at least on the dosage pattern of the pump and one or more vital signs of the patient. The method may further include sending an electronic alert to the mobile device in response to determining the presence of the one or more anomalies.

In some aspects, the one or more dosage events may include the patient attempting to trigger delivery of a dose of the drug, and/or refusal of delivery of a dose of the drug.

In some aspects, the one or more vital signs include respiration rate, blood oxygen saturation, heart rate, pain level, and/or motor movement.

In some aspects, the method further comprises adjusting the dosage mode of the pump based at least on the dosage mode of the pump and/or one or more vital signs of the patient. In some aspects, the dosage pattern is adjusted by at least modifying the amount and/or frequency of delivery and/or rejection of one or more doses of the drug to the patient. In some aspects, the dosage pattern is adjusted by modifying at least a duration of the active time period, the inactive time period, and/or the lockout time period of the pump. In some aspects, the dosage pattern is adjusted by modifying at least the maintenance dosage of the pump.

In some aspects, the one or more abnormalities include an amount of drug delivered to the patient that is greater than a maximum threshold or less than a minimum threshold. In some aspects, the one or more abnormalities include one or more vital signs of the patient being greater than a maximum threshold or less than a minimum threshold.

In some aspects, a patient monitor includes one or more sensors configured to measure one or more vital signs of a patient. The one or more sensors may include at least one motion sensor. The presence of one or more anomalies may be determined based on motion data measured by at least one motion sensor.

Embodiments of the present subject matter can include methods consistent with the description provided herein, as well as articles of manufacture including a tangibly embodied machine-readable medium operable to cause one or more machines (e.g., computers, etc.) to produce operations to implement one or more of the described features. Similarly, computer systems are also described, which may include one or more processors and one or more memories connected to the one or more processors. The memory (which may include a non-transitory computer-readable or machine-readable storage medium) may include code, storage, etc. for one or more programs that cause one or more processors to perform one or more of the operations described herein. Computer-implemented methods consistent with one or more embodiments of the present subject matter may be implemented by one or more data processors residing in a single computing system or multiple computing systems. Such multiple computing systems may be connected via one or more connections, including, for example, a connection over a network (e.g., the internet, a wireless wide area network, a local area network, a wide area network, a wired network, etc.), via a direct connection between one or more of the multiple computing systems, or the like, exchange data and/or commands or other instructions, or the like.

The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will be apparent from the description and drawings, and from the claims. While certain features of the presently disclosed subject matter are described for illustrative purposes in connection with the tracking of dose patterns and patient responses, it should be readily understood that such features are not intended to be limiting. The claims following this disclosure are intended to define the scope of the claimed subject matter.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate certain aspects of the subject matter disclosed herein and together with the description, help explain some of the principles associated with the disclosed embodiments. In the drawings, there is shown in the drawings,

FIG. 1 depicts a system diagram showing a tracking system according to some example embodiments;

fig. 2A depicts a timing diagram showing tracking of drug delivered to a patient and patient response, according to some example embodiments;

FIG. 2B depicts an example of alarm thresholds associated with a tracking system according to some example embodiments;

FIG. 3A depicts a graph showing the relationship between the frequency of a dose administered to a patient and the patient's breathing rate (BPM), according to some example embodiments;

FIG. 3B depicts a graph showing the relationship between the frequency of a dose administered to a patient and the patient's breathing rate (BPM), according to some example embodiments;

FIG. 3C depicts a graph showing the relationship between frequency of dose rejection for a patient and patient pain level, according to some example embodiments;

FIG. 3D depicts a graph showing the relationship between frequency of dose rejection for a patient and patient pain level, according to some example embodiments;

fig. 3E depicts a graph showing an example of a dose pattern according to some example embodiments;

fig. 4 depicts a flow diagram showing a method for tracking medication delivered to a patient and patient response, according to some example embodiments;

FIG. 5 depicts a block diagram showing a computing system according to some example embodiments;

fig. 6A depicts a front view of a patient care system, according to some example embodiments;

fig. 6B depicts an enlarged view of a portion of a patient care system, according to some example embodiments; and is

Fig. 6C depicts a perspective view of a pump according to some example embodiments.

Like reference numerals refer to like structures, features or elements, if applicable.

Detailed Description

Patient-controlled analgesia pumps may allow a patient to directly control the delivery of drugs without having to rely on a medical professional to administer opioid analgesics by intramuscular or intravenous injection. For example, in response to the patient pressing a button on a handset connected to the patient-controlled analgesia pump, the patient-controlled analgesia pump may deliver one or more doses of medication to the patient. To ensure timely, effective, and safe patient care, the use of patient-controlled analgesia pumps to deliver drugs may still require frequent supervision by medical professionals. This is particularly true when patient-controlled analgesia pumps are used to deliver controlled substances, such as opioid analgesics, which are susceptible to abuse and transfer and which may have adverse effects, such as over-sedation and low respiration rates, loss of motor function, and/or apnea. As such, in some example embodiments, the tracking engine may be configured to track the dose delivered to the patient and/or the rejection of the delivery/rejection of the drug to the patient for delivery to the patient and the corresponding response (e.g., vital signs) from the patient. For example, the tracking engine may track the number of drug doses that the patient attempts, delivers and/or rejects to deliver to the patient, the patient attempts, the rate at which the drug doses are delivered and/or rejected to the patient, and patient vital signs including, for example, respiration rate, blood oxygen saturation, heart rate, pain level, movement (e.g., leg movement), etc.

Fig. 1 depicts a system diagram showing a tracking system 100 according to some example embodiments. Referring to fig. 1, a tracking system 100 may include a tracking engine 110, a pump 120, a patient monitor 130, and a client 150. As shown in fig. 1, the tracking engine 110, pump 120, patient monitor 130, and/or client 150 may be communicatively connected via a network 160. The client 150 may be a mobile device, such as a smartphone, tablet, wearable device, and the like. However, it should be understood that the client 150 may be any processor-based device including, for example, a desktop computer, a laptop computer, a workstation, and the like. Meanwhile, the network 160 may be any wired and/or wireless network including, for example, a Public Land Mobile Network (PLMN), a Local Area Network (LAN), a Virtual Local Area Network (VLAN), a Wide Area Network (WAN), the internet, and the like. Additionally and/or alternatively, in some embodiments, the tracking engine 110 and/or the client 150 may form part of the pump 120.

The pump 120 may be a Patient Controlled Analgesia (PCA) pump configured to deliver medication to the patient 140. However, it should be understood that the pump 120 may be any infusion system configured to deliver a substance (e.g., a fluid, nutrient, drug, etc.) to the circulatory system or epidural space of a patient via, for example, intravenous infusion, subcutaneous infusion, arterial infusion, epidural infusion, etc. Alternatively, the infusion system may be configured to deliver substances (e.g., fluids, nutrients, drugs, etc.) to the digestive system of the patient through a nasogastric tube (NG), a percutaneous endoscopic gastrostomy tube (PEG), a nasojejunal tube (NJ), or the like. The pump 120 may be configured to receive one or more syringes containing a drug, such as an opioid analgesic (e.g., morphine, hydromorphone, fentanyl, etc.). In addition, the pump 120 can deliver one or more doses of medication to the patient 140, including, for example, a patient demand dose, a clinician dose, a loading dose, and/or a maintenance dose. For example, the patient 140 may trigger delivery of the patient requested dose by at least pressing a button in a handset connected to the pump 120. Additionally and/or alternatively, the patient-controlled analgesia pump may deliver one or more doses of medication to the patient at set time intervals. In some embodiments, the pump 120 may be used in a home environment, a clinical environment, a rehabilitation care environment, and the like.

The pump 120 can include a dose controller 125, the dose controller 125 configured to detect one or more dose events at the pump 120, including, for example, the patient 140 attempting to trigger delivery of a dose of medication, the patient 140 delivering a dose of medication, the patient 140 rejecting a delivered dose of medication, and the like. The dose controller 125 may report one or more dose events detected at the pump 120 to the tracking engine 110. In some example embodiments, the tracking engine 110 may determine a dosage pattern for the pump 120 based at least on one or more dosage events reported by the dosage controller 125. For example, the tracking engine 110 may determine an amount and/or frequency of attempting to trigger delivery of a dose of medication, delivering a dose of medication to the patient 140 (e.g., in response to attempting to trigger delivery of a dose of medication or delivering a dose of medication at a set time interval), and/or rejecting delivery of a dose of medication to the patient 140. As used herein, attempting to trigger delivery of a dose of medication may refer to the patient 140 requesting the pump 120 to deliver a dose of medication, for example, by pressing a button on a handset connected to the pump 120. Meanwhile, refusing to deliver a dose of medication may refer to the pump 120 preventing delivery of a dose of medication to the patient 140 despite the patient 140 requesting delivery of a dose of medication. During the lock-out period of the pump 120, the delivery of a dose of medication to the patient 140 may be denied. For example, delivering one or more doses of medication to the patient 140 may trigger a subsequent lock-out period of the pump 120 to prevent delivery of excess medication to the patient 140 by the frequency of medication doses.

Referring again to fig. 1, patient monitor 130 may include one or more sensors, including, for example, a first sensor 135a, a second sensor 135b, and so forth. First sensor 135a and/or second sensor 135b may be wired and/or wireless sensors configured to measure one or more vital signs associated with patient 140, including, for example, respiration rate, blood oxygen saturation, carbon dioxide concentration, heart rate, pain level, movement (e.g., leg movement), rate of change of each vital sign, and the like. For example, at least one of the first sensor 135a and the second sensor 135b may be a motion sensor configured to detect the presence and/or absence of motion movement (e.g., detect the presence and/or absence of motion movement of the lower limb of the patient 140 when a drug is administered through the epidural space of the patient 140). As such, at least one of the first sensor 135a and the second sensor 135b may be located on or near a lower limb of the patient 140, such as a leg of the patient 140. Meanwhile, patient monitor 130 may be configured to report one or more vital signs related to patient 140 to tracking engine 110.

According to some example embodiments, the tracking engine 110 may be configured to track one or more vital signs associated with the patient 140 and the corresponding dosage pattern observed at the pump 120. The tracking engine 110 may correlate one or more vital signs related to the patient 140 with the dose pattern observed at the pump 120. For example, when the patient 140 is subjected to a certain dose pattern, the tracking engine 110 may determine the respiration rate, blood oxygen saturation, carbon dioxide concentration, heart rate, movement of motion, pain level, and/or rate of change of vital signs of the patient 140. As described above, the dosage pattern observed at the pump 120 may include the number and/or frequency of attempts to trigger delivery of a dose of medication, delivery of a dose of medication to the patient 140, and/or rejection of delivery of a dose of medication to the patient 140.

In some example embodiments, the tracking engine 110 may be configured to adjust the dosage mode of the pump 120 based on the dosage mode observed at the pump 120 and/or the vital signs of the patient 140 reported by the patient monitor 130. The dosage pattern of the pump 120 may be adjusted by modifying at least the number and/or frequency of doses of medication delivered to the patient 140.

In some example embodiments, the tracking engine 110 may adjust the dosage pattern of the pump 120 by changing at least the duration of the active time period, the inactive time period, and/or the lock-out time period at the pump 120. The active time period may occur when a medication is delivered to the patient 140. The inactive time period may occur when no medication is being delivered to the patient 14, nor is delivery of medication to the patient 140 prevented (e.g., during the lockout time period). Increasing the duration of the active time period of pump 120 and/or decreasing the duration of the inactive time period and/or the lock-out time period of pump 120 may result in an increase in the amount of drug delivered to patient 140. Alternatively and/or additionally, the tracking engine 110 may adjust the dosage pattern of the pump 120 by at least modifying the maintenance dosage of the pump 120. For example, the tracking engine 110 may adjust the dosage pattern of the pump 120 by adjusting a maximum dosage limit associated with a given time period (e.g., an hour or a different time period) to increase or decrease the amount of medication delivered to the patient during the time period. The tracking engine 110 may also adjust the dosage pattern of the pump 120 by interrupting the delivery of medication to the patient.

As used herein, a maintenance dose may refer to the minimum amount of drug that is continuously administered to the patient 140. Thus, modifying the maintenance dose of the pump 120 may trigger a corresponding change in the number and/or frequency of drug doses delivered to the patient 140 and/or rejected to the patient 140.

In some example embodiments, the tracking engine 110 may also be configured to generate one or more electronic alerts based on the dose pattern observed at the pump 120 and/or vital signs of the patient 140 reported by the patient monitor 130. The one or more electronic alerts may include wireless alert messages, such as push notifications, Short Message Service (SMS) messages, and the like. Further, the one or more electronic alarms may include an indication of a dosage pattern observed at pump 120 and/or a type of abnormality occurring in a vital sign of patient 140 reported by patient monitor 130. The abnormality may include, for example, end-tidal CO₂(ETCO2) being too high, non-respirable, low respiratory rate, being rejected, the number of patient doses required exceeding a limit, the rate of change of vital signs exceeding a limit, the value of vital signs exceeding a limit, high heart rate, having no or limited pain level, etc. Alternatively and/or additionally, the one or more electronic alerts may include a patient identifier, a medication identifier, and/or a quantity of medication delivered to the patient. For example, the one or more electronic alerts may specify the amount of medication delivered to the patient, the number of doses, the rate of doses delivered, and/or the type of dose (e.g., patient requested dose, clinician dose, loading dose, maintenance dose, etc.).

For example, the tracking engine 110 may detect the presence of one or more abnormalities in the dose pattern observed at the pump 120 and/or the vital signs of the patient 140 reported by the patient monitor 130. The one or more abnormalities may include an amount of drug delivered to the patient 140 that is greater than or equal to a maximum threshold value and/or less than or equal to a minimum threshold value. Alternatively and/or additionally, the one or more abnormalities may include one or more vital signs of the patient 140 being greater than or equal to a maximum threshold and/or less than or equal to a minimum threshold. Alternatively and/or additionally, the one or more abnormalities may include a rate of change of one or more vital signs of the patient 140 being greater than or equal to a maximum threshold and/or less than or equal to a minimum threshold. Alternatively and/or additionally, the one or more abnormalities may include an amount of drug delivered to the patient 140 that does not improve or improves the pain by a limited amount greater than or equal to a maximum threshold and/or less than or equal to a minimum threshold. The threshold may be patient specific (e.g., a predetermined value based on a variety of factors such as the patient's medical history, the patient's tolerance to certain types of drugs, the patient's prior exposure to drugs, etc.), and/or may be dynamically calculated based on dose patterns, patient vital signs, etc. For example, if the patient's medical history includes greater tolerance to certain types of drugs and/or prior exposure to drugs, the maximum and/or minimum thresholds may be greater.

For further explanation, fig. 2A depicts a timing diagram 200 illustrating tracking of drug delivery to a patient and patient response, according to some example embodiments. Referring to fig. 1 and 2A, the tracking engine 110 may determine that the patient 140 experienced an adverse symptom (e.g., pain) at 12:00 pm based at least on the dose pattern observed at the pump 120. Alternatively and/or additionally, tracking engine 110 may also determine that patient 140 experienced an adverse symptom (e.g., pain, respiratory depression, apnea, reduced movement of motion, etc.) at 12:00 pm based at least on one or more vital signs of patient 140 reported by patient monitor 130. The tracking engine 110 may determine that the patient 140 experienced adverse symptoms at 12:00 pm based at least on the dose pattern observed at the pump 120 and/or the presence of one or more abnormalities in the vital signs of the patient 140. As described above, the one or more abnormalities may include an amount of drug delivered to the patient 140 that is greater than a maximum threshold and/or less than a minimum threshold. In the example shown in fig. 2A, the tracking engine 110 may determine that the patient 140 is likely to be in pain based on the number of medication doses administered to the patient by the pump 120. Alternatively and/or additionally, the one or more abnormalities may include a vital sign of the patient 140 being greater than a maximum threshold and/or less than a minimum threshold. Fig. 2B depicts an example of alarm thresholds associated with the tracking system 100 according to some example embodiments.

For example, the tracking engine 110 may determine that the patient 140 experienced adverse symptoms at 12:00 PM based at least on the patient 140 attempting to trigger delivery of one or more doses of medication from the pump 120. In response to determining that the patient 140 is experiencing adverse symptoms, the tracking engine 110 may be configured to adjust the dosage pattern observed at the pump 120, for example, by modifying the number and/or frequency of drug doses delivered to the patient 140. Alternatively and/or additionally, the tracking engine 110 may respond to the patient 140 experiencing the adverse symptoms by at least generating an electronic alert (e.g., a push notification, a Short Message Service (SMS) message, etc.). An electronic alert may be sent to a client 150 associated with the medical professional so that the medical professional may evaluate the patient 140 and/or adjust the dosage pattern observed at the pump 120, for example, by modifying the number and/or frequency of medication doses delivered to the patient 140. The electronic alert may be particularly useful in certain situations, such as when the patient 140 has no improvement or a limited improvement in the level of pain, even after adjusting the dosage pattern and/or the patient continues to attempt to trigger delivery of one or more doses of medication from the pump 120.

In some example embodiments, the tracking engine 110 may be configured to determine a correlation between a dose pattern observed at the pump 120 and a vital sign of the patient 140. For further explanation, fig. 3A-3D depict graphs showing the relationship between dose patterns and patient response. For example, the graphs shown in fig. 3A-3B illustrate the relationship between the frequency of a dose administered to a patient 140 and the respiration rate of the patient 140. The number and/or frequency of drug doses delivered to the patient 140 may affect the respiration rate of the patient 140. For example, fig. 3A shows four doses over seven unit times. Fig. 3A shows that the detected Beats Per Minute (BPM) gradually decrease toward the respiration rate threshold (RR low). In fig. 3B, three doses administered over eleven unit times maintained a higher BPM than the BPM shown in fig. 3A.

3C-3D illustrate graphs showing the frequency of dose rejected for the patient 140 versus the level of pain experienced by the patient 140. The number and/or frequency of drug doses rejected for the patient 140 may have an impact on the level of pain and/or safety (e.g., over-sedation, low respiratory rate, and/or apnea) experienced by the patient 140. For example, as shown in fig. 3C-3D, when the pump 120 refuses to deliver medication to the patient 140, the patient 140 may experience an increased level of pain. In contrast, the patient 140 may experience a reduced level of pain after the pump 120 delivers the drug.

Fig. 3C-3D further illustrate the degree of pain experienced by the patient 140 when the patient 140 is subjected to different dosage patterns. Referring to fig. 3C-3D, the patient 140 may be denied delivery of the drug more frequently using the dose pattern shown in fig. 3C than using the dose pattern shown in fig. 3D. For example, three doses of drug may be provided to the patient 140 over the same time period using the dose pattern shown in fig. 3D, while only two doses of drug are provided using the dose pattern shown in fig. 3C. Thus, with the dosage pattern shown in fig. 3C, patient 140 may be administered an insufficient amount of medication because the pain level of patient 140 soars to a level (e.g., 8) near the pain level (e.g., 9) indicating insufficient medication. In contrast, with the dose pattern shown in fig. 3D, the pain level of patient 140 remains relatively low (e.g., between 1 and 3) and does not approach the pain level associated with drug deficiency (e.g., 9).

As described above, during the lock-out period of the pump 120, the patient 140 may be denied delivery of a dose of medication. To prevent delivery of an excessive amount of drug to the patient 140 (by the frequency of delivered doses), the pump 120 may experience a lock-out period after one or more doses of the drug are delivered to the patient 140. For further explanation, fig. 3E depicts a graph illustrating an example of a dose pattern 300 according to some example embodiments. As shown in fig. 3E, the pump 120 may be associated with an active state during which the pump 120 responds to at least some attempts from the patient 140 to trigger delivery of a dose of medication by delivering a dose of medication to the patient 140. In contrast, when the pump 120 is in an inactive state, the pump 120 may reject all attempts from the patient 140 to trigger the delivery of a dose of medication. Further, fig. 3E shows that the pump 120 may experience a lock-out period after each successful patient demand dose. For example, after a dose of medication is delivered to the patient 140 in response to a request from the patient 140, the pump 120 may experience a lockout period during which any attempt by the patient 140 to trigger delivery of another dose of medication is denied.

Fig. 4 depicts a flowchart showing a method 400 for tracking dose patterns and patient responses, according to some example embodiments. Referring to fig. 4, a method 400 may be performed by the tracking system 100.

At 402, the tracking system 100 may determine a dosage pattern of the pump 120 for delivering a drug to a patient based at least on one or more dosage events at the pump 120. In some example embodiments, the dose controller 125 of the pump 120 may detect and report to the tracking engine 110 one or more dose events at the pump 120, including, for example, the patient 140 attempting to trigger delivery of a dose of medication, the patient 140 delivering a dose of medication, the patient 140 refusing to deliver a dose of medication, and the like. The tracking engine 110 may determine a dosage pattern for the pump 120 based at least on one or more dosage events at the pump 120, which may include, for example, a number and/or frequency of attempts to trigger delivery of a dose of medication, delivery of a dose of medication to the patient 140, and/or rejection of delivery of a dose of medication to the patient 140.

At 404, the tracking system 100 may receive one or more vital signs related to the patient from the patient monitor 130. In some example embodiments, the first sensor 135a and/or the second sensor 135b may be configured to measure and report to the tracking engine 110 one or more vital signs related to the patient 140, including, for example, respiration rate, blood oxygen saturation, heart rate, pain level, movement movements, and the like.

At 406, the tracking engine 110 may adjust the dosage mode of the pump 120 based at least on the dosage mode of the pump 120 and one or more vital signs associated with the patient. In some example embodiments, the tracking engine 110 may be configured to adjust the dosage mode of the pump 120 based on the dosage mode observed at the pump 120 and/or the vital signs of the patient 140 reported by the patient monitor 130. For example, the tracking engine 110 may adjust the dosage pattern of the pump 120 by at least modifying the number and/or frequency of drug doses delivered to the patient 140. The number and/or frequency of drug doses delivered to the patient 140 and/or rejected to the patient 140 may be modified by varying at least the duration of the active time period, inactive time period, and/or lockout time period implemented at the pump 120.

At 408, the tracking system 100 may generate and send an electronic alert to the client 150 in response to detecting one or more abnormalities in the dosage pattern of the pump 120 and/or one or more vital signs associated with the patient. In some example embodiments, the tracking engine 110 may be configured to track one or more vital signs associated with the patient 140 and the corresponding dosage pattern observed at the pump 120. For example, the tracking engine 110 may correlate one or more vital signs related to the patient 140 with a dosage pattern observed at the pump 120. Further, when the tracking engine 110 detects an abnormality in one or more of the dosage pattern of the pump 120 and/or one or more vital signs related to the patient 140, the tracking engine 110 may generate an electronic alert (e.g., a push notification, a Short Message Service (SMS) message, etc.) and send the electronic alert to the client 150 associated with the healthcare professional. The one or more abnormalities may include an amount of drug (e.g., a dose of drug) delivered to the patient 140 that is greater than a maximum threshold and/or less than a minimum threshold. Alternatively and/or additionally, the one or more abnormalities may include one or more vital signs of the patient 140 being greater than a maximum threshold and/or less than a minimum threshold. An electronic alert may be sent to the client 150 so that a medical professional associated with the client 150 may evaluate the patient 140 and/or adjust the dosage pattern observed at the pump 120, for example, by modifying the number and/or frequency of medication doses delivered to the patient 140.

FIG. 5 depicts a block diagram that illustrates a computing system 500 consistent with embodiments of the present subject matter. Referring to fig. 1 and 5, a computing system 500 may be used to implement the tracking engine 110 and/or any of the components therein.

As shown in fig. 5, computing system 500 may include a processor 510, a memory 520, a storage 530, and an input/output device 540. The processor 510, memory 520, storage 530, and input/output devices 540 may be interconnected by a system bus 550. Processor 510 is capable of processing instructions for execution within computing system 500. Such executed instructions may implement, for example, one or more components of the trace engine 110. In some example embodiments, the processor 510 may be a single-threaded processor. Alternatively, the processor 510 may be a multi-threaded processor. The processor 510 is capable of processing instructions stored in the memory 520 and/or on the storage device 530 to display graphical information for a user interface provided through the input/output device 540.

As used herein, a "user interface" (also referred to as an interactive user interface, graphical user interface, or UI) may refer to a network-based interface including data fields and/or other control elements for receiving input signals or providing electronic information and/or providing information to a user in response to any received input signals. The control elements may include dials, buttons, icons, selectable areas, or other perceptible indicia presented through the UI that, when interacted with (e.g., clicked, touched, selected, etc.) initiate an exchange of data by the device presenting the UI. The UI may be implemented in whole or in part using techniques such as hypertext markup language (HTML), FLASHTM, JAVATM, NETTM, web services, or Rich Site Summary (RSS). In some embodiments, the UI may be included in a standalone client (e.g., thick client) configured to communicate (e.g., send or receive data) in accordance with one or more aspects described. The communication may be to or from the medical device, diagnostic device, monitoring device, or server with which it is in communication.

Memory 520 is a computer-readable medium, such as volatile or non-volatile computer-readable medium, that stores information within computing system 500. For example, memory 520 may store data structures representing a configuration object database. Storage 530 is capable of providing persistent storage for computing system 500. Storage device 530 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, or other suitable permanent storage device. The input/output device 540 provides input/output operations for the computing system 500. In some example embodiments, the input/output device 540 includes a keyboard and/or pointing device. In various embodiments, the input/output device 540 includes a display unit for displaying a graphical user interface.

According to some example embodiments, the input/output device 540 may provide input/output operations for network devices. For example, the input/output device 540 may include an ethernet port or other network port to communicate with one or more wired and/or wireless networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), the internet).

In some example embodiments, computing system 500 may be used to execute various interactive computer software applications that may be used to organize, analyze, and/or store data in various formats. Alternatively, computing system 500 may be used to execute any type of software application. These application programs may be used to perform various functions such as planning functions (e.g., generating, managing, editing spreadsheet documents, word processing documents, and/or any other objects, etc.), computing functions, communication functions, and the like. The application program may include various additional functionality or may be a stand-alone computing product and/or functionality. Once enabled within the application, these functions may be used to generate a user interface provided through input/output device 540. The user interface may be generated by the computing system 500 (e.g., on a computer screen monitor, etc.) and presented to the user.

In some example embodiments, the pump 120 may be part of the patient care system 20 shown in fig. 6A. Referring to fig. 6A, the patient care system 20 may include a pump 120 and additional pumps 24, 26, and 28. As shown in fig. 6A, each of pumps 120, 24, 26, and 28 may be fluidly connected with upstream fluid lines 30, 32, 34, and 36, respectively. Further, each of the four pumps 120, 24, 26 and 28 may also be fluidly connected to downstream fluid lines 31, 33, 35 and 37, respectively. The fluid line may be any type of fluid conduit, such as a pipe through which a fluid may flow. At least a portion of one or more fluid lines may be constructed using a multilayer arrangement as described herein.

Fluid supplies 38, 40, 42 and 44 (which may take various forms, but in this case are shown as bottles) are inverted and suspended above the pump. The fluid supply means may also take the form of a bag, syringe or other type of container. Both the patient care system 20 and the fluid supplies 38, 40, 42, and 44 are mounted on a roller support or Intravenous (IV) pole 46.

Separate pumps 120, 24, 26 and 28 may be used to infuse each fluid of the fluid supply into the patient. Pumps 120, 24, 26, and 28 may be flow control devices that will act on respective fluid lines to move fluid from a fluid supply through the fluid lines to patient 48. Because separate pumps are used, each pump may be individually set to the pumping or operating parameters required to infuse a particular medical fluid from the corresponding fluid supply into the patient at a particular rate prescribed by the physician for that fluid. Such medical fluids may include drugs or nutrients or other fluids.

Typically, there are more components of the medical fluid applicator than are shown in fig. 6A. Many have check valves, drip chambers, valved ports, connectors and other devices known to those skilled in the art. These other means are not included in the drawings in order to maintain clarity of illustration. Further, it should be noted that the illustration of fig. 6A is not to scale and that the distances have been compressed for clarity. In a practical setting, the distance between the bottles 38, 40, 42, and 44 and the pumps 120, 24, 26, and 28 may be much greater.

Referring now to fig. 6B, an enlarged view of the front of the patient care system 20 is shown. The pump 120 may include a front door 50 and a handle 52, the handle 52 operating to lock the door in a closed position for operation and unlock and open the door to access the internal pumping and sensing mechanism and load the applicator of the pump. When the door is open, the tube may be connected to a pump, as shown in fig. 6C. When the door is closed, the tube is in operative engagement with the pumping mechanism, the upstream and downstream pressure sensors, and other equipment of the pump. In this embodiment, a display 54 (e.g., an LED display) is located in the plan view of the door and may be used to visually convey various information related to the pump, such as an alarm indication (e.g., an alarm message) including an electronic alarm as described herein (e.g., upon detection of one or more anomalies). Control keys 56 are present to program and control operation of the pump as desired. The pump 120 also includes an audio alarm device (not shown) in the form of a speaker.

In the illustrated embodiment, programming module 60 is attached to the left side of pump 120. Other devices or modules (including another pump) may be attached to the right side of the pump 120, as shown in fig. 6A. In this system, each attached pump represents a pump channel of the entire patient care system 20. In one embodiment, the programming module is used to provide an interface between the pump 120 and external devices, and to provide most of the operator interface for the pump 120.

The programming module 60 includes a display 62 for visually communicating various information, such as operating parameters of the pump 120 as well as alarm indications and alarm messages. Programming module 60 may also include a speaker to provide an audible alarm. In this embodiment, the programming module or any other module also has various input devices, including control keys 64 and a bar code or other scanner or reader to scan information from electronic data tags associated with infusions, patients, caregivers, and the like. The programming module also has a communication system (not shown) by which the programming module can communicate with external devices, such as a medical facility server or other computer, as well as a portable processor, such as a hand-held portable digital assistant ("PDA") or laptop computer, or other information device, which is a device that a caregiver may need to communicate and download a drug library to the programming module or pump. In some embodiments, pump 120 can provide data such as vital signs to programming module 60, which programming module 60 can in turn determine a dosage pattern, detect one or more abnormalities, and/or send an electronic alert related to the detected abnormality. In this embodiment, the programming module 60 may communicate with the tracking engine 110, including the tracking engine 110 or implementing features of the tracking engine 110 described herein.

The communication system may take the form of a radio frequency ("RF") (radio frequency) system, an optical system such as infrared, a bluetooth system, or other wired or wireless systems. The barcode scanner and communication system may alternatively be integrally included with the pump 120, such as without or in addition to the use of a programming module. Further, the information input device need not be hardwired to the medical instrument, and information may also be communicated via a wireless connection.

Fig. 6B includes second pump 26 connected to programming module 60. As shown in fig. 6A, more pump modules may be connected. In addition, other types of modules may be connected to the pump module or the programming module. In this embodiment, the tracking engine 110 may track the number and/or frequency of attempts at each pump (e.g., pump 120, pump 26, etc.) to trigger delivery of a dose of medication, to deliver a dose of medication to a patient, and/or to reject delivery of a dose of medication to a patient. Additionally and/or alternatively, the tracking engine 110 can track vital signs of the patient at each pump (e.g., pump 120, pump 26, etc.). Additionally and/or alternatively, the tracking engine 110 may determine a correlation between a dose pattern observed at the patient-controlled analgesia pump and patient response at each pump (e.g., pump 120, pump 26, etc.). In some embodiments, the tracking engine 110 may generate an electronic alert when one or more anomalies are detected in the dosage pattern observed at each pump (e.g., pump 120, pump 26, etc.). The tracking engine 110 may provide additional or alternative control messages to adjust the function of one or more elements of the pump based at least in part on the detected dosage pattern. For example, the tracking engine 110 may disable a dispense button connected to the patient-controlled analgesia module. As another example, the tracking engine 110 may send control messages to adjust the rate of pumping by the motor (e.g., increase the rate, decrease the rate, or stop pumping). As another example, the tracking engine 110 may adjust the configuration of the pump, such as the allowed dosing pattern (e.g., PCA lock duration or frequency).

Turning now to fig. 6C, pump 120 is shown in perspective view with front door 50 open, showing upstream fluid line 30 and downstream fluid line 31 in operative engagement with pump 120. Pump 120 acts directly on tube 66, and tube 66 connects upstream fluid line 30 to downstream fluid line 31 (also referred to as a pump section) to form a continuous fluid conduit extending from a respective fluid supply 38 (fig. 6A) to patient 48, through which the pump acts on the fluid to move the fluid downstream to the patient. Specifically, the pumping mechanism 70 acts as a flow control device for the pump to move fluid through the conduit. The upstream and downstream fluid lines and/or tubes 66 may be connected to a pump cassette or cartridge configured to be connected to a pump 120, such as the type described in co-pending U.S. patent application serial No. 13/827,775, which is incorporated herein by reference.

The type of pumping mechanism may vary and may be, for example, a multi-fingered pumping mechanism. For example, the pumping mechanism may be of the "four finger" type and include an upstream obstruction finger 72, a main pumping finger 74, a downstream obstruction finger 76, and an auxiliary pumping finger 78. The "four finger" pumping mechanism and the mechanisms used in other linear peristaltic pumps operate by a cam behind the pumping fingers and valve fingers 72, 74, 76, and 78 sequentially pressing sections of fluid conduit. Pressure is applied at sequential locations of the conduits, starting at the upstream end of the pumping mechanism and working toward the downstream end. At least one finger is pressed hard all the time to sufficiently occlude the catheter. In effect, one finger occluding the conduit does not retract until the next finger in turn has occluded the conduit; there is no direct fluid path from the fluid supply to the patient at any one time. The operation of peristaltic pumps, including four finger pumps, is well known to those skilled in the art and additional operational details are not provided herein.

In this particular embodiment, FIG. 6C further illustrates a downstream pressure sensor 82 included in the pump 120, the downstream pressure sensor 82 being located at a downstream location relative to the pumping mechanism. A downstream pressure sensor 82 is mounted to the flow control device 70 and is located adjacent to and downstream of the flow control device. The downstream pressure sensor is located downstream of the flow control device, i.e., at a location between the patient 48 (fig. 6A) and the flow control device, so that the connection of the correct fluid supply to the correct pump can be verified before any fluid is pumped to the patient.

Still referring to fig. 6C, upstream pressure sensor 80 may also be included in pump 120. The upstream pressure sensor is assigned to the flow control device or pumping mechanism 70 and, in this embodiment, is further provided as an integral part of the pump 120. An upstream pressure sensor is mounted to the flow control device 70 and is located adjacent to and upstream of the flow control device. The upstream pressure sensor is located upstream of the flow control device, i.e., at a location between the fluid supply 38 (fig. 6A) and the flow control device, to verify that the correct fluid supply is connected to the correct pump before any fluid is pumped to the patient. In embodiments where the source is a syringe, the flow control device 70 may be configured to depress the plunger of the syringe to provide an infusion according to programmed parameters.

Some of the illustrated embodiments discuss features associated with a pump. It should be understood that these features may be implemented in whole or in part using other medication dispensing devices, such as automated dispensing devices configured to provide a medication or other substance to a user for administration, robotically controlled delivery machines, and the like.

One or more aspects or features of the subject matter described herein can be implemented in digital electronic circuitry, integrated circuitry, specially designed ASICs, Field Programmable Gate Arrays (FPGAs), computer hardware, firmware, software, and/or combinations thereof. These various aspects or features may include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be connected for special or general purpose purposes to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. A programmable or computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

These computer programs (which may also be referred to as programs, software applications, components, or code) include machine instructions for a programmable processor and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the term "machine-readable medium" refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, and Programmable Logic Devices (PLDs)) that includes a machine-readable medium that receives machine instructions as a machine-readable signal and that provides machine instructions and/or data to a programmable processor. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor. A machine-readable medium may store such machine instructions non-volatilely, such as would be the case with a non-volatile solid-state memory or a magnetic hard drive or any equivalent storage medium. Alternatively or additionally, a machine-readable medium may store such machine instructions in a transitory manner, such as would be like a processor cache or other random access memory associated with one or more physical processor cores.

To provide for interaction with a user, one or more aspects or features of the subject matter described herein may be implemented on a computer having a display device (e.g., a Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) or Light Emitting Diode (LED) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with the user. For example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic, speech, or tactile input. Other possible input devices include a touch screen or other touch sensitive device such as a single or multi-point resistive or capacitive track pad, voice recognition hardware and software, optical scanners, optical pointers, digital image capture devices and associated interpretation software, and the like.

In the description above and in the claims, phrases such as "at least one" or "one or more" may appear before a combined list of elements or features. The term "and/or" may also appear in a list of two or more elements or features. The phrase is intended to mean any element or feature recited alone, or in combination with any other recited element or feature, unless otherwise implicitly or explicitly contradicted by context of its use. For example, the phrases "at least one of a and B", "one or more of a and B", and "a and/or B" each mean "a alone, B alone, or a and B together". Similar explanations also apply to lists comprising three or more items. For example, each of the phrases "at least one of A, B and C," one or more of A, B and C, "and" A, B and/or C "means" a alone, B alone, C, A and B alone together, a and C together, B and C together, or a and B and C together. The use of the term "based on" in the above and in the claims is intended to mean "based at least in part on" thereby also allowing for unrecited features or elements.

As used herein, the terms "determine" or "determining" encompass a wide variety of actions. For example, "determining" may include calculating, computing, processing, deriving, generating, obtaining, looking up (e.g., looking up in a table, a database, or another data structure), confirming, etc., via a hardware element without user intervention. Further, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc. via a hardware element without user intervention. "determining" may include parsing, selecting, choosing, establishing, etc. via hardware elements without user intervention.

As used herein, the term "provide" or "providing" encompasses a wide variety of actions. For example, "providing" may include storing the value at a location of a storage device for subsequent retrieval, transmitting the value directly to a recipient via at least one wired or wireless communication medium, transmitting or storing a reference to the value, and so forth. "providing" may also include encoding, decoding, encrypting, decrypting, validating, authenticating, etc., via hardware elements.

As used herein, the term "message" encompasses a variety of formats for communicating (e.g., sending or receiving) information. The message may comprise a collection of machine-readable information, such as an XML document, a fixed field message, a comma separated message, and the like. In some embodiments, a message may include a signal to transmit one or more representations of information. Although recited in the singular, it should be understood that a message may be composed of multiple parts, sent, stored, received, etc.

As used herein, the term "correspond to" or "corresponds to" encompasses a structural, functional, quantitative, and/or qualitative correlation or relationship between two or more objects, data sets, information, etc., preferably where the correspondence or relationship may be used to translate one or more of the two or more objects, data sets, information, etc., so as to make them appear the same or equivalent. The correspondence may be evaluated using one or more of thresholds, value ranges, fuzzy logic, pattern matching, machine learning evaluation models, or a combination thereof.

In any embodiment, the data may be forwarded to a "remote device or location," where "remote" means a location or device other than the one where the program is executed. For example, the remote location may be another location in the same city (e.g., an office, a laboratory, etc.), another location in a different city, another location in a different state, another location in a different country, etc. As such, when an item is indicated as being "remote" from another item, it is meant that the two items may be in the same room but separate, or at least in different rooms or different buildings, and may be at least one mile, ten miles, or at least one hundred miles apart. "communicating" information refers to sending data representing the information as electrical signals over a suitable communication channel (e.g., a private network or a public network). "forwarding" an item refers to any manner of physically transporting the item or otherwise (where possible) moving the item from one location to the next, and includes, at least in the case of data, physically transporting a medium carrying the data or transferring the data. Examples of communication media include radio or infrared transmission channels and network connections to another computer or networked device, and the internet or information including e-mail transmissions and recordings on websites and the like.

The subject matter described herein may be embodied in systems, devices, methods, and/or articles of manufacture according to a desired configuration. The embodiments set forth in the foregoing description do not represent all embodiments consistent with the subject matter described herein. Rather, the described embodiments are merely a few examples consistent with aspects related to the described subject matter. Although a number of variations have been described in detail above, other modifications or additions are possible. In particular, additional features and/or variations may be provided in addition to those set forth herein. For example, the embodiments described above may be directed to various combinations and subcombinations of the disclosed features and/or combinations and subcombinations of several additional features disclosed above. In addition, the logic flows depicted in the figures and/or described herein do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Other embodiments may be within the scope of the following claims.