Analyte sensor quality metric and related therapy action for automated therapy agent delivery systems

Abstract

A method of controlling operation of a medical device that regulates delivery of a fluid medicament to a user is disclosed. The method obtains a current sensor-generated value indicative of a physiological characteristic of the user and resulting from operation of a continuous analyte sensor device. The method proceeds by calculating a sensor quality metric indicative of a reliability and a confidence of the current sensor-generated value, adjusting a therapeutic action of the medical device in response to the calculated sensor quality metric to configure a quality-specific operating mode of the medical device, managing generation of user alerts at the medical device in response to the calculated sensor quality metric, and regulating delivery of the fluid medicament from the medical device in accordance with the current sensor-generated value and the quality-specific operating mode of the medical device.

Description

Technical Field

[0001] Implementations of the topics described herein generally relate to systems for delivering therapeutic agents (e.g., medications) to users. More specifically, the topics described herein relate to the user interface and quality control features of insulin infusion systems that obtain glucose readings from continuous glucose sensors. Background Technology

[0002] Medical therapeutic delivery systems, such as fluid infusion pumps, used to deliver or dispense medications like insulin or other prescribed drugs to patients are relatively well-known in the medical field. A typical infusion pump includes a pump drive system that typically comprises a small motor and drive components that convert the rotational motion of the motor into translational displacement of a plunger (or plug) in a fluid reservoir, delivering the drug from the reservoir to the patient's body via a fluid path formed between the reservoir and the patient's body. The use of infusion pump therapy has been increasing, particularly for delivering insulin to diabetic patients.

[0003] Control protocols have been developed to allow insulin infusion pumps to monitor and regulate patients' blood glucose levels in a largely continuous and autonomous manner. In addition to variations in individual patient insulin response and potential other factors, changes in patients' daily activities (e.g., exercise, carbohydrate consumption, etc.) complicate the management of blood glucose levels in patients with diabetes. Some control protocols may attempt to proactively account for daily activities to minimize glucose drift. Simultaneously, patients may manually initiate insulin delivery before or at the same time as meals (e.g., mealtime bolus or corrective bolus) to prevent spikes or fluctuations in blood glucose levels that might otherwise occur due to the imminent consumption of carbohydrates and the response time of the control protocol. Summary of the Invention

[0004] This document discloses a method for controlling the operation of a medical device that regulates the delivery of a fluid drug to a user. One embodiment of the method involves: receiving meter-generated values ​​indicating a user's physiological characteristics, the meter-generated values ​​being generated in response to operation of an analyte meter; and obtaining sensor-generated values ​​indicating a user's physiological characteristics, the sensor-generated values ​​being generated in response to operation of a continuous analyte sensor device different from the analyte meter. When a valid meter-generated value is available, the medical device is operated in a first mode to display the valid meter-generated value on a user monitoring screen and a therapeutic delivery control screen of the medical device, and the medical device is operated in the first mode to calculate a therapeutic dose for delivery based on the valid meter-generated value. When a valid meter-generated value is unavailable and the current sensor-generated value of the sensor meets a first quality criterion, the medical device is operated in a second mode to display the current sensor-generated value on the user monitoring screen and the therapeutic delivery control screen, and the therapeutic dose for delivery is calculated based on the current sensor-generated value. When a valid instrument value is unavailable and the current sensor value meets the second quality standard but not the first quality standard, the medical device is operated in the third mode to display the current sensor value on the user monitoring screen, disable the display of the current sensor value on the therapeutic delivery control screen, and disable the use of the current sensor value to calculate the therapeutic dose for delivery.

[0005] This document also discloses a medical device for regulating drug delivery to a user. One embodiment of the medical device includes: a drive system; at least one processor device that regulates the operation of the drive system to deliver a fluid drug from the medical device; a display device; and at least one memory element associated with the at least one processor device and storing processor-executable instructions that can be configured to be executed by the at least one processor device to perform a method for controlling the operation of the medical device. One embodiment of the method involves: receiving meter-generated values ​​indicating a user's physiological characteristics, the meter-generated values ​​being generated in response to operation of an analyte meter device; and obtaining sensor-generated values ​​indicating a user's physiological characteristics, the sensor-generated values ​​being generated in response to operation of a continuous analyte sensor device different from the analyte meter device. When the meter-generated values ​​are available, the medical device is operated in a first mode to display valid meter-generated values ​​on a user monitoring screen and a therapeutic drug delivery control screen on the display device, and to calculate a therapeutic drug dose for delivery based on the valid meter-generated values. When a valid meter-generated value is unavailable and the current sensor-generated value meets the first quality standard, the medical device operates in a second mode to display the current sensor-generated value on both the user monitoring screen and the therapeutic delivery control screen, and calculates the therapeutic dose for delivery based on this current sensor-generated value. When a valid meter-generated value is unavailable and the current sensor-generated value meets the second quality standard but not the first quality standard, the medical device operates in a third mode to display the current sensor-generated value on both the user monitoring screen and the therapeutic delivery control screen, prohibits the display of the current sensor-generated value on the therapeutic delivery control screen, and prohibits the use of the current sensor-generated value to calculate the therapeutic dose for delivery.

[0006] This document also discloses a non-transitory computer-readable storage medium including program instructions stored thereon, wherein the program instructions are configured to cause at least one processor device to perform a method involving: receiving a meter-generated value indicating a user's physiological characteristics, the meter-generated value being generated in response to operation of an analyte meter device; and obtaining a sensor-generated value indicating the user's physiological characteristics, the sensor-generated value being generated in response to operation of a continuous analyte sensor device different from the analyte meter device. When a valid meter-generated value is available, the method operates the medical device in a first mode to display the valid meter-generated value on a user monitoring screen and a therapeutic delivery control screen of the medical device, and operates the medical device in the first mode to calculate a therapeutic dose for delivery based on the valid meter-generated value. When a valid meter-generated value is unavailable and the current sensor-generated value meets a first quality criterion, the method operates the medical device in a second mode to display the current sensor-generated value on the user monitoring screen and the therapeutic delivery control screen, and operates the medical device in the second mode to calculate a therapeutic dose for delivery based on the current sensor-generated value instead of the meter-generated value. When a valid instrument value is unavailable and the current sensor value meets the second quality standard but not the first quality standard, the method operates the medical device in a third mode to display the current sensor value on the user monitoring screen, operates the medical device in the third mode to prevent the display of the current sensor value on the therapeutic delivery control screen, and operates the medical device to prevent the use of the current sensor value to calculate the therapeutic dose for delivery.

[0007] This document also discloses a method for controlling the operation of a medical device that regulates the delivery of fluid medication to a user. The method involves: obtaining current sensor-generated values ​​indicative of the user's physiological characteristics, the current sensor-generated values ​​being generated in response to operation of a continuous analyte sensor device; calculating a sensor quality metric indicative of the reliability and confidence of the current sensor-generated values; adjusting therapeutic actions of the medical device in response to the calculated sensor quality metric to configure a quality-specific operating mode of the medical device; managing the generation of user alarms at the medical device in response to the calculated sensor quality metric; and regulating the delivery of fluid medication from the medical device based on the current sensor-generated values ​​and the quality-specific operating mode of the medical device.

[0008] This document also discloses a medical device for regulating drug delivery to a user. The medical device includes: a drive system; at least one processor device that regulates the operation of the drive system to deliver a fluid drug from the medical device; a user interface; and at least one memory element associated with the at least one processor device and storing processor-executable instructions that can be configured to be executed by the at least one processor device to perform a method for controlling the operation of the medical device. One embodiment of the method involves: obtaining a current sensor-generated value indicating a user's physiological characteristics, the current sensor-generated value being generated in response to operation of a continuous analyte sensor device; receiving or calculating a sensor quality metric indicating the reliability and confidence of the current sensor-generated value; adjusting therapeutic actions of the medical device in response to the calculated sensor quality metric to configure a quality-specific operating mode of the medical device; managing the generation of user alerts at the user interface in response to the calculated sensor quality metric; and regulating the delivery of the fluid drug from the medical device based on the current sensor-generated value and the quality-specific operating mode of the medical device.

[0009] This paper also discloses a method for evaluating the operational quality of a continuous analyte sensor device. One embodiment of the method involves: obtaining a current sensor-generated value indicating a user's physiological characteristics, the current sensor-generated value being generated in response to the operation of the continuous analyte sensor device; calculating a sensor quality metric indicating the reliability and confidence of the current sensor-generated value, wherein the calculation is based on information generated by or derived from the continuous analyte sensor device; and formatting the sensor quality metric to be compatible with a fluid drug delivery device, such that the therapeutic actions of the fluid drug delivery device are adjusted in response to the calculated sensor quality metric, and such that the positivity of the fluid drug therapy provided by the fluid drug delivery device is proportional to the quality of the current sensor-generated value as indicated by the calculated sensor quality metric.

[0010] This synopsis is provided to introduce, in a simplified form, a series of concepts further described in the detailed embodiments described below. This synopsis is not intended to identify the principal or essential features of the claimed subject matter, nor is it intended to help determine the scope of the claimed subject matter. Attached Figure Description

[0011] A more complete understanding of the subject matter can be obtained by taking into consideration the following figures, with reference to the detailed description and claims, wherein similar reference numerals refer to similar elements throughout the figures.

[0012] Figure 1 An exemplary implementation of the infusion system is described;

[0013] Figure 2Describing applicable Figure 1 A plan view of an exemplary embodiment of the fluid delivery device for the delivery system;

[0014] Figure 3 yes Figure 2 Exploded perspective view of a fluid delivery device;

[0015] Figure 4 It is when the reservoir is assembled with the infusion device, as along Figure 3 The line 4-4 viewed Figure 2-3 A cross-sectional view of a fluid delivery device;

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

[0017] Figure 6 In one or more embodiments, it is suitable for use in Figure 5 A block diagram of an exemplary pump control system used in the infusion equipment of an infusion system;

[0018] Figure 7 In one or more exemplary embodiments, it can be provided by Figures 5 to 6 A block diagram of a closed-loop control system implemented or otherwise supported by the pump control system in a fluid delivery device;

[0019] Figure 8 This is a block diagram of an exemplary patient monitoring system;

[0020] Figure 9 This is a flowchart illustrating an exemplary implementation of a process for operating a medical device such as an insulin infusion device;

[0021] Figure 10 This is a flowchart illustrating the operation of the insulin infusion device in a first mode;

[0022] Figure 11 This is a schematic diagram of the user monitoring screen on an insulin infusion device, which displays the blood glucose (BG) value generated by the meter;

[0023] Figure 12 This is a schematic diagram of the therapeutic delivery control screen on an insulin infusion device, which displays the BG value;

[0024] Figure 13 This is a flowchart illustrating the operation of the insulin infusion device in the second mode;

[0025] Figure 14 This is a schematic diagram of the user monitoring screen on an insulin infusion device, showing the glucose (SG) value generated by the sensor;

[0026] Figure 15 This is a schematic diagram of the therapeutic delivery control screen on an insulin infusion device, which displays the SG value;

[0027] Figure 16 This is a flowchart illustrating the operation of an insulin infusion device in third mode;

[0028] Figure 17 This is a schematic diagram of the therapeutic delivery control screen on an insulin infusion device, which displays neither the BG value nor the SG value.

[0029] Figure 18 This is a flowchart illustrating an exemplary embodiment of a method for controlling the operation of a medical device to adjust therapeutic actions based on sensor quality;

[0030] Figure 19 This is a block diagram illustrating the generation of a sensor quality metric according to an exemplary embodiment; and

[0031] Figure 20 This is a flowchart illustrating the operation of an insulin infusion device according to an exemplary embodiment. Detailed Implementation

[0032] The following detailed description is illustrative in nature and is not intended to limit the subject matter or embodiments of this application, or the application and use of such embodiments. As used herein, the word "exemplary" means "serving as an example, instance, or illustration." Any specific implementation described herein as exemplary is not necessarily to be construed as more preferred or advantageous than other specific implementations. Furthermore, one is not to be bound by any express or implied theory presented in the foregoing technical fields, background art, summary of the invention, or the following detailed description.

[0033] Exemplary embodiments of the subject matter described herein are implemented in conjunction with medical devices such as portable electronic medical devices. While many different applications are possible, the following description focuses on embodiments incorporating an insulin infusion device (or insulin pump) as part of an infusion system deployment. For the sake of brevity, this document may not describe in detail conventional techniques related to the operation of the infusion system, the insulin pump, and / or the infusion unit, as well as other functional aspects of the system (and its individual operating components). Examples of infusion pumps may have the type described in, but not limited to, the following U.S. patents: 4,562,751, 4,685,903, 5,080,653, 5,505,709, 5,097,122, 6,485,465, 6,554,798, 6,558,320, 6,558,351, 6,641,533, 6,659,980, 6,752,787, 6,817,990, 6,932,584, and 7,621,893; each of which is incorporated herein by reference.

[0034] Generally, fluid infusion devices include a motor or other actuation device operable to displace a plunger (or stopper) of a fluid reservoir provided in the device to deliver a dose of a fluid medication, such as insulin, to a user's body. The dose command controlling the motor's operation can be generated automatically according to a delivery control scheme associated with a specific operating mode, and the dose command can be generated in a manner influenced by current (or recent) measurements of the user's physiological condition. For example, in closed-loop or automatic operating modes, the dose command can be generated based on the difference between a current (or recent) measurement of interstitial fluid glucose levels in the user's body and a target (or reference) glucose setpoint value. In this regard, the infusion rate can vary with fluctuations in the difference between the current and target measurements. For illustrative purposes, this subject matter is described herein in the context of insulin, used to regulate a user's (or patient's) glucose levels; however, it should be understood that many other fluids can be administered by infusion, and the subject matter described herein is not necessarily limited to use with insulin.

[0035] Insulin infusion pumps may operate in automatic mode, delivering basal insulin at a rate automatically adjusted for the user. While controlling basal insulin delivery in this manner, the pump can also control the delivery of corrective boluses to account for glucose spikes caused by meals, stress, hormonal fluctuations, etc. Ideally, the corrective bolus dose should be accurately calculated and administered to maintain the user's blood glucose within the desired range. Specifically, automatically generated and delivered corrective boluses should safely manage the user's blood glucose levels and keep them above a defined low blood glucose threshold.

