Context personalized closed-loop adjustment method and system

Abstract

The invention relates to a context-personalized closed-loop adjustment method and system. Infusion devices, systems, and related methods for autonomously delivering fluid to a patient are disclosed. In one embodiment, a method involves monitoring a current operating context during autonomous operation of the infusion device to deliver fluid to a patient using an initial value of a control parameter according to an operating mode, and autonomously operating the infusion device in response to identifying an adjusted value of the control parameter associated with the current operating context, and a controller to deliver the fluid to the patient using the adjusted value of the control parameter instead of the initial value according to the mode of operation, and thereafter restore the control parameter to the initial value.

Description

[0001] This application is a divisional application of the invention patent application entitled “Contextual Personalized Closed-Loop Adjustment Method and System” with Chinese application number 202080065681.3 and filing date September 16, 2020, PCT application PCT / US2020 / 050960. Technical Field

[0002] Embodiments of the subject matter described herein relate generally to medical devices, and more particularly, embodiments of the subject matter relate to adjusting personalized settings of an infusion device for diabetes therapy management. Background Art

[0003] The pancreas of a normal healthy person produces insulin in response to elevated plasma glucose levels and releases it into the bloodstream. The beta cells (β-cells) in the pancreas produce and secrete insulin into the bloodstream as needed. If the β-cells lose their function or die, a condition known as type I diabetes (or in some cases, if the β-cells do not produce enough insulin, type II diabetes), insulin must be supplied to the body from another source. In the United States alone, diabetes affects approximately 8% of the general population.

[0004] Traditionally, because insulin cannot be taken orally, syringe injection has been used. Infusion pump devices and systems for delivering or distributing medicaments such as insulin or another prescription drug to patients are relatively well known in the medical field. Typical infusion pumps include a pump drive system, which generally includes a small motor and a drive train assembly that converts the motion of a rotary motor into a translational displacement of a plunger (or a stopper) in a reservoir, and the reservoir delivers medicine from the reservoir to the user's body by creating a fluid path between the reservoir and the user's body. The use of infusion pump therapy is increasing, especially for delivering insulin to diabetic patients. For example, an external infusion pump is worn on a belt, in a pocket, etc., and insulin is delivered to the body by an infusion tube with a percutaneous needle or a catheter placed in the subcutaneous tissue.

[0005] Continuous insulin infusion provides better control of the symptom of diabetic patients, and therefore is developing control schemes that allow insulin infusion pumps to monitor and regulate the blood glucose level of users in a substantially continuous and autonomous manner (e.g., overnight when the user is sleeping). Regulating blood glucose levels is complicated by the response time of the type of insulin used and the variation of the individual insulin response of each user. In addition, the daily activities and experiences of the user may cause the insulin response of the user to change during the whole day or from one day to the next day. Therefore, it is desirable to consider the expected changes or fluctuations of the insulin response of the user caused by the activity of the user or one or more other conditions experienced by the user. Existing methods generally involve the user manually adjusting settings temporarily or as needed. Therefore, it is desirable to promote improved glucose control, to reduce the possibility of human error while also reducing the patient's workload. Summary of the invention

[0006] Medical devices and related systems and operating methods are provided. An embodiment of a method for automatically adjusting a control parameter of an operating mode of an infusion device involves: monitoring a current operating context during autonomous operation of the infusion device to deliver fluid to a patient using an initial value of the control parameter according to the operating mode; in response to identifying an adjusted value of the control parameter associated with the current operating context, autonomously operating the infusion device according to the operating mode using the adjusted value of the control parameter instead of the initial value to deliver fluid to the patient; and thereafter restoring the control parameter to the initial value.

[0007] In another embodiment, a method for autonomously delivering a fluid using an infusion device involves: determining an initial command for delivering the fluid based at least in part on a difference between one or more measurements of a physiological condition within a patient and a normal target value for the physiological condition within the patient; and in response to detecting a current operating scenario that corresponds to an operating scenario previously associated with an abnormal state of the patient's physiological condition, determining an adjustment command for delivering the fluid based at least in part on an updated difference between one or more subsequent measurements of the physiological condition within the patient and an adjusted target value for the physiological condition associated with the operating scenario that replaces the normal target value; and thereafter determining subsequent commands for delivering the fluid based at least in part on the normal target value.

[0008] In another embodiment, an infusion system is provided. The infusion system includes: an actuation arrangement operable to deliver a fluid to a patient; a data storage element for maintaining an association between an adjusted control parameter value and a historical operating context of the patient; and a control system coupled to the actuation arrangement and the data storage element for monitoring a current operating context during autonomous operation of the actuation arrangement to deliver the fluid to the patient using an initial value of the control parameter according to an operating mode, and in response to determining that the current operating context matches a historical operating context in a plurality of historical operating contexts, temporarily determining a command for autonomously operating the actuation arrangement using a corresponding adjusted control parameter value associated with the historical operating context instead of the initial value according to the operating mode.

[0009] This Summary is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Description below. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] A more complete understanding of the subject matter may be obtained by referring to the detailed description and claims when considered in conjunction with the following drawings, wherein like reference numerals refer to like elements throughout the drawings.

[0011] Figure 1 An exemplary embodiment of an infusion system is depicted;

[0012] Figure 2 is a block diagram of an exemplary control system suitable for use with a fluid infusion device in one or more embodiments;

[0013] Figure 3 In one or more embodiments, Figure 2 A block diagram of an exemplary pump control system for use in an infusion device in a control system of;

[0014] Figure 4 In one or more exemplary embodiments, Figures 2 to 3 A block diagram of a closed-loop control system implemented or otherwise supported by a pump control system in a fluid infusion device;

[0015] Figure 5 is a block diagram of an exemplary patient monitoring system;

[0016] Figure 6 is a flow chart of an exemplary adjustment determination process suitable for implementation in conjunction with a closed-loop control system for a medical device in one or more exemplary embodiments; and

[0017] Figure 7 In one or more exemplary embodiments, Figure 6 An adjustment determination process is suitable for use with a medical device. DETAILED DESCRIPTION

[0018] The following specific embodiments are merely illustrative in nature and are not intended to limit the application and use of the embodiments of the subject matter or the present application or such embodiments. As used herein, the word "exemplary" means "used as an example, instance or illustration". Any embodiment described as exemplary herein is not necessarily to be construed as being superior to or superior to other embodiments. In addition, it is not intended to be bound by any expressed or implied theory present in the above-mentioned technical field, background technology, summary of the invention or the following specific embodiments.

[0019] Exemplary embodiments of the subject matter described herein are implemented in conjunction with a medical device (such as a portable electronic medical device). Although many different applications are possible, the following description focuses on embodiments in which a fluid infusion device (or infusion pump) is incorporated as part of an infusion system deployment. That is, the subject matter described herein is not limited to an infusion device (or any particular configuration or implementation thereof) and may be implemented in an equivalent manner in the context of a multiple daily injection (MDI) treatment regimen or other medical devices (such as a continuous glucose monitoring (CGM) device, an injection pen (e.g., a smart injection pen), etc.). For the sake of brevity, conventional techniques related to infusion system operation, insulin pump and / or infuser operation, and other functional aspects of the system (and separate operating components of the system) may not be described in detail herein. Examples of infusion pumps may be of, but are not limited to, the types described in the following U.S. Patents: 4,562,751; 4,685,903; 5,080,653; 5,505,709; 5,097,122; 6,485,465; 6,554,798; 6,558,320; 6,558,351; 6,641,533; 6,659,980; 6,752,787; 6,817,990; 6,932,584; and 7,621,893; each of which is incorporated herein by reference.

[0020] In general, a fluid infusion device includes a motor or other actuation arrangement that is operable to displace a plunger (or stopper) or other delivery mechanism to deliver a dose of fluid, such as insulin, to a patient's body from a reservoir provided in the fluid infusion device. The dose command governing the operation of the motor may be generated in an automatic manner according to a delivery control scheme associated with a particular operating mode, and the dose command may be generated in a manner affected by the current (or most recent) measurement of the physiological condition of the user's body. For example, in a closed-loop operating mode, a dose command may be generated based on the difference between the current (or most recent) measurement of the interstitial fluid glucose level in the user's body and the target (or reference) glucose value. In this regard, the infusion rate may vary with the difference between the current measurement value and the target measurement value. For purposes of explanation, this article describes the subject matter in the context of an infused fluid being insulin for regulating the glucose level of a user (or patient); however, it should be understood that many other fluids may be administered by infusion, and the subject matter described herein is not necessarily limited to use with insulin. Additionally, for purposes of explanation, the present subject matter may be described herein in the context of a diabetes patient management system that supports the use of a cloud-based architecture to adjust certain settings of an insulin infusion device used by a patient, wherein most processor-intensive tasks are performed by one or more server systems that communicate with other devices in the system (e.g., mobile client devices, portable insulin infusion devices, data sources (such as patient-related data, insulin pump data, etc.), and potentially other remote devices).

[0021] Exemplary embodiments of the subject matter described herein generally relate to automatically adjusting control parameters utilized by an operating mode of an infusion device, such as a control target or reference for a closed-loop operating mode, in a personalized manner based on a current or real-time operating context (e.g., time of day, day of week, location of the patient, activities or behaviors engaged in by the patient, etc.). For example, based on an analysis of the relationship between the patient's historical glucose measurement data and corresponding contextual data during operation in the closed-loop operating mode, a correlation between a particular operating context and an abnormal physiological state or condition of the patient, such as a high glucose (or hyperglycemia) event (e.g., a glucose level above a threshold), a low glucose (or hypoglycemia) event (e.g., a glucose level below a threshold), a glucose variability event or other glucose excursion event (e.g., time within a range below a threshold), etc. In this regard, an operating context previously associated with a recurrence of an abnormal state of the patient's physiological condition can be identified as a potentially problematic operating context for the patient.

