CN113646847A - Personalized closed loop optimization system and method - Google Patents

Abstract

A medical device system, and associated method of automatically adjusting a control parameter of a medical device, is disclosed. One method involves: obtaining data regarding a physiological condition of a patient during operation of the medical device according to an operating mode; determining a plurality of adjustment values for the control parameter based at least in part on the data; determining, using a cost function, a respective cost associated with each respective adjustment value for the control parameter based at least in part on the data; identifying an optimized value among the plurality of adjustment values from among the plurality of adjustment values, wherein the optimized value has a minimum cost associated therewith among a plurality of costs; and updating the control parameter at the medical device to the optimized value.

Description

Personalized closed loop optimization system and method

Technical Field

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 infusion devices for diabetes therapy management.

Background

The pancreas of a normal, healthy person produces insulin in response to elevated plasma glucose levels and releases it into the bloodstream. Beta cells (beta-cells) in the pancreas produce and secrete insulin into the blood stream as needed. If the beta cells lose function or die, a condition known as type I diabetes (or in some cases, type II diabetes if the beta cells produce insufficient amounts of insulin), insulin must be provided to the body from another source. In the united states alone, diabetes affects about 8% of the general population.

Traditionally, insulin has been injected using a syringe because it cannot be taken orally. The use of infusion pump therapy has increased, particularly for delivering insulin to diabetic patients. For example, an external infusion pump is worn on a belt, a pocket, etc., and insulin is delivered into the body through an infusion tube with a percutaneous needle or a catheter placed in the subcutaneous tissue. Physicians have recognized that continuous infusion may provide better control of the condition of diabetic patients, and are increasingly also being used by patients.

Patient-related data and pump-related data may be collected during operation of the insulin infusion pump for subsequent review and analysis. For example, glucose sensor data, insulin delivery data, and/or other data generated or collected by the infusion pump may be analyzed in an appropriate manner to determine whether changes to one or more settings of the infusion device need to be suggested. Accordingly, various settings of the infusion device may be adjusted in a patient-specific manner to improve and optimize the treatment of the patient (based on the analyzed data).

Disclosure of Invention

Medical devices and related systems and methods of operation are provided. An embodiment of a method of automatically adjusting control parameters for an operating mode of a medical device involves: obtaining data regarding a physiological condition of a patient during operation of the medical device according to an operating mode; determining a plurality of adjustment values for the control parameter based at least in part on the data; determining, using a cost function, a respective cost associated with each respective adjustment value for the control parameter based at least in part on the data; identifying an optimized value among the plurality of adjustment values from among the plurality of adjustment values, wherein the optimized value has a minimum cost associated therewith among the plurality of costs; and updating the control parameter at the medical device to an optimized value.

In another embodiment, a patient monitoring system is provided. The patient monitoring system comprises: a medical device to adjust a physiological condition of a patient according to an operating mode based at least in part on a control parameter; and a remote device to obtain patient data regarding operation of the medical device; determining a plurality of adjustment values for the control parameter based at least in part on the patient data; determining, using a cost function, a respective cost associated with each respective adjustment value of a plurality of adjustment values for a control parameter based at least in part on patient data, thereby yielding a plurality of costs; identifying an optimized value from among a plurality of adjustment values based on a plurality of costs, the optimized value having a minimum cost associated therewith; and updating the control parameter to an optimized value, wherein subsequent operation of the medical device according to the operating mode utilizes the optimized value for the control parameter.

In another embodiment, a method of automatically adjusting a control parameter of an operating mode of an infusion device for regulating a blood glucose level of a patient is provided. The method involves: obtaining patient data including sensed blood glucose measurement data and event log data during an operational period of the infusion device according to an operational mode; and determining a plurality of adjustment values for the control parameter based at least in part on the sensed blood glucose measurement data. For each of a plurality of adjustment values for a control parameter, the method determines a simulated blood glucose profile for the patient corresponding to the operational phase based on the event log data and the respective adjustment value for the control parameter, and determines a respective cost associated with the respective adjustment value for the control parameter based at least in part on the simulated blood glucose profile using an asymmetric cost function. The method continues by: identifying an optimized value among a plurality of adjustment values from among the plurality of adjustment values, wherein the optimized value has a minimum cost associated therewith among a plurality of costs associated with the plurality of adjustment values according to an asymmetric cost function; and updating the control parameter at the infusion device to an optimized value, wherein subsequent operation of the infusion device utilizes the optimized value to generate a dosage command for delivering insulin to the patient.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. 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.

Drawings

A more complete understanding of the subject matter may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures.

Fig. 1 depicts an exemplary embodiment of an infusion system;

FIG. 2 is a block diagram of an exemplary control system suitable for use with a fluid infusion device in one or more embodiments;

FIG. 3 is a block diagram of an exemplary pump control system suitable for use in the infusion device in the control system of FIG. 2 in one or more embodiments;

fig. 4 is a block diagram of a closed-loop control system that may be implemented or otherwise supported by the pump control system in the fluid infusion device of fig. 2-3 in one or more exemplary embodiments;

FIG. 5 is a block diagram of an exemplary patient monitoring system; and is

FIG. 6 is a flow diagram of an exemplary personalized update process suitable for use with a medical device in one or more exemplary embodiments.

Detailed Description

The following detailed description is merely illustrative in nature and is not intended to limit the subject matter or the embodiments of the application or the application and uses of such embodiments. As used herein, the word "exemplary" means "serving as an example (instance), instance (instance), or illustration. Any embodiment described herein as exemplary is not necessarily to be construed as preferred or advantageous over other embodiments. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary or the following detailed description.

Exemplary embodiments of the subject matter described herein are implemented in connection with a medical device, such as a portable electronic medical device. While many different applications are possible, the following description focuses on embodiments that incorporate a fluid infusion device (or infusion pump) 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) therapy protocol or other medical device, 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 infusion set operation, and other functional aspects of the systems (and the individual operating components of the systems) may not be described in detail herein. Examples of infusion pumps may be of the type described in, but not limited to, the following U.S. patents: 4,562,751 No; 4,685,903 No; 5,080,653 No; 5,505,709 No; 5,097,122 No; U.S. Pat. No. 6,485,465; 6,554,798 No; 6,558,320 No; 6,558,351 No; 6,641,533 No; 6,659,980 No; 6,752,787 No; 6,817,990 No; 6,932,584 No; and No. 7,621,893; each of these U.S. patents is incorporated herein by reference.

Generally, fluid infusion devices include a motor or other actuation arrangement operable to displace a plunger (or stopper) or other delivery mechanism to deliver a dose of fluid, such as insulin, from a reservoir provided within the fluid infusion device to the body of a patient. Dose commands governing operation of the motor may be generated in an automated manner according to a delivery control scheme associated with a particular mode of operation, and dose commands may be generated in a manner that is influenced by current (or recent) measurements of physiological conditions of the user's body. For example, in a closed-loop mode of operation, a dose command may be generated based on a difference between a current (or most recent) measurement of interstitial fluid glucose level in the body of the user and a target (or reference) glucose value. In this regard, the infusion rate may fluctuate as the difference between the current measurement and the target measurement fluctuates. For purposes of explanation, the subject matter is described herein in the context of the infused fluid being insulin for regulating glucose levels 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.