[0036] Now go to Figure 1An exemplary embodiment of the infusion system 100 includes, but is not limited to, a fluid infusion device (or infusion pump) 102, a sensing device 104, a command and control device (CCD) 106, and a computer 108. The components of the infusion system 100 can be implemented using different platforms, designs, and configurations, and Figure 1 The embodiments shown are not exhaustive or limiting. In some embodiments, such as Figure 1 As shown, the infusion device 102 and the sensing device 104 are fixed at a desired location on the user's (or patient's) body. In this respect, Figure 1 The placement of the infusion device 102 and sensing device 104 on the user's body is provided only as a representative, non-limiting example. The components of the infusion system 100 may be similar to those described in U.S. Patent 8,674,288, the entire subject matter of which is incorporated herein by reference.

[0037] exist Figure 1 In exemplary embodiments, infusion device 102 is designed as a portable medical device suitable for infusing fluids, liquids, gels, or other agents into a user's body. In an exemplary embodiment, the infused fluid is insulin, but many other fluids can be administered via infusion, such as, but not limited to, HIV drugs, medications for treating pulmonary hypertension, iron chelating agents, analgesics, anticancer drugs, vitamins, hormones, etc. In some embodiments, the fluid may include nutritional supplements, dyes, tracking media, saline media, hydration media, etc.

[0038] Sensing device 104 typically refers to a component of infusion system 100 configured to sense, detect, measure, or otherwise quantify a user's condition, and may include sensors, monitors, etc., for providing data indicative of the condition sensed, detected, measured, or otherwise monitored by the sensing device. In this regard, sensing device 104 may include electronics and enzymes that respond to a user's biological condition, such as blood glucose levels, and provide data indicative of blood glucose levels to infusion device 102, CCD 106, and / or computer 108. For example, infusion device 102, CCD 106, and / or computer 108 may include displays for presenting information or data (e.g., the user's current glucose level, a graph or chart of the user's glucose level over time, device status indicators, alarm messages, etc.) to the user based on sensor data received from sensing device 104. In other embodiments, the infusion device 102, CCD 106, and / or computer 108 may include electronics and software configured to analyze sensor data and operate the infusion device 102 to deliver fluid to a user's body based on the sensor data and / or pre-programmed delivery routines. Therefore, in exemplary embodiments, one or more of the infusion device 102, sensing device 104, CCD 106, and / or computer 108 include transmitters, receivers, and / or other transceiver electronics that allow communication with other components of the infusion system 100, such that the sensing device 104 can transmit sensor data or monitor data to one or more of the infusion device 102, CCD 106, and / or computer 108.

[0039] Still referencing Figure 1 In various embodiments, the sensing device 104 may be attached to or embedded in the user's body at a location remote from where the infusion device 102 is attached to the user's body. In various other embodiments, the sensing device 104 may be incorporated into the infusion device 102. In other embodiments, the sensing device 104 may be separable from and separate from the infusion device 102, and may be, for example, part of a CCD 106. In such embodiments, the sensing device 104 may be configured to receive biological samples, analytes, etc., to measure the user's condition.

[0040] In some embodiments, CCD 106 and / or computer 108 may include electronics and other components configured to perform processing, deliver daily doses, and control infusion device 102 in a manner influenced by sensor data measured by and / or received from sensing device 104. By including control functions in CCD 106 and / or computer 108, infusion device 102 can be made with simplified electronics. However, in other embodiments, infusion device 102 may include all control functions and may operate without CCD 106 and / or computer 108. In various embodiments, CCD 106 may be a portable electronic device. Additionally, in various embodiments, infusion device 102 and / or sensing device 104 may be configured to transmit data to CCD 106 and / or computer 108 for display or processing via CCD 106 and / or computer 108.

[0041] In some embodiments, CCD 106 and / or computer 108 may provide information to the user to facilitate subsequent use of infusion device 102. For example, CCD 106 may provide information to the user to allow the user to determine the rate or dose of a drug to be administered to the user's body. In other embodiments, CCD 106 may provide information to infusion device 102 to autonomously control the rate or dose of a drug administered to the user's body. In some embodiments, sensing device 104 may be integrated into CCD 106. Such embodiments allow the user to assess their condition for monitoring purposes by, for example, providing a blood sample to sensing device 104. In some embodiments, sensing device 104 and CCD 106 may be used to determine the glucose level in the user's blood and / or body fluids without the use or requirement of a wired or cable connection between infusion device 102 and sensing device 104 and / or CCD 106.

[0042] In some embodiments, sensing device 104 and / or infusion device 102 are cooperatively configured to deliver fluid to a user using a closed-loop system. Examples of sensing devices and / or infusion pumps utilizing closed-loop systems can be found, but are not limited to, the following U.S. Patents: 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 2014 / 0066889, all of which are incorporated herein by reference in their entirety. In such embodiments, sensing arrangement 104 is configured to sense or measure a user's condition, such as blood glucose levels. Infusion device 102 is configured to deliver fluid in response to a condition sensed by sensing device 104. Subsequently, the sensing device 104 continues to sense or otherwise quantify the user's current status, thereby allowing the infusion device 102 to continuously deliver fluid indefinitely in response to the status currently (or recently) sensed by the sensing device 104. In some embodiments, the sensing device 104 and / or the infusion device 102 may be configured to utilize the closed-loop system only for a portion of the day, such as only when the user is asleep or awake.

[0043] Figures 2 to 4 An exemplary embodiment of a fluid delivery device 200 (or alternatively, an infusion pump) suitable for use in an infusion system is shown, for example... Figure 1 The infusion device 102 in the infusion system 100. The fluid infusion device 200 is a portable medical device designed to be carried or worn by a patient (or user), and the fluid infusion device 200 may utilize any number of conventional features, components, elements, and characteristics of existing fluid infusion devices, such as some of the features, components, elements, and / or characteristics described in U.S. Patent Nos. 6,485,465 and 7,621,893. It should be understood that... Figures 2 to 4 Some aspects of the infusion device 200 are shown in a simplified manner; in some embodiments, the infusion device 200 may include additional elements, features or components not shown or described in detail herein.

[0044] As in Figures 2 to 3The illustrated embodiment of the fluid infusion device 200, as best shown, includes a housing 202 adapted to house a reservoir 205 containing fluid. An opening 220 in the housing 202 accommodates a fitting 223 (or cap) for the reservoir 205, wherein the fitting 223 is configured to mate with or otherwise intersect with the tubing 221 of the infusion set 225 to provide a fluid path to / from the user's body. In this way, fluid communication is established from the interior of the reservoir 205 to the user via the tubing 221. The illustrated fluid infusion device 200 includes a human-machine interface (HMI) 230 (or user interface) containing elements 232, 234 that can be manipulated by the user to administer fluids (e.g., insulin), change therapy settings, change user preferences, select display features, etc. The infusion device also includes a display device 226 such as a liquid crystal display (LCD) or another suitable display device, which can be used to present various types of information or data to the user, such as, but not limited to: the patient's current glucose level; time; a graph or chart of the patient's glucose level relative to time; device status indicators, etc.

[0045] The housing 202 is formed of a substantially rigid material having a hollow interior 214 adapted therein, in addition to the reservoir 205, to house the electronic assembly 204, sliding member (or slider) 206, drive system 208, sensor assembly 210, and drive system cover member 212, wherein the contents of the housing 202 are surrounded by the housing cover member 216. The opening 220, slider 206, and drive system 208 are coaxially aligned in the axial direction (indicated by arrow 218), thereby facilitating linear displacement of slider 206 in the axial direction 218 by drive system 208 to dispense fluid from reservoir 205 (after reservoir 205 has been inserted into opening 220), wherein sensor assembly 210 is configured to measure the axial force applied to sensor assembly 210 (e.g., a force aligned with axial direction 218) in response to displacement of slider 206 by drive system 208. In various implementations, sensor assembly 210 may be used to detect one or more of the following: mitigating, preventing, or otherwise reducing obstruction in the fluid path of fluid delivery from reservoir 205 to the user's body; when reservoir 205 is emptied; when slider 206 is properly positioned with reservoir 205; when a fluid dose has been delivered; when infusion device 200 is subjected to shock or vibration; when infusion device 200 requires maintenance.

[0046] Depending on the implementation, the fluid-containing reservoir 205 can be implemented as a syringe, vial, infusion device, bag, etc. In some implementations, the infused fluid is insulin, although many other fluids can be administered by infusion, such as, but not limited to, HIV drugs, drugs for treating pulmonary hypertension, iron chelating agents, analgesics, anticancer therapies, drugs, vitamins, hormones, etc. Figures 3 to 4 As clearly shown, reservoir 205 typically includes a reservoir cylinder 219 that contains fluid and is concentrically and / or coaxially (e.g., in the axial direction 218) aligned with slide 206 when reservoir 205 is inserted into infusion device 200. The end of reservoir 205 near opening 220 may include fitting 223 or otherwise engage with fitting that secures reservoir 205 within housing 202 and prevents displacement of reservoir 205 relative to housing 202 in the axial direction 218 after insertion into housing 202. As described above, fitting 223 extends from (or through) opening 220 of housing 202 and engages with conduit 221 to establish fluid communication from the interior of reservoir 205 (e.g., reservoir cylinder 219) to the user via conduit 221 and infusion device 225. The opposite end of the reservoir 205 near the slider 206 includes a plunger 217 (or plug) positioned to push fluid along a fluid path through pipe 221 from the interior of the reservoir 205's container 219 to the user. The slider 206 is configured to be mechanically coupled to or otherwise engaged with the plunger 217, thereby becoming seated with the plunger 217 and / or the reservoir 205. When the drive system 208 is operated to displace the slider 206 in the axial direction 218 toward the opening 220 in the housing 202, fluid is forced out of the reservoir 205 through pipe 221.

[0047] exist Figures 3 to 4In the illustrated embodiment, drive system 208 includes a motor assembly 207 and a drive screw 209. Motor assembly 207 includes a motor coupled to a transmission assembly of drive system 208 configured to convert rotary motor motion into translational displacement of slider 206 in the axial direction 218, thereby engaging and displacing plunger 217 of reservoir 205 in the axial direction 218. In some embodiments, motor assembly 207 may also be powered to translate slider 206 in the opposite direction (e.g., opposite to direction 218) to retract from and / or remove reservoir 205 to allow replacement of reservoir 205. In an exemplary embodiment, motor assembly 207 includes a brushless DC (BLDC) motor having one or more permanent magnets mounted, attached, or otherwise disposed on its rotor. However, the subject matter described herein is not limited to use with BLDC motors, and in alternative embodiments, the motor can be implemented as a solenoid motor, AC motor, stepper motor, piezoelectric track drive, shape memory actuator drive, electrochemical gas battery, thermally driven gas battery, bimetallic actuator, etc. Drive system components may include one or more lead screws, cams, pawls, jacks, pulleys, control rods, clamps, gears, nuts, sliders, bearings, levers, beams, stops, plungers, sliders, brackets, guide rails, bearings, supports, bellows, caps, diaphragms, bags, heaters, etc. In this regard, while the exemplary embodiment of the infusion pump uses a coaxially aligned drive system, the motor may be offset relative to the longitudinal axis of the reservoir 205 or arranged in other non-coaxial manner.

[0048] like Figure 4 As best shown, the drive screw 209 engages with a thread 402 inside the slide member 206. When the motor assembly 207 is powered and operated, the drive screw 209 rotates, forcing the slide member 206 to translate in the axial direction 218. In an exemplary embodiment, the infusion device 200 includes a sleeve 211 to prevent the slide member 206 from rotating as the drive screw 209 of the drive system 208 rotates. Thus, rotation of the drive screw 209 causes the slide member 206 to extend or retract relative to the drive motor assembly 207. When the fluid infusion device is assembled and operational, the slide member 206 contacts the plunger 217 to engage the reservoir 205 and control the delivery of fluid from the infusion device 200. In one exemplary embodiment, the shoulder portion 215 of the slide member 206 contacts or otherwise engages the plunger 217 to displace the plunger 217 in the axial direction 218. In an alternative embodiment, the slider 206 may include a threaded tip 213 capable of removably engaging with an internal thread 404 on the plunger 217 of the reservoir 205, as described in detail in U.S. Patent Nos. 6,248,093 and 6,485,465, which are incorporated herein by reference.

[0049] like Figure 3 As shown, the electronics assembly 204 includes control electronics 224 coupled to the display device 226, wherein the housing 202 includes a transparent window portion 228 aligned with the display device 226 to allow the display device 226 to be viewed by a user when the electronics assembly 204 is housed within the interior 214 of the housing 202. The control electronics 224 generally refers to hardware, firmware, processing logic, and / or software (or a combination thereof) configured to control the operation of the motor assembly 207 and / or drive system 208, as described below. Figure 5 The background details are described in more detail below. Control electronics 224 are also suitably configured and designed to support various user interfaces, input / output, and display features of the fluid delivery device 200. Whether such functionality is implemented as hardware, firmware, a state machine, or software depends on the specific application and design constraints imposed on this implementation. Concepts similar to those described herein may be adapted to implement such functionality in a manner suitable for each specific application; however, such specific implementation decisions should not be construed as limiting or restrictive. In an exemplary embodiment, control electronics 224 includes one or more programmable controllers that can be programmed to control the operation of the delivery device 200.

[0050] Motor assembly 207 includes one or more electrical leads 236 adapted to be electrically coupled to electronics 204 to establish communication between control electronics 224 and motor assembly 207. In response to a command signal from control electronics 224 to operate a motor driver (e.g., a power converter) to regulate the amount of electricity supplied to the motor from a power source, the motor actuates the drive system assembly of drive system 208 to displace slider 206 in an axial direction 218, forcing fluid along a fluid path (including tube 221 and infusion device) out of reservoir 205, thereby applying a dose of fluid contained in reservoir 205 to the user's body. Preferably, the power source is implemented as one or more batteries contained within housing 202. Alternatively, the power source may be a solar panel, capacitor, AC or DC power supplied via a power line, etc. In some embodiments, control electronics 224 may operate motor assembly 207 and / or the motor of drive system 208 in a stepwise manner, typically on an intermittent basis; administering separate, precise doses of fluid to the user according to a programmed delivery profile.

[0051] refer to Figures 2 to 4As described above, the user interface 230 includes HMI elements such as buttons 232 and directional keys 234 formed on a graphical keypad cover 231 covering the keypad assembly 233. The keypad assembly includes features corresponding to the buttons 232, directional keys 234, or other user interface entries indicated by the graphical keypad cover 231. When assembled, the keypad assembly 233 is coupled to control electronics 224, thereby allowing the user to manipulate the HMI elements 232, 234 to interact with the control electronics 224 and control the operation of the infusion device 200, such as administering insulin via bolus injection, changing treatment settings, changing user preferences, selecting display features, setting or disabling alarms and alerts, etc. In this regard, the control electronics 224 maintains and / or provides information to the display device 226 regarding program parameters, delivery distribution, pump operation, alarms, warnings, status, etc., which can be adjusted using the HMI elements 232, 234. In various embodiments, HMI elements 232, 234 can be implemented as physical objects (e.g., buttons, knobs, joysticks, etc.) or virtual objects (e.g., graphical user interface elements using touch sensing and / or proximity sensing technologies). For example, in some embodiments, display device 226 can be implemented as a touchscreen or touch-sensitive display, and in such embodiments, the features and / or functions of HMI elements 232, 234 can be integrated into display device 226 and HMI 230 may not be present. In some embodiments, electronic component 204 may also include an alarm generation element coupled to control electronics 224 and suitably configured to generate one or more types of feedback, such as, but not limited to: auditory feedback; visual feedback; tactile (physical) feedback, etc.