[0022] As described in more detail below, for a detected problematic operating scenario associated with a particular abnormal condition of a patient, an adjusted closed-loop control target can be identified that may adequately mitigate the abnormal condition during autonomous operation concurrent with the potentially problematic operating scenario. Thereafter, in response to real-time detection of the potentially problematic operating scenario, the closed-loop control system can be automatically changed or otherwise adjusted to temporarily utilize the adjusted closed-loop control target associated with the operating scenario for a limited duration before reverting to the original closed-loop control target, thereby reducing the likelihood of recurrence of an abnormal physiological state or condition during recurrence of the previously problematic operating scenario without exiting the closed-loop operating mode and otherwise maintaining the operating mode or control scheme constant. It should be noted that the magnitude of the adjustment to the closed-loop control target can vary depending on the specific operating scenario, and / or the magnitude of the adjustment can be personalized and / or optimized based on patient historical data associated with the operating scenario (e.g., using physiological simulation, cost functions, etc.). Although the subject matter may be discussed herein primarily in the context of adjusting closed-loop control objectives, the subject matter described herein is not limited to closed-loop control schemes and may be implemented in an equivalent manner to adjust control objectives or similar control parameters for other control schemes or systems (e.g., open-loop mode, semi-closed-loop mode, etc.) For example, an open-loop basal rate may be automatically changed or otherwise adjusted to temporarily reduce the likelihood of an abnormal physiological state or condition during a particular operating scenario.

[0023] In one or more embodiments, a plurality of different adjusted closed-loop control targets are identified, and for each adjusted closed-loop control target, the adjusted closed-loop control target can be used in conjunction with the patient's event log data (e.g., meal data, exercise data, sleep data, bolus data, etc.) to determine a corresponding simulated glucose curve, the event log data of these patients corresponding to the aforementioned operation during the detected operating scenario in the closed-loop operating mode. Thereafter, the simulated glucose curve can be analyzed to identify or otherwise select the best closed-loop control target to be utilized. For example, in one embodiment, an adjusted closed-loop control target value that maximizes the time in range (e.g., the amount of time spent within a predefined range of glucose values) or the cumulative amount of time within a certain threshold of the normal closed-loop control target can be selected as the best closed-loop control target value associated with the detected operating scenario, while in other embodiments, an adjusted closed-loop control target value that minimizes the probability of recurrence of an abnormal physiological state or condition can be selected as the best closed-loop control target value associated with the detected operating scenario. In this regard, it should be noted that there are many different ways to identify or otherwise select optimal values ​​of variables, and the subject matter described herein is not intended to be limited to any particular way of identifying the adjusted closed-loop control target value to be utilized. For example, in some embodiments, one or more cost functions may be applied to each simulated glucose curve to determine a respective cost associated with each potential adjusted closed-loop control target value, which in turn is used to identify an optimized adjusted closed-loop control target that achieves minimal cost.

[0024] Infusion System Overview

[0025] Figure 1 An exemplary embodiment of an infusion system 100 is depicted, which includes, but is not limited to, a fluid infusion device (or infusion pump) 102, a sensing arrangement 104, a command control device (CCD) 106, and a computer 108. The components of the infusion system 100 may be implemented using different platforms, designs, and configurations, and Figure 1 The embodiments shown in are not exhaustive or limiting. In practice, Figure 1 As shown in FIG. 1 , the infusion device 102 and the sensing arrangement 104 are fixed at a desired location on the body of the user (or patient). In this regard, Figure 1 The positions of the infusion device 102 and the sensing arrangement 104 in FIG. 1 are fixed to the user's body only as representative, non-limiting examples. The elements of the infusion system 100 may be similar to those described in U.S. Pat. No. 8,674,288, the subject matter of which is incorporated herein by reference in its entirety.

[0026] exist Figure 1In the illustrated embodiment, the infusion device 102 is designed as a portable medical device suitable for infusing a fluid, liquid, gel or other medication into the body of a user. In the exemplary embodiment, the infused fluid is insulin, although many other fluids can be administered by infusion, such as but not limited to HIV medications, medications for treating pulmonary hypertension, iron chelation medications, pain medications, anti-cancer treatments, drugs, vitamins, hormones, etc. In some embodiments, the fluid may include nutritional supplements, dyes, tracking media, saline media, hydration media, etc.

[0027] The sensing arrangement 104 generally represents a component of the infusion system 100 configured to sense, detect, measure, or otherwise quantify a condition of a user, and may include sensors, monitors, and the like for providing data indicative of a condition sensed, detected, measured, or otherwise monitored by the sensing arrangement. In this regard, the sensing arrangement 104 may include electronics and enzymes responsive to a biological condition of the user, such as blood glucose level, and provide data indicative of the blood glucose level to the infusion device 102, CCD 106, and / or computer 108. For example, the infusion device 102, CCD 106, and / or computer 108 may include a display for presenting information or data to the user based on sensor data received from the sensing arrangement 104 (e.g., the user's current glucose level, a curve or graph of the user's glucose level over time, a device status indicator, an alarm message, and the like). In other embodiments, the infusion device 102, the CCD 106, and / or the computer 108 may include electronics and software configured to analyze the sensor data and operate the infusion device 102 to deliver the fluid to the user's body based on the sensor data and / or a preprogrammed delivery routine. Thus, in an exemplary embodiment, one or more of the infusion device 102, the sensing arrangement 104, the CCD 106, and / or the computer 108 include a transmitter, a receiver, and / or other transceiver electronics that allow communication with other components of the infusion system 100, such that the sensing arrangement 104 can transmit sensor data or monitor data to one or more of the infusion device 102, the CCD 106, and / or the computer 108.

[0028] Still reference Figure 1 In various embodiments, the sensing arrangement 104 may be affixed to the user's body or embedded in the user's body at a location remote from where the infusion device 102 is affixed to the user's body. In various other embodiments, the sensing arrangement 104 may be incorporated into the infusion device 102. In other embodiments, the sensing arrangement 104 may be separate and isolated from the infusion device 102 and may be, for example, part of the CCD 106. In such embodiments, the sensing arrangement 104 may be configured to receive a biological sample, an analyte, etc. to measure a condition of the user.

[0029] In some embodiments, the CCD 106 and / or the computer 108 may include electronics and other components configured to perform processing, deliver routine storage, and control the infusion device 102 in a manner affected by sensor data measured by the sensing arrangement 104 and / or received from the sensing arrangement. By including the control functions in the CCD 106 and / or the computer 108, the infusion device 102 can be made with more simplified electronics. However, in other embodiments, the infusion device 102 may include all control functions and may operate without the CCD 106 and / or the computer 108. In various embodiments, the CCD 106 may be a portable electronic device. In addition, in various embodiments, the infusion device 102 and / or the sensing arrangement 104 may be configured to transmit data to the CCD 106 and / or the computer 108 for display or processing of the data by the CCD 106 and / or the computer 108.

[0030] In some embodiments, the CCD 106 and / or computer 108 may provide information to the user that facilitates subsequent use of the infusion device 102 by the user. For example, the CCD 106 may provide information to the user to allow the user to determine the rate or dosage of the drug to be administered to the user's body. In other embodiments, the CCD 106 may provide information to the infusion device 102 to autonomously control the rate or dosage of the drug administered to the user's body. In some embodiments, the sensing arrangement 104 may be integrated into the CCD 106. Such embodiments may allow the user to monitor the condition by providing a sample of, for example, his or her blood to the sensing arrangement 104 to assess his or her condition. In some embodiments, the sensing arrangement 104 and the CCD 106 may be used to determine the glucose level in the user's blood and / or body fluids without using or requiring a wire or cable connection between the infusion device 102 and the sensing arrangement 104 and / or the CCD 106.

[0031] In some embodiments, sensing arrangement 104 and / or infusion device 102 are cooperatively configured to utilize closed loop system to deliver fluid to user. Examples of sensing devices and / or infusion pumps utilizing closed loop system can be found in, but not limited to, U.S. Patent Nos. 6,088,608, 6,119,028, 6,589,229, 6,740,072, 6,827,702, 7,323,142 and 7,402,153 or U.S. Patent Application Publication No. 2014 / 0066889, all of which are incorporated herein by reference in their entirety. In such embodiments, sensing arrangement 104 is configured to sense or measure the condition of the user, such as blood sugar level, etc. Infusion device 102 is configured to deliver fluid in response to the condition sensed by sensing arrangement 104. In turn, the sensing arrangement 104 continues to sense or otherwise quantify the user's current condition, thereby allowing the infusion device 102 to continue to deliver fluid indefinitely in response to the condition currently (or most recently) sensed by the sensing arrangement 104. In some embodiments, the sensing arrangement 104 and / or infusion device 102 may be configured to utilize a closed-loop system only during a portion of the day (e.g., only when the user is asleep or awake).

[0032] Figure 2 An exemplary embodiment of a control system 200 suitable for use with an infusion device 202 (such as the infusion device 102 described above) is depicted. The control system 200 is capable of controlling or otherwise regulating a physiological condition in a user's body 201 to a desired (or target) value, or otherwise maintaining the condition within a range of acceptable values ​​in an automatic or autonomous manner. In one or more exemplary embodiments, the regulated condition is sensed, detected, measured, or otherwise quantified by a sensing arrangement 204 (e.g., sensing arrangement 104) that is communicatively coupled to the infusion device 202. However, it should be noted that in alternative embodiments, the condition regulated by the control system 200 may be related to a measured value obtained by the sensing arrangement 204. That is, for purposes of clarity and explanation, the subject matter may be described herein in the context of a glucose sensing arrangement in which the sensing arrangement 204 is implemented as a glucose sensing arrangement that senses, detects, measures, or otherwise quantifies a patient's glucose level being regulated in the patient's body 201 by the control system 200.