Exemplary embodiments of the subject matter described herein generally relate to automatically adjusting control parameters utilized by an operating mode of an infusion device in a personalized manner based on updated patient data captured during previous operation of the infusion device. For example, based on a relationship between blood glucose measurement data of a patient during a previous phase of operation in a respective mode of operation and a target blood glucose value or other reference value or threshold value for that mode of operation, a plurality of different adjustment values for one or more control parameters are identified, resulting in different sets of potential values for the control parameters utilized by the respective mode of operation. For each set of potential control parameter values, event log data (e.g., meal data, exercise data, sleep data, bolus data, etc.) and adjusted control parameter values corresponding to previous operational stages in the respective operational mode are used to determine a corresponding simulated blood glucose profile. One or more cost functions are then applied to each of the simulated blood glucose profiles to determine a respective cost associated with each set of potential control parameter values, which in turn is used to identify an optimized set of adjusted control parameter values that achieves a minimum cost. In this regard, the example embodiments may iteratively determine a cost associated with a set of potential control parameter values, and iteratively determine an adjusted set of potential control parameter values using an optimization method until a minimum cost is reached. Subsequently, the control parameter values for the operating mode are updated to reflect the optimized values, for example, by instructing or otherwise commanding the infusion device to overwrite or otherwise update stored values of the control parameters for the operating mode maintained at the infusion device to reflect the optimized values. As described in more detail below, in one or more exemplary embodiments, the cost function is asymmetric or otherwise disproportionately penalizes hypoglycemic or negative blood glucose excursions exhibited by the simulated blood glucose profile to achieve optimized personalized control parameter adjustments that reduce the risk of hypoglycemia.

For purposes of explanation, the subject matter may be described herein in the context of a diabetes management system that uses a cloud-based architecture to generate and deliver recommendations for adjusting certain settings of an insulin infusion device used by a patient, with most processor-intensive tasks being performed by one or more server systems that are in communication with other devices in the system, such as mobile client devices, portable insulin infusion devices, data sources (e.g., patient-related data, insulin pump data, etc.), and possibly other remote devices. Patient-specific data collected during operation of the patient's insulin infusion device in the automated closed-loop mode is analyzed to determine recommended adjustments to certain settings of the insulin infusion device, which may then in turn be applied during operation of the insulin infusion device in the manual delivery mode.

Overview of infusion System

Fig. 1 depicts an exemplary embodiment of an infusion system 100, including, but 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 the embodiment shown in fig. 1 is not exhaustive or limiting. In practice, as illustrated in fig. 1, the infusion set 102 and the sensing arrangement 104 are fixed at a desired location on the body of the user (or patient). In this regard, the locations at which the infusion set 102 and the sensing arrangement 104 in fig. 1 are secured to the body of the user are provided merely as representative, non-limiting examples. The elements of the infusion system 100 may be similar to those described in U.S. patent No. 8,674,288, the subject matter of which is incorporated herein by reference in its entirety.

In the illustrated embodiment of fig. 1, the infusion device 102 is designed as a portable medical device adapted for infusing fluids, liquids, gels or other medicaments into the body of a user. In an exemplary embodiment, the infused fluid is insulin, although many other fluids may be administered by infusion, such as, but not limited to, HIV drugs, drugs to treat pulmonary hypertension, iron-chelating drugs, analgesic drugs, anti-cancer therapies, drugs, vitamins, hormones, and the like. In some embodiments, the fluid may comprise nutritional supplements, dyes, tracking media, saline media, hydration media, and the like.