[0052] refer to Figure 3-4According to one or more embodiments, the sensor assembly 210 includes a backplate structure 250 and a loading element 260. The loading element 260 is disposed between a cover member 212 and a beam structure 270 comprising one or more beams having sensing elements disposed thereon that are affected by compressive forces applied to the sensor assembly 210 to deflect one or more beams, as described in more detail in U.S. Patent No. 8,474,332, which is incorporated herein by reference. In an exemplary embodiment, the backplate structure 250 is attached, adhered, mounted, or otherwise mechanically coupled to the bottom surface 238 of the drive system 208 such that the backplate structure 250 resides between the bottom surface 238 of the drive system 208 and the housing cover member 216. The profile of the drive system cover member 212 is shaped to adapt to and match the bottom of the sensor assembly 210 and the drive system 208. The drive system cover member 212 can be attached to the interior of the housing 202 to prevent the sensor assembly 210 from displacing in a direction opposite to the force provided by the drive system 208 (e.g., opposite to direction 218). Therefore, the sensor assembly 210 is positioned between the motor assemblies 207 and secured by the cover member 212, which prevents the sensor assembly 210 from displacing in a downward direction opposite to the direction of the arrow representing the axial direction 218, such that the sensor assembly 210 is subjected to a reaction compressive force when the drive system 208 and / or the motor assembly 207 are operated to displace the slider 206 in the axial direction 218 opposite to the fluid pressure in the reservoir 205. Under normal operating conditions, the compressive force applied to the sensor assembly 210 is related to the fluid pressure in the reservoir 205. As shown, electrical leads 240 are adapted to electrically couple the sensing element of sensor assembly 210 to electronics assembly 204 to establish communication with control electronics 224, wherein control electronics 224 is configured to measure, receive, or otherwise acquire electrical signals from the sensing element of sensor assembly 210 indicating the force applied by drive system 208 in axial direction 218.

[0053] Figure 5Exemplary embodiments of an infusion system 500 suitable for use with an infusion device 502 (such as any of the infusion devices 102, 200 described above) are depicted. The infusion system 500 is capable of controlling or otherwise regulating a patient's physiological state within body 501 to a desired (or target) value, or otherwise maintaining that state within an acceptable range, in an automatic or autonomous manner. In one or more exemplary embodiments, the regulated state is sensed, detected, measured, or otherwise quantified by a sensing device 504 (e.g., a glucose sensing device 504) communicatively coupled to the infusion device 502. However, it should be noted that in alternative embodiments, the state regulated by the infusion system 500 may be correlated with the measurement obtained by the sensing device 504. That is, for purposes of clarity and illustration, this subject matter is described in the context of a glucose sensing device that is implemented to sense, detect, measure, or otherwise quantify a patient's glucose level regulated by the infusion system 500 within body 501.

[0054] In an exemplary embodiment, sensing device 504 includes one or more interstitial glucose sensing elements that generate or otherwise output an electrical signal (alternately referred to herein as a measurement signal) having signal characteristics that are correlated with, influenced by, or otherwise indicate a relative interstitial fluid glucose level in a patient's body 501. The output electrical signal is filtered or otherwise processed to obtain a measurement indicating the patient's interstitial fluid glucose level. In an exemplary embodiment, blood glucose meter 530 (such as a fingertip device) is used to directly sense, detect, measure, or otherwise quantify blood glucose in a user's body 501. In this regard, blood glucose meter 530 outputs or otherwise provides a measured blood glucose value that can be used as a reference measurement for calibrating sensing device 504 and converting the measurement indicating the patient's interstitial fluid glucose level into a corresponding calibrated blood glucose value. For illustrative purposes, the calibrated blood glucose value calculated based on the electrical signal output by one or more sensing elements of sensing device 504 may herein be alternatively referred to as a sensor glucose value, a sensed glucose value, or a variation thereof.

[0055] In an exemplary embodiment, the infusion system 500 further includes one or more additional sensing devices 506, 508 configured to sense, detect, measure, or otherwise quantify characteristics of the patient's body 501 that indicate a condition within the patient's body 501. In this regard, in addition to the glucose sensing arrangement 504, one or more auxiliary sensing arrangements 506 may be worn, carried, or otherwise associated with the patient's body 501 to measure patient (or patient activity) characteristics or conditions that may affect the patient's blood glucose levels or insulin sensitivity. For example, a heart rate sensing device 506 may be worn on or otherwise associated with the patient's body 501 to sense, detect, measure, or otherwise quantify the patient's heart rate, which in turn may indicate movement (and its intensity) that may affect the patient's glucose levels or insulin response in the body 501. In yet another embodiment, another invasive, interstitial, or subcutaneous sensing device 506 may be inserted into the patient's body 501 to obtain measurements of another physiological condition that may indicate movement (and its intensity), such as a lactate sensor, a ketone sensor, etc. Depending on the implementation, one or more auxiliary sensing devices 506 may be implemented as stand-alone components worn by the patient, or alternatively, one or more auxiliary sensing devices 506 may be integrated with infusion device 502 or glucose sensing device 504.

[0056] The illustrated infusion system 500 also includes an acceleration sensing device 508 (or accelerometer) that may be worn on or otherwise associated with a patient's body 501 to sense, detect, measure, or otherwise quantify the acceleration of the patient's body 501, thereby indicating movement or other conditions of the body 501 that may affect the patient's insulin response. While the acceleration sensing device 508 is... Figure 5 The acceleration sensing device 508 is shown as being integrated into the infusion device 502, but in an alternative embodiment, the acceleration sensing device 508 may be integrated with another sensing device 504, 506 on the patient's body 501, or the acceleration sensing device 508 may be implemented as a separate, independent component worn by the patient.

[0057] In the illustrated embodiments, the pump control system 520 generally represents the electronics and other components of the infusion device 502 that control the operation of the fluid infusion device 502 in a manner influenced by a sensed glucose value indicative of the current glucose level in the patient's body 501, according to a desired infusion delivery sequence. For example, to support a closed-loop operating mode, the pump control system 520 maintains, receives, or otherwise acquires a target or commanded glucose value and automatically generates or otherwise determines a dose command for operating an actuator such as motor 532 to displace plunger 517 and deliver insulin to the patient's body 501 based on the difference between the sensed glucose value and the target glucose value. In other operating modes, the pump control system 520 may generate or otherwise determine a dose command configured to maintain the sensed glucose value below an upper glucose limit, above a lower glucose limit, or other value within a desired glucose range. In some embodiments, the infusion device 502 may store or otherwise maintain target values, one or more upper and / or lower glucose limits, one or more insulin delivery limits, and / or one or more other glucose thresholds in a data storage element accessible to the pump control system 520. As described in more detail, in one or more exemplary embodiments, the pump control system 520 automatically adjusts or adapts one or more parameters or other control information used to generate commands for operating the motor 532 in a manner that takes into account possible changes in the patient’s glucose level or insulin response caused by eating, exercise or other activities.

[0058] Still referencing Figure 5 The target glucose value and other threshold glucose values ​​can be received from external components (e.g., CCD 106 and / or computing device 108) or input by the patient via a user interface element 540 associated with the infusion device 502 and utilized by the pump control system 520. In some embodiments, one or more user interface elements 540 associated with the infusion device 502 typically include at least one input user interface element, such as a button, keypad, keyboard, knob, joystick, mouse, touch panel, touchscreen, microphone or other audio input device and / or so on. Furthermore, one or more user interface elements 540 include at least one output user interface element for providing notifications or other information to the patient, such as a display device (e.g., a light-emitting diode, etc.), a display device (e.g., a liquid crystal display, etc.), a speaker or other audio output device, a haptic feedback device, etc. It should be noted that, although... Figure 5One or more user interface elements 540 are depicted as separate from the infusion device 502; however, in some embodiments, one or more user interface elements 540 may be integrated with the infusion device 502. Furthermore, in some embodiments, in addition to and / or as an alternative to integration of one or more user interface elements 540 with the infusion device 502, one or more user interface elements 540 are integrated with a sensing device 504. Patients can manipulate one or more user interface elements 540 as needed to operate the infusion device 502 to deliver corrective boluses, adjust target values ​​and / or thresholds, modify delivery control schemes or operating modes, etc.

[0059] Still referencing Figure 5 In the illustrated embodiment, the infusion device 502 includes a motor control module 512 coupled to a motor 532 (e.g., motor assembly 207), operable to displace a plunger 517 (e.g., plunger 217) within a reservoir (e.g., reservoir 205) and deliver a desired amount of fluid to the patient's body 501. In this respect, the displacement of the plunger 517 allows fluids capable of influencing the patient's physiological state (such as insulin) to be delivered to the patient's body 501 via a fluid delivery path (e.g., via conduit 221 of infusion unit 225). A motor drive module 514 is coupled between the power source 518 and the motor 532. Motor control module 512 is coupled to motor driver module 514, and motor control module 512 generates or otherwise provides command signals that operate motor driver module 514 to provide current (or power) from energy source 518 to motor 532 to displace plunger 517 in response to a dosage command received from pump control system 520 indicating the desired amount of fluid to be delivered.

[0060] In an exemplary embodiment, the energy source 518 is implemented as a battery housed within the infusion device 502 (e.g., within the housing 202) that provides direct current (DC) power. In this respect, the motor driver module 514 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 518 into an alternating current signal applied to the stator windings of the motor 532, causing current to flow through the stator windings at appropriate phases, which generates a stator magnetic field and rotates the rotor of the motor 532. The motor control module 512 is configured to receive or otherwise acquire a command dose from the pump control system 520, convert the command dose into a command translational displacement of the plunger 517, and command, signal, or otherwise operate the motor driver module 514 to rotate the rotor of the motor 532 to produce a certain amount of the command translational displacement of the plunger 517. For example, the motor control module 512 may determine the amount of rotor rotation required to produce the translational displacement of the plunger 517 to achieve the command dose received from the pump control system 520. Based on the current rotational positioning (or orientation) of the rotor relative to the stator indicated by the output of the rotor sensing device 516, the motor control module 512 determines the appropriate sequence of alternating current signals of the corresponding phases to be applied to the stator windings to cause the rotor to rotate a determined amount of rotation from its current positioning (or orientation). In an embodiment where the motor 532 is implemented as a BLDC motor, this alternating current signal causes the phases of the stator windings to commutate at the appropriate orientation of the rotor poles relative to the stator and in the appropriate sequence to provide a rotating stator magnetic field that rotates the rotor in the desired direction. The motor control module 512 then operates the motor driver module 514 to apply the determined alternating current signal (e.g., a command signal) to the stator windings of the motor 532 to achieve the desired fluid delivery to the patient.

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

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

[0063] It should be understood that, for the purpose of explanation, Figure 5 This is a simplified representation of the infusion device 502 and is not intended to limit the subject matter described herein in any way. In this regard, depending on the implementation, some features and / or functions of the sensing device 504 may be implemented by or otherwise integrated into the pump control system 520, or vice versa. Similarly, in some implementations, features and / or functions of the motor control module 512 may be implemented by or otherwise integrated into the pump control system 520, or vice versa. Furthermore, features and / or functions of the pump control system 520 may be implemented by control electronics 224 located within the fluid infusion device 502, while in alternative implementations, the pump control system 520 may be implemented by a remote computing device that is physically different from and / or separate from the infusion device 502 (e.g., CCD 106 or computing device 108).

[0064] Figure 6 It is shown that it is suitable for use as one or more embodiments. Figure 5 An exemplary embodiment of the pump control system 600 of the pump control system 520 is shown. The illustrated pump control system 600 includes, but is not limited to, a pump control module 602, a communication interface 604, and a data storage element (or memory) 606. The pump control module 602 is coupled to the communication interface 604 and the memory 606, and the pump control module 602 is suitably configured to support the operations, tasks, and / or processes described herein. In various embodiments, the pump control module 602 is also coupled to one or more user interface elements (e.g., user interfaces 230, 540) to receive user input (e.g., target glucose values ​​or other glucose thresholds) and to provide notifications, alerts, or other therapeutic information to the patient.

[0065] Communication interface 604 typically refers to the hardware, circuitry, logic, firmware, and / or other components of the pump control system 600 coupled to the pump control module 602 and configured to support communication between the pump control system 600 and various sensing devices 504, 506, 508. In this regard, communication interface 604 may include or otherwise coupled to one or more transceiver modules capable of supporting wireless communication between the pump control system 520, 600 and the sensing devices 504, 506, 508. For example, communication interface 604 may be used to receive sensor measurements or other measurement data from each of the sensing devices 504, 506, 508 in the infusion system 500. In other embodiments, communication interface 604 may be configured to support wired communication to / from one or more sensing devices 504, 506, 508. In various implementations, the communication interface 604 may also support communication with another electronic device in the infusion system (e.g., CCD 106 and / or computer 108) (e.g., to upload sensor measurements to a server or other computing device, to receive control information from the server or other computing device, etc.).

[0066] Pump control module 602 generally represents the hardware, circuitry, logic, firmware, and / or other components of pump control system 600 coupled to communication interface 604 and configured to determine a dose command for operating motor 532 to deliver fluid to body 501 based on measurement data received from sensing devices 504, 506, 508, and to perform various additional tasks, operations, functions, and / or functions described herein. For example, in an exemplary embodiment, pump control module 602 implements or otherwise executes command generation application 610, which supports one or more autonomous operating modes and calculates or otherwise determines a dose command for operating motor 532 of infusion device 502 in autonomous operating mode based at least in part on current measurements of the patient's body 501's condition. For example, in closed-loop operating mode, command generation application 610 may determine a dose command for operating motor 532 to deliver insulin to patient body 501 based at least in part on the current glucose measurement recently received from sensing device 504, to adjust the patient's blood glucose level to a target reference glucose value. Additionally, the command generation application 610 can generate dosage commands for push injections that are manually initiated by the patient via user interface elements or otherwise guided.