[0033] In an exemplary embodiment, the sensing arrangement 204 includes one or more interstitial glucose sensing elements that generate or otherwise output an electrical signal (alternatively referred to herein as a measurement signal) having a signal characteristic that is related to, affected by, or otherwise indicates a relative interstitial fluid glucose level in the patient's body 201. The output electrical signal is filtered or otherwise processed to obtain a measurement indicating the patient's interstitial fluid glucose level. In an exemplary embodiment, a blood glucose meter 230 (such as a finger stick device) is used to directly sense, detect, measure, or otherwise quantify blood glucose in the user's body 201. In this regard, the blood glucose meter 230 outputs or otherwise provides a measured blood glucose value that can be used as a reference measurement for calibrating the sensing arrangement 204 and converting the measurement indicating the patient's interstitial fluid glucose level into a corresponding calibrated blood glucose value. For the purpose of explanation, the calibrated glucose value calculated based on the electrical signal output by the sensing element of the sensing arrangement 204 is alternatively referred to herein as a sensor glucose value, a sensed glucose value, or a variant thereof.

[0034] In the illustrated embodiment, the control system 200 also includes one or more additional sensing arrangements 206, 208 configured to sense, detect, measure, or otherwise quantify a characteristic of the patient's body 201 that is indicative of a condition in the patient's body 201. In this regard, in addition to the glucose sensing arrangement 204, one or more auxiliary sensing arrangements 206 may be worn, carried, or otherwise associated with the patient's body 201 to measure a characteristic or condition of the patient (or the patient's activity) that may affect the patient's glucose level or insulin sensitivity. For example, a heart rate sensing arrangement 206 may be worn on or otherwise associated with the patient's body 201 to sense, detect, measure, or otherwise quantify the patient's heart rate, which in turn may indicate movement (and its intensity) that may affect the patient's glucose level or insulin response in the body 201. In yet another embodiment, another invasive, interstitial, or subcutaneous sensing arrangement 206 may be inserted into the patient's body 201 to obtain a measurement of another physiological condition that may be indicative of movement (and its intensity), such as a lactate sensor, a ketone sensor, or the like. Depending on the embodiment, the auxiliary sensing arrangement(s) 206 may be implemented as a separate component worn by the patient, or alternatively, the auxiliary sensing arrangement(s) 206 may be integrated with the infusion device 202 or the glucose sensing arrangement 204.

[0035] The illustrated control system 200 also includes an acceleration sensing arrangement 208 (or accelerometer) that may be worn on or otherwise associated with the patient's body 201 to sense, detect, measure, or otherwise quantify acceleration of the patient's body 201, which in turn may indicate motion or some other condition in the body 201 that may affect the patient's insulin response. Figure 2 202, but in alternative embodiments, the acceleration sensing arrangement 208 may be integrated with another sensing arrangement 204, 206 on the patient's body 201, or the acceleration sensing arrangement 208 may be implemented as a separate stand-alone component worn by the patient.

[0036] In some embodiments, the infusion device 202 (or the control system 200) may also include one or more environmental sensing arrangements to sense, detect, measure, or otherwise quantify the current operating environment surrounding the infusion device 202. In this regard, the environmental sensing arrangement may include one or more of a temperature sensing arrangement (or thermometer), a humidity sensing arrangement, a pressure sensing arrangement (or barometer), etc. Additionally, the infusion device 202 (or the control system 200) may also include a location sensing arrangement to sense, detect, measure, or otherwise quantify the current geographic location of the infusion device 202, such as a global positioning system (GPS) receiver. Again, it should be noted that such a sensing arrangement may be integrated into the infusion device 202, integrated with other components, or implemented as a separate stand-alone component worn or carried by the patient.

[0037] In the illustrated embodiment, the pump control system 220 generally represents the electronics and other components of the infusion device 202 that control the operation of the fluid infusion device 202 in accordance with a desired infusion delivery program in a manner that is influenced by a sensed glucose value that is indicative of a current glucose level in the patient's body 201. For example, to support a closed-loop operating mode, the pump control system 220 maintains, receives, or otherwise obtains a target or command glucose value, and automatically generates or otherwise determines a dose command for operating an actuation arrangement (such as the motor 232) to displace the plunger 217 and deliver insulin to the patient's body 201 based on a difference between the sensed glucose value and the target glucose value. In other operating modes, the pump control system 220 may generate or otherwise determine a dose command that is configured to maintain the sensed glucose value below an upper glucose limit, above a lower glucose limit, or otherwise within a desired range of glucose values. In practice, the infusion device 202 may store or otherwise maintain the target value, upper and / or lower glucose limit(s), insulin delivery limit(s), and / or other glucose threshold(s) in a data storage element accessible to the pump control system 220. In one or more exemplary embodiments, the pump control system 220 automatically adjusts or adapts one or more parameters or other control information used to generate commands to operate the motor 232 in a manner that takes into account changes that may occur in the patient's glucose level or insulin response due to meals, exercise, or other activities.

[0038] Still refer to Figure 2 The target glucose value and other threshold glucose values ​​utilized by the pump control system 220 may be received from an external component (e.g., the CCD 106 and / or the computing device 108), or may be input by the patient through a user interface element 240 associated with the infusion device 202. In practice, the one or more user interface elements 240 associated with the infusion device 202 typically include at least one input user interface element, such as a button, a keypad, a keyboard, a knob, a joystick, a mouse, a touch panel, a touch screen, a microphone or another audio input device, etc. In addition, the one or more user interface elements 240 include at least one output user interface element for providing notifications or other information to the patient, such as a display element (e.g., a light emitting diode, etc.), a display device (e.g., a liquid crystal display, etc.), a speaker or another audio output device, a tactile feedback device, etc. It should be noted that although Figure 2The one or more user interface elements 240 are depicted as being separate from the infusion device 202, but in practice, the one or more user interface elements 240 may be integrated with the infusion device 202. Furthermore, in some embodiments, in addition to and / or in lieu of the user interface element(s) 240 being integrated with the infusion device 202, the one or more user interface elements 240 are integrated with the sensing arrangement 204. The user interface element(s) 240 may be manipulated by the patient to operate the infusion device 202 as desired to deliver a correction bolus, adjust target values ​​and / or thresholds, modify a delivery control scheme or mode of operation, and the like.

[0039] Still refer to Figure 2 In the illustrated embodiment, the infusion set 202 includes a motor control module 212 coupled to a motor 232 operable to displace a plunger 217 in the infusion set and provide a desired amount of fluid to the patient's body 201. In this regard, displacement of the plunger 217 results in fluid (e.g., insulin) capable of affecting the patient's physiological condition being delivered to the patient's body 201 via a fluid delivery path (e.g., via a tube of the infusion set). A motor driver module 214 is coupled between an energy source 218 and the motor 232. The motor control module 212 is coupled to the motor driver module 214, and the motor control module 212 generates or otherwise provides a command signal that operates the motor driver module 214 to provide current (or power) from the energy source 218 to the motor 232 to displace the plunger 217 in response to receiving a dose command from the pump control system 220 indicating a desired amount of fluid to be delivered.

[0040] In an exemplary embodiment, the energy source 218 is implemented as a battery contained within the infusion device 202 that provides direct current (DC) power. In this regard, the motor driver module 214 generally represents a combination of circuitry, hardware, and / or other electrical components that are configured to convert or otherwise transform the DC power provided by the energy source 218 into an alternating current signal that is applied to the stator windings of the motor 232, causing current to flow through the corresponding phases of the stator windings, the current generating a stator magnetic field and rotating the rotor of the motor 232. The motor control module 212 is configured to receive or otherwise obtain a commanded dose from the pump control system 220, convert the commanded dose into a commanded translational displacement of the plunger 217, and command, signal, or otherwise operate the motor driver module 214 to rotate the rotor of the motor 232 by an amount that produces the commanded translational displacement of the plunger 217. For example, the motor control module 212 can determine the amount of rotation of the rotor required to produce the translational displacement of the plunger 217 to achieve the commanded dose received from the pump control system 220. Based on the current rotational position (or orientation) of the rotor relative to the stator indicated by the output of the rotor sensing arrangement 216, the motor control module 212 determines the appropriate sequence of AC electrical signals of corresponding phases to be applied to the stator windings that should cause the rotor to rotate a determined amount of rotation from its current position (or orientation). In an embodiment in which the motor 232 is implemented as a BLDC motor, the AC electrical signals cause the corresponding phases of the stator windings to switch directions with the appropriate orientation of the rotor poles relative to the stator and in an appropriate sequence to provide a rotating stator magnetic field that causes the rotor to rotate in the desired direction. Thereafter, the motor control module 212 operates the motor driver module 214 to apply the determined AC electrical signals (e.g., command signals) to the stator windings of the motor 232 to achieve the desired fluid delivery to the patient.

[0041] When the motor control module 212 is operating the motor driver module 214, current flows from the energy source 218 through the stator windings of the motor 232 to generate a stator magnetic field that interacts with the rotor magnetic field. In some embodiments, after the motor control module 212 operates the motor driver module 214 and / or the motor 232 to achieve the commanded dose, the motor control module 212 stops operating the motor driver module 214 and / or the motor 232 until a subsequent dose command is received. In this regard, the motor driver module 214 and the motor 232 enter an idle state, during which the motor driver module 214 effectively disconnects or separates the stator windings of the motor 232 from the energy source 218. In other words, current does not flow from the energy source 218 through the stator windings of the motor 232 when the motor 232 is idle, and therefore, the motor 232 does not consume power from the energy source 218 in the idle state, thereby improving efficiency.

[0042] Depending on the embodiment, the motor control module 212 may be implemented or realized with a general purpose processor, microprocessor, controller, microcontroller, state machine, content addressable memory, application specific integrated circuit, field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. In an exemplary embodiment, the motor control module 212 contains or otherwise has access to a data storage element or memory capable of storing programming instructions executed by the motor control module 212, including any kind of random access memory (RAM), read-only memory (ROM), flash memory, registers, hard disk, removable disk, magnetic or optical mass storage, or any other short-term or long-term storage medium or other non-transitory computer-readable medium. When read and executed by the motor control module 212, the computer executable programming instructions cause the motor control module 212 to perform or otherwise support the tasks, operations, functions, and processes described herein.