The sensing arrangement 104 generally represents a component of the infusion system 100 that is configured to sense, detect, measure, or otherwise quantify a condition of a user, and may include sensors, monitors, or the like for providing data indicative of the condition sensed, detected, measured, or otherwise monitored by the sensing arrangement. In this regard, the sensing arrangement 104 may contain electronics and enzymes that are reactive to a biological condition of the user (e.g., blood glucose level, etc.) and provide data indicative of the blood glucose level to the infusion device 102, the CCD106, and/or the computer 108. For example, the infusion device 102, the CCD106, and/or the computer 108 may include a display for presenting information or data (e.g., a current glucose level of the user, a plot or chart of the user's glucose level versus time, a device status indicator, an alarm message, etc.) to the user based on sensor data received from the sensing arrangement 104. In other embodiments, the infusion device 102, the CCD106, and/or the computer 108 may include electronics and software configured to analyze the sensor data and operate the infusion device 102 to deliver fluid to the body of the user based on the sensor data and/or a preprogrammed delivery routine. Thus, in an exemplary embodiment, one or more of the infusion set 102, the sensing arrangement 104, the CCD106, and/or the computer 108 includes transmitter, 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 set 102, the CCD106, and/or the computer 108.

Still referring to fig. 1, in various embodiments, the sensing arrangement 104 may be secured to or embedded in the body of the user at a location remote from the location at which the infusion device 102 is secured to the body of the user. In various other embodiments, the sensing arrangement 104 may be incorporated within the infusion device 102. In other embodiments, the sensing arrangement 104 may be separate and apart from the infusion device 102 and may, for example, be part of the CCD 106. In such embodiments, the sensing arrangement 104 may be configured to receive a biological sample, analyte, or the like to measure a condition of the user.

In some embodiments, the CCD106 and/or the computer 108 may include electronics and other components configured to perform processing, delivery routine storage, and control the infusion device 102 in a manner that is influenced by sensor data measured by and/or received from the sensing arrangement 104. By including control functions in the CCD106 and/or the computer 108, the infusion set 102 can be made with more simplified electronics. However, in other embodiments, the infusion device 102 may contain all control functions and may operate without the CCD106 and/or the computer 108. In various embodiments, the CCD106 may be a portable electronic device. Additionally, in various embodiments, the infusion set 102 and/or the sensing arrangement 104 may be configured to transmit data to the CCD106 and/or the computer 108 for display or processing of the data by the CCD106 and/or the computer 108.

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

In some embodiments, the sensing arrangement 104 and/or the infusion device 102 are cooperatively configured to utilize a closed-loop system to deliver fluid to a user. Examples of sensing devices and/or infusion pumps utilizing closed loop systems may be found in, but are not limited to, the following: 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, the sensing arrangement 104 is configured to sense or measure a condition of the user, such as blood glucose level or the like. The infusion device 102 is configured to deliver fluid in response to a condition sensed by the sensing arrangement 104. In turn, the sensing arrangement 104 continues to sense or otherwise quantify the current condition of the user, thereby allowing the infusion device 102 to continuously deliver fluid responsive to the condition currently (or most recently) sensed by the sensing arrangement 104 indefinitely. In some embodiments, the sensing arrangement 104 and/or the infusion device 102 may be configured to utilize the closed-loop system only during a portion of the day (e.g., only when the user is asleep or awake).

Fig. 2 depicts an exemplary embodiment of a control system 200 suitable for use with an infusion device 202, such as the infusion device 102 described above. The control system 200 is capable of controlling or otherwise adjusting the physiological condition in the body 201 of the user to a desired (or target) value, or otherwise maintaining the condition within a range of acceptable values in an automated or autonomous manner. In one or more exemplary embodiments, the adjusted condition is sensed, detected, measured, or otherwise quantified by a sensing arrangement 204 (e.g., sensing arrangement 104) communicatively coupled to the infusion device 202. It should be noted, however, that in alternative embodiments, the condition regulated by the control system 200 may be correlated 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 the sensing arrangement 204 being implemented as a glucose sensing arrangement that senses, detects, measures, or otherwise quantifies a glucose level of a patient being regulated in the body 201 of the patient by the control system 200.

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

In the illustrated embodiment, the control system 200 further 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 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 body 201 of the patient to measure characteristics or conditions of the patient (or activities of the patient) that may affect the glucose level or insulin sensitivity of the patient. For example, the heart rate sensing arrangement 206 may be worn on or otherwise associated with the body 201 of the patient to sense, detect, measure, or otherwise quantify the heart rate of the patient, which in turn may be indicative of motion (and intensity thereof) that may affect the glucose level or insulin response of the patient in the body 201. In yet another embodiment, another invasive, interstitial or subcutaneous sensing arrangement 206 may be inserted into the body 201 of the patient to obtain a measurement of another physiological condition that may be indicative of motion (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.

The illustrated control system 200 also includes an acceleration sensing arrangement 208 (or accelerometer), which acceleration sensing arrangement 208 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 be indicative of motion or some other condition in the body 201 that may affect the patient's insulin response. Although the acceleration sensing arrangement 208 is depicted in fig. 2 as being integrated into the infusion device 202, in alternative embodiments, the acceleration sensing arrangement 208 may be integrated with another sensing arrangement 204, 206 on the body 201 of the patient, or the acceleration sensing arrangement 208 may be implemented as a separate, stand-alone component worn by the patient.

In the illustrated embodiment, the pump control system 220 generally represents the electronics and other components of the infusion apparatus 202 that control the operation of the fluid infusion apparatus 202 in a manner that is influenced by sensed glucose values indicative of current glucose levels in the body 201 of the patient in accordance with a desired infusion delivery program. For example, to support the closed-loop operating mode, the pump control system 220 maintains, receives, or otherwise obtains a target or commanded glucose value, and automatically generates or otherwise determines a dose command for operating the actuation arrangement (e.g., motor 232) to displace the plunger 217 and deliver insulin to the patient's body 201 based on the difference between the sensed glucose value and the target glucose value. In other operating modes, the pump control system 220 can generate or otherwise determine dosage commands 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 can store or otherwise maintain the target value, the upper and/or lower glucose limit(s), the insulin delivery limit(s), and/or other glucose threshold value(s) in a data storage element accessible to the pump control system 220. As described in more detail, 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 accounts for possible changes in the patient's glucose level or insulin response caused by meals, exercise, or other activities.

Still referring to fig. 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 CCD106 and/or the computing device 108) or input by the patient via 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, among others. Further, the one or more user interface elements 240 include at least one output user interface element, 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 haptic feedback device, or the like, for providing notifications or other information to the patient. It should be noted that although fig. 2 depicts the one or more user interface elements 240 as being separate from the infusion device 202, in practice, the one or more user interface elements 240 may be integrated with the infusion device 202. Further, in some embodiments, one or more user interface elements 240 are integrated with the sensing arrangement 204 in addition to and/or in lieu of the user interface element(s) 240 being integrated with the infusion device 202. User interface element(s) 240 may be manipulated by the patient to operate infusion device 202 as needed to deliver a correction bolus, adjust target values and/or thresholds, modify a delivery control scheme or mode of operation, and so forth.

Still referring to fig. 2, in the illustrated embodiment, the infusion device 202 includes a motor control module 212 coupled to a motor 232 operable to displace a plunger 217 within the syringe and provide a desired amount of fluid to the body 201 of the patient. In this regard, displacement of the plunger 217 results in delivery of a fluid (e.g., insulin) capable of affecting a physiological condition of the patient to the body 201 of the patient via a fluid delivery path (e.g., via a tube of an infuser). Motor driver module 214 is coupled between energy source 218 and 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 command signals that operate 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 dosage command from the pump control system 220 indicating a desired amount of fluid to be delivered.

In an exemplary embodiment, the energy source 218 is implemented as a battery housed 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 configured to convert or otherwise transform the DC power provided by the energy source 218 into an alternating current signal applied to the stator windings of the motor 232 that causes a current to flow through the respective phases of the stator windings that generates a stator magnetic field and rotates 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 to produce an amount of commanded translational displacement of the plunger 217. For example, the motor control module 212 may determine an amount of rotation of the rotor required to generate a translational displacement of the plunger 217 to achieve a commanded dose received from the pump control system 220. Based on the current rotational position (or orientation) of the rotor relative to the stator, as indicated by the output of the rotor sensing arrangement 216, the motor control module 212 determines an appropriate sequence of alternating current signals to be applied to the stator windings for respective phases of rotation that should rotate the rotor from its current position (or orientation) by the determined amount of rotation. In embodiments where the motor 232 is implemented as a BLDC motor, the alternating current signal reverses the respective phases of the stator windings with the proper orientation of the rotor poles relative to the stator and in the proper sequence to provide a rotating stator magnetic field that rotates the rotor in the desired direction. Thereafter, the motor control module 212 operates the motor driver module 214 to apply the determined alternating current electrical signal (e.g., command signal) to the stator windings of the motor 232 to achieve the desired fluid delivery to the patient.

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 disconnects 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 increasing efficiency.

Depending on the embodiment, the motor control module 212 may be implemented or realized with a general purpose processor, a microprocessor, a controller, a microcontroller, a state machine, a content addressable memory, an application specific integrated circuit, a 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 includes or otherwise accesses 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, a 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.

It should be understood that fig. 2 is a simplified representation of an infusion device 202 for purposes of explanation 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 functions of the sensing arrangement 204 may be implemented by the pump control system 220 or otherwise integrated into the pump control system 220 or vice versa. Similarly, in practice, the features and/or functionality of the motor control module 212 may be implemented by the pump control system 220 or otherwise integrated into the pump control system 220 or vice versa. Further, the features and/or functions 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 CCD106 or the computing device 108).

Fig. 3 depicts an exemplary embodiment of a pump control system 300 suitable for use as the pump control system 220 in fig. 2, in accordance with one or more embodiments. 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, alerts, or other therapy information to the patient.

The communication interface 304 generally represents hardware, circuitry, logic, firmware, and/or other components of the pump control system 300 that are coupled to the pump control module 302 and configured to support communication 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 communication 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 communication to/from the sensing arrangement(s) 204, 206, 208. In various embodiments, the communication interface 304 may also support communication with another electronic device (e.g., the CCD106 and/or the computer 108) in the infusion system (e.g., uploading sensor measurements to a server or other computing device, receiving control information from a server or other computing device, etc.).

