System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy

Abstract

A system and method for monitoring and delivering medication to a patient. The system includes a controller that has a control algorithm and a closed loop control that monitors the control algorithm. A sensor is in communication with the controller and monitors a medical condition. A rule based application in the controller receives data from the sensor and the closed loop control and compares the data to predetermined medical information to determine the risk of automation of therapy to the patient. A system monitor is also in communication with the controller to monitor system, remote system, and network activity and conditions. The controller then provides a predetermined risk threshold where below the predetermined risk threshold automated closed loop medication therapy is provided. If the predetermined risk threshold is met or exceeded, automated therapy adjustments may not occur and user/clinician intervention is requested.

Claims

1. A system for operating an infusion system, the system comprising one or more hardware processors configured to: communicate with a controller of a pump, said pump configured to deliver a drug to a patient according to a first infusion program, said first infusion program corresponding to a first infusion parameters set; communicate with a clinician messaging system that is configured to remotely monitor delivery of the drug; detect a first failure in an infusion system or a second failure with communication with the clinician messaging system; stop the delivery of the drug according to the first infusion program based on the detected first failure; assess a first risk of stopping further delivery of the drug versus a second risk corresponding to the detected first failure or the second failure; and determine whether to continue delivery of the drug according a second infusion program that is different than the first infusion program based on the assessment of the first risk with the second risk, wherein the second infusion program corresponds to a second infusion parameters set.

2. The system of claim 1, wherein the drug is insulin.

3. The system of claim 1, wherein the second failure comprises a network failure.

4. The system of claim 1, wherein the first failure comprises air in an infusion line.

5. The system of claim 1, wherein the failure first comprises occlusion of an infusion line.

6. The system of claim 1, wherein the one or more hardware processors are configured to deliver the drug at a predetermined rate after the detected failure.

7. The system of claim 1, wherein the one or more hardware processors are configured to notify a remote system based on the detected failure.

8. The system of claim 1, wherein the estimation of first risk is determined on a supervisory computing system that is independent from the infusion system.

9. The system of claim 1, wherein the one or more hardware processors are configured to completely stop delivery of the drug based on the assessment indicating that the first risk of stopping is lower than the second risk corresponding to the detected failure.

10. A method for operating an infusion system, the method comprising: controlling a pump that is configured to deliver a drug to a patient according to a first infusion program; communicating with a controller of a pump, said pump configured to deliver a drug to a patient according to a first infusion program, said first infusion program corresponding to a first infusion parameters set; communicating with a clinician messaging system that is configured to remotely monitor delivery of the drug; detecting a first failure in an infusion system or a second failure with communication with the clinician messaging system; stopping the delivery of the drug according to the first infusion program based on the detected first failure; assessing a first risk of stopping further delivery of the drug versus a second risk corresponding to the detected first failure or the second failure; and determining whether to continue delivery of the drug according a second infusion program that is different than the first infusion program based on the assessment of the first risk with the second risk, wherein the second infusion program corresponds to a second infusion parameters set.

11. The method of claim 10, wherein the drug is insulin.

12. The method of claim 10, wherein the second failure comprises a network failure.

13. The method of claim 10, wherein the first failure comprises air in an infusion line.

14. The method of claim 10, wherein the first failure comprises occlusion of an infusion line.

15. The method of claim 10, further comprising delivering the drug at a predetermined rate after the detected failure.

16. The method of claim 10, further comprising notifying a clinician system based on the detected failure.

17. The method of claim 10, wherein the estimation of first risk is determined on a supervisory computing system that is independent from the infusion system.

18. The method of claim 10, further comprising completely stopping delivery of the drug based on the assessment indicating that the first risk of stopping is lower than the second risk corresponding to the detected failure.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 is a schematic diagram of a closed loop control system augmented with the automation risk monitor of the invention;

(2) FIG. 2 is an example messaging diagram for the invention;

(3) FIG. 3 is a schematic diagram showing the architecture of a semi automatic glucose management system;

(4) FIG. 4 is a schematic diagram of an automation risk monitor system; and

(5) FIG. 5 is a schematic diagram of a closed loop control system augmented with the system monitor of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

(6) FIG. 1 provides a system 10 for monitoring and delivering medication, such as insulin, to a patient 12. The system 10 includes a controller 14 that utilizes a control algorithm and an automation risk monitor 15 all presented in a closed loop. A sensor 16 is in communication with the controller 14 and monitors a medical condition of the patient 12. A rule based application 18 (see FIG. 4 for example) in the automation risk monitor of the controller 14 receives data from the sensor 16 and compares the data to predetermined medical information to determine the risk to the patient 12 to automate the delivery of medication.