[0067] In an exemplary embodiment, the pump control module 602 also implements or otherwise executes a personalization application 608, which is cooperatively configured to interact with the command generation application 610 to support adjusting dosage commands or control information, the control commands indicating how dosage commands are generated in a personalized, patient-specific manner. In this regard, in some embodiments, based on the correlation between current or recent measurement data and the current operational context relative to historical data associated with the patient, the personalization application 608 may adjust or otherwise modify the values ​​of one or more parameters utilized by the command generation application 610 when determining the dosage command, for example, by modifying the parameter value at a location in a register or memory 606 referenced by the command generation application 610. In yet other embodiments, the personalization application 608 may predict meals or other events or activities that the patient may participate in and outputs or otherwise provides instructions predicting patient behavior for patient confirmation or modification, which can then be used to adjust the manner in which dosage commands are generated to regulate glucose in a personalized manner that takes patient behavior into account.

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

[0069] It should be understood that, for the purpose of explanation, Figure 6This is a simplified representation of the pump control system 600 and is not intended to limit the subject matter described herein in any way. For example, in some embodiments, the features and / or functions of the motor control module 512 may be implemented by or otherwise integrated into the pump control system 600 and / or pump control module 602, for example, by translating dosage commands into corresponding motor commands via a command generation application 610. In such cases, a separate motor control module 512 may not be present in embodiments of the infusion device 502.

[0070] Figure 7 An exemplary closed-loop control system 700 is illustrated, which can be implemented by pump control systems 520, 600 to provide a closed-loop operating mode that autonomously adjusts the patient's physical condition to reference (or target) values. In this respect, the control system 700 can be used to regulate insulin delivery to the patient during automated basal insulin delivery operations. It should be understood that this is for illustrative purposes and is not intended to limit the subject matter described herein in any way. Figure 7 It is a simplified representation of the control system 700.

[0071] In an exemplary embodiment, the control system 700 receives or otherwise acquires a target glucose value at input 702. In some embodiments, the target glucose value may be stored or otherwise maintained by the infusion device 502 (e.g., in memory 606); however, in some alternative embodiments, the target value may be received from an external component (e.g., CCD 106 and / or computer 108). In one or more embodiments, the target glucose value may be calculated or otherwise determined prior to entering a closed-loop operating mode based on one or more patient-specific control parameters. For example, the target glucose value may be calculated at least in part based on a patient-specific reference basal rate and a patient-specific daily insulin requirement, which are determined based on historical delivery information over previous time intervals (e.g., the amount of insulin delivered in the previous 24 hours). The control system 700 also receives or otherwise acquires a current glucose measurement (e.g., a recently acquired sensor glucose value) from sensing device 504 at input 704. The illustrated control system 700 implements or otherwise provides proportional-integral-derivative (PID) control to determine or otherwise generate a delivery command for operating motor 532 based at least in part on the difference between a target glucose value and a current glucose measurement. In this respect, PID control attempts to minimize the difference between the measured value and the target value, thereby adjusting the measured value to the desired value. PID control parameters are applied to the difference between the target glucose level at input 702 and the glucose level measured at input 704 to generate or otherwise determine a dose (or delivery) command provided at output 730. Based on this delivery command, motor control module 512 operates motor 532 to deliver insulin to the patient's body to affect the patient's glucose level, thereby reducing the difference between the subsequently measured glucose level and the target glucose level.

[0072] The illustrated control system 700 includes, or otherwise implements, a summing block 706 configured to determine the difference between a target value obtained at input 702 and a measurement obtained from sensing device 504 at input 704, for example, by subtracting the target value from the measurement. The output of summing block 706 represents the difference between the measurement and the target value, and this difference is then provided to each of the proportional term path, integral term path, and derivative term path. The proportional term path includes a gain block 720 that multiplies the difference by a proportional gain coefficient KP to obtain the proportional term. The integral term path includes an integration block 708 that integrates the difference and a gain block 722 that multiplies the integrated difference by an integral gain coefficient KI to obtain the integral term. The derivative term path includes a derivative block 710 that determines the derivative of the difference and a gain block 724 that multiplies the derivative of the difference by a derivative gain coefficient KD to obtain the derivative term. The proportional, integral, and derivative terms are then added or otherwise combined to obtain a delivery command for operating the motor at output 730. Various specific implementation details relating to closed-loop PID control and determining the gain coefficients are described in more detail in U.S. Patent 7,402,153, which is incorporated herein by reference.

[0073] In one or more exemplary embodiments, the PID gain coefficient is patient-specific and is dynamically calculated or otherwise determined prior to entering closed-loop operation mode based on historical insulin delivery information (e.g., amount and / or timing of previous doses, historical corrected bolus information, etc.), historical sensor measurements, historical reference blood glucose measurements, user-reported or user-input events (e.g., meals, exercise, etc.). In this regard, one or more patient-specific control parameters (e.g., insulin sensitivity coefficient, daily insulin requirement, insulin limit, reference basal rate, reference fasting blood glucose, duration of action of active insulin, pharmacodynamic time constant, etc.) can be used to compensate, correct, or otherwise adjust the PID gain coefficient to account for various operating conditions experienced and / or exhibited by the infusion device 502. The PID gain coefficient may be maintained by a memory 606 accessible to the pump control module 602. In this respect, the memory 606 may contain multiple registers associated with control parameters used for PID control. For example, the first parameter register may store the target glucose value and be accessed at input 702 by the summing block 706 or otherwise coupled to the summing block, and similarly, the second parameter register accessed by the proportional gain block 720 may store the proportional gain coefficient, the third parameter register accessed by the integral gain block 722 may store the integral gain coefficient, and the fourth parameter register accessed by the derivative gain block 724 may store the derivative gain coefficient.

[0074] In one or more exemplary embodiments, one or more parameters of the closed-loop control system 700 are automatically adjusted or adapted in a personalized manner to account for potential changes in a patient's glucose levels or insulin sensitivity due to meals, exercise, or other events or activities. For example, in one or more embodiments, a target glucose value may be lowered prior to a predicted meal event to increase the insulin infusion rate, thereby effectively pre-injecting the meal and reducing the likelihood of postprandial hyperglycemia. Additionally or alternatively, the time constants or gain coefficients associated with one or more paths of the closed-loop control system 700 may be adjusted to tune the responsiveness to deviations between measured and target glucose values. For example, based on the specific type of meal being consumed or the specific time of day the meal is consumed, the time constants associated with the differential block 710 or differential term path may be adjusted to make the closed-loop control more or less aggressive in response to an increase in the patient's glucose levels, based on the patient's historical glycemic response to a specific meal type.

[0075] Figure 8 An exemplary embodiment of a patient monitoring system 800 is shown. The patient monitoring system 800 includes a medical device 802 communicatively coupled to a sensing element 804, which is inserted into or worn by a patient to obtain measurement data indicative of physiological conditions in the patient's body, such as sensed glucose levels. The medical device 802 is communicatively coupled to a client device 806 via a communication network 810, wherein the client device 806 is communicatively coupled to a remote device 814 via another communication network 812. In this respect, the client device 806 can serve as an intermediary for uploading or otherwise providing measurement data from the medical device 802 to the remote device 814. It should be understood that, for illustrative purposes, Figure 8 A simplified representation of a patient monitoring system 800 is shown and is not intended to limit the subject matter described herein in any way.

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