The pump control module 302 generally represents hardware, circuitry, logic, firmware, and/or other components of the pump control system 300 coupled to the communication interface 304 and 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 the exemplary embodiment, the pump control module 302 implements or otherwise executes a command generation application 310 that supports one or more autonomous operating modes and calculates or otherwise determines a dosage command for operating the motor 232 of the infusion apparatus 202 in the autonomous operating mode based at least in part on a current measurement of a condition in the body 201 of the patient. For example, in the closed-loop operating mode, the command generation application 310 may determine a dose command for operating the motor 232 to deliver insulin to the body 201 of the patient to adjust the blood glucose level of the patient to the target reference glucose value based at least in part on the current glucose measurement value most recently received from the sensing arrangement 204. Further, command generation application 310 may generate a dosage command for a bolus that is manually initiated or otherwise indicated by the patient via a user interface element.

In an exemplary embodiment, the pump control module 302 also implements or otherwise executes a personalization application 308, the personalization application 308 cooperatively configured to interact with the command generation application 310 to support deciding to adjust the dose commands or control information in which the dose commands are generated in a personalized patient-specific manner-in this regard, in some embodiments, based on a correlation between current or recent measurement data and current operational context relative to historical data associated with the patient, the personalization application 308 may adjust or otherwise modify values of one or more parameters utilized by the command generation application 310 in determining the dose commands, for example, by modifying parameter values at locations in a register or 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 be involved in, and output or otherwise provide an indication of predicted patient behavior, which in turn may then be used to adjust the manner in which the dosage commands are generated to adjust glucose in a personalized manner to account for the predicted behavior of the patient. In some embodiments, the personalization application 308 may support automatically performing personalization adjustments of control parameters utilized by the command generation application 310.

Still referring to fig. 3, depending on the embodiment, the pump control module 302 may be implemented or realized with a general purpose processor, a microprocessor, a controller, a microcontroller, a state machine, a content addressable memory, an application specific integrated circuit, a 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 a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in firmware, in a software module executed by the pump control module 302, or in any practical combination thereof. In an exemplary embodiment, the pump control module 302 includes or otherwise accesses a data storage element or memory 306, which data storage element or memory 306 can be implemented using any kind 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.

It should be understood that fig. 3 is a simplified representation of a pump control system 300 for purposes of explanation and is not intended to limit the subject matter described herein in any way. For example, in some embodiments, features and/or functions 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 the separate motor control module 212 may not be present in embodiments of the infusion device 202.

Fig. 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 appreciated that fig. 4 is a simplified representation of a control system 400 for purposes of explanation and is not intended to limit the subject matter described herein in any way.

In the exemplary embodiment, control system 400 receives or otherwise obtains a target blood glucose value at input 402. In some embodiments, the target blood glucose value may be stored or otherwise maintained by the infusion set 202 (e.g., in the memory 306), however, in some alternative embodiments, the target value may be received from an external component (e.g., the CCD106 and/or the computer 108). In one or more embodiments, the target glucose value may be calculated or otherwise determined based on one or more patient-specific control parameters prior to entering the closed-loop operating mode. For example, the target blood glucose value may be calculated based at least in part on a patient-specific reference basal rate and a patient-specific daily insulin requirement determined based on historical delivery information over a previous time interval (e.g., the amount of insulin delivered over the previous 24 hours). The control system 400 also receives or otherwise obtains a current blood glucose measurement value (e.g., a recently obtained sensor blood glucose value) from the sensing arrangement 204 at input 404. The illustrated control system 400 implements or otherwise provides proportional-integral-derivative (PID) control to determine or otherwise generate a delivery command for operating the motor 232 based at least in part on a difference between a target blood glucose value and a current blood glucose measurement value. 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 a desired value. The PID control parameters are applied to the difference between the target blood glucose level at input 402 and the measured blood glucose level at input 404 to generate or otherwise determine a dosage (or delivery) command provided at 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.

The illustrated control system 400 includes or is otherwise implemented to be configured to determine a target value obtained at input 402 and a measurement obtained from the sensing arrangement 204 at input 404, e.g., by subtracting the target value from the measurement valueA summation block 406 of the differences between the values. The output of the summation block 406 represents the difference between the measured value and the target value, which is then provided to each of the proportional, integral and derivative term paths. The proportional term path includes multiplying the difference by a proportional gain factor K_PTo obtain a gain block 420 for the scale term. The integral term path includes an integration block 408 that integrates the difference and multiplies the integrated difference by an integration gain factor K_ITo obtain a gain block 422 of the integral term. 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 factor K_DTo obtain a gain block 424 of derivative terms. The proportional, integral and derivative terms are then added or otherwise combined to obtain a delivery command at output 430 for operating the motor. Details of various embodiments related to closed-loop PID control and determination of gain coefficients are described in more detail in U.S. patent No. 7,402,153, which is incorporated by reference.

In one or more exemplary embodiments, the PID gain coefficients are patient-specific and are dynamically calculated or otherwise determined prior to entering the closed-loop operating mode based on historical insulin delivery information (e.g., previous dose amounts and/or timing, historical correction bolus information, etc.), historical sensor measurements, historical reference blood glucose measurements, user-reported or user-entered events (e.g., meals, exercise, etc.), and the like. In this regard, one or more patient-specific control parameters (e.g., insulin sensitivity factor, daily insulin demand, insulin limit, reference basal rate, reference fasting glucose, effective insulin action duration, pharmacodynamic time constant, etc.) may be used to compensate for, correct, or otherwise adjust the PID gain factors to account for various operating conditions experienced and/or exhibited by the infusion device 202. The PID gain coefficients may be maintained by a memory 306 accessible to the pump control module 302. In this regard, the memory 306 may contain 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 or otherwise coupled to the summing block 406 at input 402, and similarly, a second parameter register accessed by proportional gain block 420 may store a proportional gain coefficient, a third parameter register accessed by integral gain block 422 may store an integral gain coefficient, and a fourth parameter register accessed by derivative gain block 424 may store a derivative gain coefficient.

Fig. 5 depicts an exemplary embodiment of a patient monitoring system 500. The patient monitoring system 500 includes a medical device 502 communicatively coupled to a sensing element 504 inserted into or otherwise worn by a patient to obtain measurement data (e.g., sensed blood glucose levels) indicative of a physiological condition in the patient's body. Medical device 502 is communicatively coupled to client device 506 through a communication network 510, where client device 506 is communicatively coupled to remote device 514 through 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 fig. 5 depicts a simplified representation of a patient monitoring system 500 for purposes of explanation and is not intended to limit the subject matter described herein in any way.

In an exemplary embodiment, the client device 506 is implemented as a mobile phone, smartphone, tablet computer, or other similar mobile electronic device, however, in other embodiments, the client device 506 may be implemented as any kind of electronic device capable of communicating with the medical device 502 over the network 510, such as a laptop or notebook computer, desktop computer, or the like. 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, network 510 may be implemented as a wireless ad hoc network, a Wireless Local Area Network (WLAN), or a Local Area Network (LAN). Client device 506 contains or is coupled to a display device, such as a monitor, screen, or another conventional electronic display, capable of graphically presenting data and/or information related to a physiological condition of a patient. Client device 506 also includes, or is otherwise associated with, a user input device, such as a keyboard, mouse, touch screen, etc., capable of receiving input data and/or other information from a user of client device 506.