(7) The rule based application 18 can be set to assess the therapy being administered and its criticality. Further, the rule based application 18 can assess currently administered drugs and 15 patient 12 characteristics such as food intake, fluid intake, and disease state. Patient physiological response variables such as vitals, labs, and cognitive assessments can also be set to be used by the rule based application 18 to determine the risk to the patient. The rule based application 18 can also be set to include factors related to patient risk parameters such as change in patient state and transitions in therapy such as beginning, continuing, changing, or ending therapy.

(8) The rule based application 18 in one embodiment includes physician or clinician entered conditions of when automation is acceptable. Clinician entered conditions can include therapy importance such as critical, life sustaining, supplementary, and benign. Further, the clinician can establish fail-safe, fail-operate, and fail-stop conditions for infusion that are based on strict rules or based on ranges of conditions. The system 10 is thus in communication with a clinician messaging system 20 that communicates to a clinician when the risk of automation is unacceptable. In a preferred embodiment the messaging system is remote from the system 10.

(9) The rule based application 18 in one embodiment can include a risk profile wherein a clinician implements a risk profile according to a metric that may be qualitative (low, medium or 30 high) or quantitative (1-10 where 10 is the highest risk) and a threshold defining when intervention is required. In either case, a quantitative metric is internally calculated and compared to a quantitative threshold. For example, in the case of low, medium or high each qualitative measurement is assigned a quantitative value such as 2, 5 and 7 respectively. Consequently, a risk scale is specified and a threshold above which intervention is requested. The rule based application 18 can also include a risk matrix that is developed to enable a determination of risk. Although the matrix is ultimately stored internally, it can be parameterized by the user. One example of the risk matrix is shown below:

(10) TABLE-US-00001 Glucuse Range (mg/dL) Gluose Δ (derivative) Calculated Δ in Insulin Risk Level  0-70 Increasing Increasing High  0-70 Increasing Decreasing Low  0-70 Decreasing Increasing High  0-70 Decreasing Decreasing Low 70-90 Increasing Increasing Medium 70-90 Increasing Decreasing Low 70-90 Decreasing Increasing Medium 70-90 Decreasing Decreasing Low  90-120 Increasing Increasing Medium  90-120 Increasing Decreasing Low  90-120 Decreasing Increasing High  90-120 Decreasing Decreasing Low 120-180 Increasing Increasing Low 120-180 Increasing Decreasing Low 120-180 Decreasing Increasing Medium 120-180 Decreasing Decreasing Low 180-250 Increasing Increasing Low 180-250 Increasing Decreasing High 180-250 Decreasing Increasing Medium 180-250 Decreasing Decreasing Low Above 250 Increasing Increasing High Above 250 Increasing Decreasing Low Above 250 Decreasing Increasing Low Above 250 Decreasing Decreasing Medium
Specifically, the second column is the calculated or requested insulin level from the closed loop controller. The table is an example of how the treatment condition is mapped to a risk level. There are numerous other methods for implementing this information which may include continuous mapping functions, fuzzy logic, probability calculations and the like.

(11) A second way to provide this type of system is to employ an insulin/glucose pharmacokinetic/pharmacodynamic model as shown below which predicts the future glucose level. The clinician can then use a predicted value rather than or in addition to glucose level and a derivative.

(12) $\begin{array}{cc}\stackrel{.}{G}\left(t\right)=-p_G.Math.G\left(t\right)-S_I\left(t\right).Math.G.Math.\frac{Q\left(t\right)}{1+{\alpha }_{G}Q\left(t\right)}+\frac{P\left(t\right)+\mathrm{EGP}-\mathrm{CNS}}{V_G}\stackrel{.}{I}\left(t\right)=-n\frac{I\left(t\right)}{1+{\alpha }_{I}I\left(t\right)}+\frac{u_{\mathrm{cx}}\left(t\right)}{V_I}+\frac{u_{\mathrm{en}}\left(t\right)}{V_I}{\stackrel{.}{P}}_1\left(t\right)=-d_1{P}_1\left(t\right)+P_e\left(t\right){\stackrel{.}{P}}_2\left(t\right)=-\min \left(d_2{P}_2\left(t\right),P_{\max }\right)+d_1{P}_1\left(t\right)P\left(t\right)=\min \left(d_2{P}_2\left(t\right),P_{\max }\right)+P_N\left(t\right)\stackrel{.}{G}\left(t\right)=-p_G\left(t\right)G\left(t\right)-S_I\left(t\right)G\left(t\right)\frac{Q\left(t\right)}{1+{\alpha }_{G}Q\left(t\right)}+\frac{P\left(t\right)}{V_G}& \left(1\right)\end{array}$$\begin{array}{cc}\stackrel{.}{Q}\left(t\right)=-\mathrm{kQ}\left(t\right)+\mathrm{kI}\left(t\right)& \left(2\right)\end{array}$$\begin{array}{cc}\stackrel{.}{I}\left(t\right)=-n\frac{I\left(t\right)}{1+{\alpha }_{I}I\left(t\right)}+\frac{u_{\mathrm{ex}}\left(t\right)}{V_I}& \left(3\right)\end{array}$
In Equations (1)-(3), G(t) [mmol/L] denotes the total plasma glucose concentration, and I(t) [mU/L] is the plasma insulin concentration. The effect of previously infused insulin being utilized over time is represented by Q(t) [mU/L], with k [1/min] accounting for the effective life of insulin in the system. Exogenous insulin infusion rate is represented by u.sub.ex(t) [mU/min], whereas P(t) [mmol/L min] is the exogenous glucose infusion rate. Patient's endogenous glucose removal and insulin sensitivity through time are described by p.sub.G(t) [I/min] and S.sub.I(t) [L/mU min], respectively. The parameters V.sub.I[L] and V.sub.G[L] stand for insulin and glucose distribution volumes. n [l/min] is the first order decay rate of insulin from plasma. Two Michaelis-Menten constants are used to describe saturation, with α.sub.I [L/mU] used for the saturation of plasma insulin disappearance, and a.sub.G [L/mU] for the saturation of insulin-dependent glucose clearance.

