WO2022204705A1 - Commande de dose de médicament d'urgence - Google Patents

Commande de dose de médicament d'urgence Download PDF

Info

Publication number
WO2022204705A1
WO2022204705A1 PCT/US2022/071308 US2022071308W WO2022204705A1 WO 2022204705 A1 WO2022204705 A1 WO 2022204705A1 US 2022071308 W US2022071308 W US 2022071308W WO 2022204705 A1 WO2022204705 A1 WO 2022204705A1
Authority
WO
WIPO (PCT)
Prior art keywords
therapy
subject
glucose level
insulin
user
Prior art date
Application number
PCT/US2022/071308
Other languages
English (en)
Inventor
Michael J. Rosinko
Firas H. EL-KHATIB
Edward R. DAMIANO
David Chi-Wai LIM
Edward Bacha RASKIN
Original Assignee
Beta Bionics, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/212,984 external-priority patent/US11957876B2/en
Priority claimed from PCT/US2021/072742 external-priority patent/WO2022126080A1/fr
Priority claimed from PCT/US2021/064228 external-priority patent/WO2022140204A1/fr
Priority claimed from PCT/US2022/012795 external-priority patent/WO2022159393A1/fr
Priority claimed from PCT/US2022/017368 external-priority patent/WO2022178447A1/fr
Application filed by Beta Bionics, Inc. filed Critical Beta Bionics, Inc.
Priority to US17/882,469 priority Critical patent/US20230166035A1/en
Publication of WO2022204705A1 publication Critical patent/WO2022204705A1/fr

Links

Classifications

    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
    • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
    • A61M5/168—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body
    • A61M5/172—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body electrical or electronic
    • A61M5/1723—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body electrical or electronic using feedback of body parameters, e.g. blood-sugar, pressure
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/145—Measuring characteristics of blood in vivo, e.g. gas concentration, pH value; Measuring characteristics of body fluids or tissues, e.g. interstitial fluid, cerebral tissue
    • A61B5/14532—Measuring characteristics of blood in vivo, e.g. gas concentration, pH value; Measuring characteristics of body fluids or tissues, e.g. interstitial fluid, cerebral tissue for measuring glucose, e.g. by tissue impedance measurement
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/48—Other medical applications
    • A61B5/4836—Diagnosis combined with treatment in closed-loop systems or methods
    • A61B5/4839—Diagnosis combined with treatment in closed-loop systems or methods combined with drug delivery
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
    • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
    • A61M5/142—Pressure infusion, e.g. using pumps
    • A61M5/14244—Pressure infusion, e.g. using pumps adapted to be carried by the patient, e.g. portable on the body
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
    • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
    • A61M5/168—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body
    • A61M5/16804—Flow controllers
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
    • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
    • A61M5/168—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body
    • A61M5/16831—Monitoring, detecting, signalling or eliminating infusion flow anomalies
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G16H20/17—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered via infusion or injection
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/40—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management of medical equipment or devices, e.g. scheduling maintenance or upgrades
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/30—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for calculating health indices; for individual health risk assessment
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/02—Detecting, measuring or recording pulse, heart rate, blood pressure or blood flow; Combined pulse/heart-rate/blood pressure determination; Evaluating a cardiovascular condition not otherwise provided for, e.g. using combinations of techniques provided for in this group with electrocardiography or electroauscultation; Heart catheters for measuring blood pressure
    • A61B5/024—Detecting, measuring or recording pulse rate or heart rate
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/72—Signal processing specially adapted for physiological signals or for diagnostic purposes
    • A61B5/7271—Specific aspects of physiological measurement analysis
    • A61B5/7275—Determining trends in physiological measurement data; Predicting development of a medical condition based on physiological measurements, e.g. determining a risk factor
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/72—Signal processing specially adapted for physiological signals or for diagnostic purposes
    • A61B5/7271—Specific aspects of physiological measurement analysis
    • A61B5/7282—Event detection, e.g. detecting unique waveforms indicative of a medical condition
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
    • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
    • A61M5/142—Pressure infusion, e.g. using pumps
    • A61M2005/14208—Pressure infusion, e.g. using pumps with a programmable infusion control system, characterised by the infusion program
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/18—General characteristics of the apparatus with alarm
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/35—Communication
    • A61M2205/3546—Range
    • A61M2205/3553—Range remote, e.g. between patient's home and doctor's office
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/35—Communication
    • A61M2205/3546—Range
    • A61M2205/3561—Range local, e.g. within room or hospital
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/35—Communication
    • A61M2205/3546—Range
    • A61M2205/3569—Range sublocal, e.g. between console and disposable
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/35—Communication
    • A61M2205/3576—Communication with non implanted data transmission devices, e.g. using external transmitter or receiver
    • A61M2205/3584—Communication with non implanted data transmission devices, e.g. using external transmitter or receiver using modem, internet or bluetooth
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/50—General characteristics of the apparatus with microprocessors or computers
    • A61M2205/502—User interfaces, e.g. screens or keyboards

Definitions

  • This disclosure relates to glucose level control systems and to ambulatory medical devices (e.g., ambulatory medicament devices including ambulatory medicament pumps) that provide therapy (e.g., medicament) to a subject.
  • ambulatory medical devices e.g., ambulatory medicament devices including ambulatory medicament pumps
  • therapy e.g., medicament
  • Sustained delivery, pump driven medicament injection devices generally include a delivery cannula mounted in a subcutaneous manner through the skin of the subject at an infusion site.
  • the pump draws medicine from a reservoir and delivers it to the subject via the cannula.
  • the injection device typically includes a channel that transmits a medicament from an inlet port to the delivery cannula, which results in delivery to the subcutaneous tissue layer where the delivery cannula terminates.
  • Some infusion devices are configured to deliver one medicament to a subject while others are configured to deliver multiple medicaments to a subject.
  • Glucose level control systems and ambulatory medical devices that provide therapy to a subject, such as glucose level control
  • Disclosed systems and devices can implement one or more features that improve the user experience, such as software update techniques that avoid interrupting delivery of therapy, gesture -based control of therapy delivery, automatic resumption of therapy after a user-initiated pause, improved alarm management, display of autonomously calculated dosing recommendations, wide area network connectivity, and security features, generating emergency dose control signals for commanding administration of modified glucose control therapy to the subject, tracking insulin therapy administered to the subject over a tracking period, storing indications of basal, correction boluses, or mealtime boluses of insulin delivered to the subject, generating backup injection therapy protocol with insulin therapy instructions based at least in part on the insulin therapy administered to the subject over the tracking period.
  • GLCSes glucose level control systems
  • the disclosed GLCSes may include interconnected remote computing systems, mobile electronic devices, and medicament delivery devices that cooperatively improve the glucose control therapy provided to a subject by facilitating various tasks associated with glucose therapy delivery, such as generating emergency dose control signals, tracking insulin therapy administered to the subject, and generating backup injection therapy protocol with insulin therapy instructions.
  • the disclosed GLCSes may include automated systems that autonomously calculate dosing recommendations, generate emergency dose control signals, track insulin therapy administered to the subject, and generate backup injection therapy protocols.
  • FIG. 1A illustrates an example glucose level control system that provides glucose control via an ambulatory medicament pump.
  • FIG. IB illustrates another example glucose level control system that provides glucose control via an ambulatory medicament pump.
  • FIG. 1C illustrates a further example glucose level control system that provides glucose control via an ambulatory medicament pump.
  • FIG. 2A shows a block diagram of an example glucose level control system.
  • FIG. 2B shows a block diagram of another example glucose level control system.
  • FIG. 2C shows a block diagram of another example glucose level control system.
  • FIG. 2D shows a block diagram of another example glucose level control system.
  • FIG. 3 is a schematic of an example glucose level control system that includes an electronic communications interface.
  • FIG. 4A shows a block diagram of an example glucose level control system in online operation mode.
  • FIG. 4B shows a block diagram of an example glucose level control system in offline operation mode.
  • FIG. 5A illustrates a perspective view of an example ambulatory medical device.
  • FIG. 5B illustrates a cross sectional view of the ambulatory medical device shown in FIG. 5 A.
  • FIG. 6 illustrates an example ambulatory medical device or glucose level control system.
  • FIG. 7 illustrates various methods and links that AMD may establish a connection with a host computing system.
  • FIG. 8 is a flow diagram showing an example of a computer-implemented method that may be used by an AMD in order to detect and download an application update.
  • FIG. 9 is a flow diagram showing an example of a computer-implemented method that may be used by an AMD to install a down-loaded application update without interrupting the therapy provided to a subject.
  • FIG. 10 is a flow diagram showing an example of a computer-implemented method that may be used by an AMD to install a second update downloaded from a host computing system and switch control of the AMD from a first application to the second application without interrupting the therapy provided to a subject.
  • FIG. 11 is a flow diagram showing an example of a computer-implemented method that may be used by an AMD to install a second application downloaded from a host computing system, and verify and switch control of the AMD from a first application to the second application without interrupting the therapy provided to a subject, if the second application satisfies a minimum set of operation conditions.
  • FIG. 12 is a flow diagram showing an example of a computer-implemented method that may be used to respond to detection of an application fault during the execution of a first version of an application and switching control of the AMD to a second version an application installed on the AMD.
  • FIG. 13 is a flow diagram showing an example of a computer-implemented method that may be used to respond to detection of an application fault during the execution of a first version of an application and switching control of the AMD to a second version an application installed on the AMD and/or downloading a third version of the application.
  • FIG. 14. is a block diagram, illustrating an example network configuration wherein the AMD is directly connected to a computing system and the computing system shares the therapy reports with one or more display systems and the AMD.
  • FIG. 15 is a flow diagram illustrating an example method that may be used by a computing system, to generate and share a therapy report based on encrypted therapy data received from an AMD.
  • FIG. 16. is a block diagram, illustrating an example network and data flow configuration wherein the AMD is directly connected to a computing system and the computing system generates and sends alerts to one or more display systems and the AMD.
  • FIG. 17 is a flow diagram illustrating an example method that may be used by a computing system, to generate and send an alert to one or more authorized devices.
  • FIG. 18 illustrates the interconnection among modules and procedures in AMD involved in receiving, accepting and/or canceling therapy change request.
  • FIG. 19 is a flow diagram illustrating an example method that may be used by an AMD to allow a user to change the configuration of the ambulatory medicament device using a touch screen user interface.
  • FIG. 20A is an illustration of the touchscreen display of an example AMD after the touch screen is waked/unlocked by a wake action of a user and before the first user gesture is received.
  • FIG. 20B is an illustration of an example touchscreen display that may prompt the user to enter a predetermined series of inputs for the first gesture or second gesture.
  • FIG. 20C is an illustration of an example therapy change user interface.
  • FIG. 20D is an illustration of another therapy change user interface on a touchscreen display.
  • FIG. 21 is a flow diagram illustrating an example method that may be used by an AMD to generate an alarm status indicator.
  • FIG. 22 is a flow diagram illustrating an example method that may be used to cancel a therapy change using a touchscreen interface.
  • FIG. 23A is an illustration of a touchscreen display alerting the user that the delivery of one or more medicaments will occur.
  • FIG. 23B is an illustration of a touchscreen display showing that a medicament is being delivered to the user.
  • FIG. 24 is a block diagram illustrating the interconnection among modules and procedures in AMD involved in receiving, accepting and/or canceling a therapy suspension request.
  • FIG. 25 is a flow diagram illustrating an example method for receiving and implementing a suspension request, which may be implemented by an AMD
  • FIG. 26 illustrates a plurality of screens that the ambulatory medical device may display when a user pauses therapy.
  • FIG. 27 is a flow diagram illustrating an example method of resuming a suspended therapy that may be implemented by an AMD.
  • FIG. 28 illustrates a plurality of screens that the ambulatory medical device may display when a user resumes therapy.
  • FIG. 29 is a block diagram illustrating the interconnection among modules and procedures in AMD involved in changing the settings of the AMD.
  • FIG. 30 is a flow diagram illustrating an example method that may be used by an AMD to allow a user to change a setting of the AMD using a user generated passcode or an override passcode.
  • FIG. 31 is a flow diagram illustrating an example method that may be used by an AMD to allow a user to change a setting of the AMD using a user generated passcode or an override passcode.
  • FIG. 32 is a schematic diagram illustrating the interconnection among modules and procedures in AMD involved in monitoring the status of the AMD and/or the subject and generate alarms when an alarm condition is met.
  • FIG. 33 is a flow diagram illustrating an example procedure that may be used by the alarm system of an AMD to annunciate an alarm condition upon receiving a status information that satisfies an alarm condition.
  • FIG. 34 is a block diagram illustrating the interconnection among modules and procedures in AMD involved in monitoring the condition of the AMD and generating alerts when a device malfunction is detected.
  • FIG. 35 is a flow diagram illustrating an example procedure that may be used by the alert system of an AMD to monitor the operation of an AMD and generate alerts when a device malfunction is detected.
  • FIG. 36 is a schematic diagram illustrating an ambulatory medical device that provides the user with various options for providing medicament.
  • FIG. 37 is a flow diagram of a process for providing options for meal dosage selection on an ambulatory device.
  • FIG. 38 is another flow diagram of a process for providing options for meal dosage selection on an ambulatory device.
  • FIG. 39 is a series of screen displays showing a user initiating the activation of meal dosage on an ambulatory device.
  • FIG. 40 is a series of screen displays showing a user activating meal dosage on an ambulatory device.
  • FIG. 41 is a series of screen displays showing a user activating meal announcement on an ambulatory device.
  • FIG. 42 is a series of screen displays showing a user inputting the total number of units on an ambulatory device.
  • FIG. 43 is a series of screen displays showing an ambulatory medical device delivering the units and cancelling the delivery of the units.
  • FIG. 44 is a schematic illustrating a computer system that can be implemented in various embodiments of the described subject matter.
  • FIG. 45 shows an example glucose level control system configured to configured to modify a manual therapy instruction and to generate an emergency dose control signal.
  • FIG. 46 shows a flow diagram illustrating an example method that may be used by a control system to generate an emergency dose control signal for commanding administration of modified glucose control therapy to a subject via a medicament pump.
  • FIG. 47 illustrates a block diagram of a glucose level control system in accordance with certain embodiments.
  • FIG. 48 illustrates a block diagram of a controller system in accordance with certain embodiments.
  • FIG. 49 presents a flowchart of an example carbohydrate therapy equivalence tracking process in accordance with certain embodiments.
  • FIG. 50 presents a flowchart of an example backup therapy protocol generation process in accordance with certain embodiments.
  • FIG. 51 presents a flowchart of an example control parameter modification tracking process in accordance with certain embodiments.
  • FIG. 52 illustrates an example backup therapy protocol in accordance with certain embodiments.
  • FIG. 53 illustrates an example control parameter modification report in accordance with certain embodiments.
  • FIG. 54 illustrates an example meal selection report that may be included as part of some implementations of the control parameter modification report of FIG. 53 in accordance with certain embodiments.
  • FIG. 55 presents a flowchart of an example automated glucose level control refinement process in accordance with certain embodiments.
  • FIG. 56A illustrates a simulation of glucose level control of a subject with Tmax set to 65 minutes.
  • FIG. 56B illustrates a simulation of glucose level control of a subject with Tmax set to 15 minutes.
  • FIG. 56C illustrates a simulation of glucose level control of a subject with Tmax set to 130 minutes.
  • FIG. 57 illustrates an example of glucose level signal (CGM trace) and some of the parameters associated with glycemic control using a glucose level control system.
  • FIG. 58 presents a flowchart of an example automated glucose level control refinement process based on an adjustment function in accordance with certain embodiments.
  • FIG. 59 illustrates some examples of statistical quantities that may be generated and utilized by the glucose level control system as part of statistical analysis.
  • FIG. 60 presents a flowchart of an example automated glucose level control refinement process in accordance with certain embodiments
  • Some embodiments described herein pertain to medicament infusion systems for one or more medicaments and the components of such systems (e.g., infusion pumps, medicament cartridges, cartridge connectors, lumen assemblies, infusion connectors, infusion sets, etc.). Some embodiments pertain to methods of manufacturing infusion systems and components thereof. Some embodiments pertain to methods of using any of the foregoing systems or components for infusing one or more medicaments (e.g., pharmaceutical, hormone, etc.) to a subject.
  • an infusion system may include an infusion pump, which can include one or more medicament cartridges or can have an integrated reservoir of medicament.
  • An infusion system may include medicament cartridges and cartridge connectors, but not a pump.
  • An infusion system may include cartridge connectors and an infusion pump, but not medicament cartridges.
  • An infusion system may include infusion connectors, a lumen assembly, cartridge connectors, an infusion pump, but not medicament cartridges or an infusion set.
  • a glucose level control system can operate in conjunction with an infusion system to infuse one or more medicaments, including at least one glucose control agent, into a subject.
  • Any feature, structure, component, material, step, or method that is described and/or illustrated in any embodiment in this specification can be used with or instead of any feature, structure, component, material, step, or method that is described and/or illustrated in any other embodiment in this specification. Additionally, any feature, structure, component, material, step, or method that is described and/or illustrated in one embodiment may be absent from another embodiment.
  • a glucose level control system is used to control the glucose level in a subject.
  • the glucose level may comprise a blood glucose level, or a glucose level in other fluids in a subject’s body.
  • the glucose level may comprise a physiological glucose level of the subject that can be a concentration of glucose in the subject’s blood (herein referred to as “blood glucose level”) or in an interstitial fluid in part of the subject’s body (e.g., expressed in milligram per deciliter (mg/dl or mg/dL)).
  • a glucose level may comprise a measured or an estimated glucose level.
  • the measured glucose level can be correlated to the blood glucose level of the subject.
  • an estimated glucose level can be an estimated concentration of glucose in subject’s blood.
  • Glucose level control systems can include a controller configured to generate dose control signals for one or more glucose control agents that can be infused into the subject.
  • Glucose control agents can be delivered to a subject via subcutaneous injection, via intravenous injection, or via another suitable delivery method.
  • Glucose control agents may include regulatory agents that tend to decrease glucose level (e.g., blood glucose level) of the subject, such as insulin and insulin analogs, and counter-regulatory agents that tend to increase glucose level, such as glucagon or dextrose.
  • a glucose control system configured to be used with two or more glucose control agents can generate a dose control signal for each of the agents.
  • a glucose level control system can generate a dose control signal for an agent even though the agent may not be available for dosing via a medicament pump connected to the subject.
  • a GLCS may include or can be connected to an ambulatory medicament pump.
  • An ambulatory medicament pump (AMP) or a medicament pump is a type of ambulatory medical device (“AMD”), which is sometimes referred to herein as an ambulatory device, an ambulatory medicament device, a mobile ambulatory device.
  • ambulatory medical devices may include ambulatory medicament pumps and other devices configured to be carried by a subject and to deliver therapy to the subject. Multiple embodiments of an AMD are described herein. It should be understood that one or more of the embodiments described herein with respect to one AMD may be applicable to one or more of the other AMDs described herein.
  • a GLCS can include a therapy administration system and an AMD that is in communication with the therapy administration system.
  • the AMD may comprise an AMP.
  • a GLCS implements algorithms, and medicament or glucose control functionality discussed herein to provide medicament or glucose control therapy without being connected to an AMD.
  • the GLCS can provide instructions or dose outputs that direct a user to administer medicament to provide glucose control therapy.
  • the user may use, for example, a medicament pen to manually administer, or self-administer, the medicament according the GLCS’s dose outputs.
  • the user may provide inputs such as glucose level readings into the GLCS, and the GLCS may provide or output an indication of medicament doses.
  • the user inputs to the GLCS may be combined with inputs from other systems or devices such as sensors as discussed herein.
  • the GLCS can provide glucose control therapy based on user inputs without other system or device inputs.
  • the GLCS includes a memory that stores specific computer-executable instructions for generating a dose recommendation and/or a dose control signal.
  • the dose recommendation and/or the dose control signal can assist with glucose level control of a subject via medicament therapy.
  • the dose recommendation or dose output of the GLCS can direct a user to administer medicament to provide medicament therapy for glucose level control, including manual administration of medicament doses.
  • the GLCS includes the memory and a delivery device for delivering at least a portion of the medicament therapy.
  • the GLCS includes the memory, the delivery device, and a sensor configured to generate a glucose level signal. The GLCS can generate the dose recommendation and/or the dose control signal based at least in part on the glucose level signal.
  • control parameters can include subject- specific parameters, delivery device-specific parameters, glucose sensor- specific parameters, demographic parameters, physiological parameters, other parameters that can affect the glucose level of the subject, or any combination of one or more of the foregoing.
  • the ambulatory medical device is an electrical stimulation device, and therapy delivery includes providing electrical stimulation to a subject.
  • An example of an electrical stimulation device is a cardiac pacemaker.
  • a cardiac pacemaker generates electrical stimulation of the cardiac muscle to control heart rhythms.
  • Another example of an electrical stimulation device is a deep brain stimulator to treat Parkinson’s disease or movement disorders.
  • FIG.1A-FIG.1C show examples of glucose level control systems that provide glucose level control therapy via an ambulatory medical device (AMD), such as an ambulatory medicament pump (AMP) connected to a subject.
  • AMD ambulatory medical device
  • AMP ambulatory medicament pump
  • the AMD 100 may be connected to an infusion site 102 using an infusion set 104.
  • the AMD 100 may include a medicament pump that may have integrated pump controls accessible via a user interface 106a.
  • the user interface 106a may permit a user to view pump data and change therapy settings via user interaction with the pump controls via the user interface 106a.
  • a glucose level sensor 110 can generate a glucose level signal that is received by the glucose level control system.
  • the glucose level control system may receive an insulin level signal from an insulin level sensor.
  • the glucose level sensor 110 may include a continuous glucose monitor (CGM).
  • CGM continuous glucose monitor
  • the glucose level control system includes the AMD 100 (e.g., a medicament pump) that communicates with an external electronic device 108 (such as, for example, a smartphone) via a wireless data connection. At least some of the pump controls can be manipulated via user interaction with user interface elements in the user interface 106a or user interface 106b of the external electronic device 108.
  • the glucose level sensor 110 can also communicate with the AMD 100 via a wireless data connection.
  • the AMD 100 (e.g., a medicament pump) includes an integrated cannula that inserts into the infusion site 102 without a separate infusion set.
  • At least some of the pump controls can be manipulated via user interaction with user interface elements of the user interface 106b of an external electronic device 108.
  • pump controls can be manipulated via user interaction with user interface elements generated by a remote computing environment (not shown), such as, for example, a cloud computing service, that connects to the AMD 100 via a direct or indirect electronic data connection.
  • Glucose level control systems typically include a user interface configured to provide one or more of therapy information, glucose level information, and/or therapy control elements capable of changing therapy settings via user interaction with interface controls.
  • the user can provide an indication of the amount of the manual bolus of medicament from an electronic device remote from the medicament pump.
  • the user interface can be implemented via an electronic device that includes a display and one or more buttons, switches, dials, capacitive touch interfaces, touchscreen interfaces, or voice interfaces.
  • at least a portion of the user interface is integrated with an ambulatory medicament pump that can be tethered to a body of a subject via an infusion set configured to facilitate subcutaneous injection of one or more glucose level control agents.
  • at least a portion of the user interface is implemented via an electronic device separate from the ambulatory medicament pump, such as a smartphone.
  • FIG. 2A-FIG. 2D illustrate block diagrams showing example configurations of four different embodiments (200a/200b/200c/200d) of a glucose level control system.
  • a glucose level control system 200a may comprise an ambulatory medical device (AMD) 100 that includes a controller 202a having an electronic processor 204a and a memory 210a that stores instructions 208a executable by the processor 204a.
  • the controller 202a and a pump 212 can be integrated into AMD 100.
  • the pump 212 can be an infusion pump for administering regulatory agent and/or counter-regulatory agent.
  • the AMD 100 can include at least one pump 212.
  • the AMD 100 may include at least one pump and a wireless connection interface or a transceiver.
  • the AMD 100 can include a wireless electronic communications interface (e.g., a transceiver 214a) for wireless data (e.g., digital data) communications with external electronic devices.
  • a wireless electronic communications interface e.g., a transceiver 214a
  • wireless data e.g., digital data
  • the controller 202a can implement at least a portion of a control algorithm that generates dose control signals for one or more glucose level control agents based on time-varying glucose levels of the subject (e.g., received from a glucose level sensor 110 that is in communication with the AMD 100) and one or more control parameters.
  • the dose control signals when delivered to the pump 212, result in dosing operations that control the glucose level of the subject.
  • the pump 212 may be controlled by at least one pump controller.
  • the pump controller may be included in the pump 212.
  • the pump controller receives the dose control signals and controls the operation of the pump 212 based on the received dose control signals.
  • the pump controller may be integrated with the pump.
  • the controller may be included in the AMD 100, or in an external electronic device 108 or a remote computer 206, that are connected to the AMD 100 via wired or wireless communication links.
  • a glucose level control system may comprise an ambulatory medicament pump AMD 100 (also referred to as ambulatory medicament pump or AMP) that includes a medicament pump, and at least one controller that controls the medicament pump.
  • the controller may be included in the AMD 100, or in an external electronic device 108 or a remote computer 206, that are connected to the AMD 100 via wired or wireless communication links.
  • a glucose level control system 200b can operate at least partially via execution of instructions 208b by an electronic processor 204b of an electronic device 108 (e.g., an external electronic device) separate from the AMD 100.
  • the electronic device 108 can include a transceiver 214b capable of establishing a wireless data connection (e.g., digital data connection) to the AMD 100, and a controller 202b can implement at least a portion of a control algorithm via execution of instructions 208b stored in memory 210b.
  • the controller 202b can implement at least a portion of a control algorithm that generates dose control signals for one or more glucose level control agents based on time-varying glucose levels of the subject and one or more control parameters.
  • the dose control signals when delivered to the pump 212 (e.g., to the pump controller of the pump 212), result in dosing operations that control the glucose level of a subject.
  • the dose control signals are transmitted from the transceiver 214b of the electronic device 108 to the transceiver 214a of the AMD 100 over a short-range wireless data connection 216.
  • the AMD 100 receives the dose control signals and passes them to the pump 212 for dosing operations.
  • a glucose level control system 200c may include a remote computer 206 that is in communication with the AMD 100 (e.g., an ambulatory medicament pump).
  • the glucose level control system 200c can operate at least partially via execution of instructions 208c on an electronic processor 204c integrated with a remote computer 206, such as, for example, a cloud service (e.g., remote computing environment).
  • a cloud service e.g., remote computing environment.
  • the controller 202c can implement at least a portion of a control algorithm that generates dose control signals for one or more glucose level control agents based on time-varying glucose levels of the subject and one or more control parameters.
  • the dose control signals when delivered to the pump controller of the pump 212 may result in dosing operations that control the glucose of a subject.
  • the dose control signals are transmitted from the remote computer 206 via WAN connection interface 220c to the AMD WAN connection interface 220a over an end-to-end wireless data connection 218.
  • the AMD 100 receives the dose control signals and passes them to the pump 212 (or the pump controller of the pump 212) for dosing operations.
  • a glucose level control system 200d may include a remote computer 206 that is in communication with an external electronic device 108 (e.g., an electronic device of the subject), and the AMD 100, which is in communication with the electronic device 108.
  • the glucose level control system can have two or more controllers 202a, 202b, 202c (e.g., located in different subsystems) that cooperate to generate a dose control signal for dosing operations by the pump 212.
  • the remote computer 206 can transmit or receive data or instructions passed through a WAN connection interface 220c via a wireless data connection 218 to a WAN connection interface 220b of the external electronic device 108.
  • the external electronic device 108 can transmit or receive data or instructions passed through a transceiver 214b via a short-range wireless data connection 216 to a transceiver 214a of an AMD 100.
  • the external electronic device 108 can be omitted, and the controllers 202a, 202c of the AMD 100 and the remote computer 206 cooperate to generate dose control signals that are passed to the pump 212 (or the pump controller that controls pump 212).
  • the AMD 100 may have its own WAN connection interface 220a to support a direct end-to-end wireless data connection to the remote computer 206.
  • the glucose level control system may include circuitry that implements an electronic communications interface (ECI) 302 configured to send and receive electronic data from one or more electronic devices.
  • ECI includes a sensor interface 304 configured to receive a glucose level signal from a sensor 110 such as a continuous glucose monitor (CGM). Some CGMs generate the glucose level signal at fixed measurement intervals, such as five-minute intervals.
  • the sensor 110 can be operatively connected to a subject in order to generate a glucose level signal that corresponds to a glucose estimate or measurement of the subject.
  • the glucose level signal can be used by the controller 202a to generate a dose control signal.
  • the dose control signal can be provided to a pump 212 via a pump interface 306.
  • the sensor interface 304 connects to the sensor 110 via a short-range wireless connection 308.
  • the pump interface 306 connects to the pump 212 via a short-range wireless connection 310.
  • the pump interface 306 connects to the pump 212 via a local data bus, such as when the controller 202, the ECI 302, and the pump 212 are integrated into an AMD 100.
  • the controller 202a can be configured to generate the dose control signal using a control algorithm that generates at least one of a basal dose, a correction dose, and/or a meal dose.
  • control algorithms that can be used to generate these doses are disclosed in U.S. Patent Application Publication Nos. 2008/0208113, 2013/0245547, 2016/0331898, 2018/0220942, and PCT Patent Application Publication No. WO 2021/067856 (referenced herein as the “Controller Disclosures”), the entire contents of which are incorporated by reference herein and made a part of this specification.
  • the correction dose can include regulatory or counter-regulatory agent and can be generated using a model-predictive control (MPC) algorithm and/or other algorithms such as those disclosed in the Controller Disclosures.
  • the basal dose can include regulatory agent and can be generated using a basal control algorithm such as disclosed in the Controller Disclosures.
  • the meal dose can include regulatory agent and can be generated using a meal control algorithm such as disclosed in the Controller Disclosures. In some cases, a meal dose can be generated by the subject via a user interface of the glucose level control system 200a/200b/200c/200d. Additional aspects and improvements for at least some of these controllers are disclosed herein.
  • the dose control signal can be transmitted to a pump interface 306 via the ECI 302 or can be transmitted to the pump interface 306 via an electrical conductor when the controller 202a is integrated in the same housing as the pump interface 306. Transmitting the dose control signal to the pump interface 306 may cause an infusion motor pump of an ambulatory medicament pump to administer medicament to the subject.
  • FIG. 4A shows a block diagram of an example glucose level control system in online operation mode.
  • the controller 400 can be configured to operate in “online mode” (or “automatic mode”) during time periods when the controller 400 receives a glucose level signal 402 from the sensor 110 (e.g., a glucose level sensor). Alternatively or in addition, in some cases, the controller 400 may receive an insulin level signal from the sensor 110 or another sensor operatively connected to the subject.
  • the control algorithm In online mode, the control algorithm generates a dose control signal 404 that implements regular correction doses based on values of the glucose level signal 402 (and/or an insulin level signal) and control parameters of the control algorithm.
  • the pump 212 can be configured to deliver at least correction doses and basal doses to the subject without substantial user intervention while the controller 400 remains in online mode.
  • the ambulatory medicament pump 212 can include one or more medicament cartridges or can have an integrated reservoir 408 of medicament.
  • the reservoir 408 may be integrated with the pump 212.
  • a medicament stored in the reservoir 408 can be delivered to the subject by operation of the pump 212.
  • the operation of the pump 212 can be controlled by the controller 400.
  • the controller 400 can be configured to operate in “offline mode” during time periods when the controller does not receive a glucose level signal 402 (and/or an insulin level signal) from a sensor 110, at least during periods when the glucose level signal 402 is expected but not received.
  • the controller may generate dose control signals as described in U.S. Patent No. 10,543,313, the entire contents of which are hereby incorporated by reference in its entirety herein.
  • the control algorithm In offline mode, the control algorithm generates a dose control signal 404 that implements correction doses in response to isolated glucose measurements 406 (such as, for example, measurements obtained from the subject using glucose test strips), and/or isolated insulin measurements, and based on control parameters of the control algorithm.
  • the pump 212 is configured to deliver basal doses to the subject without substantial user intervention and can deliver correction doses to the subject in response to isolated glucose measurements 406 while the controller 400 remains in offline mode.
  • the ambulatory medical device can be a portable or wearable device (e.g., an insulin or bi-hormonal medicament pump) such as an ambulatory medicament pump (AMP) that provides life-saving treatment to a subject by delivering one or more medicaments (e.g., insulin and/or glucagon) to a subject.
  • a portable or wearable device e.g., an insulin or bi-hormonal medicament pump
  • AMP ambulatory medicament pump
  • Some AMDs may continuously monitor a health condition of a subject (e.g., glucose level, insulin level, heart rate, etc.) using a sensor (e.g., a glucose level sensor that can measure values corresponding to the glucose level, or an insulin level sensor that can measure values corresponding to the blood insulin level, etc.) and deliver therapy (e.g., one or more medicaments) to the subject based at least in part on the health condition of the subject and/or physiological characteristics of the subject.
  • a sensor e.g., a glucose level sensor that can measure values corresponding to the glucose level, or an insulin level sensor that can measure values corresponding to the blood insulin level, etc.
  • therapy e.g., one or more medicaments
  • an AMP e.g., an insulin pump or a bi-hormonal pump
  • CGM Continuous Glucose Monitor
  • Certain AMDs may be worn by subjects constantly (e.g., all day), or for a large portion of the day (e.g., during waking hours, during sleep hours, when not swimming, etc.) to enable continuous monitoring of the health condition of the subject and to deliver medicament as necessary.
  • an AMD may be an ambulatory medicament device such as a medicament delivery pump.
  • an AMD may be a device that provides therapy in the form of electrical stimulation based on a health condition of a subject (e.g., heart rhythm or brain activity) determined using signals received from one or more sensors (e.g., heartbeat monitor or electrodes monitoring activity of the brain).
  • FIG. 5A illustrates a three-dimensional (3D) view of an example ambulatory medical device (AMD) 500 (such as an ambulatory medicament pump) comprising a housing 502 with a wake button 506 and a touchscreen display 504.
  • FIG. 5B is an illustration of a cross sectional view of the ambulatory medical device 500 shown in FIG. 5A.
  • the wake button 506 may be any type of button (e.g., capacitive, inductive, resistive, mechanical, etc.) that registers an input generated by user interaction with the wake button 506 to generate a wake signal.
  • a wake signal may be a signal that activates a user interface of the AMP (e.g., a touchscreen display).
  • the wake button 506, if touched, pressed, or held for a period, may generate the wake signal that activates the touchscreen display 504.
  • the wake signal is generated by a sensor (e.g., a biometric sensor such as a fingerprint reader or a retinal scanner, an optical or RF proximity sensor, and the like).
  • the wake signal may be generated by user interaction with the touch screen display 504 or with an alphanumeric pad (not shown).
  • wake signal may be generated based on facial recognition or other biometric indicia.
  • the wake signal may be generated by a wireless signal such as a signal generated by an RFID system or Bluetooth signals received from an electronic device, or by detection of movement using one or more motion sensors such as an accelerometer.
  • the wake button 506, if touched, pressed, or held for a certain period of time, may generate a wake signal that activates the touchscreen display 504.
  • touches on the touchscreen display 504 are not registered until the wake button activates the touchscreen display.
  • the AMD remains locked from accepting at least certain types of user interaction or settings modification until a gesture (such as, for example, any of the gesture interactions described with reference to any of the embodiments disclosed herein) is received after the touchscreen display 504 is activated by the wake button 506.
  • a passcode may be required to unlock the touchscreen display.
  • the AMD 500 includes a microphone and a speaker for receiving a sound (e.g., user’s voice) and outputting a sound, respectively. In this case, a user can wake up the touchscreen by a voice input.
  • FIG. 6 illustrates different modules or systems that may be included in an example glucose control system (GLCS) or an AMD (e.g., AMD 500).
  • GLCS glucose control system
  • AMD e.g., AMD 500
  • the AMD (or GLCS) 600 may comprise a complete glucose level control system (e.g., glucose level control system 200a/200b/200c/200d), or can include one or more components of a complete glucose level control system (e.g., a medicament pump, a transceiver, and/or a controller).
  • a complete glucose level control system e.g., glucose level control system 200a/200b/200c/200d
  • a complete glucose level control system e.g., a medicament pump, a transceiver, and/or a controller.
  • the AMD 600 may include one or more modules or systems that can facilitate monitoring a subject’s glucose level (e.g., glucose level in an interstitial fluid of the subject, or subject’s glucose level), monitoring a subject’s insulin level, managing the subject’s diabetes, tracking a condition of the AMD 600, tracking usage of infusion sets, tracking usage of analyte sensors, and/or communicating with one or more computing systems (e.g., remote computing systems).
  • the AMD (or GLCS) 600 may include a mono-hormonal or bi-hormonal medicament pump configured to administer one or more types of insulin and, in some cases, counter-regulatory agent (e.g., Glucagon or other medicament that can reduce or address hypoglycemia).
  • the AMD 600 may include one or more alarm generators, transceivers, touchscreen controllers, display controllers, encryption modules, etc.
  • two or more of the modules or systems may be integrated together inside a single housing 502 (as shown in FIG. 5A and 5B).
  • one or more modules may be individual modules contained in separate housings that communicate with other modules or systems, and/or with the main unit via a wired or wireless communication links (e.g., Bluetooth).
  • the modules included in the AMD 600 may include a communication module 602, signal processing module 604, a therapy (or medicament) therapy delivery module 606, a user interface module 608, and a control and computing module (CCM) 610.
  • CCM control and computing module
  • control and computing module 610 can be the same or similar in at least some respects to the other glucose control system controllers described herein, including, for example, the controllers 202a-c, and 400 described with reference to FIGS. 2A-D and 4A-B.
  • one or more modules may comprise one or more single purpose or multipurpose electronic systems. In some such examples, one or more electronic systems may perform procedures associated with different features of the AMD 600.
  • one or more modules or systems may comprise a non-transitory memory that stores machine readable instructions and a processor that executes instructions stored in the memory.
  • the memory may be a non-volatile memory, such as flash memory, a hard disk, magnetic disk memory, optical disk memory, or any other type of non-volatile memory. Further, types of memory may include but are not limited to random access memory (“RAM”) and read-only memory (“ROM”). In some such examples, a system can be programed to perform different procedures each implemented based on a different set of instructions.
  • RAM random access memory
  • ROM read-only memory
  • the therapy delivery module 606 may be an external medicament delivery system that is in communication with the control and computing module 610, e.g., via the communication module 602 (e.g., via a wired or wireless link).
  • the therapy delivery module 606 may be included in the same housing as other systems and subsystems of the AMD 600.
  • AMD 600 may include a therapy delivery interface configured to transmit dose control signals to the external therapy delivery system and receive signals indicating the status of the external therapy delivery system and/or medicament delivery.
  • the therapy delivery interface may be included in the communication module 602.
  • the external therapy delivery module may communicate with the AMD 600 using a wireless transceiver included in the external therapy delivery module.
  • the control and computing module (CCM) 610 may include one or more processors 614, a main memory 616, a storage 618 that may comprise one or more non- transitory memories and an interface 612 that enables data and signal communication among the components within the control and computing module 610 as well as communication between the control and computing module 610 and all other modules of the AMD.
  • the main memory 616 and the storage 618 each may be divided into two or more memory locations or segments.
  • the main memory 616 may communicate with the other components of the control and computing module 610 as well as other modules through the interface 612. Instructions may be transmitted to the main memory (e.g., from the storage) and the processor 614 may execute instructions that are communicated to the processor via the main memory 616.
  • the storage 618 may store data while the control and computing module 610 is powered or unpowered.
  • the storage 618 may exchange data with sub-systems within the control and computing module 610 as well as other systems (e.g., via the interface 612). In some cases, the. In some cases, the storage 618 may exchange data with the main memory directly or through the interface 612.
  • the main memory 616 can be any type of memory that can store instructions and communicate them to the processor 614 and receive executed instructions from the processor 614. Types of main memory include but are not limited to random access memory (“RAM”) and read-only memory (“ROM”).
  • the processor 614 may be any type of general-purpose central processing unit (“CPU”).
  • control and computing module may include more than one processor of any type including, but not limited to complex programmable logic devices (“CPLDs”), field programmable gate arrays (“FPGAs”), application-specific integrated circuits (“ASICs”) or the like.
  • the storage 618 can be any type of computer storage that can receive data, store data, and transmit data to the main memory 616 and possibly other modules of AMD 600. Types of storage 618 that can be used in the control and computing module 610 include, but are not limited to, magnetic disk memory, optical disk memory, flash memory and the like.
  • the interface 612 may include data transfer buses and electronic circuits configured to support data exchange among different components within the control and computing module 610. In some embodiments, in addition to the data exchange between any of the systems of the control and computing module 610, the interface 612 may also support data and signal exchange with other systems as well as data exchange between any of the systems of the control and computing module 610.
  • the signal processing module 604 may include a plurality of interconnected electronic modules for signal conditioning and signal conversion (e.g., for A-to-D or ADC conversion and/or D-to-A or DAC conversion) configured to support communication and data exchange between different modules.
  • the signal processing module 604 may convert an analog signal received from the communication module 602 and convert it to a digital signal that can be transmitted to the control and computing module 610 (e.g., via the interface 612).
  • the control and computing module 610 may further process the digital signal and control one or more modules based on the processed signal.
  • the signal processing module 604 may receive a digital control signal from the control and computing module 610 and convert it to a dose control signal (e.g., an analog dose control signal) that can be transmitted to the therapy delivery module 606, for example, to control one or more infusion pumps included in the therapy delivery module.
  • a dose control signal e.g., an analog dose control signal
  • the therapy delivery module 606 may comprise one or more infusion pumps configured to deliver one or more medicaments (e.g., insulin, glucagon, etc.) to a subject 622 and a pump controller that may activate the infusion pumps upon receiving dose control signals.
  • the medicaments may be stored in one or more medicament cartridges housed in the therapy delivery module 606.
  • medicaments may be stored in a cavity of the therapy delivery module 606.
  • the therapy delivery module 606 may include electronic and mechanical components configured to control the infusion pumps based on the signals received from control and computing module 610 (e.g., via the signal processing module 604 or the interface 612).
  • the therapy delivery module 606 may include a pump controller that controls the infusion pumps upon receiving dose control signals from the control and computing module 610.
  • the user interface module 608 may include a display to show various information about the AMD 600, for example, medicament type and delivery schedule, software status, and the like.
  • the display may show graphical images and text using any display technology including, but not limited to OLED, LCD, or e-ink.
  • the AMD 600 may include a user interface (e.g., an alphanumeric pad) that lets a user enter information or interact with the AMD 600 to modify the settings of the AMD 600, respond or submit to request(s) for certain actions (e.g., modifying control parameters, entering manual meal doses, ordering infusion sets, sensors, transmitters, replacement components).
  • the user interface module 608 may include a user interface that allows a user to install or update a software.
  • the alphanumeric pad may include a multitude of keys with numerical, alphabetical, and symbol characters.
  • the keys of the alphanumeric pad may be capacitive or mechanical.
  • the user may be a subject 622 receiving medicament or therapy, or may be another user, such as a clinician or healthcare provider, or a parent or guardian of the subject 622.
  • the AMD 600 may include a touchscreen display that produces output and accepts input enabling a two-way interaction between the user and the AMD 600.
  • the touchscreen display may be any input surface that shows graphic images and text and registers the position of touches on the input surface.
  • the touchscreen display may accept input via capacitive touch, resistive touch, or other touch technology.
  • the input surface of the touchscreen display can register the position of touches on the surface.
  • the touchscreen display can register multiple touches at once.
  • the user interface may be a digital keypad displayed on a user interface screen.
  • an alphanumeric pad comprising user-selectable letters, numbers, and symbols may be displayed on the touchscreen display.
  • the touchscreen may present one or more user- interface screens (e.g. as described in reference to FIGS. 20, 26, and 28) to a user enabling the user to modify one or more therapy settings of the ambulatory medicament device, order additional infusion sets, order additional analyte sensors, order a replacement AMD, etc.
  • a user-interface screen may comprise one or more parameter control elements.
  • a user- interface screen may include one or more user input elements displayed on the screen that enable a user to interact with the AMD 600.
  • a user-interface screen may comprise one or more therapy control elements (e.g., displayed on the touchscreen display) enabling a user or the subject to access therapy change controls and modify therapy settings by interacting with these control elements.
  • the user can modify the therapy settings by changing one or more control parameters using the corresponding therapy control elements.
  • a therapy control parameter may include any parameter that controls or affects the volume, duration and/or the frequency of medicament doses delivered to the subject.
  • the user interface module 608 may include an audio or auditory sensor and system such as a speaker and a microphone for voice recognition.
  • a user can verbally interact with the AMD 600 without physically touching the device.
  • the verbal interaction may reduce gesture motion of the user for controlling the AMD 600.
  • “voice recognition” may refer to identifying the speaking user and/or the speech of the user. Recognizing the user who is speaking can simplify the task of translating speech in systems that have been trained on a specific user’s voice or it can be used to authenticate or verify the identity of a speaker as part of a security process.
  • the communication module 602 may include one or more wireless transceivers, one or more antennas and one or more electronic systems (e.g., front end modules, antenna switch modules, digital signal processors, power amplifier modules, etc.) that support communication over one or more communication links and/or networks.
  • each transceiver may be configured to receive or transmit different types of signals based on different wireless standards via the antenna (e.g., an antenna chip).
  • the transceiver may support communication using a low power wide area network (LPWAN) communication standard.
  • LPWAN low power wide area network
  • the transceiver may support communication with wide area networks (WANS) such as a cellular network transceiver that enables 3G, 4G, 4G-LTE, or 5G.
  • the transceiver may support communication via a Narrowband Long-Term Evolution (NB-LTE), a Narrowband Internet-of-Things (NB-IoT), or a Long-Term Evolution Machine Type Communication (LTE-MTC) communication connection with the wireless wide area network.
  • NB-LTE Narrowband Long-Term Evolution
  • NB-IoT Narrowband Internet-of-Things
  • LTE-MTC Long-Term Evolution Machine Type Communication
  • the transceiver may support Wi-Fi® communication.
  • one or more transceivers may support data communication via Bluetooth or Bluetooth Low Energy (BLE).
  • BLE Bluetooth Low Energy
  • the transceiver may be capable of down-converting and up-converting a baseband or data signal from and to a wireless carrier signal.
  • the communication module may wirelessly exchange data between other components of the GLCS or AMD 600 (e.g., an analyte sensor such as a glucose level sensor or insulin level), a mobile device (e.g., smart phone, a laptop, a tablet, and the like), a Wi-Fi network, WLAN, a wireless router, a cellular tower, a Bluetooth device and the like.
  • the antenna may be capable of sending and receiving various types of wireless signals including, but not limited to, Bluetooth, LTE, or 3G.
  • the communication module 602 may support direct communication between the AMD 600 and a server or a cloud network.
  • the AMD 600 may communicate with an intermediary device (e.g., a smart phone).
  • the AMD 600 may include an eSIM card that stores the information that may be used to identify and authenticate a mobile subscriber.
  • the eSIM card may enable the AMD 600 to function as an IOT device that can communicate over a network that supports communication with IoT devices.
  • the AMD 600 may be configured to transmit data using a narrowband communication protocol such as 2G or EDGE.
  • the ambulatory medical device may be paired with the mobile device at inception and permit real-time data access to the ambulatory medical device by a healthcare provider.
  • the ambulatory medical device may include a geolocation receiver or transceiver, such as a global positioning system (GPS) receiver.
  • GPS global positioning system
  • the communication module 602 may include a Near Field Communication (NFC) sub-system that enables contactless data exchange between the AMD 600 and an electronic device located in the vicinity of the AMD 600.
  • NFC Near Field Communication
  • a glucose sensor interface in the communication module 602 may be configured to receive glucose level signals from an analyte sensor, a glucose level sensor, and/or insulin level sensor, hereinafter referred to as “subject sensor” 620.
  • the subject sensor 620 can be a wearable continuous glucose monitor (CGM) that is operatively connected to the subject 622.
  • CGM wearable continuous glucose monitor
  • the subject sensor 620 may be attached to a site on subject’s body using adhesive patch holds and may include a cannula that penetrates the subject’s skin allowing the sensor to take glucose readings in interstitial fluid and generate glucose level signals that indicate the level of glucose in subject’s blood.
  • the glucose sensor interface may receive the glucose level signals from the subject sensor 620 via a wired or wireless link.
  • each of the AMDs described herein may include one or more of the embodiments described with respect to the other AMDs unless specifically stated otherwise.
  • an AMD or GLCS may continuously, periodically (e.g., every 5 minutes, every 10 minutes, etc.), or intermittently receive information associated with one or more parameters (e.g., parameter values) that are correlated with a health condition of the subject 622 (e.g., glucose level, glucose level trend, insulin level, insulin level trend, heart rate, body movement indicia, etc.).
  • This information may be encoded to a signal provided to AMD 600 by a subject sensor 620 (e.g., a glucose level sensor or an insulin sensor) that is connected to the AMD 600 via a wired or wireless link (e.g., Bluetooth).
  • the subject sensor 620 can be a wearable sensor.
  • the subject sensor 620 may measure an analyte in the interstitial fluid of the subject 622).
  • AMD 600 may receive glucose level signals that carry encoded glucose level data usable to determine a glucose level of the subject 622, from a continuous glucose monitor (CGM).
  • CGM continuous glucose monitor
  • a CGM may be a wearable biomedical sensor that measures a glucose level in an interstitial fluid of the subject.
  • a glucose level signal may comprise an electronic signal indicative of a measured glucose level of the subject 622.
  • the measured glucose level associated with a glucose level signal may be correlated with a physiological glucose level of the subject.
  • the physiological glucose level of the subject can be a concentration of glucose in subject’s blood or an interstitial fluid in part of the subject’s body (e.g., expressed in milligram per deciliter (mg/dl)).
  • the concentration of glucose in the interstitial fluid of the subject’s body may be correlated to a blood glucose level of the subject.
  • the AMD (or GLCS) 600 may receive glucose level signals from the subject sensor 620 via a glucose sensor interface (e.g., via a wired or a wireless data connection).
  • the glucose sensor interface may be included in the communication module 602.
  • the glucose sensor interface may be separate from the communication module 602.
  • the glucose level signal sent by the subject sensor 620 may be received by the communication module 602 and transmitted to the control and computing module (CCM) 610 where it is analyzed to determine whether medicament should be delivered to the subject.
  • CCM control and computing module
  • the communication module 602 may transmit the glucose level signal to a signal processing module 604 that converts the glucose level signal to a machine-readable signal (e.g., a digital signal) and transmits the converted signal to the CCM 610.
  • a second communication system may be included in the AMD (or GLCS) 600 to communicate with the subject sensor 620.
  • the CCM 610 may determine the dosage and type of medicament to administer based at least in part on the information received from the subject sensor 620. Subsequently, the control and computing module 610 may send a signal to the therapy delivery module to initiate the medicament delivery the subject.
  • the control and computing module 610 may determine a dose and a delivery time of a medicament (e.g., insulin or glucagon) based at least in part on the glucose levels of the subject 622 decoded from the received glucose level signals. Subsequently, the control and computing module 610 may generate a dose control signal and transmit the dose control signal to the therapy delivery module 606 of the AMD 600, to cause the delivery of the determined dose of medicament at the determined delivery time to the subject 622.
  • the dose control signal may be received by the pump controller that controls the operation of the infusion pump.
  • the control and computing module 610 may generate the dose control signal using a control algorithm.
  • the control algorithm may comprise a model-predictive control (MPC) algorithm and/or a basal control algorithm.
  • the CCM 610 may perform one or more procedures by using the processor 614 (or a plurality of processors) that executes the instructions stored in the CCM 610 (e.g., in the main memory 616).
  • one or more procedures within the control and computing module 610 may be executed by the processor 614 (or a plurality of processors) based on instructions provided by one or more software applications installed in one of the memories (e.g., the main memory 616) of control and computing module 610.
  • These procedures include, but are not limited to, determining the need for delivering medicament, determining the type of medicament and the required dose, determining the rate of delivery during a therapy session, providing information (e.g., device status, infusion set usage, infusion set status, subject sensor usage, transmitter status, transmitter usage, subject sensor 620 status, next delivery time, level of certain analytes in the subject’s blood and the like) via the user interface module 608, processing the data received from the subject sensor 620, managing access to control parameters (e.g., by controlling one or more therapy change controls that may be provided by the user interface module 608), and the like.
  • information e.g., device status, infusion set usage, infusion set status, subject sensor usage, transmitter status, transmitter usage, subject sensor 620 status, next delivery time, level of certain analytes in the subject’s blood and the like
  • processing the data received from the subject sensor 620 e.g., managing access to control parameters (e.g., by controlling one or more therapy change controls that may be provided by the
  • an amplitude of the glucose level signal may be proportional to or correlated to the glucose level of the subject.
  • a glucose level signal may carry glucose level data (e.g., measured glucose level values or information usable to determine glucose level values).
  • the glucose level signal, generated by the glucose sensor e.g., subject sensor 620
  • the glucose level signal may include encoded glucose level data.
  • the glucose level signal may comprise glucose level data encoded onto a carrier signal, for example, using amplitude modulation, frequency modulation, and/or phase modulation.
  • the glucose level signal can be an analog signal encoded with data associated with the glucose level data.
  • the glucose level signal can be transmitted via a wireless link (e.g., a Bluetooth link, a Wi-Fi link, a cellular data link, and/or other wireless network infrastructure) and received by a wireless receiver included in a glucose sensor interface.
  • a wireless link e.g., a Bluetooth link, a Wi-Fi link, a cellular data link, and/or other wireless network infrastructure
  • the glucose sensor interface can be included in the communication module 602.
  • the glucose sensor interface can a separate module or system in the AMD 600.
  • the glucose sensor interface may direct the glucose level signal to the control and computing module 610.
  • the control and computing module 610 may decode the glucose level data from the glucose level signal.
  • the glucose level data may be decoded by the glucose sensor interface.
  • the glucose level signal sent by the subject sensor 620 may be received by the communication module 602 and transmitted to the control and computing module 610.
  • a first software application may control the AMD 600 and may be installed on the main memory 616 while a second software application (e.g., a different version of the first software application or an alternative control application) may be stored in the storage 618.
  • the first and second software applications may be both installed in the main memory 616 but in different locations or segments.
  • the control of the device can be switched from the first software application to the second software application in response to a trigger (e.g., a command, an error, receipt of an authorization indication, etc.).
  • a trigger e.g., a command, an error, receipt of an authorization indication, etc.
  • the AMD 600 may deliver multiple types of therapies that are selectable by a user or the control and computing module 610.
  • the AMD 600 may deliver the therapy of infusing insulin into a user and may also deliver the therapy of infusing glucagon into a user.
  • the user interface may include an option for the user to select an infusion of insulin, glucagon, or both insulin and glucagon.
  • other hormones, liquids or therapies may be delivered.
  • the software application executed by the control and computing module 610 may determine the type of hormone that needs to be delivered, at least partly based on the information received from the sensor 620.
  • the AMD 600 may provide the user or the subject 622 a user interface (e.g., via a touch screen display) that allows delivery of glucose therapy to the subject 622 upon request.
  • a user interface e.g., via a touch screen display
  • the user interface module 608 may generate a medicament bolus or medicament burst user interface on a touch screen display that allows the user to enter a dose of a medicament for immediate delivery.
  • a regulatory medicament bolus can be a meal bolus requested and delivered in anticipation of food intake.
  • a counter-regulatory medicament bolus can be delivered in anticipation of physical activity (e.g., swimming or running), or similar to how a meal bolus can be delivered in anticipation of food intake.
  • a medicament bolus may be requested and delivered to maintain the glucose level of the subject 622 within a set range during a period of time when the subject 622 does not receive therapy from the AMDs 600.
  • the subject 622 may request a medicament bolus via the medicament burst user interface when he or she expects to be disconnected from the AMDs 600 for a period.
  • FIG. 7 illustrates various methods and links or communication paths that an AMD (or GLCS) 702 may use to communicate (e.g., by establishing a connection) with a host computing system 704 (e.g., a remote computing environment), for example, to obtain an application update, send and/or receive therapy reports, facilitate ordering of infusion sets, analyte sensors, transmitters, and/or a new AMD, receive passcodes, send and receive electronic requests, receive values of control parameters, send or receive aggregate reports, and the like.
  • a host computing system 704 e.g., a remote computing environment
  • the host computing system 704 may be a server 706 or a computing system within a cloud based computing system 708 or other networked computing environments, that provide networking computing services (e.g., network storage, application hosting, and/or network processing services).
  • the host computing system 704 may be part of a data center (e.g., the data center of a health care provider).
  • the host computing system 704 may be a computing system of a healthcare provider, a healthcare professional, a manufacturer, or a payer (e.g., an insurance company).
  • the host computing system 704 may be part of a patient data network or be connected to a patient data network.
  • the patient data network may comprise a local storage of patient data or a cloud storage.
  • the host computing system 704 may be in communication with a data center of a healthcare provider, a health institute, or a payer.
  • the AMD (or GLCS) 702 may establish a connection (e.g., using its communication module) with the host computing system 704 through an intermediary device 710, such as a desktop computer, a mobile device (e.g., a smart phone, a laptop, and the like).
  • the server 706 can be an electronic device can be a desktop computer, a mobile phone, a notebook, or any electronic device capable of establishing a data connection with the AMD 702 and receiving data from the AMD 702.
  • the AMD (or GLCS) 702 may establish a connection (e.g., using its communication module) with the host computing system 704 to obtain the application update.
  • the AMD may receive the application update from an intermediary device 710 of a user (e.g., a clinical computer, a subject’s home computer, a smartphone, etc.) that has obtained a copy of the application update from the host computing system directly or via internet 714.
  • the AMD 702 may communicate with the host computing system 704 through a local area network (LAN) through a Wi-Fi connection.
  • LAN local area network
  • Wi-Fi wireless fidelity
  • the AMD 702 may establish a communication connection to the host computing system 704 via a wide area network (WAN) 716.
  • the communication between the ambulatory medical device and the cloud computing system 704 may be encrypted.
  • the AMD 702 may establish a direct end-to-end communication connection over a wide area network (WAN) 716 (e.g., a cellular network) with the host computing system 704.
  • a direct-end-to-end communication connection may be a connection that does not involve a local device, a device that is accessible by the user or the subject (besides the AMD 702), a Wi-Fi network, a short range wireless link (e.g., Bluetooth), or the like.
  • the direct end-to-end communication may pass through one or more wireless systems (e.g., receivers, transmitters or antenna) of a WAN.
  • the host computing system 704 may establish the end- to-end connection by receiving a public key from the AMD 702.
  • the public key and a private key stored in the host computing system 704 can be used to permit the host computing system 704 to decrypt data communications transmitted by the AMD 702.
  • the host computing system 704 may send a public key to the AMD 702 that allows the AMD 702 to encrypt data (e.g., therapy data). Up on receiving the encrypted data from the AMD 702 the host computing system 704 may use a private key stored in its memory, to decrypt the data.
  • the host computing system 704 may establish a direct end-to-end data connection with the AMD 702 based on receiving a device identifier associated with the AMD 702.
  • the device identifier may be a unique identifier specific to the AMD 702.
  • establishing the direct end-to-end data connection may include determining that the ambulatory medical device is permitted to communicate with the computing system 704 based at least in part on the device identifier.
  • the device identifier may be initially provided to the networked computing environment prior to provisioning of the ambulatory medical device to the subject.
  • the device identifier may be initially provided to the networked-computing environment as part of a manufacturing process for manufacturing the AMD 702.
  • the device identifier may include or may be based on one or more of an Internet Protocol (IP) address, a Media Access Control (MAC) address, a serial number, or a subject identifier of a subject that receives therapy from the AMD 702.
  • IP Internet Protocol
  • MAC Media Access Control
  • the subject or a user may establish (or initiate) the direct end-to- end data connection with the computing system.
  • the direct end-to-end data connection may be initiated or established without action by the subject or the user.
  • the direct end-to-end data connection may occur automatically at particular times or when the AMD 702 is in particular locations. This automatic connection may occur using information supplied to the AMD 702 at a time of manufacture, shipment, sale, or prescription to the subject.
  • the wide area network may include, or may communicate with, the internet 714.
  • the AMD 702 may be configured to communicate via the wide area network during manufacture or prior to being provisioned to the subject.
  • a manufacturer can register the AMD 702 with a wireless wide-area network provider (e.g., T-Mobile or Verizon) and provide an International Mobile Equipment Identity (IMEI) number or serial number for the AMD 702 to the network provider.
  • IMEI International Mobile Equipment Identity
  • any fees can be negotiated or paid between the manufacturer and the network provider or between the subject’ s health insurance and the network provider.
  • AMD 702 may be configured to communicate via the network of the network provider without any action by the subject.
  • the AMD 702 may be pre-registered or authenticated with a computing network of the cloud services provider as part of the manufacturing process or before the AMD 702 is provided to the subject. This enables the AMD 702 to communicate over the wide area network with the computing system of the cloud services provider from day one without any or with minimal configuration by the subject.
  • a user such as a healthcare provider may register or associate the AMD 702 with the subject at the computing network of the cloud services provider.
  • the AMD 702 may use a whitelist that identifies via a unique identifier (e.g., via an IP address, a MAC address, or a URL) permitted cloud servers or computing system of the cloud computing system.
  • the cloud computing service may have a whitelist that uses unique identifiers to specify AMD 702s and/or other computing systems (e.g., remote display systems) that are permitted to communicate with the cloud computing system.
  • the whitelist may be stored in a memory of the AMD 702. Further, the whitelist may be configured during manufacture of the AMD 702. For example, the whitelist may be configured with connection information to establish communication with one or more computing systems of a networked-computing environment.
  • the AMD 702 may be configured to execute the specific computer-executable instructions to at least obtain an address of the computing system from the whitelist and to establish a direct end-to-end data connection to the computing system of the networked- computing environment via a wireless wide area network using the address. Moreover, the AMD 702 may be configured to execute the specific computer-executable instructions to at least receive a public key from the computing system of the networked-computing environment.
  • the AMD 702 may include a blacklist, or restricted list, that identifies systems the AMD 702 is not permitted to access.
  • the blacklist may be updated as more restricted or unsafe websites, network accessible systems, or computing systems are identified.
  • the whitelist may be updated over time if approved systems are added or removed.
  • the cloud based computing system 708 service may have a whitelist, or approved list, that uses unique identifiers to specify AMD 702 and/or other computing systems (e.g., remote display systems) that are permitted to communicate with the cloud based computing system 708.
  • the cloud based computing system 708 may have a blacklist or restricted list that identifies AMDs, or other computing devices, that are not permitted to access the cloud computing services.
  • An AMD may be added to the restricted list if it is decommissioned, damaged, or is no longer in possession of the subject. It may be desirable to remove an AMD’s access to the cloud computing service to help protect private or personal data of a subject.
  • establishing a connection based on a whitelist may enhance the security of the communication link established between AMD 702 and the cloud based computing system 708 or other computing systems.
  • the whitelist may include any information that may facilitate access to the systems identified on the whitelist.
  • the whitelist may include access information (e.g., usernames, passwords, access codes, account identifiers, port identifiers, a shared secret, public keys, etc.).
  • access information e.g., usernames, passwords, access codes, account identifiers, port identifiers, a shared secret, public keys, etc.
  • the whitelist may include different information depending on whether the whitelist is publicly accessible, accessible by only the AMD, accessible by authorized users or devices, etc. For example, a publicly accessible whitelist or a whitelist accessible by more than one authorized system or user may not include passwords or access codes.
  • the user may not receive a necessary insulin bolus from the ambulatory medical device.
  • an ambulatory medical device includes a computer- implemented method of updating an application executing on the ambulatory medical device without interrupting, or while causing minimal interruption, to therapy provided by the ambulatory medical device to a subject or subject.
  • the method may generally be performed by a hardware processor, (e.g., a controller, and the like), included in an ambulatory medical device and based on a set of instructions that may be stored, for example, in a non-transitory memory of the AMD.
  • the application update may be a new version of the application, a replacement or substitute application, or an application patch.
  • the application may be an older version of the application that has been used by instances of the ambulatory medical device for more than a threshold period of time and has experienced less than a threshold number of faults.
  • the application update may be stored in one or more host computing systems.
  • the application update may be pushed to the host computing systems by a company that manages or manufactured the ambulatory medical device or other software company that is authorized by the manufacturer or licensee of the device.
  • FIG. 8 is a flow diagram showing an example of a computer-implemented method that may be used by the AMD in order to detect and download an application update from a host computing system or other computer readable media in which a copy of the application update is stored.
  • an ambulatory medical device such as a medicament delivery device or a medicament pump may receive an indication 802 that an update is available for an application, such as control software or other software that controls or facilitates the operation of the ambulatory medical device.
  • the software update may include a binary executable file for various processors of the ambulatory medical device.
  • the indication may be a determination made by a software or hardware module included in an ambulatory medical device of AMD.
  • the AMD may access a particular host computing system (e.g., using its communication module) to determine whether an update is available, based on set of update trigger conditions stored in a memory of AMD.
  • the set of update trigger conditions may be defined/changed by a user and/or received by AMD from a host computing system.
  • a trigger condition may push the AMD to periodically search for an update at time intervals set by the user or received from a host computing system.
  • the ambulatory medical device may access a particular host computing system to determine whether an update is available to an application installed on the AMD.
  • the software to be updated on the AMD may be currently executing on the ambulatory medical device or may be executed in future.
  • the indication may a query received from the host computing system that may access the AMD to read and compare the software versions and the hardware configuration (and warranty) to determine the eligibility of the ambulatory medical device for a software upgrade.
  • the serial number, the model number, and/or the software version may be used to determine software upgrade eligibility.
  • the eligibility may be determined based on the geoposition of the device and/or whether the device is connected to a local area network (such as for example, a Wi-Fi network) or a wide area network (such as, for example, a cellular network).
  • the ambulatory medical device may have an antenna that provides the device with GPS, text or picture messaging, telephone calling, and data transfer capabilities.
  • Software update may be provided on a limited release with test groups of varying sizes, e.g., 1-100 or 1-1000 or 1- 10000. There may be a phase rollout of the software updates.
  • the AMD may respond to an upgrade eligibility request with a version of the first software or a model identification information of the ambulatory medical device or a manufacturing date of the ambulatory medical device.
  • the ambulatory medical device may establish a connection 804 to a host computing system that hosts the update to the application.
  • Such connection may be established via one or more links or methods discussed above with reference to FIG. 7.
  • the ambulatory medical device may download the application update or application update from the host computing system over the connection 806.
  • the ambulatory medical device may download an image of the application update from the host computing system. While the application update is being downloaded, an existing version of the application on the ambulatory medical device may continue to execute. Thus, there is little or no interruption to therapy provided by the ambulatory medical device while the application update is being obtained by the ambulatory medical device.
  • the ambulatory medical device may perform one or more operations to confirm that the application update was successfully downloaded from the application host system and that the download was not corrupted 808. For example, the ambulatory medical device may calculate a hash or checksum value from the downloaded application update. This hash or checksum value may be compared with one received from the application host system. If the calculated hash or checksum value matches the received hash or checksum value, then it may be determined that the download is both complete and not corrupt. Further, the ambulatory medical device may use the checksum, a tag, a payload size, or any other method to confirm that the download of the application update is complete and not corrupt.
  • the AMD discards the corrupt copy and downloads another copy of the update. If it is determined that the download is complete and not corrupt, the AMD may proceed to the installation step wherein the application update may be installed on the AMD without interrupting the ongoing or upcoming therapy sessions.
  • FIG. 9-11 are flow diagrams illustrating examples of computer- implemented methods that may be used by the AMD to install a downloaded application update without disrupting the therapy provided to a subject.
  • the control and computing module (CCM) of the AMD may determine the amount of time required to install the application update 904 and wait for a trigger signal 906 to initiate installation process.
  • the CCM may notify to the user 908 through a user interface (e.g., a touchscreen display), that an update is ready for installation. The notification may include the installation time and information about the update.
  • CCM may send one or more notifications to the user indicating that a new update is ready for installation.
  • the trigger may be the confirmation that the application was successfully downloaded.
  • the trigger may be a user command received based on an interaction by a user or subject with a user interface that is part of or that communicates with the ambulatory medical device.
  • the installation time may be determined by the CCM based on data or metadata provided with the downloaded application update.
  • the application update may include a file (e.g., a text file or configuration file) that includes the install time.
  • the installation time may be determined by the manufacturer of the ambulatory medical device or the publisher of the application update. For example, the developer of the software update may average the install time across several test devices to determine the install time metadata that is provided with the software update.
  • General purpose computers have a wide variety of configurations and the performance of a general purpose computer may vary depending on the applications executing at a particular time. Thus, the determination of install time for an application based on the measurement of install time on a test device is typically unreliable.
  • an install time determined during testing by a manufacturer may in many cases be a reliable determination of install time on an ambulatory medical device of a subject.
  • the install time of an application update may be determined or estimated based on a size of the application update.
  • the provided or estimated install time may include a buffer. In other words, an additional amount of time may be added to the install time to account for variances in operating condition of the ambulatory medical device or inaccuracies in the estimated install time.
  • the CCM may check for any ongoing therapy session 910. If the no therapy is currently being administered, the CCM determines the next therapy time 914 (or the time left until the next therapy session). If therapy is currently being administered the installation will be delayed 912 until the therapy session is compete. Once the current therapy session is complete, the CCM may determine the time remaining until next therapy session 914 (e.g., during which medicament, such as insulin is delivered to a subject).
  • the determination of the next time that therapy is to be delivered may be an estimate based on historical delivery of therapy, a present condition of the subject (e.g., when a glucose level is of a subject is at the center of a desired range, the next therapy delivery time may be estimated to be further off than when the glucose level is at the edge of the desired range), and/or an indication provided by a user or subject (e.g., an indication that the user is planning to have a meal, to exercise, or to go to sleep).
  • the determination of the next time that therapy is to be delivered may be based on a scheduled delivery of therapy (e.g., every 5 minutes or every hour).
  • the estimated install time may be compared 916 to the determined or estimated next therapy delivery time to determine whether the installation of the application update can be completed before the next therapy delivery to the subject. If it is determined that the time left until the next therapy session is sufficiently longer than the determined time for completing the installation, installation of the application updated may be initiated 918. In some examples, the determined time to the next therapy session has to be longer than the determined installation time by a threshold value. Such threshold value may be different for different application updates and/or the type of next therapy session.
  • the installation of the application may be delayed, regardless of receipt of the trigger.
  • the CCM may wait for the next therapy to be completed and then determine a new therapy time at block 914. This process may be repeated until CCM determines that the update can be installed without interrupting an expected or scheduled therapy by the ambulatory medical device.
  • a new determination may be made before completion of the next therapy, to determine whether installation may be completed prior to a subsequent therapy time after the next therapy time.
  • a time when the application can be installed without interrupting therapy may not be identified.
  • a user e.g., a clinician or other medical provider, or a subject
  • the user may be provided with an option as to whether to permit the update and/or when to install the application update.
  • the option may include presenting the user with the estimated install time enabling the user to schedule the application update at a time when interruptions to therapy may be minimal or when an alternative source of therapy (e.g., injection therapy) can be utilized.
  • an alternative source of therapy e.g., injection therapy
  • the AMD’s control and computing module may notify the user and wait for a trigger signal before determining the installation time. Once the trigger has been received, the CCM initiates the installation process of the downloaded copy of the application update without interrupting therapy provided by the ambulatory medical device to the subject.
  • the application update may be installed in a different memory location than the memory location where the original application is installed and executed.
  • FIG. 10 is flow diagram illustrating an example of a computer-implemented method that may be used by the AMD in order to install a second application that is an update to a first application executing on the ambulatory medical device, without disrupting the therapy provided to a subject.
  • the CCM may initiate the installation process of the second application 1004 without interrupting the execution of the first application.
  • the CCM may confirm 1006 the successful installation of the second application and wait for a trigger signal 1010 to initiate the execution of the second application in place of the first application.
  • the installation of the second application may be confirmed by sending a notification the user 1008 via a user interface of the AMD.
  • the CCM may determine the amount of time required for switching the control of AMD to from the first application to the second application.
  • the notification may include information about the update and the time required for switching between the applications.
  • the trigger may be a user command received based on an interaction by a user or subject with a user interface that is part of or that communicates with the ambulatory medical device. In such examples, if a trigger is not received the AMD may send one or more notifications to the user indicating that a new update is ready for installation. If a trigger is received, the CCM may check for any ongoing therapy session 1012.
  • the CCM determines the next therapy time 1016 (or the time left until the next therapy session). If therapy is currently being administered the installation will be delayed 1014 until the therapy session is compete. Once the current therapy session is complete, the CCM may determine the time remaining until next therapy session 1016. The estimated next therapy delivery time may be compared to a set threshold time to determine whether the switching from the first application to the second application can be performed without interfering with the next therapy session. If it is determined that the time left until the next therapy session is longer than the set threshold time, the execution of the second application will be initiated and the execution of the first application will be halted 1020. In some examples, the set threshold time may be determined by the CCM at least partly based on the time required to execute of the second application and halt the first application. In some other examples, the set threshold time may be received from a host computing system.
  • the performance of an application update may be tested before switching control of the AMD to the application update.
  • FIG. 11 illustrate an example method that may be used by such embodiment.
  • the AMD verifies that an uncorrupted copy of the update for a first application is successfully downloaded 1102 (e.g., using the procedure described above with reference to FIG. 8).
  • the AMD may install 1104 and execute 1106 the downloaded copy of the second application without interrupting the execution of the first application and therefore the therapy that might be provided by the ambulatory medical device to the subject.
  • the second application update may be installed to a separate portion (e.g., a separate execution space or separate memory) from the portion where the first application is installed and is being executed.
  • the Control and computing module (CCM) of the AMD may determine that a minimum set of operating conditions are satisfied by the second application 1110, wherein the minimum set of operating conditions relate to maintaining therapy provided by the ambulatory medical device to the subject. If it is determined that the minimum set of operating conditions are not satisfied by the second application, the AMD may wait for an indication that a third application is available and repeat the procedure described above to evaluate the performance of the third application. If it is determined that the minimum set of operating conditions are satisfied by the second application, the AMD may check for an ongoing therapy session 1114. If it is determined that currently no therapy is provided to a subject, CCM may switch the control of the ambulatory medical device from the first application to the second application 1118. If currently therapy is provided to a subject, the CCM may wait until the therapy session is competed 1116 and then switch the control of the AMD from the first application to the second application.
  • CCM Control and computing module
  • the ambulatory medical device may be updated (or downgraded) to add (or remove) features from the ambulatory medical device.
  • the ambulatory medical device may initially provide only insulin therapy.
  • the ambulatory medical device may be upgraded to include bi-hormonal control (e.g., to provide both insulin therapy and counter-regulatory agent (e.g., Glucagon) therapy).
  • the upgrade may be based on newly available features and/or based on a decision by a user to purchase or otherwise obtain additional features.
  • a user may opt to downgrade therapy from bi-hormonal to insulin-only therapy.
  • the upgrade or downgrade may be made based on the availability of medicament.
  • a first update can be a first application version comprising a first feature set (e.g., providing insulin therapy) and a second update can be a second application version comprising a second feature set (e.g., provide both insulin therapy and Glucagon therapy).
  • the first feature set may comprise a subset of the second feature set.
  • the first feature set may comprise a partially overlapping set of features with the second feature set.
  • a computer-implemented method that may be used by the AMD in order to detect, download and install an update to an application executing on the ambulatory medical device wherein the application comprises one of a first application version comprising a first feature set or a second application version comprising a second feature set.
  • the first feature set may comprise partially overlapping set of features with the second feature set.
  • the first feature set may comprise partially overlapping set of features with the second feature set.
  • the AMD may receive an indication of availability of the application update, download the application update and verify that an uncorrupted image of the application update is successfully downloaded (e.g., using the procedure described above with reference to FIG. 8).
  • the control and computing module (CMM) of the AMD may initiate the installation process of the application update image without interrupting the execution of the application.
  • the indication received by the AMD may include information about application update being an update to the first application version or to the second application version.
  • the CCM may determine the version of the application update and download the application update image based on the determined version
  • any downloaded application update may be installed to a separate portion (e.g., a separate execution space or separate memory) from a currently executing version of the application.
  • the active version of the application can be switched. For example, control of the ambulatory medical device can be provided to the updated application, the previously executing application can be ceased or halted. The old application can then be removed, or kept as backup. Determining when to switch which version of the application is active may follow a similar process as previously described for identifying a next therapy delivery time and selecting a time to switch active versions of the application when there will not be an interruption to the therapy provided by the ambulatory medical device.
  • the ambulatory medical device may be configured to store multiple instances of an application (e.g., ambulatory medical device control software).
  • the ambulatory medical device may have a current, or first, version of the application that it is installed in a first memory location (e.g., in the main memory 616) and is executing to, for example, control therapy provided by a subject.
  • the ambulatory medical device may include an updated, or second version of the application installed in a second memory location (e.g., in the main memory 616). The update of the second version may have been downloaded and installed (e.g., in a prior to detection of the fault).
  • the ambulatory medical device may initiate the execution of the second version of the application and then switch control of the AMD to the second version of the application to maintain therapy to the subject.
  • the second version of the application installed on the AMD may be a version older than the first version, or version that may not have track a record of stability and reliability.
  • FIG. 12 is a flow diagram for such examples.
  • the control and computing module (CMM) of the AMD may switch the control of the AMD to the second version of the application 1204 while establishing a connection with a host computing system configured to host a third update and download the third update 1206.
  • the third version of the application may be a new version, a version prior to the first version, an update to the first application that addresses the detected application-fault or an older version that satisfies the conditions to be classified as a “safe version” (e.g., less than a threshold number or rate of faults over a minimum period of time).
  • the second version (installed in the device) may control the AMD while the third version is being downloaded and installed 1208 without interrupting the therapy.
  • the CCM may initiate the installation process of the downloaded copy of the third application and switch control of the ambulatory medical device form the second application to the third application 1210 without interrupting therapy provided by the ambulatory medical device to the subject
  • a “safe version” of the application may have been installed on the ambulatory medical device prior to detection of a fault.
  • the safe version of the application may include a version of the application that has been used by instances of the ambulatory medical device for more than a threshold period of time and has experienced less than a threshold number of faults.
  • the safe version of the application may be a two-year old version of the application that has demonstrably had less than a threshold number of faults occur over the period of two years.
  • This safe version of the application may have less features than the first or second version of the application.
  • the ambulatory medical device may switch control of the device to the safe version of the application to maintain therapy to the subject.
  • the ambulatory medical device may revert to the current version or a safe version installed on the AMD.
  • the AMD may be triggered to establish a connection with the host computing system and search for the second version once a fault is detected during execution of the first version.
  • the ambulatory medical device may revert to the safe version (installed in the device) while downloading and installing the second version without interrupting the therapy.
  • FIG. 13 is a flow diagram illustrating yet another example of a method of responding to a fault detection by the AMD.
  • the control and computing module (CMM) of the AMD may look for a second version of the application 1304 in the main memory or the storage. If it is determined that the second version has been already downloaded, the CCM will determine 1306 whether the second version of the application is installed in a memory location and is ready to be executed. If it is determined that the second version of the application is installed, the control of the AMD will be switch to the second version of the application.
  • CCM control and computing module
  • CCM determines that the second version exists in the memory but it is not installed, it will switch the control of the AMD to a safe version that may be already installed and then initiates the installation 1318 of the second version.
  • the CCM may switch control of the AMD from the safe version of the application to the second version of the application.
  • the CCM may search for a third version of the application 1310 that may be an update to the previously downloaded second version. If a third version is found, the CCM may download and install the third version 1312 and switch the control of the AMD to the third version 1314.
  • the CCM With reference to block 1304, if the CCM cannot find a second version of the application in a memory or storage location, it will switch the control of the AMD to a safe version of the application 1320 that may be installed in a memory location (e.g., in the main memory or in the storage) and then search for a third version of the application 1310. If a third version is found, the system may download and install the third version 1312 and switch the control of the device to the third version 1314.
  • the AMD may transmit an indication of the application-fault to the host computing system of a manufacturer or maintenance service of the ambulatory medical device.
  • the AMD may notify the user when an application-fault occurs through a user interface of the AMD or user interface communicating with the AMD.
  • An ambulatory medical device such as an ambulatory medicament device (e.g., glucose level control system (e.g., an insulin pump or a bi-hormonal pump that includes insulin and a counter-regulatory agent), a pacemaker, or any type of medical device that may be connected to a subject to provide therapy to the subject, can generate a significant amount of data related to therapy provided to a subject (therapy data).
  • This therapy data may be useful for the subject, a healthcare provider, or other users (e.g., parent or guardian) to actively manage the subject’s health condition.
  • the therapy data may be useful to determine whether a modification to therapy may be desirable or to confirm that intended therapy is being delivered at the right time.
  • the data may be used to generate an alert about the health condition of the subject when therapy data indicates that immediate attention is needed or advised with regards to subject’ health condition.
  • Accessing the data from the ambulatory medical device can be problematic in some cases. For example, accessing the data may require a user to connect the ambulatory medical device to a computer to upload the data. This places a burden on the user to remember to connect the ambulatory medical device. Further, during the period when the device is connected to the computer, the subject may not be receiving therapy from the ambulatory medical device. In some cases, the subject may not be capable of connecting the device to the computer (e.g., when the AMD is not within range of the local device) and may not have someone available to assist the subject. Thus, a direct end-to-end connection to a computing system that (e.g., computing system of a healthcare provider) can safely share data (e.g., therapy data) with authorized users may facilitate data management and access.
  • a computing system e.g., computing system of a healthcare provider
  • data e.g., therapy data
  • FIG. 14 is a block diagram illustrating an example network configuration wherein the AMD 1402 is directly connected to a computing system 1404.
  • the computing system 1404 may be part of networked computing environment 1408 (e.g., a data center, networked computing system), or cloud network 1406 or cloud computing system of a cloud service provider.
  • the computing system may include one or more non-transitional memories and one or more hardware processors configured to execute the computer-executable instructions stored in one or more non-transitional memories.
  • the procedures performed by the computing system may be associated with the execution of certain computer-executable instructions stored in a memory of the computing system by a hardware processor of the computing system.
  • the direct end-to-end data connection may be supported by one or more transceivers in AMD’s communication module 602.
  • a direct connection may be established between the AMD 1402 and the computing system 1404 over a wide area network (e.g., a cellular network) without using an intermediary system using various wireless standards and technologies (e.g., 4G, 5G and the like).
  • the transceiver may support communication via communication standards, including but not limited to, low power wide area network (LPWAN), Narrowband Long-Term Evolution (NB- LTE), Narrowband Internet-of-Things (NB-IoT), or Long-Term Evolution Machine Type Communication (LTE-MTC).
  • LPWAN low power wide area network
  • NB- LTE Narrowband Long-Term Evolution
  • NB-IoT Narrowband Internet-of-Things
  • LTE-MTC Long-Term Evolution Machine Type Communication
  • the transceiver is always on, and in some cases, the transceiver may be activated when a data transfer is scheduled, requested or activated. In some cases, the capability of the ambulatory medical device 1402 to communicate with the computing system may be activated during manufacture or before providing the device to a subject.
  • the subject or a user establishes or initiates establishing the direct end-to-end data connection with the computing system.
  • the subject may interact with a user interface to cause the ambulatory medical device to communicate with the cloud computing service.
  • the direct end-to-end data connection may be initiated or established without action by the subject or the user.
  • the direct end-to-end data connection may occur automatically at particular times or when the ambulatory medical device is in particular locations. This automatic connection may occur using information supplied to the ambulatory medical device at a time of manufacture, shipment, sale, or prescription to the subject.
  • the ambulatory medical device can communicate with the computing system without having access to a Wi-Fi network or a local area network (LAN).
  • LAN local area network
  • the ambulatory medical device may communicate using a cellular or other wide area network.
  • the interaction by the user with the ambulatory medical device may be relatively minimal or simple compared to traditional network communication.
  • a user may push a single button (e.g., an “upload” button) to trigger establishing of a connection with the cloud computing service and causing data to be provided from the ambulatory medical device to the cloud computing service.
  • the ambulatory medical device may be turned on and paired with the wireless wide area network (e.g., a cellular network) at the time of manufacture, or prior to being provided to a subject. Further, the ambulatory medical device may be authenticated with the networked-computing environment as part of the manufacturing process [0168] Further, establishing the direct end-to-end data connection may include determining that the ambulatory medical device is permitted to communicate with the computing system based at least in part on the device identifier.
  • the wireless wide area network e.g., a cellular network
  • establishing the direct end-to-end data connection may include determining that the ambulatory medical device is permitted to communicate with the computing system based at least in part on a device identifier associated with the ambulatory medical device.
  • the device identifier may be a unique identifier specific to the ambulatory medical device.
  • the device identifier may include or may be based on one or more of an Internet Protocol (IP) address, a Media Access Control (MAC) address, a serial number, or a subject identifier of a subject that receives therapy from the ambulatory medical device.
  • IP Internet Protocol
  • MAC Media Access Control
  • establishing the direct end-to-end data connection may include determining that the ambulatory medical device is permitted to communicate with the computing system based at least in part on the device identifier.
  • the device identifier may be initially provided to the networked-computing environment prior to provisioning of the ambulatory medical device to the subject.
  • the device identifier may be initially provided to the networked-computing environment as part of a manufacturing process for manufacturing the ambulatory medical device.
  • the request may include a device identifier associated with the ambulatory medical device.
  • the ambulatory medical device may be configured to at least identify a computing system 1404 of a networked-computing environment 1408 based on a whitelist of one or more approved computing systems.
  • the whitelist may be stored in a memory of the ambulatory medical device 1402 (e.g., a memory in the control and computing module of the AMD). Further, the whitelist may be configured during manufacture of the ambulatory medical device. For example, the whitelist may be configured with connection information to establish communication with one or more computing systems of a networked-computing environment.
  • the ambulatory medical device may be configured to at least obtain an address of the computing system from the whitelist and to establish a direct end-to-end data connection to the computing system of the networked-computing environment via a wireless wide area network using the address.
  • the whitelist may include unique identifiers, such as MAC addresses or static IP addresses that are associated with computing systems of the cloud services provider.
  • the ambulatory medical device may use a whitelist that identifies via a unique identifier (e.g., via an IP address, a MAC address, or a URL) permitted cloud servers or computing systems in networked computing environment.
  • the cloud computing service may have a whitelist that uses unique identifiers to specify ambulatory medical devices and/or other computing systems (e.g., remote display systems) that are permitted to communicate with the cloud computing system.
  • all communication between the ambulatory medical device and the computing may be based on a secure data transmission method.
  • the ambulatory medical device may encrypt all data using an asymmetric key.
  • the therapy data may be encrypted before being transferred to the computing system.
  • AMD may have a public key and a private key stored in one of its memories permitting the AMD to encrypt data communications transmitted by the ambulatory medical device to the computing system.
  • AMD may transmit the public key along with the therapy data to the computing system.
  • the public key provided by the AMD and a private key stored on the computing system may permit the computing system to decrypt the data received from the ambulatory medical device.
  • the public key may timeout and a new public key may be obtained from the ambulatory medical device to facilitate decrypting subsequent communications from the ambulatory medical device.
  • the public key may be associated with a time-to- live (TTL) value.
  • TTL time-to- live
  • the secure data transmission may include generating a shared secret based at least in part on the public key and the private key.
  • decrypting the encrypted data comprises using the shared secret to decrypt the encrypted data.
  • shared secret may be established using public key exchange algorithm (e.g., Diffie-Hellman key exchange algorithm).
  • the computing system may be configured to transfer the data after receiving a request to transfer data stored on the ambulatory medical device to the computing system over the direct end-to-end data connection via the wireless wide area network. Responsive to receiving the request to transfer data stored on the ambulatory medical device to the computing system, the computing system may be configured to receive, via the direct end-to-end data connection.
  • the computing system may analyze the therapy data received from the ambulatory medical device and generate a therapy report. Further, the computing system may detect an alarm condition, based on therapy data analysis, and generate an alarm that may be provided to the subject, authorized user (e.g., healthcare provider). In some cases, the therapy data may trigger an automatic response by the computing system. For example, the AMD may determine that a medicament or another disposable is running low based on the received data and may automatically reorder the medicament or the disposable.
  • the computing system may periodically receive data from the ambulatory medical device based on a regular schedule. Alternatively, or in addition, the data may be received in response to a command or when the ambulatory medical device determines it is within a certain location. For example, when the ambulatory medical device determines it is within a subject’s home or at a healthcare provider’s office based on a local area network connection or based on a geolocation system (e.g., a global positioning system (GPS)).
  • GPS global positioning system
  • additional encrypted data is received from the ambulatory medical device on an intermittent basis. Alternatively, or in addition, additional encrypted data is received from the ambulatory medical device on a continuous basis for at least a time period.
  • the ambulatory medical device may be configured to transmit data as it is generated, or shortly thereafter, (e.g., in real or near real-time (e.g., within a few milliseconds, seconds, or minutes of the data being generated)), or in bulk at specified periods of time. Transmitting the data in bulk at particular time periods may extend battery life but may provide for less up-to-date analysis. Data can be made available on-demand by keeping the transceiver always on, but this may consume more power. Thus, the scheduling of data transfer may be balanced based on different considerations, such as: (1) power consumption and (2) need to share information with authorized users or systems.
  • the computing system may be used as a backup for the ambulatory medical device.
  • the ambulatory medical device can backup data to the computing system every night, or every night that a successful communication connection is established; when it is charging; or when it is in proximity to home or a physician’s office (e.g., when subject is in waiting room, the device may upload data that the physician can then access).
  • the ambulatory medical device is replaced (e.g., for a new model or to replace a damaged device), the device can automatically synchronize with the computing system to obtain subject-specific configuration or therapy control data.
  • the therapy data comprises dose or dosage data corresponding to one or more doses of medicament provided by the ambulatory medical device to the subject. Further, the therapy data may comprise subject data corresponding to a medical or physiological state of the subject as determined by the ambulatory medical device.
  • the data provided to computing system may include any type of data that may be measured or obtained by the ambulatory medical device and may include a record of therapy provided by the ambulatory medical device.
  • the data may include a time that therapy was provided, an amount of medicament provided as part of the therapy, a measure of one or more vital signs of the subject, a measure of glucose levels at different times for the subject, a location of the subject, and the like.
  • the therapy data may be used to track the use of disposables, such as insulin or other medicament, or insulin pump site kits.
  • the computing system may automatically order or reorder disposables at a particular time based on tracking the use of the disposable.
  • the reordering of the disposables may be initiated or performed from the ambulatory medical device (e.g., via a wireless wide area network or via a local connection through a separate electronic device).
  • the data transferred to the computing systems may comprise operation data corresponding to operation of the ambulatory medical device.
  • the data may further comprise error data corresponding to an error in operation of the ambulatory medical device.
  • the data, therapy data and/or the therapy report may be stored in a memory of the computing system and/or at a storage of the networked-computing environment.
  • the method may include converting the therapy data from one format to another format.
  • the method may include converting the therapy data from a format used to store and/or present data on ambulatory medical device to a format that can be stored or processed on the computing system.
  • the therapy data is converted from a machine-readable format to a human-readable format.
  • the data may be stored in a more easily interpreted format that can be understood by different types of users.
  • the data may be presented in one format for a healthcare provider (e.g., sensor readings), a simplified format for a subject or parent of a subject, other data formats for displaying data to different types of users.
  • the therapy data collected from different AMDs associated with plurality of subjects may be aggregated for a group of subjects based on their association with an institution or organization (e.g., a clinic, an insurance company, and the like)
  • an institution or organization e.g., a clinic, an insurance company, and the like
  • a therapy report based at least in part on the therapy data may be generated by the computing system.
  • the therapy report may comprise time-series therapy data relating to the therapy delivered by the ambulatory medical device over a particular time period.
  • the therapy report may be sent to AMD wherein the subject can see the report via a user interface (e.g., a touchscreen display).
  • a user interface e.g., a touchscreen display
  • the ambulatory device data and/or data generated by the computing system based on the ambulatory device data can be viewed on a secondary display system from the computing system.
  • a clinician or parent can access the data from their personal device.
  • the communication between the computing systems and the viewing device may be encrypted.
  • permission for sharing of end user data with a 'follower' (e.g., family member) or clinician may be granted or controlled by the end user (e.g., the subject or a guardian).
  • An association between a subject, a clinic, and/or an ambulatory medical device may be performed by association of a device serial number of the ambulatory medical device with the subject and/or clinic.
  • a user e.g., a subject, clinician, or parent
  • the computing system may be configured to at least receive a request from one or more display systems 1410 that are separate from the networked computing environment to access the therapy report, therapy data or other data received by or stored in the AMD.
  • the display system may be a computing system of a medical practitioner 1414 (e.g., such as a doctor, nurse,...), a guardian of the subject 1416 (e.g., subject’s parents), an authorized user 1418 (e.g., a user authorized by the subject such as spouse, relative, friend, and the like), a healthcare provides 1410, or a device of the subject 1412 (e.g., cell phone, personal computer, tablet and the like).
  • a medical practitioner 1414 e.g., such as a doctor, nurse,
  • a guardian of the subject 1416 e.g., subject’s parents
  • an authorized user 1418 e.g., a user authorized by the subject such as spouse, relative, friend, and the like
  • a healthcare provides 1410 e.g., cell phone, personal computer, tablet and the like.
  • the display system can be a therapy data management system that analyses a therapy data associated with a specific type health problem (e.g., data associated with managing diabetes) and provides useful information to the subject or an authorized user to monitor and manage the corresponding ailment.
  • a therapy data management system that analyses a therapy data associated with a specific type health problem (e.g., data associated with managing diabetes) and provides useful information to the subject or an authorized user to monitor and manage the corresponding ailment.
  • the request may comprise an account identifier associated with a user that generated the request.
  • the account identifier may comprise a unique identifier associated with the subject.
  • the account identifier comprises a unique identifier associated with a user that is authorized to access the therapy report.
  • the user may or may not be the subject.
  • the method may further include associating the therapy data with the account identifier at a storage of the networked-computing environment.
  • the computing system may be configured to determine whether an account associated with the account identifier is permitted to view the therapy report. In some examples, account permissions may be granted and/or modified by the subject.
  • the subject can access an account at a networked computing environment 1408, for example, a cloud service provider associated with the subject, and provide one or more identifiers associated with one or more other users to give them permission to access the subject’s therapy data or report stored on the computing system.
  • a networked computing environment 1408 for example, a cloud service provider associated with the subject, and provide one or more identifiers associated with one or more other users to give them permission to access the subject’s therapy data or report stored on the computing system.
  • the hardware processor may be configured to transmit the therapy report to the display system over an encrypted communication channel.
  • the method may include receiving an identity or identification information of one or more users that are authorized to access therapy data stored at the networked-computing environment.
  • a user or subject may authorize a clinician or other healthcare provider, a parent or guardian, or other users that the subject desires to have access to the therapy data.
  • the identity information of the one or more users may include any type of information that may identify the user or enable the user to be authenticated.
  • the identity information may include a name, unique identifier (e.g., social security number), an email, an address, a phone number, account information for the user at the networked-computing environment, or any other identifying information.
  • FIG. 15 is a flow diagram that illustrates an example method that may be used by computing system 1404, to generate and share a therapy report based on encrypted therapy data received from an AMD 1402.
  • the AMD 1402 may generate the encrypted therapy data using a public key and a private key.
  • the method may include establishing a direct end-to-end data connection 1502 to an ambulatory medical device, for example, via a wireless wide area network (WAN) using a Narrowband Long-Term Evolution (NB-LTE) transceiver included in the AMD 1402.
  • WAN wireless wide area network
  • NB-LTE Narrowband Long-Term Evolution
  • the computing system may receive a public key 1504 (e.g., associated with encrypted data), from the AMD 1402 over the established connection.
  • the computing system may receive a request from the AMD 1506 to transfer data (e.g., therapy data) stored on the ambulatory medical device 1402 to the computing system 1404 over the direct end-to-end data connection.
  • the computing system 1404 may use the device ID associated with the AMD 1402 to determine whether the AMD 1402 is authorized to transfer data to the computing system 1404. If, based on the device ID, it is determined that the AMD 1402 is authorized to transfer data to the computing system, the encrypted therapy data may be transferred 1512 to the computing system.
  • the request may be denied 1510.
  • the computing system may decrypt the encrypted therapy data 1514 using a private key (e.g., stored in a memory of the computing system) and a public key received from the AMD 1402.
  • the therapy data may be used to generate a therapy report 1516.
  • the decrypted therapy data and/or therapy report may be stored in a memory of the computing system 1404.
  • the example method may further include receiving a request from a display system 1410 that is separate from the networked computing environment, to access the therapy report 1518.
  • the request may comprise an account identifier associated with a user that generated the request.
  • the method may include determining, using the account identifier, whether the account associated with the account identifier is permitted to view the therapy report. If the computing system determines that the account associated with the received account identifier does not have the required permissions, the request will be denied 1524. Responsive to determining that the account is permitted to view the therapy report, the method may include transmitting the therapy report to the display system over an encrypted communication channel.
  • the method may further include determining that the therapy data or other data received from the AMD satisfy an alert threshold condition.
  • the computing system may send an alert to one or more display systems designated to receive alerts from the computing system.
  • alert threshold condition may be associated with the health condition of the subject.
  • alert threshold condition may include subject’s glucose level (e.g., blood glucose level) is above or below a set value (hyperglycemia or hypoglycemia).
  • alert threshold condition may be associated with the operation of the AMD.
  • alert threshold condition may include the rate of therapy (e.g., the rate at which insulin is provided to a subject) being above or below a set value.
  • alert threshold condition may be associated with the temporal behavior of therapy data over a period of time.
  • the alert threshold condition may include the fluctuations or variations of the subject’s glucose level being above a set value.
  • the alert threshold condition may be defined or set by health provider.
  • the health provider may change one or more alert threshold conditions based on the health condition of the subject.
  • FIG. 16 is block diagram, illustrating an example network and data flow configuration where an AMD 1602, which is directly connected to a computing system 1604 (e.g., computing system within a cloud network 1606), may generate and send alerts 1619 (e.g., alert messages, alert signals and the like) upon determining that data received from the AMD 1607 satisfies a threshold condition.
  • the computing system 1604 may be part of networked computing environment 1608 (e.g., a data center, networked computing system), or cloud network 1606 or cloud computing system of a cloud service provider.
  • the computing system may include one or more non-transitional memories and one or more hardware processors configured to execute the computer-executable instructions stored in one or more non- transitional memories.
  • the AMD may receive data from one or more medical sensors 1605 (e.g., analyte sensor, temperature sensor, heartbeat sensor, and the like) and/or one or more environmental sensors (e.g., geolocation receiver, motions sensor, accelerometer and the like.). These sensors may be included in the AMD unit or may be connected to the AMD via a wired or wireless link.
  • medical sensors 1605 e.g., analyte sensor, temperature sensor, heartbeat sensor, and the like
  • environmental sensors e.g., geolocation receiver, motions sensor, accelerometer and the like.
  • the display systems receiving the alert 1611 may be display systems that have already received therapy reports from the computing system 1604.
  • a group of display systems may be selected and authorized by the subject, who is receiving therapy from the AMD, to receive alerts 1611.
  • the display systems that may receive alerts 1611 from the AMD may include: a medical practitioner 1614 (e.g., such as a doctor, nurse,...), a guardian of the subject 1616 (e.g., subject’s parents), an emergency service provider 1618, an authorized user 1420 (e.g., a user authorized by the subject such as spouse, relative, friend, and the like), a healthcare provider 1622, or a device of the subject 1612 (e.g., cell phone, personal computer, tablet and the like).
  • the computing system 1604 may send an alert 1609 to the AMD 1602.
  • the AMD 1602 may be configured to establish a connection to support continuous data transfer to the computing system 1604 for a given period of time (e.g., provided to the AMD by the subject), in order to capture any data that is generated over that period and satisfies an alert threshold condition.
  • the subject may request a continuous connection between AMD and the computing system when going for hike alone to make sure that if his/her health condition deteriorate during the hike, an alert is sent to authorized display systems.
  • a geolocation sensor e.g., a Global Positioning System (GPS) receiver
  • GPS Global Positioning System
  • the ambulatory medical device may include or be connected to an accelerometer or a geolocation system. This velocity of the ambulatory medical device may be determined based at least in part on the accelerometer or geolocation system.
  • the computing system 1604 can provide intelligent alerts.
  • the computing system may automatically alert an emergency service provider 1618 that a subject is at risk of hypoglycemia and may be driving. Further, the computing system can provide a location of the subject to the emergency services provider 1618.
  • the computing system can generate alerts based on a trend of the aggregated therapy data or based on therapy data that is an outlier to the aggregate therapy data or an outlier to a time-based average of the therapy data.
  • the geolocation sensor and/or a motion sensor can be used to detect velocity of a subject to enable intelligent motion-sensitive alerts. For example, if the subject is moving at 60 mph and experiences low glucose level, the system may enable a set of driving alerts and schedule possibly therapy in the future. The driving alerts may inform the subject to pull over immediately due to a risk of a hypoglycemic event. Further, an emergency responder may be informed of a subject location using based on information obtained from the geolocation sensor. If the subject is moving at 6-7 mph, exercise alerts may be enabled to, for example, alert the user to pause exercising and attend to low blood glucose.
  • a motion sensor e.g., an accelerometer
  • the system can enable automatic notification to emergency services. Further, a determination of the subject’s motion can be used to automatically adjust setpoint (e.g., raise setpoint during exercise). The activity level of the subject can be sensed and use to improve alerts and therapy.
  • setpoint e.g., raise setpoint during exercise
  • the cloud server can send a text message or call to a follower’ s and/or end user’s phone or smart device in case the therapy data satisfies an alert threshold. These messages may be provided from the cloud computing system to a third-party device in case roaming or disabling of the data plan on the ambulatory medical device occurs (e.g., no TCP/IP available). Further, the cloud computing service may send a text message or call 911 in case of a detected emergency.
  • the cloud server can track, for example, via GPS, the end user’ s most recent location and share that information with a follower and/or emergency personnel. Moreover, the cloud computing system may enable an end user to order and reorder medical supplies directly from the viewing device.
  • the computing system can generate notifications (e.g., generate a message when there is a risk of hypoglycemia). Further, more detailed processing in the cloud can result in improved recommendations (e.g., Tmax, setpoint, or other control parameters)
  • FIG. 17 is a flow diagram illustrating an example method that may be used by computing system 1604, to generate and send alerts (e.g., alert messages, alert signals and the like) to one or more authorized devices and to the AMD.
  • the method may include establishing a direct end-to-end data connection 1702 to an ambulatory medical device, for example, via a wireless wide area network (WAN) using a Narrowband Long-Term Evolution (NB-LTE) transceiver included in the AMD 1602.
  • WAN wireless wide area network
  • NB-LTE Narrowband Long-Term Evolution
  • the direct end-to-end connection may be established for a given period of time set by the subject or an authorized user (e.g., a guardian of the subject).
  • the computing system may receive a public key 1704, from the AMD 1602 over the established connection.
  • the computing system may receive a request from the AMD 1706 to transfer data (e.g., therapy data, medical sensor data or environmental sensor data) generated by the ambulatory medical device 1602 to the computing system 1604 over the direct end-to-end data connection.
  • the request may include a time period during which AMD continuously transmits any data generated by the AMD 1602 or obtained from one or more sensors (e.g., medical sensors 1603 or environmental sensors 1605), to the computing system 1604.
  • the time period for continuous data transfer from the AMD 1602 to the computing system 1604, may be provided by the subject or a guardian of eth subject to the AMD.
  • the computing system 1604 may use the device ID associated with the AMD 1602 to determine whether the AMD 1602 is authorized to transfer data to the computing system 1604. If, based on the device ID, it is determined that the AMD 1602 is authorized to transfer data to the computing system 1604, the encrypted therapy data may be transferred 1712 to the computing system 1604. If, based on the device ID, it is determined that the AMD 1602 is not authorized to transfer data to the computing system, the request may be denied 1610.
  • the computing system 1604 may decrypt the received data 1714 using a private key (e.g., stored in a memory of the computing system 1604) and a public key received 1702 from the AMD 1602. In some examples, the computing system 1604 may determine whether the received data (e.g., therapy data, medical sensor data or the environmental sensor data), satisfies a threshold condition 1716. In some cases, the threshold condition may be provided to the AMD by the subject or an authorized user (e.g., a guardian of the subject). In some other examples, the threshold condition may be provided by a healthcare provider. In some such examples, the threshold condition may be stored in a memory of the AMD.
  • a private key e.g., stored in a memory of the computing system 1604
  • the computing system 1604 may determine whether the received data (e.g., therapy data, medical sensor data or the environmental sensor data), satisfies a threshold condition 1716.
  • the threshold condition may be provided to the AMD
  • an alert may be generated and sent 1718 to one or more display systems 1610 that are authorized (e.g., by the subject or a guardian of the subject) to receive alerts.
  • the subject or the guardian may authorize one or more display systems 1610 to receive alerts by providing the account IDs of the one or more displays systems to the computing system 1604 or the networked computing environment 1608.
  • the ambulatory medicament device may include a user interface (e.g., touchscreen interface or a non-touchscreen interface) that may present one or more user-interface screens to a user enabling the user to modify one or more therapy settings of the ambulatory medicament device, such as a quantity of medicament delivered when a condition is met or the condition that triggers the delivery of medicament to a subject.
  • the user may be a subject receiving medicament or therapy, or may be another user, such as a clinician or healthcare provider, or a parent or guardian.
  • ambulatory medicament devices that include a user interface
  • a setting is accidentally modified or is modified (intentionally or unintentionally) by a user that does not fully comprehend his or her action (e.g., a child or a user with a reduced mental capacity).
  • ambulatory medicament devices may accidentally have settings modified by inadvertent interactions with a user interface, such as may occur when an ambulatory medicament device is worn against the body of a subject.
  • This section relates to an ambulatory medicament device (AMD) to prevent an inadvertent modification in medicament deliver, for example, in the event of a setting of the AMD being accidentally modified by a user or inadvertent interactions with a user interface.
  • the user may modify the control or configuration the AMD using a user interface.
  • the control or configuration of the AMD is accidentally modified through the user interface.
  • the user may transport the ambulatory medical device, there is a danger that the user will inadvertently activate input in the ambulatory medical device that initiates a therapy change input (e.g., by applying pressure on the ambulatory medical device that may be placed in the jacket pocket of the user).
  • the control and computing module (CCM) of the AMD may include a set of therapy change procedures 1828 implemented to prevent therapy change inputs 1829 that are inadvertent.
  • the therapy change procedures 1828 may be implemented as instructions stored in a memory of CCM (e.g., the main memory 616) and executed by the processor 614.
  • the therapy change input 1829, received from a user 1827, may be verified by the therapy change procedures 1828 before the ambulatory medical device 600 provides the therapy change delivery 1807.
  • Some or all the user interactions with the user interface module 1808 may be controlled and analyzed by the control and computing module (CCM) 610 via one or more therapy change procedures 1828.
  • the user 1827 may wake or unlock the AMD by interacting with a wake interface 1822.
  • the wake interface 1822 can be any of the additional user interfaces mentioned above, configured to generate a wake input to the CCM when detecting a pre-set user interaction.
  • the therapy change input 1829 can be an input provided by the user 1827 to change a therapy that is currently being delivered to the user 1827.
  • the therapy change input 1829 may cause the insulin or glucagon infusion pump to start infusing an amount of insulin or glucagon into the user 1827.
  • the therapy change input 1829 may modify the rate of insulin or glucagon infusion into the user 1827.
  • the therapy change input 1829 may also cancel insulin or glucagon infusion into the user 1827 from the insulin or glucagon infusion pump.
  • a wake action is detected by the wake interface 1822, a wake input is sent to the control and computing module 610 wherein it imitates a wake control procedure 1834 that generates a wake signal to wake/unlock the user interface (e.g., a touch screen display).
  • a wake control procedure 1834 that generates a wake signal to wake/unlock the user interface (e.g., a touch screen display).
  • a user may interact with the touchscreen display 1824, alphanumeric pad 1826 or other types of user interfaces that may be included in the user interface module 1808, to obtain access to therapy change user interface.
  • the therapy change user interface may be activated by a first user interaction with the user interface (e.g., touchscreen display 1824).
  • the user interface module 1808 sends an input signal to the control and computing module 610 wherein it is analyzed by a therapy change control procedure 1836. If it is determined that the first user interaction satisfies a set of predefined conditions, the therapy change control procedure 1836 generates a signal to the user interface module 1808 to activate the therapy change user interface.
  • the therapy change user interface may be limited based on the first user interaction.
  • the therapy change control procedure 1836 may send one of two signals to the user interface module 1808.
  • the therapy change user interface may then unlock one of two different therapy change user interfaces that result in different options of therapy change selections for the user 1827.
  • a therapy change selection to make a significant therapy change such as dramatically increase the rate of insulin or glucagon infusion rate, requires a first user interaction that is different from the first user interaction that would be required for an insulin or glucagon infusion at a normal or prescribed rate.
  • the first user interaction may be a simple interaction (e.g., a simple gesture) that unlocks a therapy change user interface with therapy change selections that are limited.
  • Another first user interaction may be a complicated interaction (e.g., a series of complex gestures) that unlocks a therapy change user interface with therapy change selections that have no limits.
  • An example of this implementation may be useful for child users. The child user may perform the first gesture that is made up of a series of simple inputs to unlock therapy change selections that are limited. An adult user may perform the first gesture that is made up of a series of complex inputs to unlock the therapy change user interface with therapy change selections that have no limits.
  • the therapy change user interface may provide one or more control or configuration elements that enable the user to modify the control or configuration of the ambulatory medicament device.
  • the control or configuration element may include any type of user interface screen on the touchscreen, or other type of user interface in the non-touchscreen context, that enables or permits a user to change a configuration of the ambulatory medicament device.
  • This change in configuration of the ambulatory medicament device may relate to a change in the therapy provided or in the detection of a triggering event that causes therapy (e.g., medicament) to be provided to a subject.
  • the change in configuration may include a selection between one or more hormones that regulate blood glucose level (e.g., insulin or glucagon) of a user, an amount of the one or more hormones that regulate blood glucose level of the user.
  • a change to the configuration of the ambulatory medicament device is automatically and/or instantly recognized or implemented by the ambulatory medicament device, and/or transmitted to the ambulatory medicament device.
  • a confirmation of the change may be required before the change is implemented by or transmitted to the ambulatory medicament device.
  • This confirmation may be entered based on a second user interaction with a user interface (e.g., touchscreen display 1824).
  • a user interface e.g., touchscreen display 1824.
  • the user interface module 1808 sends an input signal to the control and computing module 2110 wherein it is analyzed by a therapy change control procedure 1836. If it is determined that the second user interaction satisfies a set of predefined conditions, the therapy change control procedure 1836 implements the change to the configuration of the AMD.
  • the first and/or second user interactions may include the selection of an icon, a series of taps or inputs, one or more gestures (e.g., a linear swipe, an arcuate swipe, a circular swipe, or other simple or complex movement across the touchscreen), performing a pattern or sequence on the touchscreen (e.g., drawing an image), a multi-touch or multi-input interaction, a combination of the foregoing, or any other type of interaction with a touchscreen, or portion thereof.
  • the series of inputs may be any combination of touch movements, touch points, numerical characters, alphabetical characters, and other symbols.
  • Gesture interactions can be guided by visual indicia displayed or printed on the AMD.
  • the visual indicia can include animations that suggest or guide user interactions with a touchscreen.
  • the first user interaction can include an arcuate swipe around at least a portion of a generally circular icon or logo.
  • the first and/or second user interactions may include a predetermined sequence of numerical or alphabetical inputs.
  • a series of multiple inputs the range of parameters for an input may be dependent on other inputs in the series. For example, required start position of a touch movement may be dependent on the position of the previous touch movement.
  • the amount of time that the series of inputs are to be entered may also be a part of the range of parameters. For example, a series of inputs may need to be entered within 3 seconds, 5 seconds, or 15 seconds, etc. to successfully complete an input process.
  • one or more of the interactions may include interacting with a sensor as an optical sensor (e.g., visible light or IR sensor), biometric sensor (e.g., a fingerprint or retinal scanner), a proximity sensor, a gyroscope, or a combination of accelerometer and gyroscope, and the like.
  • a sensor as an optical sensor (e.g., visible light or IR sensor), biometric sensor (e.g., a fingerprint or retinal scanner), a proximity sensor, a gyroscope, or a combination of accelerometer and gyroscope, and the like.
  • the second user interaction may be made through a wireless signal such as RFID or Bluetooth.
  • the second user interaction may include receiving a selection of an indicator box that correspond to either insulin or glucagon and receiving a predetermined sequence of numerical inputs in order to deliver the therapy change selection.
  • the type of user interaction that unlocks the touchscreen, provides access to a configuration screen, and/or confirms a change to the configuration of the ambulatory medicament device may be the same or may differ.
  • the system may have a time-out such that if no interaction occurs for a set period of time, the user interface will turn off and the therapy change request process has to start again. In one implementation of the time-out, if no interaction occurs for more than 30 seconds after the system is waked/unlocked before the second user interaction is received by the user interface, the user interface will be deactivated.
  • the ambulatory medicament device may begin operating with the changed configuration.
  • This operation may include triggering therapy based on the new configuration or providing therapy based on the new configuration.
  • the ambulatory medicament device may generate a dose control signal based at least in part on the modified configuration or control parameter, or may detect a trigger based at least in part on the modified configuration or control parameter that leads to the provisioning of therapy.
  • the changes made through the therapy change user interface are sent to CCM wherein the therapy control change procedure 1836 in CCM transfers the changes to the device and subject monitoring procedure 1832.
  • the device and subject monitoring procedure 1832 may be implemented in the CCM 610 to monitor the status of the AMD (e.g., therapy delivery configuration) and the health condition of the user 1827 (or a subject).
  • the subject monitoring procedure 1832 may receive information about a therapy change requested by a user 1827 through a user interface (a touchscreen display 1824 or alphanumeric pad 1826) or information about glucose level in subject’s blood from the subject sensor 1820.
  • the device and subject monitoring procedure 1832 may transmit the information pertaining a health condition of the subject and/or the AMD configuration, to the medicament dose control procedure 1830.
  • the parameters in the medicament dose control procedure 1830 may be adjusted based on the changes and/or information captured by the device and subject monitoring procedure 1832.
  • the medicament dose control procedure 1830 controls the medicament delivery interface 1806 by providing a medicament dose signal.
  • the medicament does control may be generated based on detected conditions or physiological characteristics of the subject (e.g., provided by the readings of the subject sensor 1820) and according to parameter values received from the therapy change control procedure 1836.
  • the medicament delivery interface 1806 may provide a therapy change delivery to the user according to the information received by device and subject monitoring procedure 1832.
  • the dose control signals may be produced based on time (e.g., medicament may be delivered on a periodic basis), one or more a command, indication that the subject is planning to engage or is engaging in a particular activity (e.g., eating a meal, exercising, sleeping, fasting, etc.), or any other factor that may relate to or cause the triggering of therapy (e.g., medicament delivery).
  • FIG. 19 is a flow diagram illustrating an example method that may be used by an AMD to allow a user to change the configuration of the ambulatory medicament device using a touch screen user interface.
  • the user may initiate the configuration change process by waking/unlocking the touch screen using a wake action.
  • the wake interface sends a wake input to CCM 1904.
  • the wake procedure generates a wake signal 1906 that unlocks the touch screen 1908.
  • the therapy change user interface is unlocked 1912.
  • the user may change the therapy configuration 1914.
  • the user may confirm the changes made, by providing a second gesture on the touch screen 1916. Once the confirmation is received 1916 the requested changes will be implemented, and the ambulatory medicament device may begin operating with the changed configuration. In some examples, once the user confirms the changes made, a dose control signal may be sent to the medicament delivery interface 1806 that triggers a therapy change delivery to the subject.
  • the ambulatory medicament device may have a timeout feature.
  • the timeout feature may cause the ambulatory medicament device or the control device to enter a sleep or locked state after a period of time of inactivity by the user.
  • the timeout feature may cause the ambulatory medicament device or the control device to enter a sleep or locked state after a particular period of time regardless of whether the user is interacting with the ambulatory medicament device or control device.
  • a user may have a limited period of time to modify he configuration of the ambulatory medicament device.
  • the therapy change made by a user may trigger the delivery of a medicament according to the therapy change received and confirmed by a user. This therapy change delivery may occur after a set time from period from receiving the confirmation.
  • an alarm status indicator may be presented to the user via the user interface.
  • the alarm status indicator can be an alert message or an alert symbol.
  • the alarm status indicator may be related to a configuration change made by a user, a change in the status of the AMD not related to a user input, or the condition of the subject (e.g., detected by the subject sensor).
  • FIG. 20A is an illustration of the touchscreen display 2000 of an example AMD after the touch screen is waked/unlocked by a wake action of a user and before the first user gesture is received. Even while the touchscreen display is locked, the touchscreen display 2000 may display any images, animations, text, or other graphics.
  • the first gesture prompt 2005 displays to the user 1827 the input required to unlock the therapy change user interface.
  • the first gesture prompt 2005 shows the user 1827 that a touch movement that begins at the greater-than symbol and moves right across the “Unlock” text is the acceptable first gesture.
  • the refill status of the ambulatory medical device 600 is shown in a graphic representation 2010.
  • the graphic representation 2010 shows that the insulin cartridge in the ambulatory medical device 600 is almost full.
  • a current glucose level 2015 is shown at the top of the touchscreen display 2000, which can inform the user 1827 of the need for a hormone that regulates blood glucose levels.
  • the touchscreen display 2000 also shows a graphic representation 2020 of a cartridge of glucagon.
  • the graphic representation of an alarm 2025 in the touchscreen display 2000 shows that an alert is set on the ambulatory medical device 600.
  • FIG. 20B is an illustration of an example touchscreen display 2050 that may prompt the user to enter a predetermined series of inputs for the first gesture or second gesture.
  • the touchscreen display 2050 may display touchable number keys 2055.
  • the touchscreen display 2050 prompts the user 1827 to enter the series of inputs that complete the first gesture or second gesture.
  • the text Enter Code 2060 prompts the user 1827 to enter a predetermined or preselected numerical sequence as part of the first gesture or second gesture.
  • the numerical sequence being typed by the user 1827 is displayed in field 2065 as it is entered as an aid to the user 1827.
  • the input 2070 of the touchscreen display 2050 shows that a touch movement of a swipe right across the bottom of the screen is required to complete the predetermined series of inputs for the first gesture or second gesture.
  • a Bluetooth connection symbol 2075 shows that the ambulatory medical device 600 is paired or can be paired to another electronic device.
  • FIG. 20C is an illustration of an example therapy change user interface (in this case a touchscreen display 2002).
  • the touch screen display may the user 1827 prompt to select a hormone that regulates blood glucose level.
  • the touchscreen display 2002 presents the user 1827 with an option to select between two hormones.
  • the touchscreen display 2002 aids the user 1827 by showing the selection 2008 for the user 1827.
  • the selected hormone is “insulin Only” 2008.
  • the user 1827 is also given the options of selecting the hormone glucagon only button 2012 or both insulin & glucagon button 2004 to regulate blood glucose level. Once the user 1827 selects between the one or more hormones that regulate glucose level.
  • the Next button 2014 may be selected to complete the therapy change selection or select more options.
  • the therapy change user interface prompts the user 1827 to select an amount of the one or more hormones that regulate glucose level of the user 1827.
  • the user 1827 may be prompted to select a glucose level and the ambulatory medical device or the glucose level control system (e.g., AMD 100, or AMD 600) may choose the hormone and the amount of the hormone.
  • FIG. 20D is an illustration of another therapy change user interface on a touchscreen display 2016.
  • the user 1827 is given a multitude of options.
  • One or more options in the therapy change user interface allow the user 1827 to make a therapy change selection.
  • Other options are related to the therapy change selection.
  • a Deliver Hormone Button 2030 allows the user 1827 to select a therapy change that delivers a hormone that regulates blood glucose to the user 1827.
  • a Test Blood glucose Button 2018 allows the user 1827 to test the glucose level of the user 1827.
  • a Generate Report Button 2020 generates a document that reports the therapy changes that have been delivered to the user 1827.
  • a Refill Cartridge Button 2022 allows the user 1827 to fill a cartridge in the ambulatory medical device 600 with medicament.
  • An Upload to Cloud Button 2026 allows the user 1827 to transmit therapy change information to a cloud-based server.
  • a Sound Control Button 2024 allows the user 1827 to control the sounds emitted by the ambulatory medical device 600.
  • a Settings Button 2028 allows the user 1827 to manipulate other settings of the ambulatory medical device 600.
  • an alarm status indicator may be presented to the user via the user interface to alert the user about a change made or occurred in the AMD configuration.
  • the user 1827 may make a therapy change, e.g.., by providing a therapy change input 1829 to the using the user interface module 1808 and based on the procedure illustrated in FIG. 19.
  • therapy change procedure 1836 implements the therapy change
  • the AMD may alert the user that a therapy change is implemented.
  • the alert message or symbol may be presented on a user interface (e.g., touch screen display) before and/or during the therapy change delivery 1807.
  • alarm indicator may inform the user 1827 that a therapy change is about to occur. Any number of details of the therapy change may be displayed as part of the alert message or symbol.
  • the alarm status indicator may appear after the user unlocks or wakes the user interface using a wake action.
  • FIG. 21 is a flow diagram illustrating an example method that may be used by an AMD to generate an alarm status indicator.
  • the device and subject monitoring procedure (excused within CCM), may continuously monitor the status of the AMD (e.g., the user interface, different modules of the AMD and the like) as well as the health condition of a subject (e.g., using various subject sensors such as analyte sensors).
  • the device and subject monitoring procedure may determine whether the received status information satisfies an alarm condition 2106. If the received status information does not satisfy an alarm condition, no cation will be taken and device and subject monitoring procedure continuous monitoring the AMD and the subject.
  • the system searches for a wake signal 2108. If no wake signal is detected, the system waits for a wake signal to be received 2110. Once a wake signal is received via one or more user interfaces or sensors, the CCM may generate a display of a touchscreen lock screen interface 2112 and display one or more alarm status indicators, corresponding to the detected alarm condition, on the lock screen.
  • the AMD may allow the user to provide a therapy change and then cancel the therapy change.
  • FIG. 22 is a flow diagram illustrating an example method that may be used to cancel a therapy change using a touchscreen interface.
  • the user may unlock the touchscreen display 2202 using a wake action and get access to a therapy change user interface 2204 (e.g., using a first gesture), where one or more therapy control elements may be displayed.
  • an indication of a modification to a therapy control element may be received 2206 by the user interface followed by a confirmation of the modification made 2208 (e.g., a second gesture).
  • the corresponding control parameter may be changes from a first setting to a second setting 2210.
  • the user may decide to cancel it, for example, after realizing that requested change is erroneous.
  • the user may provide a third gesture 2212 on the touch screen.
  • the therapy change procedure may restore the modified control parameter to the first setting 2214.
  • the third gesture may a restore gesture.
  • the restore gesture may be a swipe gesture.
  • the swipe gesture may be performed near or in a region of the therapy change user interface that is occupied by the therapy control element.
  • An example of a restore swipe gesture may be performed from a starting swipe position to an ending swipe position located closer to a left edge of the touchscreen than the starting swipe position.
  • the restore gesture is received on a different user interface screen than a therapy change user interface wherein one or more therapy control element are provided.
  • the restore gesture is performed in the opposite direction from a therapy change confirmation gesture that confirms the modification to the therapy control element.
  • the restore gesture in order to cancel a therapy change request, has to be provided within a set time period after the confirmation gesture is received by the user interface.
  • one or more dose control signals may be provided to the medicament delivery interface resulting in one or more therapy change deliveries.
  • the system may allow the user, to modify a therapy change before confirmation.
  • the user may modify a therapy control element for a second time to change the corresponding control parameter from a second setting to a third setting.
  • the third setting may be the same as the first setting.
  • the first setting or the third setting may be a default setting.
  • the first setting or the third setting may be a restore setting.
  • FIG. 23A is an illustration of a touchscreen display 2300 alerting the user that the delivery of one or more medicaments will occur.
  • the alert may be accompanied by sound or vibration effects.
  • the alert informs the user 1827 a delivery of medicament will occur in 2 seconds 2305.
  • the touchscreen display 2300 is further allowing the user 1827 to perform a gesture to cancel the therapy change.
  • the gesture to cancel the delivery is a touch movement that starts at the less-than symbol 2310 and swipes left across the “Cancel” text.
  • a single gesture by the user 1827 may cancel the therapy change.
  • input of the wake signal, the first gesture, the therapy change selection, and the second gesture may all be required to cancel a therapy that is being delivered.
  • the user may be able to cancel a therapy change delivery triggered based on therapy change made by the user.
  • the user may get access to the user interface using a wake action and provide a gesture to cancel the ongoing therapy corresponding to a therapy change delivery.
  • FIG. 23B is an illustration of a touchscreen display 2350 showing that a medicament is being delivered to the user 1827.
  • the text Delivering 2355 informs the user 1827 that a medicament is currently being delivered to the user 1827.
  • the progress bar 2360 is a graphic representation of the progress of the delivery. As shown in FIG. 23B, the delivery is only starting and zero progress has been completed.
  • the touchscreen display 2350 is allowing the user 1827 to perform a gesture to cancel the delivery, which includes interrupting and discontinuing the delivery if it had already begun but has not yet been completed.
  • the gesture to cancel the delivery is a touch movement that starts at the less-than symbol 2365 and swipes left across the “Cancel” text.
  • the therapy change delivery 1807 may be canceled by an input by the user 1827.
  • the input to cancel a therapy change delivery 1807 may be any input such as a wake signal input or a series of touch inputs such as a gesture.
  • the subject when a subject suspends the treatment delivered by a medical device, the subject may forget to resume the treatment delivered by the medical device. In some cases, the health condition of the subject may deteriorate during the suspension period requiring therapy delivery prior to end of the suspension period. As such, there is a need for AMDs that allows subjects to safely suspend treatment for temporary amounts of time.
  • the AMD may support a therapy suspension and resumption procedure allowing a user to suspend all therapies or a subset of therapies for a period of time defined by the user as well as automatic resumption of one or more therapies at the end of the requested suspension period or when a threshold condition is met (e.g., a threshold condition associated with the health condition of the subject).
  • a threshold condition e.g., a threshold condition associated with the health condition of the subject.
  • inadvertent activation and/or resumption of therapy delivery can be dangerous (e.g., when the AMD is an insulin and/or glucagon infusion device).
  • the AMD may be configured to avoid inadvertent suspension or resumption of therapies.
  • inadvertent activations of suspensions of medicament delivery may be prevented by requiring a user to perform gestures to activate suspension on the ambulatory medical device. The gestures may be entered at a particular prompt to activate a therapy suspension.
  • One application of the therapy suspension with automatic resumption feature in an AMD can be in the field of diabetes drug delivery.
  • the user may desire to suspend delivery of insulin when exercising, which may have a glucose lowering effect.
  • Suspension of insulin delivery can prevent a subject from entering a hypoglycemic state (extreme low blood glucose level), which carries severe complications.
  • a hyperglycemic state high glucose that may result in complications such as diabetic ketoacidosis or neurovascular complications
  • the subject s glucose level may rise above or below a dangerous level during the period of exercise. In these situations, the automatic medicament delivery resumption may improve the health of the subject.
  • the AMD may suspend one or more therapy deliveries when the AMD receives an indication that therapy (e.g., delivery of medicament) is to be suspended.
  • the indication that therapy is to be suspended may be a command from a user.
  • the user is the subject, but the user may also include other users that may have a say or interest in the care of the subject.
  • the user may be a clinician or other healthcare provider, or a parent or guardian.
  • the indication that the therapy or medicament delivery is to be suspended may be a command received via an interface of the ambulatory medicament device or from another device that provides the user with an interface to request that medicament delivery be suspended.
  • the device may be a smartwatch, smartphone, laptop or desktop, or other control device that can communicate via a wired or wireless connection with the ambulatory medical device.
  • the indication that the therapy or medicament delivery is to be suspended may be received from the ambulatory medicament device itself. For example, if the quantity of medicament available to the ambulatory medicament device drops below a threshold (e.g., the cartridge or reservoir is empty or below a minimum dosage amount), a signal may be generated to suspend medicament delivery. In some embodiments, suspension of therapy occurs based on a loss of a sensor signal, such as the loss of a glucose level signal.
  • FIG. 24 illustrates the interconnection among modules and procedures 2428 involved in receiving, accepting and/or canceling a therapy suspension request, in an example GLCS or AMD.
  • a request for suspending one or more therapies can be made by a user 2427 by providing an input 2429 (e.g., the start and stop time for therapy suspension, selecting the type of therapy that should be suspended, and the like), through a therapy suspension user interface provided by the user interface module 2408.
  • the user 2427 may be the subject and the input 2429 may be provided by the subject.
  • the therapy suspension user interface sends the suspension request along with the corresponding information to CCM wherein the therapy suspension control procedure 2436, implemented in CCM, processes and sends a therapy suspension signal to the device and subject monitoring procedure 2432.
  • the therapy suspension control procedure may include a therapy suspension request verification procedure to verify the therapy suspension request.
  • the device and subject monitoring procedure 2432 may be implemented in the CCM 610 to monitor the status of the AMD (e.g., therapy delivery configuration) and the health condition of the user 2427 (or a subject). For example, when the device and subject monitoring procedure 2432 receives the request for therapy suspension, it may send a signal to the medicament dose control procedure 2430 indicating that no dose control signal should be send to the medicament delivery interface 2406 during the period request by the user 2427. In some cases, if during the suspension period, certain pre-set conditions are satisfied, the device and subject monitoring procedure 2432 automatically resumes the therapy delivery by sending a signal to the medicament dose control procedure 2430.
  • the device and subject monitoring procedure 2432 may send a signal to the medicament dose control procedure 2430 indicating that no dose control signal should be send to the medicament delivery interface 2406 during the period request by the user 2427. In some cases, if during the suspension period, certain pre-set conditions are satisfied, the device and subject monitoring procedure 2432 automatically resumes the therapy delivery by sending a signal to the medicament dose control procedure 2430.
  • the subject sensor 2420 may resume the medicament delivery to the user 2427 by a sending a dose control signal to the medicament delivery interface 2406.
  • the user may initiate a therapy suspension request starting with a wake action (e.g., received by the wake interface 2422 and processed by the wake control procedure 2434), that activates the user interface module 2408.
  • a wake action e.g., received by the wake interface 2422 and processed by the wake control procedure 2434
  • the user may unlock a therapy suspension user interface where the information pertaining therapy suspension is provided.
  • the user may confirm the requested therapy suspension using a second interaction with the user interface.
  • the system may allow access to the therapy suspension user interface and accept the suspension request, if the first and second interaction with the user interface are verified by the therapy suspension control procedure 2436.
  • the therapy suspension control procedure 2436 may receive the request for suspension and suspension information from another device connected to the ambulatory medical device 600 (e.g., through the communication module).
  • the suspension information provided by the user may include a set of parameters evaluated for suspending therapy.
  • the suspension information may include the dates and/or times for starting and ending the therapy suspension, threshold values associated with a threshold condition that may trigger an early resumption of the therapy delivery, and the like.
  • suspension information may indicate that the suspension of therapy should happen at a particular time or after a particular event (e.g., after the next dose of medicament is delivered or after the condition of the subject reaches a particular state, such as the middle of a desired glucose level range).
  • the threshold values may be associated with input provided by the subject sensor 2420 or other types of sensors that may be used to monitor one or more parameters associated with the health condition of the user 2427.
  • the parameters for a suspension may include the start and stop conditions for a suspension.
  • the start condition for a suspension may be a condition that, when met, activates a suspension. In some such examples, the start condition is met when a timer runs out.
  • the stop condition is a condition that, when met, ends the suspension. In one example, the stop condition is met when a timer runs out. In another example, the stop condition is met when a threshold is met.
  • a threshold may be related to a measurement taken by ambulatory medical device (e.g., by a subject sensor 2420), such as a glucose concentration of the blood of a user. The threshold may be met if the glucose concentration goes above, goes below, or matches a set concentration.
  • a time condition and a threshold condition may be set simultaneously.
  • a user may specify that a suspension will end after a set time. However, the suspension may end sooner than the set time if the glucose concentration of the user meets a threshold.
  • the request to suspend therapy may include an indefinite suspension period.
  • the request may not include a time period specified by a user or an identity of a resumption condition.
  • the indication may include a request to temporarily suspend delivery of therapy for a defined period of time or until a further interaction or event occurs.
  • the resumption condition can include an expiration of time or an active event (e.g., a command or a determined condition of a subject).
  • the therapy to be suspended may include any type of therapy.
  • the therapy to be suspended may be the suspension of the delivery of medicament, which may include insulin, counter- regulatory agent (e.g., Glucagon), or both insulin and a counter-regulatory agent.
  • the ambulatory medicament device may be capable of and/or configured to administer multiple medicaments (e.g., both insulin and a counter-regulatory agent).
  • the request to suspend therapy may include a request to suspend one (e.g., insulin or the counter-regulatory agent) or both of the medicaments.
  • the interactions with the user interface may include the selection of an icon, a series of taps or inputs, one or more gestures (e.g., a swipe or other simple or complex movement across the touchscreen), performing a pattern or sequence on the touchscreen (e.g., drawing an image), a multi-touch or multi-input interaction, a combination of the foregoing, or any other type of interaction with a touchscreen, or portion thereof.
  • the series of inputs may be any combination of touch movements, touch points, numerical characters, alphabetical characters, and other symbols.
  • the first and/or second user interactions may include a predetermined sequence of numerical or alphabetical inputs.
  • a series of multiple inputs the range of parameters for an input may be dependent on other inputs in the series.
  • required start position of a touch movement may be dependent on the position of the previous touch movement.
  • the time that the series of inputs are entered may also be a part of the range of parameters.
  • a series of inputs may need to be entered in no less than 3 seconds or more than 3 seconds, and no more than 15 seconds or less than 15 seconds.
  • a visual guide may assist the user in generating the user interaction.
  • one or more arrows or images may be presented to the user to guide the user in providing the command to suspend the delivery of therapy.
  • one or more of the interactions may include interacting with a sensor as an optical sensor (e.g., visible light or IR sensor), biometric sensor (e.g., a fingerprint or retinal scanner), a proximity sensor, a gyroscope, or a combination of accelerometer and gyroscope, and the like.
  • a sensor as an optical sensor (e.g., visible light or IR sensor), biometric sensor (e.g., a fingerprint or retinal scanner), a proximity sensor, a gyroscope, or a combination of accelerometer and gyroscope, and the like.
  • the second user interaction may be made through a wireless signal such as RFID or Bluetooth.
  • the second user interaction may include receiving a selection of an indicator box that correspond to either insulin or glucagon and receiving a predetermined sequence of numerical inputs in order to deliver the therapy change selection.
  • the type of user interaction that unlocks the touchscreen, provides access to a therapy suspension user interface or confirms a suspension request may be the same or may differ.
  • the system may have a time-out such that if no interaction occurs for a set period of time at a step during the therapy suspension request process, the user interface may turn off. In some such cases, the therapy suspension request process may need to restart if therapy suspension is desired. In one implementation of the timeout, if no interaction occurs for more than 30 seconds after the system is waked/unlocked before the second user interaction is received by the user interface, the user interface will be deactivated.
  • FIG. 25 is a flow diagram illustrating an example method for receiving and implementing a suspension request, which may be implemented by an AMD.
  • the user may use a touchscreen interface to request and confirm a therapy suspension.
  • the AMD may wait for a first gesture on the touchscreen.
  • a therapy user interface may be activated 2506 where the user can request a therapy suspension and provide 2508 the suspension information (e.g., a start day/time and stop day/time and/or a resumption condition).
  • the AMD may wait for second gesture on the user interface 2510.
  • the therapy delivery will be suspended 2512. If the second gesture is received and verified by the therapy suspension control procedure 2436, the therapy delivery will be suspended 2512. If the second gesture is not received or not verified by the therapy suspension control procedure 2436, the therapy suspension control procedure 2436, may determine if a set time has passed since receiving the therapy suspension request 2514. If it is determined that a set time has passed since receiving the therapy suspension request, the request may be canceled and the touch screen may be locked 2516. If it is determined that time from receiving the therapy suspension is less than a set time the AMD may wait for the second gesture to be received.
  • the AMD may automatically activate a therapy suspension user interface 2506, without the first gesture 2504.
  • a gesture e.g., a first gesture
  • a second gesture may stop a suspension before any of the conditions of the stop parameter are met. This allows the user the versatility of being able to modify a suspension that has been activated.
  • FIG. 26 is an illustration 2600 of a plurality of screens that the ambulatory medical device may display when a user activates a therapy suspension user interface.
  • Screen 2602 shows a user interface that an ambulatory medical device may display to a user 2427.
  • the display may be a touchscreen display 2424 that can accept input that includes the first and second gestures.
  • the therapy suspension system shown in FIG. 24 is not limited to the displays shown in FIG. 26.
  • Various displays may communicate to the user 2427 the same information shown in FIG. 26.
  • the screen 2602 allows the user 2427 to select various functions.
  • the pause button 2603, shown on screen 2602 is a function that suspends the delivery of a medicament to the user 2427.
  • the pause screen 2604 allows the user 2427 to select a duration of the medicament suspension.
  • the ambulatory medical device 600 may display various interfaces to allow the user 2427 to select a duration of the medicament suspension.
  • the pause screen 2604 shows a simple interface, giving the user 2427 one of two duration options.
  • the pause screen 2606 shows the user 2427 the duration 2607 that the user 2427 selected (e.g., in the figure the user 2427 selected 1 hour and thus, the medicament delivery is suspended for 1 hour after the suspension begins).
  • the pause screen 2606 has a prompt 2608 for the user to make a gesture to confirm the requested suspension before the medicament suspension begins.
  • the prompt 2608 the user 2427 is being prompted to swipe right across the bottom of the screen.
  • the suspension screen 2610 is displayed on the touchscreen.
  • the suspension screen 2610 informs the user 2427 that the medicament is paused.
  • the user 2427 has the option of performing another gesture to unlock the ambulatory medical device.
  • the prompt 2612 for the user 2427 to unlock the device forces the user to perform another swipe to execute more functions on the ambulatory medical device 600.
  • Suspending the medicament delivery may occur by not generating a dose control signal to deliver a dose of medicament.
  • suspending the medicament delivery may occur by sending a signal to the medicament pump to cease providing therapy or medicament to the subject.
  • the ambulatory medicament device may not immediately suspend therapy upon receiving a command to suspend therapy. For example, if the ambulatory medicament device is in the process of delivering medicament or determines that a condition of the subject indicates that medicament may soon be required to maintain the subject’s condition (e.g., glucose level) within a particular state (e.g., within a desired glucose level range), the suspension of therapy may be delayed until at least such time that medicament is not being delivered, is predicted to not be required during the suspension period, or the next therapy has been delivered. In some such cases, the ambulatory medicament device may inform that user that the suspension of therapy is being delayed. Further, the ambulatory medicament device may indicate the reason for the delay.
  • condition e.g., glucose level
  • the user may be able to override the delay and request immediate suspension of therapy. For example, if the user is replacing the medicament cartridge, the user may override an indication that the suspension of therapy should be delayed. In some cases, the requested start time may be overridden by a determined condition of the subject.
  • the suspension of therapy or the suspension of the delivery of medicament may continue until a resumption condition occurs. In certain cases, when a resumption condition is met, the suspension period may automatically end without action by the user or subject.
  • the resumption condition may include the expiration of a time period, a command from a user (e.g., the subject), detection that the ambulatory medicament devise satisfies a condition (e.g., that medicament has been refilled), that the condition of the subject meets certain criteria (e.g., the subject’s glucose level drops below a threshold range or rises above a threshold range), or any other condition that may satisfy the reason for suspension of therapy or that overrides the request for suspension of therapy.
  • the drug delivery device may be configured to automatically resume drug delivery when a glucose threshold is reached or exceeded. This threshold could be set to 300mg/dl for example.
  • the resumption condition may include detection of an impending risk of hypoglycemia or hyperglycemia, or a hypoglycemia or hyperglycemia event. Further, the resumption condition may include a meal announcement, or an “exercise concluded announcement,” a motion sensing event, a pause of other administered medicament, a conclusion of an undefined suspension length (e.g., during cartridge change), a speed-based resumption event, a location-based resumption, a remote resumption in case of an emergency (e.g., commanded from caregiver admin software or clinician), or any other type of resumption event. In some cases, the resumption condition can include a combination of criteria.
  • automatically resuming therapy may include discontinuing the suspension of therapy before the expiration of the suspension period. For example, if a condition that caused therapy to be suspended is resolved prior to the expiration of the suspension period, therapy may be resumed.
  • the ambulatory medicament device may confirm that one or more additional conditions of the ambulatory medicament device are satisfied before therapy is resumed. For example, if the ambulatory medicament device determines that medicament has not been refilled or if there is a problem with the refill (e.g., cartridge is incorrectly installed), the ambulatory medicament device may continue to maintain the suspension of therapy despite the trigger to resume therapy.
  • a therapy suspension may be ended if a third interaction with a user interface (e.g., a gesture) is detected.
  • the third user interface interaction may be detected by the user interface module 2408 and sent to the therapy suspension control procedure 2436. If the therapy suspension control procedure 2436 verifies that third interaction with the user interface is a predetermined third user interface interaction, it may send a signal to the device and subject monitoring procedure 2432 to activate the medicament dose control procedure 2430. This allows the user the versatility of being able to end a suspension that has been activated, during the suspension period set by the user before the confirmation (second interface with the user interface).
  • a user may decide to end a therapy suspension to modify one or more suspension conditions set prior to activation of the current therapy suspension. In some other examples, user may decide to end a therapy suspension due to change in user’s health condition not included in one or more therapy resumption conditions provided before activating the current therapy suspension.
  • FIG. 27 is a flow diagram illustrating an example method of resuming a suspended therapy that may be implemented by an AMD.
  • the AMD suspends one or more therapies selected for suspension at suspension initiation time received as part of the suspension information.
  • therapy suspension control procedure 2436 deactivates the medicament dose control procedure 2430 using the device and subject monitoring procedure 2432.
  • the therapy suspension control procedure 2436 continuously monitors the system clock and the subject and device condition (e.g., using medicament dose control procedure 2430).
  • the therapy suspension control procedure 2436 determines that the time passed since the suspension initiation is less than the requested suspension time period 2706 and none of condition for resumption has been met 2708, the therapy suspension continues.
  • the therapy suspension control procedure 2436 may check other AMD or subject conditions (not included in the therapy suspension information), in order to determine whether the therapy delivery can be safely resumed 2710. If it is determined that the therapy delivery cannot be safely resumed, an alert message will be send to the user interface to inform the about the reason for such determination. If it is determined that the therapy delivery can be safely resumed, the one or more suspended therapies will be resumed.
  • FIG. 28 is an illustration 2800 of a plurality of screens that may be displayed, for example, on a touchscreen display when a user 2427 resumes a suspended therapy.
  • Screen 2802 informs the user that the delivery of medicament is currently in a suspended mode.
  • the screen 2803 also shows the user 2427 the current glucose concentration of the blood of the user 2427.
  • the ambulatory medical device 600 may display various vital measurements that are useful to the user 2427.
  • the medicament suspension ends if the glucose concentration of the blood of the user meets or passes a threshold.
  • the interface screen 2804 allows the user 2427 to select and execute various functions on the ambulatory medical device 600.
  • the resume button 2805 is a function that ends a medicament suspension.
  • the ambulatory medical device 600 displays a resume screen 2806.
  • the resume screen 2806 has a prompt 2807 that prompts the user 2427 to perform a gesture.
  • the user 2427 is being prompted in the resume screen (e.g., by the prompt 2807) to swipe right across the bottom of the resume screen 2806.
  • the requirement to perform the gesture to resume medicament delivery prevents the user 2427 from inadvertently resuming medicament delivery in the ambulatory medical device 600.
  • the medicament suspension ends.
  • the resumption screen 2808 shows the user 2427 that the regular medicament delivery has resumed.
  • the ambulatory medical device 600 may display a lock screen 2810.
  • the lock screen 2810 prevents the user 2427 from inadvertently executing more functions on the ambulatory medical device 600.
  • the ambulatory medical device 600 may end the suspension before the one or more conditions to end the suspension are met in response to a second gesture performed on a user interface (e.g., the interface screen 2804).
  • the second gesture may be used to ensure that the user 2427 does not inadvertently end the suspension of medicament delivery.
  • the second gesture may be relatively simple (e.g., a single swipe) or complex (e.g., a multi-swipe gesture, a touch gesture of a circle, or a swipe to the left and then up on a touchscreen beginning from a lower right comer).
  • the ambulatory medicament device may determine whether a dose of medicament should be supplied to the user based on a control algorithm used by the ambulatory medicament device to control the provisioning of medicament to the subject. For example, the therapy suspension control procedure 2436 may determine a resumption condition has been satisfied or receive a user input from the user interface module 2408 (a third interaction with a user interface) indicating that therapy suspension should be ended. Subsequently the therapy suspension control procedure 2436 may send a signal to the device and subject monitoring procedure 2432 to activate the medicament dose procedure 2430. If medicament is to be supplied, the Medicament does control may generate and send a dose control signal to the medicament delivery interface 2406.
  • the ambulatory medicament device may alert the user and/or the subject that therapy is being resumed. This alert may occur before generating a dose control signal and/or after a resumption condition is satisfied (e.g., a suspension time expires).
  • a resumption condition e.g., a suspension time expires.
  • the user may request that the suspension of therapy end early. The user may request the early resumption of therapy be interacting with the aforementioned user interface using one or more of the previously described interaction methods (e.g., gestures or taps).
  • An ambulatory medicament device such as, but not limited to, an insulin pump, that provides life-saving treatment to subjects or subjects based on the condition of the subject, may include a user interface (e.g., a touchscreen display) that lets a user to modify the settings of the ambulatory medicament device.
  • the setting may include, but not limited to, a condition that triggers the delivery of medicament to a subject, the quantity of medicament delivered when a condition is met, type of the medicament and the like.
  • the setting may also include features of the AMD that may not be directly related to the medicament delivery (e.g., the screen brightness, an alarm sound, and the like).
  • certain authorized users e.g., a healthcare provider
  • some other settings other authorized users e.g., the subject, a guardian or parent of the subject.
  • a healthcare provider can modify the settings of the ambulatory medicament device.
  • a non-healthcare provider modify at least some settings of the ambulatory medicament device.
  • changing the medicament cartridge may include interacting with a user interface and/or one or more settings of the ambulatory medicament device.
  • Another example of when it is desirable for a non-healthcare user (e.g., a subject, parent, or guardian) to modify settings of the ambulatory medicament device is when the initial settings of the ambulatory medicament device are not providing the desired effect (e.g., sufficient medicament, too much medicament, providing the medicament too slowly or too fast, etc.).
  • the desired effect e.g., sufficient medicament, too much medicament, providing the medicament too slowly or too fast, etc.
  • normal maintenance of the ambulatory medicament device and/or subject may require interaction with the ambulatory medicament device settings and/or controls.
  • negative consequences may begin to occur when an ambulatory medicament device remains connected to a subject at the same site for more than a threshold period of time (e.g., for more than 2-3 days, more than 5 days, more than a week, etc.).
  • the ambulatory medicament device may need to be periodically moved from one site on the subject to another site on the subject (e.g., from left-side to right-side, from arm to leg, from stomach to back, etc.).
  • the change in site location may require interaction with settings of the ambulatory medicament device (e.g., pausing operation until the site change is completed).
  • the user may be a subject receiving medicament or therapy, or may be another user, such as a clinician or healthcare provider, or a parent or guardian of the subject.
  • the passcode required for changing one or more setting via an intermediary device may be different than the passcode required for changing the same settings directly using the AMD’s user interface.
  • One solution to regulating access to settings of the ambulatory medicament device is to implement a lock feature to require that a user provide a passcode, a passcode, or other information before the user is permitted to modify a setting of the AMD, such as a control parameter.
  • a passcode can be substituted for a passcode or any other type of secret or semi-secret information.
  • the AMD when the AMD is in the locked state, it may continue delivering therapy to the subject at the same rate as unlocked state.
  • the lock feature may be activated by default, or may be activated by a user.
  • the lock feature can be enabled through a setting in a control menu of the AMD device provided on a user interface (i.e., touchscreen display).
  • the setting may include an on/off toggle (e.g., a software interface element or a hardware interface element) so when the toggle is on, a passcode (e.g., 4 to 8 numeric digits) may be required.
  • the passcode e.g., a 4 to 8 numeric digit code
  • the user may program the ambulatory medicament device with a user passcode selected by the user.
  • the user passcode may be set in response to a passcode change request.
  • a user passcode may expire.
  • a user may be required to generate a new passcode after the previous passcode expires or before the previous passcode is permitted to expire.
  • the ambulatory medicament device may periodically generate a new passcode (e.g., an override passcode), or may generate the passcode at a time when a user supplies the passcode.
  • the user interface element used for accessing a user interface that enable changing one or more settings of the AMD may differ from a user interface for modifying the control parameters associated with that setting.
  • a keypad may be used to enter a passcode for unlocking a user interface for changing a control parameter and a touchscreen may be used to modify the control parameter.
  • the user interface screen may look and function the same as if the lock feature were not enabled. If the lock feature is enabled, when a visual guide for unlocking the device (such as, for example, a linear unlock slider, an arcuate unlock slider, or another unlock user interface element) is activated, a passcode entry interface (e.g., a keypad user interface element) may be displayed. If either the user passcode or the global override passcode is entered, the user interface may proceed as normal. Otherwise, the user interface may revert back to the original lock screen.
  • a visual guide for unlocking the device such as, for example, a linear unlock slider, an arcuate unlock slider, or another unlock user interface element
  • a passcode entry interface e.g., a keypad user interface element
  • the user action that permits a user to change one or more settings of the AMD may be different from the wake action that activates a user interface.
  • a wake action may be used to activate a touchscreen display that may display a plurality of user selectable elements some of which may be accessible without a passcode.
  • a subset of the user selectable elements for example those allowing the user to change therapy control parameters, may require a passcode.
  • access to each user parameter control element, or at least some of the user parameter control elements may require a different passcode.
  • providing a passcode to an AMD in a locked state may directly enable access to a subset of control parameter elements.
  • the passcode may be set by the user enabling the user to select a passcode the user is more likely to remember.
  • the passcode may be set by the user enabling the user to select a passcode the user is more likely to remember.
  • the passcode may not remember the passcode. Due to the nature of the device (e.g., a device that may provide life-saving treatment), it is desirable that certain users not be restricted from accessing particular settings of the ambulatory medicament device, and be able to quickly (e.g., within seconds, minutes, prior to a next therapy event, or before harm may occur to the subject) obtain access to the particular settings when required.
  • embodiments disclosed herein include an ambulatory medicament device that can include an override passcode that enables access to the ambulatory medicament device (or control settings thereof) regardless of whether the user passcode is provided.
  • the passcode or the override passcode can be a series of taps, series of inputs, a complex or a simple gesture (e.g., a swipe or other movement across the touchscreen).
  • the series of inputs may be any combination of touch movements, touch points, numerical characters, alphabetical characters, or other symbols.
  • the time that the series of inputs are entered may also be a part of the range of parameters. For example, a series of inputs may need to be entered in no less than 3 seconds or more than 3 seconds, and no more than 15 seconds or less than 15 seconds.
  • One example of the complex gesture is a swipe that forms a letter or shape.
  • a simple gesture may be a unidirectional swipe.
  • the passcode or the override passcode can be a complex or a simple gesture (e.g., a swipe or other movement across the touchscreen), performing a pattern or sequence on the touchscreen (e.g., drawing an image), a multi-touch interaction, a combination of the foregoing, or any other type of interaction with a touchscreen, or portion thereof.
  • a complex gesture is entering a predetermined sequence of touches.
  • the passcode may include a quiz or set of questions.
  • using a quiz to override the passcode can be used to ensure a minimum level of competency before overriding the passcode.
  • the ambulatory medicament device may be configured to receive therapy settings or modifications to therapy settings from an intermediary device via a communication connection. In some cases, this feature may be supported in addition to providing the user with option of modifying one or more settings with a user interface of the AMD.
  • the communication connection between the intermediary device and the AMD may be a direct connection via, for example, Bluetooth®, or a connection via a network, such as over a local area network or a wide area network.
  • the ambulatory medicament device may include a wireless transceiver, such as an NB-LTE transceiver, a Wi-Fi transceiver, or a Bluetooth transceiver.
  • the intermediary device that provides the user with a user interface to modify settings of the AMD, include any type of device (e.g., a computing device) that can communicate with an ambulatory medicament device.
  • the intermediary device may be a laptop or desktop computer, a smartwatch, a smartphone, or a hardware control device that may be configured to interact with the ambulatory medicament device.
  • Embodiments disclosed herein may be applicable regardless of whether the user interface for modifying therapy settings or the configuration of the ambulatory medicament device is generated or presented by the ambulatory medicament device to the user or via another device.
  • a user may provide a user-generated passcode or an override passcode via an interface of the computing device.
  • the computing device may then provide the user-generated passcode or the override passcode to the ambulatory medicament device via the network connection between the devices.
  • certain intermediary devices may have access to user interfaces that may be used to change one or more settings (e.g., therapy settings) of the AMD.
  • the smart phone of a guardian or a parent of the subject may be used to change one or more settings of the AMD while the AMD is in the locked state.
  • the AMD may be configured to receive a passcode from or via a computing system (e.g., a cloud computing system).
  • the AMD may receive passcode through a direct end-to-end connection (e.g., a wireless connection over a wide area network) stablished with the computing system.
  • another computing device e.g., a smartphone, a laptop, a personal computer, and the like
  • the user can obtain access to the user interface that permits modification of the control parameter by supplying an override passcode.
  • the override passcode may be a universal fixed passcode (e.g., an 8-digit override passcode) that can be used instead of the user set passcode.
  • the override passcode can be stored in the ambulatory medicament device at the time of manufacture and may be shared among multiple ambulatory medicament devices (e.g., a global override passcode), or may be unique to a particular ambulatory medicament device.
  • the override passcode may be managed by the manufacturer or by a third-party service. To obtain the override passcode, the user may contact the manufacturer or passcode managing service.
  • enabling the passcode may exist to prevent a user with a diminished mental capacity (e.g., a child) from modifying settings of the ambulatory medicament device.
  • security may be less of a concern and any user can contact the manufacturer or passcode managing service to obtain the override passcode.
  • a single global override may be used for all devices produced by the manufacturer.
  • a level of security may be desired.
  • the user may be required to provide a serial number of the ambulatory medicament device.
  • each model or each unit of the ambulatory medicament device may have a different override passcode. The user may provide authorization information and a serial number of the ambulatory medicament device to the manufacturer or passcode managing service to obtain the override passcode.
  • the ambulatory medicament device may periodically generate a new override passcode or may generate an override passcode at a time when a user supplies the passcode.
  • the ambulatory medicament device may use the same parametric values to generate the override passcode as another device may use thereby ensuring a match between the override passcodes.
  • the override passcode can be obtained regardless of whether a user is able to contact a manufacturer or other passcode managing service.
  • the user may generate the override passcode without access to a network or phone using, for example, a computing device that can access a common parameter value as the ambulatory medicament device.
  • the override passcode may change over time or be a rotating passcode.
  • the override passcode may change every thirty seconds, every minute, every hour, etc.
  • the override passcode may be determined from an algorithm executed by an application.
  • the ambulatory medicament device may store a copy of the algorithm in a memory of the ambulatory medicament device and may execute the algorithm to determine the override passcode that is currently valid.
  • a copy of the algorithm may be executed by another computing device accessible by the user.
  • the output of the algorithm may be based on a value that is commonly accessible by the ambulatory medicament device and the copy of the algorithm accessible by the computing device.
  • the output of the algorithm may be generated based on a time, a user identifier, a provided value, or any other factor that may be used to repeatedly generate the same output.
  • the override passcode may be calculated based on a combination of factors.
  • the override passcode may be calculated based on a portion of a serial number or model number for the ambulatory medicament device and the time.
  • the determination of the override passcode may be calculated by the ambulatory medicament device, a computer server, and/or an application on a user device.
  • the override code can be automatically received by the ambulatory medicament device. Thus, a user may not need to see or enter the override code.
  • the override code may be transmitted to another device of the user (e.g., a smartphone or laptop). For example, the override code can be texted to a user’s smartphone. In some cases, the override code may be received in a coded manner that may not be understandable by a child or user with diminished mental capacity.
  • the override passcode may be linked to a location.
  • the override passcode may only be enterable at a healthcare provider’s office, at the subject’s place of residence, or at some defined set of locations.
  • the determination of the location of the ambulatory medicament device may be based on a geolocation system (e.g., a Global positioning System (GPS)) available to the ambulatory medicament device.
  • GPS Global positioning System
  • the passcode may provide a second level of security in addition to other interactions with the user interface (e.g., a first and a second gesture on a touchscreen display) that may be used to change the therapy settings and/or accept the change made to a therapy setting.
  • the passcode may be used instead of other interactions with the user interface (described above).
  • interacting with the user interface may cause the ambulatory medicament device, or other device that can modify a control of the ambulatory medicament device, to present a passcode input screen to the user.
  • the user may enter the passcode to unlock additional user interface features including, for example, a user interface that enables the user to modify at least one control parameter of the ambulatory medicament device.
  • the control parameter can be modified based on an interaction with a parameter control element of the user interface. Further, modification of the control parameter may cause modification of the generation of a dose control signal that is generated by a control algorithm based at least in part on the control parameter.
  • the ambulatory medicament device may have an advanced therapy screen, or other user interface, that permits a healthcare provider, or other user, to obtain additional details relating to therapy provided by the ambulatory medicament device.
  • the advanced therapy screen may generally be intended for a knowledgeable user, such as a clinician, in some cases, any user may obtain access to the advanced therapy screen.
  • the advanced therapy screen may permit the healthcare provider to modify control parameters that may not be modifiable by other users.
  • the healthcare provider may be able to control parameters that relate to the calculation of a rate of insulin accumulation, the rate the insulin diminishes within the blood of the subject, the setting of a glucose setpoint, an aggression level or factor of therapy relating to an amount of insulin provided when the subject’s glucose level is outside the setpoint range, or when the insulin reaches a point of maximum concentration within the blood of the subject (e.g., T m ax).
  • Access to the advanced therapy screen may be limited or restricted by requirement of a passcode, which may be referred to as a clinician passcode to distinguish it from the user-generated passcode and/or the override passcode.
  • This clinician passcode may or may not be user-generated.
  • the clinician passcode may be a separate passcode from the user-generated passcode that permits access to the non-advanced therapy screen interface.
  • the clinician passcode may be separate from the override passcode that permits a user to override the user-generated passcode to obtain access to the non-advanced therapy screen interface.
  • the clinician passcode may be used as an override passcode.
  • the clinician passcode can be valid for period of time (e.g., set by a subject or another authorized user such as the guardian or apparent of the subject). For example, the clinician passcode may be valid for a day, a week or a month. In some examples, the AMD may allow certain authorized users to terminate the clinician access at any time.
  • access to the advanced therapy screen may be limited to a particular period of time. After the time period expires, the ambulatory medicament device may automatically restrict access to the advanced therapy screen. In some cases, the window of access may be extended. For example, if the healthcare provider is continuing to interact with the advanced therapy screen, the screen may remain accessible.
  • the advanced therapy screen may provide additional features. For example, while a user may be able to indicate that an amount of insulin provided for a meal or as a correction factor should be higher or lower, the healthcare provider may be able to specifically adjust the amount of insulin. Moreover, while a user’s direction may or may not be followed depending, for example, if the request exceeds a threshold or may cause glucose to not satisfy a setpoint range, an indication provided via the advanced therapy screen may be followed regardless, or may have a wider range or different threshold that may control whether the instruction is followed. Further, the advanced therapy screen may be used to temporarily pause therapy and/or may prevent subject access.
  • the manufacturer of the ambulatory medicament device may provide a remote unlock signal that can be used to unlock access to the ambulatory medicament device and/or to an advanced therapy screen of the ambulatory medicament device.
  • the passcode may be desired to prevent particular users from inadvertently changing certain control parameters of the ambulatory medicament device.
  • features of the ambulatory medicament device that do not affect therapy may remain accessible to a user when the ambulatory medicament device is in a locked state.
  • a user may be able to access therapy history, screen brightness settings or colors, or any other feature that is unlikely to harm a subject if modified in a particular manner.
  • the passcode feature is generally to prevent control parameter changes, the ambulatory medicament device may provide therapy and continue to provide therapy at the same rate and under the same condition, whether or not the ambulatory medicament device is locked or unlocked.
  • the ambulatory medicament device validates the passcode.
  • the passcode may be validated by comparing the received passcode to a passcode stored in a memory of the ambulatory medicament device or generated by the ambulatory medicament device. If the passcode received from the user is successfully validated, the user may be granted access to a user interface to modify one or more control parameters. In some cases, the user may be requested to re-enter a passcode to confirm a change to a control parameter. In some other examples, the user may be requested to provide a gesture on a touchscreen to confirm a change to a control parameter.
  • the ambulatory medicament device may prevent access to the user interface to modify the one or more control parameters.
  • the user interface that presents the user with the ability to enter the passcode may permit the user a particular number of tries or a particular number of tries within a particular time period to enter the user passcode. If the correct user passcode is not entered within the provided number of tries or within the particular time period, the user interface may enter a lock state (e.g., the screen will be turned off) and prevent further attempts to enter a passcode for at least a period of time. In some cases, the user passcode option may be indefinitely locked or blocked.
  • control parameters of the ambulatory medical device may only be accessible if the override passcode is provided.
  • a user passcode of a different user may be used to provide access to the control parameters of the ambulatory medical device.
  • the user interface may block any attempt to change the override passcode for at least a period of time.
  • a user may deactivate the passcode feature of the ambulatory medicament device. Deactivating the passcode feature may require use of a separate passcode or the override passcode in addition to the user passcode.
  • the passcode may be optional or omitted based on the computing device connected to the ambulatory medicament device. For example, if the end- to-end connection is established between a smartphone registered to a particular user (e.g., a parent of the subject), the ambulatory medicament device may unlock automatically without requiring a passcode.
  • the smartphone, or other computing device may automatically provide the user-generated passcode or the override passcode to the ambulatory medicament device upon establishing a connection.
  • the ambulatory medicament device may automatically be unlocked when connected to a charger or when in a particular geographic area.
  • a geo-fence may be configured in one or more locations, such as the subject’s house or the clinician’s office.
  • the ambulatory medicament device may automatically be unlocked.
  • the ambulatory medicament device determines that it is not within the geo-fenced region, it may automatically be locked.
  • the determination of the location of the ambulatory medicament device may be made based on a geo-location system, such as the Global Positioning System (GPS).
  • GPS Global Positioning System
  • the user interface screen may be turned off or may accept only the global override passcode
  • FIG. 29 is a block diagram illustrating the interconnection among modules and procedures in AMD involved in changing the settings of the AMD.
  • one or more settings of the AMD may be changed using one more parameter control elements 2941/2943/2945 presented on one or more setting control screens 2940/2942/2944 provided by the user interface module 2908.
  • access to one or more setting control screens 2940/2942/2944 and/or one or more parameter control elements 2941/2943/2945 may be protected by a passcode.
  • the user may provide a passcode 2933 (e.g., a user generated passcode or an override passcode), via the user interface module 2908 (e.g., using a touchscreen display 2924 or alphanumeric pad 2926).
  • the user 2927 may provide a passcode 2946 using an intermediary device (e.g., a laptop, a smart phone and the like) that is connected to the AMD (e.g., via a wireless link).
  • the access to one or more setting control screens 2940/2942/2944 and/or parameter control elements 2941/2943/2945 may be managed by setting change procedures 2928 stored in a memory in the CCM of the AMD.
  • a hard processor may execute the machine -readable instructions associated with the setting change procedures 2928.
  • the option to provide a passcode may become available when the user 2927 performs a wake action on a wake interface 2922.
  • the wake control module 2934 of the CCM determines that a valid wake action is performed, it may present selectable elements associated with the setting control screens 2940/2942/2944, for example, on a touchscreen display.
  • the first screen presented on the touchscreen display may provide other selectable elements including an element to change the settings of the AMD.
  • selecting element associated with settings change may activate a second screen that presents selectable elements associated with the setting control screens 2940/2942/2944.
  • any of the setting control screens 2940/2942/2944 and/or parameter control elements 2941/2943/2945 may require a passcode.
  • each one of the control screens 2940/2942/2944 and/or parameter control elements 2941/2943/2945 may require a different passcode.
  • one or more control screens 2940/2942/2944 and/or parameter control elements 2941/2943/2945 may not require a passcode. For example, access to the first screen 2940 may require a first passcode, the access to the second screen 2942 may require a second passcode and the access to the third screen 2944 may not need a passcode.
  • all the control screens 2940/2942/2944 may be presented without the need for providing a passcode, but access (read, write, or read and write access) to one or more control elements of a control screen may require a passcode.
  • access read, write, or read and write access
  • the user may select the second screen 2942 without entering a passcode but in order to select one or more parameter control elements 2943 on that screen, the user may need to enter one or more passcodes.
  • FIG. 30 is a flow diagram illustrating an example method that may be used by an AMD to allow a user to change a setting of the AMD using a user generated passcode or an override passcode.
  • the AMD e.g., the wake action procedure in the CCM
  • a user interface may be activated.
  • the wake action may directly activate a setting change interface 3004 (e.g., a setting change screen presented on a touchscreen display).
  • a specific wake action may activate the setting change interface.
  • the AMD e.g., the setting change procedure in the CCM
  • the AMD may request a passcode (e.g., by presenting a window to enter a passcode).
  • the AMD e.g., the setting change procedure in the CCM
  • the AMD may determine whether the passcode matches a user generated passcode 3008. If it is determined the passcode matches with a user generated passcode, the AMD may provide access 3010 to one or more control parameter elements associated with the received passcode.
  • the AMD may determine whether the passcode matches with an override passcode. If it is determined the passcode matches an override passcode stored in a memory of AMD or a memory of an authorized computing device, the AMD may provide access 3014 to one or more control parameter elements associated with the received override passcode. If it is determined the passcode does not match an override passcode, the AMD denies access to one or more passcode protected control elements.
  • FIG. 31 is a flow diagram illustrating another example method that may be used by an AMD to allow a user to change a setting of the AMD using a user generated passcode or an override passcode.
  • the AMD e.g., the wake action procedure in the CCM
  • the AMD may provide a user interface (e.g., a touchscreen display) on which the user can provide a first gesture to activate a setting change interface or screen.
  • the AMD may activate a setting change interface or a screen.
  • the setting change interface or a screen may include one or more parameter control elements associated with one or more settings of the AMD.
  • the setting change interface or a screen may include one or more selectable elements, with at least some of the one or more selectable elements associated with its own setting change screen (e.g., a screen provided on a touchscreen display) or a common setting change screen that may include one or more control parameters.
  • the AMD may determine whether the requested setting change is passcode protected or not.
  • the request for setting change may include selecting a parameter control element.
  • the request for setting change may include selecting a list of parameter control elements (e.g., included in a separate screen provided on a touchscreen display).
  • the AMD may permit access to one or more parameter control elements associated with the requested setting change 3112.
  • the user may need to provide a second gesture on the user interface (e.g., touchscreen display) to confirm the changes made.
  • the AMD may change one or more settings according to the requested and confirmed changes.
  • the AMD may request a passcode 3120 via a passcode display (e.g., provided on a touchscreen display). In some examples, the request for the passcode may be presented on a display but the passcode may be received via a physical keypad.
  • the AMD may validate the passcode 3124 by comparing it with one or more user generated passcodes or an override passcode. If it is determined that the passcode matches with a user generated passcode or an override passcode, the AMD may activate 3126 one or more parameter control elements associated with the requested setting change. Subsequently, the AMD may receive a setting change via the selected control parameter element 3128.
  • the user may need to provide a second gesture on the user interface (e.g., touchscreen display) to confirm the changes made. In response to receiving the second gesture 3130, the AMD may change one or more settings according to the requested and confirmed changes 3132.
  • a condition may occur that impacts the operation of the ambulatory medicament device.
  • This condition may be associated with the ability of the ambulatory medicament device to operate as intended by the manufacturer, a subject receiving therapy from the ambulatory medicament device, and/or user (e.g., healthcare provider, parent, or guardian of the subject).
  • the ambulatory medicament device may be operating as intended, but the condition of the subject may not satisfy a desired level of health.
  • the user may be a subject receiving medicament or therapy, or may be another user, such as a clinician or healthcare provider, or a parent or guardian.
  • This section of the disclosure relates to an ambulatory medicament device, such as an insulin pump or a combined insulin and counter-regulatory agent (e.g., Glucagon) pump, configured to generate a dose control signal configured to cause a medicament pump to infuse medicament into a subject.
  • an ambulatory medicament device configured to detect a condition of the ambulatory medicament device and/or the subject, and to generate an alarm when it is determined that the detected condition satisfies an alarm condition.
  • an ambulatory medicament device may include an alarm system configured to monitor the ambulatory medicament device and/or the subject, and to generate an alarm when it is determined that a condition has been detected that satisfies an alarm condition.
  • the alarm system may organize a list of alarms, notifying a user of these alarms, and allowing the user to acknowledge alarms.
  • the alarm system may comprise a plurality of sensors that monitor the AMD or the subject, a monitoring system interface that receives the data from sensors, and alarm generation module that process the received data and generate alarms if an alarm condition is met.
  • the monitoring system interface and the alarm generation module are implemented using one or more hardware processors and machine readable.
  • the monitoring system interface and the alarm generation module are separate hardware modules.
  • an alarm control system 3222 implements alarm control procedures in the control and computing module 610 (CCM) of the AMD.
  • the alarm control system 3222 can be implemented as instructions stored in a memory of the CCM (e.g., the main memory 616) and executed by a hardware processor 214 to generate an alarm upon detection of a condition of the ambulatory medicament device and/or the subject.
  • the hardware processor of the monitoring system is a hardware processor of the ambulatory medicament device that controls medicament delivery. In some cases, the hardware processor of the monitoring system may be a separate hardware processor.
  • the alarm control system 3222 includes a monitoring system 3226 and an alarm annunciation system 3228.
  • the monitoring system 3226 monitors the condition or status of the AMD and/or the subject at least partially based on signals or status values received form a set of device sensors 3224 and a set of subject sensors 3220.
  • the device sensors may be configured to track the status of the components or the elements of the ambulatory medicament device, and the subject sensors can be configured to obtain measurements of one or more physiological characteristics of the subject
  • a device sensor 3224 is a sensor that generates a signal or status value associated with the condition of modules, interfaces, accessories, disposables of the AMD.
  • a device sensor 3224 may generate a signal that corresponds to a parameter associated with a component in a module or interface. For example, one device sensor may record the voltage of a battery and another device sensor may record the follow rate of a pump the medicament delivery interface 3206.
  • a subject sensor 3220 may be any sensor that generates a signal or status value associated with one or more physiological indicators (or parameters) of a subject (e.g., heart rate, blood pressure, body temperature, level of blood glucose, serum levels of various hormones or other analytes).
  • the device and subject monitoring system 3226 can include continuously receiving and analyzing signals received from device sensors 3224 and subject sensors 3220 to determine the condition of the ambulatory medicament device, the subject, a sensor, and/or other accessories.
  • a single sensor may be used to monitor both the condition of the subject and the ambulatory medicament device or accessories and sensors connected to the AMD.
  • a continuous glucose monitoring CGM sensor may be used to monitor the condition of the subject, and may be monitored to determine whether the condition of the CGM satisfies an alarm condition (e.g., to alarm a user that the CGM should be replaced).
  • an alarm condition e.g., to alarm a user that the CGM should be replaced.
  • one or more of the sensors may be accessories that may or may not be part of the ambulatory medicament device, but that may communicate with the ambulatory medicament device.
  • alarm control system 3222 implements procedures for allowing a user or the subject to change the alarm settings and/or acknowledging an alarm annunciation via the user interface module 3208.
  • the user may be able to see one or more alarms annunciated on a user interface (e.g., as a list of alarms), even if the AMD is in locked state. In these examples, the user may not be able to acknowledge or respond to alarm when the AMD is in locked state.
  • a user or the subject may get access to an alarm setting screen or acknowledge an alarm annunciation by providing a wake signal and a first gesture (e.g., on a touchscreen display).
  • the first gesture may be created by entering predetermined characters on the alphanumeric pad.
  • the alarm control system 3222 distinguishes inadvertent alarm control inputs from intentional alarm control inputs.
  • An inadvertent alarm control input is an alarm acknowledgment input that was made without the intent of the user to acknowledge the alarm that the ambulatory medical device 600 is delivering to the user.
  • the alarm control system 3222 implements processes for determination and categorization of an alarm condition based on its severity level (e.g., a severity level between 0 and 5), according to the information received through the monitoring system 3226.
  • its severity level e.g., a severity level between 0 and 5
  • the alarm control system 3222 implements procedures for controlling the annunciation of alarm conditions via the user interface module 3208, at least partially, based on their severity level.
  • a user interface e.g., a touchscreen display
  • This capability provides the user with access to address the fault causing the alarm so that it could be corrected thereby stopping the alarm.
  • the device and subject monitoring system 3226 may provide the status information received from the device sensors 3224 and/or subject sensors 3220 to the alarm annunciation system 3228.
  • the status information may comprise one or more status values.
  • the alarm annunciation system 3228 is configured to determine based at least in part on the status information received from the subject monitoring system 3226, whether an alarm condition is satisfied.
  • Determining whether the alarm condition is satisfied may include comparing one or more status values associated with the ambulatory medicament device and/or the subject to one or more alarm thresholds or alarm conditions. In some cases, at least some of the alarm thresholds or alarm conditions may be associated with an alarm profile. In some such cases, determining whether the alarm condition is satisfied may include comparing the status information to one or more alarm thresholds or alarm conditions included in one or more alarm profiles.
  • the alarm profile may be stored in the storage 618 of the CCM 610. In some such examples, at least some of the alarm profiles may be provided to the CCM by an authorized user or the subject via a user interface or directly transferred from another device to the storage (e.g., from USB drive, a laptop, smart phone, PC and the like). In some other examples, at least some of the alarm profiles may be stored in the storage 618 at the time of manufacture,
  • At least some of the alarm profiles may indicate the characteristics or status of the ambulatory medicament device and/or subject that triggers an alarm corresponding to the alarm profile.
  • at least some alarm profiles may indicate the threshold status values below or above which an alarm should be triggered.
  • one alarm profile may indicate that when a glucose level of the subject exceeds a particular threshold, a particular alarm is to be generated and/or annunciated.
  • an alarm profile may indicate that when an available amount of medicament is below a particular threshold, a particular alarm is to be generated and/or annunciated.
  • the type of alarm and/or the alarm frequency or intensity associated with the medicament level may differ from the alarm triggered based on the glucose level.
  • a glucose level that exceeds an upper threshold or is below a lower threshold may be associated with different alarm profiles or the same alarm profile.
  • a glucose level that is above an upper threshold or a medicament pump that is unable to supply insulin may be associated with the same alarm profile.
  • a medicament pump that is unable to supply insulin due to an empty insulin cartridge may be associated with a different alarm profile than if the medicament pump is unable to supply insulin due to damage to the medicament pump.
  • conditions of the ambulatory medicament device or of the subject that may be associated with an alarm profile include conditions relating to a battery capacity (e.g., below a threshold charge capacity or below a capacity associated with a particular amount of operating time (e.g., one day)), a battery condition (e.g., high temperature or low voltage), a medicament or drug delivery condition (e.g., medicament is empty or below a threshold, motor is stalled, catheter is occluded, etc.), subject sensor condition (e.g., glucose sensor is expiring, or signal was not received from sensor), calibration failure, high or low glucose levels, network (e.g., Bluetooth® or BN-LTE) communication errors, haptic interface errors (e.g., motor non-responsive), speaker errors (e.g., noise or low volume), medicament cartridge errors (e.g., empty cartridge, cartridge detection error, etc.), and the like. As explained below, at least some of these errors or conditions may be associated with different severity levels that cause the an a battery capacity (e.g.
  • an alarm profile may be associated with a severity level of the alarm.
  • the severity level may be associated with how urgently the condition that triggered the alarm should be addressed or resolved. Further, the severity level may be associated with an amount of harm that may be caused to a subject if the condition that triggered the alarm is not resolved or is not resolved within a particular time period.
  • the number of severity levels may vary based on the type of ambulatory medicament device. Generally, there is no limit to the number of severity levels. However, there may be a point of diminishing returns as the number of severity levels exceeds a particular number because, for example, it may be difficult for a user to distinguish between the different numbers of severity levels or to identify with which severity level a particular alarm is associated.
  • the number of severity levels may be limited to a particular number, such as 3, 5, 6, 9, or some number in between. However, it is possible for there to be more than 9 severity levels. [0350] There may be multiple alarm profiles associated with the severity level. Or each condition of the ambulatory medicament device and/or subject that is associated with the same severity level may be associated with the same alarm profile.
  • the ambulatory medicament device may determine a severity of an alarm condition based on the condition of the ambulatory medicament device and/or the subject that triggered the alarm condition. In some cases, the ambulatory medicament device may determine the severity of the alarm condition based at least in part on an alarm profile associated with the alarm condition.
  • the ambulatory medicament device may continue to provide therapy. However, if the alarm condition interferes with the delivery of therapy, operation of the ambulatory medicament device may be suspended or partially suspended. Generally, alarm conditions that interfere with the provisioning of therapy may be associated with a higher severity level. However, some alarm conditions that interfere with the provisioning of therapy may be associated with lower severity levels. For example, a determination that the ambulatory medicament device cannot supply insulin may normally be associated with a highest severity alarm. But if a user indicates that the site location is currently in process of being changed, the alarm condition may be associated with a lower severity level (e.g., an informational alarm reminding the user that insulin cannot be delivered during site change).
  • a lower severity level e.g., an informational alarm reminding the user that insulin cannot be delivered during site change.
  • the alarm annunciation system 3228 can implement an annunciation pattern selected based at least in part on the status information generated by and received from the monitoring system 3226, whether an alarm condition is satisfied. Determining whether the alarm condition is satisfied may include comparing one or more status values associated with the ambulatory medicament device and/or the subject to one or more alarm thresholds or alarm conditions associated with an alarm profile.
  • the alarm annunciation system 3228 Upon verifying that an alarm condition associate with an alarm profile is satisfied, the alarm annunciation system 3228 annunciates the alarm condition. [0355] In some examples, the alarm system may generate a list of pending alarm conditions and store it in a memory of the AMD (e.g., storage 618 in CCM 610). In these examples, any time an alarm condition associated with an alarm profile is satisfied, the alarm system may update the list of pending alarm condition by adding the new alarm condition to the list of pending alarm conditions.
  • the list of pending alarm conditions may be sorted according to the severity level associated with the alarm conditions.
  • the alarm system may annunciate the alarm conditions via the user interface module 3208 of the AMD 600.
  • the alarm condition may be annunciated via one or more user interfaces (e.g., a display, a speaker, and the like).
  • an alarm may comprise an audio alarm, a text message, a graphical message, a text or graphical message with audio, vibrations, flashing light and any combination of these.
  • the alarm conditions may be transmitted to other devices, via the communication module 3202 of the AMD where, for example, an authorized user (e.g., guardians or parents of the subject), the subject or an emergency provider can view the alarm condition.
  • the alarm annunciation system 3228 may establish a direct end-to-end connection with a computing system (e.g., a cloud computing system) using the communication module 3202 and send the alarm condition to the computing system through the end-to-end connection.
  • a computing system e.g., a cloud computing system
  • an alarm may be generated and/or annunciated that is associated with the severity of the alarm condition and/or the type of alarm condition.
  • Different alarm conditions and/or alarm profiles may result in different types of alarms or different annunciations of the alarm.
  • an alarm associated with the highest severity level may include an audible alarm with a loudness that exceeds a particular decibel level (e.g., above 70 or 80 decibels), a visible alarm (e.g., a flashing or steady light) with a luminance above a particular luminance value (e.g., a luminance between 10 5 or 10 6 candelas per square meter), and/or a vibrational alarm.
  • the alarm associated with the highest severity level may not be snoozed or dismissed.
  • the alarm associated with the highest severity level may be snoozed for a shorter time period than alarms of lower severity levels (e.g., for 5 minutes, for 10 minutes, etc.).
  • An alarm associated with a different severity level than the highest severity level may include a different combination of audible, visible, and vibrational alarms. Not only may the existence of audible, visible, and vibrational alarms differ for different severity levels, but so may the characteristics of each of the alarm types. For example, audible alarms may have different sound patterns, loudness, frequencies, etc. Visible alarm may be of different intensity, color, pattern, etc.
  • Vibrational alarms may be of different patterns or intensity, and/or may be combined with other types of alarms (e.g., visual or auditory alarms). Further, an alarm with a different severity level than the highest severity level may be permitted to be snoozed or dismissed, or snoozed for a longer period of time. In some examples, the severity of the alarm condition may determine the type of type of the alarm generated (e.g., audio, text, graphical, or any combination of the aforementioned).
  • the display of alarm conditions on the user interface may include an icon for each type of alarm condition.
  • the user interface may display the number of alarm conditions and/or the number of alarm conditions of a particular type or severity level.
  • a duplicate alarm may be omitted from the list of alarms.
  • a count of the occurrence of alarms may be increased to reflect the duplicate alarm.
  • a duplicate alarm may result in the annunciation of the duplicate alarm.
  • the duplicate alarm is ignored.
  • the occurrence of a duplicate alarm may cause an escalation of the existing alarm.
  • an alarm condition that causes an annunciation of an alarm with a first severity level is detected as occurring a second time
  • the alarm may be annunciated with a second severity level that indicates a greater degree of severity that the first severity level.
  • an alarm occurring after an alarm condition is resolved may not be considered a duplicate alarm, but instead may be a reoccurrence of the alarm condition and/or an indicator that the resolution for the alarm condition failed (e.g., an insulin cartridge replacement is faulty or is empty).
  • the list of alarms may be accessed when the ambulatory medicament device is locked. Further, details about the alarms may be accessible when the ambulatory medicament device is locked.
  • Each of the alarm conditions, or information associated therewith, may be added to an indicator or user interface (e.g., a list, or other data structure or user interface element) that may be accessed by a user.
  • This user interface may maintain the alarm condition on the user interface until the alarm condition is resolved.
  • the alarm conditions may be sorted or ranked based on the severity level of the alarm condition, the time that the alarm condition occurred, whether the alarm condition relates to the subject or the ambulatory medicament device, any combination of the foregoing, or any other factor for sorting or ranking the alarm conditions.
  • the displayed information may include details about what caused the alarm, the severity of the alarm, how to respond to or address the alarm, or any other information that may be informative regarding why the alarm was generated and/or how to respond to the alarm.
  • the information may provide a workflow or instructions on how to respond to the alarm.
  • the instructions may include a link to a workflow provided by a manufacturer of the ambulatory medicament device or of another entity, such as an entity that provides medicament or site changing kits.
  • different views of an alarm or different information associated with the alarm may be provided based on an identity of the user, or a role of the user, viewing the alarm. For example, a child may be instructed to contact a parent to address an alarm. But a parent may be provided with information to resolve the alarm. The parent may receive simplified information (e.g., glucose level is high) about what caused the alarm, but a healthcare provider may receive more detailed information regarding the alarm (e.g., internal control parameter values, insulin flow rates, curvature of insulin diminishment predictions, etc.) that facilitates the healthcare provider caring for the subject.
  • simplified information e.g., glucose level is high
  • a healthcare provider may receive more detailed information regarding the alarm (e.g., internal control parameter values, insulin flow rates, curvature of insulin diminishment predictions, etc.) that facilitates the healthcare provider caring for the subject.
  • the alarm conditions may be displayed on a display of the ambulatory medicament device.
  • the alarm conditions may be displayed on a remote display that is separate from the ambulatory medicament device.
  • the remote display may be a display that is authenticated or associated with a computing device that is authenticated to access data, such as alarm conditions, from the ambulatory medicament device.
  • the list of alarms may be presented on a mobile device (e.g., a smartwatch or smartphone) or on a computing device (e.g., a laptop or desktop) that can obtain data directly or indirectly from the ambulatory medicament device.
  • annunciating the alarm may include contacting a manufacturer and/or user (e.g., a healthcare worker, a parent or guardian, or other registered user). Further, the alarm may include instructions on repairing the ambulatory medicament device and/or on addressing the alarm condition. For example, the alarm may provide a user with instructions to replace the insulin cartridge and how to replace the insulin cartridge. As another example, the alarm may provide instructions on how to change the battery of the device or on how to change a site where the insulin pump connects to the subject. In some cases, the alarm may include one or more operations associated with the alarm. For example, the alarm may trigger reordering of insulin or may request that the user confirm a reorder request to reorder insulin.
  • a manufacturer and/or user e.g., a healthcare worker, a parent or guardian, or other registered user.
  • the alarm may include instructions on repairing the ambulatory medicament device and/or on addressing the alarm condition. For example, the alarm may provide a user with instructions to replace the insulin cartridge and
  • a user may be able to acknowledge and/or snooze alarms. Certain alarms, such as informational alarms, may be dismissible. However, generally the alarm may remain on the alarm list until the condition that caused the alarm is resolved.
  • Resolving the alarm may include any action that addresses the condition that caused the alarm to be generated.
  • resolving the alarm may include replacing an insulin cartridge, changing a site where the ambulatory medicament device is connected to the subject, charging a battery of the ambulatory medicament device, providing insulin or a counter-regulatory agent to the subject and/or the ambulatory medicament device, or any other action that may be performed to address an alarm condition.
  • the resolution action may be acknowledging the alarm. For example, if the alarm is informational (e.g., to inform the user that more insulin has been ordered), acknowledging the alarm may be a sufficient resolution action.
  • whether the alarm condition is resolved may depend on an identity of the user. For example, if a child interacts with an alarm related to reordering of insulin, the alarm may remain until a parent or guardian acknowledges the alarm. However, the child may be able to snooze the alarm.
  • a user interface that displays alarms may differ based on who is viewing the alarm. For example, a child may view the alarms, but may not be able to interact with the alarms. However, a parent or guardian may be able to snooze or dismiss an alarm. Further, a child may be instructed to bring the device to a parent or adult to address an alarm.
  • the child may be informed of how urgently to contact the parent (e.g., contact a parent immediately, within a day, within a week, etc.). Moreover, a designated adult may separately be alarmed (e.g., via a text or email alarm). The parent or guardian may receive additional information not provided to the child or subject (e.g., a link to repair instructions or a workflow to address the alarm condition).
  • certain conditions may self-resolve over time. For example, a low battery alarm may resolve as the battery is charged. In such cases, the alarm may be cancelled automatically as the battery charge level exceeds a particular threshold.
  • one or more alarms and/or the alarm list can be viewed and/or accessed on a home screen, a main screen, or other non-alarm based user interface screen in addition to a user- interface screen designated for display alarms.
  • the alarm list may be accessed from the ambulatory medicament device and/or a computing system in communication with the ambulatory medicament device.
  • the alarm condition may or may not be resolvable when the ambulatory medicament device is locked.
  • a user may interact with the alarms generated based on the alarm condition.
  • the user can only interact with the alarms when the ambulatory medicament device is unlocked.
  • the user can interact with the alarms to snooze them or to obtain further information.
  • the user may not be able to dismiss the alarm without unlocking the ambulatory medicament device.
  • Interacting with the alarms may include providing information associated with the alarm to a user in response to the user interacting with the alarm, or an indicator representative of the alarm.
  • FIG. 33 shows a flow diagram illustrating an example procedure that may be used by the alarm system of an AMD to annunciate an alarm condition upon receiving a status information that satisfies an alarm condition.
  • the alarm annunciation system 3228 implements an annunciation process by execution of instructions by a processor in CCM of the AMD, where the instructions can be stored in the main memory, storage of the AMD, or in a memory of a connected electronic device or computing system.
  • the alarm system may receive status information 3302 using the device and subject monitoring system 3226, one or more device sensors and/or one or more subject sensors.
  • the alarm annunciation system 3228 determines whether the received status information satisfies an alarm condition.
  • the alarm condition may be an alarm condition in an alarm profile. If the received status information does not satisfy an alarm condition, no action may be taken 3306. If the received status information satisfies an alarm condition, the alarm system may determine whether the alarm condition is already present in the list of pending alarm conditions or not 3308. If the alarm condition is not present in the list of pending alarm conditions, the alarm system may add the alarm condition to the list of pending alarm conditions 3310. Next the alarm system, may determine the severity of the alarm condition 3312.
  • the alarm annunciation system 3228 can select an annunciation pattern 3314 and annunciate the alarm condition using the selected annunciation pattern. If the alarm condition is present in the list of pending alarm conditions, the alarm system may select an annunciation pattern and annunciate the alarm condition using the selected annunciation pattern.
  • the annunciation pattern selected at block 3318 may be an annunciation pattern that is different than the previously used annunciation patterns for the alarm condition. In some such examples, the annunciation pattern selected at block 3318, may be selected based on number of times that the same alarm condition is satisfied by a received status information.
  • the process of the alarm detection and control function may repeat each processing cycle so long as the ambulatory medical device is in use.
  • the alarm system may wait for user acknowledgment of the alarm. If the user acknowledges the alarm, the system proceeds to perform alarm processing. However, if the user fails to acknowledge the alarm, the annunciation continues and may escalate depending on the level of the alarm.
  • the alarm conditions may be categorized based and annunciated based on their severity level.
  • the alarms are categorized numerically in descending order with the highest priority fault displayed at the top of the list.
  • a level 0 severity may be for a trivial fault that does not require any action by the user thus not warranting an alarm notification.
  • a level 1 severity may be an informational type notification that repeats at a certain frequency (e.g., every 30 minutes) until acknowledged by user which results in it being reset.
  • the annunciation may include a brief vibration and a beep, for example.
  • a level 2 severity may be one relating to an imminent loss of system function. Thus, such an annunciation may include two brief vibrations and two beeps, for example, and repeating at a certain frequency (e.g., every 30 minutes).
  • a level 3 fault may be for when the system is no longer fully functional thus requiring user intervention to correct the issue.
  • the annunciation may begin with a base level intensity with three brief vibrations and three audio beeps, for example, and repeating at a certain frequency (e.g., every 5 minutes).
  • the annunciation escalates at a second frequency, e.g., every 30 minutes, up to a maximum intensity level.
  • the escalation may be a change in vibration intensity and/or audio level, for example.
  • the escalation may be cleared to base level when the user acknowledges the fault; however, the base alarm remains if underlying condition persists.
  • a level 4 severity may be for when the system is no longer functional and not correctable by the user.
  • the annunciation may begin with a base level intensity with three audio beeps, for example, and repeating at a certain frequency (e.g., every 5 minutes).
  • the annunciation escalates at a second frequency, e.g., every 30 minutes, up to a maximum intensity level.
  • the escalation may be a change in audio level, for example.
  • the escalation may be cleared when the user acknowledges the fault; however, the base alarm remains because the underlying condition persists.
  • a level 5 severity may be for high priority alarms per IEC 60601-1-8. The annunciation when activated may be cleared only when the underlying issue is resolved, e.g., glucose level is raised.
  • a condition may occur that impacts the operation of the ambulatory medicament device. This condition may be associated with the ability of the ambulatory medicament device to operate as intended by the manufacturer, a subject receiving therapy from the ambulatory medicament device, and/or user (e.g., healthcare provider, parent, or guardian of the subject).
  • the condition or malfunction of the ambulatory medical device may prevent the ambulatory medical device from providing therapy to the subject.
  • the condition or malfunction may permit, at least for a period of time, the ambulatory medical device to continue providing at least partial therapy to the subject.
  • it is desirable to track the alert until the condition that caused the alert is resolved.
  • it is desirable to issue different types of alerts for different conditions to enable a subject or user to easily distinguish the severity of the condition that triggered the alert.
  • the best or most desirable response to a problem with the device for a subject is to notify the device manufacturer, or other user that can address the problem, while the subject continues to receive therapy until a replacement device can be obtained or a repair can be made.
  • alert fatigue can be an issue with medical devices due to excessive alerts which do not necessarily require user interaction. Alert fatigue can be dangerous because it can lead users to ignore serious alerts or alerts that require action in the short term.
  • the method described herein may be performed by an AMD (e.g., by one or more processor of the AMD) to detect device malfunctions for the AMD and that can generate alerts corresponding to the ambulatory medical device and prioritize the alerts to enable the subject or user to quickly and easily determine whether the device malfunction will impact therapy, should be addressed in the short-term (e.g., immediately, in 1-2 hours, within the day, etc.), and/or can be addressed at the subject’s convenience (e.g., within a month, or more).
  • the method may be used by other systems.
  • the system disclosed herein can detect a condition in which the ambulatory medical device does not meet a manufacturer’s specification (e.g., a failure of a haptic annunciator, a Bluetooth® radio malfunction, glucagon or insulin runs out, there is a medicament delivery malfunction, a touchscreen failure, etc.).
  • a condition in which the ambulatory medical device does not meet a manufacturer’s specification e.g., a failure of a haptic annunciator, a Bluetooth® radio malfunction, glucagon or insulin runs out, there is a medicament delivery malfunction, a touchscreen failure, etc.
  • a condition in which the ambulatory medical device does not meet a manufacturer’s specification e.g., a failure of a haptic annunciator, a Bluetooth® radio malfunction, glucagon or insulin runs out, there is a medicament delivery malfunction, a touchscreen failure, etc.
  • the fault may not be a fault of the device, but may be indicative of required maintenance (e.g., recharge battery indicator, order more medicament indicator, etc.) ⁇
  • required maintenance e.g., recharge battery indicator, order more medicament indicator, etc.
  • the condition may be annunciated to the user with appropriate instructions (e.g., call manufacturer for replacement medicament or parts) for addressing the fault or issue.
  • the alert may be re-annunciated as a reminder at some later period in time (e.g., the alert may be re- annunciated daily at 4:00 PM or on Saturdays at noon).
  • the length of time between annunciations may depend on the severity of the fault. In some cases, the re- annunciation cannot be stopped by the user, but may only cease if the underlying condition is resolved.
  • the method may include detecting a condition of the ambulatory medical device.
  • the condition of the ambulatory medical device may be determined by one or more sensors of the ambulatory medical device. Further, the condition of the ambulatory medical device may be determined by the presence or absence of one or more errors when performing one or more functions of the ambulatory medical device. For example, if the ambulatory medical device fails to establish a communication connection with a control system or a data storage system, it may be determined that there is a possible malfunction with the ambulatory medical device. As another example, if the ambulatory medical device fails to deliver medicament or detects an error when attempting to deliver medicament, there may be a malfunction with the medicament pump.
  • the condition of the ambulatory medical device may be determined based on one or more configuration values being outside a normal operating range. For example, if the speed of delivery of medicament is faster or slower than a configured operating range, then it may be determined that there is a malfunction with the medicament pump or a connection with a medicament delivery tube (e.g., a catheter).
  • a medicament delivery tube e.g., a catheter
  • the method may include comparing the detected condition of the ambulatory medical device to a set of normal operating parameters.
  • the set of normal operating parameters may be the specifications set by the manufacturer for when the ambulatory medical device is operating as intended by the manufacturer.
  • the normal operating parameters may be associated with a range of values.
  • the operating parameter for a speed of medicament delivery may be associated with a range of speeds, which may vary based on user settings, medicament type, site location of medicament delivery, or manufacturing tolerances, among other parameters.
  • Comparing the detected condition of the ambulatory medical device to the set of normal operating parameters may include comparing each operating parameter in the specification to a corresponding detected operating parameter of the ambulatory medical device.
  • the ambulatory medical device may generate a user alert based on the determined condition of the ambulatory medical device.
  • the AMD may generate an alert when the detected condition of the ambulatory medical device does not satisfy a set of normal operating parameters.
  • the method may further include determining whether the detected condition satisfies a minimum set of operating parameters.
  • the minimum set of operating parameters may match the normal operating parameters. However, typically the minimum set of operating parameters differ from the normal operating parameters.
  • the minimum operating parameters may include the minimum specifications, minimum parameters, or minimum condition required by the ambulatory medical device to maintain or continue providing therapy to the subject. In other words, the minimum operating parameters are the operating parameters sufficient to provide therapy. However, the minimum operating parameters may not be sufficient to enable all features of the ambulatory medical device. For example, the minimum operating parameters may permit the ambulatory medical device to deliver insulin to the subject, but may not be sufficient to deliver the insulin at a normal delivery speed for the particular ambulatory medical device.
  • the minimum operating parameters may permit the delivery of therapy, but may not be sufficient to track a log of therapy or to transmit a therapy log to another computing system.
  • the normal operating parameters and/or minimum operating parameters may be specified by a subject or healthcare provider (e.g., the minimum amount of medicament that is to be provided in each bolus may be specified by a healthcare provider). In some cases, the normal or minimum operating parameters may be modified.
  • the ambulatory medical device may be configured to maintain delivery of therapy to the subject. Maintaining delivery of therapy may include maintaining therapy at the same rate, at a reduced rate (e.g., providing only basal therapy and therapy responsive to a meal announcement), or at a minimum maintenance rate (e.g., providing only basal insulin).
  • Maintaining delivery of therapy may include maintaining therapy at the same rate, at a reduced rate (e.g., providing only basal therapy and therapy responsive to a meal announcement), or at a minimum maintenance rate (e.g., providing only basal insulin).
  • the ability of the ambulatory medical device to distinguish between a minimum set of operating parameters and a normal set of operating parameters enables an ambulatory medical device with a malfunction to continue providing therapy, which sometimes includes life-saving treatment, to a subject until the ambulatory medical device can be repaired or until the condition of the device worsens to a point where the minimum operating parameters cannot be maintained.
  • the ambulatory medical device may temporarily maintain delivery of therapy. Temporarily maintaining therapy may provide a subject time to address the issue that caused the ambulatory medical device to not satisfy the normal operating parameters before the subject loses access to therapy. In some cases, the ambulatory medical device temporarily maintains therapy until the device condition makes it no longer possible to maintain therapy.
  • FIG. 34 is a block diagram illustrating the interconnection among modules and procedures in AMD involved in monitoring the condition of the AMD and generating an alert when a device malfunction is detected.
  • the condition of AMD may include the status of the modules and components of the AMD and/or operation of modules and procedures of the AMD, such as AMD modules and sensors 3407.
  • the alert system may be implemented as a set of alert control procedures 3422 in the control and computing module 610 (CCM) of the AMD.
  • the alert control procedures 3422 may be implemented as instructions stored in a memory of CCM (e.g., the main memory 616) and executed by a hardware processor 614 to generate an alert upon detection of a malfunction of the AMD.
  • the hardware processor may be a hardware processor of the AMD that controls medicament delivery.
  • the hardware processor of the monitoring system may be a separate hardware processor.
  • the alert control procedures 3422 may include a monitoring interface 3426, an operation monitoring procedure 3425 and alert generation procedure 3428.
  • the monitoring interface 3426 may monitor and evaluate the condition of the AMD and/or the subject at least partially based on the information received from the operation monitoring procedure 3425 and device sensors 3424.
  • the device sensors may be configured to track the status of the components or the modules of the ambulatory medicament device and the operation monitoring procedure 3425 may be configured to monitor the operation of the AMD modules and subject sensors (e.g., sensors such a CGM that may be used to monitor one or more parameters associated with the health condition of the subject).
  • the detected of the AMD may be provided to the alert generation procedure monitoring interface.
  • the alert generation procedure 3428 may compare the detected condition of the AMD with a set of normal operating parameter. In some examples, the alert generation procedure may also determine whether the detected condition of the AMD satisfies a minimum set of operating parameters. In some examples, if it is determined that the detection condition of the AMD does not satisfy the normal operating parameters, the alert generation procedure may generate an alert. In some examples, the alert may be transmitted to the user interface module 3408 and displayed on a display of the AMD (e.g., a touchscreen display). In some examples, once an alert is generated the AMD may establish a connection (e.g., a wireless connection) with another device.
  • a connection e.g., a wireless connection
  • This other device may include a local device (e.g., a laptop, smartphone or smartwatch of the user) or a computing system of a cloud-based service.
  • the alert may be transmitted by the communication module 3402 to the computing systems where it may be displayed on user interface associated with the computing system.
  • the additional device may receive data from the ambulatory medical device enabling it to monitor the condition of the ambulatory medical device.
  • the type of the alert, and the frequency at which the alert is repeated, or whether an alert is dismissible or not, may be determined by the alert generation procedure based on the detected condition of the AMD and the alert information stored in a memory of the AMD.
  • the alert information may be provided by the subject, an authorized user or a healthcare provider.
  • the alert information may be stored in the AMD at time of manufacturing.
  • the alert generation procedure may cause the therapy delivery interface 606 to stop therapy delivery or modify one or more delivery parameters (e.g., therapy delivery rate).
  • the therapy delivery may be maintained at a normal rate.
  • the alert may include any type of alert.
  • the alert may be a visual alert (e.g., a light or changing light), an audible alert (e.g., a beep or series of beeps), a haptic or vibration alert, an email alert, a text alert, or any other type of alert.
  • Different device conditions may be associated with or may trigger different alerts.
  • the user alert may enable the user to determine the device condition of the ambulatory medical device based on the alert. For example, an indication that the ambulatory medical device failed to deliver a medicament may trigger one type of alert while an indication that the ambulatory medical device has below a particular level of medicament available may trigger a different alert.
  • the user alert is dismissible and/or may be snoozed by the user. In some cases, such as when the ambulatory medical device fails to satisfy a set of minimum operating parameters, the user alert may not be dismissible or cannot be snoozed.
  • a dismissible alert may be scheduled to repeat on a particular schedule until an alert modification condition occurs.
  • the frequency with which the dismissible alert repeats may depend on the severity of the condition or the particular operating parameters that do not satisfy normal or minimum operating parameters. More urgent device conditions may result in alerts that repeat more frequently. Further, alerts may vary based on when the condition was detected, the time of day, or the detected activity of a subject (e.g., sleep, abnormal activity, or elevated activity, such as exercise). Similarly, the snooze options may vary for different alerts or any of the aforementioned conditions. In some cases, the ambulatory medical device may escalate an alert if it detects that the condition of the ambulatory medical device has become more critical.
  • the alert frequency may be for a static time period (e.g., every 5 hours) or may ramp towards more frequency (e.g., every 5 hours for 1 to 3 reminders, every 4 hours for 3 to 6 reminders, etc.), or may change based on time of day (e.g., snooze alerts during sleeping hours for non-urgent alerts), etc.
  • the alert modification condition may include any action that causes the operating parameters of the ambulatory medical device to return to normal operating parameters.
  • the alert modification condition may be a repair or replacement of a faulty component.
  • the alert modification condition may include an acknowledgement of the alert.
  • the alert modification condition may include a worsening of the ambulatory medical device condition.
  • the modification to the alert may include the substitution of the alert to a different alert that indicates a different or more serious condition of the ambulatory medical device. For example, an urgent condition may become critical if the detected malfunction is addressed after generating certain number of alerts.
  • an urgent condition When an urgent condition becomes critical, it may trigger a different alert type (e.g., a louder sound, or brighter image) and/or escalation in the alert frequency.
  • a different alert type e.g., a louder sound, or brighter image
  • the audible alert may become louder and may be combined with a vibration alert from a haptic annunciator.
  • the ambulatory medical device may cease providing therapy to the subject.
  • generating the alert may further include contacting a manufacturer and/or healthcare provider (e.g., clinician). Further, generating the alert may include ordering replacement parts. In some cases, the alert may instruct a subject or user on how to repair the ambulatory medical device.
  • a manufacturer and/or healthcare provider e.g., clinician
  • generating the alert may include ordering replacement parts.
  • the alert may instruct a subject or user on how to repair the ambulatory medical device.
  • the ambulatory medical device is repaired, or the condition that caused the alert is resolved, a user may permanently (or until the next time a device condition triggers the alert) dismiss the alert. Alternatively, or in addition, the ambulatory medical device may automatically dismiss the alert if it senses that the device condition that caused the alert has been resolved. In some cases, the ambulatory medical device may periodically recheck the device condition to determine whether the alert condition has been resolved.
  • the manufacturer or healthcare provider may remotely clear or stop an alert using, for example, an NB-LTE connection. In some cases, only the manufacturer and/or healthcare provider can clear or stop the alert. Further, in some cases, a manufacturer and/or a healthcare provider may notify a user (e.g., a subject, or parent or guardian) of an issue or impending issue with the ambulatory medical device. The notification may be received by the ambulatory medical device via the NB — LTE connection. Alternatively, or in addition, the notification may be received via a computing device, such as a smartphone or laptop.
  • FIG. 35 is a flow diagram illustrating an example procedure that may be used by the alert system of an AMD to monitor the operation of an AMD and generate alerts when a device malfunction is detected.
  • the alert system continuously monitors the status of all modules and components associated with AMD as well as the operation of all modules and procedures of the AMD.
  • the alert system may determine whether the detected device condition satisfies a set of normal operating parameters 3504. If it is determined that the detected device condition satisfies a set of normal operating parameters, the alert system takes no action and continuous monitoring the AMD. If it is determined that the device condition does not satisfy a set of normal operating parameters, the alert system determines whether the detected device condition satisfies a set of minimum operating parameters.
  • the alert system may send a signal to the therapy delivery module to stop delivery of therapy to the subject 3509, and immediately generate a critical user alert 3511 indicating that immediate action is required.
  • the alarm system of the AMD may contact a healthcare provider or certified user (e.g., parent or guardian of the subject) and/or may send the critical alert to one or more computing devices (e.g., laptop, cell phone, personal computer, and the like) of the healthcare provider or certified user.
  • the alert system may maintain the delivery of therapy to the subject 3510 and generate a user alert 3512. In some such examples, the alert system may maintain the delivery of the therapy at rate associated with the detected condition of the AMD (e.g., normal rate or minimum maintenance rate) until an alert modification condition is detected 3514. Upon detection of an alert modification condition 3514, the alert system may determine whether the new device condition satisfies a set of normal parameters 3516. If, at block 3516, it is determined that the new device condition satisfies a set of normal operating parameters, the alert system may resume the normal operation of the AMD 3518 (e.g., deliver the therapy at a normal rate).
  • the AMD e.g., normal rate or minimum maintenance rate
  • the alert system may determine whether the new device condition satisfies a set of minimum operating parameters 3520. If, at block 3520, it is determined that the new device condition satisfy a set of minimum operating parameters. The alert system may maintain or modify the rate of therapy delivery according to the new device condition 3522 and generate a user alert 3524 according to the according to the new device condition. If, at block 3520, it is determined that the new device condition does not satisfy a set of minimum operating parameters, the alert system may send a signal to the therapy delivery module to stop delivery of therapy to the subject 3509, and immediately generate a critical user alert 3511 indicating that immediate action is required.
  • the alarm system of the AMD may contact a healthcare provider or certified user (e.g., parent or guardian of the subject) and also send the critical alert to one or more computing devices (e.g., laptop, cell phone, personal computer, and the like) of the healthcare provider or certified user.
  • a healthcare provider or certified user e.g., parent or guardian of the subject
  • computing devices e.g., laptop, cell phone, personal computer, and the like
  • Ambulatory medical devices allow subjects the freedom to treat themselves while being mobile. Self-managed medical treatment comes with inherent risks to the subject.
  • An automated glucose level control system may automatically provide insulin and/or a counter-regulatory agent (e.g., Glucagon) to a subject to help control the glucose level of the subject.
  • a control algorithm is implemented by an automated GLCS to determine when to deliver one or more glucose level control agents and how much agent to provide to the subject.
  • the control algorithm may control both an ongoing or periodic delivery of insulin (e.g., a basal dose), and a correction bolus that may be provided to adjust a subject’s glucose level to within a desired range.
  • the control algorithm may use glucose level readings obtained from a sensor, such as a continuous glucose monitoring (CGM) sensor, that obtained automated glucose measurements from the subject.
  • the control algorithm may deliver a bolus of insulin in response to an indication of a meal to be consumed or being consumed by the subject.
  • CGM continuous glucose monitoring
  • Insulin may be administered subcutaneously to a subject. There is often a delay between when the insulin is provided and when the amount of insulin in the subject’s blood plasma reaches maximum concentration. This amount of time may vary based on the type of insulin and on the physiology of the particular subject. For example, with a fast-acting insulin, it may take approximately 65 minutes for a bolus of insulin to reach maximum concentration in the blood plasma of the subject. For some other types of insulin, it may take anywhere from 3-5 hours to reach maximum concentration in the blood plasma of the subject. Accordingly, the GLCS may implement a predictive algorithm that implements a biexponential pharmacokinetic (PK) model that models the accumulation of insulin doses in the blood plasma of the subject. The GLCS may modify its predictions based on the type of insulin, one or more glucose readings, and/or characteristics of the subject.
  • PK pharmacokinetic
  • a subject may receive a manual bolus of insulin or medicament.
  • a user e.g., healthcare provider, parent, or guardian
  • subject may inject a dose of insulin into the subject.
  • the user or subject may manually direct the automated GLCS to provide a bolus of insulin to the subject.
  • the present disclosure relates to an automated GLCS configured to provide automatic delivery of glucose level control therapy to a subject and receive information about manual glucose level control therapy provided to the subject. Using the received information about the manual glucose therapy, the automated GLCS can adjust the glucose control algorithm to account for the manual dosing of insulin (or counter-therapy agents).
  • the manual glucose level control therapy may be provided by injection therapy, or it may be provided by an insulin pump.
  • the automated GLCS may receive an indication of insulin or medicament to administer to a subject in place of an automatically calculated dose of insulin.
  • the automated GLCS may receive an indication that a subject is consuming or will consume a meal.
  • the indication may include a type of meal to be consumed (e.g., breakfast, lunch, or dinner) and an estimate of the quantity of food or carbohydrates to be consumed (e.g., less than usual, a usual amount, more than usual, 30-40 grams of carbohydrates, 45-60 grams of carbohydrates, etc.).
  • the automated GLCS may calculate an amount of insulin to administer to the subject.
  • the calculation may be based on an insulin to carbohydrate ratio provided by a clinician and/or determined by the automated GLCS.
  • the calculation may be based at least in part on a history of glucose level measurements for the subject when consuming particular meals.
  • the calculated amount of insulin for the meal announced by the user may be presented to the user.
  • the user e.g., the subject
  • the user may modify the amount of insulin to administer.
  • the user may determine that for the size meal the subject is consuming or planning to consume, more or less insulin should be administered.
  • the user may modify the calculated insulin dosage to match the user’s determination of the amount of insulin to administer.
  • the automated GLCS may modify its control algorithm based on the user’s input.
  • future meal announcements may result in a calculation of insulin that satisfies the subject’s insulin needs and/or preferences.
  • the indication of an amount of a manual bolus may be received by a user entering a numerical value (e.g., an amount of insulin, a number of carbohydrates, or another calculation) associated with administering insulin.
  • a numerical value e.g., an amount of insulin, a number of carbohydrates, or another calculation
  • the automated GLCS may automatically-calculate a meal dose of insulin and present it to a user via a user interface where a user may enter the manual bolus information.
  • the user may have an option to enter the manual bolus.
  • the meal controller of the glucose pump can provide a recommendation against the manual entry if there is a prior history of online operation or a basis for making the recommendation.
  • the information may be received from a user via a user interface.
  • This user interface may be provided by the automated GLCS.
  • the user interface may be generated by another device, such as a laptop or desktop, a smartphone, a smartwatch, or any other computing device that can communicate via wired or wireless communication with the automated GLCS.
  • the information may include one or more of: an indication of delivery of a manual bolus (e.g., via injection therapy), an amount of the manual bolus, a type of the insulin (or other medicament), a time when the manual bolus was delivered, a general location that the manual bolus was administered to the subject (e.g., back, stomach, arm, leg, etc.), a reason for the manual bolus (e.g., a meal, a maintenance dose, a glucose level reading, in advance of exercise, etc.), and any other information that may be useable by the GLCS in controlling the glucose level of the subject.
  • an indication of delivery of a manual bolus e.g., via injection therapy
  • an amount of the manual bolus e.g., a type of the insulin (or other medicament)
  • a time when the manual bolus was delivered e.g., a general location that the manual bolus was administered to the subject (e.g., back, stomach, arm, leg, etc.
  • providing manual dosing information to the automated glucose level control system can help the GLCS maintain the glucose level of the subject within a desired range when the automated features of the GLCS are active or operational. For example, if the automated GLCS determines from a CGM sensor reading that a subject’s glucose level is high, the automated GLCS might normally administer a bolus of insulin. However, if the automated GLCS receives an indication that a manual bolus of insulin was administered recently (e.g., within the past thirty minutes), the automated GLCS may reduce or not administer a bolus of insulin, thereby preventing a Hypoglycemic event. In some such cases, the automated GLCS may continue monitoring the glucose level of the subject and may administer additional insulin at a later time if the glucose level readings do not reflect an expected glucose level based on the reported manual bolus of insulin.
  • the automated GLCS may track the amount of insulin delivered and the timing of the administering of the bolus.
  • the automated GLCS may store the information associated with the manual bolus in a therapy log. Accordingly, when the automated GLCS is operating in an automatic mode, the automated GLCS can access the therapy log to determine whether any manual bolus was administered and, if so, the timing and amount of the manual bolus.
  • the automated GLCS may model the diminishing of insulin, or other medicament, in the blood plasma over time based on the information associated with the manual bolus. Modeling the diminishing of medicament over time may be used to estimate a future effect of the medicament previously administered.
  • the model may account for previously administered medicament by the automated GLCS. Further, in some cases, the model may account for physiological characteristics of the subject, such as the subject’s weight or an input parameter related to the subject’s weight (e.g., body mass index).
  • the model may account for perfusion over time of the medicament bolus from a subcutaneous infusion site into the blood plasma of the subject. Further, the automated GLCS may model an accumulation of insulin, model time course of activity of insulin, or model a finite rate of utilization of insulin.
  • the automated GLCS may adjust the automated administering of insulin, or other medicament when operating in an automatic mode. Further, the automated GLCS may operate the administering of medicament (e.g., by controlling a medicament pump) based on a glucose level of the subject and the modeled concentration of medicament in the subject.
  • the automated GLCS may operate the administering of medicament (e.g., by controlling a medicament pump) based on a glucose level of the subject and the modeled concentration of medicament in the subject.
  • the automated GLCS may confirm that the manual bolus was delivered to the subject.
  • the confirmation may be determined based at least in part on whether glucose level readings by the CGM sensor match or are within a threshold level anticipated by the automated GLCS based on the manual dosing information.
  • the automated GLCS may request, via a user interface, that a user confirm that the manual bolus was delivered.
  • a user may be requested to confirm the administering of the manual bolus by using a particular gesture or sequence of interactions with a user interface (e.g., a touchscreen) of the automated GLCS or of a device (e.g., laptop or smartphone, etc.) that communicates with the automated GLCS.
  • a user interface e.g., a touchscreen
  • a device e.g., laptop or smartphone, etc.
  • the information relating to the manual bolus may include an amount of insulin and a reason the manual bolus was administered (e.g., for a meal of a particular size).
  • the automated GLCS may determine an amount of insulin the automated GLCS would administer in an automatic operating mode based on the manual dosing information if the manual bolus had not been supplied. If the automated GLCS determines it would have supplied a different quantity of the medicament, and if the difference exceeds a threshold, the automated GLCS may adjust a glucose control algorithm to account for the difference. For example, the automated GLCS may change the operating setpoint or range of insulin the automated GLCS attempts to maintain in the subject. As another example, the automated GLCS may supplement the manual bolus with additional insulin to account for an under-administering of insulin, or may reduce a subsequent dosage of insulin to account for an over-administering of insulin.
  • the automated GLCS may maintain a therapy log of manual insulin therapy.
  • This therapy log may be maintained based on the use of the automated GLCS to provide a manual bolus, or based on information provided by the user based on manual administering of insulin (e.g., via injection).
  • the manual boluses may be supplied when the automated GLCS is not operating, is not operating in an automatic mode, or is not connected to the subject.
  • the automated GLCS may determine therapy, if any, to provide to the subject based on a combination of the therapy log and the glucose control algorithm implemented by the automated glucose level control system.
  • the automated glucose level control system may generate a dose control signal based on the determined therapy. This dose control signal may be supplied to a medicament pump, which may control delivery of the medicament (e.g., insulin) to the subject.
  • a user may control whether the automated GLCS is operating in a manual mode or an automatic mode by interacting with a user interface of the automated GLCS or of a device that communicate with the automated GLCS.
  • the user interaction may include any type of user interaction with a user interface.
  • the user interaction may include interaction via physical buttons or interactions with a touchscreen including gestures or taps on the touchscreen.
  • a system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions.
  • One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.
  • One general aspect includes a method including: providing an option to a user to select between receiving medicament using a manual delivery component or an automated delivery system. The method also includes receiving, by the automated delivery system, subjective information regarding the activity or action that may alter the glucose level. The method also includes receiving, by the manual delivery component, an amount of the medicament to be infused.
  • the method also includes storing a time and the amount of medicament that is infused into the automated delivery system that controls glucose level.
  • Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.
  • Implementations may include one or more of the following features.
  • the method where the automated delivery system modifies medicament delivery based on the time and the amount of medicament that was received from either the manual delivery component or the automated delivery system.
  • the method where the manual delivery component includes a keypad which allows the user to type in the dosage amount of the desired medicament.
  • the method where providing the option to select is provided prior to a user performing the activity that may alter the glucose level.
  • the method where the activity that may alter the glucose level includes of consuming food or exercising.
  • the method where the subjective information regarding the activity of consuming food includes the approximate relative size of the food that is to be digested.
  • the method where the subjective information regarding the activity of exercising includes the intensity and the duration of the exercise.
  • a system having a medical device configured to provide an option to a user to select between receiving medicament using a manual delivery component or an automated delivery system.
  • the system may also include an automated delivery system configured to receive subjective information regarding the activity that may alter the glucose level.
  • the system may also include a manual delivery component configured to receive an amount of the medicament to be infused.
  • the system may also stores in memory a time and the amount of medicament that is infused into a subject via an automated delivery system that controls glucose levels of the subject.
  • the system may include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods disclosed herein.
  • an ambulatory medical device may provide options which enable the user to either manually request the amount of the desired medicament or to choose an automated delivery system that automatically delivers the right amount of the medicament at the right time without further assistance.
  • the user may input a desired medicament amount on a keypad that is in communication with the medical device.
  • the medical device may confirm the medicament quantity or type and may deliver the requested medicament or confirm manual delivery of the medicament.
  • the data is stored into a model predicative control component which is further used to control and regulate the glucose level.
  • the user may provide subjective information regarding the activity or the action that may alter the glucose level. For example, if the glucose level changing activity is consuming food, the user may provide the time and the dosage amount of the food that is going to be digested. This information may be associated with the automated delivery system, and the subjective information is further stored into a model predicative control component.
  • Embodiments described herein include an ambulatory medical device that has a keypad which allows a user to type in a dose of insulin or glucagon to be administered to a user.
  • a user may wish to receive a single dose of insulin prior to consuming food and decide how much insulin need to be administered.
  • the user may choose to receive a burst of glucagon due to low blood glucose because of physical activities.
  • Embodiments may include the options for manual inputs of medicament and automated delivery system of medicament.
  • the automated delivery system of medicament is driven by the glucose level or related trends.
  • Embodiments herein address a problem that may arise when the user has just received a manual dose and has switched on the automated delivery system.
  • the automated delivery system may receive data indicating manual medicament infusion amounts and the timing of such infusions. Accordingly, the manual delivery component may inform the automated delivery system upon delivering any medicament the type of medicament delivered, the amount of medicament and the timing of the medicament delivered. By having the above information, the automated delivery system may determine the amount of medicament that is the user’s blood stream and adjust the automated delivery of medicament and the timing of the automated delivery. Accordingly, embodiments are directed to allowing for a risk free, or reduced risk, transition from the manual delivery component to the automated delivery system.
  • the manual delivery of medicament may be correlated or associated with an automated delivery system.
  • the dose input from the user may be stored and can be used as an input into the MPC algorithm (Model Predictive Control) instead of or in addition to use by the meal delivery algorithm.
  • Other embodiments may include selection being able to have a relativistic algorithmically tuned value.
  • Other embodiments may include a learning algorithm that includes a usual size meal or larger size meal or smaller size meal.
  • Embodiments may include corelating the manual inputs, such as user indication of meal size, to insulin effects enabling the system to learn how doses of insulin affect the user.
  • Embodiments may include corelating the manual inputs to asking the user what activity the user performed and learning how the glucagon affects the user for a particular activity.
  • FIG. 36 illustrates a schematic of the therapy change delivery system 3600 in an ambulatory medical device 3602 that allows the user the choice of receiving manual delivery of medicament or automated delivery of medicament. Moreover, the therapy change delivery system 3600 allow the user to transition between the manual mode and the automated mode with ease.
  • the therapy change delivery system 3600 includes the ambulatory medical device 3602, a signal processing component 3603, a user 3604, a therapy delivery component 3605, a therapy change input 3606, input components 3607, activity change component 3608, and a therapy change delivery 3610.
  • the user 3604 may initiate a therapy change input 3606 to request the manual or automated medicament.
  • the ambulatory medical device 3602 may be any type of medical device that a user 3604 may carry around and use, generally with the approval of a medical professional, to help manage a subject’s health or a disease of the subject (e.g., diabetes).
  • a subject e.g., diabetes
  • the ambulatory medical device 3602 is an insulin and/or glucagon infusion device for user 3604 that has type I diabetes.
  • Ambulatory medical devices 3602 allow users 3604 the freedom to receive medical care in any setting at their convenience.
  • the drawback of using an ambulatory medical device 3602 could be the user 3604 making mistakes when the user is away from the medical professionals.
  • One possible issue may be caused when the user 3604 switches from a manual delivery mode to an automated delivery mode when the ambulatory medical device 3602 is unable to determine the amount of medicament in the subject (e.g., the amount of insulin on board or IOB) or in the subject’s blood stream.
  • Embodiments are directed to the manual medicament delivery information being provided to the automated medicament delivery system so that it can adjust its operations based on the current and future medicament in the subject’s blood stream.
  • automated delivery of medicament can be problematic, such as when unreported manual doses of medicament are administered.
  • the ambulatory medical device 3602 includes a signal processing component 3603, a therapy delivery component 3605, and input components 3607.
  • the signal processing component 3603, therapy delivery component 3605, and input components 3607 may be physically connected, wirelessly connected, connected via a cloud-based computer system, or connected in any other way.
  • the signal processing component 3603 is a computing system that performs the computing functions for the ambulatory medical device 3602.
  • the signal processing component 3603 includes a processor, memory, and storage.
  • the signal processing component 3603 may be a single computing system or may be made up of several computing systems.
  • the signal processing component 3603 may perform the computing functions for a single ambulatory medical device 3602 or many ambulatory medical devices.
  • the signal processing component 3603 receives signals from the therapy delivery component 3605 and from the input components 3607.
  • the signal processing component 3603 also transmits signals to the therapy delivery component 3605 and the input components 3607. Signals of the therapy change input 3606, the therapy change delivery 3610, and the activity change component 3608 may be received or transmitted by the signal processing component 3603.
  • the user 3604 may be any individual that uses the ambulatory medical device 3602.
  • the user 3604 is an individual with diabetes that requires a periodic infusion of insulin or glucagon to maintain healthy blood glucose levels.
  • the ambulatory medical device 3602 infuses insulin or glucagon into the user 3604.
  • the user 3604 may transport the ambulatory medical device 3602. Thus, as the user 3604 moves around, there is a danger that the user 3604 will inadvertently activate input in the ambulatory medical device 3602 that initiates a therapy change input 3606.
  • the therapy delivery component 3605 provides medicaments to the user 3604. Signals received from the signal processing component 3603 are executed by the therapy delivery component 3605 to change therapy such as starting, modifying, or stopping a therapy.
  • the therapy delivery component 3605 may have a computing component for interpreting and executing instructions from the signal processing component 3603. Thus, the therapy delivery component 3605 can follow a program that is controlled by the signal processing component 3603.
  • the therapy delivery component 3605 may include one or more infusion pumps.
  • An infusion pump may be capable of delivering fluids at varying rates to a user 3604. The infusion pump may deliver any fluid, including medicaments.
  • the infusion pump may be connected to a user 3604 through any means.
  • the infusion pump is connected to the body through a cannula.
  • the therapy delivery component 3605 may be an insulin infusion pump and/or a glucagon infusion pump. Signals received from the signal processing component 3603 may be interpreted by an insulin and glucagon pump to start, stop, or change the rate of insulin and glucagon being delivered into a user 3604.
  • the therapy delivery component 3605 may be an electrical stimulation device.
  • An example of an electrical stimulation device is a cardiac pacemaker.
  • a cardiac pacemaker stimulates the cardiac muscle to control heart rhythms.
  • Instructions received from the signal processing component 3603 may be interpreted by a cardiac pacemaker to start stimulating a cardiac muscle, stop stimulating a cardiac muscle, or change the rate of stimulation of a cardiac muscle.
  • Another example of an electrical stimulation device is a deep brain stimulator to treat Parkinson’s disease or movement disorders. Instructions received from the signal processing component 3603 may be interpreted by the deep brain stimulator to start, stop, or modify the stimulation of the brain.
  • the therapy change input 3606 is an input provided by the user 3604 to change a therapy that is currently being delivered to the user 3604.
  • the change of therapy may be to start a therapy, modify a therapy, or cancel a therapy.
  • the types of therapy changes are dependent on the type of ambulatory medical device 3602.
  • the ambulatory medical device 3602 may be an insulin or glucagon infusion device.
  • the therapy change input 3606 in an insulin or glucagon infusion device may be an instruction, that when executed, causes the insulin or glucagon infusion device to start infusing an amount of insulin or glucagon into the user 3604.
  • the therapy change input 3606 may be an instruction to modify the rate of insulin or glucagon infusion into the user 3604.
  • the therapy change input 3606 may also be an instruction to cancel insulin or glucagon infusion into the user 3604 from the insulin or glucagon infusion device.
  • the ambulatory medical device 3602 may be an electrical implant, that when operated, stimulates a part of the body.
  • An example is an electrical brain implant for users 3604 with Parkinson’s disease or for pain management.
  • the implementation of the therapy change can be to modify the rate of electrical stimulation to the body.
  • the therapy change delivery 3610 is the performance, by the ambulatory medical device 3602, of the therapy change input 3606 that was verified by the 3608.
  • the therapy change that is delivered by the therapy change delivery 3610 corresponds to the therapy change selection made by the user 3604.
  • the ambulatory medical device 3602 alerts the user 3604 that it is performing a therapy change delivery 3610.
  • the ambulatory medical device 3602 displays the therapy change during the therapy change delivery 3610. Any number of details of the therapy change may be displayed during the therapy change delivery 3610. As shown in FIG. 43, a simple message of “Delivering” may be displayed during the therapy change delivery 3610.
  • the ambulatory medical device 3602 plays a sound effect during the therapy change delivery 3610.
  • the therapy change delivery 3610 may be canceled by an input by the user 3604.
  • the input to cancel a therapy change delivery 3610 may be any input such as a wake signal input or a series of touch inputs such as a gesture.
  • the input components 3607 allow the user 3604 to interact with and control the ambulatory medical device 3602.
  • the amount of control that a user 3604 has may vary based on the type of ambulatory medical device 3602 and the user 3604.
  • an ambulatory medical device 3602 that delivers pain medication may allow the user more control than an ambulatory medical device 3602 that controls heart rhythms.
  • a user 3604 that is a young child may be allowed less control over an ambulatory medical device 3602 than a user 3604 that is a teen or an adult.
  • the input components 3607 include a wake button 3620, a touchscreen display 3622, and an alphanumeric pad 3624.
  • the wake button 3620 may be activated by a user 3604 to create a wake signal input to unlock an ambulatory medical device 3602.
  • the wake button 3620 may be any input button.
  • the wake button 3620 is a capacitive button that detects a change in capacitance.
  • the wake button 3620 may have a computing component for interpreting and executing instructions from the signal processing component 3603. Thus, the wake button 3620 can follow a program that is dictated by the signal processing component 3603.
  • the touchscreen display 3622 may display a therapy change user interface for the user 3604 and receive user 3604 inputs on the touchscreen display 3622 input surface. Inputs on the touchscreen display 3622 may be registered by any touch technology including, but not limited to capacitive and resistive sensing.
  • the touchscreen display 3622 may be a part of a mobile computing device, such as a cellular phone, tablet, laptop, computer or the like.
  • the touchscreen display 3622 may have a computing component for interpreting and executing instructions from the signal processing component 3603. Thus, the touchscreen display 3622 can follow instructions that are directed by the signal processing component 3603.
  • the touchscreen display 3622 may display buttons, alphanumeric characters, symbols, graphical images, animations, or videos.
  • the touchscreen display 3622 may display an image to indicate when the ambulatory medical device 3602 is locked or inaccessible via the touchscreen display 3622.
  • the touchscreen display may receive the series of inputs that make up the first gesture and the second gesture.
  • the alphanumeric pad 3624 registers numerical inputs, alphabetical inputs, and symbol inputs.
  • the alphanumeric pad 3624 includes a multitude of keys corresponding to numerical, alphabetical, and symbol inputs.
  • the alphanumeric pad 3624 may have a computing component for interpreting and executing instructions from the signal processing component 3603. Thus, the alphanumeric pad 3624 can follow instructions that are dictated by the signal processing component 3603.
  • the alphanumeric pad 3624 may be configured to provide haptic feedback from its keys.
  • the alphanumeric pad or pads 3624 may have any number of keys and any number of characters and may span multiple screens that the user 3604 can toggle between to find particular characters.
  • the wake button 3620 is incorporated into the alphanumeric pad 3624.
  • the wake button 3620 may be any one or more keys of the alphanumeric pad 3624.
  • the alphanumeric pad 3624 is displayed as part of the touchscreen display 3622. Characters from the alphanumeric pad 3624 may be used as input for the wake signal input, first gesture, therapy change selection, and second gesture.
  • the first gesture and/or second gesture are created by entering predetermined characters on the alphanumeric pad 3624.
  • the activity change component 3608 may be part of a specialized software that is executed on an ambulatory medical device or include a specialized hardware that performs the various functions described here.
  • the activity change component 3608 may receive inputs from the user regarding weather the user is about to conduct activities that will change the glucose of the user. For example, the user may provide input using the input components 3607 that the user is about to perform exercise that may lower their blood glucose or eat a meal that will increase their blood glucose.
  • the activity change component 3608 offers the user the option via the mode controller 3613 to select between the automated delivery system 3612 or the manual delivery component 3614.
  • the manual delivery system may inform the automated delivery system 3612 and the model predictive control component 3616 regarding any manual medicament deliveries of insulin or glucagon.
  • the user may choose the dosage amount, the drug type (insulin or glucagon; fast or slow acting) and the time of the delivery and the manual delivery component 3614 may receive such information and deliver the medicament(s) accordingly.
  • the manual delivery component 3614 may inform the automated delivery system 3612 and the model predictive control component 3616 regarding the drug type (insulin or glucagon; fast or slow acting) and the time of the delivery.
  • the data from previous manual medicament infusions can be readily available so that the automated delivery system 3612 may be able to determine how much medicament is still in the user’s blood stream.
  • the automated delivery system 3612 may make that determination by tracking the finite rate of utilization of infused insulin by the subject based on the time and amount of any manual medicament infusions reported to the automated delivery system 3612.
  • FIG. 37 is a flow chart of a process 3700 detailing a medicament selection process, according to an exemplary embodiment.
  • the medical device provides an option to a user to select between receiving medicament using a manual delivery component or an automated delivery system.
  • the mode controller 3613 the user can select the method for the therapy change request between manual delivery component and the automated delivery system.
  • the medical device may receive subjective information regarding the activity or action that may alter the glucose level.
  • Subjective information may include the size of the meal and/or the type of physical activity.
  • the manual delivery component may receive an amount of the medicament to be infused.
  • the medicament may be a plurality of hormones, including but not limited to, glucagon or insulin.
  • the medical device may store a time and the amount of medicament that was infused into the automated delivery component that controls the glucose level.
  • the systems that are disclosed in FIG. 36 may be utilized to accomplish one or more of the operations associated with the steps 3710, 3720, 3730 and 3740.
  • FIG. 38 is another flow diagram of a process 3800 for providing options for meal dosage selection or physical activity of the user on an ambulatory device.
  • Embodiments described herein may include an ambulatory medical device that has a keypad or other user interface device that enables a user to enter a dose of insulin or glucagon to be administered to a user.
  • a user may wish to receive a single dose of insulin prior to consuming food and decide how much insulin need to be administered.
  • the user may choose to receive a burst of glucagon due to low blood glucose because of physical activities.
  • Embodiments may include the options for manual inputs of medicament and automated delivery system of medicament. In various implementations, the automated delivery system of medicament is driven by the glucose level or related trends.
  • Embodiments herein address a problem that may arise when the user has received a manual medicament dose and has switched on the automated delivery system.
  • data indicating the quantity and timing of a manual medicament dose may be provided to or transmitted to the automated delivery system.
  • the manual delivery component may transmit to the automated delivery system the type of medicament delivered, the amount of medicament and the timing of the medicament delivered.
  • the automated delivery system may determine the amount of medicament that is the user’s blood stream and adjust the automated delivery of medicament and the timing of the automated delivery. Accordingly, embodiments disclosed herein enable a risk-free or reduced risk transition from the manual delivery component to the automated delivery system, or vice versa.
  • the user may inform the activity change component 3608 that the user is about to engage in activities that may alter the glucose level of the user.
  • the mode controller 3613 may be activated at decision block 3820 and ask whether the user wants to use the manual delivery component 3830 or the automated delivery system 3850. If the user chooses to use the manual delivery component 3830 and the user provides an input to infuse medicament, the ambulatory device 3602 may delivery the medicament to the user. Upon the manual delivery process completion, the manual delivery component 3830 may inform at least one of the model predictive control component 3840 and the automated delivery system 3850 regarding the type of medicament, amount of medicament and the time when the medicament was delivery.
  • the model predictive control component 3840 and automated delivery system 3850 may track these manual infusions of medicament and determine that based on the rate of decay or the half-life of the medicament the total amount of medicament that remains in the user’s blood stream at a particular time or a period of time. Accordingly, when the automated delivery system 3850 is activated by the user, the automated delivery system 3850 may change its medicament infusion based on the medicament that remains in the user’s blood stream after a manual infusion by the user.
  • Differences from other system may include that the manual delivery may be tied to an automated delivery system, the dose input from the user is then stored into the MPC algorithm (Model Predictive Control) instead of the meal delivery algorithm and is handled by the MPC algorithm.
  • Other embodiments may include selection being able to have a relativistic algorithmically tuned value.
  • Other embodiments may include a learning algorithm that includes a usual size meal or larger size meal or small size mean.
  • Embodiments may include correlating the manual inputs to asking the user what was the size of the meal and learning how the insulin affects the user.
  • Embodiments may include corelating the manual inputs to asking the user what activity the user performed and learning how the glucagon affects the user for a particular activity.
  • FIG. 39 illustrates a plurality of screens 3900 that may be produced by the ambulatory medical device 100.
  • the plurality of screens 3900 demonstrates a process that a user may take in order to enter meal doses.
  • the enter meal doses screen 3910 may be displayed.
  • a warning text may be displayed for the user to ensure safety.
  • the warning text states that entering a dose may be unsafe and the device will not adapt its meal doses. This warning text cautions the user of the risks that may be involved in the process of using the ambulatory medical device 3602.
  • a password screen 3920 may be displayed.
  • a keypad is provided for the user to enter a predetermined sequence of numbers to ensure that the user is the actual registered user of the ambulatory medical device 3602.
  • the enter meal doses screen 3930 (with meals key in OFF state) or enter meal doses off screen 3940 (with meals key on ON state) may be displayed.
  • the user may decide to access the advanced screen 3960, and upon doing so, the advanced screen 3960 will allow the user to double check the CGM Insulin levels and change the speed of the of the insulin pump.
  • the user is provided the option to have the meal keypad on or off.
  • the user selects to have the keypad on, then an option may be provided for the user to choose the max dose limit. If the user decides to choose the max dose limit, the official max dose limit screen 3950 is displayed, where the user may enter up to 10 units of the dose. The provided number of units is then stored in the model predictive control component 116 for further regulation of the glucose level.
  • FIG. 40 illustrates a plurality of screens 4000 that may be produced by the ambulatory medical device 3602.
  • the initial menu screen 4010 may be displayed.
  • options regarding functionalities of the ambulatory medical device 3602 is provided.
  • the list of functionalities may cover some or all of the aspects of the ambulatory medical device 3602.
  • the user may access and control many aspects of the device by choosing the setting option.
  • the setting option will allow the user to further assess and regulate the adjustable functionalities of the ambulatory medical device 3602.
  • the setting screen 4020 may be displayed and the user may select the advanced setting option.
  • the advanced setting screen 4030 is displayed, and the user is provided the option to double check the CGM insulin levels and change the speed of the of the insulin pump.
  • the user may speed up the process or slow down the process depending on the regulation stats that are provided by the model predictive control component 3616.
  • FIG. 41 illustrates a plurality of screens 4100 that may be produced by the ambulatory medical device 3602.
  • the plurality of screens 4100 is the process that a user may take in order to enter meal announcements.
  • the home screen 4110 provides information and stats regarding the cartridge of the ambulatory medical device 3602.
  • the user may select the meal button with or without an installation of a new cartridge. If a user selects the meal button without installing a new cartridge, the ambulatory device 3602 will display the warning screen 4130, where the user is warned that the insulin cartridge is empty, and the device further advises the user to change the cartridge.
  • the ambulatory medical device 3602 will display the carbs screen 4120, where the user is provided the option to choose a meal dose option.
  • the carbs screen 4120 allows the user to provide subjective information regarding the food that is to be digested. This subjective data provided by the user is further stored in the model predictive control component 3616 for further regulation of the glucose level.
  • FIG. 42 illustrates a plurality of screens 4200 that may be produced by the ambulatory medical device 3602.
  • the plurality of screens 4200 demonstrates the process of the user being alerted about the empty cartridge and having the option to replace the cartridge and further enter the meal doses.
  • Warning screen 4210 alerts the user that the insulin cartridge is empty and the fact that it needs to be replaced.
  • screens 4220 and 4230 will be displayed.
  • Screen 4220 is initially displayed, and a user may enter a specified dose for each meal on a numerical pad.
  • screen 4230 is displayed where a next button is provided for the user to further complete the therapy change.
  • the numerical specified dose is further stored in the model predictive control component 3616 for further regulation of the glucose level.
  • FIG. 43 illustrates a plurality of screens 4300 that may be produced by the ambulatory medical device 3602.
  • a user may cancel the delivery of the medicaments prior to the completion of the delivery.
  • the ambulatory medical device 3602 displays a countdown prior to delivery.
  • the initial countdown screen 4310 is proceeded by the secondary countdown screen 4330.
  • a cancel button is provided for the user to cancel the therapy change.
  • the user may cancel the delivery at any time. By swiping the cancel button, the user may officially stop the delivery of the therapy change. If the user does not cancel, the therapy change may be delivered successfully.
  • the time and the amount of the therapy change delivery is stored in the model predictive control component 3616 for further regulation of the glucose level.
  • the delivery will be canceled and the screen 4320 will be provided.
  • the ambulatory medical device 3602 upon pressing the ok button, the ambulatory medical device 3602 will display a lock screen 4340 and take the time to officially cancel the therapy change request.
  • FIG. 44 is a block diagram illustrating a computer system 4400 that may be implemented in the various embodiments in the described subject matter.
  • the computer system 4400 includes a processor 4402, main memory 4404, storage 4406, a bus 4408, and input 4410.
  • the processor 4402 may be one or more processors.
  • the processor 4402 executes instructions that are communicated to the processor through the main memory 4404.
  • the main memory 4404 feeds instructions to the processor 4402.
  • the main memory 4404 is also connected to the bus 4408.
  • the main memory 4404 may communicate with the other components of the computer system through the bus 4408. Instructions for the computer system 4400 are transmitted to the main memory 4404 through the bus 4408. Those instructions may be executed by the processor 4402.
  • Executed instructions may be passed back to the main memory 4404 to be disseminated to other components of the computer system 4400.
  • the storage 4406 may hold large amounts of data and retain that data while the computer system 4400 is unpowered.
  • the storage 4406 is connected to the bus 4408 and can communicate data that the storage holds to the main memory 4404 through the bus 4408.
  • the processor 4402 may be any type of general purpose processor including, but not limited to a central processing unit (“CPU”), a graphics processing unit (“GPU”), a complex programmable logic device (“CPLD”), a field programmable gate array (“FPGA”), or an application-specific integrated circuit (“ASIC”).
  • CPU central processing unit
  • GPU graphics processing unit
  • CPLD complex programmable logic device
  • FPGA field programmable gate array
  • ASIC application-specific integrated circuit
  • the main memory 4404 can be any type of main memory that can communicate instructions to the processor 4402 and receive executed instructions from the processor 4402.
  • Types of main memory 4404 include but are not limited to random access memory (“RAM”) and read only memory (“ROM”).
  • RAM random access memory
  • ROM read only memory
  • the computer system 4400 incorporates RAM as the form of main memory 4404 to communicate instructions to the processor 4402 and receive executed instructions from the processor 4402.
  • Other embodiments may be envisioned that incorporate other types of main memory 4404 in the computer system 4400.
  • the storage 4406 can be any type of computer storage that can receive data, store data, and transmit data to the main memory 4404 via the bus 4408.
  • Types of storage 4406 that can be used in the computer system 4400 include, but are not limited to, magnetic disk memory, optical disk memory, and flash memory.
  • flash memory is used as the storage 4406 in the computer system 4400 of the ambulatory medical device 100.
  • Other embodiments that use other types of storage 4406 for the computer system 4400 may be envisioned.
  • the bus 4408 connects the internal components of the computer system 4400.
  • the bus 4408 may include a multitude of wires that are connected to the components of the computer system 4400.
  • the wires of the bus 4408 may differ based on the components of the computer system 4400 to which the bus 4408 connects.
  • the bus 4408 connects the processor 4402 to the main memory 4404.
  • the processor 4402 is directly connected to the main memory 4404.
  • the input 4410 of the computer system 4400 includes a touchscreen display 4412, an alphanumeric pad 4414, and buttons 4416.
  • the touchscreen display 4412 both produces output and accepts input.
  • the bus 4408 may be coupled to the touchscreen display 4412 to produce visual output.
  • the touchscreen display 4412 may also accept input via capacitive touch, resistive touch, or other touch technology.
  • the input surface of the touchscreen display 4412 can register the position of touches on the surface. Some types of touchscreen display 4412 can register multiple touches at once.
  • the alphanumeric pad 4414 includes a multitude of keys with numerical, alphabetical, and symbol characters. Signals from the alphanumeric pad 4414 are communicated by the bus 4408 to the main memory 4404. Keys of the alphanumeric pad 4414 may be capacitive or mechanical. In some embodiments, the alphanumeric pad 4414 is displayed on the touchscreen display 4412. Buttons 4416, such as the wake button 120, may be capacitive, mechanical, or other types of input buttons.
  • Providing glucose control therapy such as glucose control therapy, generally requires regular delivery of medicament.
  • a healthcare provider may need to set a rate of medicament delivery to a subject. This rate may need to be regularly and/or frequently adjusted in response to a variety of factors. For instance, a subject may require additional insulin delivery after a meal.
  • a subject will receive a basal rate of medicament.
  • a subject may receive a regular or basal rate of insulin to maintain a desired glucose level.
  • This basal rate may be set by a healthcare provider, such as a nurse or a doctor.
  • the basal rate may need to be modified as needed. The modifications may need to be made in response to changes to a user’s consumption pattern or other factor.
  • the basal rate may need to be modified in response to a meal announcement.
  • the basal dose can be generated using a basal control algorithm such as discussed above. Meal announcements are not the only changes that may cause modifications to the basal rate.
  • the therapy delivered e.g., the basal rate
  • Manual therapy can be provided to the subject that is different from the basal rate.
  • a healthcare provider may set an initial dose control signal that commands a delivery of medicament to the subject according to a particular schedule. This initial dose control signal may be modified from time to time using a glucose level control system.
  • Health- appropriate therapy may include therapy that is sufficient to maintain a baseline level of health for the subject.
  • health- appropriate therapy may be therapy that is configured to maintain a glucose level of the subject within a threshold range.
  • the threshold range may include glucose levels or predicted glucose levels from about 70 mg/dl to about 180 mg/dl.
  • the threshold range can be from about 70 mg/dl to about 170 mg/dl, from about 75 mg/dl to about 160 mg/dl, from about 80 mg/dl to about 150 mg/dl, from about 80 mg/dl to about 140 mg/dl, from about 85 mg/dl to about 130 mg/dl, from about 90 mg/dl to about 125 mg/dl, or a range between any of the foregoing values.
  • the system may generate (e.g., automatically) an emergency dose control signal that is configured to command administration of modified glucose control therapy to the subject via the medicament pump. Based on the emergency dose control signal, the system may modify the manual therapy instruction and transmit the emergency dose control signal to the pump controller of the medicament pump.
  • the system can supply critical updates to a subject’s therapy during an emergency situation.
  • the subject may receive a counter- regulatory dose of medicament if, for example, a glucose sensor determines that a level of glucose level in the subject’s body has exceeded a threshold maximum level and/or if the glucose level is below a threshold minimum level.
  • FIG. 45 shows an example glucose level control system 4500 configured to configured to modify a manual therapy instruction and to generate an emergency dose control signal.
  • “Modify” may refer to its plain and ordinary meaning, and may include adjusting, updating, complementing, temporarily overriding, or permanently overriding the manual therapy instruction.
  • the emergency dose control signal can be configured to command administration of modified glucose control therapy to a subject via a medicament pump 4520.
  • the glucose level control system 4500 includes a non-transitory memory 4504, an electronic hardware processor 4508, and a data interface 4516.
  • the data interface 4516 may include a wireless and/or wired data interface.
  • the data interface 4516 can include a short-range wireless data interface.
  • the data interface 4516 may be in communication (e.g., wired, wireless) with the medicament pump 4520 (e.g., via a medicament pump connection 4532).
  • the glucose level control system 4500 may be directly connected to the medicament pump 4520 within a hospital room or other healthcare setting.
  • the data interface 4516 can be in communication with a network 4524 (e.g., via a network connection 4536), and/or a user device connection 4540 (e.g., via a user device connection 4540).
  • Each of the connections 4532, 4536, 4540 may be one-way or two-way.
  • the data interface 4516 may also be in communication with other elements of the medicament pump 4520, such as the pump mechanism 4522 and/or the pump controller 4523.
  • the communication with the other elements within the medicament pump 4520 may be via a wired connection.
  • the glucose level control system 4500 can represent one or a plurality of medicament pumps. In some embodiments, for example, the glucose level control system 4500 is in communication with a medicament pump that is to be replaced as well as an additional pump to replace that pump. However, for simplicity, reference to the medicament pump 4520 will represent one or a plurality of medicament pumps.
  • the medicament pump 4520 may be any medicament pump described herein, such as the AMD 100 and/or the pump 212.
  • the medicament pump 4520 is a medicament pump coupled to the subject during in-patient therapy delivery.
  • the pump controller 4523 is configured to direct medicament from a medicament reservoir to the subject using the pump mechanism 4522.
  • the data interface 4516 may be able to communicate (e.g., wirelessly, via wired connection) with a medicament pump 4520, a network 4524, and/or a user device 4528 via respective connections 4532, 4536, 4540.
  • the data interface 4516 can communicate with the medicament pump 4520, such as via a wireless connection.
  • the medicament pump 4520 can include a pump mechanism 4522 and a pump controller 4523. In some embodiments, the data interface 4516 communicates with the pump controller 4523 of the medicament pump 4520.
  • the network 4524 may include any wired network, wireless network, or combination thereof.
  • the network 4524 may be a personal area network, local area network, wide area network, over-the-air broadcast network (e.g., for radio or television), cable network, satellite network, cellular telephone network, or combination thereof.
  • the network 4524 may be a publicly accessible network of linked networks, possibly operated by various distinct parties, such as the Internet.
  • the network 4524 may be a private or semi-private network, such as a corporate or university intranet.
  • the network 4524 may include one or more wireless networks, such as a Global System for Mobile Communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Long Term Evolution (LTE) network, or any other type of wireless network.
  • GSM Global System for Mobile Communications
  • CDMA Code Division Multiple Access
  • LTE Long Term Evolution
  • the network 4524 can use protocols and components for communicating via the Internet or any of the other aforementioned types of networks.
  • the protocols used by the network 4524 may include Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), Message Queue Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and the like. Protocols and components for communicating via the Internet or any of the other aforementioned types of communication networks are well known to those skilled in the art and, thus, are not described in more detail herein.
  • the network 4524 may comprise the “cloud.”
  • the network 4524 may include a remote computing environment.
  • FIG. 45 Various example user devices 4528 are shown in FIG. 45, including a desktop computer, a laptop, and a mobile phone, each provided by way of illustration only.
  • the user devices 4528 can be any computing device such as a desktop, laptop or tablet computer, personal computer, tablet computer, wearable computer, server, personal digital assistant (PDA), PDM, hybrid PDA/mobile phone, mobile phone, smartphone, set top box, voice command device, digital media player, and the like.
  • PDA personal digital assistant
  • a user device 4528 may execute an application (e.g., a browser, a stand-alone application) that allows a user to access and interact with interactive graphical user interfaces as described herein.
  • an application e.g., a browser, a stand-alone application
  • the glucose level control system 4500 may be configured to receive a manual therapy instruction.
  • the manual therapy instruction may include an initial dose of medicament that is to be delivered to the subject.
  • the manual therapy instruction can direct a default or basal rate of medicament delivery to the subject.
  • the glucose level control system 4500 may receive the manual therapy instruction via a manual therapy control interface.
  • the glucose level control system 4500 may include the manual therapy control interface.
  • the manual therapy control interface may be a graphical user interface.
  • the manual therapy control interface may be integrated into the glucose level control system 4500 or may be a separate element.
  • the manual therapy control interface may be integrated with the user device 4528 described above.
  • the user interface may be operatively coupled to the glucose level control system 4500 via, for example, the wireless data interface.
  • the manual therapy control interface can include a touchscreen display.
  • the touchscreen display may display a therapy modification interface for modifying therapy the subject and/or for receiving subject inputs on the therapy modification interface. Inputs on the touchscreen display may be registered by any touch technology including, but not limited to capacitive and resistive sensing.
  • the touchscreen display may be a part of a mobile computing device, such as a cellular phone, tablet, laptop, computer or the like (e.g., the user device 4528).
  • the touchscreen display may have a computing component for interpreting and executing instructions from the processor 4519. Thus, the touchscreen display can follow instructions that are directed by the processor 4519.
  • the touchscreen display may display buttons, alphanumeric characters, symbols, graphical images, animations, or videos.
  • the user interface is not a touchscreen display.
  • the user interface may comprise one or more mechanical buttons.
  • the user interface may include an alert generator, such as a light emitter, a speaker, a haptic feedback system, or other sensory alert system.
  • the glucose level control system 4500 can be configured to transmit an initial dose control signal to a pump controller of the medicament pump 4520.
  • the initial dose control signal may be configured to cause the medicament pump 4520 to infuse an initial amount of medicament into a subject.
  • This initial amount of medicament may be a regular (e.g., basal) rate of medicament.
  • the glucose level of the subject may be obtained in one or more ways. For example, a nurse or other healthcare provider may take a measurement of the glucose level by pricking the subject’s finger. This glucose measurement may be taken periodically (e.g., regularly). For example, the measurement may be taken about once per hour, about twice per hour, about three times per hour, about four times per hour, about five times per hour, or some other time.
  • the measurements may be taken at regular intervals over a time period in some cases.
  • the time period may be about an hour, about 2 hours, about 3 hours, about 4 hours, about 5 hours, about 6 hours, about 9 hours, about 12 hours, about 18 hours, about 24 hours, any time period therein, or fall within any range of times having any of those values as endpoints.
  • the time period is about an hour.
  • the measurements may be taken at irregular points after the initial dose control signal has been received by the medicament pump 4520.
  • the measurement may be manually input into an analyzer (not shown in FIG. 45.
  • the analyzer may, in some embodiments, directly relay the glucose level measurement to the glucose level control system 4500. This may be done automatically.
  • the glucose level control system 4500 can receive the glucose level of the subject via a manual input into the glucose level control system 4500 (e.g., via a manual therapy control interface).
  • the glucose level control system 4500 receives the glucose level of the subject via an automated measuring device, such as a bedside blood monitoring system.
  • the bedside blood monitoring system may include an intravenous monitoring system, such as a “keep vein open” (KVO) system configured to periodically take up the patient’s blood and monitor the glucose level.
  • KVO keep vein open
  • the monitoring system may be configured to directly transmit the glucose level of the subject to the glucose level control system 4500 once it is received.
  • the glucose level control system 4500 may be configured to receive one or more glucose level measurements of the subject.
  • a continuous glucose monitor may be coupled to the subject and may determine a glucose level of the subject, such as a glucose level of the subject within the interstitial fluid in the subcutaneous depot of the subject.
  • the CGM may determine the glucose level of the subject by receiving an electrochemical signal from the subject’s blood and/or interstitial fluid.
  • the CGM may transmit the glucose level of the subject wirelessly or via a wired connection to the glucose level control system 4500.
  • the glucose level control system 4500 can determine whether the initial dose control signal indicates health-appropriate therapy. This may be determined based at least in part on the received glucose level of the subject. For example, the glucose level control system 4500 may determine that the current rate of therapy, the subject will no longer have a glucose level that is within an acceptable range, such as that described herein. The glucose level control system 4500 may determine that the initial dose control signal does not indicate health- appropriate therapy by, for example, determining a time-varying glucose level of the subject over the time period mentioned above. Additionally or alternatively, the determination may be made by estimating an amount of insulin in the subject.
  • Estimating the amount of insulin in the subject may include determining an amount of insulin delivered to the subject. If the total amount of insulin delivered to the subject is known, the glucose level control system 4500 may be able to estimate what an approximate glucose level of the subject may be, based on other factors already known by the glucose level control system 4500, such as those described above. Additionally or alternatively, the glucose level control system 4500 may estimate the amount of insulin in the subject by determining a rate of insulin absorption in the subject. This rate of insulin absorption may be calculated using values previously measured and then received by the glucose level control system 4500. Additionally or alternatively, the rate of insulin absorption may be received by a manual input by a healthcare provider via the manual therapy control interface. The glucose level control system 4500 may receive additional information in determining whether the subject is receiving health-appropriate therapy. Such additional information may include a weight of the subject.
  • the glucose level control system 4500 may determine that the initial amount of medicament is either insufficient or more than is needed by the subject. This determination may cause the glucose level control system 4500 to determine that modified therapy should be delivered to the subject. In some embodiments, the glucose level control system 4500 can determine maximum time within which the modified therapy must be given. In some cases, if the maximum time is less than a threshold time, the glucose level control system 4500 may be configured to generate an emergency dose control signal.
  • the threshold time may refer to an amount of time that can elapse before the patient may suffer injury or pain. Additionally or alternatively, the threshold may indicate a time within which the glucose control therapy must be modified before future pain or injury of the subject can be avoided.
  • the emergency dose control signal can be configured to command administration of modified glucose control therapy to the subject via the medicament pump 4520.
  • the emergency dose control signal may be configured to command administration of medicament (e.g., insulin) at a lower rate of therapy than was commanded by the initial dose control signal.
  • the emergency dose control signal is configured to command administration of medicament (e.g., glucagon) at a higher rate of therapy than was commanded by the initial dose control signal.
  • the glucose level control system 4500 determines that the initial dose control signal does not indicate health-appropriate therapy based on the manual therapy instruction discussed above.
  • the glucose level control system 4500 may modify (e.g., override) the manual therapy instruction based on the determination that initial amount of medicament is insufficient to provide health- appropriate therapy to the subject.
  • the glucose level control system 4500 may temporarily override the manual therapy instructions.
  • the override may be over an override time period.
  • the override time period may be on the order of minutes or hours.
  • the override timer period may be about 5 minutes, about 15 minutes, about 30 minutes, about 45 minutes, about an hour, about 2 hours, about 3 hours, about 6 hours, about 12 hours, any value therein, or fall within a range having endpoint therein.
  • the glucose level control system 4500 can transmit the emergency dose control signal to the pump controller 4523 of the medicament pump 4520.
  • the glucose level control system 4500 can be configured to receive additional data relevant to the care of the subject.
  • the glucose level control system 4500 may receive a rate of insulin delivered to the subject. This may include an amount of insulin that is delivered at a regular rate and/or a bolus of insulin delivered to the subject.
  • the glucose level control system 4500 may receive a rate of dextrose delivered to the subject and/or a rate of saline delivered to the subject.
  • the glucose level control system 4500 can receive a rate of glucagon delivered to the subject. These data may be input by a healthcare provider (e.g., via the manual control therapy interface).
  • these data may be transmitted automatically to the glucose level control system 4500 by an analyzer.
  • the glucose level control system 4500 is configured to receive a rate of nutrition delivered to the subject. This rate of nutrition may be received via the manual therapy control interface. Other data receivable by the glucose level control system 4500 are described below.
  • the glucose level control system 4500 can transmit via the data interface 4516 data to a graphical user interface.
  • the glucose level control system 4500 may transmit a glucose level of the subject, glucose control therapy data (e.g., a time and/or amount of delivered medicament), one or more glucose control parameters, an indication of the glucose trend of the subject, and/or other similar data to the graphical user interface for display.
  • the data may be transmitted to a remote device, such as a user device 4528 and/or the network 4524, via a corresponding connection 4536, 4540.
  • the glucose level control system 4500 can receive, store, and/or transmit one or more glucose control parameters to the one or more devices illustrated, such as the medicament pump 4520 (e.g., the medicament pump to be replaced, a replacement medicament pump), the user device 4528, and/or the network 4524.
  • the medicament pump 4520 e.g., the medicament pump to be replaced, a replacement medicament pump
  • the user device 4528 e.g., the user device 4528
  • example glucose control parameters can include a variety of parameters.
  • glucose control parameters includes, but is not limited to: an insulin decay rate constant associated with a decay rate of insulin at a subcutaneous depot of the subject, a clearance time associated with an estimate of an amount of time for a bolus of insulin to be utilized by the subject, an insulin rise rate constant associated with a rise rate of insulin in blood of the subject after a bolus of insulin, a value (e.g., half-life value) associated with when a concentration of insulin in blood plasma of the subject reaches a threshold concentration (e.g., half, maximum) in the blood plasma, a weight of the subject, an age of the subject, a learned parameter (e.g., via a control algorithm described herein), glucose level data of the subject, a model parameter associated with a pharmacokinetic (PK) model, a health state of the subject (e.g., sick, pregnant, etc.), a parameter associated with an activity level of the subject, an aspect of a diet of the subject (e.g., smoker), a bas
  • the glucose level control system 4500 can receive various data related to an amount of insulin on board and/or a value used in a pharmacokinetic (PK) model of the control algorithm described above.
  • the glucose level control system 4500 may be configured to execute the control algorithm in some embodiments.
  • the glucose control therapy data may include the amount of insulin on board and/or the value used in the PK model. [0483] If the glucose level control system 4500 determines that the therapy delivery
  • the glucose level control system 4500 can generate (e.g., automatically) a user alert that indicates that additional delivery of medicament may be necessary or that the therapy delivery should be modified.
  • the user alert may include any type of alert.
  • the alert may be a visual alert (e.g., a light or changing light), an audible alert (e.g., a beep or series of beeps), a haptic or vibration alert, an email alert, a text alert, or any other type of alert.
  • the user alert is dismissible and/or may be snoozed by the user.
  • the alert may be different for an emergency alert (e.g., if the maximum time is less than the threshold time described above) compared to a standard alert (e.g., if the maximum time is greater than or equal to the threshold time).
  • Alerts may vary based on when falling below or rising above the threshold time was detected, the time of day, or the detected activity of a subject (e.g., sleep, abnormal activity, or elevated activity).
  • the alert frequency may be for a static time period (e.g., every 5 hours) or may ramp towards more frequency (e.g., every 5 hrs for 1 to 3 reminders, every 4 hours for 3 to 6 reminders, etc.), or may change based on time of day, etc.
  • the alert may prompt the healthcare provider to modify the therapy that is delivered to the subject.
  • the alert can recommend an amount of therapy to be delivered and/or an indication of an estimated time before the current level of therapy raises an urgent or critical medical situation.
  • the glucose level control system 4500 can be configured to receive a request for modifying the therapy delivered to the subject.
  • the request may be made by a user via user interaction with a manual therapy control interface, such as one described herein.
  • the request may be made via a gesture, such as a movement of the eye and/or finger.
  • the input is received via a touchscreen interface.
  • the touchscreen interface is part of a separate device, such as the user device 4528 and/or the glucose sensor described herein.
  • the request may include an amount of medicament to be delivered, a time for the medicament delivery to begin, a time for the medicament delivery to end, a rate of medicament delivery, a record of the current/previous medicament delivery (e.g., total medicament delivered, rate of delivery, time of start of previous medicament delivery), and/or some other request.
  • the glucose level control system 4500 can propose to the user one of the request options mentioned above (e.g., an amount and/or time of medicament to be delivered), allowing the user to confirm or decline the option. Such recommendations can help a user (e.g., the healthcare provider) make a correct input and to avoid user error.
  • FIG. 46 shows a flow diagram illustrating an example method 4600 that may be used by a control system (e.g., the glucose level control system 4500) to generate an emergency dose control signal for commanding administration of modified glucose control therapy to a subject via a medicament pump.
  • the system can receive a manual therapy instruction at block 4604.
  • the system transmits an initial dose control signal to a pump controller of a medicament pump.
  • the glucose control parameter can include one or more of the glucose control parameters described above.
  • the system receives a glucose level of the subject.
  • the system determines that the initial dose control signal does not indicate health-appropriate therapy.
  • the system generates an emergency dose control signal for commanding administration of modified glucose control therapy to the subject via the medicament pump.
  • the system modifies the manual therapy instruction and transmits the emergency dose control signal to the pump controller of the medicament pump. Other details related to these steps are described above.
  • FIG. 47 illustrates another example of an automated glucose control system 4710 for regulating the glucose level of an animal subject (subject) 4712, which may be a human.
  • the automated glucose control system 4710 is an example of a medicament infusion system and may include any of the embodiments previously described above with respect to medicament infusion systems.
  • the subject 4712 may receive doses of insulin from one or more delivery devices 4714, for example infusion pump(s) coupled by catheter(s) to a subcutaneous space of the subject 4712.
  • the delivery devices 4714 may also deliver a counter- regulatory agent or hyperglycemic agent, such as glucagon or dextrose, for control of the glucose level under certain circumstances.
  • a counter- regulatory agent e.g., glucagon
  • the delivery devices 4714 may be mechanically driven infusion mechanisms having dual cartridges for insulin and the counter-regulatory agent, respectively.
  • insulin in the present description, reference is made to glucagon specifically, but it is to be understood that this is for convenience only and that other counter-regulatory agents (e.g., dextrose) may be used.
  • other counter-regulatory agents e.g., dextrose
  • insulin analogs commonly referred to as “insulin analogs”.
  • a glucose sensor 4716 is operatively coupled to the subject 4712 to continually sample a glucose level of the subject 4712.
  • the glucose sensor 4716 may be referred to as a continuous glucose monitoring (CGM) sensor, which may continuously or periodically measure or sense glucose levels of the subject 4712 for at least a period of time. Sensing may be accomplished in a variety of ways, generally involving some form of physical coupling 4721 between the subject 4712 and the glucose sensor 4716.
  • CGM continuous glucose monitoring
  • a controller 4718 may control operation of the delivery device(s) 4714 as a function of a glucose level signal 4719 from the glucose sensor 4716 and subject to programmed input parameters (P ARAMS) 4720 which may be provided by a user such as the subject 4712, a parent or guardian of the subject 4712, or a healthcare provider (e.g., a clinician or doctor).
  • P ARAMS programmed input parameters
  • One input parameter for automatic operation may include the weight of the subject 4712.
  • the glucose control system 4710 can provide effective automated control without receiving explicit information regarding either meals that the subject 4712 has ingested or any other “feedforward” information, which is achieved in part by an adaptive aspect to operation of the controller 4718.
  • the glucose control system 4710 can use received information regarding either meals that the subject ingested, or plans to ingest, or other “feedforward” information to modify control of glucose level (e.g., blood glucose level) and/or delivery of insulin or counter-regulatory agent.
  • glucose level e.g., blood glucose level
  • other “feedforward” information to modify control of glucose level (e.g., blood glucose level) and/or delivery of insulin or counter-regulatory agent.
  • the controller 4718 is an electrical device with control circuitry that provides operating functionality as described herein.
  • the controller 4718 may be realized as a computerized device (e.g., a hardware processor) having computer instruction processing circuitry that executes one or more computer programs each including respective sets of computer instructions.
  • the processing circuitry will generally include one or more processors 4730 along with memory 4740 and input/output circuitry 4732 coupled to or in communication with the processor(s) 4730, where the memory 4740 stores computer program instructions and data, and the input/output circuitry 4732 can provide interface(s) to external devices such as the glucose sensor 4716 and delivery device(s) 4714.
  • the input/output circuitry 4732 may provide a user interface, or may operate with one or more processors (e.g., the controller 4718 or a separate processor 4730 included in the glucose control system 4710 or in a separate computing system, such as a smartphone, a laptop computer, a desktop computer, a smartwatch, and the like) to provide a user interface to a user (e.g., the subject 4712, a parent or guardian, or a clinician).
  • the input/output circuitry 4732 may include a touchscreen and/or a touchscreen controller 4738 configured to control a touchscreen (not shown).
  • the controller 4718 may perform all of the functionality of the glucose level control system 4710. In such cases, the processor 4730 may be optional or omitted. In some cases, the controller 4718 may perform at least automated glucose level control of the subject 4712, and one or more separate processors 4730 may perform one or more additional operations of the glucose level control system 4710 (or medicament pump), such as tracking occurrences of hyperglycemic or hypoglycemic events or risk events, outputting data to a user, controlling or initiating communication with another computing system, regulating access to the glucose level control system 4710, or other operations unrelated to operation of a medicament pump or the delivery devices 4714.
  • the glucose level control system 4710 or medicament pump
  • the input/output circuitry 4732 may control communication with one or more other computing systems and/or with a user.
  • the input/output circuitry 4732 may include one or more separate interface circuits or controllers to facilitate user interaction and/or communication.
  • the input/output circuitry 4732 may include user interface circuitry 4734, network interface circuitry 4736, and/or a touchscreen controller 4738.
  • the user interface circuitry 4734 may include any circuitry or processors that may output a user interface to a user and/or receive user input from the user via the user interface.
  • the user interface circuitry 4734 may receive one or more signals from a processor 4730 corresponding to a user interface.
  • the user interface circuitry 4734 may control a display to present the user interface to a user based on the one or more signals received from the processor 4730.
  • the user interface circuitry 4734 may include any circuitry that can receive a signal corresponding to an interaction by a user with a user interface and can provide the signal to the processor 4730 and/or controller 4718 for further processing.
  • the user interface circuitry may be replaced by a touchscreen controller 4738 that can control a touchscreen interface.
  • the touchscreen controller 4738 may be in addition to the user interface circuitry 4734.
  • the network interface circuitry 4736 may include any circuitry that enables communication with a wired or wireless network.
  • the network interface circuitry 4736 may include one or more network interface cards and/or wireless radios (e.g., a Bluetooth radio, a Bluetooth Low Energy (BLE) radio, a 4g LTE radio, a 5G radio, a ND-LTE radio, and the like).
  • wireless radios e.g., a Bluetooth radio, a Bluetooth Low Energy (BLE) radio, a 4g LTE radio, a 5G radio, a ND-LTE radio, and the like.
  • the memory 4740 can include non-volatile memory and/or volatile memory.
  • the non-volatile memory may include flash memory or solid-state memory.
  • the control system 4710 is also able to operate in an offline manner in which it is used to provide delivery of insulin (and potentially glucagon as well), independent of or without receipt of glucose levels reported by the sensor 4716.
  • the glucose control system 4710 may operate in an offline manner without input from the sensor 4716.
  • overall operation may be divided between online periods each including a succession of sampling intervals when a glucose signal (level) 4719 is available, and offline periods each including a succession of sampling intervals when the glucose signal (level) 4719 is either completely or intermittently unavailable.
  • online and “offline” for these periods.
  • offline operation may be user-selected for some reason even when a glucose level signal 4719 is available for use.
  • User control inputs may be provided via a local or remote user interface of some type.
  • the user interface may resemble that of conventional insulin pumps or similar devices, e.g., by including control buttons for commanding the delivery of a bolus and perhaps a small display.
  • the system may have a wired or wireless interface to a remote device that may incorporate a fuller- function user interface, such as a smartphone, smartwatch, laptop computer, desktop computer, cloud computing service, or other wearable device or computing device.
  • the wireless interface may provide access to a local area network, such as a personal home network, a company network, or otherwise.
  • the wireless interface may provide a direct connection between local devices available to a user (e.g., via Bluetooth or other near field communication technologies).
  • the wireless interface may provide access to a wide area network, such as, but not limited to, the Internet.
  • the wireless interface may include a cellular interface that permits access to a network via a 4G or 5G cellular connection.
  • the cellular interface may be a low power interface, such as narrowband LTE or other Internet of Things (IoT) interfaces.
  • IoT Internet of Things
  • the glucose sensor 4716 may be absent, non-functioning, or not coupled to the subject 4712. As such, in offline mode, the glucose level signal 4719 may not be available to control automatic operation.
  • a user may provide one or more glucose level measurements to the control system 4710 to facilitate automatic operation of the control system 4710. These measurements may be provided over a particular time period.
  • the glucose control system 4710 may use a therapy history and/or a history of prior glucose level control measurements to facilitate automatic operation of the control system 4710 for at least a particular time period.
  • the description herein refers to a “user” as the source of the user control inputs 4723.
  • the “user” as used herein may be the subject 4712, a parent or guardian of the subject 4712, a healthcare provider (e.g., a clinician, doctor, or other person who may provide medical care to the subject), or any other user who may be authorized to help manage therapy of the subject 4712.
  • the glucose level control system 4710 is a personal device worn by a subject 4712 for continual glucose control.
  • the user and subject 4712 may be the same person.
  • FIG. 48 shows an example structure of the controller 4718 in accordance with certain embodiments.
  • the controller 4718 illustrated in FIG. 48 may represent a physical structure with different controllers or processors, or a logical structure that is implemented by one or more physical processors.
  • a single processor may be used to implement each of the controllers illustrated in FIG. 48, each controller may be implemented by its own processor, or certain processors may implement multiple, but not necessarily all, of the controllers illustrated in FIG. 48 as part of the controller 4718.
  • the controllers of FIG. 48 are illustrated as part of the controller 4718, in some implementations, one or more of the controllers may be separate from the controller 4718.
  • the controller 4718 may include four separate controllers, namely a glucagon (or counter-regulatory agent) controller 4822, a basal insulin controller 4824, a corrective insulin controller 4826, and a priming insulin controller 4828.
  • the basal insulin controller 4824 includes a nominal rate controller 4830 and a modulating controller 4832.
  • the glucagon controller 4822 generates a glucagon dose control signal 4834 provided to a glucagon delivery device 4714-1.
  • Respective outputs 4836-4840 from the controllers 4824-4828 may be combined to form an overall insulin dose control signal 4842 provided to insulin delivery device(s) 4714-2.
  • the output signal 4836 from the basal insulin controller 4824 may be formed by a combination of respective outputs of the nominal rate controller 4830 and a modulating controller 4832.
  • the insulin delivery device(s) 4714-2 may include devices tailored to deliver different types and/or quantities of insulin, and the exact configuration may be known to and/or under the control of the controllers 4824-4828.
  • the collection of one or more insulin delivery devices 4714-2 is referred below to in the singular as an insulin delivery device 4714-2.
  • FIG. 48 Also shown in FIG. 48 are input/output signals of the various controllers, including the glucose level signal 4719, parameters 4720 and user control inputs 4723 as well as a set of inter-controller signals 4844.
  • the inter-controller signals 4844 enable communication of information from one controller, where the information is developed or generated, to another controller where the information may be used for that controller's control function.
  • the controllers 4822-4828 may be operated in either the online/automatic mode or in the offline mode. In the automated mode, the corrective controller 4826 regulates glucose level using a control scheme such as described in US Patent No. 7,806,854, the contents of which are hereby incorporated by reference in its entirety herein.
  • the basal controller 4824 and priming insulin controller 4828 may perform adaptive automated control as described in International Patent Application Publication WO 2012/058694 A2, the contents of which are hereby incorporated by reference in its entirety herein.
  • the controllers 4822-4828 generally employ control methods or algorithms that include control parameters that are mathematically combined with reported glucose values to generate an output value that is converted (either directly or via additional conditioning) into the dose control signals 4834, 4842.
  • control scheme described in US Patent No. 7,806,854 includes a generalized predictive control (GPC) method that incorporates a variety of control parameters.
  • the control algorithms are generally adaptive, meaning that control parameters are dynamically adjusted during operation to reflect changing operating circumstances and a “learning” aspect — by monitoring its own operation, the algorithm adjusts its operation to be more specifically tailored to the individual user, enhancing the algorithm's effectiveness and reducing or avoiding a need for additional explicit input information about the user.
  • the input parameters 4720 may form part of the control parameters used by the control algorithm.
  • Other control parameters are internal parameters according to the specifics of the algorithm, and selected ones of those internal control parameters are dynamically adjusted to realize the adaptation of the control algorithm.
  • One feature of operation is the ability of the controllers to learn from recent past periods of online operation and to use that learning during offline operation.
  • a first method automatically calculates the correct size of a correction bolus of insulin at a time of receiving an isolated glucose measurement, the correction bolus then being administered by the system in response to a user control input.
  • a second method automatically calculates the correct size of a meal bolus of insulin and administers it in response to a user control input. Both methods utilize information obtained during past periods of online operation to automatically calculate correct values, freeing the user of a need to make the calculation or provide a correction factor.
  • Hyperglycemia is a condition that occurs when the levels of sugar or glucose in the blood exceeds a particular level (e.g., 180 mg/dL). This condition may occur in diabetics.
  • a subject may use an automated glucose level control system, which may automatically provide insulin to a subject using a medicament pump. The administered insulin may help control the glucose level of the subject by consuming glucose in the subject.
  • glucose level may comprise a physiological glucose level of the subject that can be a concentration of glucose in subject’s blood or an interstitial fluid in part of the subject’s body (e.g., expressed in milligram per deciliter (mg/dl)).
  • Hypoglycemia is a condition that occurs when the levels of sugar or glucose in the blood are below a particular level (e.g., 70 mg/dL). This condition may have adverse consequences including loss of consciousness, seizures, and death.
  • the levels of blood glucose that lead to hyperglycemia and hypoglycemia may vary from patient to patient.
  • a subject may consume carbohydrates to increase blood glucose. Because of the severe consequences associated with a hypoglycemic event, subjects usually consume carbohydrates that metabolize quickly. These carbohydrates are often unhealthy but are preferable to the occurrence of a hypoglycemic event.
  • the carbohydrates may include candy bars with a lot of refined sugar.
  • a bihormonal glucose-control system may reduce the risk of occurrence of hypoglycemia by including, in addition to insulin, a counter-regulatory agent (e.g., Glucagon) that can be administered to a subject when the glucose level drops too low (e.g., below 50 mg/dL).
  • a counter-regulatory agent e.g., Glucagon
  • it may be useful for subjects who do have a bihormonal glucose-control system to understand the reduction in carbohydrate therapy obtained by having the bihormonal glucose-control system.
  • understanding the amount of carbohydrate therapy consumed or avoided can be important in monitoring the subject’s nutrition intake. While monitoring nutrition in take is important for all people, it is particularly important for diabetics because diabetics must balance eating healthy with ensuring that their blood glucose is maintained in a particular range to avoid both hyperglycemia and hypoglycemia.
  • the present disclosure relates to a system that can perform a computer- implemented method of generating an indication of total carbohydrate therapy over a time period in a subject using a medicament pump configured to deliver at least insulin therapy to the subject.
  • the system may be an automated glucose level control system (e.g., the glucose level control system 4710) that includes a hardware processor (e.g., controllers 4718) for determining dose control signals to provide the medicament pump (e.g., delivery devices 4714).
  • the medicament pump may be configured to deliver both insulin therapy and counter-regulatory agent (e.g., Glucagon) therapy.
  • the system may be separate from the glucose level control system but may receive glucose level information from the glucose level control system.
  • the system may be personal computing system or a cloud computing system that can received glucose level information from the glucose level control system.
  • the system may receive or determine a glucose level of a subject (e.g., subject 4712).
  • the glucose level of the subject may be determined based on a signal (e.g., a glucose level signal) received from a continuous glucose monitoring (CGM) sensor (e.g., glucose sensor 4716) that corresponds to the glucose level of the subject.
  • CGM continuous glucose monitoring
  • the glucose level may be determined from an isolated glucose measurement, such as may be obtained using a glucose measurement kit and/or glucose paper.
  • the system can determine whether a triggering event for raising the subject’ s glucose level has occurred.
  • the triggering event may include a glucose level that indicates an occurrence of a hypoglycemic event or a risk of the occurrence of a hypoglycemic event exceeding a risk threshold within a particular period of time.
  • a risk of a hypoglycemic event may be determined when a glucose level of the subject falls below a glucose threshold. This glucose threshold may vary for different subjects and may, in some cases, be specified by the subject or a caregiver (e.g., healthcare provider, parent, or guardian).
  • the system may determine an amount of counter-regulatory agent to administer, or an amount of counter-regulatory agent that would be administered if the glucose level control system included the capability of administering a counter-regulatory agent.
  • the counter-regulatory agent is administered by, for example, the automated glucose level control system.
  • the counter-regulatory agent is not administered.
  • the automated glucose level control system may not be capable of delivering the counter-regulatory agent.
  • the automated glucose level control system may be capable of delivering the counter-regulatory agent but may not have a dose of the counter-regulatory agent available.
  • the system can use the indication of the counter-regulatory agent that is administered or that would be administered to determine a corresponding amount of carbohydrates.
  • the corresponding amount of carbohydrates may be indicative of the amount of carbohydrates that were consumed to prevent the hypoglycemic event, to reduce the risk of the hypoglycemic event, or in response to an occurrence of a hypoglycemic event.
  • the corresponding amount of carbohydrates may be indicative of the amount of carbohydrates that would have been consumed if the counter-regulatory agent were not available.
  • the corresponding amount of carbohydrates may be obtained from a mapping between amounts of a counter-regulatory agent and amounts of carbohydrates.
  • the mapping may be based on a measured equivalency between carbohydrates and a counter-regulatory agent.
  • the mapping may be between a determined amount of counter-regulatory agent and an amount of carbohydrate a subject indicates he or she normally consumes when determining that a hypoglycemic event may occur.
  • the mapping may be implemented by a lookup table that maps different amounts of counter-regulatory agent to different corresponding amounts of carbohydrates.
  • a single quantity of counter-regulatory agent may map to different amounts of carbohydrates depending on the type of carbohydrate consumed (e.g., simple vs complex carbohydrates, or the type of candy bar consumed, etc.).
  • the mapping may be based on a formula that converts an amount of counter-regulatory agent to an amount of carbohydrates based on a correspondence between the amount of counter-regulatory agent and the amount of carbohydrates.
  • the determination of a relationship between the counter- regulatory agent and carbohydrates may be based on clinical tests comparing carbohydrates to the counter-regulatory agent (e.g., Glucagon, dextrose, etc.).
  • the mapping may be based at least in part on a subject’s preferred carbohydrate source and/or characteristics of the subject (e.g., weight).
  • the system can track a number of hypoglycemic events or a number of occurrences of a trigger indicating an impending risk of a hypoglycemic event within a particular time period.
  • the time period may be days, weeks, months, years, or any other period of time over which it is desirable to determine a relationship between carbohydrates consumed or avoided based on the lack of availability or availability of a counter-regulatory agent.
  • the tracking of carbohydrate therapy may be based on a number of hypoglycemia events or hypoglycemia risk events instead of or in addition to a time period.
  • the system can determine an estimate of the carbohydrate therapy saved or that would have been saved by having access to the counter-therapy agent.
  • the system can generate a report for the time period that indicates the total carbohydrate saved or that would have been saved with access to counter-regulatory agent.
  • the report may include an aggregate or sum of the carbohydrate therapy required or saved during the time period. This time period may be days, weeks, months, years, or since a particular time (e.g., since the subject starting using the system).
  • the report may indicate the type of carbohydrates typically consumed by the subject when responding to a hypoglycemic event or a risk of an impending hypoglycemic event.
  • This report can be presented to the subject, a healthcare provider, and/or a parent or guardian of the subject.
  • the healthcare provider can use this report to help care for the subject.
  • the healthcare provider can use the report to generate a nutrition plan for the subject that accounts for the carbohydrates consumed to maintain the glucose level within a desired or setpoint range.
  • the report may include a range of carbohydrate therapy avoided or likely consumed to address the risk of hypoglycemia events. Further, the report may include an amount of calories saved or not consumed, an amount of sugar avoided, an amount of food not consumed, a likely weight gain avoided, etc. based on the use of a counter-regulatory agent in place of carbohydrate therapy.
  • FIG. 49 presents a flowchart of an example carbohydrate therapy equivalence tracking process 4900 in accordance with certain embodiments.
  • the process 700 may be performed by any system that can track the glucose level of a subject over time and identify hypoglycemic events, or occurrences when a risk of a hypoglycemic event satisfies a threshold (e.g., when the risk of the hypoglycemic event matches or is above a particular probability).
  • the process 4900 may be performed by one or more elements of the glucose level control system 4710.
  • At least certain operations of the process 4900 may be performed by a separate computing system that receives indications of glucose levels of the subject 4712 from the glucose level control system 4710 and/or indications of hypoglycemic events (or identified above threshold hypoglycemic risk events).
  • a separate computing system that receives indications of glucose levels of the subject 4712 from the glucose level control system 4710 and/or indications of hypoglycemic events (or identified above threshold hypoglycemic risk events).
  • the process 4900 begins at block 4902 where the glucose level control system 4710 receives a glucose level of a subject 4712.
  • Receiving the glucose level may include receiving a glucose level signal corresponding to a glucose level of the subject.
  • the glucose level signal may be received from the glucose sensor 4716 (e.g., a CGM sensor).
  • the glucose level may be received from a user that provides the glucose level to the glucose level control system 4710 via a user interface, such as a user interface generated by the processor 4730 that may be output on a touchscreen by the touchscreen controller 4738.
  • the glucose level received from the user may be a glucose level measured using an alternative sensor or measurement mechanism (e.g., diabetes measurement strips) that may be used in place of the glucose sensor 4716.
  • the glucose level control system 4710 determines based at least in part on the glucose level that a triggering event for raising the glucose level of the subject 4712 has occurred.
  • the triggering event may include a determination that a hypoglycemic event or an episode of hypoglycemia is present or is occurring in the subject 4712.
  • the triggering event may include a determination that there is an impending risk of hypoglycemia in the subject 4712, or an impending risk that a hypoglycemic event will occur within a particular amount of time in the subject 4712.
  • the determination of the hypoglycemic event or the risk of a hypoglycemic event occurring may be determined by comparing the glucose level of the subject to a glucose threshold.
  • the determination of the hypoglycemic event or the risk of a hypoglycemic event occurring may be determined by comparing a trend and/or rate of change (e.g., rate of decrease) in the glucose level to a threshold.
  • rate of change e.g., rate of decrease
  • the particular glucose level and the trend in the glucose level may be combined to determine a risk of hypoglycemia. For example, if the glucose level is low (e.g., below a particular threshold, such as 60 mg/dL), but a determined trend in the glucose level is upwards, then a risk of hypoglycemia may be lower than if the glucose level is above the threshold, but the determined trend in the glucose level is downwards towards a threshold.
  • the threshold(s) used to determine whether a hypoglycemic event is occurring or to determine that there is an above threshold risk of hypoglycemia occurring may vary based on physiological characteristics of the subject 4712.
  • the physiological characteristics may be based on physiological characteristics associated or shared among groups of patients (e.g., gender, age, weight) or may be specific to the particular subject 4712.
  • thresholds associated with a risk of hypoglycemia may be determined based on determined glucose levels of the subject 4712 during prior occurrences of hypoglycemia as determined by the glucose level control system 4710 or based on clinical data specific to the subject 4712.
  • the glucose level control system 4710 determines an amount of counter-regulatory agent at block 4906.
  • the glucose level control system 4710 may determine the amount of counter-regulatory agent based at least in part on the glucose level of the subject 4712, the amount or percentage of risk of hypoglycemia occurring (e.g., a 99% risk or probability of hypoglycemia may trigger a larger counter-regulatory agent dose than a 75% risk or probability of hypoglycemia), physiological characteristics of the subject 4712, a trend in the glucose level of the subject 4712, or a type of counter-regulatory agent.
  • the glucose level control system 4710 may use a delivery device 4714-1 to deliver the determined amount of counter-regulatory agent to the subject 4712.
  • the counter-regulatory agent may be delivered to the subject 4712 in response to the impending risk of hypoglycemia or the episode of hypoglycemia, and/or in response to the glucose level satisfying or falling below a threshold glucose level.
  • the threshold glucose level or the determination of whether to deliver the counter-regulatory agent may be based on physiological characteristics of the subject 4712 and/or the risk tolerance of the subject 4712 to a hypoglycemic event. It should be understood that, in the present context, risk tolerance generally does not refer to a user’s subjective propensity for risk.
  • the risk tolerance is typically an objective determination of how likely the subject 4712 is to have a hypoglycemic event, or for symptoms of hypoglycemia to occur, when the glucose level of the subject 4712 is at a particular level.
  • This risk tolerance may be determined based on a history of hypoglycemia, or lack thereof, in the subject 4712 at particular glucose levels and/or based on clinical data obtained for the subject 4712.
  • the glucose level control system 4710 may not deliver counter-regulatory agent to the subject 4712 because, for example, the glucose control system 4710 may not be capable of delivering counter-regulatory agent or because the cartridge holding the counter-regulatory agent may be empty or have less than a threshold amount of counter-regulatory agent remaining.
  • the glucose level control system 4710 determines a dose of carbohydrate therapy based at least in part on the counter-regulatory agent.
  • the carbohydrate therapy may refer to carbohydrates consumed to prevent or respond to an occurrence of hypoglycemia.
  • the carbohydrates may include any type of carbohydrate that the subject 4712 may consume to prevent or respond to an occurrence of hypoglycemia, and typically includes fast-acting carbohydrates, which may include sugary foods that are easily converted into sugars in the human body.
  • the carbohydrate may be a candy bar, soda, fruit juice, or other foods that may have a lot of sugar or refined sugars.
  • Determining the dose of carbohydrate therapy may include accessing a mapping between the counter-regulatory agent and carbohydrates. This mapping may be stored in, and accessed from, the memory 4740 and/or may be accessed from another computing device.
  • the glucose level control system 4710 may determine the dose of carbohydrate therapy based at least in part on the mapping and the amount of the counter-regulatory agent. In some cases, the mapping may vary based on the type of counter-regulatory agent and/or the type of carbohydrates.
  • the type of counter-regulatory agent may be identified by a user or may automatically be determined based on a medicament cartridge installed or inserted into the glucose level control system 4710.
  • the type of carbohydrates may be specified by a user and may include an identity of the type of carbohydrates usually consumed by the subject 4712 when responding to an occurrence or a risk of an occurrence of hypoglycemia.
  • the user may specify, via a user interface, whether the subject usually consumes a candy bar or fruit juice, or the size of the carbohydrate usually consumed when responding to an occurrence or a risk of an occurrence of hypoglycemia.
  • the mapping between the counter-regulatory agent and carbohydrates may be generated based on a clinical comparison of the counter-regulatory agent to the carbohydrates. Alternatively, or in addition, the mapping may be based at least in part on a physiological characteristic of the subject 4712.
  • the mapping may be stored in a lookup table or other data structure that can store relationships between different carbohydrates and counter-regulatory agents.
  • the mapping may be between different quantities and/or types of carbohydrates and different quantities and/or types of counter-regulatory agent.
  • the mapping may be a formula that relates the carbohydrates to the counter-regulatory agent or vice versa.
  • the glucose level control system 4710 may use the determined amount of counter- regulatory agent as an index to a lookup table to determine a corresponding quantity of carbohydrates.
  • the glucose control system 4710 may apply the determined amount of counter-regulatory agent to a formula to calculate a corresponding quantity of carbohydrates. This formula may be generated based on the type of counter-regulatory agent and/or carbohydrates, physiological characteristics of the user, and/or clinical data.
  • the mapping may vary based on the glucose level control system 4710.
  • the glucose level control system 4710 may include a first mapping when the glucose level control system 4710 (or medicament pump thereof) is a bi-hormonal pump configured to deliver insulin and counter-regulatory agent therapy to the subject, and may include a second mapping when the glucose level control system 4710 is not configured to deliver the counter-regulatory agent therapy to the subject 4712.
  • the glucose level control system 4710 may store both mappings in the memory 4740. For example, the glucose level control system 4710 may use the first mapping when counter-regulatory agent is available and may use the second mapping when counter-regulatory agent is not available.
  • mappings may vary for a number of reasons including because a bi-hormonal glucose level control system 4710 may more precisely control the occurrence of hypoglycemic events due to the availability of counter-regulatory agent, which may therefore alter the frequency and type of carbohydrates that a subject may consume.
  • the glucose level control system 4710 outputs an indication of the dose of carbohydrate therapy.
  • Outputting the indication of the dose of carbohydrate therapy may include outputting an indication of the dose of carbohydrate therapy on a display for presentation to a user.
  • the indication of the dose of carbohydrate therapy may be transmitted to another computing system for display or aggregation with other therapy data associated with the subject 4712, such as therapy data used by a clinician to help manager the subject’s 4712 care.
  • the indication of the dose of carbohydrate therapy may be included in a report corresponding to care of the subject 4712.
  • the operations of the process 4900 are performed or repeated over a period of time.
  • the operations associated with the block 4902- 4908 may be repeated one or more times over the period of time.
  • the determined doses of carbohydrate therapy may be aggregated for the period of time to determine a total carbohydrate therapy for the period of time.
  • the block 4910 may include outputting an indication of the dose of carbohydrate therapy for each individual time that a dose of carbohydrate therapy is determined and/or the aggregated determined doses of carbohydrate therapy for the period of time.
  • the period of time may be any time period.
  • the period of time may be a day, week, month, year, since the subject 4712 began using the glucose level control system 4710, since a user obtained or ceased obtaining access to a counter- regulatory agent, or any other period of time.
  • the period of time is defined by the occurrences of hypoglycemic events or occurrences of the risk of hypoglycemia satisfying a threshold.
  • the period of time may be the time associated with 5, 10, 15, 100, or any other number of hypoglycemic events or occurrences of the risk of hypoglycemia satisfying a threshold.
  • the indication of total carbohydrate therapy may correspond to a reduction in carbohydrates consumed by the subject 4712 because, for example, of the availability of counter-regulatory agent to the glucose level control system 4710, and consequently, the subject 4712.
  • the indication of total carbohydrate therapy may correspond to a reduction in carbohydrates achievable by an availability to the subject 4712 of the counter-regulatory agent.
  • the indication of total carbohydrate therapy may correspond to an amount of counter-regulatory agent provided or that can be provided to the subject as a substitute for carbohydrates.
  • the particular carbohydrates consumed, or the amount of carbohydrates consumed by each subject or during each hypoglycemic event may vary.
  • a subject 4712 may consume a particular candy bar when the subject’s 4712 measured glucose level is too low or when the subject feels that the blood glucose level is likely low (e.g., begins to feel some hypoglycemic effects).
  • the subject may consume the whole candy bar or may consume a portion. Some of the candy bar may be lost to the subject (e.g., fall on the ground).
  • the subject may have different candy bars available, or other refined sugar sources, during different hypoglycemic events.
  • the amount of carbohydrates consumed or avoided due to the availability of counter-regulatory agent may vary for each hypoglycemic event. Accordingly, the indication of total carbohydrate therapy avoided, or that could be avoided if counter-regulatory agent were available, may indicate a range of carbohydrates that may potentially be replaced by the availability of counter-regulatory agent.
  • the indication of carbohydrate therapy or total carbohydrate therapy may include one or more of an indication of calories, an indication of carbohydrates, an indication of a measure of sugar, an indication of a quantity of food, or an indication of weight of the subject attributable to the carbohydrate therapy.
  • the indications may be associated with what is consumed due to a lack of counter-regulatory agent, or what is avoided based on the availability of counter-regulatory agent.
  • the indication of calories may be the number of calories not consumed because of the presence of the counter-regulatory agent.
  • the availability of therapy information relating to the carbohydrate therapy or avoided carbohydrate therapy can assist in patient care. For example, a subject can reduce refined sugar consumption that can have a number of health consequences. Further, a healthcare provider can better help a subject control his or her weight based on the carbohydrate information.
  • the indication of carbohydrate therapy may be presented to a user in any presentable form.
  • the indication of carbohydrate therapy may be presented as a table, a chart, a graph, a histogram, or other data presentation tool for indicating the reduction in carbohydrates over time that is achieved by the presence of counter-regulatory agent or that could be achieved by the use of counter-regulatory agent for the particular subject 4712.
  • the indication of carbohydrate therapy data may vary for different users due to differences in physiological characteristics of the users, differences in the diabetes of each user, differences in lifestyle of each user, among other factors.
  • management of the subject’s 4712 glucose level can be personalized.
  • Certain embodiments of the present disclosure relate to a method for translating an amount of online counter-regulatory dosing (e.g. glucagon) computed by an autonomous glucose-control system to an amount of carbohydrates that the user is estimated to have been spared from needing by virtue of the counter-regulatory dosing, or that the user would be spaced from needing if the user had access to the counter-regulatory agent.
  • an amount of online counter-regulatory dosing e.g. glucagon
  • the method may include a mapping between the online counter- regulatory dosing, which was delivered to treat or prevent low glucose levels, and oral carbohydrates that are estimated to have otherwise been required to achieve a comparable safe control situation (had the counter-regulatory dosing not been delivered).
  • the method may include a mapping between the computed online counter-regulatory dosing and an estimated amount of oral carbohydrates that the subject will likely have been spared from needing to consume to treat or prevent low glucose levels had the counter-regulatory agent been available and its doses actually delivered.
  • embodiments disclosed herein include an autonomous glucose-control system where the counter-regulatory agent is glucagon.
  • the counter-regulatory agent is glucagon.
  • the method may include relating computed online glucagon dosing with consumed oral carbohydrates for the treatment or prevention of low glucose levels (“treatment carbs”) as observed in real use (e.g., during clinical studies) in the insulin-only configuration, and relating the relationship between the counter-regulatory agent and carbohydrates to a similar relationship between delivered online glucagon doses (or other counter-regulatory agent) and similarly consumed oral carbohydrates in the bihormonal (insulin-glucagon) configuration.
  • Ci 0 Ri o (x) * Gc
  • Ri 0 (x) may be a relating factor that can be a function of several dependencies that are included in vector x.
  • dependencies can include the specific insulin and/or glucagon being used (e.g., their clinical properties), and/or the pharmacokinetic settings assumed by the control system in relation to insulin and/or glucagon.
  • the dependencies can also include the user’s body mass and the glucose target used by the glucose-control system.
  • Rio(x) may be a constant, or Rio(x) o Rio, for a system exhibiting limited variation in the relationship between Ci 0 and G c (e.g., due to limited effect, or limited or no variation in the associated dependencies).
  • the quantities Ci 0 , G c , C bh , and G d can refer to daily amounts, as averaged over some period of use (e.g., a week).
  • the quantities Ci 0 , G c , C bh , and G d can refer to average daily amounts per body mass of the user, in which case dependency on body mass can be eliminated from x.
  • G c In cases where G c is computed, but no glucagon is actually delivered in an insulin-only system, G c has no effect on glucose insofar as treating or preventing low glucose levels, which in turn is generally expected to invoke further computed glucagon dosing (e.g., goes towards increasing the magnitude of G d for a given situation).
  • G d since G d is delivered in a bihormonal system, it is expected to have an effect in preventing or reducing the frequency, extent, or duration of low glucose levels, which in turn is expected to limit the overall magnitude of glucagon dosing (e.g., limits G d for a given situation).
  • real-use cases where the insulin-only system is used can be re-simulated while assuming a bihormonal system is available, where glucagon is assumed to be delivered. Since the control system may take delivered doses into account when issuing subsequent nearby glucagon doses, the simulated glucagon dosing may exhibit a reduction relative to the original G c of the insulin-only system. With the glucose profile kept unaltered in a simulation, the simulation may lack reflecting any resulting glucose excursions in response to the assumed delivered glucagon dosing. The simulation in turn may lack reflecting the full reduction in glucagon dosing down to G d that may have been observed if the glucose excursions had in fact benefited from glucagon being delivered.
  • the reduced glucagon dosing that is observed in the simulation, pseudo delivered glucagon G d may arguably be exaggerated in magnitude relative to what would have been the “real G d ”.
  • G c can be mapped to a corresponding amount Ci 0 in the insulin-only configuration
  • G d can be mapped to a corresponding amount C bh in the bihormonal configuration.
  • the simulation results therefore, can map the reduction “G c - G d ” to an estimate “Ci 0 - C bh ” of treatment carbs that the user would spare had they been using the bihormonal system.
  • the estimates may be conservative estimates.
  • mapping can be utilized when a bihormonal system is being used, where the observed dosing G d is mapped back to a pseudo computed glucagon G c and the resulting associated difference “C 10- C bh ” provides a (in some cases, conservative) estimate of the treatment carbs that the user had likely saved by virtue of being on the bihormonal system.
  • Certain embodiments includes a system that comprises a controller for automatic control of a glucose level of a subject.
  • the controller may be operative to generate an insulin dose control signal based on time-varying glucose levels of the subject as represented by a glucose level signal over time.
  • the glucose level signal can be generated by a glucose sensor operative to continually sense a glucose level of the subject.
  • the insulin dose control signal may control the delivery of doses of insulin by a delivery device.
  • the controller can operate at a regular frequency to generate an insulin dose control signal to regulate the glucose levels in the subject.
  • the controller can employ a control algorithm that generates a glucagon dosing signal, which may be mapped to an associated amount of oral carbohydrates.
  • the oral carbohydrates may be associated with the prevention or treatment of low glucose levels. Further, the mapping between the glucagon dosing signal and the oral carbohydrates may be derived from analysis of clinical data.
  • the glucagon dosing signal may be computed, but not delivered in an insulin-only system configuration.
  • the glucagon dosing signal can be computed, and glucagon can be delivered in an insulin-glucagon system configuration.
  • the computed glucagon dosing in an insulin-only system configuration can be mapped to an amount of oral carbohydrates that is estimated to have been saved had glucagon dosing been delivered if an insulin-glucagon system configuration had instead been used.
  • the delivered glucagon dosing in an insulin-glucagon system configuration can be mapped to an amount of oral carbohydrates that is estimated to have been saved if an insulin- only system configuration had instead been used.
  • the mapping may be dependent on the clinical properties of the insulin and glucagon being used, and settings in the control system related to the action and effect of insulin and glucagon. Further, the mapping may be dependent on the subject’s body mass.
  • An ambulatory medicament device such as a glucose level control system (e.g., an insulin pump or a combined insulin and counter-regulatory agent (e.g., Glucagon) pump), can provide personalized therapy to a subject.
  • the ambulatory medicament device may provide medicament that is specific to a subject’s physiology, condition, activity, and the like. Further, some ambulatory medicament device’s monitor a condition of the subject to determine when to provide therapy, what type of therapy to provide (e.g., insulin or counter-regulatory agent therapy), and/or how much therapy to provide.
  • the therapy provided by the ambulatory medicament device may be ongoing and, in some cases, lifesaving. Thus, it is important that ambulatory medicament device function uninterrupted.
  • the ambulatory medicament device may break, a subject may run out of or not have access to a necessary disposable (e.g., a replacement insulin cartridge, a site kit for changing the site of the ambulatory medicament device, a replacement battery, and the like), or the subject may forget to charge a battery of the ambulatory medicament device or not be in a location where a power source is available to charge the ambulatory medicament device.
  • a necessary disposable e.g., a replacement insulin cartridge, a site kit for changing the site of the ambulatory medicament device, a replacement battery, and the like
  • the subject may forget to charge a battery of the ambulatory medicament device or not be in a location where a power source is available to charge the ambulatory medicament device.
  • the ambulatory medicament device may not be available or may need replacing.
  • the ambulatory medicament device When the ambulatory medicament device is not available, or when a replacement (temporary or permanent) ambulatory medicament device is being used, it may be desirable to have an indication of the therapy settings from the ambulatory medicament device. For example, if a user (e.g., a subject, healthcare provider, parent, or guardian) is providing alternative therapy (e.g., injection therapy) while the ambulatory medicament device, it may be necessary to know the quantity of therapy to provide under particular circumstances or at particular times.
  • alternative therapy e.g., injection therapy
  • a healthcare provider may have access to therapy information that may have been previously determined, for example, via clinical testing.
  • This therapy information may include any type of information that can be used to determine therapy to provide to a subject at a particular time or under particular conditions.
  • the therapy information may indicate a setpoint insulin range for the subject, a quantity of insulin to provide to the user to adjust glucose levels, an amount of time for insulin to reach max concentration in the subject, or any other information that might impact the timing or amount of dosing of a medicament.
  • the therapy information available to the healthcare provider may be insufficient.
  • the subject may not be able to reach the healthcare provider to obtain the therapy information at a point in time when the information is needed.
  • the information may be outdated because, for example, the ambulatory medicament device may have refined the therapy over time. If the refinements have occurred recently, it is possible that the outdated values of the healthcare provider may be sufficient until a replacement ambulatory medicament device can repeat the refinement process of the original ambulatory medicament device.
  • the outdated therapy information may be insufficient because, for example, the refinements were significant or the subject may have had physiological changes (e.g., weight gain or weight loss, or metabolism changes) since the last time a clinical test was performed. Using outdated therapy information may be less effective and may cause discomfort or harm to a subject.
  • Certain embodiments of a system disclosed herein can generate backup therapy data.
  • a subject or user
  • the subject can maintain a level of therapy care that matches or more closely matches what was being provided by the ambulatory medicament device than clinical data, which may be outdated if available at all.
  • the system can include an automated glucose level control system (e.g., the glucose level control system 4710) configured to generate a backup therapy protocol comprising insulin therapy instructions derived from autonomously determined doses of insulin.
  • the system may receive glucose level signals from a sensor operatively configured to determine glucose levels in a subject.
  • the sensor can include any type of sensor that can determine glucose levels.
  • the sensor may be a Continuous Glucose Monitoring (CGM) sensor.
  • CGM Continuous Glucose Monitoring
  • the system may autonomously determine and/or generate a dose control signal using a control algorithm.
  • the determination and/or generation of the dose control system may be performed without any user action or interaction with the glucose level control signal.
  • the lack of user action or interaction with the glucose level control system refers to conscious action and may exclude sensor measurements of physiological characteristics of the subject.
  • the control algorithm may autonomously determine doses of insulin to be infused into the subject for the purpose of controlling glucose level (e.g., blood glucose level) of the subject based at least in part on the glucose level signal.
  • the control algorithm may include any type of control algorithm.
  • the control algorithm may be a biexponential pharmacokinetic (PK) model that models the accumulation of insulin doses in the blood plasma of the subject.
  • the automated glucose level control system may control delivery or administering of insulin or a counter-regulatory agent based on the bi-exponential PK model and one or more glucose level measurements of the subject.
  • the bi-exponential PK model may model the absorption of subcutaneously administered insulin into blood and/or a rate of diminishing glucose in the blood.
  • the control algorithm may include a linear algorithm that models diminishing glucose or the accumulation of glucose in the subject based on a linear reduction rate. For example, the control algorithm may determine that a particular dose, D, of insulin is to be administered to the subject. The control algorithm may then estimate that 0.25*D of the insulin is absorbed into the blood plasma per hour over 4 hours. Similarly, the control algorithm may estimate that the insulin diminishes at a rate of 0.33*D per hour over three hours upon the insulin reaching maximum concentration within the blood plasma.
  • the automated glucose level control system may administer insulin and, in some cases, a counter-regulatory agent one or more times over a particular time period. There may be multiple reasons and/or triggers that cause the automated glucose level control system to supply insulin.
  • the automated glucose level control system may provide a basal does of insulin on a periodic basis in an attempt to maintain a steady glucose level in the blood plasma of the subject.
  • the automated glucose level control system may supply mealtime boluses of insulin to account for an expected amount of glucose to be consumed as part of a meal.
  • the mealtime bolus may be an amount specified by a user or may be an amount of insulin administered in response to an indication of meal size by the subject. This indication of meal size may be subjective.
  • the size of the bolus of insulin for an identified meal size may be a fixed or constant value. In some cases, the size of the bolus of insulin for an identified meal size may vary over time as the automated glucose level control system learns or refines the amount of insulin to administer to a subject to keep the subject’s glucose level (e.g., blood glucose level) within a target setpoint. The automated glucose level control system may learn or refine the optimal insulin to administer based on a comparison of expected glucose level measurements to actual glucose level measurements when the subject (or other user) makes a subjective identification of meal size. In addition to basal and mealtime boluses of insulin, the automated glucose level control system may also supply correction doses of insulin to the subject based on the glucose level signal.
  • glucose level e.g., blood glucose level
  • the correction doses of insulin may be supplied in response to a model predictive controller (MPC) determining or estimating that a user’s level of insulin is expected to fall below a threshold in some future period of time based on glucose level readings.
  • the MPC may execute a control algorithm that can regulate glucose concentration to a reference setpoint while simultaneously minimizing both the control signal aggressiveness and local insulin accumulation.
  • a mathematical formulation describing the subcutaneous accumulation of administered insulin may be derived based on nominal temporal values pertaining to the pharmacokinetics of insulin in the subject.
  • the mathematical formulation may be in terms of the insulin absorption rate, peak insulin absorption time, and/or overall time of action for the insulin (or another medicament). Examples of an MPC controller that may be used with embodiments of the present disclosure are described in U.S. Patent No. 7,806,854, issued on October 5, 2010, the disclosure of which is hereby incorporated by reference in its entirety herein for all purposes.
  • the automated glucose level control system may track insulin therapy administered to the subject over a tracking period.
  • the tracking period is not limited in length and may generally be any period of time, typically the tracking period is at least a minimum period of time sufficient for the automated glucose level control system to learn or refine the amount of medicament (e.g., insulin) to administer to the subject under particular conditions (e.g., when particular glucose levels are detected or when particular meal sizes are identified).
  • the automated glucose level control system may initially administer 6 units of insulin for lunch and 10 units of insulin for dinner. These initial values may be set be a healthcare provider and/or a subject based, for example, on clinical data for the subject.
  • the automated glucose level control system may determine that providing 7 units of insulin for lunch and 8 units of insulin for dinner maintains the subject’s glucose level closer to the median of the setpoint range than did the initial configuration.
  • each unit of insulin is l/lOO 111 of a milliliter of insulin.
  • the tracking period can be any length of time.
  • the tracking period could be 1 day, 3 days, 5 days, 7 days, anything in between, or more.
  • the tracking period is at least long enough to provide sufficient time to learn or refine initial settings of the automated glucose level control system for the subject.
  • the tracking period may be 1 or 2 days.
  • the tracking period may be from a particular time period until a current time period.
  • the tracking period may be from the start of therapy until a current point in time.
  • the tracking period may be a moving or shifting window.
  • the tracking period may be the least week, two weeks, month, or year.
  • the tracking period may differ based on the amount of time sufficient to determine or refine medicament control values for the subject.
  • the tracking period may a window of a particular length. This window may be a moving window.
  • the window may be the previous 7 days. As time passes, the window moves to continue to encompass the previous 7 days.
  • Tracking the insulin therapy may include storing the autonomously determined doses of insulin delivered to the subject. These autonomously determined doses of insulin may include one or more of basal insulin doses, mealtime insulin boluses, or correction insulin doses. Moreover, tracking the insulin therapy may including tracking the type of insulin used.
  • the type of insulin may include any type of insulin, such as fast-acting insulin (e.g., Lispro, Aspro, or Glulisin), regular or short-acting insulin (e.g., Humulin R, Novolin R, or Velosulin R), intermediate-acting insulin (e.g., Humulin N, Novolin N, ReliOn), long-acting insulin (e.g., detemir (Levemir), and glargine (Basaglar, Lantus)), or Ultra long-acting insulin (e.g., degludec (Tresiba), glargine u-300 (Toujeo)).
  • tracking the insulin therapy may include tracking counter-regulatory agent (e.g., Glucagon) therapy.
  • tracking the insulin therapy may include calculating average therapy provided over a period of time (e.g., over the tracking window). For example, the tracking the insulin therapy may include determining a moving average of the past 7 days of nominal basal doses during each dosing interval. Assuming basal therapy is provided every five minutes, the moving average may be calculated based on the previous 288 doses (e.g., over 1 day) or 2016 doses (e.g., over 7 days). This calculation can be used to obtain a basal rate profile for backup therapy. In some cases, the time period may be broken up into different time segments that may be associated with different rates of therapy.
  • basal therapy periods there may be 4 basal therapy periods (e.g., 10pm-4am, 4am-10am, 10am-4pm, and 4pm-10pm).
  • a separate moving average may be calculated for each of the basal therapy periods over a day, or over some other time period (e.g., 7 days).
  • the calculated averages may be used to calculate a backup basal rate that can be used to program an automated glucose control system.
  • the basal rate profile may include aggregating the doses across the day to determine a dose of long-acting insulin that can be used for injection therapy.
  • a moving average of correction doses can be calculated to determine a correction bolus of insulin to supply via a pump or injection therapy.
  • the moving average of correction doses in combination with measurements of glucose level of the subject over time may be used to determine a rate of change of glucose level from a unit of insulin provided during correction therapy.
  • Mealtime boluses may also be calculated using a moving average. Further, a separate moving average may be calculated for each meal (e.g., breakfast, lunch, and dinner) dose over some period of time (e.g., 7 previous days of mealtimes). In some cases, each of the moving averages may be calculated using different windowing functions. For example, the moving average may be calculated using a Hann window or a Hamming window. In some cases, different levels of dosing may be determined for different meal sizes and different doses may be determined for different meals.
  • different meals may have different dosing despite similarity in size due, for example, to differences in the subject’s glucose levels when they wake up versus when they usually have lunch, or because differences in types of foods consumed at breakfast versus lunch. Further, in some cases, differences in metabolisms of different subjects may result in different mealtime boluses.
  • the insulin therapy may be stored in a therapy log, or any other type of data structure. Further, the insulin therapy may be stored in a memory of the automated glucose level control system, on a companion device, on a computing device of the subject or user (e.g., a laptop or desktop), in a cloud computing environment, or in any other storage system capable of receiving the insulin therapy information from the automated glucose level control system.
  • the automated glucose level control system may generate a backup insulin therapy protocol.
  • the backup insulin therapy protocol may include a backup injection therapy protocol or a backup pump therapy protocol.
  • the backup injection therapy protocol may include one or more amounts of insulin (or other medicament) to administer using injection therapy (e.g., manually provided shots) at one or more times to help maintain the subject’s condition within a normal or desired physiological range or condition.
  • the backup pump therapy protocol may include data and/or instructions for a replacement medicament pump of the same type or of a different type to supply therapy to the subject.
  • the replacement medicament pump may be a permanent replacement or a temporary replacement.
  • the backup pump therapy protocol may be the same as and/or include the same type of information as the backup injection therapy protocol.
  • the backup pump therapy protocol may include different values than the backup injection therapy protocol.
  • the backup pump therapy protocol may include an indication of basal therapy to provide periodically on relatively short increments (e.g., every 5 minutes, every half hour, every hour, etc.). Because an insulin pump may automatically administer insulin, it is possible to provide a steady or periodic drip of insulin. It may be impractical for a subject using injection therapy to administer insulin manually on similar short increments.
  • the backup therapy protocol for a pump and for injection may differ.
  • the type of insulin used or identified in the backup protocol may differ.
  • the backup protocol may call for use of long-acting insulin, such as, for example, insulin glargine, or intermediate- acting insulin, such as, for example human recombinant insulin.
  • the backup pump therapy protocol may be used to manually refine pump settings for a replacement glucose level control system to be used by the subject.
  • the replacement glucose level control system may automatically configure itself based on the backup therapy protocol. For example, a user may cause the backup therapy protocol to be provided to the replacement glucose level control system, which may use the information to self-calibrate.
  • one or both of the backup pump therapy protocol and the backup injection therapy protocol may include a calculation of a carbohydrate ratio.
  • This carbohydrate ratio may be specific to the subject.
  • the carbohydrate ratio may be associated with a set of subjects or patients. This set of subjects may share one or more characteristics or demographics with the subject. For example, the set of subjects may be the same age, gender, weight range, ethnicity, live in the same geographical region, etc.
  • an initial carbohydrate ratio may be included in the backup pump therapy protocol and/or backup injection therapy protocol that is not specific to the subject. Over time, the carbohydrate ratio may be updated based on specific data obtained for the subject as determined by the automated glucose level control system and/or clinical data. Examples of calculations of carbohydrate ratios may be found in U.S. Publication No. 2019/0019571, which is hereby incorporated by reference in its entirety for all purposes and is made a part of this specification.
  • therapy data may be useful in determining whether the subject is satisfied with therapy provided by the automated glucose level control system or whether the glucose level control system is configured in a way that best matches the subject’s lifestyle or therapy preferences (subjective or otherwise).
  • One way to determine whether the glucose level control system is providing desired therapy, or therapy at a desired rate, is to determine the frequency and/or magnitude of modifications made by the subject, or other user that may help manage a subject’s therapy, to therapy provided by the automated glucose level control system.
  • the automated glucose level control system disclosed herein can track user modifications to a control parameter over a tracking period.
  • the tracking period may include any time period described above for tracking therapy to generate a backup protocol.
  • the control parameter may include any type of control parameter that may affect the administering of therapy.
  • the control parameter may relate to a quantity of therapy, a timing of delivered therapy, a rate that therapy is delivered, or a trigger of when or whether to deliver therapy, among other control parameters.
  • control parameters may directly affect the delivery of therapy (e.g., specify a time to deliver the medicament or a quantity of medicament to deliver) or may indirectly affect therapy (e.g., adjust a setpoint range to maintain blood glucose or a rate of insulin accumulation in the subject, which may be used to modify a control algorithm for administering therapy).
  • therapy e.g., adjust a setpoint range to maintain blood glucose or a rate of insulin accumulation in the subject, which may be used to modify a control algorithm for administering therapy.
  • the user modifications may include any change to the control parameter or settings of the automated glucose level control system.
  • the automated glucose level control system may track each instance and/or the rate or percentage of times a user reduces or increases a control parameter (e.g., an amount of administered insulin).
  • tracking changes to the control parameter may including tracking how often a user pauses therapy or temporarily adjusted a target glucose level range, or other control parameter.
  • tracking changes to the control parameter may include tracking when a user makes changes to the control parameter.
  • the user may generally modify the control parameter at night, but leave the daytime parameter unchanged, or vice versa.
  • the automated glucose level control system may track a subject’s weight over time. The weight may be provided by a user and may affect the glucose level control (e.g., an amount of insulin administered may be related to a subject’s weight).
  • the automated glucose level control system may generate a report that tracks user modifications to the control parameter.
  • the report may comprise a measure of the frequency of increases and decreases from the stored control parameter value. Further, the report may include an indicator of a percentage of times a user modified a control parameter higher or lower than the stored control parameter value of the automated glucose level control system over the tracking period. In some cases, the report indicates the number of times that the infusion of insulin is paused over the tracking period, or the speed (e.g., aggressiveness) that insulin is delivered to the subject.
  • a clinician or other healthcare provider can determine whether modifications should be made to a control parameter to better manage a subject’s therapy. For example, if it is determined that a subject is raising a glucose level target level 4- 5 times a week during an evening time or nighttime, the clinician may determine that the target setpoint for the evening should be adjusted to reduce the number of occurrences that a user manually adjusts therapy, or control parameter settings for therapy, provided by the automated glucose level control system. In some cases, the subject may be adjusted therapy based on subjective reasons. In some such cases, the therapy report may enable the clinician or healthcare provider to train the subject on controlling his or her disease. In some cases, the clinician may determine that the subject has a different tolerance for blood glucose than initially determined or than an average subject and may adjust one or more control parameters of the automated glucose level control system accordingly.
  • the automated glucose level control system may automatically adjust one or more control parameters over time based on the report. For example, if the automated glucose level control system determines that over a course of a month the subject adjusted lower a daytime target glucose level range 20 out of 30 days, the automated glucose level control system may modify a control parameter to have a lower setpoint range. In some cases, the automated glucose level control system may communicate the change to a user, such as the subject, a parent or guardian, or a healthcare provider.
  • FIG. 50 presents a flowchart of an example backup therapy protocol generation process 5000 in accordance with certain embodiments.
  • the process 5000 may be performed by any system that can track medicament therapy (e.g., insulin therapy) provided to a subject over time and generate a backup therapy protocol that may be used if a glucose level control system 4710 becomes unavailable.
  • the process 5000 may be performed by one or more elements of the glucose level control system 4710.
  • at least certain operations of the process 5000 may be performed by a separate computing system that receives indications of medicament therapy provided to the subject 4712 from the glucose level control system 4710.
  • the process 5000 is described with respect to particular systems.
  • the process 5000 begins at block 5002 where the glucose level control system 4710 receives a glucose level of a subject 4712.
  • Receiving the glucose level may include receiving and/or determining a glucose level signal corresponding to a glucose level of the subject.
  • the glucose level signal may be received from the glucose sensor 4716 (e.g., a CGM sensor).
  • the glucose level may be received from a user that provides the glucose level to the glucose level control system 4710 via a user interface, such as a user interface generated by the processor 4730 that may be output on a touchscreen by the touchscreen controller 4738.
  • the glucose level received from the user may be a glucose level measured using an alternative sensor or measurement mechanism (e.g., diabetes measurement strips) that may be used in place of the glucose sensor 4716.
  • the glucose level control system 4710 generates an insulin dose control signal based at least in part on the glucose level signal.
  • the insulin dose control signal may be a medicament control signal configured to control a medicament pump to administer medicament (e.g., insulin, counter-regulatory agent, or other medicament) to a subject 4712.
  • the dose control signal may be generated using a control algorithm configured to autonomously determine doses of insulin to be administered to or infused into the subject for the purpose of controlling glucose level of the subject based at least in part on the glucose level or glucose level signal determined at the block 5002.
  • the glucose level control system 4710 tracks insulin therapy administered to the subject 4712 over a tracking period. The tracking period is typically at least one day and may be longer.
  • the tracking period may be 1 day, 2 days, a week, a month, several months, a year, any length of time between the foregoing examples, or even longer.
  • the tracking period may be continuous from a point in time when tracking begins.
  • the tracking period may encompass the entire usage lifetime of the glucose level control system 4710 by the subject 4712.
  • the process 5000 may be repeated periodically, upon request, or upon a triggering event using a new tracking period, of equal or different length.
  • the triggering event may include any event that may render a prior generated backup therapy protocol potentially out-of-date.
  • the triggering event may include a change in medicament type (e.g., different insulin or counter-regulatory agent formulations), a change in physiological characteristics of the subject 4712 (e.g., a change in weight, or sensitivity to different glucose levels or medicament), or a change in average activity level of the subject 4712.
  • a change in medicament type e.g., different insulin or counter-regulatory agent formulations
  • a change in physiological characteristics of the subject 4712 e.g., a change in weight, or sensitivity to different glucose levels or medicament
  • the tracking period is typically at least one day enabling the glucose level control system 4710 to determine a backup protocol based on data from a full cycle (e.g., waking and sleeping hours) of glucose level control system 4710 use
  • the tracking period may at least initially be less than a day.
  • an initial backup therapy protocol may be generated after a half-day’s activity. This initial backup therapy protocol may be updated as more data becomes available throughout the day’s (and, in some cases, subsequent day’s) use of the glucose level control system 4710.
  • the tracking period may be defined by or based on a particular number of insulin administering events.
  • the tracking period may be defined by at least ten instances of generating an insulin dose based on a glucose level signal.
  • the tracking period may be defined by a minimum number of meal events, correction dose events, and/or basal dose events.
  • the tracking period may require 3 meals, or 3 meals of each meal type to occur, 2 correction doses, and/or 100 basal doses. It should be understood that the aforementioned number of doses is just an example, and the tracking period may include more or fewer dose amounts.
  • the tracking period may be defined or specified as a combination of time and occurrences of a particular number of doses of insulin.
  • the tracking period may be variable. For example, if the glucose level control system 4710 determines that the insulin dose therapy is inconsistent or erratic over the tracking period (e.g., due to inconsistent exercise or eating habits), the tracking period may be extended.
  • Tracking the insulin therapy may include storing the insulin dose control signal generated based at least in part on the glucose level signal at the block 5004.
  • tracking the insulin therapy may include storing an indication of a quantity of insulin (or other medicament) corresponding to the insulin (or another medicament) dose control signal.
  • the insulin dose control signal and/or the indication of the quantity of insulin may correspond to a dose of insulin delivered to the subject 4712 as a basal insulin dose, a correction bolus of insulin, and/or as a mealtime bolus of insulin.
  • Storing the insulin dose control signal and/or the indication of the quantity of insulin may include storing the insulin dose control signal and/or the indication of the quantity of insulin in a therapy log or any other type of data structure in the memory 4740 of the glucose level control system 4710.
  • the glucose level control system 4710 may store the insulin dose control signal and/or the indication of the quantity of insulin at a remote data store.
  • This remote data store may be a local computing system with which the glucose level control system 4710 may communicate (e.g., a laptop, desktop, smartphone, or other computing device of the subject 4712 or a user).
  • the glucose control system 4710 may provide the insulin dose control signal data or the indication of the quantity of insulin to the local computing system via Bluetooth® or other near field communication services, or via a local network.
  • the remote data store may be a remote computing system that the glucose level control system 4710 may communicate with over a wide area network, such as a wireless area network, a cellular network using IoT based communication technology, cellular communication technology, or any other communication network.
  • the wide area network may include the Internet.
  • the glucose level control system 4710 may include a wireless radio that enables it to communicate with the local or remote computing system.
  • the remote computing system may be a computing system of a data center or a cloud computing environment.
  • the glucose level control system 4710 may establish a communication channel with the computing system. This communication channel may be an encrypted channel. Further the communication channel may be a direct end-to-end connection between the glucose level control system 4710 and the computing system. Once the communication channel is established, the glucose level control system 4710 may transmit the insulin dose control signal data or the indication of the quantity of insulin to the computing system.
  • tracking the insulin therapy may include storing insulin does control signals and/or corresponding indications of quantities of insulin for a plurality of autonomously determined doses of insulin infused into the subject 4712 throughout the tracking period.
  • counter-regulatory agent therapy includes administering a counter-regulatory agent (e.g., glucagon) when there is a risk or occurrence of hypoglycemia.
  • a counter-regulatory agent e.g., glucagon
  • the counter-regulatory agent is not supplied on periodic or daily basis.
  • it can be useful to understand the amount and frequency that counter-regulatory agent is administered to the subject 4712. For example, it may help a healthcare worker or user guide or adjust care for the subject 4712. Further, tracking counter-regulatory agent use may help determine a minimum quantity of counter-regulatory agent that should be accessible to the subject 4712, either in a bi-hormonal pump or for use in injection therapy.
  • the block 5006 may include tracking the counter-regulatory agent administered during the tracking period. Tracking the counter-regulatory agent therapy may include storing an indication of autonomously determined doses of counter-regulatory agent delivered to the subject 4712 responsive to the glucose level signal obtained at the block 5002.
  • the glucose level control system 4710 generates a backup therapy protocol based at least in part on the tracked insulin therapy.
  • the backup therapy protocol may be determined based on an average quantity or rate of insulin administered to the user over the tracking period, over different portions (e.g., breakfast, lunch, and dinner, or waking and sleeping hours, etc.) of the tracking period, or in response to particular events (e.g., when eating, when glucose level exceeds a threshold level, etc.).
  • the backup therapy protocol may include a backup injection protocol and/or a backup pump therapy protocol.
  • the backup injection protocol may provide a user (e.g., the subject 4712, a parent or guardian, or other caretaker for the subject 4712) with quantities of insulin that may be administered to the subject 4712 via injection.
  • the backup injection therapy may indicate times that the insulin may be administered.
  • the backup injection therapy may indicate quantities of insulin to be administered at particular mealtimes.
  • the backup injection therapy may indicate an effect that a unit of insulin may have on the subject 4712 enabling a user to calculate how much insulin to administer to the subject 4712 when a glucose level reading indicates that the glucose level of the subject 4712 is too high (e.g., above a desired setpoint range).
  • the backup pump therapy protocol may provide a user (e.g., the subject 4712, a parent or guardian, or other caretaker for the subject 4712) with quantities of insulin that may be administered to the subject 4712 via a medicament pump.
  • a user may configure the medicament pump to administer the quantities of insulin identified.
  • the backup pump therapy protocol may be used to configure the medicament pump when access to a CGM sensor is unavailable (e.g., the subject 4712 does not possess a CGM sensor, or the medicament pump or CGM sensor has a fault, etc.). Further, the backup pump therapy protocol may be useful for providing an initial configuration to a replacement glucose level control system.
  • the backup injection therapy protocol and the backup pump therapy protocol may be the same. However, often at least the recommended basal therapy settings may differ. It is generally not practicable for insulin to be administered to a subject 4712 more than a few times a day via injection therapy.
  • the backup injection therapy protocol may identify long acting insulin units or doses that may be administered on a limited basis (e.g., once or twice a day). However, the medicament pump may more easily administer insulin on a more than limited basis (e.g., every hour, every half hour, every 5 minutes, etc.).
  • the backup pump therapy protocol may identify a basal rate of insulin that may be administered once every time unit (e.g., once per hour or once per 15 minutes, or once per five minutes), or continuously at a particular rate (e.g., 0.5 or 0.6 units) per time unit (e.g., per hour).
  • the backup pump therapy protocol may identity different rates for different portions of a day (e.g., one rate each half of the day, one rate each quarter of the day, or one rate during typical waking hours and one rate during typical sleeping hours for the subject, etc.) ⁇
  • an initial backup therapy protocol may be generated at the block 5008.
  • the initial backup therapy protocol may be updated over time as additional insulin therapy data is obtained.
  • Generating the backup therapy protocol may include determining a number of long acting insulin units based at least in part on an average total basal insulin provided to the subject 4712 per day over the tracking period.
  • the averaged total basal insulin provided per day may be included in a backup injection therapy protocol as a single dose of long acting insulin that is configured to help maintain the basal insulin level of the subject 4712 throughout the day.
  • the averaged total basal insulin provided per day may be included in a backup injection therapy protocol as multiple doses of insulin (e.g., 2 or 3 doses throughout the day).
  • the basal insulin may be included in the backup therapy protocol, such as in a backup pump therapy protocol, as a dosage rate that may be supplied to a pump to provide a rate of basal insulin throughout the day.
  • each day of the tracking period may be divided into a plurality of sub-periods. For example, each day of the tracking period may be divided into two, three, four, or more time periods, or equal or different length.
  • generating the backup therapy protocol may include determining an hourly basal rate for each sub-period of the plurality of sub-periods. This hourly basal rate may be determined by averaging the corresponding sub-periods for each day of the tracking period.
  • the basal rate supplied during the first sub-period throughout the tracking period may be averaged and the basal rate supplied during the second sub-period throughout the tracking period may be averaged to determine two basal rates for inclusion in the backup therapy protocol.
  • the basal rate may be determined on an hourly rate or based on any other time period.
  • the basal rate may be determined based on an amount of time that a particular quantity (e.g., one unit) of insulin is recommended to be administered to the subject 4712 as part of the backup therapy protocol.
  • the backup therapy protocol may indicate the basal rate to be one unit every 1.125 hours.
  • the backup therapy protocol may indicate a basal rate of 0.89 units per hour.
  • generating the backup therapy protocol may include determining an average correction bolus provided to the subject per day over the tracking period.
  • the average correction bolus may be determined by adding the total amount of correction doses administered each data and dividing by the number of days in the tracking period.
  • the average correction bolus may be included in the backup therapy protocol as guidance for the user.
  • the correction bolus is supplied in response to a determination that a subject’s glucose level is spiking or exceeding a threshold, and not necessarily as a daily dose of insulin.
  • the average correction bolus may be included as part of the backup therapy protocol to facilitate the user understanding an amount of insulin that is likely to be required during an average day, which may be useful for the user (e.g., the subject) to determine how much insulin to have accessible to use, for example, in injection therapy.
  • one or more days, or time periods, of the tracking period may be omitted when determining the average correction bolus because, for example, the one or more days or time periods may be determined to be outliers. The outliers may be omitted to provide a more accurate understanding of average insulin needs or consumption.
  • the glucose level control system 4710 may determine an average change in glucose level (e.g., blood glucose level) at least partially attributable to a unit of insulin provided as a correction bolus to the subject during the tracking period. In some cases, the glucose level control system 4710 may correlate each correction bolus applied during the tracking period to a change in the glucose level of the subject 4712.
  • glucose level e.g., blood glucose level
  • Generating the backup therapy protocol may include determining, for each mealtime of a plurality of mealtimes per day, an average mealtime bolus of insulin provided to the subject over the tracking period.
  • the average mealtime bolus may be determined for particular meals (e.g., breakfast, lunch, and dinner), while other periods of food intake (e.g., snacks or teatime) may be omitted or ignored.
  • the average mealtime boluses may be associated with particular meal sizes as identified by a user.
  • the glucose level control system 4710 may determine an average mealtime bolus for a small and a large meal, or for a small, a medium, and a large meal.
  • the average mealtime bolus may be determined by averaging an amount of insulin the glucose level control system 4710 determines should be administered to the subject 4712 using a control algorithm of the glucose level control system 4710 for each mealtime and identified meal size.
  • the backup therapy protocol may include data relating to the administering of counter-regulatory agent.
  • the backup therapy protocol may include an indication of total counter-regulatory agent and/or daily counter-regulatory agent provided to the subject over the tracking period.
  • the glucose level control system 4710 outputs the backup therapy protocol.
  • Outputting the backup therapy protocol may include displaying the backup therapy protocol on a display enabling a user to implement the backup therapy protocol.
  • outputting the backup therapy protocol may include transmitting the backup therapy protocol to a computing device of a user for display and/or storage.
  • the backup therapy protocol may be stored at the glucose level control system 4710 and may be accessed in response to a user interaction with a user interface of the glucose level control system 4710.
  • the process 5000 can be combined at least in part with the process 47100 described below.
  • the backup therapy protocol may further include a record of user modifications to one or more control parameters used by the control algorithm of the glucose level control system 4710 to autonomously determine doses of insulin to be infused into or administered to the subject.
  • This record of user modifications may include an identity of instances of user modification to the control parameter and/or a percentage of times a user modified the control parameter during each day of the tracking period and/or during the entire tracking period.
  • FIG. 51 presents a flowchart of an example control parameter modification tracking process 5100 in accordance with certain embodiments.
  • the process 5100 may be performed by any system that can track user interactivity with glucose level control system 4710, and more specifically, occurrences of a user modifying a control parameter used by the glucose level control system 4710 to help control medicament delivery to the subject 4712.
  • the process 5100 may be performed by one or more elements of the glucose level control system 4710.
  • At least certain operations of the process 5100 may be performed by a separate computing system that receives indications of changes to control parameter settings of the glucose level control system 4710 from the glucose level control system 4710 and/or from user interaction with a user interface at the separate computing system prior to transmitting the modification to the glucose level control system 4710.
  • a separate computing system that receives indications of changes to control parameter settings of the glucose level control system 4710 from the glucose level control system 4710 and/or from user interaction with a user interface at the separate computing system prior to transmitting the modification to the glucose level control system 4710.
  • the process 5100 begins at block 5102 where the glucose level control system 4710 receives a glucose level of a subject 4712.
  • the block 5102 can include one or more of the embodiments previously described with respect to the block 5002.
  • the glucose level control system 4710 generates an insulin dose control signal based at least in part on the glucose level signal and a control parameter.
  • the insulin dose control signal may be generated based on a control algorithm that enables the glucose level control system 4710 to autonomously determine doses of insulin to be infused into or administered to the subject to control the glucose level of the subject.
  • the control algorithm may determine the doses of insulin based at least in part on the control parameter.
  • the control parameter may include any parameter that can affect the operation or output of the control algorithm, or the operation of the glucose level control system 4710, and that is modifiable by a user (e.g., the subject 4712 or a user that is at least partially responsible for care of the subject 4712 (e.g., a parent or guardian)).
  • the control parameter may be, or may correspond to, a target setpoint for the glucose level of the subject 4712.
  • the control parameter may correspond to whether the glucose level control system 4710 is to generate the insulin dose control signal for at least a period of time.
  • the control parameter may relate to whether at least some operation of the glucose level control system 4710 is paused or active.
  • the block 5104 can include one or more of the embodiments previously described with respect to the block 5004.
  • the glucose level control system 4710 tracks one or more user modifications to the control parameter over a tracking period.
  • the tracking period may be one day, less than a day, or it may be longer than one day (e.g., 2 days, 3 days, a week, a month, etc.). Further, the tracking period may include one or more periods of time as previously described with respect to the process 5000.
  • the user may be the subject 4712 or any other user (e.g., a parent or guardian, or a healthcare provider) that may be permitted to modify a control parameter of the glucose level control system 4710.
  • the user may modify the control parameter using a user interface that may be generated and/or output by the glucose level control system 4710.
  • the user interface may be generated and/or output by a computing system that can communicate with and/or modify the control parameter at the glucose level control system 4710.
  • the computing system may be a smartphone, a smartwatch, a laptop, or desktop computer, or any other type of computing device that may be used to configure the glucose level control system 4710.
  • the user interface may be output on a touchscreen with which the user may interface to modify the control parameter.
  • the user may interact with a control parameter selection element or other user interface element to select and/or modify the control parameter.
  • the user may provide the control parameter with any value supported by the glucose level control system 4710.
  • the user may be limited to selecting particular values for the control parameter, which may be less than the supported capability of the glucose level control system 4710 or less than what other users are permitted to select. For example, a clinician may be granted a greater modification range than a parent for modifying the control parameter.
  • Tracking the one or more user modifications may include storing in the one or more user modifications in a therapy log, database, or other data structure. Further, tracking the one or more user modifications may include tracking or storing whether each of the user modifications comprises an increase or a decrease in the control parameter. The determination of whether the control parameter has been increased or decreased may be determined based on whether a value for the control parameter has been increased or decreased relative to a reference value. The reference value may include a current value of the control parameter, a default value, a clinical value supplied to the glucose level control system 4710, and/or a value determined by the glucose level control system 4710. Further, tracking the one or more user modifications may include storing a time and/or one or more conditions under which the control parameter is modified.
  • the glucose level control system 4710 may store a time of day, an activity level of the subject 4712 as determined from one or more physiological sensors and/or as identified by a user, a meal being consumed or not consumed, and the like.
  • tracking the insulin therapy may include storing an indication of the autonomously determined doses of insulin delivered or administered to the subject 4712.
  • the tracking period may be divided into a plurality of subperiods. The sub-periods may correspond to different portions of a day within the tracking period. For example, each day of the tracking period may be divided into two equal halves corresponding roughly to day and night, or into 3 or 4 different periods corresponding to a particular number of hours in the day.
  • the sub-periods may be of equal or unequal length. Tracking the one or more user modifications may include tracking the occurrence of modifications to the control parameter within the sub-periods of the tracking period. Further, the occurrence of modifications within a sub-period of a day within the tracking period may be combined with the occurrence of modifications within a corresponding sub-period of another day within the tracking period. In other words, each occurrence of a modification of a control parameter in a sub-period defined from 9:00-21:00 may be aggregated across days of the tracking period.
  • a different reference value may be determined for the control parameter for each sub-period.
  • tracking the one or more user modifications may include tracking modifications to the control parameter value with respect to the reference value for the sub-period.
  • the glucose level control system 4710 generates a report of user modifications to the control parameter.
  • the repot may be generated by another computing system, such as a cloud computing system or a computing system of a healthcare provider based on data (e.g., occurrences of user modification of the control parameter value) received from the glucose level control system 4710.
  • the report may include a measure of frequency of increases and decreases from the stored control parameter value. Further, the report may indicate a number of times that operation of one or more features of the glucose level control system 4710 has been paused or suspended, or a percentage of the tracking period that operation of one or more features of the glucose level control system 4710 has been paused or suspended. Moreover, the report may indicate a magnitude of the modification to each control parameter for each occurrence, in total, and/or on average. In some cases, the report may indicate a percentage of user modifications that are higher or lower than the reference value over the tracking period.
  • the report may include a measure of frequency of increases and decreases from a reference value for the control parameter for each sub-period of the tracking period.
  • the report may include an identity of user activity that occurred when, or within a threshold time period, of a user modification to a value of the control parameter. For example, the report may identify whether a user was exercising (e.g., swimming, running, dancing, etc.) when a user modification to the control parameter value was made.
  • the block 5108 may include storing the generated report at the glucose level control system 4710 (e.g., in the memory 4740) and/or at a storage of another computing device.
  • the computing device may be a computing device of the subject 4712 (or parent or guardian). Further, the computing device can be a computing device of a healthcare provider. In some cases, the computing device may be a computing device of a cloud computing service.
  • the report may be obtained from the glucose level control system 4710 by a wired connection (e.g., a USB cable). Alternatively, or in addition, the report may be obtained via a wireless connection to the glucose level control system 4710.
  • the glucose level control system 4710 may establish an encrypted connection to a computing system of a healthcare provider, which may receive the report from the glucose level control system 4710.
  • the glucose level control system 4710 may establish an encrypted communication channel with a cloud computing provider, which can receive the report from the glucose level control system 4710. This report may then be accessed by any authorized users.
  • a healthcare provider can use the report to help manage care of the subject 4712. For example, if the healthcare provider determines that a user is modifying the control parameter more than a threshold number of times or during particular time periods, the healthcare provider may use this information to modify the care being provided to the subject 4712 and/or to educate the subject 4712 on optimal care. For example, the rate of therapy may need to be modified or the amount of insulin may be too low for the subject’s comfort. For example, in some cases, a subject 4712 may have a different tolerance to a glucose level than the average user leading the user to modify a setpoint range.
  • the process 5100 may be combined with the process 5000.
  • a report may be generated that includes both backup therapy protocols and a record of the number of times a user may a modification to one or more control parameters of the glucose level control system 4710.
  • the processes 5000 and 5100 may be triggered and/or performed independently.
  • FIGs. 52-54 illustrate one non-limiting example of a backup therapy report, or a set of reports, that may be generated using one or more of the embodiments disclosed herein.
  • the reports of FIGs. 52-54 may be portions of a single report generated by the glucose level control system 4710, or may be separate reports that are concurrently generated or that are generated based on different data and/or over different tracking periods.
  • the report may be generated by the automated glucose level control system 4710, or by another computing system that may receive therapy data from the automated glucose level control system.
  • FIGs. 52-54 represent just one non-limiting example of a report or set of reports that may be generated. It is possible for other reports to be generated that include more or less data.
  • the backup injection therapy protocol and the backup pump therapy protocol illustrated in FIG. 52 may be separated into two separate reports that may be separately generated and/or accessed.
  • FIG. 52 illustrates an example backup therapy protocol report 5200 in accordance with certain embodiments.
  • the amount of insulin recommended under different ties and/or conditions may be displayed in units.
  • the report 5200 may identify the quantity of insulin included in a unit and/or the type of insulin.
  • the report 5200 may be an interactive report that enables a user to modify a type of insulin or a unit size of insulin.
  • the table 5202 may update the recommended number of units of insulin to administer under particular times or conditions based on the type of insulin and or unit size of insulin selected.
  • the report 5200 may identify the length of the tracking period 5206 used to determine the backup therapy protocol. Further, the report 5200 may identify the time or date range 5208 during which the tracking period 5206 occurred. Advantageously, knowing the tracking period 5206 may help determine an amount of trust to place in the recommendations included in the backup therapy protocols. The longer the tracking period, the more likely that the recommendations are accurate. A shorter tracking period is more susceptible to less accurate recommendations because, for example, the tracking period may encompass more days that are outliers for the subject’s typical condition or activity level. For example, a tracking period of one day that occurs on a day when a subject consumed larger than normal meals or exercised significantly more than normal may result in backup therapy recommendations that do not match the subject’s typical lifestyle.
  • knowing when the tracking period occurred may be useful to determine how current the recommendations are and whether they are a reliable indicator of an amount of insulin a subject should administer. For example, if the date range 5208 of the tracking period 5206 is a year old, and the subject has gained or lost significant weight over the year, the backup therapy protocol may no longer be a reliable indication of recommended injection therapy. In such cases, a user may adjust the recommendation and/or trigger a new occurrence of the process 5000.
  • the table 5202 illustrates an example backup injection therapy protocol, which may indicate various insulin doses that may be administered to the subject 4712 at various times or under various conditions using injection therapy.
  • the table 5202 identifies an amount of insulin the subject 4712 may inject when consuming a usual-sized meal for breakfast, lunch, or dinner.
  • the usual-sized meal may refer to the size of a meal that the particular subject 4712 usually consumes or has been advised to consume by a healthcare provider.
  • the units of insulin specified may refer to an amount of insulin that the automated glucose level control system 4710 provides the subject 4712 on average when the user consumes the identified usual size meal.
  • the table 5202 may further include recommended insulin doses for different size meals.
  • each breakfast may illustrate three different values (e.g., 5 units, 6 units, and 8 units) corresponding to light or smaller than usual breakfast, usual size breakfast, and heavy or larger than usual size breakfast.
  • the amount of insulin delivered may vary over time and/or based on the condition of the patient at a particular time.
  • the recommendations in the backup therapy protocols are suggested for temporary use for a particular quantity of time (e.g., up to 72 hours in the illustrated example).
  • the quantity of time for which the recommendations are valid may vary based on the subject 4712, the amount of historical data collected (e.g., the size of the tracking period), the amount of daily variation in the subject’s glucose level, or any number of other factors that may affect the amount of time that the backup therapy protocol can be safely followed.
  • the backup injection therapy protocol may further identify an amount of long-lasting insulin a subject 4712 is recommended to administer each day (or at certain times throughout the day). This long-lasting insulin may be used in place of the basal insulin that the glucose level control system 4710 may provide on a periodic basis.
  • the table 5202 identifies the reduction in glucose level attributable to one unit of insulin.
  • the automated glucose level control system 4710 has determined that one unit of insulin (e.g., 17100 th of a milliliter of insulin) may reduce a subject’s 4712 glucose level by 9 mg/dL.
  • a user implementing injection therapy may measure a subject’s 4712 glucose level, determine a difference between the measured glucose level and a desired setpoint or threshold glucose level, and divide the difference by 9 to determine a number of units of insulin to inject in response to a determination that a correction dose is warranted (e.g., that glucose level is outside of a desired setpoint range).
  • the table 5204 of the report 5200 provides an example of a backup pump therapy protocol.
  • the backup pump therapy protocol may have the same therapy information as the backup injection therapy protocol for mealtimes and for the correction factor.
  • the long acting insulin units of the injection therapy may be replaced with a basal rate indicating a rate at which the backup or replacement pump should administer insulin to the subject.
  • the basal rate may vary over time. In the illustrated example, a basal rate is supplied for four different time periods constituting a 24-hour day.
  • the basal rate may be divided into a fewer (e.g., 2 twelve-hour blocks) or greater (e.g., every four hours) number of periods, with each time period potentially having a different basal rate as determined based on the historical therapy data provided by an automated glucose level control system.
  • the report 5200 may include additional data that may be tracked over the tracking period.
  • This additional data may include any data that may facilitate care of the subject 4712 and/or maintenance of the automated glucose level control system 4710.
  • Some non-limiting examples of additional data that may be tracked and included in a report using, for example, the process 5000 or 900 are illustrated in chart 5210 of the report 5200.
  • the report may include the average glucose level of the subject 4712 over the tracking period and/or the corresponding estimated AIC percentage.
  • the report 5200 may indicate the amount or percentage of time that the subject’s glucose level is within a desired setpoint range and/or is above the desired setpoint range.
  • the report 5200 may indicate the amount or percentage of time that the subject’s glucose level is below a threshold glucose level.
  • the report 5200 may indicate the average number of meal announcements per day. As illustrated in the chart 5210, the subject 4712 from which the example report 5200 was generated made an average of 4.2 meal announcements indicating that on average, the subject consumed more than 3 meals a day. In some cases, the report may further indicate the types of meals announced (e.g., two breakfasts, one lunch, and one dinner). The second breakfast may be a large snack that is roughly equivalent in size to a small breakfast for the subject. Thus, the subject may have made an additional breakfast meal announcement. In some cases, the automated glucose level control system 4710 may support a separate snack or other meal announcement option.
  • the report 5200 may further include the total amount of insulin administered to the subject per day, and/or the total amount of counter-regulatory agent (e.g., glucagon) administered to the subject per day.
  • the report 5200 may indicate the amount of percentage of time that the automated glucose level control system 4710 is able to connect or communicate with the CGM sensor over the tracking period, which may correspond to the amount of time that the automated glucose level control system 4710 functions in an online mode during the tracking period.
  • FIG. 53 illustrates an example control parameter modification report 5300 in accordance with certain embodiments.
  • the report 5300 may be a separate report generated using, for example, the process 900. Or the report 5300 may be included as a second within the report 5200.
  • the report 5300 may generally provide an indication of the number or percentage of times that a user modified one or more control parameters of the automated glucose level control system 4710 during a tracking period. Further, as with the report 5200, the report 5300 may identify the time or date range 5208 during which the tracking period 5206 occurred. In some cases, a user may interact with the report 5300 to determine the number of percentage of times that the user modified one or more control parameters during a subset of the tracking period. Similarly, the user may filter or narrow the date range to view other data described herein for a subset (e.g., a selected data range) of the tracking period.
  • a subset e.g., a selected data range
  • the report 5300 may include a graph 5302 that illustrates the subject’s glucose level with respect to the desired target setpoint range over the course of a day during the tracking period. This day can be an average of the values obtained for each day over the tracking period, or it can illustrate a particular selected day.
  • the report 5300 may include a table 5304 that indicates the percentage of times that a user modified the glucose level target during specific time periods.
  • the table 5304 of the non-limiting example report 5300 indicates two time-periods, daytime and nighttime. However, it should be understood that the table 5304 may indicate fewer or more time periods. Further, the time periods may indicate specific times (e.g., from 9:00 to 21:00 and from 21:00 to 9:00) for the time periods.
  • the table 5304 may indicate the percentage of times that a user increased or decreased glucose target setpoints.
  • the report may indicate the percentage of times that the user did not modify, or left as usual, the glucose target setpoint.
  • This target setpoint indicated in the table 5304 may refer to a single target value (e.g., 110 mg/dL, 125 mg/dL, 130 mg/dL, etc.), or may refer to a target setpoint range (e.g., 70-180 mg/dL).
  • the report 5300 may indicate the number of times that a user set a temporary glucose target during the tracking period (the temporary target count 5306) or a selected data range.
  • the report may also indicate a number of times that the user paused therapy during the tracking period (e.g., the paused insulin therapy count 5308) and/or the selected date range.
  • the glucose level (e.g., blood glucose level) of a subject may be affected by a subject’s weight. Accordingly, the subject may provide updates of weight to the automated glucose level control system.
  • the report may indicate a change in weight and when the weight parameter was modified (e.g., body weight data 5310).
  • the report 5300 may be filtered to show data before and after a weight change separately.
  • the body weight data may be helpful for the healthcare provider to, for example, determine whether weight change may at least in part have been a basis for user modifications to target glucose levels.
  • the automated glucose level control system 4710 e.g., using glucose level readings
  • the subject 4712 may feel differently.
  • the ability to collect the modification data relating to a user’s modification of the automated glucose level control system 4710 and to correlate the data with weight changes can assist a healthcare provider in better treating the subject 4712 by, for example, adjusting settings of the automated glucose level control system 4710, changing insulin prescriptions, educating the subject 4712, or any other action that may improve care of the subject 4712.
  • the report may omit changes to glucose level target settings that are below a threshold. In other words, minor changes that may be statistical noise may be ignored. Further, in some cases, the report may indicate when control parameters (e.g., at bedtime, with respect to a particular meal, such as dinner, etc.) are modified. In some cases, the report may also indicate the duration of the change to the glucose target setpoint, or other control parameter.
  • control parameters e.g., at bedtime, with respect to a particular meal, such as dinner, etc.
  • the report may also indicate the duration of the change to the glucose target setpoint, or other control parameter.
  • FIG. 54 illustrates an example meal selection report 5400 that may be included as part of some implementations of the control parameter modification report 5300 of FIG. 53 in accordance with certain embodiments.
  • the report 5400 may include a table 5402 identifying the average number of times per day that a user (e.g., the subject 4712) announces each meal type. Typically, a user will announce a meal 0 or 1 times a day. However, in some cases, a user may announce a particular mealtime more than 1 time to account, for example, for large snacks that may be similar in size to a particular meal. Smaller snacks often may be handled by the control algorithm of the automated glucose level control system 4710 (e.g., by the corrective insulin controller 4826) without a meal announcement.
  • the automated glucose level control system 4710 e.g., by the corrective insulin controller 4826
  • the table 5402 may identify the number of times over the tracking period, or selected time period within the tracking period, that meals of particular sizes are announced by a user. For example, the table 5402 may indicate the number of times that a usual size meal is announced, a smaller than usual size meal is announce, or a larger than usual size meal is announced.
  • Some automated glucose-control systems can use control algorithms for automated delivery of insulin or an insulin-like agent.
  • Such an automated glucose control system may be driven by glucose data that is captured from a continuous glucose monitoring (CGM) device.
  • CGM continuous glucose monitoring
  • Current standard of care requires setting and/or utilizing patient-specific therapeutic parameters that require a lot of effort to set at effective and safe levels, that remain subjective to a high degree, and that require vigilant management to compensate for ever-changing therapeutic requirements of the patient over time.
  • Embodiments of an automated glucose control system that can be adapted for use with embodiments of the present disclosure are described in International Publication No. WO 2015/116524, published on August 6, 2015; U.S. Patent No. 9,833,570, issued on December 5, 2017; and U.S. Patent No. 7,806,854, issued on October 5, 2010, the disclosures of each of which are hereby incorporated by reference in their entirety for all purposes and made a part of this specification.
  • the automated glucose level control system can continue to provide autonomous dosing decisions during periods when the glucose signal is offline (e.g., when the CGM is not- functioning).
  • an automated system can provide dosing guidance recommendations that the user can follow during periods when the control system is not functional or otherwise not available.
  • the guidance may include dosing recommendations to cover or account for the user’s basal insulin needs, dosing recommendations to account for food intake (such as, but not limited to, carbohydrate consumption), and dosing recommendations to cover any additional or remaining insulin needs beyond basal insulin, such as to compensate for glucose excursions and departures from normal range.
  • the values attained online can be used for guiding the user’s basal insulin settings during self-management periods, such as by using averages of ut over multiple time segments (e.g., over multiple hour segments) over a 24 hour period (e.g., four 6-hour average values to provide a basal-rate profile of four basal rates over a 24-hour day), inferred over a particular time horizon (e.g., most recent day or week).
  • a single daily basal dose can be recommended by the control system, which can guide a user who follows a daily injection regimen for the basal dosing.
  • the latest meal doses converged upon by the algorithm during online use can provide guidance to the user on their insulin needs for different relative meal sizes (e.g., tiny or snack, smaller than typical, typical, and more than typical for the user, etc.) at different time segments of the day (e.g., breakfast, lunch, and dinner time periods).
  • total daily dosing by the system during operation e.g., over the last day or week
  • the CF may comprise a quantity estimating the glucose level drop expected per unit of insulin for the user. This can be done in conjunction with guides adopted by care providers on how to relate the total daily dose to CF. Examples of such estimations or guides can be found in U.S.
  • the mapping ratio can relate to a correction factor calculated using a known technique, such as a technique disclosed in the King publication.
  • the recommendation CF can provide guidance to the user on the dosing to follow to compensate for glucose excursions and departures from a normal range.
  • Certain embodiments include a controller that is configured to provide automatic control of glucose level of a subject.
  • the controller can be operative to generate an insulin dose control signal based on the time-varying glucose levels of the subject as represented by a glucose level signal over time.
  • the glucose level signal may be generated by a glucose sensor operative to continually sense a glucose level of the subject.
  • the insulin dose control signal may control the delivery of doses of insulin by a delivery device.
  • the controller may operate at a regular or periodic frequency to generate an insulin dose control signal to regulate the glucose levels in the subject.
  • the controller can employ a control algorithm that issues and updates insulin dosing recommendations for the purpose of being utilized during periods when the system becomes not functional or unavailable.
  • the insulin dosing recommendations include quantities related to the subject’s basal insulin needs, insulin needs for food intake, and remaining insulin needs beyond basal insulin. Further, the insulin dosing recommendations may address the expectation that the employment of the system could ultimately de-skill the user or adversely affect their ability to effectively and safely manage their glucose levels when the system becomes not functional or unavailable. Moreover, the insulin dosing recommendations can address the expectation that the use of the system from the beginning of a user’s glucose management condition could prevent the user from ever acquiring the necessary knowledge and skills that would be necessary to effectively and safely manage their glucose levels when the system becomes not functional or unavailable.
  • the insulin dosing recommendations can address a use scenario where the system is used temporarily on the subject for the purpose of obtaining such therapeutic insulin dosing recommendations for the subject or their caregiver to subsequently manage the subject’s glucose levels.
  • the system is successively usable on multiple subjects to obtain therapeutic insulin dosing recommendations, thereby providing a service that could be deployed in a clinical practice.
  • An ambulatory medical device may include a control system that autonomously provides therapy to a subject, for example, based on a health condition of a subject (e.g., determined based on one or more measured physiological indicators or parameters of the subject).
  • the control system may determine the therapy time and/or the intensity of the therapy e.g., a volume or dose of medicament delivered) during each therapy delivery based on measured values of one or more physiological parameters (e.g., using one or more subject sensors, such as a CGM sensor) and according to a predictive model that may include the one or more control parameters.
  • the predictive model may be used to estimate a physiological effect (e.g., a blood glucose level of the subject) of the therapy in order to adjust the therapy delivery according to an intended physiological effect. It is desirable to adaptively adjust the values of the control parameters to optimize the therapy delivery to a subject in the presence of time varying and subject specific factors that may influence the physiological effects of a therapy delivery on the subject.
  • the AMD may be an ambulatory medicament device that regulates the level of an analyte in subject’s blood.
  • an automated glucose level control system e.g., the glucose level control system 4710
  • a counter-regulatory agent e.g., Glucagon
  • a control algorithm may be implemented by the automated blood level glucose control system 4710 to determine when to deliver insulin and/or how much insulin to provide to the subject 4712. Further, the control algorithm may control both an ongoing or periodic delivery of insulin (e.g., a basal dose), and a correction bolus that may be provided to adjust a subject’s glucose level to within a desired range.
  • the control algorithm may use glucose level readings obtained from a subject sensor (e.g., a sensor measuring one or more physiological parameters of the subject in real time), such as a continuous glucose monitoring (CGM) sensor, that obtains automated glucose level measurements from the subject. Moreover, in some cases, the control algorithm may deliver a bolus of insulin in response to an indication of a meal to be consumed or being consumed by the subject 4712.
  • a subject sensor e.g., a sensor measuring one or more physiological parameters of the subject in real time
  • CGM continuous glucose monitoring
  • the control algorithm may deliver a bolus of insulin in response to an indication of a meal to be consumed or being consumed by the subject 4712.
  • Insulin may be administered subcutaneously to a subject 4712.
  • the administered insulin may directly or indirectly enter subject’s blood.
  • the glucose control system may subcutaneously deliver a medicament (e.g., insulin, glucagon) via an infusion set connected to a site on subject’s body.
  • a medicament e.g., insulin, glucagon
  • PK pharmacokinetic
  • pharmacodynamic (PD) delay there might be a delay, referred to as pharmacodynamic (PD) delay, between variation of the amount of insulin in the subject’s blood plasma and the resulting variation of glucose level in the subject’s blood.
  • the value of pharmacodynamic (PD) delay may be used to estimate BGL based on an estimated concertation of insulin in patient’s blood.
  • a glucose level of the subject may comprise blood glucose level, or glucose level in other fluids in subject’s body.
  • a glucose level may comprise a measured glucose level estimated using a glucose level signal received from a glucose sensor operatively connected to a subject.
  • the blood glucose level of the subject may be estimated based at least in part on the measured glucose level of the subject.
  • the glucose level control system may implement a predictive algorithm based on a pharmacokinetic (PK) model to estimate the accumulation of insulin in the blood plasma of the subject over time, following the subcutaneous administration of insulin to a subject.
  • PK pharmacokinetic
  • the PK delay may be subject specific and/or change overtime.
  • the PK model may include one or more parameters, referred to as control parameters, that may be subject specific and/or change overtime.
  • factors and parameters that may influence the PK delay and/or the control parameters of the PK model may include, type of insulin, glucose level (e.g., at the insulin administration time), physiological characteristics of the subject, health condition of the subject, one or more physiological parameters of the subject, time of the administration, location at which the infusion set is placed, the amount of insulin administered and the like.
  • the physiological characteristics may include characteristics shared among large portions of the population (e.g., weight, gender, age, etc.) as well as characteristics that may be unique or specific to the subject, or shared among few people (e.g., characteristics related to genetics). Differences between the physiologies of different subjects may result in differences in the optimal glucose level range for each subject, or some subset of subjects.
  • the differences in physiologies may also affect the absorption of insulin into the blood plasma.
  • different physiologies of different subjects may result in insulin absorption taking different amounts of time for different subjects.
  • the maximum concentration of glucose in blood plasma may occur 65 minutes after delivery of a bolus of fast-acting insulin for one subject, it may be 60 minutes or 70 minutes for another subject.
  • the glucose level control system 4710 may implement a method to adaptively change the one or more control parameters in of the PK model used in its control algorithm to modify its predictions, in order to maintain the BGL within a desired range.
  • the glucose level control system may use readings from one or more subject sensors (e.g., a CGM) and/or information received from the subject (e.g., using a user interface of the AMD), to modify one or more control parameters.
  • a glucose level control system such as an automated glucose level control system 4710, may control delivery or administering of insulin, or a counter-regulatory agent, based on a PK model and one or more glucose level measurements of the subject.
  • the PK model can be a bi-exponential PK model that may be used to estimate or determine the absorption or accumulation of subcutaneously administered insulin into blood and/or a decay rate of the insulin level in the subject’s blood for a given value of delivered dose of insulin.
  • the absorption of insulin over time according to a bi-exponential PK model may be represented by the following equation: where Uo is the subcutaneous dose in units (U), K is a scaling constant, and ai and a.2 are time constants that may be used as the control parameters of the model.
  • the peak time of absorption of insulin, starting from the time that subcutaneous dose (Uo) is administered may be referred to as Tmax and can be determined based on the following equation:
  • Tmax alone may be used as the control parameter of the bi-exponential PK model.
  • Tmax may be referred to the time at which the concentration of insulin in subject’ s blood reaches a maximum level (e.g., starting from the time that subcutaneous dose is administered).
  • the bi-exponential PK model may be used to estimate or determine the accumulation of counter-regulatory agent or hormone (e.g., glucagon) in subject’s blood.
  • Equation 2 may be used to calculate the pending effect of the accumulated amount of insulin in the subcutaneously administered dose, as that can be taken to be the difference between the total area ( / 0 °° p(t)dt, which can describe a measure of the total amount of hormone (e.g., insulin) that can be absorbed due to a dose Uo) and which can represent a measure of the expended portion of Uo at time.
  • hormone e.g., insulin
  • the glucose level control system is configured to maintain a subject’s glucose level (e.g., blood glucose level) within a particular range (e.g., a normal range). As glucose level rises or falls, the glucose level control system may administer particular amounts of insulin or counter-regulatory agent to the subject to bring the glucose level of the subject back to within a desired range or closer to a desired setpoint. As explained above, it may take some non-infinitesimal amount of time for the medicament to be absorbed into the subject’s blood stream.
  • glucose level e.g., blood glucose level
  • a particular range e.g., a normal range
  • the glucose level control system may administer particular amounts of insulin or counter-regulatory agent to the subject to bring the glucose level of the subject back to within a desired range or closer to a desired setpoint. As explained above, it may take some non-infinitesimal amount of time for the medicament to be absorbed into the subject’s blood stream.
  • a PK model (e.g., the bi-exponential PK model), may be used to determine how much insulin or counter-regulatory agent should be provided to the subject in order to maintain the subject’s blood glucose within a particular range.
  • the PK model (e.g., the bi-exponential PK model) may be used to predict the concentration of insulin glucose level of the subject over time as insulin or counter-regulatory agent is administered.
  • control parameter values of the PK model may be set by a healthcare provider based on default values obtained through clinical trials and/or based an individualized treatment plan for the subject as may be determined based on clinical tests of the subject and/or on the healthcare provider’s evaluation of the subject, which may be determined based on tests of the subject.
  • the pharmacokinetic delay and the control parameters of the PK model may be subject specific and/or change overtime due to various factors.
  • clinical data may determine optimal or recommended values of the control parameters for an average subject through one or more trials, the determined data may not be optimal for a particular subject.
  • individualized treatment plans are typically based on point- in-time measurements. These point- in-time measurements may provide a good guideline for treatment, but the optimal values of the control parameters for a subject may vary at different times of day, due to different activities, due to changes in the subject over his or her lifetime, or for any other number of reasons.
  • the glucose level control system 4710 of the present disclosure can implement a method or process to autonomously and/or automatically modify one or more control parameters of a control algorithm, or the model used by the control algorithm, to modify therapy provided to the subject using the glucose level control system 4710.
  • the method may be performed by a hardware processor 4730 and/or a controller 4718 that controls the administering of therapy.
  • the system can provide therapy (e.g., insulin) to a subject in response to a determination of a glucose level of the subject.
  • the glucose level may be determined based at least in part on a glucose level signal obtained from a glucose level sensor that is operatively connected to a subject.
  • the determination of the therapy may be based at least in part on the glucose level and/or the bi-exponential model. Moreover, the determination of therapy may be based at least in part on a value or setting of one or more control parameters of the glucose level control system.
  • the one or more control parameters may be, or may correspond to, one or more parameters of the bi-exponential PK model, or any other model or control algorithm used to control the administering of therapy to the subject.
  • the system 4710 may provide the therapy based on the value or setting of the one or more control parameters.
  • the value or setting of the one or more control parameters may be based on an initial configuration of the glucose level control system 4710 by a healthcare provider, subject, or other user. Further, the initial configuration may be based on clinical data or data obtained that is specific to the subject.
  • a control parameter may be a time constant used by a control algorithm of the glucose level control system (e.g., Tmax in a bi-exponential PK model). This time constant may be used in a calculation of an accumulation of insulin in the subject by the control algorithm.
  • control parameter may be used to control an insulin dosing response of the control algorithm to a glucose level excursion in the subject as indicated by a glucose level signal obtained from a glucose level sensor.
  • control parameter may be, or may be related to, Tmax (e.g., defined by equation 2).
  • the control parameter may be an estimate of Tmax or a fraction (e.g., 0.5) of Tmax.
  • Tmax may be the peak time of absorption of insulin, or the amount of time until the concentration of insulin from an insulin dose reaches maximum concentration in the blood of the subject.
  • control parameter may be associated with a setpoint or target glucose level, or a glucose level range.
  • the control parameter could relate to a point in time when an estimated amount of “insulin on board” (e.g., an amount of insulin in the subject as determined by a model of insulin accumulation and/or utilization in the subject) falls below a threshold value.
  • the control parameter can be a clearance time for insulin boluses (e.g., an estimate of an amount of time for an administered bolus of insulin to be utilized by the subject).
  • the control parameter may relate to Tl/2, which corresponds to a time when the concentration of insulin in the blood plasma reaches half of the maximum concentration in the blood plasma.
  • the control parameter may be a parameter that can be used to calculate Tmax or Tl/2.
  • the system 4710 may determine an effect of the supplied therapy (herein referred to as therapy effect or effect).
  • the therapy effect may be determined by analyzing a glycemic control of blood glucose (e.g., variation of BGL or supplied therapy over a measurement period) in the subject’s blood as indicated by the glucose level signal received from the glucose sensor (e.g., a CGM sensor).
  • the control system may measure or determine the effect of the supplied therapy over time.
  • the therapy effect may be determined based on variation of BGL and/or the amount of therapy delivered over time.
  • the system may continue to supply therapy to the subject over several therapy delivery times or instances and may average or otherwise aggregate the measured or determined effects of the therapy over the several therapy delivery times or instances.
  • the system 4710 may determine the therapy effect based at least in part on an input received from the subject.
  • the input received from the subject may include a subjective or objective effect.
  • the input received from the subject may include manual glucose level measurements obtained using, for example, test strips.
  • Another example of input may be an indication of light-headedness, difficulty breathing, headaches, or any other objective or subjective effect identified by the subject.
  • the control system 4710 may autonomously determine a modification to one or more control parameters. For example, the control system may modify Tmax value used by the control algorithm (or the PK model used in the control algorithm), for example, to improve the effect of a subsequent therapy that may be provided to the subject.
  • the directional modification e.g., increase or decrease
  • the control parameter value may depend on the measured or determined effect of the therapy provided based on the initial or prior value of a control parameter.
  • the directional modification of the control parameter value may depend on a difference between the determined or measured effect of the blood glucose therapy and an expected effect of the blood glucose therapy (e.g., calculated based on PK model). In some examples, the directional modification of a control parameter may be determined based on the amount of therapy doses provided and/or measured BGL of the subject, during and between one or more previous therapy deliveries.
  • the pharmacodynamic delay for a subject may be a known value.
  • the amount of absorbed insulin in the subject’s blood may be estimated based on the measured value of BGL received from a glucose sensor.
  • the directional modification may depend on the difference between calculated value of absorbed insulin based on a PK model (e.g., bi-exponential PK model) with a selected value of Tmax, and the estimated value of the absorbed insulin based on the measured value of BGL received from a glucose sensor.
  • a PK model e.g., bi-exponential PK model
  • the system 4710 may determine therapy to deliver to the subject 4712 at a therapy delivery time. As with the initial control parameter, therapy may be delivered during one or more therapy delivery times based on the modified control parameter. The system may determine the effect of the therapy delivered based on the modified control parameter using one or more of the embodiments previously described with respect to the therapy delivered using the initial control parameter.
  • the control system can compare the measured, determined or reported effects (e.g., physiological effects) from the therapy delivered using the initial value of a control parameter and those from the therapy delivered using the modified value of the control parameter. Based on the comparison, the control system may determine which values of the control parameter is preferable for the subject. In some examples, the comparison may be performed in real-time, or substantially in real-time. Further, the comparison may be performed by the system 4710 without user interaction. The comparison may be performed using a comparison method and based on one or more comparison criteria.
  • the measured, determined or reported effects e.g., physiological effects
  • the comparison method may be based on finite number of therapy effects determined or measured at discrete times or based on continuous temporal variations of an effect over a period.
  • the comparison method may involve statistical analysis of the measured or determined effects resulting from usage of the initial value and modified value of the control parameter.
  • the comparison criterion may be based on the effects or based on the temporal variations of the effects over a period.
  • the preferable control parameter value can be a value that causes the glucose level of the subject to stay within a desired range or closer to a setpoint level for the subject. Accordingly, the system can set or maintain the control parameter to have the value that generated glucose levels that are closer to the desired range or setpoint for the subject for subsequent therapy.
  • the system 4710 may repeat the process for different control parameter values enabling the system to refine the glucose level control for the subject over time.
  • the initial control parameter value may not be an initial value but may be the most recent selected value for the control parameter based on the determined effects of the control parameter.
  • the determination of a second or modified value for a control parameter, or the modification of the control parameter may be triggered based on a glucose level of the subject not satisfying a threshold.
  • a process of modifying a control parameter value may be triggered based on a difference between an expected glucose value of a subject and an expected glucose value of a subject after the administering of therapy exceeding a threshold.
  • the value of a control parameter may be autonomously modified without interaction by a subject or user with the glucose level control system.
  • the glucose level control system can automatically adjust and/or refine a control parameter used by a control algorithm for glycemic control of the subject.
  • the glucose level control system may provide both insulin therapy and counter-regulatory agent therapy to a subject.
  • the glucose level control system may only provide insulin therapy.
  • the glucose level control system may output an indication of an amount of counter-regulatory agent that may or should be administered to the subject based on a detected condition of the subject.
  • the active control parameter value used by the control parameter may remain active until a subsequent occurrence of the therapy modification process.
  • performance of the therapy modification process is continuously performed with the control parameter value being modified based at least in part on a determined effect of the prior control parameter value.
  • the therapy modification process is performed until the determined effect of the therapy satisfies a desired threshold (e.g., when the detected glucose level is within a threshold of a setpoint or median setpoint value).
  • the therapy modification process is performed a set amount of times and the control parameter value that provides the best outcome (e.g., closes to desired glucose level) is set as the active control parameter for subsequent therapy.
  • providing therapy at different sites on the subject’s body may result in different blood glucose absorption rates (associated with different PK delays).
  • the therapy modification process may be performed each time the infusion set used to deliver the therapy is moved to a different site on the subject.
  • FIG. 55 presents a flowchart of an example automated glucose level control refinement process in accordance with certain embodiments.
  • the process 5500 may be performed by any system that can autonomously and/or automatically modify a control algorithm and/or a control parameter that affects execution of the control algorithm based on feedback (e.g., from a glucose level signal) relating to therapy administered to a subject 4712.
  • the process 5500 may be performed by one or more elements of the glucose level control system 4710.
  • at least certain operations of the process 5500 may be performed by a separate computing system that receives glucose level data from the glucose level control system 4710.
  • the process 5500 may be performed automatically and without user interaction.
  • a user may trigger the process 5500 via a command or interaction with a user interface.
  • the process 5500 may be performed automatically.
  • the process 5500 may be performed continuously, periodically, or in response to a trigger.
  • the trigger may be time based and/or based on a measurement of the glucose level of the subject.
  • the trigger may correspond to a determination that a glucose level of a subject differs by more than a threshold from a predicted glucose level that is predicted by a glucose level control algorithm based on the administering of medicament. Further, the trigger may be based on the activation or first time use of the glucose level control system 4710 by the subject 4712.
  • the process 5500 begins at block 5502 where the glucose level control system 4710 receives a glucose level signal corresponding to the glucose level of a subject 4712.
  • the glucose level signal may be received from a glucose sensor capable of measuring the level of glucose in the blood of the subject.
  • the sensor may be a continuous glucose monitoring (CGM) sensor.
  • CGM continuous glucose monitoring
  • the block 5502 can include one or more of the embodiments previously described with respect to the block 802 or 5102.
  • the glucose level control system 4710 provides a first therapy during a first therapy period to the subject 4712.
  • the first therapy may be based at least in part on the glucose level signal and a first value of a control parameter.
  • the control parameter may include any control parameter that affects operation of the glucose level control system 4710 and/or performance of a control algorithm of the glucose level control system 4710.
  • the control algorithm may include any control algorithm used to determine a dose of medicament (e.g., insulin) to administer to the subject 4712.
  • the controller 4718 or the processor 4730 may use the control algorithm to generate a dose control signal based at least in part on a value (e.g., the first value of the block 5504) of the control parameter to cause the delivery device 4714 to administer a dose of insulin or other medicament.
  • a value e.g., the first value of the block 5504
  • the control algorithm may be based on the PK model (equation 2). Further, in some cases, the control parameter may be Tmax, which may be calculated using equation 3. In some cases, the control parameter may be T 1 / 2, which may relate to the amount of time for the dose of insulin in the blood stream to drop to 1 ⁇ 2 of the maximum concentration in the blood attributable to the dose administered to the subject 4712. In some cases, the control parameter corresponds to a time until insulin within blood plasma of the subject reaches a particular concentration level subsequent to administration of an insulin dose. Moreover, in some cases, the control parameter may be a parameter that affects the determination of Tmax, such as one or more of the time constants al and a2.
  • control parameter may be used by the control algorithm to account for and/or determine an accumulation of insulin (or other medicament) in the subject 4712 and/or a rate of diminishment of the insulin (or other medicament) in the subject 4712.
  • control parameter may be used to control an insulin dosing response of the control algorithm to a glucose level excursion in the subject as indicated by the glucose level signal received at the block 5502.
  • control parameter may relate to at least one time constant used in a calculation of an accumulation of insulin in the subject by the control algorithm, such as one or more of the time constants ai and a.i that may be used in the calculation of Tmax.
  • control parameter may correspond to a rate of insulin diminishment in the subject 4712.
  • control parameter may relate to a target setpoint or a target setpoint range for maintaining or attempting to maintain the subject’s 4712 glucose level.
  • the first therapy may correspond to a single administering of insulin to the subject 4712.
  • This single administering of insulin may be any type of insulin administered for any reason.
  • the insulin dose may be a basal insulin dose, a priming dose, a dose supplied in response to a meal announcement, or a correction dose of insulin.
  • the first therapy may be medicament other than insulin, such as counter-regulatory agent (e.g., glucagon).
  • the first therapy may be a plurality of medicament (e.g., insulin and/or counter-regulatory agent) doses supplied or administered to the subject 4712 over the first therapy period.
  • the plurality of medicament doses may include a variety of types of medicament doses, such as one or more basal doses, one or more meal doses associated with one or more meal announcements, one or more corrective doses, etc.
  • the first therapy period may be a time period that corresponds to a single medicament dose.
  • the first therapy period may be a time period that encompasses a plurality of medicament doses.
  • the time first therapy period may be a time period associated with a defined length of time.
  • the first therapy period may be defined based on a number of medicament delivery periods. In other words, the time period may vary based on the amount of time it takes to deliver or administer a specified number of doses of medicament (of any type or of a particular type).
  • the first value may be selected based on a prior therapy or a prior performance of the process 5500. In some cases, the first value is selected based on a baseline value. The baseline value may be associated with clinical data, or it may be determined based on initial operation of the glucose level control system 4710 for some period of time before performance of the process 5500. Alternatively, or in addition, the first value may be selected based on clinical data or a particular prescription for the subject 4712. In some cases, the first value may be based on clinical data for average users or average users that share certain physiological data with the subject 4712. In some cases, the first value is determined based on a healthcare provider’s assessment of the subject 4712.
  • the first value may be determined based on an infusion site (e.g., back, stomach, leg, etc.) for the glucose level control system 4710. In some cases, the first value may be selected based on demographics or characteristics of the subject 4712. For example, the first value may be based on the subject’s 4712 gender, weight, body mass, or age.
  • the glucose level control system 4710 determines a first effect corresponding, or attributable, at least in part to the first therapy. Determining the first effect may include receiving a glucose level signal from the glucose level sensor operatively connected to the subject. This glucose level signal may be a subsequent or updated glucose reading that is more recent than the glucose level signal received at the block 5502. The glucose level signal received at the block 5502 may be used to determine therapy to administer to the subject 4712 and the glucose level signal received at the block 5506 may be used to determine a result of the administered therapy. It should be understood that glucose level signals may be received continuously or periodically and can be used to both determine therapy to administer and to determine the effect of the administered therapy.
  • determining the first effect may include analyzing glycemic control of blood glucose in the subject as indicated by the glucose level signal. Analyzing the glycemic control of the blood glucose in the subject may include tracking the glucose level of the subject 4712 over time. Further, analyzing the glycemic control of the blood glucose in the subject may include comparing the glucose level of the subject 4712 over time to a predicted glucose level for the subject 4712 over time as predicted based on the PK model used in the control algorithm using the selected value for the control parameter. As mentioned above, in some examples, the measured glucose level of the subject 4712 over time may be used to calculate the accumulation and/or diminishment of the insulin level in subject’s blood.
  • analyzing the glycemic control of the blood glucose in the subject may include determining whether, or to what degree, the calculated accumulation and/or diminishment of insulin (or other medicament) using the PK model (e.g., bi-exponential PK model) and the control parameter values used in the control algorithm matches the accumulation or diminishment of insulin (or other medicament) estimated based on the measured glucose level (e.g., obtained from the CGM sensor).
  • the first effect may, at least partially, be determined by analyzing one or more signals received from one or more subject sensors that measure one or more physiological parameters of the subject (e.g., heart rate, temperature and the like).
  • the first effect may be determined based on an input received from the subject (e.g., using a user interface of the AMD). In some cases, the first effect may be determined based at least in part on an assessment or input provided by the subject 4712 (e.g., using a user interface) with respect to the first value or the first effect. For example, if the subject 4712 feels woozy, dizzy, lightheaded, nauseous, or otherwise uncomfortable during the first therapy period, the subject 4712 may, via, for example, a touchscreen display of the AMD, indicate how the subject 4712 is feeling.
  • the glucose level control system 4710 generates a second value for the control parameter.
  • This second value may be autonomously determined. Further, in some cases, the second value may be automatically determined. In some cases, the second value is determined based at least in part on a user triggering the glucose level control refinement process 5500. In some such cases, the control system may determine the second value and present it to the user via a user interface circuitry 4734 of the control system 4710.
  • the second value may be obtained from a user interface 4734 of the glucose level control system 4710 (e.g., in response to a user interaction with the user interface).
  • the second value may be obtained from a computing system that is connected to or otherwise in communication with the glucose control system.
  • the communication connection may be a wired or wireless connection.
  • the wireless connection may be a direct connection (e.g., via Bluetooth or other near-field communication technologies) or a connection over a network (e.g., a local area network, a wide area network, a cellular network, etc.).
  • the second value may be an increase or decrease of the control parameter compared to the first value.
  • the second value may be limited to a particular maximum change from the first value.
  • the second value may be selected based at least in part on the first effect. For example, if the first effect corresponding to the first value results in glucose level being near an upper range of the setpoint range, the second value may be selected in an attempt to being the glucose level closer to the middle of the setpoint range. Further, the second value may be selected based at least in part on characteristics of the subject 4712, such as age, weight, gender, or any other characteristics that may affect blood glucose management. In some examples, the second value may be selected based at least in part on the first effect determined based on an assessment provided by the subject 4712, in an attempt to reduce the symptoms felt by the subject 4712.
  • the second value of the control parameter may be generated based at least in part on a baseline value of the control parameter and an output of a function defined based on glycemic control of the subject.
  • the glycemic control of the subject may include the measured value of the glucose level in subjects blood (e.g., provided by the CGM) and/or the amount of therapy (e.g., dose of insulin or counter-regulatory hormone) provided during the first therapy period.
  • the baseline value of the control parameter may correspond to the first value used to provide therapy at the block 5504. This baseline value may be a last known optimal value for the subject prior to any changes to the subject (e.g., change in weight, insulin type, or metabolism changes, etc.). Alternatively, or in addition, the baseline value may be a value determined by a healthcare provider.
  • the second value of the control parameter is based at least in part on glycemic control indicated by the glucose level signal.
  • the second value may be a modification to Tmax or T1 / 2. It should be understood that Tmax and/or T1/2 may, at least in part, be based on the physiology or biochemistry of the subject 4712.
  • the setting of either Tmax or Tmfor the setting of the first value and the second value may refer to setting a parameter of the control algorithm or the PK model used by the control algorithm, representative of or corresponding to Tmax and/or Ti / 2.
  • the setting of the first value and the second value may include setting one or more control parameters that may be used to determined or estimate Tmax and/or T1/2 for the subject 4712.
  • the set value may differ from the actual value of Tmax and/or T1/2 for the subject 4712.
  • Tmax and/or T1/2 may vary for different subjects, it is not always possible to explicitly set or determine Tmax and/or T1/2 for a subject. Instead, Tmax and/or T1/2 may be estimated or determined by comparing the effects and/or glucose levels determined for different control parameter values that correspond, at least in part, to Tmax and/or T1 / 2 .
  • the control parameter may iteratively approach the actual Tmax and/or T1/2 for the subject 4712, or within a threshold of the actual Tmax and/or T1/2 for the subject 4712.
  • the control parameter (such as one or more of the time constants ai and a.2) may iteratively approach a value that corresponds to the actual Tmax and/or T1/2 for the subject 4712.
  • the glucose level control system 4710 changes the control parameter to the second value. Changing the control parameter to the second value causes a change in the operation or execution of the control algorithm. This change in the execution of the control algorithm may result in a change in one or more factors associated with the provisioning of therapy to the subject 4712.
  • the changing in the execution of the control algorithm may result in a change in an amount of medicament delivered, a timing of the delivery of the medicament, a rate at which a dose of medicament is delivered to the subject 4712, a target setpoint or target range for the glucose level (e.g., blood glucose level) of the subject, a threshold used in determining whether to deliver medicament (e.g., a threshold difference from the target setpoint), or any other factor that may affect therapy delivered to the subject 4712.
  • a target setpoint or target range for the glucose level e.g., blood glucose level
  • a threshold used in determining whether to deliver medicament e.g., a threshold difference from the target setpoint
  • the glucose level control system 4710 provides second therapy during a second therapy period to the subject 4712.
  • the second therapy is based at least in part on the updated control parameter that is updated to the second value at the block 5510.
  • the second therapy may refer to one or a plurality of medicament doses.
  • the second therapy period may refer to a specific amount of time, an amount of time to deliver a particular number of medicament doses, or a particular number of medicament doses.
  • the block 5512 may include one or more of the embodiments described with respect to the block 5504 but using the second value for the control parameter over the second therapy period.
  • the duration of the second therapy period may be equal to the duration of the first period.
  • the number of therapies delivered during the second therapy period may be equal to the number of therapies delivered during the first second therapy period.
  • the glucose level control system 4710 determines a second effect corresponding at least in part to the second therapy.
  • the block 5514 may include one or more of the embodiments described with respect to the block 5506, but with respect to the second therapy.
  • the glucose level control system 4710 selects one of the first value or the second value based at least in part on a comparison of the first effect and the second effect.
  • the comparison of the first effect and the second effect may be performed autonomously without action by a user.
  • the glucose level control system 4710 may select the one of the first value or the second value to be a current or active value for the control parameter based on whether the first effect or the second effect results in improved care (e.g., closer to a desired setpoint for a greater period of time, or less volatility in glucose level values, or any other factor that a healthcare provider may use to evaluate the success of diabetes management) for the subject 4712.
  • the glucose level control system 4710 selects a third value to the current or active value for the control parameter.
  • the third value may be selected based on the comparison of the first effect and the second effect. For example, if it is determined that the first effect is preferable to the second effect, the third value may be selected based on a change to the first value in the opposite direction as the change made to the first value to obtain the second value.
  • the first value corresponded to a Tmax of 60 minutes
  • the second value was selected to correspond to a Tmax of a longer time period (e.g., 65 or 70 minutes)
  • the third value may be selected to correspond to a Tmax of a shorter time period (e.g., 50 or 55 minutes).
  • Comparing the first effect and the second effect may include determining whether the first value or the second value brought the subject’s 4712 glucose level closer to a target setpoint and/or maintained the subject’s 4712 glucose level within a target range for a longer period of time. In some cases, comparing the first effect and the second effect may include determining whether the first value or the second value resulted in a more stable glucose level for the subject 4712 or less volatility in the glucose level of the subject 4712. In some cases, comparing the first effect and the second effect may include determining whether the first value or the second value resulted in more and/or greater excursions of the subject’s 4712 glucose level from a target glucose level range.
  • Comparison of the first effect and the second effect may be performed in real-time or substantially in real-time accounting for the processing speed of the hardware processor 4730 or the glucose level control system 4710. Thus, in some cases, the comparison of the first effect and the second effect may be performed upon determination of the second effect.
  • the comparison of the first effect and the second effect may include a statistical comparison or statistical analysis of the first effect and the second effect.
  • the comparison of the first and second effects may include determining whether the second therapy produced a statistically significant improvement in therapy (e.g., glycemic control) compared to the first therapy. A statistically significant improvement may vary depending on the subject or the condition of the subject.
  • the comparison can also include a determination of whether there was a statistically significant increase in risk factors (e.g., hypoglycemia) during the second therapy period compared to the first therapy period.
  • a statistically significant improvement may be an improvement determined based on a first statistical analysis of a set of data associated with the first effect and a second statistical analysis associated with the second set of data associated with the second effect.
  • the first and second statistical analysis may include calculating the mean and variance of the glucose levels measured during the first and second therapy periods, respectively.
  • an improvement may be determined by comparing the mean value and the variance of the glucose levels measured during the first and second therapy periods.
  • an improvement may be determined by comparing the mean value and the variance of the glucose levels measured during the first and second therapy periods with one or more reference values.
  • the reference values may be values provided by a health care provider or a user and may be stored in the memory 4740 of the glucose level control system 4710.
  • the first and second therapy period may be long enough to include a plurality of therapy deliveries (e.g., infusion of glucose and/or glucagon) during each period.
  • an improvement may be determined by comparing by other statistical quantities calculated at least in part based on the glucose levels measured during the first and second therapy periods.
  • the statistical quantities may be specific statistical quantities defined for comparing the effects of a therapy (e.g., medicament delivery for controlling the glucose level in a subject).
  • the first and/or second may be output to user (e.g., the subject or a parent) via a user interface of the glucose control system and/or a computing system (e.g., a smartphone, laptop, personal computer, or the like).
  • a computing system e.g., a smartphone, laptop, personal computer, or the like.
  • the user may use the determined effect to adjust the value of a control parameter.
  • the value that better manages the subject’s 4712 blood glucose may be output to a user (e.g., the subject or a parent).
  • the user may then configure the glucose level control system 4710 based on the selected control parameter value.
  • the glucose level control system 4710 may automatically modify the value of the control parameter.
  • the user may be provided with an opportunity to confirm the modification.
  • the modification may occur automatically without confirmation. However, the modification may be presented to the user (e.g., the subject or a healthcare provider) and/or logged in a therapy log.
  • the comparison is performed by another computing system that is in communication with the glucose level control system 4710.
  • the glucose level control system 4710 may transmit the glucose level signal, data determined from the glucose level signal, and/or the assessment received from the subject, indicative of the effect of the glucose level control, to another computing system, such as a local computing system, a smartphone, or a cloud-based computing system.
  • the glucose level control system 4710 may transmit data associated with the control parameters values and the administering of medicament to the subject 4712 to the computing system.
  • the computing system may determine the value of the control parameter that better manages the subject’s 4712 glucose level.
  • the computing system may configure the glucose level control system 4710 with the selected value. Alternatively, or in addition, the selected value may be output to a user who can configure the glucose level control system 4710 with the selected value.
  • the glucose level control system 4710 provides therapy to the subject 4712 based on the selected value for the control parameter that is selected at the block 5516.
  • the therapy provided at the block 5518 may be provided during a third therapy period that is at some point after the first and second therapy periods.
  • the first and second values may be used, respectively, for the control parameter to determine the value that results in the better outcome or improved care for the subject 4712.
  • the value that resulted in the better outcome for the subject 4712 may be used to provide future care for the subject 4712.
  • a new value that is neither the first or second value may be used to provide subsequent care in an attempt to find a value for the control parameter that may provide a better or improved level of care (e.g., closer to a desired target glucose level for a longer period of time) for the subject 4712.
  • providing therapy to the subject may include generating a dose control signal to a delivery devices 4714 (e.g., infusion pump coupled by catheter to a subcutaneous space of the subject 4712) that delivers an amount of a medicament (e.g., insulin or a counter-regulatory agent) to the subject wherein the amount may be determined by the dose signal.
  • a delivery devices 4714 e.g., infusion pump coupled by catheter to a subcutaneous space of the subject 4712
  • a medicament e.g., insulin or a counter-regulatory agent
  • Providing therapy to the subject 4712 based on the selected value may include configuring the glucose level control system 4710 to provide therapy to the subject 4712 during a third therapy period based at least in part on the active control parameter value.
  • configuring the glucose level control system 4710 to provide therapy to the subject 4712 based at least in part on the active control parameter value may end the process 5500.
  • the process 5500 may be repeated. Repeating the process 5500 may include using the selected value (e.g., the first or second value from a prior iteration of the process 5500) as the first value when performing the operations associated with the block 5504.
  • the second value generated at the block 5508 may be a new value not used during the prior iteration of the process 5500.
  • the process 5500 may be repeated until a difference between the first effect and the second effect is less than a threshold difference. Alternatively, or in addition, the process 5500 may be repeated a particular number of iterations, periodically, in response to a command, or in response to determining that the subject’s 4712 blood glucose does not satisfy a particular threshold for a particular amount of time.
  • the process 5500 may be used to modify more than one control parameters of a glucose system (or a control algorithm used by the control system).
  • the process 5500 may be used to adjust a first control parameter during a first modification period starting from block 5502 and ending at block 5518, and to adjust a second control parameter during a second modification period again starting from block 5502 and ending at block 5518.
  • the second modification period may be immediately after the first modification period or delayed by a particular time.
  • the control system may determine when a second control parameter should be modified following the modification of a first parameter.
  • the delay may be determined at least in part based on the measured glycemic control based on the glucose signal (e.g., received from a CGM sensor). In some other examples, the delay may be determined based on input received from a user. In some examples, the modification of the second control parameter may be at least partially determined based on the determined modification of the first control parameter.
  • a third control parameter may be adjusted during a third time period after adjusting the first and the second control parameters.
  • the adjustment of the third control parameter may immediately follow the adjustment of the second control parameter or may occur after a delay.
  • the delay may be determined at least in part based on the glycemic control of the subject after the second control parameter is adjusted.
  • the glucose control system may be configured to sequentially adjust the first and second, or the first, second and third control parameters when the glycemic control of the subject satisfies one or more threshold conditions.
  • the duration of the time period during which a control parameter is adjusted may defer from that of the other parameters.
  • a modified version of the process 5500 may be used to determine a value (e.g., an optimal value) of a control parameter.
  • the control system may skip block 5516 and block 5518, and instead obtain a third value for the control parameter.
  • this third value may be determined at least in part based on the determined second effect at block 5514.
  • this third value may be autonomously determined. Further, in some cases, the third value may be automatically determined. In some cases, the third value is determined based at least in part on a user triggering the glucose level control refinement process 5500.
  • control system may determine the third value and present it to the user via a user interface 4734 of the control system 4710.
  • the third value may be provided by a user via a user interface 4734 of the control system 4710.
  • the system may provide therapy to the subject based on the third value.
  • This modified version of process 5500 may be repeated several times. In some examples, this modified version may be repeated until a difference between the last two subsequent effects is less than a threshold difference. Alternatively, or in addition, the modified version of the process 5500 may be repeated a particular number of iterations, periodically, in response to a command, or in response to determining that the subject’s 4712 blood glucose does not satisfy a particular threshold for a particular amount of time.
  • the process 5500 may be used to modify one or more control parameters that affect the delivery of insulin.
  • the process 5500 is not limited as such and may be used to modify one or more control parameters that affect the delivery of other medicaments, such as counter-regulatory agent (e.g., glucagon, dextrose, etc.).
  • the process 5500 may be used to recommend a change in insulin and/or counter-regulatory agent delivery without modifying the delivery. This can be advantageous for generating recommendations regarding counter-regulatory agent in a single hormone glucose level control system 4710 that does not support counter-regulatory agent, or that supports the use of counter- regulatory agent, but does not have the counter-regulatory agent available.
  • the at least two or more of the control parameters may be related to each other.
  • the control parameters include the time constants al and a2
  • a may equal 1.5 times ai
  • the value for the control parameter set as the active parameter (e.g., the first value or the second value) at the block 5516 may be used by the control algorithm to provide therapy to the subject 4712 for a particular period of time or until the process 5500 is repeated.
  • the process 5500 is repeated periodically and/or in response to a trigger, such as a blood glucose value or an average blood glucose value over a time period, or an indicate of a site change for the connection of the glucose level control system 4710 to the subject 4712 (e.g., a change in the location of the infusion set used to provide the subcutaneous dose).
  • the peak time of absorption of insulin may be referred to as Tmax.
  • Different types of insulin may result in different amounts of time until peak absorption into the subject’s blood or for different subjects.
  • the aggregate Tmax among subjects for the fast-acting insulin lispro and insulin aspart may be determined to be approximately 65 minutes, while the aggregate Tmax among subjects using ultra-fast-acting insulin, such as, for example, the insulin aspart injection marketed under the Fiasp brand, which has a formulation to decrease time to peak absorption, may be determined to be approximately 40 minutes.
  • Tmax is held constant while varying the type of insulin used.
  • the first cohort uses a glucose level control system configured with a Tmax of 65 minutes for a first week of therapy and a lower Tmax (such as, for example, 50 minutes) for a subsequent week of therapy.
  • the second cohort uses the glucose level control system configured with a Tmax of 65 minutes for the first week of therapy and an even lower Tmax (such as, for example, 40 minutes) for a subsequent week of therapy.
  • the third cohort uses the glucose level control system configured with a Tmax of 65 minutes for the first week of therapy and a sharply lower Tmax (such as, for example, 30 minutes) for a subsequent week of therapy. Comparison of the change in Tmax within each cohort and across cohorts demonstrates that the mean glucose level drops when Tmax is lowered, and there is no statistically significant increase or decrease in hypoglycemia.
  • Tmax is shorter than physiological insulin absorption peak time
  • the glucose level control system may stack or administer multiple doses of insulin within a time period. This may occur because the glucose level control system may incorrectly identify a lower blood glucose concentration as a maximum glucose level concentration when Tmax is set below the actual peak insulin absorption time.
  • the control system may determine whether there is a statistically significant difference in mean glucose level during a later period using a different Tmax value compared to an earlier evaluation period.
  • Tmax or a control parameter of the glucose level control system 4710 corresponding to Tmax may be set to the newer value, where the change in the control parameter value may occur automatically upon determination of a statistically significant improvement or may occur after generating a notification of the potential improvement and receiving confirmation that the change in control parameter value should occur.
  • the value for Tmax may be lowered by a significant amount from the initial Tmax.
  • control algorithm may automatically change Tmax or an associated time constant to reflect a Tmax reduction of at least 10 minutes, at least 5 minutes, at least 2 minutes, no more than 15 minutes, no more than 20 minutes, no more than 30 minutes, or by a change within a range spanning between any two of the preceding values in this sentence, where the preceding values are included in the range.
  • the system can perform a statistical analysis between the prior data set associated with the higher Tmax, and the current data set associated with the lower Tmax.
  • the system can adopt or recommend the lower Tmax value as the preferred Tmax. This process can be repeated using additional reductions in Tmax. In some cases, each reduction in Tmax may be smaller than the previous reduction. Moreover, if it is determined that there is a not an improvement in the mean glucose level for the subject and/or if there is an increase in hypoglycemia or hypoglycemia risk events, the system may use the prior Tmax or may select a Tmax between the new Tmax and the prior Tmax. Thus, using the process 5500, the system can iteratively modify Tmax to find an optimal value for the subject and/or the selected insulin type.
  • a significant or statistically significant improvement e.g., more than a threshold improvement
  • the real-time process and statistical analysis described above can be used to analyze other types of biomedical data obtained by one or more subject sensors (e.g., measuring one or more physiological parameters).
  • the additional biomedical data such as data may be received from a smartwatch (e.g., blood pressure, heart rate), from a weight sensor, or any other type of biomedical sensor.
  • the outcomes of the comparative analysis described above may be used to make additional recommendations to the subject. For example, if it is determined that the actual Tmax for a particular type of insulin is higher than expected for the subject, it may be recommended that the subject modify his or her diet in a particular manner while using that particular type of insulin.
  • Embodiments of an automated glucose level control system 4710 that can be adapted for use with embodiments of the present disclosure are described in International Publication No. WO 2015/116524, published on August 6, 2015; U.S. Patent No. 9,833,570, issued on December 5, 2017; and U.S. Patent No. 7,806,854, issued on October 5, 2010, the disclosures of each of which are hereby incorporated by reference in their entirety for all purposes.
  • the automated glucose level control system 4710 can autonomously administer insulin doses and account for online accumulation of insulin doses (“insulin on board”) due to the finite rate of utilization of the insulin.
  • the rate the insulin absorption, and in turn accumulation, of insulin doses may be modeled by a pharmacokinetic (PK) model (e.g., the bi-exponential PK model represented by equation 2 with preset values of time constants al and a2).
  • PK pharmacokinetic
  • Tmax the peak time for insulin absorption in blood is referred to as Tmax.
  • Tmax may be the time at which the concentration of insulin reaches its maximum value following the delivery of a specific dose of insulin. In some such examples, Tmax may be measured from the time that insulin is provided to the subject (e.g., subcutaneously using an infusion set).
  • setting the time constants in the PK model may be equivalent to setting Tmax that is inherently assumed by the model; conversely, setting Tmax may set the time constants of the PK model. Since the values of the time constants may be used to determine the online calculation of the accumulation of insulin by a control system, the value of the time constants may consequently control the control system’s insulin dosing response to a given glucose level excursion. Thus, varying Tmax or time constants associated with Tmax controls the aggressiveness of the control system’s insulin doses.
  • the control system implements a method to adapt the control system’s PK model’s Tmax (hence time constants) setting online. This method may be performed either by the control system periodically making online assessments and calculations that produce recommendations of modifications in Tmax or by the control system autonomously modulating Tmax online. In either case, the calculations may be based on the control system’s performance over some time period. In some cases, adaptations to Tmax online, whether autonomously occurring or issued as recommendations can be based on the glucose-control performance by the control system over some time interval, including trends in glucose level, mean glucose level, or extent and/or duration of low glucose level (hypoglycemia) and/or high glucose level (hyperglycemia) occurrence.
  • the calculation can be based on the usage of a counter-regulatory agent, the otherwise intended usage of a counter-regulatory agent had it been available (e.g., in insulin-only systems or in cases where the counter-regulatory agent or its delivery channel are temporarily unavailable).
  • the method can impose upper and/or lower (static or dynamic) bounds for the range over which the Tmax can vary.
  • the degree of adaptation in Tmax for a given situation can be different depending, for example, on the specific insulin being administered by the control system.
  • the described method may be applicable regardless of whether the continuous glucose monitor (which can provide the input glucose signal to the control system) is online or offline.
  • the method disclosed herein can be applied to system described in International Publication No. WO 2015/116524.
  • the described method can coexist with other aspects of the system being activated or not, such as, but not limited to, having a glucose target that is adapted automatically by the system, e.g., as in the system described in International Publication No. WO 2017/027459, published on February 16, 2017, which is hereby incorporated by reference herein for all purposes.
  • the absorption of subcutaneously administered insulin into blood may be governed by the bi-exponential PK model of equation 2.
  • Setting the time constants in the PK model may set a measure of the pending effect of the accumulated amount of insulin in the subcutaneously administered dose, as that can be taken to be the difference between the total area (f p(t)dt, which can describe a measure of the total action over time due to a dose U0) and which can represent a measure of the expended portion of U0.
  • the peak time, Tmax, of the absorption of insulin doses into blood may be given by equation 3.
  • setting Tmax may set the PK model time constants, which can directly govern the magnitude (e.g., aggressive or conservative) of the control system’s online insulin dosing response to a given glucose profile.
  • the bi-exponential PK model may be used to simulate the relation between a glucose profile and the medicament (e.g., insulin or glucagon) doses delivered to a subject.
  • Figures 56A-56C illustrate a simulation demonstrating an effect that increasing or decreasing the Tmax setting, or value for a control parameter corresponding to Tmax, may have on the glucose level control system’s 4710 online insulin and glucagon dosing response to a given glucose profile (e.g., temporal variation of glucose level over 24 hours).
  • FIG. 56A illustrates a simulation of glucose level control of a subject with Tmax set to 65 minutes.
  • the graph 5602 illustrates the variation of glucose level (BGL) of a subject over 24 hours.
  • the range 5604 indicates the desired target setpoint range (e.g., between 70 and 120 mg/dL) for the subject’s glucose level.
  • the range 5606 indicates the range in glucose level (e.g., below 60 mg/dL) for the subject that is associated with hypoglycemia or a risk of hypoglycemia.
  • the graph 5610A illustrates the administering of medicament (insulin or glucagon) to the subject over the same 24-hour time period as graph 5602 based at least in part on the glucose level variation illustrated in the graph 5602.
  • FIG. 56B illustrates a simulation of glucose level control of a subject with Tmax set to 15 minutes.
  • the graph 5610B corresponds to the graph 5610A, but with Tmax set to 15 minutes instead of 65 minutes. As illustrated by comparing the graph 5610B to 5610A, reducing Tmax to 15 minutes may result in an increase in insulin dosing required to maintain the given glucose profile 1400.
  • Figure 56C illustrates a simulation of glucose level control of a subject with Tmax set to 130 minutes.
  • the graph and 1410C corresponds to the graph 5610A, but with Tmax set to 130 minutes instead of 65 minutes.
  • Tmax set to 130 minutes instead of 65 minutes.
  • increasing Tmax to 130 minutes may result in a decrease in insulin dosing required to maintain the given glucose profile 1400.
  • the value of Tmax can be varied automatically online based on glycemic control in a receding time period.
  • Tmax can be described using the following the equation:
  • T max ik) T£ ax + f(y k ,g k ), (4)
  • T ⁇ ax is a baseline value of Tmax
  • f(y k , g k ) is a parameter control adjustment function (herein referred to as adjustment function), based on glycemic control of the glucose signal, y k , and/or the amount of counter-regulatory dosing, g k , that is computed by the control system (whether delivered or not).
  • Evaluation of / ( [y k , g k ) could be over a time period (e.g., one week, two weeks, four weeks or other time intervals).
  • k may represent a current therapy period and N may indicate a receding time period that may include one or more therapy periods.
  • the parameter control adjustment function / ( [y k , g k ) can cause an increase in T max (k ) relative to T ⁇ ax for an increase in hypoglycemia (in severity and/or duration) or impending hypoglycemia in glycemic control of the glucose signal, y k , over the receding time period (that may include one or more therapy periods) and, conversely, can cause a decrease in T max (k ) relative to T ⁇ ax for an increase in hyperglycemia (in severity and/or duration) in glycemic control of the glucose signal, y k , over the receding time period.
  • f(y k , g k ) can cause an increase or decrease in T max (k ) relative to T ⁇ ax respectively for an increase or decrease in amount of counter-regulatory dosing, g k , over the receding time period.
  • the adjustment fiy ⁇ g k ) to T max (k ) can be evaluated and effected at discrete times, which can be at scheduled periodic intervals (e.g., once every 24 hours, once every three days, once a week, etc.), in response to a user command, or based on a physiological measurement of the subject.
  • adjustments can be evaluated and effected online when some metric satisfies a threshold or meets certain criteria within the current computation window (e.g., a week, a month, etc.). This criterion can include when hypoglycemia in y k reaches or crosses a certain threshold or the level of counter-regulatory dosing in g k reaches or crosses a certain threshold.
  • the adjustment can be effected after some evaluation related to the glucose signal y k (e.g., mean value) in the current computation window has attained a statistically significant difference from its evaluation in a preceding computation window (e.g., the week before).
  • therapy periods can be scheduled regular or periodic time intervals (e.g., 24 hour periods, two day periods, one week periods, etc.), based on a user command, or based on a physiological measurement of the subject.
  • therapy periods may be defined as the time interval between two subsequent therapy deliveries, and each therapy period may be identified based on the therapy delivery time that marks the beginning of the therapy period.
  • FIG. 57 is a plot 5700 that illustrates an example of glucose level signal G(t) 1502 (e.g., a CGM trace received from a CGM sensor) over a therapy period (starting from ts 5704 and ending at t E 5706) during which one or several doses of insulin and/or a counter- regulatory agent (e.g., glucagon) are determined and/or administered by the glucose control system 4710.
  • a counter- regulatory agent e.g., glucagon
  • an insulin dose of Ui 5708 units may be provided at time t u ,i 5710 at a measured glucose level of G u ,i 14712 (where i varies from 1 to the number of insulin deliveries between ts 5704 and at t E 5706).
  • control system may have calculated a dose of Cj 14714 units, that may have been administered or not, a glucose level G c ,j 14718 at which glucagon may have been delivered and the time t cj 14716, at which glucagon may have been delivered, (where j varies from 1 to the number of glucagon deliveries between ts 5704 and at t E 5706).
  • the control system may be configured to provide therapy in order to maintain the BGL within a normal range defined by an upper bound G m ax 5720 and a lower bound G m in 5722 and close to a setpoint G set 5724.
  • the glucose levels above G m ax 5720 may indicate hyperglycemia and glucose levels below G m in 5722 may be considered hypoglycemia.
  • two instances of hyperglycemia 5726 and two instances of hypoglycemia 1528 may be identified by the control system.
  • the control system may store G(t) 5702, t u ,i 5710, tcj 14716, Ui 5708 and Cj 14714, for all therapy deliveries (all values of i and j).
  • the value of one or more control parameters (e.g., Tmax, G set ) may not change during the therapy period between ts 5704 and t E 5706.
  • FIG. 58 presents a flowchart of an example automated glucose level (e.g., blood glucose level) refinement process that may use the above-mentioned modification method to control Tmax and/or other control parameters of a glucose control system.
  • the process 5800 may be performed by any system that can autonomously and/or automatically modify a control algorithm and/or a control parameter that affects execution of the control algorithm based on feedback (e.g., from a glucose level signal) relating to therapy administered to a subject 4712.
  • the process 5800 may be performed by one or more elements of the glucose level control system 4710.
  • at least certain operations of the process 5800 may be performed by a separate computing system that receives glucose level data from the glucose level control system 4710.
  • one or more different systems may perform one or more operations of the process 5800, to simplify discussion and not to limit the present disclosure, the process 5800 is described with respect to particular systems.
  • the process 5800 may be performed automatically and without user interaction.
  • a user may trigger the process 5800 via a command or interaction with a user interface.
  • the process 5800 may be performed automatically.
  • the process 5800 may be performed continuously, periodically, or in response to a trigger.
  • the trigger may be time based and/or based on a measurement of the glucose level of the subject.
  • the trigger may correspond to a determination that a glucose level of a subject differs by more than a threshold from a predicted glucose level that is predicted by a glucose level control algorithm based on the administering of medicament.
  • the trigger may be based on the activation or first time use of the glucose level control system 4710 by the subject 4712.
  • the process 5800 begins at block 5802 where a first value is selected for a control parameter (e.g., a control parameter that may be adaptively modified) of the glucose control system 4710.
  • the control parameter can be a Tmax value used in the control algorithm of the glucose control system 4710. In some examples, Tmax may be related to one or more parameters in a PK model used by the control algorithm.
  • the control parameter can be a setpoint (e.g., G set 5724 in FIG. 57) or the target value for the measured value of the blood glucose concentration of a subject 4712 (e.g., measured using a CGM sensor).
  • the first value of the control parameter may be selected based on a baseline value.
  • the baseline value may be associated with clinical data, may be determined based on operation of the glucose level control system 4710 for some period of time before performance of the process 5800, or may be determined from a prior performance of the process 5800.
  • the baseline value may be selected based on clinical data or a particular prescription for the subject 4712.
  • the baseline value may be based on clinical data for average users or average users that share certain physiological data with the subject 4712.
  • the baseline value is determined based on a healthcare provider’s assessment of the subject 4712.
  • the baseline value may be determined based on an infusion site (e.g., back, stomach, leg, etc.) for the glucose level control system 4710.
  • the baseline value may be selected based on demographics or characteristics of the subject 4712.
  • the glucose control system 4710 provides therapy over a time period to the subject 4712 based at least in part on the first value of the control parameter. Further, the therapy may be provided based at least in part on one or more glucose signals received during the time period.
  • the glucose signals may be received from a glucose sensor (e.g., a CGM) and may correspond to a glucose level of the subject.
  • the time period may include one or more therapy periods. In some examples, the number of therapy periods included in the time period may be equal or unequal therapy periods.
  • a therapy period may be a time period that corresponds to a single delivered medicament dose, which may include an instantaneous delivery or a delivery of the medicament dose over a period of time.
  • a therapy period may be a time period that encompasses a plurality of medicament dose deliveries. Further, a therapy period may be a time period associated with a defined length of time. Alternatively, or in addition, the therapy period may be defined based on a number of medicament periods. In other words, the time period may vary based on the amount of time it takes to deliver or administer a specified number of doses of medicament (of any type or of a particular type).
  • the time of delivery and dose of the plurality of therapies may be based at least in part on the glucose level signal and the first value of a control parameter of the control algorithm used by the glucose control system 4710.
  • the control parameter may include any control parameter that affects operation of the glucose level control system 4710 and/or performance of a control algorithm of the glucose level control system 4710.
  • the control parameter can be Tmax, T1 / 2, speed of delivery of a medicament dose, a setpoint for the glucose level, a glucose level range, a threshold value of glucose level (e.g., a maximum or minimum value) and the like.
  • the control algorithm may include any control algorithm and/or PK model used to determine a dose of medicament (e.g., insulin) to administer to the subject 4712.
  • the controller 4718 or the processor 4730 may use the control algorithm to generate a dose control signal based at least in part on a value (e.g., the first value selected at the block 5802) of the control parameter to cause the delivery device 4714 to administer a dose of insulin or other medicament.
  • Each therapy of the plurality of the therapies provided over the time period may correspond to a single administering of insulin to the subject 4712.
  • This single administering of insulin may be any type of insulin that may be administered for any reason.
  • the insulin dose may be a basal insulin dose, a priming dose, a dose supplied in response to a meal announcement, or a correction dose of insulin.
  • each therapy provided may be a medicament other than insulin, such as counter-regulatory agent (e.g., glucagon).
  • each therapy delivery may include a plurality of medicament (e.g., insulin and/or counter-regulatory agent) doses supplied or administered to the subject 4712 over a therapy period.
  • the plurality of medicament doses may include different types of medicament doses, such as one or more basal doses, one or more meal doses associated with one or more meal announcements, one or more corrective doses, etc.
  • the value of the control parameter that is being adjusted may change from one therapy period to another therapy period during the time window.
  • the value of the control parameter may change by a given amount in the beginning of each therapy period or group of therapy periods.
  • the value of the control parameter may change by a given amount after certain number of therapies.
  • the amount by which the control parameter is changed may be determined based on one or more receding therapy periods in the time window.
  • the block 1604 may include one or more of the embodiments described with respect to the block 5504.
  • therapy data may include the glucose signal, G(t) 5702, the calculated or actual delivery time (t c,j 14716) and the estimated or delivered amount of a counter-regulatory agent (C j 14714).
  • This therapy data may be stored in the memory 4740 of the glucose level control system 4710. Further, the therapy data may include a total amount of the counter-regulatory hormone administered during a therapy period. Alternatively, or in addition, other parameters and data associated with each therapy period may be stored in the memory 4740.
  • the total amount of insulin administered an amounts of insulin delivered (Ui 5708), a delivery time (t u,i 5710) of the insulin delivered during each therapy period, data received from other sensors that may measure one or more physiological parameters of the subject, data received from the subject or user (e.g., via a user interface), and the like.
  • the glucose level control system 4710 determines a control parameter adjustment for the control parameter.
  • the control parameter adjustment may be based at least partially on the therapy data.
  • the adjustment may be determined using an adjustment function.
  • the adjustment function may be the function /(y fc , g k ) for modifying Tmax according to equation 4.
  • the control parameter adjustment may be determined by analyzing glycemic control of blood glucose in the subject as indicated by the glucose level signal (e.g., G(t) 1502 or the CGM trace). Analyzing the glycemic control of the blood glucose in the subject may include tracking the glucose level of the subject 4712 over time.
  • analyzing the glycemic control of the blood glucose in the subject may include comparing the glucose level of the subject 4712 over time to a predicted blood glucose for the subject 4712 over time estimated based on the PK model and control parameter values used in the control algorithm.
  • the value of the adjustment function fiy ⁇ gu) may be calculated at least in part using the estimated or actual values of t cj 14716, C j 14714, and G c,j , (where j varies from 1 to the number of counter- regulatory provided during the time period).
  • determination of the adjustment function fiy ⁇ gu may include a statistical analysis based on the estimated or actual values of t c,j 14716, C j 14714, and G c,j , (where j varies from 1 to the number of counter- regulatory provided during the time period).
  • the statistical analysis may be based on statistical quantities and/or the analytical tools described below.
  • the adjustment to the control parameter may be determined based on the number of hypoglycemia 1528 and/or hyperglycemia 5726 events and/or duration of each event. In some examples, the adjustment to the control parameter may be determined based on the difference between measured glucose level and the setpoint (G set 5724). In some examples, the adjustment may be determined based on the time intervals during which the glucose level stays within a target range (e.g., between G max 5720 and G min 5722). In some cases, the adjustment may be determined based on the stability of the measured glucose level for the subject 4712 or less volatility in the glucose level of the subject 4712. For example, a statistical analysis may be performed to determine the distribution rate of change for G(t) beyond one or more threshold rates.
  • the adjustment to the control parameter may, at least partially, be determined by analyzing one or more signals received from one or more subject sensors that measure one or more physiological parameters of the subject (e.g., heart rate, temperature and the like).
  • the adjustment to the control parameter may be determined based on an assessment or input received from the subject 4712 (e.g., using a user interface of the AMD). For example, if the subject 4712 feels woozy, dizzy, lightheaded, nauseous, or otherwise uncomfortable during one or a plurality of therapy periods, the subject 4712 may, via, for example, a touchscreen user interface or other interface of the AMD, indicate how the subject 4712 is feeling.
  • the adjustment may be determined in real-time or substantially in real-time accounting for the processing speed of the hardware processor 4730, the glucose level control system 4710, or the time for the subject to provide an assessment of his or her condition to the glucose level control system 4710.
  • the adjustment to the control parameter may be determined by a computing system that is in communication with the glucose level control system 4710.
  • the glucose level control system 4710 may transmit the therapy data, to another computing system, such as a local computing system, a smartphone, or a cloud- based computing system.
  • the glucose level control system 4710 may transmit the therapy data and data associated with the control parameters values to the computing system.
  • the computing system may determine the adjustment that better manages the subject’s 4712 glucose level in the next time period.
  • the glucose level control system 4710 adjusts the control parameter using the control parameter adjustment determined at the block 5806.
  • the adjustment may be performed autonomously or automatically.
  • the control parameter adjustment determined at block 5806 may be presented to the subject or other user (e.g., parent, guardian, clinician, etc.) via a user interface (e.g., a touchscreen display).
  • the subject or other user may be able to confirm or modify the control parameter adjustment.
  • the display of the control parameter adjustment may be presented for informational purposes and may not be adjustable by a user.
  • the control parameter may be adjusted only after receiving the user confirmation (e.g., a user interaction with a user interface).
  • the adjustment value may be presented to user via a user interface of the glucose control system or a user interface of the computing system.
  • the user may adjust the control parameter of the glucose control system using the adjustment value received from or presented by the computer system.
  • the adjustment at block 5808 may cause a change in the operation or execution of the control algorithm.
  • This change in the execution of the control algorithm may result in a change in one or more factors associated with the provisioning of therapy to the subject 4712.
  • the change in the execution of the control algorithm may result in a change in an amount of medicament delivered, a timing of the delivery of the medicament, a rate at which a dose of medicament is delivered to the subject 4712, a target setpoint or target range for the glucose level of the subject, a threshold used in determining whether to deliver medicament (e.g., a threshold difference from the target setpoint), or any other factor that may affect therapy delivered to the subject 4712.
  • the adjusted value of the control parameter may be output to a user (e.g., the subject or a parent).
  • the user may then configure the glucose level control system 4710 based on the selected control parameter value.
  • the glucose level control system 4710 may automatically adjust the value of the control parameter.
  • the user may be provided with an opportunity to confirm the adjustment.
  • the adjustment may occur automatically without confirmation. However, the adjustment may be presented to the user (e.g., the subject or a healthcare provider) and/or logged in a therapy log.
  • the glucose level control system 4710 provides therapy based at least in part on the updated control parameter that is updated at the block 5808.
  • the new value of the control parameter may be maintained during a second time period.
  • the second time period may refer to a specific amount of time, an amount of time to deliver a particular number of medicament doses, or a particular number of medicament doses.
  • the process 5800 may be repeated during subsequent time periods.
  • the process may be repeated periodically (every 24 hours, every two days, every week, or other time intervals).
  • the time period may be provided by the subject or a user.
  • the process may be repeated in response to a command.
  • the process may be repeated in response to determining that the subject’s 4712 glucose level does not satisfy one or more criteria for a particular amount of time. For example, the process may be repeated when a statistically significant difference between the measured mean value of the BGL and a target BGL exceeds a threshold, or a number of hypoglycemia and/or hyperglycemia detected exceeds a threshold number during a specific amount of time.
  • the process 5800 may be used to adjust several control parameters that affect the therapy delivery by the glucose control system.
  • the process 5800 may be used to adjust a first control parameter during a time period and to adjust a second control parameter during a second time period.
  • the second time period may be immediately after the first time period or delayed by a particular time.
  • the control system 4710 may determine when to adjust the control parameter.
  • a delay between periods of control parameter adjustment may be determined at least in part on the glycemic control of the glucose signal. In some cases, the delay may be determined based on input received from a user. Further, the adjustment of the second control parameter may be at least partially determined based on the determined adjustment for the first control parameter.
  • a third control parameter may be adjusted during a third time period.
  • the adjustment of the third control parameter may immediately follow the adjustment of the second control parameter or may occur after a delay.
  • the delay may be determined at least in part based on the glycemic control of the subject after the second control parameter is adjusted.
  • the glucose control system may be configured to sequentially adjust the first and second, or the first, second, and third control parameters when the glycemic control of the subject satisfies one or more threshold conditions.
  • the duration of the time period during which a control parameter is adjusted may differ from that of the first and second control parameters.
  • the process 5800 may be used to adjust one or more control parameters that affect the delivery of insulin.
  • the process 5800 is not limited as such and may be used to modify one or more control parameters that affect the delivery of other medicaments, such as a counter-regulatory agent (e.g., glucagon).
  • the process 5800 may be used to recommend a change in insulin and/or counter-regulatory agent delivery without modifying the delivery. This can be advantageous for generating recommendations regarding counter-regulatory agent in a non-bi-hormonal glucose level control system 4710 that does not support counter-regulatory agent, or that supports the use of counter-regulatory agent, but does not have the counter-regulatory agent available.
  • a value (e.g., a baseline value or optimal clinical value) of one or more control parameters of a PK model and/or control algorithm used by a glucose control system 4710 may be determined by statistical analysis of therapy data sets (e.g., glycemic control information) collected from multiple cohorts of subjects (e.g., 20, 50, 100, 200 subjects) during a clinical study.
  • the control parameter e.g., Tmax
  • Tmax may be directly measured for the subjects within each cohort (e.g., based on results of blood analysis following manual or automated medicament administrations).
  • a control parameter e.g., Tmax
  • Tmax glucose level
  • BGL glucose level
  • the subjects in each cohort may use the same values for a control parameter of the glucose control system while the subjects in different cohorts may use different values of the same control parameter.
  • the measured therapy data sets (e.g., comprising measured and/or determined glycemic control information for the subjects) over the given period may be compared using statistical analysis to evaluate an optimal value of the control parameter.
  • the measured glycemic control of subjects in a first cohort in response to setting Tmax to a first value may be compared to the measured glycemic control of subjects in a second cohort in response to setting Tmax to a second value.
  • Such comparison may include various statistical analysis that can reveal statistically significant differences between measured glycemic controls.
  • the mean value, variance and/or standard deviation of the measured glucose level data obtained from the first and second cohort may be compared to a set of reference values that may be obtained from a third cohort of subjects with normal glucose level (e.g., nondiabetic subjects).
  • a third cohort of subjects with normal glucose level e.g., nondiabetic subjects.
  • clinical studies often require several cohorts each comprising a large number of subjects (e.g., large enough to produce enable statistical analysis) and therefore large number of identical glucose control systems. For example, in some studies 10, 20, 50, or 100 subjects and glucose systems may be required. As such, determining the optimal value of one or more control parameters based on clinical studies can be expensive and time consuming. Moreover, clinical studies typically cannot capture unique physiological characteristics of and real-time physiological changes of a subject (even studies include several large cohorts).
  • a portable glucose control system that monitors the BGL in real time and autonomously or automatically provides medicament to a subject, may collect and store therapy data sets that, similar to those collected in clinical studies, may include sufficient number data points for a statistical analysis.
  • therapy data may include glycemic control information (e.g., received from a CGM sensor), other physiological effects of the therapy (e.g., obtained from subject sensors or the subject), an amount and type of medicament delivered, medicament delivery times, and the like.
  • these therapy data sets may be used to determine an optimal value of one or more control parameters of the glucose control system or a value for the one or more control parameters of the glucose control system that provides improved diabetes management compared to a default value, baseline value, or initial clinically determined value.
  • the optimal or improved values may be determined based on statistical analysis, including the type of statistical analysis that may be used in clinical studies.
  • the statistical analysis may include calculating one or more statistical quantities such as mean, variance, standard deviation, various statistical distributions (e.g., those described with respect to FIG. 57 and FIG. 59 below) and the like.
  • On board and real-time (or near real-time) evaluation of values of one or more control parameters of a glucose control system based on therapy data collected during one or more therapy periods eliminates the need for expensive and time consuming clinical studies and may improve the maintenance of a subject’s diabetes by, for example, taking into account unique physiological characteristics of and real-time physiological changes of a subject.
  • control parameter values provide for faster and more accurate diabetes evaluation and management compared to clinical testing.
  • Some of the embodiments described herein may be used to determine optimal values of one or more control parameters that may be used by a user to adjust the control parameters via a user interface of the glucose control system.
  • the glucose control system may autonomously adjust one or more control parameters using the determined optical values.
  • the therapy data collected by a glucose control system may include glycemic control information, information related to medicament delivery times, doses of medicament provided, the BGL level at the time of medicament delivery (e.g., measured based on a glucose signal obtained from a CGM sensor), the physiological effects of the medicament on a subject (e.g., BGL in a time period after medicament delivery, subjects assessment and the like), and any the type of data that may be determined from therapy provided to the subject.
  • the glucose control system may collect therapy data during one or more therapy periods.
  • the collected and stored therapy data during each therapy period may include, but is not limited to: a CGM trace G(t) 5702, delivered doses (Ui 5708) and delivery times (time t u,i ) of insulin, delivered or determined doses (Ci 14714) and delivery times (t c,i 14716), of a counter- regulatory agent (e.g., glucagon) and the like.
  • the therapy data may be stored in a memory (e.g., a flash drive, a solid-state drive, a hard disk, or any other type of non-volatile memory) of the glucose control system as one or more data sets.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Public Health (AREA)
  • General Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Medical Informatics (AREA)
  • Animal Behavior & Ethology (AREA)
  • Epidemiology (AREA)
  • Veterinary Medicine (AREA)
  • Primary Health Care (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Vascular Medicine (AREA)
  • Physics & Mathematics (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Anesthesiology (AREA)
  • Chemical & Material Sciences (AREA)
  • Hematology (AREA)
  • Pathology (AREA)
  • Medicinal Chemistry (AREA)
  • Surgery (AREA)
  • Biophysics (AREA)
  • Molecular Biology (AREA)
  • Pharmacology & Pharmacy (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Diabetes (AREA)
  • Emergency Medicine (AREA)
  • Optics & Photonics (AREA)
  • Infusion, Injection, And Reservoir Apparatuses (AREA)

Abstract

Sont divulgués un système de régulation automatisée de la glycémie qui fournit une thérapie à un sujet, telle qu'une régulation du glucose. Le système génère des signaux de commande de dose au moyen d'algorithmes de commande configurés pour déterminer de manière autonome des doses d'insuline à administrer par perfusion à un sujet. Lorsque le système détermine qu'un signal de commande de dose initial n'indique pas une thérapie saine, le système peut modifier une instruction de thérapie manuelle et transmettre un signal de commande de dose d'urgence à la pompe de médicament. Les systèmes et les dispositifs divulgués peuvent effectuer un suivi de la thérapie par insuline administrée au sujet sur une période de suivi, comprenant le stockage d'une indication des doses déterminées de manière autonome d'insuline administrée au sujet. Le système peut générer un protocole de thérapie de réserve avec des instructions de thérapie par insuline sur la base au moins en partie de la thérapie par insuline administrée au sujet sur la période de suivi.
PCT/US2022/071308 2021-03-25 2022-03-24 Commande de dose de médicament d'urgence WO2022204705A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/882,469 US20230166035A1 (en) 2021-03-25 2022-08-05 Emergency medicament dose control

Applications Claiming Priority (48)

Application Number Priority Date Filing Date Title
US17/212,984 2021-03-25
US17/212,984 US11957876B2 (en) 2019-07-16 2021-03-25 Glucose control system with automated backup therapy protocol generation
US202163167563P 2021-03-29 2021-03-29
US63/167,563 2021-03-29
US202163168203P 2021-03-30 2021-03-30
US63/168,203 2021-03-30
US202163169112P 2021-03-31 2021-03-31
US63/169,112 2021-03-31
US202163183900P 2021-05-04 2021-05-04
US63/183,900 2021-05-04
US202163194126P 2021-05-27 2021-05-27
US63/194,126 2021-05-27
US202163212521P 2021-06-18 2021-06-18
US63/212,521 2021-06-18
US202163215857P 2021-06-28 2021-06-28
US63/215,857 2021-06-28
US202163216177P 2021-06-29 2021-06-29
US63/216,177 2021-06-29
US202163238670P 2021-08-30 2021-08-30
US63/238,670 2021-08-30
US202163239365P 2021-08-31 2021-08-31
US63/239,365 2021-08-31
US202163261290P 2021-09-16 2021-09-16
US63/261,290 2021-09-16
US202163249975P 2021-09-29 2021-09-29
US63/249,975 2021-09-29
US202163276481P 2021-11-05 2021-11-05
US202163263602P 2021-11-05 2021-11-05
US63/276,481 2021-11-05
US63/263,602 2021-11-05
US202163264645P 2021-11-29 2021-11-29
US63/264,645 2021-11-29
PCT/US2021/072742 WO2022126080A1 (fr) 2020-12-07 2021-12-03 Pompes à médicament et systèmes de commande pour gérer des données de thérapie de régulation de la glycémie d'un sujet
USPCT/US2021/072742 2021-12-03
PCT/US2021/064228 WO2022140204A1 (fr) 2020-12-21 2021-12-17 Pompes à médicament et leurs systèmes de commande
USPCT/US2021/064228 2021-12-17
US202163295361P 2021-12-30 2021-12-30
US63/295,361 2021-12-30
USPCT/US2022/012795 2022-01-18
PCT/US2022/012795 WO2022159393A1 (fr) 2021-01-19 2022-01-18 Dispositif ambulatoire et composants correspondants
USPCT/US2022/017368 2022-02-22
PCT/US2022/017368 WO2022178447A1 (fr) 2021-02-19 2022-02-22 Pompes à médicament dotées de systèmes et procédés pour améliorer l'expérience de l'utilisateur
US202263320591P 2022-03-16 2022-03-16
US202263320587P 2022-03-16 2022-03-16
US63/320,587 2022-03-16
US63/320,591 2022-03-16
US202263321514P 2022-03-18 2022-03-18
US63/321,514 2022-03-18

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US17/212,984 Continuation-In-Part US11957876B2 (en) 2019-07-16 2021-03-25 Glucose control system with automated backup therapy protocol generation

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/882,469 Continuation US20230166035A1 (en) 2021-03-25 2022-08-05 Emergency medicament dose control

Publications (1)

Publication Number Publication Date
WO2022204705A1 true WO2022204705A1 (fr) 2022-09-29

Family

ID=83396117

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/071308 WO2022204705A1 (fr) 2021-03-25 2022-03-24 Commande de dose de médicament d'urgence

Country Status (1)

Country Link
WO (1) WO2022204705A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024097378A1 (fr) * 2022-11-03 2024-05-10 Insulet Corporation Titrage programmé de médicament avec un dispositif d'administration de médicament
WO2024097207A1 (fr) * 2022-11-03 2024-05-10 Insulet Corporation Utilisation de capteurs de glucose non invasifs et de données de taux de changement de glucose dans un système d'administration d'insuline

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006124716A2 (fr) * 2005-05-13 2006-11-23 Trustees Of Boston University Systeme de controle entierement automatise du diabete de type 1
US20180296757A1 (en) * 2017-04-18 2018-10-18 Animas Corporation Diabetes management system with automatic basal and manual bolus insulin control
US20200101223A1 (en) * 2018-09-28 2020-04-02 Medtronic Minimed, Inc. Insulin infusion device with configurable target blood glucose value for automatic basal insulin delivery operation
WO2020245090A1 (fr) * 2019-06-05 2020-12-10 Sanofi Dispositifs médicaux et procédés d'administration d'une dose d'insuline basale et d'une dose d'insuline bolus
WO2021011738A1 (fr) * 2019-07-16 2021-01-21 Beta Bionics, Inc. Système de régulation de la glycémie
WO2021067856A1 (fr) * 2019-10-04 2021-04-08 Beta Bionics, Inc. Système de régulation de la glycémie
US20210213200A1 (en) * 2019-07-16 2021-07-15 Beta Bionics, Inc. Glucose control system with automated backup therapy protocol generation

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006124716A2 (fr) * 2005-05-13 2006-11-23 Trustees Of Boston University Systeme de controle entierement automatise du diabete de type 1
US20180296757A1 (en) * 2017-04-18 2018-10-18 Animas Corporation Diabetes management system with automatic basal and manual bolus insulin control
US20200101223A1 (en) * 2018-09-28 2020-04-02 Medtronic Minimed, Inc. Insulin infusion device with configurable target blood glucose value for automatic basal insulin delivery operation
WO2020245090A1 (fr) * 2019-06-05 2020-12-10 Sanofi Dispositifs médicaux et procédés d'administration d'une dose d'insuline basale et d'une dose d'insuline bolus
WO2021011738A1 (fr) * 2019-07-16 2021-01-21 Beta Bionics, Inc. Système de régulation de la glycémie
US20210213200A1 (en) * 2019-07-16 2021-07-15 Beta Bionics, Inc. Glucose control system with automated backup therapy protocol generation
WO2021067856A1 (fr) * 2019-10-04 2021-04-08 Beta Bionics, Inc. Système de régulation de la glycémie

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024097378A1 (fr) * 2022-11-03 2024-05-10 Insulet Corporation Titrage programmé de médicament avec un dispositif d'administration de médicament
WO2024097207A1 (fr) * 2022-11-03 2024-05-10 Insulet Corporation Utilisation de capteurs de glucose non invasifs et de données de taux de changement de glucose dans un système d'administration d'insuline

Similar Documents

Publication Publication Date Title
US11941392B2 (en) Ambulatory medical device with malfunction alert prioritization
US20220218905A1 (en) Ambulatory medicament pump voice operation
CA3151777A1 (fr) Systeme de regulation de la glycemie
WO2022204705A1 (fr) Commande de dose de médicament d'urgence
US20230166035A1 (en) Emergency medicament dose control
US20240024578A1 (en) Ambulatory medicament pump with distress notifications
US20230337949A1 (en) Ambulatory medicament pump with distress notifications
US20230338643A1 (en) Ambulatory medicament pump with automated support contact
US20230298724A1 (en) Ambulatory medicament pump with training notifications
WO2022178447A1 (fr) Pompes à médicament dotées de systèmes et procédés pour améliorer l'expérience de l'utilisateur

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22776834

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22776834

Country of ref document: EP

Kind code of ref document: A1