In some embodiments, a user, such as a patient, a doctor of the patient, or another healthcare provider, manipulates a client device 506 to execute a client application 508 that supports communication with the medical device 502 over a 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. Client application 508 generally represents a software module or another feature generated or otherwise implemented by client device 506 to support the processes described herein. Thus, client device 506 typically includes a processing system and data storage elements (or memories) capable of storing programming instructions for execution by the processing system that, when read and executed, cause the processing system to create, generate, or otherwise facilitate client application 508 and to 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 elements or memories may be implemented as Random Access Memory (RAM), Read Only Memory (ROM), flash memory, magnetic or optical mass storage, or any other suitable non-transitory short or long term data storage or other computer readable medium and/or any suitable combination thereof.

In one or more embodiments, client device 506 and medical device 502 establish an association (or pairing) with each other over network 510 to support subsequent establishment of a peer-to-peer communication session between medical device 502 and client device 506 over 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 network identification information for each other). The pairing information obtained during the discovery procedure allows either the medical device 502 or the client device 506 to initiate establishment of a secure communication session over the network 510.

In one or more exemplary embodiments, the client application 508 is also configured to store or otherwise maintain an address and/or other identifying information of the remote device 514 on the second network 512. In this regard, the second network 512 may be physically and/or logically distinct from the network 510, such as the internet, a cellular network, a Wide Area Network (WAN), and so forth. 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 the exemplary embodiment, remote device 514 is coupled to a database 516 that is configured to store or otherwise maintain data associated with individual patients. In practice, the remote device 514 may reside at a physically different and/or separate location from the medical device 502 and the client device 506, such as at a facility owned and/or operated by or otherwise affiliated with the manufacturer of the medical device 502. For purposes of explanation, but not limitation, remote device 514 may alternatively be referred to herein as a server.

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 does not have to rely on a network-based or cloud-based server arrangement, as depicted in fig. 5, but such a 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 act as data sources, data processing units, and/or advice delivery mechanisms. For example, system 500 may include, but is not limited to, any or all of the following elements: a computer device or system; a patient monitor; a healthcare provider system; data communication means, and the like.

Still referring to fig. 5, sensing element 504 generally represents a component of patient monitoring system 500 configured to generate, produce, or otherwise output one or more electrical signals indicative of a physiological condition sensed, measured, or otherwise quantified by sensing element 504. In this regard, the physiological condition of the patient 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 blood glucose sensing element inserted at a location on the patient's body that generates an output electrical signal having a current (or voltage) associated therewith that is related to an interstitial blood glucose level sensed or otherwise measured in the patient's body by the sensing element 504.

The medical device 502 generally represents a component of the patient monitoring system 500 communicatively coupled to an 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 through 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 body of a patient. That is, in other embodiments, the medical device 502 may be a stand-alone sensing or monitoring device (e.g., sensing arrangement 104, 204) separate and independent from an infusion device, such as a continuous blood glucose monitor (CGM), interstitial blood glucose sensing arrangement, or similar device. It should be noted that although fig. 5 depicts the medical device 502 and the sensing element 504 as separate components, in practice, the medical device 502 and the sensing element 504 may be integrated or otherwise combined to provide an overall device that may be worn by a patient.

In the exemplary embodiment, medical device 502 includes a control module 522, a data storage element 524 (or memory), a communication interface 526, and a user interface 528. The user interface 528 generally represents input user interface elements and/or output user interface elements (e.g., one or more user interface elements 240) associated with the medical device 502. Control module 522 generally represents hardware, circuitry, logic, firmware, and/or other components of medical device 502 that are coupled to sensing element 504 to receive electrical signals output by sensing element 504 and to perform or otherwise support various additional tasks, operations, functions, and/or processes described herein. Depending on the embodiment, control module 522 may be implemented or realized with a general purpose processor, a microprocessor, a controller, a microcontroller, a state machine, a content addressable memory, an application specific integrated circuit, a 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, the control module 522 includes an analog-to-digital converter (ADC) or another similar sampling arrangement that samples or otherwise converts the output electrical signal received from the sensing element 504 into a corresponding digital measurement data value. In other embodiments, the sensing element 504 may be incorporated into an ADC and output a digital measurement.

Communication interface 526 generally represents hardware, circuitry, logic, firmware, and/or other components of medical device 502 that are coupled to control module 522 to output/transmit data and/or information from/to medical device 502 to/from 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) communication.

In an exemplary embodiment, remote device 514 receives measurement data values (e.g., sensor blood glucose measurements, acceleration measurements, etc.) associated with a particular patient obtained using sensing element 504 from client device 506, and remote device 514 stores or otherwise maintains historical measurement data in association with the patient in database 516 (e.g., using one or more unique patient identifiers). Additionally, the remote device 514 may also receive meal data or other event log data from or through the client device 506 that may be entered or otherwise provided by the patient (e.g., through the client application 508) 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, meal data includes, for example, a time or timestamp associated with a particular meal event, meal type, or other information indicative of the content or nutritional characteristics of the meal, as well as 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 base 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 an insulin delivery dose and 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 the particular patient. The remote device 514 may also receive geographic location data and potentially other contextual data associated with the devices 502, 506 from the client device 506 and/or the client application 508 and store or otherwise maintain historical operating 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 circuitry capable of outputting or otherwise providing data characterizing the geographic location of the respective device 502, 506 in real time.