(13) Thus, the rule based application 18 determines the risk to a patient 12 by determining a predetermined risk threshold. Below the predetermined risk threshold, because low risk is detected, the system 10 can move forward in an automated fashion and provide medication as required. If the risk is determined to be above the predetermined risk threshold the controller triggers a request for user intervention by contacting the clinician messaging system 20 instead of moving forward with automation.

(14) The system 10 can also be used to monitor any form of infusion including anticoagulation monitoring during heparin infusion, respiratory monitoring during pain medication infusion such as morphine, and hemodynamic monitoring during infusion of vasco-active medication for cardio vascular support.

(15) As best understood in view of FIGS. 1-5, in an alternative embodiment the system 10 includes a system monitor 22 that is in communication with the controller 14. In one arrangement the system monitor 22 tracks network activity on a network 30 to determine whether a network failure has occurred. The system 22 also detects interruptions in communication with decision support provided by a remote system 23. Similarly, the system monitor 22 tracks network activity to determine whether an interruption has occurred between the system 10 and the clinician messaging system 20 or other remote system 23 that allows for remote operation of the system 10 by a clinician or other basis of support such as medical record tracking. In the event that an interruption is detected the system 10 is enabled to continue infusion at either a backup infusion rate set by a clinician or the rule based application 18. Alternatively, the system 10 can be configured to set an infusion rate based on a default setting that can include a minimum or maximum rate that depends on the physiological state of the patient 12 and the therapy being administered.

(16) In another embodiment the system monitor 22 detects air in line levels. In this embodiment the system monitor 22 determines whether the amount of air present in line is at a critical level that requires stopping the infusion. When air in line is detected the system monitor 22 sends data to the controller 14 that uses the automation risk monitor 15 to determine whether the criticality of treatment is sufficient to allow the system 10 to continue to operate. In one arrangement, when air is detected by the system monitor 22 an alarm is sent via the clinician messaging system 20 or emitted from the system 10 locally. The system monitor 22 also determines whether the detection of air in line is a false positive and if a false positive is detected the alarm is auto-cleared. The system monitor 22 can also be set to not send an alarm if the amount of air present is non-critical.

(17) Additionally, the system monitor 22 detects whether an occlusion is present. If an occlusion is detected the system monitor 22 sends data to the controller 14 to determine whether the occlusion poses a sufficient risk to adjust the infusion rate. Alternatively, if the controller 14 determines a sufficient risk is presented by an occlusion an alarm can be triggered or a message can be sent via the clinician messaging system 20. In one arrangement the presence of occlusions is based on occlusion pressure levels.

(18) In the event that the system monitor 22 detects a sufficient amount of air or large enough occlusion the system 10 can activate a backup system 24. For example, in a life-sustaining situation, a backup system 24 would be enabled and the infusion rate set by the controller 14. In one arrangement, the backup system 24 maintains infusion parameters set by the system 10 so that treatment can be transitioned without interruption.

(19) In another arrangement the system 10 includes a multi-channel infusion system 26 that allows for multiple treatment paths or channels 27. When the system monitor 22 detects that one channel 27 has failed the system 10 switches to an alternative channel 27 to deliver the infusion. In one embodiment the system 10 adjusts the infusion rate of a concurrently infused medication to compensate for the failure of a channel 27. For example, if a dextrose infusion fails in a hypoglycemic patient 12 the system 10 can increase the infusion of nutrition to compensate for the lack of dextrose being infused.