[0077] In an exemplary embodiment, a user (such as a patient, the patient's doctor, or another healthcare provider) manipulates client device 806 to execute client application 808, which supports communication with medical device 802 via network 810. In this regard, client application 808 supports establishing a communication session with medical device 802 on network 810 and receiving data and / or information from medical device 802 via the communication session. Medical device 802 may similarly execute or otherwise implement a corresponding application or process that supports establishing a communication session with client application 808. Client application 808 generally represents a software module or other feature generated or otherwise implemented by client device 806 to support the processes described herein. Therefore, client device 806 typically includes a processing system and a data storage element (or memory) capable of storing programming instructions for execution by the processing system, which, when read and executed, cause the processing system to create, generate, or otherwise facilitate client application 808 and perform or otherwise support the processes, tasks, operations, and / or functions described herein. Depending on the implementation, the processing system may be implemented using any suitable processing system and / or device, such as one or more processor devices, a central processing unit (CPU), a controller, a microprocessor, a microcontroller, a processing core configured to support the operation of the processing system described herein, and / or other hardware computing resources. Similarly, data storage elements or memory 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-term or long-term data storage or other computer-readable media and / or any suitable combination thereof.

[0078] In one or more embodiments, client device 806 and medical device 802 establish an association (or pairing) with each other via network 810 to support the subsequent establishment of a point-to-point or peer-to-peer communication session between medical device 802 and client device 806 via network 810. For example, according to one embodiment, network 810 is implemented as a Bluetooth network, wherein medical device 802 and client device 806 pair with each other by performing a discovery process or other suitable pairing process (e.g., by obtaining and storing each other's network identification information). The pairing information obtained during the discovery process allows either medical device 802 or client device 806 to initiate the establishment of a secure communication session via network 810.

[0079] In one or more exemplary embodiments, client application 808 is also configured to store or otherwise maintain the address and / or other identifying information of remote device 814 on a second network 812. In this regard, the second network 812 may be physically and / or logically different from network 810, such as the Internet, a cellular network, a wide area network (WAN), etc. Remote device 814 generally refers to a server or other computing device configured to receive and analyze or otherwise monitor measurement data, event log data, and possibly other information for a patient associated with medical device 802. In exemplary embodiments, remote device 814 is coupled to database 816, which is configured to store or otherwise maintain data associated with an individual patient. In some embodiments, remote device 814 may reside in a location physically different from and / or separate from medical device 802 and client device 806, such as at a facility owned and / or operated by or otherwise attached to the manufacturer of medical device 802. For purposes of explanation, but not limitation, remote device 814 may alternatively be referred to herein as a server.

[0080] Still referencing Figure 8 Sensing element 804 generally refers to a component of a patient monitoring system 800 configured to generate, produce, or otherwise output one or more electrical signals indicating a physiological condition sensed, measured, or otherwise quantified by sensing element 804. In this respect, the patient's physiological condition will affect the characteristics of the electrical signals output by sensing element 804, such that the characteristics of the output signals correspond to or are otherwise related to the physiological condition to which sensing element 804 is sensitive. In an exemplary embodiment, sensing element 804 is implemented as an interstitial glucose sensing element inserted at a location on the patient's body, generating an output electrical signal having an associated current (or voltage) related to the interstitial fluid glucose level sensed or otherwise measured in the patient's body by sensing element 804.

[0081] Medical device 802 typically refers to a component of patient monitoring system 800 that is communicatively coupled to the output of sensing element 804 to receive or otherwise obtain measurement data samples (e.g., measured glucose and characteristic impedance values) from sensing element 804, store or otherwise retain the measurement data samples, and upload or otherwise transmit the measurement data to remote device 814 or a server via client device 806. In one or more embodiments, medical device 802 is implemented as infusion devices 102, 200, 502, configured to deliver fluids such as insulin to a patient's body. That is, in other embodiments, medical device 802 may be a separate and independent sensing or monitoring device separate from and independent of the infusion device (e.g., sensing device 104, 504). It should be noted that, although Figure 8 The medical device 802 and the sensing element 804 are depicted as separate components, but in some embodiments, the medical device 802 and the sensing element 804 may be integrated or otherwise combined to provide a whole device that can be worn by a patient.

[0082] In an exemplary embodiment, medical device 802 includes a control module 822, a data storage element 824 (or memory), and a communication interface 826. The control module 822 generally represents the hardware, circuitry, logic, firmware, and / or one or more other components of medical device 802 coupled to sensing element 804 to receive electrical signals output by sensing element 804 and to perform or otherwise support the various additional tasks, operations, functions, and / or processes described herein. Depending on the embodiment, control module 822 may be implemented or carried out using a general-purpose processor device, microprocessor device, controller, microcontroller, state machine, content-addressable memory, application-specific integrated circuit, field-programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. In some embodiments, control module 822 includes an analog-to-digital converter (ADC) or another similar sampling device that samples or otherwise converts the output electrical signals received from sensing element 804 into corresponding digital measurement data values. In other embodiments, sensing element 804 may incorporate an ADC and output digital measurement values.

[0083] Communication interface 826 typically represents the hardware, circuitry, logic, firmware, and / or other components of medical device 802 coupled to control module 822 for outputting data and / or information from medical device 802 to client device 806 / and from said client device to said medical device. For example, communication interface 826 may include or otherwise be coupled to one or more transceiver modules capable of supporting wireless communication between medical device 802 and client device 806. In an exemplary embodiment, communication interface 826 is implemented as a Bluetooth transceiver or adapter configured to support Bluetooth Low Energy (BLE) communication.

[0084] In an exemplary implementation, remote device 814 receives patient-specific measurement data values ​​(e.g., sensor glucose measurements, acceleration measurements, etc.) obtained using sensing element 804 from client device 806, and remote device 814 stores or otherwise maintains historical measurement data in a patient-associated database 816 (e.g., using one or more unique patient identifiers). Additionally, remote device 814 may also receive meal data or other event log data that can be input by the patient or otherwise provided (e.g., via client application 808) from or via client device 806, and store or otherwise maintain patient-associated historical meal data and other historical event or activity data in database 816. In this regard, meal data includes, for example, the time or timestamp associated with a specific meal event, the type of meal or other information indicating the ingredients or nutritional characteristics of the meal, and an indication of the size associated with the meal. In an exemplary embodiment, remote device 814 also receives historical fluid delivery data corresponding to the basal or bolus dose of fluid delivered to a patient by infusion devices 102, 200, and 502. For example, client application 808 may communicate with infusion devices 102, 200, and 502 to obtain insulin delivery doses and corresponding timestamps from them, and then upload the insulin delivery data to remote device 814 for patient-specific storage. Remote device 814 may also receive geolocation data and possibly other background data associated with devices 802 and 806 from client device 806 and / or client application 808, and store or otherwise maintain historical operational background data associated with a specific patient. In this regard, one or more of devices 802 and 806 may include a Global Positioning System (GPS) receiver, or similar modules, components, or circuitry capable of outputting or otherwise providing data characterizing the geographic location of the respective device 802 or 806 in real time.

[0085] Historical patient data can be analyzed by one or more of the remote device 814, client device 806, and / or medical device 802 to modify or adjust the operation of infusion devices 102, 200, and 502 in a personalized manner to influence fluid delivery. For example, historical meal data and corresponding measurements or other contextual data can be analyzed to predict the future time when the patient is likely to consume their next meal, the probability of a future meal event within a specific time period, the possible size or quantity of carbohydrates associated with the future meal, the possible type or nutritional composition of the future meal, etc. Furthermore, historical measurements of the patient's postprandial cycle following a historical meal event can be analyzed to model or otherwise characterize the patient's predicted size and type of glycemic response to a meal in the current context (e.g., time of day, day of week, geographic location, etc.). One or more aspects of the infusion devices 102, 200, and 502 that control or regulate insulin delivery can then be modified or adjusted to proactively consider the patient's likely meal activities and glycemic response.

[0086] In one or more exemplary embodiments, remote device 814 utilizes machine learning to determine which combination of historical sensor glucose measurement data, historical delivery data, historical ancillary measurement data (e.g., historical acceleration measurement data, historical heart rate measurement data, etc.), historical event log data, historical geolocation data, and other historical or background data is associated with or predicts the occurrence of a specific event, activity, or metric for a particular patient, and then determines a corresponding equation, function, or model for calculating the value of the parameter of interest based on that set of input variables. Thus, the model is capable of characterizing a specific combination of one or more of current (or recent) sensor glucose measurement data, ancillary measurement data, delivery data, geographic location, patient behavior or activity, or mapping that specific combination to a value representing the current probability or likelihood of a particular event or activity, or the current value of the parameter of interest. It should be noted that because each patient's physiological response may differ from other groups, the subset of input variables predicted or associated with a particular patient may differ from that of other patients. Furthermore, the relative weights applied to the corresponding variables of that predicted subset may also differ from those applied to other patients who may have a common predicted subset, based on the different correlations between the specific input variables and the historical data of that particular patient. It should be noted that the remote device 814 can utilize any number of different machine learning techniques to determine which input variables predict the patient of current interest, such as artificial neural networks, genetic programming, support vector machines, Bayesian networks, probabilistic machine learning models or other Bayesian techniques, fuzzy logic, combinations of heuristic derivations, etc.

[0087] Medical devices of the type described herein can generate a variety of user interface display screens supporting different functions and features. For example, an insulin infusion device can generate a main screen that serves as a patient status or monitoring screen, a settings / preference screen, a bolus delivery control screen, etc. These and other display screens can present different information, status data, notifications, patient data (e.g., glucose data), and / or other information to the user in any desired arrangement or format.

[0088] Non-adjunctive insulin administration requires the provision of sensor glucose (SG) values ​​for bolus dose estimation. SG values ​​should only be presented to the user if they are accurate, reliable, or otherwise trusted. The user may instead choose to use blood glucose (BG) values ​​from a linked blood glucose meter device (e.g., a blood glucose meter that communicates wirelessly or wired with a medical device). Assuming there are two input sources for treatment, and only one source can be used, the insulin infusion device is appropriately configured to clearly indicate which glucose source is being used. To this end, the exemplary embodiments described herein are controlled in an appropriate manner to avoid using the current SG value for bolus estimation if the quality or reliability of the determined SG value is insufficient. For the purposes of bolus estimation and presentation to the user, the exemplary embodiments also securely separate SG from BG.

[0089] The handling of BG and SG values, described in more detail below, is governed by certain rules. For example, when a BG value is provided to the system, it is displayed on the push delivery control screen until the BG value expires (e.g., after a specified time period, such as 12 minutes). A unique and visually distinguishable icon is used to indicate that the displayed value is a BG value. If the user fails to make a push delivery selection within the predetermined time period (e.g., 12 minutes or any other time period), the push delivery function will time out.

[0090] According to another operating rule, when the system trusts the SG value and there is no recent BG input, the bolus delivery control screen includes the current SG value with a corresponding icon, in a way that allows for visual differentiation from the displayed BG value. The SG value displayed in the bolus delivery interface cannot be modified via the insulin infusion device's user interface.

[0091] According to another operating rule, if there is a sudden spike in the SG reading that cannot be attributed to carbohydrate intake or other physiological processes (e.g., SG increases at a rate above a predetermined threshold), the current SG value is assumed to be temporarily unsuitable for non-adjuvant therapy. In this case, no alert is required, but the SG value is not displayed on the bolus delivery control screen, and the SG value is not used to calculate the bolus estimate.

[0092] Therefore, the insulin infusion device supports a user interface associated with fully unassisted bolus estimation. When the current SG value is stable / confident, it is visually displayed on the bolus delivery control screen. Otherwise, the SG value is removed from the bolus delivery control screen without generating a user alert. If the user wishes to administer a manual bolus, the user can provide the BG value for bolus estimation. The display screen and user interface features are designed to clearly distinguish the SG value from the BG value. This avoids user confusion and potential bolus estimation errors.

[0093] Figure 9 This is a flowchart illustrating an exemplary embodiment of a process 900 for operating a medical device that regulates the delivery of a fluid medication to a user. Process 900 can be performed by an insulin infusion device of the type described above or any other medical device. Process 900 receives meter-generated values ​​indicative of a user's physiological characteristics, wherein the generated values ​​are produced in response to operation of the analyte meter device. For the exemplary embodiment described herein, the medical device is an insulin infusion device, the fluid medication is insulin, the physiological characteristic of interest is blood glucose, and the meter-generated values ​​are BG values ​​obtained from a blood glucose meter device (e.g., a BG fingertip device) that generates the BG measurement based on a blood sample taken from the user. Therefore, the exemplary embodiment of process 900 receives BG values ​​directly from a linked BG meter or via manual data input by the user or caregiver at the insulin infusion device (e.g., once a day, every 12 hours, or at a frequency desired by the user) (Task 902). The insulin infusion device assumes that the most recently received BG measurement (whether user-input or received directly from the BG meter device) is accurate and reliable.

[0094] Process 900 also obtains sensor-generated values ​​indicative of the same physiological characteristics of the user, wherein the sensor-generated values ​​are generated in response to operation of the continuous analyte sensor device. For a specific implementation of the exemplary insulin infusion device described herein, the sensor-generated values ​​are SG values ​​obtained from a continuous glucose monitor or sensor worn by the user (or calculated based on sensor data obtained from a continuous glucose monitor or sensor). Therefore, exemplary embodiments of process 900 periodically obtain SG values, for example, every five minutes, every ten minutes, or any other desired time interval (task 904). In some embodiments, tasks 902 and 904 are performed independently of each other. For example, task 904 may be performed more frequently than task 902, or tasks 902 and 904 may be performed consecutively or simultaneously in any order.

[0095] Process 900 determines how the BG value and / or SG value will be used for display purposes and for therapeutic dosage and delivery purposes. To this end, an exemplary embodiment of process 900 checks for the existence of a valid BG value (e.g., a valid meter-generated value) (query task 906). For this particular embodiment, the current BG value is considered "valid" until it expires after an expiry period. The expiry period can vary from one embodiment to another. For this particular example, the valid lifetime of a BG value is only 12 minutes; expired BG values ​​are not used. Therefore, if process 900 determines that a valid BG value is available (the "Yes" branch of query task 906), the device is controlled appropriately to operate in a first mode, for example, as described below. Figure 10 (Task 908) is described in further detail. According to the implementation described herein, when a valid instrument generates a BG value, the device operates in the first mode regardless of the availability of a sensor to generate an SG value, and regardless of the quality, accuracy, or reliability of the current SG value (if any).

[0096] Figure 10 This is a flowchart illustrating the operation of the insulin infusion device in first mode. It can be executed at task 908 of process 900. Figure 10 The first mode operation process 1000 is described in the text.

[0097] In this example, it is assumed that the "new" BG value is accurate and reliable. Therefore, process 1000 displays the valid BG value on the device's user monitoring screen (task 1002). While the BG value remains valid, it remains displayed on the user monitoring screen. Once the BG value expires or is otherwise deemed invalid, it is removed from the user monitoring screen (e.g., stopped from being displayed on the user monitoring screen). In some embodiments, the user monitoring screen is the main screen of the insulin infusion device, and the main screen may include additional information, such as other patient data, status indicators, etc., if desired. In this regard, Figure 11 This is a schematic diagram of the user monitoring screen 1100 on an insulin infusion device, displaying the current and valid meter-generated BG value 1102. The BG value 1102 may be displayed along with a “BG” label 1104 to clearly indicate that the displayed value is indeed a BG value (and not an SG value). Furthermore, the process 1000 uses visually distinguishable characteristics to display the BG value, which may also be used to display the “BG” label 1104 and the unit (mg / dL) for displaying the BG value. For example, any one or more of the following visually distinguishable characteristics may be used to display the BG value: color; font design; font size; font characteristics such as bold, italic, or outline; animation such as blinking or moving displays; fill patterns or patterns; transparency levels; and accompanying icons (such as blood drops).

[0098] Re-reference Figure 10 Process 1000 also displays a valid BG value on the device's therapeutic delivery control screen (Task 1004). While the BG value remains valid, it remains displayed on the therapeutic delivery control screen. Once the BG value expires or is otherwise deemed invalid, it is removed from the therapeutic delivery control screen. For this particular embodiment, the therapeutic delivery control screen is the insulin bolus delivery control screen of the insulin infusion device, and the bolus delivery control screen may include additional information related to the estimated bolus dose and the operation of the bolus delivery function. In this regard, Figure 12 This is a schematic diagram of a therapeutic delivery control screen 1200 on an insulin infusion device, displaying the current and effective BG value 1202. The BG value 1202 may be displayed together with a “BG” label 1204 to clearly indicate that the displayed value is indeed a BG value (and not an SG value). Furthermore, the BG value 1202 may be displayed together with a visually distinguishable and context-sensitive icon 1206 to further indicate that the displayed value is a BG value and not an SG value. In this example, the icon 1206 resembles a blood droplet, and the icon 1206 is red.

[0099] It is worth noting that process 1000 uses the same (or substantially similar) visually distinguishable characteristics used for displaying BG value 1102 on user monitoring screen 1100 to display BG value 1202. This same visually distinguishable characteristic can also be used to display the “BG” label 1204 and the unit (mg / dL) for displaying the BG value. Using the same visually distinguishable characteristic for BG values ​​on different user interface screens or features makes it easy for the user to interpret and identify the source of the displayed glucose measurement result. Although this description focuses on user monitoring screens and therapeutic delivery control screens, consistent visual characteristics (“appearance and feel” aspects) can be used on any number of display screens generated by the device.

[0100] Re-reference Figure 10 Process 1000 prohibits the display of any SG values ​​on the user monitoring screen and the treatment delivery control screen (Task 1006). In this regard, the device relies on the measurement result if a valid BG value is available, regardless of whether the current and accurate SG value is also available. Therefore, preventing the display of available SG values ​​under these conditions is intuitive and less confusing for the user.

[0101] Process 1000 continues by calculating the therapeutic dose for delivery (if necessary) based on the BG value generated by the valid instrument (Task 1008). In this example, the insulin bolus is calculated at Task 1008, and the calculated bolus dose is displayed on the therapeutic delivery control screen. In this respect, Figure 12The therapeutic delivery control screen 1200 shown includes a calculated insulin bolus of 0.8 units. Therefore, the effective BG value is used as an input or parameter for estimating the appropriate insulin bolus to maintain the user's blood glucose level within the desired target range.

[0102] In some implementations, the calculated bolus dose can be administered automatically or manually. For example, if an automatic delivery mode is supported and activated, the bolus can be delivered automatically. Thus, during operation in the first mode, process 1000 enables the device's automatic therapeutic delivery function (task 1010). Therefore, if the user cannot manually administer the calculated bolus dose, the automatic delivery function will take appropriate action to deliver the bolus in a timely manner. To this end, process 1000 can automatically control the operation of the device according to the calculated therapeutic dose to regulate the delivery of fluid medication (insulin) from the device (task 1012).

[0103] return Figure 9 As described in process 900, if a valid BG value is unavailable (the "No" branch of query task 906), process 900 checks the current SG value to determine the quality of the measurement. The quality of the current SG value can be determined or calculated using any suitable method. For example, the current SG value can be compared with historical SG measurements, historical BG measurements, recent BG values, etc. Alternatively, the quality of the current SG value can be determined using a "self-diagnostic" technique that takes into account the age of the continuous glucose sensor, SG measurement trends, electrical noise in the raw sensor signal, etc. According to some implementations, process 900 uses methods described in more detail below to determine the quality of the SG measurement result.

[0104] While the quality of an SG measurement result can be expressed in any suitable manner, the exemplary implementation of process 900 considers a “high-quality” SG measurement result to be the best quality (e.g., above a high-quality threshold) and therefore suitable for glucose monitoring, therapeutic dosing calculation, and controlled therapeutic delivery. Process 900 considers a “monitoring quality” SG measurement result to be suitable only for glucose monitoring, where a monitoring quality SG measurement result is less desirable than a high-quality SG measurement result but is still suitable for certain non-treatment-related functions (e.g., below a high-quality threshold and above a low-quality threshold). If the quality of an SG measurement result is considered less than monitoring quality (e.g., below a low-quality threshold), then that SG value is neither displayed nor used for treatment-related functions.

[0105] If process 900 determines that the current SG value meets the "high quality" criterion, for example, a quality higher than the high quality threshold (query task 910's "Yes" branch), then the device is controlled appropriately to operate in the second mode (task 912). According to the implementation described herein, the device operates in the second mode when a valid instrument-generated BG value is unavailable, and when the current sensor-generated SG value is determined to be of high quality.

[0106] Figure 13 This is a flowchart illustrating the operation of the insulin infusion device in second mode. It can be executed at task 912 of process 900. Figure 13 The second mode operation process 1300 is described in the diagram. The second mode relies on the currently available high-quality SG value. Therefore, process 1300 displays the current SG value on the device's user monitoring screen (task 1302). This SG value remains displayed on the user monitoring screen until it is refreshed. Figure 14 This is a schematic diagram of the user monitoring screen 1400 on an insulin infusion device, showing the current SG value 1402. The SG value 1402 may be displayed together with an "SG" label (not shown) to clearly indicate that the displayed value is indeed an SG value (and not a BG value). Figure 14 The example shown displays a glucose trend arrow 1404 near the displayed SG value 1402 to indicate whether the user's blood glucose level is elevated or decreased (e.g., compared to a previous glucose level measurement). Furthermore, process 1300 uses a visually distinguishable characteristic to display the SG value 1402, which can also be used to display the "SG" label, trend arrow 1404, and the unit (mg / dL) of the SG value. The embodiments described herein use color as a visually distinguishable characteristic. However, in some embodiments, any one or more of the following characteristics may be used to display the SG value: color; font design; font size; font characteristics such as bold, italic, or outline; animation such as blinking or moving display; fill pattern or pattern; transparency level; and accompanying icon. It is noteworthy that the SG value and BG value are displayed using different visually distinguishable characteristics, allowing the user to quickly and easily observe whether the displayed measurement result is a BG value or an SG value. For example, the BG value and related information may be presented in white or yellow font, while the SG value and related information may be presented in a contrasting color such as blue, cyan, or purple.

[0107] Re-reference Figure 13 In process 1300, the current SG value is also displayed on the device's treatment delivery control screen (task 1304). The SG value remains displayed on the treatment delivery control screen until it is refreshed and cannot be modified via the device's user interface. Figure 15This is a schematic diagram of a therapeutic delivery control screen 1500 on an insulin infusion device, displaying the current (and high-quality) SG value 1502. The SG value 1502 may be displayed together with an "SG" label 1504 to clearly indicate that the displayed value is indeed an SG value (and not a BG value). Furthermore, the SG value 1502 may be displayed together with a visually distinguishable and context-sensitive icon 1506 to further indicate that the displayed value is an SG value and not a BG value. In this example, the icon 1506 resembles a graph or signal waveform, and the color of the icon 1506 matches the color of the displayed SG value 1502.

[0108] It is worth noting that process 1300 uses the same (or substantially similar) visually distinguishable characteristics used to display SG value 1402 on user monitoring screen 1400 to display SG value 1502. This same visually distinguishable characteristic can also be used to display the “SG” label 1504 and the unit (mg / dL) for displaying the SG value. Using the same visually distinguishable characteristic for SG values ​​on different user interface screens or features makes it easy for the user to interpret and identify the source of the displayed glucose measurement result. Although this description focuses on user monitoring screens and therapeutic delivery control screens, consistent visual characteristics (“appearance and feel” aspects) can be used on any number of display screens generated by the device.

[0109] Re-reference Figure 13 Process 1300 prohibits the display of any BG values ​​on the user monitoring screen and the treatment delivery control screen (Task 1306). In this regard, if a valid BG value is not available, the device only considers the current (e.g., most recent) and accurate SG value for display purposes.

[0110] Process 1300 continues by calculating the therapeutic dose for delivery (if needed) based on the SG value generated by a high-quality sensor (Task 1308). In this example, the insulin bolus is calculated at Task 1308, and the calculated bolus volume is displayed on the therapeutic delivery control screen. In this respect, Figure 15 The therapeutic delivery control screen 1500 shown includes a calculated insulin bolus of 0.8 units. Therefore, a high-quality SG value is used as an input or parameter for estimating the appropriate insulin bolus to maintain the user's blood glucose level within the desired target range.

[0111] In some examples, if an automated delivery mode is supported and activated, the calculated bolus dose can be administered manually or automatically. Therefore, during operation in the second mode, process 1300 enables the device's automated therapeutic delivery function (task 1310). Thus, if the user cannot manually administer the calculated bolus dose, the automated delivery function will take appropriate action to deliver the bolus in a timely manner. For this purpose, process 1300 can automatically control the operation of the device based on the calculated therapeutic dose to regulate the delivery of the fluid drug (insulin) from the device (task 1312).

[0112] return Figure 9 As described in process 900, if the current SG value does not meet the "high quality" criterion (query task 910, "No" branch), but meets the "monitoring quality" criterion (query task 914, "Yes" branch), the device is controlled appropriately to operate in the third mode (task 916). According to the implementation described herein, the device operates in the third mode when a valid instrument-generated BG value is unavailable, and when the current sensor-generated SG value is determined to have sufficient quality for user monitoring purposes but may not be suitable for calculating therapeutic dosage.

[0113] Figure 16 This is a flowchart illustrating the operation of the insulin infusion device in third mode. It can be executed at task 916 of process 900. Figure 16 The third mode operation process 1600 is depicted in the diagram. The third mode relies on the currently available monitoring quality (SG) value. Therefore, process 1600 displays the current SG value on the device's user monitoring screen (task 1602). This SG value remains displayed on the user monitoring screen until it is refreshed. User monitoring screen 1400 (see...) Figure 14 The above description also applies to this scenario, because the monitored quality SG value is displayed in a similar way, which has the previously combined... Figure 14 The example shown illustrates the same visually distinguishable features.

[0114] When operating in the third mode, the device disables the display of the current SG value on the treatment delivery control screen (Task 1604). Furthermore, process 1600 disables the display of any BG value on the treatment delivery control screen (Task 1606). Instead, the device is operated to display an appropriate message, notification, or indication on the treatment delivery control screen, indicating that no suitable measurement of the user's physiological characteristics is available. For this particular example, process 1600 displays a message such as "No glucose" or "No glucose available" on the treatment delivery control screen (Task 1608). Figure 17This is a schematic diagram of a therapeutic delivery control screen 1700 on an insulin infusion device, which displays neither BG nor SG values. Instead, the therapeutic delivery control screen 1700 includes a "No Glucose" message or field 1702, which informs the user that no suitable glucose measurement is available to calculate the estimated bolus. Therefore, the therapeutic delivery control screen 1700 indicates a bolus dose of 0.0 units under these conditions.

[0115] Re-reference Figure 16 Process 1600 prohibits the use of the current SG value to calculate the dose of therapeutic agent to be delivered (Task 1610). Although the monitored quality SG value is suitable as a general indicator of a user's glucose level, Process 1600 assumes that it may not be suitable for calculating an accurate insulin bolus dose. Therefore, Process 1600 operates the device in third mode to disable the automated therapeutic agent delivery function (Task 1612). For the embodiments described herein, Task 1612 ensures that no corrective bolus of insulin is administered when the insulin infusion device is operating in third mode.

[0116] Process 1600 can continue by prompting the user to obtain a new instrument-generated BG value (Task 1614), which can be used to update the user monitoring screen and the drug delivery control screen. Additionally, the new BG value can be used to calculate the estimated bolus and reactivate the automated drug delivery function. Alternatively, Process 1600 can generate reminders, messages, or notifications to prompt the user to check the integrity of the sensor equipment, recalibrate the sensor equipment, replace the sensor equipment with a new unit, etc.

[0117] Refer again Figure 9 If process 900 determines that the current SG value does not meet the specified "monitoring quality" criterion (query the "No" branch of task 914), then process 900 generates an appropriate alarm, message, or notification regarding the need for some form of corrective action (task 918). For example, the device may generate an alarm to remind the user to take one or more of the following actions: obtain / enter a new BG value; check the integrity of the currently deployed sensor equipment; recalibrate the currently deployed sensor equipment; check the data communication functionality of the currently deployed sensor equipment; replace the sensor equipment with a new unit; etc.

[0118] Process 900 is executed in a continuous manner, as expected, to update the BG value and / or SG value over time. Figure 9 The dashed lines in the diagram indicate how to repeat process 900 as needed to receive and process new BG and SG values.

[0119] Automated insulin infusion systems that use feedback from a continuous glucose monitor (CGM) to adjust insulin dosage require the implementation of safety features to mitigate the risks of overdelivery and hypoglycemia under certain glucose sensor conditions. These mitigations can be achieved using one or more of the following technical components: (1) detection and rating of the quality of CGM measurements used for automated insulin dosing; (2) a set of therapeutic adjustments applicable to each sensor quality level; and (3) a set of system alerts or other user interface (UI) notifications to guide the user to take appropriate action when needed. An example of an insulin infusion system that utilizes sensor quality metrics to adjust therapeutic delivery patterns has been described above.

[0120] Sensor quality—High-quality CGM / sensor measurements are required to realize the full benefits of the control basis of automated insulin infusion systems and bolus insulin delivery. Sensor quality metrics can be determined using known factors that may affect sensor accuracy. Examples of these factors include, but are not limited to: (1) sensor age with a known correlation to measurement accuracy; (2) measurement noise in the CGM electronics and / or the raw sensor signal; and (3) sudden and sharp increases or decreases in sensor measurements that cannot be attributed to natural physiological conditions.

[0121] According to an exemplary embodiment, sensor quality metrics can be mapped to scales (e.g., a scale of 1 to 10, or low / medium / high values) that provide different quality levels that can be used to adjust the therapeutic. The determination of a particular level should be related to the potential risks of providing automated therapy, as baseline conditions may lead to the expected level of sensor error. For example, for the purposes of this specification, transient measurement noise may cause moderate CGM measurement error, thus corresponding to a “medium” sensor quality metric, while sudden, discontinuous jumps or drops in CGM measurements may correspond to a “low” sensor quality metric.

[0122] Sensor quality metrics can also depend on the characteristics of historical CGM values ​​in a time series. For example, previous CGM values ​​within a moving time window can be analyzed and compared to the current value. Alternatively, the average of historical CGM values ​​obtained on or near the same day can be analyzed and compared to the current value (obtained on the day of analysis). Therefore, the lack of a sufficient number of historical values ​​can itself lead to conservative sensor quality ratings until enough historical data are recorded.

[0123] Therapeutic agent adjustment—Once sensor quality metrics are determined, adjustments may be needed to the control algorithms or methods governing automated insulin infusion to mitigate the risk of over- or under-delivery insulin. In some implementations, specific types of adjustments depend on the design of the automated infusion algorithm.

[0124] For example, consider an automated infusion algorithm that uses CGM measurements to adjust basal insulin in real time and provides additional bolus insulin during rapid glucose rises. Furthermore, the algorithm includes a safety backup delivery mode that provides a constant basal rate when CGM measurements are unavailable. In such a system, therapeutic adjustments can be made for the following situations:

[0125] Scenario 1: "High" CGM / sensor quality metric – The algorithm can be used to fully authorize basal and bolus insulin based on CGM measurement results.

[0126] Scenario 2: "Medium" CGM / sensor quality metric – Only CGM is allowed to determine basal insulin delivery, but delivery of bolus insulin is stopped or otherwise restricted.

[0127] Scenario 3: "Low" CGM / Sensor Quality Metrics – Completely ignore CGM and revert to safe backup delivery mode until sensor quality is restored.

[0128] The three scenarios listed above are representative examples of hypothetical automated insulin infusion systems. Different algorithm designs will require therapeutic adjustments to match the algorithm's dosing rules and / or other factors.

[0129] System alerts and notifications – System alerts and notifications represent another component in helping manage risk while balancing treatment effectiveness and user burden. Ideally, treatment should remain acceptable without increasing the burden of disruptive system alerts on the user. However, in some cases, alerts are necessary to further mitigate the risks associated with poor CGM quality or to guide the user to take the necessary actions to restore optimal treatment.

[0130] For example, it may be known that a particular CGM quality condition is essentially transient and typically recovers without any intervention. In this case, it might be appropriate for the system to adjust the treatment without notifying the user. However, if the CGM quality does not fully recover after a specified period, it may be appropriate to include a condition that notifies the user.

[0131] For example, it may be possible to identify different CGM quality conditions that require calibration using external blood glucose measurements. In such cases, it would be appropriate to alert the user that CGM calibration is needed once this condition occurs.

[0132] As mentioned above, the scale of the sensor quality metric can be changed in any desired manner. According to an exemplary implementation, the sensor quality metric can be “unknown” or “uncertain,” or it can indicate low, medium, or high sensor quality. Table 1 shows all the sensor quality metrics for this specific implementation, along with their associated treatment actions and system alarms.

[0133] Table 1: Sensor Quality and Corresponding Actions

[0134]

[0135] Figure 18 This is a flowchart illustrating an exemplary embodiment of a process 1800 for controlling the operation of a medical device to adjust therapeutic actions based on sensor quality. Process 1800 obtains a current sensor-generated value indicating a user's physiological characteristics, wherein this value is generated in response to the operation of a continuous analyte sensor device. The embodiments presented herein relate to insulin infusion systems including or in collaboration with a continuous glucose sensor, wherein the physiological characteristic is glucose level.

[0136] Process 1800 obtains the current SG value from the CGM sensor device (Task 1802). Process 1800 calculates, receives, or otherwise obtains a sensor quality metric from the CGM sensor device, wherein the sensor quality metric indicates the accuracy, reliability, and / or confidence of the SG value generated by the current sensor (Task 1804). According to some embodiments, the sensor quality metric is calculated by the CGM sensor device, which transmits the calculated sensor quality metric to one or more target devices as needed (e.g., the calculated sensor quality metric may be sent from the CGM sensor device to an insulin infusion device, a glucose monitoring device, a mobile device running an appropriately configured mobile app, etc.). Alternatively or otherwise, the sensor quality metric may be calculated by one or more devices other than the CGM sensor device based on the raw sensor signal or information generated at the CGM sensor device. For example, the CGM sensor device may provide its electrical output (such as a current value or voltage) to an insulin infusion device, and the insulin infusion device may then calculate the sensor quality metric based on the provided electrical output value.

[0137] Process 1800 continues by adjusting the therapeutic actions of the insulin infusion device in response to sensor quality measurements to configure a quality-specific operating mode for the insulin infusion device (Task 1806), as described below. Figure 20More detailed description. Therefore, the treatment-related functions, features, and / or operation of the medical device (insulin infusion device) are altered based on calculated sensor quality metrics (e.g., high quality, moderate quality, low quality, etc.). As shown in Table 1, conservative or aggressive insulin therapy options can be enabled / disabled continuously based on the current state of the sensor quality metrics. Furthermore, process 1800 manages the generation of user alarms at the medical device in response to the calculated sensor quality metrics (task 1808). In this respect, process 1800 controls the insulin infusion device (and / or other user devices) to generate, disable, or otherwise adjust user alarms based on the current state of the sensor quality metrics. In some embodiments, task 1808 manages alarms by generating user alarms when the calculated sensor quality metrics meet specified alarm generation criteria and disabling user alarms when the calculated sensor quality metrics do not meet specified alarm generation criteria. Alarm generation criteria can be specified to reduce unwanted or annoying alarms, warnings, and notifications. For example, an alarm generation criterion can disable user alarms if the sensor quality metric is "good" than a low value. For example, alarm generation criteria can allow users to issue alarms if sensor quality metrics are low, or if the system determines that a sensor is nearing the end of its lifespan or has lost communication with a medical device. This provides a better user experience and reduces intrusive alarms and alarming notifications.

[0138] Process 1800 continues by adjusting the delivery of fluid medication (e.g., insulin) from the medical device based on the current SG value and the quality-specific operating mode of the medical device (Task 1810). In other words, the delivery of fluid medication is controlled in response to a current sensor quality metric that determines the quality-specific operating mode to be used, resulting in adjustments to certain therapeutic actions (see Table 1). For this particular implementation, Task 1810 adjusts the therapeutic actions of the insulin infusion device such that the aggressiveness of insulin delivery therapy is proportional to the quality of the current SG value as indicated by the calculated sensor quality metric, as referenced below. Figure 20 More detailed description. Depending on the specific application and type of medical device, any desired method or algorithm driven by the value of the sensor quality metric can be used to adjust, control, or regulate the therapeutic action in different ways. Process 1800 can be repeated continuously to take into account the updated SG value and its corresponding sensor quality metric used to adjust the therapeutic action over time.

[0139] Figure 19 This is a block diagram illustrating the generation of sensor quality metrics according to an exemplary embodiment. Figure 19Sensor quality calculation logic 1900 is described, which calculates a sensor quality metric 1902 based on one or more data inputs. The sensor quality calculation logic 1900 may reside in and execute in: CGM sensor devices; insulin infusion devices; user monitoring devices; mobile devices; smart devices or appliances; cloud-based systems, devices, or services; in-vehicle computing systems or devices; tablets, desktop computers, or portable computers; and so on. Although not always necessary, the exemplary embodiments presented herein calculate the sensor quality metric 1902 solely based on information, data, or signals generated or derived from the continuous analyte sensor device. In other words, the data inputs to the sensor quality calculation logic 1900 are generated by or derived / calculated from data generated by the sensor device, and the sensor quality calculation logic 1900 does not process information from external calibration devices or auxiliary devices to obtain the sensor quality metric 1902. In this respect, the continuous analyte sensor device can generate its own sensor quality metric 1902 in an “isolated” and self-diagnostic manner, without relying on any additional information obtained from another device or system. Alternatively, the continuous analyte sensor device may provide information generated or calculated internally to a compatible target device, which then uses only the information obtained from the sensor device to calculate the sensor quality metric 1902.

[0140] In some examples, the data inputs utilized by the sensor quality calculation logic 1900 can be selected to suit the needs and requirements of a particular medical device system, intended application, and / or specific implementation. Figure 19 The example shown processes at least the following data inputs: sensor age data 1904; raw sensor signal value 1906; and / or historical sensor-generated values ​​1908 generated in response to the operation of the continuous analyte sensor device. As described above, these three data inputs are generated by the sensor device or derived from information / data generated by the sensor device.

[0141] Sensor age data 1904 indicates the actual age, operational lifespan, or "running time" of the sensor device, the amount of time since the sensor device was deployed, etc. In this regard, sensor age data 1904 may be based on the date / time of manufacture, the date / time of initial deployment on the user's body, the date / time after initialization or warm-up of the sensor device following deployment, etc. A preferred embodiment bases the age of the sensor device on the time immediately following the initialization or warm-up of the deployed sensor device, which may be determined or marked by the sensor device in some embodiments. The sensor device may keep tracking its age and continuously update the sensor age data 1904 over time. Alternatively or additionally, the sensor device may mark and report the initial date / time (after warm-up) so that the target device can keep tracking the sensor age and update the sensor age data 1904 over time.

[0142] The raw sensor signal value 1906 corresponds to the raw signal output of the continuous analyte sensor device, which is generated when the sensor device is monitoring a physiological characteristic of interest. In some embodiments, the raw sensor signal value 1906 is a current and / or voltage measurement result. For the continuous glucose sensor example described herein, the raw sensor signal value 1906 is a current reading sometimes referred to as the "ISIG" value. The raw sensor signal value 1906 is processed or converted into the monitored analyte level, such as a blood glucose level. For this purpose, Figure 19 The sensor generated value 1908 shown represents a usable sensor value derived, calculated, or converted from the original sensor signal value 1906. The method described herein takes into account multiple historical sensor generated values ​​1908 required to generate a sensor quality metric 1902 associated with the current sensor value.

[0143] In some implementations, sensor quality calculation logic 1900 calculates sensor quality metrics 1902 based on: sensor age data 1904; measurement noise in the raw signal output of the continuous analyte sensor device; and variations in sensor generated values ​​1908 that cannot be attributed to the user's natural physiological condition. Sensor age data 1904 is considered because the accuracy of newly deployed sensor devices typically fluctuates within a short period immediately following initialization or warm-up. Measurement noise in the raw sensor signal values ​​1906 can be caused by various conditions, such as physical movement of the sensor device, displacement of embedded sensor elements, sudden unpredictable physiological changes, or infiltration of water or other substances at the sensor site. The raw sensor signal values ​​1906 are typically relatively stable over "long" time periods, such as five minutes. However, if sensor quality calculation logic 1900 detects high variations (measurement noise) in the raw sensor signal values ​​1906, the corresponding sensor measurement result can be designated as low quality. Similarly, if the sensor-generated value 1908 exhibits abrupt changes, peaks, or inaccurate measurement results that do not correspond to normal physiological changes or conditions, the sensor quality calculation logic 1900 can mark those sensor values ​​as low quality or ignore them.

[0144] Sensor quality calculation logic 1900 can consider any input data item individually or in any combination to generate sensor quality metric 1902. As previously described, sensor quality metric 1902 can be expressed in any desired format using any desired range, scale, or domain. For the exemplary embodiments presented herein, sensor quality metric 1902 is calculated as a number between 0 and 10 (inclusive), but only four available metric values ​​are mapped to the quality states indicated in Table 1: uncertain; low; medium; and high. In other embodiments, more or fewer than four quality states may be utilized. Sensor quality metric 1902 is generated and formatted in a manner compatible with the fluid drug delivery device such that the therapeutic actions of the fluid drug delivery device are adjusted in response to the calculated sensor quality metric.

[0145] Sensor quality calculation logic 1900 executes a method for evaluating the operational quality of a continuous analyte sensor device, wherein sensor quality metric 1902 serves as an indicator of quality. Sensor quality metric 1902 can be used to regulate, control, or adjust certain functions or features of an associated medical device that regulates the delivery of therapeutic substances to a patient. In this regard, Figure 20This is a flowchart (process 2000) illustrating the operation of an insulin infusion device according to an exemplary embodiment of sensor quality calculation logic 1900. The following description of process 2000 assumes that the insulin infusion device receives or generates a sensor quality metric with a corresponding SG value, as described above. Therefore, the embodiment of process 2000 shown begins by processing the current value of the sensor quality metric (task 2002). For this particular specific embodiment, process 2000 checks whether the sensor quality metric indicates uncertain quality (query task 2004), high quality (query task 2012), medium quality (query task 2020), or low quality (query task 2028).

[0146] When the sensor quality metric indicates uncertain quality (query Task 2004's "Yes" branch), Process 2000 adjusts certain therapeutic actions of the insulin infusion device to configure an operating mode suitable for the uncertain quality state. More specifically, when the sensor quality metric indicates uncertain quality, Process 2000 enables automated basal insulin delivery by the insulin infusion device (Task 2006), disables the automated bolus delivery function of the insulin infusion device (Task 2008), and prohibits the generation of any user alerts related to the current sensor value with uncertain quality (Task 2010). Under the assumption that the sensor quality metric will be determined in the near future, the therapeutic adjustment for this particular operating mode is appropriate. Therefore, no user alerts are generated, but the automated bolus delivery function is temporarily disabled.

[0147] When a sensor quality metric indicates high quality, for example, when the sensor quality metric is greater than or equal to a high threshold, such as 7 (query Task 2012's "Yes" branch), Process 2000 adjusts certain therapeutic actions of the insulin infusion device to configure an appropriate high-quality operating mode. More specifically, when a sensor quality metric indicates high quality, Process 2000 enables automated basal insulin delivery by the insulin infusion device (Task 2014), enables automated bolus delivery (Task 2016), and disables the generation of any user alerts related to the current sensor value with high quality (Task 2018). Therapeutic adjustments to this high-quality operating mode are appropriate under the assumption that the sensor device is operating normally and accurately. For this purpose, no user alerts are generated, and both automated basal delivery and automated bolus delivery remain active and enabled.

[0148] When the sensor quality metric indicates moderate quality, for example, between a low threshold (such as 3) and a high threshold (such as 7) (query the "Yes" branch of Task 2020), Process 2000 adjusts certain therapeutic actions of the insulin infusion device to configure an appropriate moderate quality operating mode. More specifically, when the sensor quality metric indicates moderate quality, Process 2000 enables automated basal insulin delivery by the insulin infusion device (Task 2022), enables restricted automated bolus delivery (Task 2024), and disables the generation of any user alerts related to the current sensor value with moderate quality (Task 2026). Therapeutic adjustments for this moderate quality operating mode are appropriate under the assumption that the sensor device operates in a manner that still supports the modified automated bolus delivery function. Therefore, no user alerts are generated, and automated basal delivery remains active. However, the automated bolus delivery function is modified to be less aggressive than usual. For example, the amount of insulin delivered by the automated bolus delivery function may be limited or capped, or the bolus volume calculated based on the current SG value may be reduced by a certain percentage as a safety factor. For example, when the sensor quality metric indicates moderate quality, an upper limit can be set on the current SG value to control the insulin infusion device for calculating and administering automated boluses. According to some implementations, when the sensor quality metric indicates moderate quality, the maximum SG value is used for bolus calculation purposes (e.g., 250 mg / dL) – if the current SG value is higher than the maximum permissible SG value, the actual SG value is ignored for automated bolus calculation purposes. This method reduces the likelihood of over-delivery of insulin when the reliability or quality of the continuous glucose sensor device may be problematic.

[0149] When a sensor quality metric indicates low quality, such as when the sensor quality metric is less than or equal to a low threshold, such as 3 (query the "Yes" branch of Task 2028), Process 2000 adjusts certain therapeutic actions of the insulin infusion device to configure an appropriate low-quality operating mode. More specifically, when a sensor quality metric indicates low quality, Process 2000 enables the insulin infusion device's safe basal insulin delivery mode (Task 2030), disables automatic bolus delivery (Task 2032), and generates a user alert to prompt the user to take corrective actions, such as obtaining a new glucometer value for sensor calibration (Task 2034). The therapeutic adjustments made to this low-quality operating mode result in conservative insulin therapy. For this purpose, the user's normal basal insulin delivery distribution can be adjusted to be generally less aggressive, or the basal delivery distribution can be adjusted to a flat distribution that only provides the baseline amount of basal insulin over time. Furthermore, automatic bolus delivery is paused until the sensor quality metric improves.

[0150] As described above, low positivity for fluid drug therapy is provided when the sensor quality metric is low (e.g., at or below a low threshold), moderate positivity is provided when the sensor quality metric is moderate (e.g., between a low and a high threshold), and high positivity is provided when the sensor quality metric is high (e.g., at or above a high threshold). Depending on the specific implementation, more or fewer than three levels of positivity may be supported.

[0151] If a sensor quality metric indicates poor quality or an erroneous value, process 2000 may generate an appropriate alarm, message, or notification regarding the need for investigation, corrective action, etc. (task 2036). For example, an insulin infusion device may generate an audible alarm and display a message requiring the user to check the integrity of the sensor device, recalibrate the sensor device, replace the sensor device, etc.

[0152] The iteration of process 2000 can be performed frequently in a continuous manner as needed. In some implementations, process 2000 is performed for each new SG value (and its corresponding sensor quality metric).

[0153] This document describes technologies and processes based on functional and / or logical block components, and refers to symbolic representations of operations, processing tasks, and functions that can be performed by various computing components or devices. Such operations, tasks, and functions are sometimes referred to as computer-executed, computerized, software-implemented, or computer-implemented. It should be understood that the various block components shown in the figures can be implemented by any number of hardware, software, and / or firmware components configured to perform specified functions. For example, implementations of systems or components can employ various integrated circuit components, such as memory elements, digital signal processing elements, logic elements, and lookup tables, which can perform various functions under the control of one or more microprocessors or other control devices.

[0154] When implemented in software, firmware, or other forms of executable program instructions, the various elements of the system described herein are essentially segments of code or instructions that perform various tasks. In some implementations, the program or code segments are stored in a tangible processor-readable medium, which may include any medium capable of storing or transmitting information. Examples of non-transitory and processor-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, and hard disks.

[0155] The various tasks performed in conjunction with the processes described herein can be executed by software, hardware, firmware, or any combination thereof. It should be understood that the described processes may include any number of additional or alternative tasks, without requiring the tasks shown in the flowchart representation to be performed in the illustrated order, and the described processes may be incorporated into more comprehensive programs or processes with additional functionality not described in detail herein. Furthermore, one or more of the tasks shown may be omitted from an implementation of the described processes, provided that the intended overall functionality remains intact.

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

[0157] Various aspects of this disclosure are described in the following provisions:

[0158] 1. A method for controlling the operation of a medical device, the medical device regulating the delivery of a fluid drug to a user, the method comprising:

[0159] Receive meter-generated values ​​indicating the user's physiological characteristics, the meter-generated values ​​being generated in response to the operation of the analyte instrument;

[0160] A sensor-generated value indicating the user's physiological characteristics is obtained, the sensor-generated value being generated in response to the operation of a continuous analyte sensor device different from the analyte instrumentation device.

[0161] When a valid meter generated value is available, the medical device is operated in a first mode to display the valid meter generated value on the user monitoring screen of the medical device and the therapeutic delivery control screen of the medical device, and the medical device is operated in the first mode to calculate the therapeutic dose for delivery based on the valid meter generated value;

[0162] When a valid instrument value is unavailable and the current sensor value meets a first quality standard, the medical device is operated in a second mode to display the current sensor value on the user monitoring screen and the therapeutic delivery control screen, and in the second mode to calculate the therapeutic dose for delivery based on the current sensor value; and

[0163] When a valid instrument value is unavailable and the current sensor value meets the second quality standard but not the first quality standard, the medical device is operated in a third mode to display the current sensor value on the user monitoring screen, the medical device is operated in the third mode to disable the display of the current sensor value on the treatment delivery control screen, and the medical device is operated to disable the use of the current sensor value to calculate the dosage of the treatment for delivery.

[0164] 2. The method described in Clause 1 further includes:

[0165] When a valid meter-generated value is unavailable and the current sensor-generated value meets the second quality standard but not the first quality standard, the medical device is operated in the third mode to prevent the display of any meter-generated value on the treatment delivery control screen.

[0166] 3. The method described in Clause 1 further includes:

[0167] When a valid meter-generated value is unavailable and the current sensor-generated value meets the second quality standard but not the first quality standard, the medical device is operated in the third mode to display a message on the treatment delivery control screen indicating that no suitable measurement results for the user's physiological characteristics are available.

[0168] 4. The method described in Clause 1 further includes:

[0169] When a valid meter-generated value is available, the medical device is operated in the first mode to enable the automated therapeutic delivery function;

[0170] When a valid instrument value is unavailable and the current sensor value meets the first quality standard, the medical device is operated in the second mode to enable the automated treatment delivery function; and

[0171] When a valid instrument value is unavailable and the current sensor value meets the second quality standard but not the first quality standard, the medical device is operated in the third mode to disable the automated therapeutic delivery function.

[0172] 5. The method described in Clause 1 further includes:

[0173] When a valid meter value is available, the medical device is operated in the first mode to display the valid meter value on the user monitoring screen and the treatment delivery control screen using a first visually distinguishable characteristic; and

[0174] When a valid instrument value is unavailable and the current sensor value meets the first quality standard, the medical device is operated in the second mode using a second visually distinguishable characteristic that is different from the first visually distinguishable characteristic to display the current sensor value on the user monitoring screen and the treatment delivery control screen.

[0175] 6. The method according to Clause 1 further includes:

[0176] When valid instrument-generated values ​​are available, the medical device is operated in the first mode regardless of the availability of sensor-generated values.

[0177] 7. The method described in Clause 1 further includes:

[0178] When a valid instrument value is unavailable and the current sensor value meets the second quality standard but not the first quality standard, the medical device is operated in the third mode to prompt the user to obtain a new instrument value.

[0179] 8. The method according to any one of clauses 1 to 7 further includes:

[0180] The delivery of the fluid drug from the medical device is adjusted according to the therapeutic dose calculated when the medical device is operated in the first mode or the second mode.

[0181] 9. The method according to any one of clauses 1 to 8, wherein:

[0182] Valid instrument-generated values ​​remain available until they expire after their expiry period; and

[0183] Valid instrument-generated values ​​become unavailable after their expiration.

[0184] 10. A medical device for regulating the delivery of a drug to a user, the medical device comprising:

[0185] Drive system;

[0186] At least one processor device, said at least one processor device regulating the operation of the drive system to deliver a fluid drug from the medical device;

[0187] Display devices; and

[0188] At least one memory element, associated with the at least one processor device and storing processor-executable instructions, the processor-executable instructions being configurable by the at least one processor device to perform a method of controlling the operation of the medical device, the method comprising:

[0189] Receive meter-generated values ​​indicating the user's physiological characteristics, the meter-generated values ​​being generated in response to the operation of the analyte instrument;

[0190] A sensor-generated value indicating the user's physiological characteristics is obtained, the sensor-generated value being generated in response to the operation of a continuous analyte sensor device different from the analyte instrumentation device.

[0191] When the meter-generated value is available, the medical device is operated in the first mode to display the valid meter-generated value on the user monitoring screen and the therapeutic delivery control screen on the display device, and the medical device is operated in the first mode to calculate the therapeutic dose for delivery based on the valid meter-generated value;

[0192] When the instrument-generated value is unavailable and the current sensor-generated value meets a first quality standard, the medical device is operated in a second mode to display the current sensor-generated value on the display device, on the user monitoring screen and the therapeutic delivery control screen, and the medical device is operated in the second mode to calculate the therapeutic dose for delivery based on the current sensor-generated value; and

[0193] When a valid instrument value is unavailable and the current sensor value meets the second quality standard but not the first quality standard, the medical device is operated in a third mode to display the current sensor value on the user monitoring screen on the display device, to disable the display of the current sensor value on the therapeutic delivery control screen, and to disable the use of the current sensor value to calculate the therapeutic dose for delivery.

[0194] 11. The medical device according to Clause 10, wherein the method performed by the at least one processor device further comprises:

[0195] When a valid meter-generated value is unavailable and the current sensor-generated value meets the second quality standard but not the first quality standard, the medical device is operated in the third mode to prevent the display of any meter-generated value on the treatment delivery control screen.

[0196] 12. The medical device according to clause 10, wherein the method performed by the at least one processor device further comprises:

[0197] When a valid instrument value is unavailable and the current sensor value meets the second quality standard but not the first quality standard, the medical device is operated in the third mode to display a message on the treatment delivery control screen on the display device, the message indicating that no suitable measurement results for the user's physiological characteristics are available.

[0198] 13. The medical device according to Clause 10, wherein the method performed by the at least one processor device further comprises:

[0199] When a valid meter-generated value is available, the medical device is operated in the first mode to enable the automated therapeutic delivery function;

[0200] When a valid instrument value is unavailable and the current sensor value meets the first quality standard, the medical device is operated in the second mode to enable the automated treatment delivery function; and

[0201] When a valid instrument value is unavailable and the current sensor value meets the second quality standard but not the first quality standard, the medical device is operated in the third mode to disable the automated therapeutic delivery function.

[0202] 14. The medical device according to any one of clauses 10 to 13, wherein the method performed by said at least one processor device further comprises:

[0203] When a valid meter value is available, the medical device operates in the first mode to display the valid meter value on the display device, on the user monitoring screen and the treatment delivery control screen, using a first visually distinguishable characteristic; and

[0204] When a valid instrument value is unavailable and the current sensor value meets the first quality standard, the medical device is operated in the second mode using a second visually distinguishable characteristic that is different from the first visually distinguishable characteristic to display the current sensor value on the display device on the user monitoring screen and the treatment delivery control screen.

[0205] 15. The medical device according to Clause 10, wherein the method performed by the at least one processor device further comprises:

[0206] When a valid instrument value is unavailable and the current sensor value meets the second quality standard but not the first quality standard, the medical device is operated in the third mode to prompt the user to obtain a new instrument value.

[0207] 16. The medical device according to Clause 10, wherein the method performed by the at least one processor device further comprises:

[0208] The delivery of the fluid drug from the medical device is adjusted according to the therapeutic dose calculated when the medical device is operated in the first mode or the second mode.

[0209] 17. The medical device according to any one of clauses 10 to 16, wherein:

[0210] The medical device is an insulin infusion device;

[0211] The fluid drug includes insulin; and

[0212] The physiological characteristic of the user is blood glucose.

[0213] 18. The medical device as described in Clause 17, wherein:

[0214] The user monitoring screen is the main screen of the insulin infusion device; and

[0215] The therapeutic delivery control screen is the insulin bolus delivery control screen of the insulin infusion device.

[0216] 19. A non-transitory computer-readable storage medium comprising program instructions stored thereon, wherein the program instructions are configured to cause at least one processor device to perform a method comprising:

[0217] Receive meter-generated values ​​indicating the user's physiological characteristics, the meter-generated values ​​being generated in response to the operation of the analyte instrument;

[0218] A sensor-generated value indicating the user's physiological characteristics is obtained, the sensor-generated value being generated in response to the operation of a continuous analyte sensor device different from the analyte instrumentation device;

[0219] When a valid meter generated value is available, the medical device is operated in a first mode to display the valid meter generated value on the user monitoring screen of the medical device and the therapeutic delivery control screen of the medical device, and the medical device is operated in the first mode to calculate the therapeutic dose for delivery based on the valid meter generated value;

[0220] When a valid instrument-generated value is unavailable and the current sensor-generated value meets a first quality standard, the medical device is operated in a second mode to display the current sensor-generated value on the user monitoring screen and the therapeutic delivery control screen, and the medical device is operated in the second mode to calculate the therapeutic dose for delivery based on the current sensor-generated value instead of the instrument-generated value; and

[0221] When a valid instrument value is unavailable and the current sensor value meets the second quality standard but not the first quality standard, the medical device is operated in a third mode to display the current sensor value on the user monitoring screen, the medical device is operated in the third mode to disable the display of the current sensor value on the treatment delivery control screen, and the medical device is operated to disable the use of the current sensor value to calculate the dosage of the treatment for delivery.

[0222] 20. The storage medium according to clause 19, wherein the method performed by the at least one processor device further comprises:

[0223] When an effective meter-generated value is available, the medical device is operated in the first mode to enable the automatic therapeutic delivery function using a therapeutic dose calculated based on the effective meter-generated value.

[0224] When a valid instrument-generated value is unavailable and the current sensor-generated value meets the first quality standard, the medical device is operated in the second mode to enable the automated therapeutic delivery function using a therapeutic dose calculated based on the current sensor-generated value instead of the instrument-generated value; and

[0225] When a valid instrument value is unavailable and the current sensor value meets the second quality standard but not the first quality standard, the medical device is operated in the third mode to disable the automated therapeutic delivery function.

[0226] 21. The storage medium according to clause 19, wherein the method performed by the at least one processor device further comprises:

[0227] When a valid meter-generated value is unavailable and the current sensor-generated value meets the second quality standard but not the first quality standard, the medical device is operated in the third mode to prevent the display of any meter-generated value on the treatment delivery control screen, and the medical device is operated in the third mode to display a message on the treatment delivery control screen indicating that no suitable measurement results for the user's physiological characteristics are available.

Claims

1. One or more processor-readable media storing instructions that, when executed by one or more processors, cause the following steps to be performed: Obtain current sensor-generated values ​​indicating the physiological characteristics of the user of the medical device, the current sensor-generated values ​​being generated in response to the operation of the continuous analyte sensor device; Obtain a sensor quality metric that indicates the accuracy of the current sensor-generated value; In response to obtaining a calculated sensor quality metric, the medical device is configured with a quality-specific operating mode, which includes individually adjusting automated basic delivery and automated bolus delivery of fluid drugs based on the obtained sensor quality metric. as well as The delivery of fluid medication from the medical device is adjusted based on the current sensor-generated values ​​and the quality-specific operating mode of the medical device.

2. The processor-readable medium of claim 1, wherein the sensor quality metric is calculated based on information generated or derived by the continuous analyte sensor device.

3. The processor-readable medium of claim 2, wherein the information includes sensor age data, raw sensor signal values, and historical sensor generated values ​​generated in response to operation of the continuous analyte sensor device.

4. The one or more processor-readable media of claim 1, wherein the one or more processor-readable media stores instructions, which, when executed by the one or more processors, further cause the following steps to be performed: The generation of user alerts at the medical device is managed in response to the calculated sensor quality metric.

5. The processor-readable medium of claim 4, wherein the generation of management user alarms comprises: A user alarm is generated when the calculated sensor quality metric meets the alarm generation criteria. as well as User alarms are disabled when the calculated sensor quality metric does not meet the alarm generation criteria.

6. The one or more processor-readable media according to claim 1, wherein: The sensor quality metric is calculated by the continuous analyte sensor device; The current sensor-generated value is obtained from the medical device; and The one or more processor-readable medium storage instructions, when executed by the one or more processors, further cause the following steps to be performed: The calculated sensor quality metric is transmitted from the continuous analyte sensor device to the medical device.

7. The processor-readable medium of claim 1, wherein the calculation of the sensor quality metric is based on: Sensor age data indicating the age of the continuous analyte sensor device; Measurement noise of the raw signal output of the continuous analyte sensor device; as well as The changes in sensor-generated values ​​cannot be attributed to the user's natural physiological condition.

8. One or more processor-readable media according to claim 1, wherein when the sensor quality metric indicates uncertain quality, the quality-specific operating mode enables automatic basic delivery by the medical device, disables the automatic bolus delivery function of the medical device, and prohibits the generation of any user alerts related to the current sensor generated value having uncertain quality.

9. One or more processor-readable media according to claim 1, wherein when the sensor quality metric indicates high quality, the quality-specific operating mode enables automated basic delivery by the medical device, enables the automated bolus delivery function of the medical device, and disables the generation of any user alerts related to the current sensor generated value having high quality.

10. One or more processor-readable media of claim 1, wherein when the sensor quality metric indicates medium quality, the quality-specific operating mode enables automated basic delivery by the medical device, enables limited automated bolus delivery of the medical device, and disables the generation of any user alerts related to the current sensor generated value having medium quality.

11. One or more processor-readable media according to claim 1, wherein when the sensor quality metric indicates low quality, the quality-specific operating mode enables the medical device's secure basic delivery mode, disables the medical device's automatic bolus delivery function, and generates a user alert to prompt the user to take corrective action.

12. One or more processor-readable media according to claim 11, wherein the user alarm prompts the user to calibrate the continuous analyte sensor device.

13. The processor-readable medium of claim 1, wherein configuring a quality-specific operating mode of the medical device includes adjusting the therapeutic action of the medical device such that the positivity of the fluid drug therapy is proportional to the quality of the current sensor-generated value indicated by a calculated sensor quality metric.

14. One or more processor-readable media according to any one of claims 1 to 13, wherein: The medical device is an insulin infusion device; The fluid drug includes insulin; The user's physiological characteristic is glucose level; and The continuous analyte sensor device is a continuous glucose sensor device.

15. A system for delivering a fluid medication to a user of a medical device, the system comprising: One or more processors; and One or more processor-readable media storing instructions that, when executed by one or more processors, cause the following operations to be performed: Obtain current sensor-generated values ​​indicating the physiological characteristics of the user of the medical device, the current sensor-generated values ​​being generated in response to the operation of the continuous analyte sensor device; Obtain a sensor quality metric that indicates the accuracy of the current sensor-generated value; In response to obtaining a calculated sensor quality metric, the medical device is configured with a quality-specific operating mode, which includes individually adjusting automated basic delivery and automated bolus delivery of fluid drugs based on the obtained sensor quality metric. as well as The delivery of fluid medication from the medical device is adjusted based on the current sensor-generated values ​​and the quality-specific operating mode of the medical device.

16. The system of claim 15, wherein the sensor quality metric is obtained from the continuous analyte sensor device.

17. The system of claim 15, wherein the medical device calculates the sensor quality metric based on information generated or derived by the continuous analyte sensor device, the information including: Sensor age data indicating the age of the continuous analyte sensor device; Measurement noise of the raw signal output of the continuous analyte sensor device; as well as The changes in sensor-generated values ​​cannot be attributed to the user's natural physiological condition.

18. The system according to claim 15, wherein: When the sensor quality metric indicates uncertain quality, the quality-specific operating mode enables automated basic delivery by the medical device, disables the automated bolus delivery function of the medical device, and prohibits the generation of any user alerts related to the current sensor generated value with uncertain quality. When the sensor quality metric indicates high quality, the quality-specific operating mode enables automated basic delivery by the medical device, enables the automated bolus delivery function, and disables the generation of any user alerts related to the current sensor value with high quality. When the sensor quality metric indicates medium quality, the quality-specific operating mode enables automated basic delivery by the medical device, enables limited automated bolus delivery, and prohibits the generation of any user alerts related to the current sensor value with medium quality. and When the sensor quality metric indicates low quality, the quality-specific operating mode enables the medical device's safe basic delivery mode, disables the automatic bolus delivery function, and generates a user alert to prompt the user to take corrective action.

19. The system of claim 15, wherein configuring the quality-specific operating mode includes adjusting the therapeutic action of the medical device such that the positivity of the fluid drug therapy is proportional to the quality of the current sensor-generated value indicated by the sensor quality metric.

Images