Historical patient data may be analyzed by one or more of the remote device 514, the client device 506, and/or the medical device 502 to alter or adjust the operation of the infusion device 102, 202 to affect fluid delivery in a personalized manner. In the exemplary embodiments described herein, historical patient data is utilized to develop pharmacokinetic/pharmacodynamic (PK/PD) models for individual patients supported by the patient monitoring system 500. For example, in one embodiment, for each individual patient, a "digital twin" is generated that includes a patient-specific PK/PD model and a fixed profile of meal absorption rate over time (as identified from the patient's historical data), and used to personalize the infusion device settings for that individual patient. In this context, a digital twin is a mathematical model or simulation of an individual patient that contains a set of differential equations derived from historical data of the patient that collectively define or describe the patient's glycemic response to carbohydrate intake and insulin delivery. In this regard, the resulting patient-specific PK/PD model for the digital twin represents the model best suited for generating historical sensor blood glucose measurement data for the patient over the evaluation period of the model. The digital twin "output" is a predicted blood glucose level or profile incorporating various patient-specific parameter values associated with the model, based on "inputs" that may affect the patient's blood glucose status, such as the amount of insulin delivered, the amount of carbohydrates consumed, and so forth. 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 rates, carbohydrate ratios, insulin sensitivity factors, target blood glucose values, etc.), which may be unique to each individual patient.

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 remote server 514 and/or database 516. Additional details regarding the development of a digital twin are provided in U.S. patent application No. 16/386,104 filed 2019 on 16/4 and incorporated herein by reference in its entirety. As described in more detail below, in one or more exemplary embodiments, cloud-based digital twins for individual patients are managed and/or maintained by remote server 514 and/or database 516 and are used to automatically configure and adjust settings, gains, and parameters of infusion device 502 for the patient. That is, in an alternative embodiment 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.

Personalized optimization

In an exemplary embodiment, an infusion device is configured to support multiple operating modes in which aspects of fluid delivery are automatically and/or autonomously controlled and managed using patient-specific parameter values stored or otherwise maintained at the infusion device. For example, a dual mode insulin infusion device is capable of operating in: a manual insulin delivery mode in which the infusion device delivers basal insulin according to a preprogrammed rate or time-based rate profile and/or other applicable manual mode settings; or an automated closed-loop insulin delivery mode, in which the infusion device utilizes an applicable closed-loop setting to affect the manner in which basal insulin delivery is automatically adjusted based on the relationship between the measured blood glucose value and the target blood glucose value (or set point), as described above. That is, it should be appreciated that the subject matter described herein is not limited to any particular type or number of operating modes supported by the infusion device.

As described in U.S. patent application No. 15/960,495, incorporated herein by reference, the total basal insulin delivered daily tends to reach better levels after a period of operation in closed loop mode due to the constant adjustment of insulin delivery by the feedback controller. Thus, the efficacy of the preprogrammed base rates and other parameter values for various operating mode settings may diminish over time for a variety of reasons. Accordingly, in the exemplary embodiments described herein, the personalized infusion device settings are dynamically updated to achieve a better result for the patient in response to updated patient data collected or otherwise obtained during operation of the infusion device. In this regard, one or more cost functions may be used to obtain patient-specific values for the operating mode parameters that may enable maximizing an amount of time a patient's blood glucose level is likely to be within a normoglycemic range (e.g., a euglycemic range), minimizing a deviation between the patient's blood glucose level and a target blood glucose level, and minimizing a likelihood, a probability, or a desired relationship between time spent in a hypoglycemic range.

Fig. 6 depicts an exemplary personalized update process 600 for dynamically updating operational mode control parameters in real-time employing patient-specific values based on recent patient data reflecting changes in physiological characteristics of a patient in a continuous manner. The various tasks performed in connection with the personalized update process 600 may be performed by hardware, firmware, software executed by processing circuitry, or any combination thereof. For purposes of illustration, the following description refers to elements mentioned above in connection with fig. 1-5. For purposes of explanation, the personalized update process 600 may be described herein primarily in the context of being implemented at a remote server 514 in the patient monitoring system 500. It should be appreciated that the personalized update process 600 may include any number of additional or alternative tasks, the tasks need not be performed in the illustrated order and/or the tasks may be performed concurrently, and/or the personalized update process 600 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the tasks shown and described in the context of fig. 6 may be omitted from a practical embodiment of the personalization update process 600 as long as the intended overall functionality remains intact.

Depending on the embodiment, the personalized update process 600 may be performed periodically (e.g., daily, weekly, etc.), at predetermined times of day (e.g., during an overnight period), in response to manually initiating an update of his or her infusion device, or in response to the latest or updated patient data being available (e.g., in response to a batch of latest measurement and delivery data being uploaded from the infusion device to a remote server and/or database). The personalized update process 600 receives or otherwise obtains patient data regarding the recent operation of the infusion device of the patient, adjusts or otherwise changes values for one or more control parameters for the purpose of simulating a physiological response of the patient based on the obtained patient data, and generates a simulated blood glucose profile for the patient using the adjusted control parameter values and the recent patient data ( tasks 602, 604, 606). For example, the infusion device 502 and/or client device 506 of the patient may upload recent sensor blood glucose measurement data, insulin delivery data, event log data, etc. to the remote device 514 for the purpose of updating the historical patient data of the individual maintained in the database 516. Subsequently, the remote device 514 builds or otherwise generates a model associated with the patient that can be used to generate a simulated blood glucose profile for the patient based on recent event log data (e.g., recent meal data, exercise information, sleep information, etc.), and then adjusts one or more control parameter values based on a relationship between the simulated blood glucose profile and one or more target blood glucose values (e.g., target blood glucose or set points for the patient for closed-loop mode, hypoglycemic and/or hyperglycemic thresholds, etc.). For example, in an exemplary embodiment where a digital twin for the patient is maintained (e.g., in database 516), remote server 514 utilizes the patient's specific PK/PD model to generate predicted sensor blood glucose measurements for a time period after the digital twin of the patient is generated based on meal data, exercise data, bolus data, sleep data, etc. of the patient that will be generated from the simulated operation of the patient's infusion device 502 using adjusted control parameter values during the time period.

After generating the simulated blood glucose profile for the patient, the personalized update process 600 applies one or more cost functions to the simulated blood glucose profile to calculate or otherwise determine a total cost associated with utilizing the adjusted control parameter values (task 608). As described in more detail below, in an exemplary embodiment, the cost is influenced by the relationship between the simulated blood glucose value and the target blood glucose value, such that adjustments to the control parameter value that reduce the difference between the simulated blood glucose value and the target blood glucose value will have a lower cost associated therewith. After determining the cost associated with a given set of control parameter values, the illustrated personalization update process 600 verifies or otherwise identifies whether the set of control parameter values achieves a minimum cost from among a plurality of potential sets of control parameter values (task 610). In this regard, the tasks of adjusting the control parameter values (task 604), determining the simulated blood glucose profile (task 606), and determining the costs associated with the respective set of adjusted control parameter values (task 608) may be repeated or otherwise performed a plurality of times to obtain different potential sets of adjusted control parameter values and corresponding costs associated therewith. Any number of different multivariate parameter optimization methods can be used to identify a respective set of adjusted control parameter values that are likely or expected to reduce cost, with tasks 604, 606, and 608 being iteratively repeated using the optimization method to adjust one or more control parameter values (task 604) and determine corresponding blood glucose profiles and costs (tasks 606 and 608), which in turn can be utilized by the optimization method to iteratively adjust the control parameter values until a minimum cost is obtained. Additionally, in some embodiments, the reference cost associated with a set of control parameter values corresponding to a current infusion device setting may be determined based on recent sensor blood glucose measurement data received by remote device 514 and/or database 516. In such embodiments, if a set of control parameter values corresponding to a current infusion device setting results in a minimum cost, the personalized update process 600 may exit and maintain the current infusion device setting without any adjustment to the infusion device setting.

After identifying the set of control parameter values that yields the minimum cost, the personalized update process 600 updates or otherwise adjusts the infusion set settings to reflect the adjusted control parameter values (task 612). For example, the remote server 514 may push or otherwise transmit commands or instructions to the infusion device 502 and/or the client device 506 indicating the adjusted patient-specific control parameter values to be implemented, which in turn causes the stored values for those operating mode control parameters (e.g., at designated registers or locations in the memory 306) to be updated to the adjusted patient-specific control parameter values. Subsequently, the control system (e.g., command generation application 310 or closed-loop control system 400) of the infusion device 502 automatically references or otherwise utilizes the updated adjusted patient-specific control parameter values when generating dosage commands for operating the infusion device 502 to deliver fluid to the patient.

Still referring to fig. 6, in general, the goal of insulin delivery therapy is to inject the appropriate amount of insulin to regulate the patient's blood glucose level under various circumstances toMaximizing the time spent in the normal range, e.g., 80mg/dL to 150 mg/dL. Additionally or alternatively, the effectiveness of the treatment may be assessed by a mathematical cost function that calculates a cost based on the extent to which the patient's blood glucose profile deviates from a control goal or other reference value (e.g., the midpoint of the range of normal blood glucose). For example, the cost associated with a blood glucose profile that deviates from a target may be determined using a first equation (alternatively referred to herein as equation 1):

wherein BG_kIndividual blood glucose samples representing a blood glucose profile, TG representing a reference or target blood glucose value, n representing the total number of blood glucose samples considered, and f being the total cost associated with the blood glucose profile. Alternatively, the cost may be determined using the equation (equation 2):

in some embodiments, the cost function may be normalized using the normalization factor p using the equation (equation 3):

the normalization factor (p) may be used to normalize the cost to a value between 0 and 1, which may increase accuracy and reduce the number of iterations required to converge to an optimal or minimum cost. In this regard, in some embodiments, the normalization factor (p) may be based on blood glucose levels (BG)_k) But may vary. For example, if the blood glucose profile is associated with a target blood glucose value (BG)_k-TG) is never greater than 100, then the normalization factor may be set to a value of 100 (p-100). In this regard, in some embodiments, p may be set to the maximum difference between the blood glucose profile and the target blood glucose value.