(20) In one embodiment, the system monitor 22 tracks whether input is received from clinicians after the clinician is contacted via the clinician monitoring system 20 to input or confirm a therapy adjustment. If the clinician fails to respond the system monitor 22 sends data to the controller 14 to adjust treatment based on information from the automation risk monitor 15 as described previously.

(21) An alarm system 28 can also be included in the system 10. The alarm system 28 determines the appropriate alarm to send depending on the level of patient risk, uncertainty, and predicted outcomes. In this manner, the alarm system 28 provides the highest degree of alarm in association with critical events that require immediate attention.

(22) In operation, the system 10 monitors a control algorithm of a controller 14 to receive data. The controller 14 additionally receives continuous data from a sensor 16 regarding a medical condition such as a glucose level. The controller 14 then compares the data from the control algorithm and the sensor 16 to predetermined medical information so that the controller 14 can determine a predetermined risk threshold of automating the delivery of medication. Then, based on the data, if a risk is below a predetermined threshold, automation is permitted and a command or request for medication or insulin is provided to the insulin pump. Therefore the insulin delivery rate is automatically updated according to the algorithm model or closed loop controller used. Alternatively, if the risk is at or above a predetermined threshold a request for user intervention is triggered sending a message to the clinician messaging system 20 so that a user may intervene to make a determination regarding whether the medication should be provided. The request for intervention is generated and sent directly to the user through a messaging system that is bi-directional. The message system 20 provides information and requests a user response. When the response is related to a change in therapy an authentication step is included.

(23) The response to a request is provided by the user directly through the user interface of the system. Alternatively, the response can be returned through an authenticated messaging system involving a unique identifier specific to a positive or negative response. In the event that the clinician fails to respond the therapy may be continued at a lower rate or stopped altogether. Optionally, an alarm can be generated by the alarm system 28.

(24) During the course of normal operation glucose measurements may be received that generate a change in the recommended insulin. However, the change may not be significant enough to provide a therapeutic advantage to the patient versus the burden of requesting confirmation from the nurse. Consequently, a rule based application 18 is provided which evaluates therapy changes to trigger a request for an automatic update or nursing intervention. The input to the rule based application 18 includes the blood glucose level, the change in glucose, the insulin infusion, the recommended change in insulin infusion, the estimated insulin on board, and the predicted glucose in the future. Rules involving comparisons to thresholds, regression equations, and calculations are created which trigger a therapy update based on the inputs.

(25) In the event that an interruption to the normal operation of the system 10, the remote systems 23, or network 30 is detected by the system monitor 22, the system adjusts therapy by altering the infusion rate of the system 10 or switching to a backup system 24. Additionally, if an interruption is detected in a system 10 using multi-channel infusions 26, the system 10 can alter the infusion rate or channel 27 used for infusing to compensate for the channel 27 failure.

(26) When a command request is made or an interruption to normal operation is detected an alarm system 28 determines the appropriate alarm to send. The highest alarm is sent by the alarm system 28 based on the most critical failures of the system 10 or risks to the patient 12.

(27) Thus, the present system can be used to make determinations of treatment decisions requiring user intervention based upon a diagnostic value, the change in diagnostic value, the current drug infusion rate, the updated drug infusion rate, the treatment target range, network failures, system failures, and clinician inactivity. In addition, the system notifies a clinician that intervention is required and receives the implementing clinician instruction in response to the notification.

(28) An additional advantage is presented because the system 10 determines when clinician intervention is necessary and unnecessary. Specifically, system 10 is independent of an adaptive control algorithm or a computerized protocol. The system 10 functions as a supervisor that watches the performance of the closed loop system. Consequently, data from the closed loop system and diagnostic sensor 16 are provided to the rule based application 18 that uses a matrix to produce a quantitative level of risk. The level of risk can be expressed as a discrete general level such as the “High”, “Low” and “Medium” values expressed in the table above or the level of risk can be a numerical value, score, index or percentage. The risk is compared to a particular risk threshold to either generate and/or provide an “okay” to proceed with therapy or to trigger a request for user intervention.

(29) This operation differs from current systems that do not determine risk of automation. Instead prior art systems allow automation to occur regardless of potential risk and then when sensors indicate a patient is experiencing an unacceptable medical condition a clinician is alerted. Therefore the system 10 provides an advantage of preventing the unacceptable medical condition from occurring in the first place as a result of monitoring the automation process and predetermining risks of automation.

(30) A further advantage is found in that the system 10 detects failures of the system 10, remote systems 23, networks 30, and inactivity of clinicians. Upon detection of one of these failures or risks posed to a patient the alarm system 28 escalates alarms based on the risk or risks posed to the patient 12 based on changes to the patient 12 or the system 10. Thus, at the very least all of the stated objectives have been met.