[0043] It should be understood that for the purpose of explanation, Figure 2 is a simplified representation of the infusion device 202 and is not intended to limit the subject matter described herein in any way. In this regard, depending on the embodiment, some features and / or functionality of the sensing arrangement 204 may be implemented by or otherwise integrated into the pump control system 220 or vice versa. Similarly, in practice, features and / or functionality of the motor control module 212 may be implemented by or otherwise integrated into the pump control system 220 or vice versa. In addition, features and / or functionality of the pump control system 220 may be implemented by control electronics located in the fluid infusion device 202, while in alternative embodiments, the pump control system 220 may be implemented by a remote computing device that is physically distinct and / or separate from the infusion device 202 (e.g., the CCD 106 or the computing device 108).

[0044] Figure 3 Describes an embodiment of the present invention that is suitable for use as Figure 2 20. The pump control system 300 of the embodiment of the present invention is an exemplary embodiment of the pump control system 300 of the pump control system 220 in the embodiment of the present invention. The illustrated pump control system 300 includes, but is not limited to, a pump control module 302, a communication interface 304, and a data storage element (or memory) 306. The pump control module 302 is coupled to the communication interface 304 and the memory 306, and the pump control module 302 is suitably configured to support the operations, tasks, and / or processes described herein. In various embodiments, the pump control module 302 is also coupled to one or more user interface elements (e.g., the user interface 240) to receive user input (e.g., a target glucose value or other glucose threshold) and provide notifications, alarms, or other therapy information to the patient.

[0045] The communication interface 304 generally represents the hardware, circuitry, logic, firmware, and / or other components of the pump control system 300 that are coupled to the pump control module 302 and are configured to support communications between the pump control system 300 and the various sensing arrangements 204, 206, 208. In this regard, the communication interface 304 may include or otherwise be coupled to one or more transceiver modules capable of supporting wireless communications between the pump control system 220, 300 and the sensing arrangement(s) 204, 206, 208. For example, the communication interface 304 may be used to receive sensor measurements or other measurement data from each sensing arrangement 204, 206, 208 in the control system 200. In other embodiments, the communication interface 304 may be configured to support wired communications to / from the sensing arrangement(s) 204, 206, 208. In various embodiments, the communication interface 304 may also support communication with another electronic device in the infusion system (e.g., CCD 106 and / or computer 108) (e.g., uploading sensor measurements to a server or other computing device, receiving control information from a server or other computing device, etc.).

[0046] The pump control module 302 generally represents the hardware, circuitry, logic, firmware, and / or other components of the pump control system 300 that are coupled to the communication interface 304 and are configured to determine dosage commands for operating the motor 232 to deliver fluid to the body 201 based on measurement data received from the sensing arrangements 204, 206, 208 and to perform various additional tasks, operations, functions, and / or operations described herein. For example, in an exemplary embodiment, the pump control module 302 implements or otherwise executes a command generation application 310 that supports one or more autonomous operation modes and calculates or otherwise determines dosage commands for operating the motor 232 of the infusion device 202 in the autonomous operation mode based at least in part on current measurements of conditions in the patient's body 201. For example, in a closed-loop operation mode, the command generation application 310 may determine dosage commands for operating the motor 232 to deliver insulin to the patient's body 201 to adjust the patient's blood glucose level to a target reference glucose value based at least in part on current glucose measurements most recently received from the sensing arrangement 204. Additionally, the command generation application 310 may generate dosage commands for bolus injections that are manually initiated or otherwise indicated by the patient via a user interface element.

[0047] In an exemplary embodiment, the pump control module 302 also implements or otherwise executes a personalization application 308 that is cooperatively configured to interact with the command generation application 310 to support determining the manner in which the dose command is generated to adjust the dose command or control information in a personalized patient-specific manner. In this regard, in some embodiments, based on the correlation between the current or recent measurement data and the current operating context relative to the historical data associated with the patient, the personalization application 308 may adjust or otherwise modify the value of one or more parameters utilized by the command generation application 310 in determining the dose command, for example by modifying the parameter value at a register or location in the memory 306 referenced by the command generation application 310. In still other embodiments, the personalization application 308 may predict meals or other events or activities that the patient may participate in, and output or otherwise provide an indication of the predicted patient behavior, which in turn may then be used to adjust in a personalized manner the manner in which the dose command is generated to adjust glucose in a manner that takes into account the patient's predicted behavior. In some embodiments, the personalization application 308 may support automatically performing personalized adjustments of control parameters utilized by the command generation application 310.

[0048] Still refer to Figure 3 Depending on the embodiment, the pump control module 302 may be implemented or realized with a general purpose processor, microprocessor, controller, microcontroller, state machine, content addressable memory, application specific integrated circuit, field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. In this regard, the steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be directly embodied in hardware, firmware, a software module executed by the pump control module 302, or any practical combination thereof. In an exemplary embodiment, the pump control module 302 contains or otherwise accesses a data storage element or memory 306, which may be implemented using any type of non-transitory computer-readable medium capable of storing programming instructions for execution by the pump control module 302. When read and executed by the pump control module 302, the computer executable programming instructions cause the pump control module 302 to implement or otherwise generate the applications 308, 310 and perform the tasks, operations, functions, and processes described herein.

[0049] It should be understood that for the purpose of explanation, Figure 3is a simplified representation of the pump control system 300 and is not intended to limit the subject matter described herein in any way. For example, in some embodiments, the features and / or functionality of the motor control module 212 may be implemented by or otherwise integrated into the pump control system 300 and / or the pump control module 302, such as by the command generation application 310 converting dose commands into corresponding motor commands, in which case a separate motor control module 212 may not be present in embodiments of the infusion device 202.

[0050] Figure 4 Depicts an exemplary closed-loop control system 400 that may be implemented by the pump control system 220, 300 to provide a closed-loop operating mode that autonomously regulates the patient's physical condition to a reference (or target) value. It should be understood that for purposes of explanation, Figure 4 is a simplified representation of control system 400 and is not intended to limit the subject matter described herein in any way.

[0051] In an exemplary embodiment, the control system 400 receives or otherwise obtains a target blood glucose value at an input 402. In some embodiments, the target blood glucose value can be stored or otherwise maintained (e.g., in a memory 306) by the infusion device 202, however, in some alternative embodiments, the target value can be received from an external component (e.g., CCD 106 and / or computer 108). In one or more embodiments, the target glucose value can be calculated or otherwise determined before entering the closed-loop operation mode based on one or more patient-specific control parameters. For example, the target blood glucose value can be calculated at least in part based on a patient-specific reference basal rate and a patient-specific daily insulin requirement, and the patient-specific reference basal rate and the patient-specific daily insulin requirement are determined based on historical delivery information (e.g., the amount of insulin delivered within the first 24 hours) in a previous time interval. The control system 400 also receives or otherwise obtains a current blood glucose measurement value (e.g., the most recently obtained sensor blood glucose value) from the sensing arrangement 204 at an input 404. The control system 400 shown implements or otherwise provides a proportional integral derivative (PID) control to determine or otherwise generate a delivery command for operating the motor 232 based at least in part on the difference between the target blood glucose value and the current blood glucose measurement. In this regard, the PID control attempts to minimize the difference between the measured value and the target value, and thereby adjusts the measured value to the desired value. The PID control parameters are applied to the difference between the target blood glucose level at the input 402 and the measured blood glucose level at the input 404 to generate or otherwise determine the dosage (or delivery) command provided at the output 430. Based on the delivery command, the motor control module 212 operates the motor 232 to deliver insulin to the patient's body to affect the patient's blood glucose level, and thereby reduce the difference between the subsequently measured blood glucose level and the target blood glucose level.

[0052] The illustrated control system 400 includes or otherwise implements a summing block 406 configured to determine the difference between a target value obtained at input 402 and a measured value obtained from the sensing arrangement 204 at input 404, for example by subtracting the target value from the measured value. The output of the summing block 406 represents the difference between the measured value and the target value, which is then provided to each of the proportional term path, the integral term path, and the derivative term path. The proportional term path includes multiplying the difference by a proportional gain coefficient K P The integral term path includes an integral block 408 that integrates the difference and multiplies the integrated difference by an integral gain factor K. I The derivative term path includes a derivative block 410 that determines the derivative of the difference and multiplies the derivative of the difference by a derivative gain coefficient K. Dto obtain a gain block 424 for the derivative term. The proportional, integral, and derivative terms are then summed or otherwise combined to obtain a delivery command for operating the motor at output 430. Various implementation details related to closed-loop PID control and determining gain coefficients are described in more detail in U.S. Pat. No. 7,402,153, which is incorporated by reference.

[0053] In one or more exemplary embodiments, the PID gain factor is patient-specific and is dynamically calculated or otherwise determined before entering the closed-loop operating mode based on historical insulin delivery information (e.g., amount and / or timing of previous doses, historical correction bolus information, etc.), historical sensor measurements, historical reference blood glucose measurements, user-reported or user-entered events (e.g., meals, exercise, etc.), etc. In this regard, one or more patient-specific control parameters (e.g., insulin sensitivity factor, daily insulin requirement, insulin limit, reference basal rate, reference fasting blood glucose, effective insulin action duration, drug effect time constant, etc.) can be used to compensate, correct or otherwise adjust the PID gain factor to account for various operating conditions experienced and / or exhibited by the infusion device 202. The PID gain factor can be maintained by a memory 306 accessible to the pump control module 302. In this regard, the memory 306 can include a plurality of registers associated with control parameters for PID control. For example, a first parameter register may store a target blood glucose value and be accessed by or otherwise coupled to the summing block 406 at input 402, and similarly, a second parameter register accessed by the proportional gain block 420 may store a proportional gain coefficient, a third parameter register accessed by the integral gain block 422 may store an integral gain coefficient, and a fourth parameter register accessed by the derivative gain block 424 may store a derivative gain coefficient.