The above cost function is symmetric in that it assigns costs proportionally to both positive and negative deviations with respect to the target blood glucose value. However, in diabetes management treatments, the risk of hypoglycemia is often more alarming than hyperglycemia (e.g., because insulin can be delivered to alleviate hyperglycemia, but cannot be removed from the body to relieve hyperglycemiaTo resolve hypoglycemia). Thus, in an exemplary embodiment, an asymmetric cost function is used to disproportionately assign a larger cost to a negative bias or offset in the blood glucose profile relative to a positive bias. In one or more embodiments, the cost associated with the blood glucose profile of the target bias is determined using the natural log cost function equation (equation 4):

because the natural logarithm of the negative difference is greater than the natural logarithm of the positive difference, the cost function assigns a greater cost to blood glucose samples that are less than the target blood glucose value. For example, a blood glucose is given and targeted (Δ G ═ BG)_K-TG |) of the same magnitude, the cost associated with a positive deviation provided by the numerator of the cost function corresponding to (log (TG + Δ G) -log TG)²And the cost associated with the negative bias provided by the numerator of the cost function corresponds to (log (TG- Δ G) -log TG)². Therefore, the cost of a negative deviation from the target will be greater than the cost of a positive deviation. Thus, in the exemplary embodiment, personalization update process 600 utilizes a natural log cost function to asymmetrically assign costs to a set of adjusted control parameters (e.g., task 608), and thereby identify a set of adjusted control parameters (e.g., task 610) that minimizes the risk of hypoglycemia.

Additionally or alternatively, in some embodiments, the cost function is designed to minimize the time taken below a hypoglycemic threshold or other lower glycemic threshold relative to the amount of time taken within a predefined range of blood glucose values (alternatively referred to as "time within range"). For example, given a series of blood glucose measurements that make up a simulated blood glucose profile, the equation is used:

the percentage of time taken below a hypoglycemic threshold or other lower glycemic threshold (e.g., 70mg/dL) is calculated. In addition, using the equation:

the percentage of time spent within a normal range above the lower glycemic threshold but below the upper glycemic or upper glycemic threshold (e.g., 180mg/dL) is calculated. The percentage spent below the desired range then uses the equation with two factors α and β by the following equation:

to normalize. In this regard, the normalization factor may be adjusted to increase or decrease the cost for violating the hypoglycemic threshold. In an exemplary embodiment, the normalization factors are selected to be a-100 and β -2 to achieve a desired balance between glycemic control efficacy and safety. The equation (equation 5) may then be used in terms of the percentage of time spent below the desired range and the percentage of time spent within the desired range:

in terms of normalized percentage of time spent below the hypoglycemic threshold, or using the equation (equation 6):

the final cost is determined by the percentage of time spent below the hypoglycemic threshold. Where the maximum percentage of time within the range is 100, the number 5 in equations 5 and 6 is the normalization factor representing the ideal maximum of the percentage of time spent below the normal range (e.g., 5%), while the number 110 is the normalization factor selected to maintain the range of values of the cost function between-1 and 1.

It should be noted that any of the above cost functions may be utilized alone or in combination in conjunction with the personalization update process 600 to optimize the personalization control parameter adjustments to achieve the desired cost minimization. For example, for each set of adjusted parameters, the total cost may be determined as a weighted sum of the cost determined using the natural logarithmic cost function (equation 4) and the cost determined based on the percentage of time spent at the range (equation 5 or equation 6), with the weighting factors assigned to the different cost functions being selected to achieve the desired relationship between the magnitude of the deviation (equation 4) and the duration of the deviation (equation 5 or equation 6). In this regard, the weighting factor assigned to the natural log cost function may be increased to penalize deviations from the target blood glucose level, while the weighting factor assigned to times below the range cost function may be increased to penalize extended durations below the hypoglycemic threshold. In this regard, there are any number of different ways in which the cost functions (equations 1-6) may be utilized, alone or in combination, to achieve the desired optimized total cost determination (e.g., at task 608) of personalized control parameter adjustment, and the subject matter described herein is not necessarily intended to be limited to any particular cost function or combination thereof.

In the context of diabetes management, as can be seen from the above examples, there are patient-specific parameters that can be individually or collectively optimized to a set by the system of the present invention. This includes, for example, controller targets and coefficients, adaptive delivery constraints (e.g., insulin limits), lead/feed forward gains (e.g., carbohydrate to insulin ratio, insulin sensitivity factor), effective insulin time, and so forth.

Also, in the context of diabetes management, the system disclosed herein includes an insulin pump having a memory containing patient-specific control parameters (e.g., as mentioned above) and a historical data source regarding past diabetes control. The system includes a processor configured to build a mathematical model of the patient from historical data and optimize control parameters to produce a minimum cost, where the cost is determined to represent a single quantity from the closeness of behavior of model performance to a desired patient performance. The processor then loads the optimized values of the parameters into memory to govern future operation of the pump. The cost as discussed above is derived by averaging the differences between a large number of data points and their corresponding desired values. Although four different cost functions are discussed above: i.e., the linear difference from the target, the squared difference from the target, the difference of the logarithm of the data point and the logarithm of the target, and the time at which the data point is below the hypoglycemic threshold. The cost function thus reduces the complex distribution of blood glucose data values to a single variable representing a "goodness" factor, which can be more easily optimized by standard mathematical techniques.

For the sake of brevity, other functional aspects of well-known techniques and subject matter related to blood glucose sensing and/or monitoring, bolus, closed-loop blood glucose control, patient modeling, cost functions, optimization, and related mathematical concepts may not be described in detail herein. In addition, certain terminology may also be used herein for the purpose of reference only, and is thus not intended to be limiting. For example, the terms "first," "second," and other such numerical terms referring to structures do not imply a sequence or order unless clearly indicated by the context. The foregoing description may also refer to elements or nodes or features being "connected" or "coupled" together. As used herein, unless expressly stated otherwise, "coupled" means that one element/node/feature is directly or indirectly joined to (or directly or indirectly communicates with) another element/node/feature, and not necessarily mechanically.

While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or exemplary embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope defined by the claims, which includes known equivalents and foreseeable equivalents at the time of filing this patent application.

Claims (25)

1. A method of automatically adjusting one or more operating mode control parameters of a medical device, the method comprising:

obtaining data (602) regarding a physiological condition of a patient during operation of the medical device;

for each of the one or more control parameters:

a. determining a plurality of adjustment values for a particular control parameter (604);

b. determining, for each of the plurality of adjustment values for the particular control parameter, a respective cost (608) associated with the respective adjustment value for the control parameter based at least in part on the data using a cost function, resulting in a plurality of costs associated with each of the plurality of adjustment values; and

c. identifying an optimized value (610) among the plurality of adjustment values from among the plurality of adjustment values, wherein the optimized value has a minimum cost associated therewith among a plurality of costs; and

d. updating the particular control parameter at the medical device to the optimized value.

2. The method of claim 1, the data including event log data associated with the patient, the method further comprising determining, for each of the plurality of adjustment values for the control parameter, a simulated profile of the physiological condition of the patient based at least in part on the event log data, wherein determining the respective cost associated with the respective adjustment value for the control parameter comprises determining the respective cost associated with the respective adjustment value for the particular control parameter based at least in part on a relationship between the simulated profile associated with the respective adjustment value and a reference value.

3. The method of claim 2, the reference value comprising a target value for the physiological condition, wherein determining the respective cost associated with the respective adjusted value for the particular control parameter comprises determining the respective cost associated with the respective adjusted value for the particular control parameter based at least in part on a respective difference between a data sample of the simulated profile associated with the respective adjusted value and the target value.

4. The method of claim 3, wherein the respective cost is based at least in part on a square of the respective difference.

5. The method of claim 3 or 4, wherein the respective differences comprise natural logarithms of the respective data samples and natural logarithms of the target values.

6. The method of claim 2, the reference value comprising a lower threshold for the physiological condition, wherein determining the respective cost associated with the respective adjustment value for the control parameter comprises determining the respective cost associated with the respective adjustment value for the control parameter based at least in part on a percentage of data samples of the simulated profile associated with the respective adjustment value that are below the lower threshold.

7. The method of any of claims 3, 4, and 5, wherein the cost associated with the respective adjustment value for the control parameter is further based in part on the relationship between the simulated profile associated with the respective adjustment value and a second reference value, the second reference value comprising a lower threshold for the physiological condition, wherein determining the respective cost associated with the respective adjustment value for the control parameter comprises determining the respective cost associated with the respective adjustment value for the control parameter based at least in part on a percentage of data samples of the simulated profile associated with the respective adjustment value that are below the lower threshold.

8. A method according to any preceding claim, wherein there is more than one said operating mode parameter and steps a to c are repeated successively for each parameter in turn to derive an optimal set of control parameters to update the medical device.

9. The method of any preceding claim, wherein the physiological condition is blood glucose level and the medical device is an insulin infusion pump.

10. The method of claim 9, wherein the operating mode control parameter comprises a gain parameter of a closed-loop PID controller (400).

11. The method of claim 9 or 10, wherein the operating mode control parameter comprises insulin sensitivity of the patient.

12. A patient monitoring system, comprising:

a medical device (502) to adjust a physiological condition of a patient according to an operating mode based on one or more operating mode control parameters, the medical device having a memory holding the one or more operating mode parameters;

a data source (516) containing data collected during operation of the medical device in the operational mode regarding a physiological condition of a patient;

and

a remote device (506, 514) in communication with the medical device and the data source (516), the remote device (506, 514) having processing equipment configured to perform the method of any of claims 1-8;

wherein the medical device has a communication interface (526) and is configured to provide data regarding the operation of the medical device (502) to the remote device (506, 514) and to receive updated control parameters from the remote device (506, 514) for storage in the memory.

13. The patient monitoring system of claim 12, wherein the medical device has a housing and the remote device (506, 514) is housed within the housing of the medical device.

14. The patient monitoring system of claim 12, wherein the remote device (506, 514) comprises a portable mobile phone or a portable health monitor.

15. The patient monitoring system according to any one of claims 12, 13 or 14, wherein the remote device (506, 514) is coupled to an external database (516) that includes the data source and contains historical event log data for the patient.

16. The patient monitoring system of any one of claims 12-15, the medical device comprising an insulin infusion device, and the physiological condition being a blood glucose level of the patient.

17. The patient monitoring system according to any one of claims 12 to 16, wherein the medical device (502) is coupled to a sensor (504) and configured to function as a PID controller (400) in a closed-loop operating mode, the operating mode parameter being a gain factor of the PID controller.

18. A method of automatically adjusting a control parameter of an operating mode of an infusion device that regulates a blood glucose level of a patient, the method comprising:

obtaining patient data (602) including sensed blood glucose measurement data and event log data during an operational period of the infusion device according to the operational mode;

optionally determining a plurality of adjustment values for the control parameter based at least in part on the sensed blood glucose measurement data (604);

for each of the plurality of adjustment values for the control parameter:

determining a simulated blood glucose profile for the patient corresponding to the operational period based on the event log data and the respective adjustment value for the control parameter (606); and

determining respective costs associated with the respective adjustment values for the control parameters based at least in part on the simulated blood glucose profile using a cost function (608);

identifying an optimized value (610) among the plurality of adjustment values from among the plurality of adjustment values, wherein the optimized value has a minimum cost associated therewith among a plurality of costs associated with the plurality of adjustment values according to the cost function; and

updating the control parameter at the infusion device to the optimized value (612), wherein subsequent operation of the infusion device utilizes the optimized value to generate a dosage command for delivery of insulin to the patient.

19. The method of claim 18, wherein determining the respective costs associated with the respective adjustment values for the control parameters based at least in part on the simulated blood glucose profile using an asymmetric cost function (608) comprises determining the respective costs based on respective differences between natural logarithms of data samples of the simulated blood glucose profile and target blood glucose values.

20. The method of claim 18, wherein determining the respective cost (608) associated with the respective adjustment value for the control parameter based at least in part on the simulated blood glucose profile using an asymmetric cost function comprises determining the respective cost associated with the respective adjustment value for the control parameter based at least in part on a percentage of data samples of the simulated blood glucose profile that are less than a hypoglycemic threshold.

21. The method of claim 18, 19 or 20, further comprising the step of repeating the method with one or more additional operating mode parameters to provide a set of optimized control parameters.

22. The method of claim 21, wherein the mode is closed loop and the control parameter is a gain of a PID controller (400) in the loop.

23. An infusion system (500), comprising:

an infusion device (502) for infusing insulin into a patient, the infusion device having a memory (524)

And configured to infuse the insulin according to an operating mode based on operating mode control parameters contained in the memory (524);

a patient data source (516) comprising sensed blood glucose measurement data and event log data collected during an operational period of the infusion device (502) according to the operational mode;

a processing device (506, 514) coupled to the infusion apparatus (502) and the patient data source (516) and configured to perform the method according to any one of claims 18 to 22;

the system (500) is configured such that the step of obtaining patient data (602) obtains the data from the source (502) and the step of updating the control parameter (612) places a new value of the control parameter into the memory (524).

24. The infusion system of claim 23, wherein the processing device is a mobile phone or a portable health monitoring device.

25. The infusion system of claim 23 or 24, wherein the patient data source is a database running on a server.

Images