[0054] As follows Figures 6 to 7As described in more detail in the context of , in an exemplary embodiment, in response to detecting an operational context associated with an abnormal glycemic condition or event of a patient, the closed-loop control target value at input 402 is temporarily automatically adjusted. For example, during an operational context associated with a patient exhibiting a hypoglycemic event (e.g., a specific time on a specific day of the week), an adjusted closed-loop control target value can be utilized at input 402 that is greater than a normal (or previous) control target value previously utilized at input 402 to temporarily reduce the rate or amount of insulin infusion in response to detecting the operational context. Thus, during a specific time on a specific day of the week when the patient is susceptible or otherwise prone to hypoglycemia, the closed-loop control target value at input 402 is automatically adjusted in real time to reduce the likelihood that the patient will experience hypoglycemia at or around the specific time on the specific day of the week. After the period of time in which the patient has previously exhibited hypoglycemia, the closed-loop control target value at input 402 can be automatically restored to a normal (or previous) target value (e.g., an original target value entered or set by the patient, determined based on the patient's historical delivery information, etc.). Conversely, in response to detecting an operating scenario associated with a hyperglycemic event, an adjusted closed-loop control target value may be utilized at input 402 that is less than the normal (or previous) control target value utilized at input 402 to temporarily increase the rate or amount of insulin infusion in response to detecting the operating scenario, thereby reducing the likelihood of hyperglycemia in the patient.

[0055] Figure 5 An exemplary embodiment of a patient monitoring system 500 is depicted. The patient monitoring system 500 includes a medical device 502 that is communicatively coupled to a sensing element 504 that is inserted into a patient's body or otherwise worn by the patient to obtain measurement data indicative of a physiological condition in the patient's body, such as a sensed blood glucose level. The medical device 502 is communicatively coupled to a client device 506 via a communication network 510, wherein the client device 506 is communicatively coupled to a remote device 514 via another communication network 512. In this regard, the client device 506 may act as an intermediary for uploading or otherwise providing measurement data from the medical device 502 to the remote device 514. It should be appreciated that for purposes of explanation, Figure 5 A simplified representation of patient monitoring system 500 is depicted and is not intended to limit the subject matter described herein in any way.

[0056] In an exemplary embodiment, the client device 506 is implemented as a mobile phone, a smart phone, a tablet computer or other similar mobile electronic device, however, in other embodiments, the client device 506 can be implemented as any kind of electronic device capable of communicating with the medical device 502 via the network 510, such as a laptop or notebook computer, a desktop computer, etc. In an exemplary embodiment, the network 510 is implemented as a Bluetooth network, a ZigBee network or another suitable personal area network. That is, in other embodiments, the network 510 can be implemented as a wireless ad hoc network, a wireless local area network (WLAN) or a local area network (LAN). The client device 506 includes or is connected to a display device capable of graphically presenting data and / or information related to the patient's physiological condition, such as a monitor, a screen or another conventional electronic display. The client device 506 also includes a user input device capable of receiving input data and / or other information from a user of the client device 506, such as a keyboard, a mouse, a touch screen, etc., or is otherwise associated with the user input device.

[0057] In some embodiments, a user, such as a patient, a patient's physician, or another healthcare provider, manipulates the client device 506 to execute a client application 508 that supports communication with the medical device 502 over the network 510. In this regard, the client application 508 supports establishing a communication session with the medical device 502 over the network 510 and receiving data and / or information from the medical device 502 over the communication session. The medical device 502 may similarly execute or otherwise implement a corresponding application or process that supports establishing a communication session with the client application 508. The client application 508 generally represents a software module or another feature generated or otherwise implemented by the client device 506 to support the processes described herein. Thus, the client device 506 generally includes a processing system and a data storage element (or memory) capable of storing programming instructions executed by the processing system, which, when read and executed, causes the processing system to create, generate, or otherwise facilitate the client application 508 and perform or otherwise support the processes, tasks, operations, and / or functions described herein. Depending on the embodiment, the processing system may be implemented using any suitable processing system and / or device (e.g., one or more processors, central processing units (CPUs), controllers, microprocessors, microcontrollers, processing cores, and / or other hardware computing resources) configured to support the operations of the processing system described herein. Similarly, the data storage element or memory may be implemented as a random access memory (RAM), a read-only memory (ROM), flash memory, magnetic or optical mass storage, or any other suitable non-transitory short-term or long-term data storage or other computer-readable medium, and / or any suitable combination thereof.

[0058] In one or more embodiments, the client device 506 and the medical device 502 establish an association (or pairing) with each other through the network 510 to support the subsequent establishment of a peer-to-peer communication session between the medical device 502 and the client device 506 through the network 510. For example, according to one embodiment, the network 510 is implemented as a Bluetooth network, wherein the medical device 502 and the client device 506 are paired with each other by performing a discovery procedure or other suitable pairing procedure (e.g., by obtaining and storing each other's network identification information). The pairing information obtained during the discovery procedure allows either the medical device 502 or the client device 506 to initiate the establishment of a secure communication session through the network 510.

[0059] In one or more exemplary embodiments, the client application 508 is also configured to store or otherwise maintain the address and / or other identification information of the remote device 514 on the second network 512. In this regard, the second network 512 can be physically and / or logically different from the network 510, such as the Internet, a cellular network, a wide area network (WAN), etc. The remote device 514 generally represents a server or other computing device configured to receive and analyze or otherwise monitor measurement data, event log data, and potentially other information obtained for a patient associated with the medical device 502. In an exemplary embodiment, the remote device 514 is connected to a database 516 configured to store or otherwise maintain data associated with an individual patient. In practice, the remote device 514 can reside at a location physically different and / or separate from the medical device 502 and the client device 506, such as at a facility owned and / or operated by the manufacturer of the medical device 502 or otherwise affiliated with the manufacturer. For the purpose of explanation but not limitation, the remote device 514 is alternatively referred to as a server herein.

[0060] It should be noted that in some embodiments, some or all of the functionality and processing intelligence of the remote computing device 514 may reside at the medical device 502 and / or other components or computing devices compatible with the patient monitoring system 500. In other words, the patient monitoring system 500 need not rely on a network-based or cloud-based server arrangement, such as Figure 5 , but such deployment may be the most efficient and economical implementation. The present disclosure contemplates these and other alternative arrangements. To this end, some embodiments of system 500 may include additional devices and components that serve as data sources, data processing units, and / or advice delivery mechanisms. For example, system 500 may include, but is not limited to, any one or all of the following elements: a computer device or system; a patient monitor; a healthcare provider system; a data communication device, etc.

[0061] Still refer to Figure 5, sensing element 504 generally represents a component of the patient monitoring system 500 that is configured to generate, produce, or otherwise output one or more electrical signals indicative of a physiological condition sensed, measured, or otherwise quantified by the sensing element 504. In this regard, the patient's physiological condition affects the characteristics of the electrical signal output by the sensing element 504, such that the characteristics of the output signal correspond to or are otherwise related to the physiological condition to which the sensing element 504 is sensitive. In an exemplary embodiment, the sensing element 504 is implemented as an interstitial glucose sensing element inserted at a location on the patient's body, the interstitial glucose sensing element generating an output electrical signal having a current (or voltage) associated with the interstitial glucose sensing element that is related to the interstitial fluid glucose level sensed or otherwise measured by the sensing element 504 in the patient's body.

[0062] The medical device 502 generally represents a component of the patient monitoring system 500 that is communicatively coupled to the output of the sensing element 504 to receive or otherwise obtain measurement data samples (e.g., measured blood glucose and characteristic impedance values) from the sensing element 504, store or otherwise maintain the measurement data samples, and upload or otherwise transmit the measurement data to the server 514 via the client device 506. In one or more embodiments, the medical device 502 is implemented as an infusion device 102, 202 configured to deliver a fluid, such as insulin, to the patient's body. That is, in other embodiments, the medical device 502 can be an independent sensing or monitoring device (e.g., a sensing arrangement 104, 204) that is separate and independent from the infusion device, such as a continuous glucose monitor (CGM), an interstitial glucose sensing arrangement, or the like. It should be noted that although Figure 5 Medical device 502 and sensing element 504 are depicted as separate components, but in practice, medical device 502 and sensing element 504 may be integrated or otherwise combined to provide an integral device that may be worn by a patient.

[0063] In an exemplary embodiment, medical device 502 includes control module 522, data storage element 524 (or memory), communication interface 526 and user interface 528. User interface 528 generally represents input user interface element and / or output user interface element (for example, one or more user interface elements 240) associated with medical device 502. Control module 522 generally represents hardware, circuit system, logic, firmware and / or other components of medical device 502 that are connected to sensing element 504 to receive the electrical signal output by sensing element 504 and perform or otherwise support various other tasks, operations, functions and / or processes described herein. Depending on the embodiment, control module 522 can be implemented or realized with a general-purpose processor, microprocessor, controller, microcontroller, state machine, content addressable memory, application specific integrated circuit, field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components or any combination thereof designed to perform the functions described herein. In some embodiments, control module 522 includes an analog-to-digital converter (ADC) or another similar sampling arrangement that samples or otherwise converts output electrical signals received from sensing element 504 into corresponding digital measurement data values. In other embodiments, sensing element 504 may incorporate an ADC and output digital measurement values.

[0064] The communication interface 526 generally represents the hardware, circuitry, logic, firmware, and / or other components of the medical device 502 that are coupled to the control module 522 to output data and / or information from the medical device 502 to / from the client device 506. For example, the communication interface 526 may include or otherwise be coupled to one or more transceiver modules capable of supporting wireless communication between the medical device 502 and the client device 506. In an exemplary embodiment, the communication interface 526 is implemented as a Bluetooth transceiver or adapter configured to support Bluetooth Low Energy (BLE) communications.

[0065] In an exemplary embodiment, the remote device 514 receives measurement data values ​​(e.g., sensor blood glucose measurements, acceleration measurements, etc.) associated with a particular patient obtained using the sensing element 504 from the client device 506, and the remote device 514 stores or otherwise maintains the historical measurement data in association with the patient in a database 516 (e.g., using one or more unique patient identifiers). In addition, the remote device 514 may also receive meal data or other event log data that may be input or otherwise provided by the patient (e.g., through the client application 508) from or through the client device 506 and store or otherwise maintain historical meal data and other historical event or activity data associated with the patient in the database 516. In this regard, the meal data may include, for example, a time or timestamp associated with a particular meal event, a meal type or other information indicating the content or nutritional characteristics of the meal, and an indication of the size associated with the meal. In an exemplary embodiment, the remote device 514 also receives historical fluid delivery data corresponding to a basic or bolus fluid dose delivered to the patient by the infusion device 102, 202. For example, the client application 508 may communicate with the infusion device 102, 202 to obtain the insulin delivery dose and the corresponding timestamp from the infusion device 102, 202, and then upload the insulin delivery data to the remote device 514 for storage in association with a particular patient. The remote device 514 may also receive geographic location data and potentially other contextual data associated with the device 502, 506 from the client device 506 and / or the client application 508, and store or otherwise maintain historical operational contextual data in association with a particular patient. In this regard, one or more of the devices 502, 506 may include a global positioning system (GPS) receiver or similar module, component, or circuit system capable of outputting or otherwise providing data characterizing the geographic location of the respective device 502, 506 in real time.

[0066] The historical patient data can be analyzed by one or more of the remote device 514, the client device 506, and / or the medical device 502 to change or adjust the operation of the infusion device 102, 202 to affect fluid delivery in a personalized manner. In the exemplary embodiment described herein, the historical patient data is used to develop a pharmacokinetic / pharmacodynamic (PK / PD) model for an individual patient supported by the patient monitoring system 500. For example, in one embodiment, for each individual patient, a "digital twin" containing a patient-specific PK / PD model and a fixed profile of meal absorption rate that varies over time (as identified from the patient's historical data) is generated, and the digital twin is used to personalize the infusion device settings for the individual patient. In this context, a digital twin is a mathematical model or simulation of an individual patient that includes a set of differential equations derived from the patient's historical data, which collectively define or describe the patient's blood glucose response to carbohydrate intake and insulin delivery. In this regard, the resulting patient-specific PK / PD model for the digital twin represents a model that best fits the patient's historical sensor blood glucose measurement data during the evaluation period used to generate the model. The "output" of the digital twin is a predicted blood glucose level or profile in combination with various patient-specific parameter values ​​associated with the model, based on "inputs" that may affect the patient's glycemic state, such as the amount of insulin delivered, the amount of carbohydrate consumed, etc. For example, each digital twin may be associated with a personalized and patient-specific set of values ​​for various closed-loop control parameters (e.g., PID gain coefficient values, PID time constants, basal insulin delivery rate, carbohydrate ratio, insulin sensitivity factor, target blood glucose value, etc.), which may be unique to each individual patient.

[0067] Depending on the embodiment, the digital twin may be updated periodically (e.g., daily, weekly, etc.), at predetermined time intervals, or in response to new or updated patient data (e.g., new or more recent sensor blood glucose measurement data samples, insulin delivery amounts, meal event log data, etc.) uploaded to the remote server 514 and / or database 516. Additional details on the development of digital twins are provided in U.S. patent application No. 16 / 386,104, filed on April 16, 2019 and incorporated herein by reference in its entirety. As described in more detail below, in one or more exemplary embodiments, a cloud-based digital twin for an individual patient is managed and / or maintained by a remote server 514 and / or database 516 and is used to automatically configure and adjust the settings, gains, and parameters of the infusion device 502 for the patient. That is, in alternative embodiments where the infusion device has sufficient processing power, the generation, updating, and management of the digital twin may be implemented at the infusion device 502, rather than a cloud-based implementation.

[0068] Situational Control Adjustment

[0069] Reference now Figures 6 to 7 In an exemplary embodiment, in response to detecting a particular operating context, control parameters utilized by an autonomous operating mode of an infusion device are automatically adjusted in real time and for a temporary duration in a personalized manner to affect fluid delivery during or around that operating context to mitigate or otherwise reduce the likelihood of an undesirable or abnormal physiological state. In this regard, the subject matter described herein illustrates so-called "hot spots" where other control personalizations or optimizations such as those described above cannot fully prevent recurring abnormal physiological states. For example, a local control algorithm implemented by an infusion device may be stateless or otherwise lack the data, capability, or intelligence to account for recurring "hot spot" scenarios, which may cause patients to disproportionately experience or exhibit abnormal physiological states, conditions, or events at particular times of the day or other operating contexts.

[0070] Exemplary embodiments are described herein primarily in the context of adjusting a target (or reference) glucose value utilized by a closed-loop operating mode (e.g., a value at input 402 of closed-loop control system 400); however, the subject matter described herein is not limited to closed-loop control targets or closed-loop operating modes, and other control parameters or other autonomous operating modes may be implemented in an equivalent manner. For example, in response to detecting a particular operating context during operation in an open-loop operating mode, a basal rate setting utilized by an open-loop operating mode that periodically and autonomously delivers fluid according to the basal rate setting to achieve a desired basal infusion rate may similarly be adjusted in real time.

[0071] Figure 6 An exemplary adjustment determination process 600 is depicted for identifying an operating scenario in which a patient exhibits some recurring physiological abnormality and determining a corresponding control adjustment to alleviate the physiological abnormality or otherwise reduce the likelihood of recurrence. The various tasks performed in conjunction with the adjustment determination process 600 may be performed by hardware, firmware, software executed by processing circuitry, or any combination thereof. For purposes of illustration, the following description relates to the above-described embodiments in conjunction with the present invention. Figures 1 to 5 For purposes of explanation, the adjustment determination process 600 may be described herein primarily in the context of being implemented at the remote server 514 in the patient monitoring system 500. It should be understood that the adjustment determination process 600 may include any number of additional or alternative tasks, that the tasks need not be performed in the order depicted and / or that the tasks may be performed simultaneously, and / or that the adjustment determination process 600 may be incorporated into a more comprehensive program or process having additional functionality not described in detail herein. Figure 6 One or more of the tasks shown and described in the context of FIG. 60 may be omitted from an actual implementation of the adjustment determination process 600 as long as the intended overall functionality remains intact.

[0072] Depending on the embodiment, the adjustment determination process 600 may be performed on a periodic basis (e.g., daily, weekly, etc.), at a predetermined time of day (e.g., during an overnight period), in response to manually initiating an update to his or her infusion device, or in response to more recent or updated patient data being available (e.g., in response to a batch of updated measurement and delivery data being uploaded from the infusion device to a remote server and / or database). The adjustment determination process 600 receives or otherwise obtains patient data related to previous operation of the patient's infusion device and analyzes the patient's historical measurement data to detect or otherwise identify patterns of specific abnormal physiological events within the historical measurement data and operational contexts associated with the occurrence of the detected abnormalities (tasks 602, 604, 606). For example, the patient's infusion device 502 and / or client device 506 may upload recent sensor glucose measurement data, insulin delivery data, event log data, context data, etc. to the remote device 514 in order to update the personal historical patient data maintained in the database 516. Thereafter, the remote device 514 analyzes the patient's historical sensor glucose measurement data to detect event patterns within the historical sensor glucose measurement data that are associated with the particular operational context.

[0073] In one or more embodiments, the sensor glucose measurements can be assigned to different operational context groups, and then abnormal blood glucose states or conditions are analyzed. For example, the sensor glucose measurements can be classified into different monitoring cycles based on the timestamps associated with those values ​​that fall within the time period associated with each monitoring cycle (e.g., the measurements with timestamps between 12 noon and 3 p.m. can be classified as the post-lunch monitoring cycle). In addition, the sensor glucose measurements can be further classified into different groups based on the time of day or other contextual data of the same period as the corresponding sensor glucose measurements. For example, sensor glucose measurements with substantially the same or common geographic location data associated therewith (e.g., measurements within a threshold distance from the patient's home) can be grouped into specific operational contexts associated with the geographic location. Similarly, sensor glucose measurements with substantially the same or common lifestyle activities associated therewith can be grouped together. Various embodiments may also analyze the patient's meal data, event log data, auxiliary measurement data (e.g., from the sensing arrangements 206, 208), etc. to categorize or classify the sensor glucose measurements into different operational contexts corresponding to different lifestyle events or activities (e.g., mealtime, post-meal, sleep, exercise, stress, menstruation, etc.). In this regard, the present subject matter is not limited to any particular number, logic, or manner for categorizing or classifying a patient's historical sensor glucose measurement data into different operational context groups based on any number or combination of simultaneous or concurrent auxiliary measurement data, delivery data, location data, meal data, exercise data, event log data, or other contextual data indicative of concurrent patient behavior, activity, or contextual state.

[0074] In such embodiments, after the sensor measurements are classified into one or more operating context groups, the sensor measurements within each operating context group can be analyzed for various event detection criteria to identify event patterns associated with the corresponding group. For example, the sensor measurements can be compared with the glucose threshold to identify the number of times or cumulative durations that the sensor measurements violate the glucose threshold during the monitoring period, and when the number or duration is greater than the corresponding detection threshold, the corresponding event pattern can be detected. For example, when the sensor measurements fall below a lower glucose threshold (e.g., 70 mg / dL) during more than 50% of the days or instances of a specific operating context, a hypoglycemia (or low glucose) event pattern can be identified. Similarly, when the sensor measurements are above an upper glucose threshold (e.g., 150 mg / dL) for a duration greater than a specific number or with sufficient frequency, a hyperglycemia (or high glucose) event pattern can be identified. In this regard, it should be noted that any number of different detection thresholds can be used to detect event patterns with desired severity and / or frequency, and the subject matter described herein is not intended to be limited to any specific threshold or logic for detecting or identifying event patterns associated with different operating contexts. Additionally, it should be noted that other glucose measurement indicators (e.g., sensor glucose measurement rate of change values, etc.) may be assigned to different operating scenario groups and abnormal blood glucose states or conditions analyzed in an equivalent manner, and that the subject matter described herein is not limited to any particular type of sensor glucose measurement data for analysis.

[0075] In other embodiments, machine learning or artificial intelligence can be applied to the patient's historical data to identify the correlation between a specific physiological state or condition and a corresponding context variable. For example, remote server 514 can utilize machine learning to determine which combination of historical delivery data, historical auxiliary measurement data (e.g., historical acceleration measurement data, historical heart rate measurement data, etc.), historical event log data, historical geolocation data, and other historical or context data is related to or predicts the occurrence of a specific blood sugar state, condition, or event, and identifies the degree or correlation between those variables and the blood sugar state. In some embodiments, remote server 514 can determine the equation, function, or model for calculating the possibility or probability of a specific blood sugar state based on a group of relevant input context variables. Therefore, a specific combination of auxiliary measurement data, delivery data, geographic location, patient behavior, or activity, etc. can be mapped to a specific blood sugar state. It should be noted that the context variables that predict a specific patient or are related to a specific patient can be different from other users. It should also be noted that the remote device 514 can utilize any number of different machine learning techniques to determine which combinations of contextual variable states are predictive for the patient currently of interest, such as artificial neural networks, linear models, general linear models, generalized linear models, search trees, genetic programming, support vector machines, Bayesian networks, probabilistic machine learning models or other Bayesian techniques, fuzzy logic, heuristic deduction combinations, and the like.

[0076] In the illustrated embodiment, after identifying a correlation between an operating scenario and a recurring abnormal blood glucose state or condition, the adjustment determination process 600 continues with the steps of: identifying an adjusted control parameter value to compensate for the abnormal blood glucose state; generating a simulated glucose curve for the patient using the adjusted control parameter value and recent patient data for the relevant operating scenario; and determining whether the simulated glucose curve exhibits an abnormal blood glucose state or condition (tasks 608, 610, 612). In this regard, the adjustment determination process 600 can repeat the loop defined by tasks 608, 610, and 612 to iteratively adjust the control parameter value until the resulting simulated glucose curve does not exhibit an abnormal blood glucose state or condition. When the adjusted control parameter value adequately compensates for the abnormal blood glucose state or condition, the adjustment determination process 600 assigns or otherwise associates the adjusted control parameter value to the problematic operating scenario for subsequent use during the operating scenario (task 614), as described below. Figure 7 The context is described in more detail.

[0077] For example, as described above, in one or more embodiments, the remote server 514 establishes or otherwise creates a model associated with the patient that can be used to generate a simulated glucose curve for the patient based on the patient's historical event log data (e.g., recent meal data, exercise information, sleep information, etc.). In conjunction with the adjustment determination process 600 in the context of a closed-loop operating mode, the remote server 514 can adjust the closed-loop control target value (e.g., the patient's target glucose at input 402 or the set point of the closed-loop mode) for use during a period of the patient's historical data, where the operating scenario is associated with a recurrent abnormal blood glucose state or condition. For example, in an exemplary embodiment where a digital twin is maintained for a patient (e.g., in a database 516), the remote server 514 utilizes a specific PK / PD model for the patient to generate a predicted sensor glucose measurement value, which is obtained from a simulated operation of the patient's infusion device 502 using the adjusted closed-loop control target value during a time period corresponding to the problematic operating scenario using the patient's historical meal data, exercise data, bolus data, sleep data, etc. In this regard, in some embodiments, when an abnormal glycemic state or condition occurs, predicted sensor glucose measurements are determined using the patient's historical meal data, exercise data, bolus data, sleep data, etc. for previous instances of the operational scenario in question to determine whether an adjusted closed-loop control target value is likely to be sufficient to alleviate or prevent the abnormal glycemic state or condition.

[0078] For example, for a patient who exhibits a pattern of hyperglycemic events during the post-lunch period between 2pm and 3pm, the patient's personalized PK / PD model can be used to simulate what the patient's sensor glucose measurements during the previous operating instances between 2pm and 3pm might have been using the temporarily reduced closed-loop control target value during the period between 2pm and 3pm and the patient's historical meal data, exercise data, bolus data, sleep data, etc. associated with those previous operating instances between 2pm and 3pm. In this regard, if the simulated glucose curve remains below the hyperglycemic threshold, or does not otherwise exhibit a pattern of hyperglycemic events, the reduced closed-loop control target value can be assigned or otherwise associated with the operating scenario between 2pm and 3pm. For example, the reduced closed-loop control target value can be stored or maintained in a lookup table that maintains an association between the problematic operating scenario and its assigned temporary control parameter adjustment for the corresponding operating mode. Conversely, if the simulated glucose curve with the reduced closed-loop control target still exhibits a hyperglycemic event pattern, the adjustment determination process 600 can continue to reduce the closed-loop control target value and generate an updated simulated glucose curve using the updated closed-loop control target value until the simulated glucose curve remains below the hyperglycemic threshold or does not exhibit a hyperglycemic event pattern. In this regard, the adjustment determination process 600 can iteratively increase or decrease the closed-loop control target value by a fixed percentage (e.g., 5%) or a fixed amount (e.g., 5 mg / dL) until a simulated glucose curve indicating that an abnormal blood glucose state may be alleviated is reached. In a similar manner, for open-loop mode, the adjustment determination process 600 can iteratively increase or decrease the basal rate setting by a fixed percentage or a fixed amount until the resulting simulated glucose curve does not exhibit abnormal blood glucose.

[0079] It should be noted that in some embodiments, the adjustment determination process 600 can generate multiple different simulated glucose curves for multiple different control parameter adjustments, and apply a cost function or perform some other optimization to identify the optimal adjustment value of the control parameter. For example, a cost function can be constructed so that the resulting cost is affected by the relationship between the simulated glucose value and the target glucose value, the duration of the simulated glucose value within the expected value range (e.g., within a certain threshold of the normal target or original target glucose value), the amount of insulin delivered using the adjusted control parameter value, etc. The adjustment determination process 600 can then select or otherwise identify the potential adjusted closed-loop control target that achieves the minimum cost from a subset of potential closed-loop control targets that fully alleviate or reduce the possibility of recurrence of abnormal blood glucose states as the optimal closed-loop control target to be assigned to a specific problematic operating scenario. Therefore, the resulting adjusted closed-loop control target can not only alleviate or reduce the possibility of recurrence of a specific blood glucose event pattern, but the closed-loop control target can also optimize insulin delivery or some other aspects of blood glucose control during the specific operating scenario.

[0080] Figure 7 Depicted with Figure 6 The present invention relates to an exemplary contextual adjustment process 700 for autonomously operating an infusion device in connection with the adjustment determination process 600 of FIG. 1 to temporarily adjust control parameters to mitigate or otherwise reduce the likelihood of recurrence of physiological abnormalities during a particular operating context. The various tasks performed in connection with the contextual adjustment process 700 may be performed by hardware, firmware, software executed by processing circuitry, or any combination thereof. For purposes of illustration, the following description relates to the contextual adjustment process 700 described above in connection with FIG. Figures 1 to 5 For purposes of explanation, the contextual adjustment process 700 may be described herein primarily in the context of being implemented at an infusion device 102, 202, 502. It should be understood that the contextual adjustment process 700 may include any number of additional or alternative tasks, that the tasks need not be performed in the order depicted and / or that the tasks may be performed simultaneously, and / or that the contextual adjustment process 700 may be incorporated into a more comprehensive program or process having additional functionality not described in detail herein. Furthermore, the contextual adjustment process 700 may be omitted from an actual embodiment of the contextual adjustment process 700. Figure 7 One or more tasks are shown and described in the context of the invention so long as the intended overall functionality remains intact.

[0081] In an exemplary embodiment, the context adjustment process 700 is implemented or otherwise performed by the control system 220, 300, 522 at the infusion device 102, 202, 502 after the remote server 514 executes the adjustment determination process 600 to identify problematic operating scenarios and corresponding control adjustments for the patient. For example, after the remote server 514 executes the adjustment determination process 600 to identify different operating scenarios that may be problematic for the patient and determines and assigns corresponding control adjustments to these operating scenarios, the remote device 514 may push, transmit, or otherwise provide indications of these operating scenarios and their associated operating modes and control parameter adjustments to the infusion device 102, 202, 502, either directly over the network 512 or via an intermediate client device 506. For example, a lookup table of operating scenarios and control parameter adjustments may be pushed or otherwise provided to the infusion device 102, 202, 502 for local storage (e.g., in a memory 306, 524). In other embodiments, the infusion device 102, 202, 502 may attempt to download or otherwise obtain the identified problematic operating scenarios and determined control parameter adjustments associated with a particular operating mode from the remote device 514 and / or database 516 upon entering that operating mode.

[0082] The context adjustment process 700 begins by autonomously operating the infusion device to deliver fluid according to normal control parameters for the autonomous operating mode (task 702). For example, in the closed-loop operating mode, the pump control system 220, 300 can periodically determine a dose command based on the difference between the patient's current or real-time sensed glucose measurement from the interstitial glucose sensing arrangement 204, 504 provided at input 404 and the normal target glucose value at input 402 according to the closed-loop control system 400, which can be manually set by the patient or determined based on the patient's historical data as described above. Similarly, in the open-loop operating mode, the pump control system 220, 300 can periodically provide a dose command corresponding to the normal or default basal rate setting of the open-loop operating mode, which can similarly be manually set by the patient or determined based on the patient's historical data.

[0083] The context adjustment process 700 continuously monitors or analyzes the current operating context to detect or otherwise identify when the current operating context corresponds to a previously problematic operating context that had adjusted control parameters assigned or otherwise associated therewith (tasks 704, 706). In this regard, the pump control system 220, 300 may continuously monitor, in substantially real time, the current time of day, the current day of the week, the current geographic location, auxiliary measurement data from various other sensing arrangements 206, 208, meal or other bolus guidance data, activity or event log data, etc. to identify or otherwise determine whether the current or most recent combination of context variable states matches or otherwise corresponds to a previously problematic operating context for the patient. In the event that no potentially problematic operating context is identified, the context adjustment process 700 maintains autonomous operation according to normal or default control parameters (task 702).

[0084] In response to detecting or otherwise determining that the current operating context matches or otherwise corresponds to a potentially problematic operating context, the context adjustment process 700 automatically changes the implementation of the autonomous operating mode to temporarily utilize an adjusted control parameter value assigned to or otherwise associated with the operating context (task 708). In this regard, the pump control system 220, 300 can utilize a lookup table to identify the adjusted control parameter value associated with a particular combination of context variables corresponding to the current operating context. For example, if the pump control system 220, 300 autonomously operates the infusion device 102, 202, 502 in the closed-loop operating mode for a patient who previously exhibited a pattern of hyperglycemic events between 2 p.m. and 3 p.m., while in the closed-loop operating mode, in response to detecting that the current time of day is between 2 p.m. and 3 p.m., the pump control system 220, 300 can automatically retrieve or otherwise obtain the adjusted closed-loop control target associated with the 2 to 3 p.m. time period and utilize the reduced closed-loop control target glucose value at the input 402 instead of the normal target glucose value or set point. For example, the target glucose value at input 402 may be adjusted from a normal value of 120 mg / dL to 100 mg / dL. As a result, the closed-loop control system 400 will determine a larger dose command (or increase in basal delivery rate) that would be achieved relative to the normal target glucose value for the same sensed glucose measurement provided at input 404, thereby reducing the likelihood or severity of any hyperglycemic events.

[0085] As another example, for a patient who has previously exhibited a pattern of hypoglycemic events during exercise of a particular duration or intensity level, the pump control system 220, 300 may automatically detect exercise of that duration or intensity based on a combination of acceleration measurement data from the acceleration sensing arrangement 208 and heart rate measurement data from the heart rate sensing arrangement 206. In response, the pump control system 220, 300 may automatically retrieve or otherwise obtain an adjusted closed-loop control target associated with the duration or intensity of the exercise and replace the normal target glucose value or set point with the increased closed-loop control target glucose value at input 402. For example, the target glucose value at input 402 may be adjusted from a normal value of 120 mg / dL to 150 mg / dL, which results in the closed-loop control system 400 determining a reduced dose instruction (or reduced basal delivery rate) that would be achieved relative to the normal target glucose value for the same sensed glucose measurement value provided at input 404, thereby reducing the likelihood or severity of any hyperglycemic event.

[0086] It should be noted that the contextual adjustment process 700 can also be implemented in an equivalent manner for an open-loop operating mode. For example, for a patient who previously exhibited a pattern of hyperglycemic events between 2 p.m. and 3 p.m. in an open-loop operating mode, in response to detecting that the current time of day is between 2 p.m. and 3 p.m., the pump control system 220, 300 can automatically retrieve or otherwise obtain an adjusted basal rate associated with the 2 to 3 p.m. time period and utilize the increased basal rate in place of the normal or default basal rate, thereby reducing the likelihood or severity of any hyperglycemic events. Similarly, in response to detecting a particular type of motion for which the patient has previously exhibited a pattern of hypoglycemic events, the pump control system 220, 300 can automatically retrieve or otherwise obtain an adjusted basal rate associated with the detected motion and utilize the reduced basal rate in place of the normal or default basal rate, thereby reducing the likelihood or severity of any hypoglycemic events.

[0087] It should be noted that, relative to the situation of utilizing normal or default control parameters, any different number or combination of context variables can be utilized to identify or otherwise distinguish problematic operating situations. For example, if the patient only exhibits a hypoglycemic event pattern related to exercise at a specific time (e.g., between 9 am and 12 pm) of a specific day of the week (e.g., Saturday), as long as the current time is not between 9 am and 12 pm, and the current day of the week is not Saturday, even if a specific exercise duration, intensity or type is detected, the pump control system 220, 300 will also maintain normal closed-loop control parameters. In this way, the combination of adjustment determination process 600 and context adjustment process 700 allows the autonomous operating mode to automatically adapt to the specific operating situation that has problems with the patient before but has certain limitations on its duration or frequency, so that the personalization of control parameters (e.g., PID gain coefficient value, PID time constant, basal insulin delivery rate, carbohydrate ratio, insulin sensitivity factor, target glucose value) may not be able to solve such limited scenarios. Therefore, potential abnormal blood sugar events can be automatically alleviated or prevented without any manual intervention.

[0088] Still reference Figure 7In the illustrated embodiment, the context adjustment process 700 continuously monitors or analyzes the current operating context to detect or otherwise identify when the current operating context no longer corresponds to the previously problematic operating context before returning to normal control parameters (tasks 704, 706, 708). In this regard, the adjusted control parameters may be temporarily maintained until the operating context changes. For example, if the patient has previously exhibited a pattern of hyperglycemic events between 2 p.m. and 3 p.m., the pump control system 220, 300 may maintain the adjusted closed-loop control target associated with the 2 p.m. to 3 p.m. time period at input 402 until the current time of day is after 3 p.m., at which time the pump control system 220, 300 may automatically restore the control target at input 402 to a normal target glucose value or set point. Similarly, if the patient previously exhibited a pattern of hypoglycemic events during or around a particular exercise event, the pump control system 220, 300 may maintain an increased closed-loop control target value at input 402 for a specific amount of time (which may be determined based on the patient's historical data) after the duration of the exercise or exercise event has passed, and then the control target at input 402 may be automatically restored to a normal target glucose value or set point. In other embodiments, the patient's sensor glucose measurement (and / or rate of change thereof) may be continuously monitored while utilizing the adjusted closed-loop control target until the patient's sensor glucose measurement meets one or more criteria for restoring to normal control parameters. For example, the pump control system 220, 300 may monitor the patient's sensor glucose measurement to detect or otherwise identify when the patient's sensor glucose measurement is within a threshold of a normal closed-loop control target or otherwise within a desired range of values ​​and / or the patient's sensor glucose rate of change is less than a threshold amount. Thus, the context adjustment process 700 may dynamically restore to normal operation in response to real-time detection that certain criteria are met.

[0089] For the sake of brevity, other functional aspects of the known techniques and themes related to blood glucose sensing and / or monitoring, bolus injection, closed-loop blood glucose control, patient modeling, cost functions, optimization and related mathematical concepts may not be described in detail herein. In addition, certain terms may also be used herein only for reference purposes, and are therefore not intended to be restrictive. For example, unless clearly indicated by the context, the terms "first", "second" and other such numerical terms referring to structures do not imply order or sequence. The foregoing description may also relate to elements or nodes or features that are "connected" or "coupled" together. As used herein, unless otherwise expressly stated, "connection" refers to an element / node / feature that is directly or indirectly and not necessarily mechanically joined to another element / node / feature (or directly or indirectly communicated with another element / node / feature).

[0090] Although at least one exemplary embodiment has been presented in the foregoing detailed description, it should be understood that there are a large number of variations. It should also be understood that one or more exemplary embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. More specifically, the foregoing detailed description will provide a convenient guide for implementing one or more of the described embodiments to those skilled in the art. It should be understood that various changes may be made to the function and arrangement of the elements without departing from the scope defined by the claims, and the scope defined by the claims includes known equivalents and foreseeable equivalents at the time of filing this patent application.

Claims

1. A processor-implemented method, comprising: causing delivery of a fluid to a patient based on a first value of a control parameter; identifying a second value for the control parameter based on determining that the current operating scenario is associated with the second value; and Replacing the first value of the control parameter based on the second value of the control parameter causes the fluid to be delivered to the patient.

2. The method according to claim 1, further comprising: After causing delivery of the fluid to the patient based on the second value, causing delivery of the fluid to the patient based on the first value instead of the second value.

3. The method of claim 2, wherein causing delivery of the fluid to the patient based on the first value instead of the second value comprises: A first value for the control parameter is identified based on determining that the current operating scenario has changed.

4. The method of claim 1, wherein the control parameter is a target value used by a closed-loop control system.

5. The method of claim 1, wherein the control parameter is a basal rate setting used in an open loop mode of operation of the fluid delivery device. The method of claim 1 , wherein the current operating context comprises a time of day. The method of claim 1 , wherein the current operating context includes an activity level of the patient.

8. A system comprising: one or more processors; and One or more processor-readable storage media storing instructions that, when executed by the one or more processors, cause the following operations to be performed: causing delivery of a fluid to a patient based on a first value of a control parameter; identifying a second value for the control parameter based on determining that the current operating scenario is associated with the second value; and Replacing the first value of the control parameter based on the second value of the control parameter causes the fluid to be delivered to the patient.

9. The system of claim 8, wherein the one or more processor-readable storage media further stores instructions that, when executed by the one or more processors, cause execution of: After causing delivery of the fluid to the patient based on the second value, causing delivery of the fluid to the patient based on the first value instead of the second value.

10. The system of claim 9, wherein causing delivery of the fluid to the patient based on the first value instead of the second value comprises: A first value for the control parameter is identified based on determining that the current operating scenario has changed.

11. The system of claim 8, wherein the control parameter is a target value used by a closed-loop control system.

12. The system of claim 8, wherein the control parameter is a basal rate setting used in an open loop mode of operation of the fluid delivery device.

13. The system of claim 8, wherein the current operating context includes a time of day.

14. The system of claim 8, wherein the current operating context includes an activity level of the patient.

15. A method comprising: causing delivery of a fluid to a patient based on a first value of a control parameter; determining an abnormal physiological condition of the patient; and In response to determining the abnormal physiological condition, delivery of a fluid to the patient is caused based on a second value of the control parameter.

16. The method of claim 15, wherein the control parameter is a glucose target value. The method of claim 16 , wherein the second value of the control parameter is higher than the first value of the control parameter.

18. The method of claim 15, wherein the abnormal physiological condition comprises a detected hypoglycemic event.

19. The method of claim 15, wherein the fluid is delivered to the patient using closed loop control of an infusion set.

20. A system comprising: one or more processors; and One or more processor-readable storage media storing instructions that, when executed by the one or more processors, cause the following operations to be performed: causing delivery of a fluid to a patient based on a first value of a control parameter; determining an abnormal physiological condition of the patient; and In response to determining the abnormal physiological condition, delivery of a fluid to the patient is caused based on a second value of the control parameter.

Images