WO2021067767A1 - Blood glucose control system - Google Patents

Blood glucose control system Download PDF

Info

Publication number
WO2021067767A1
WO2021067767A1 PCT/US2020/054025 US2020054025W WO2021067767A1 WO 2021067767 A1 WO2021067767 A1 WO 2021067767A1 US 2020054025 W US2020054025 W US 2020054025W WO 2021067767 A1 WO2021067767 A1 WO 2021067767A1
Authority
WO
WIPO (PCT)
Prior art keywords
medical device
application
therapy
ambulatory medical
subject
Prior art date
Application number
PCT/US2020/054025
Other languages
English (en)
French (fr)
Inventor
Edward R. DAMIANO
Firas H. EL-KHATIB
Michael J. Rosinko
Justin P. Brown
David Chi-Wai LIM
Bryan Dale Knodel
Himanshu Patel
John R. COSTIK
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 PCT/US2020/042195 external-priority patent/WO2021011697A1/en
Priority claimed from PCT/US2020/042198 external-priority patent/WO2021011699A1/en
Priority claimed from PCT/US2020/042269 external-priority patent/WO2021011738A1/en
Priority to MX2022003961A priority Critical patent/MX2022003961A/es
Priority to CN202080084028.1A priority patent/CN114868200A/zh
Priority to DE112020004762.8T priority patent/DE112020004762T5/de
Application filed by Beta Bionics, Inc. filed Critical Beta Bionics, Inc.
Priority to EP20872387.4A priority patent/EP4042441A4/en
Priority to JP2022520424A priority patent/JP2023503792A/ja
Priority to CA3151777A priority patent/CA3151777A1/en
Priority to AU2020358856A priority patent/AU2020358856A1/en
Publication of WO2021067767A1 publication Critical patent/WO2021067767A1/en
Priority to IL291671A priority patent/IL291671A/en

Links

Classifications

    • 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
    • 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
    • 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/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
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running
    • 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
    • G16H15/00—ICT specially adapted for medical reports, e.g. generation or transmission thereof
    • 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/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/63—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 local 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
    • 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/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • 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
    • A61M2005/1401—Functional features
    • 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
    • A61M2202/00—Special media to be introduced, removed or treated
    • A61M2202/07—Proteins
    • 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/33—Controlling, regulating or measuring
    • A61M2205/3303—Using a biosensor
    • 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/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/35—Communication
    • A61M2205/3576—Communication with non implanted data transmission devices, e.g. using external transmitter or receiver
    • A61M2205/3592—Communication with non implanted data transmission devices, e.g. using external transmitter or receiver using telemetric means, e.g. radio or optical transmission
    • 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
    • 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
    • A61M2205/505—Touch-screens; Virtual keyboard or keypads; Virtual buttons; Soft keys; Mouse touches
    • 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/52—General characteristics of the apparatus with microprocessors or computers with memories providing a history of measured variating parameters of apparatus or patient
    • 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/60—General characteristics of the apparatus with identification means
    • A61M2205/609—Biometric patient identification means
    • 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
    • A61M2230/00—Measuring parameters of the user
    • A61M2230/20—Blood composition characteristics
    • A61M2230/201—Glucose concentration
    • 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/1407—Infusion of two or more substances
    • A61M5/1408—Infusion of two or more substances in parallel, e.g. manifolds, sequencing valves

Definitions

  • 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.
  • SUMMARY [0004] Blood glucose control systems and ambulatory medical devices that provide therapy to a subject, such as blood glucose control, are disclosed.
  • 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.
  • FIG. 1A illustrates an example blood glucose control system that provides blood glucose control via an ambulatory medicament pump.
  • FIG. 1B illustrates another example blood glucose control system that provides blood glucose control via an ambulatory medicament pump.
  • FIG. 1C illustrates a further example blood glucose control system that provides blood glucose control via an ambulatory medicament pump.
  • FIG. 2A shows a block diagram of an example blood glucose control system.
  • FIG. 2B shows a block diagram of another example blood glucose control system.
  • FIG. 2C shows a block diagram of another example blood glucose control system.
  • FIG. 2D shows a block diagram of another example blood glucose control system.
  • FIG.3 is a schematic of an example glucose control system that includes an electronic communications interface.
  • FIG.4A shows a block diagram of an example blood glucose control system in online operation mode.
  • FIG.4B shows a block diagram of an example blood glucose 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.5A.
  • FIG. 5A illustrates a perspective view of an example ambulatory medical device.
  • FIG. 6 illustrates different modules that may be included in an example ambulatory medical device (AMD).
  • FIG.7 illustrates various methods and links that AMD may use to establish a communication 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 downloaded 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, verify and switch control of the AMD from a first application to the second application without interrupting the therapy provided to a subject, only 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 of the 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.15A 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.15B is a flow diagram illustrating an example method that may be used by an AMD to transmit therapy to a computing system in a networked computing environment.
  • 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.31 FIG.
  • 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. [0036] FIG.
  • 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. [0050] FIG.
  • FIG. 33A 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. 33B is an illustration of a user interface provided on a touch screen display for accessing the alarm notifications screen when the touch screen display is locked.
  • FIG. 33C is an illustration of a user interface user interface provided on a touch screen display for accessing the alarm notifications screen when the touch screen display is unlocked.
  • 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. [0054] FIG.
  • 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 is a flow diagram of a process for receiving manual entry of a medicament dose on an ambulatory device.
  • 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 blood glucose control system can operate in conjunction with an infusion system to infuse one or more medicaments, including at least one blood 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 blood glucose control system is used to control blood glucose level in a subject.
  • Blood glucose 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 include regulatory agents that tend to decrease blood glucose level, such as insulin and insulin analogs, and counter-regulatory agents that tend to increase blood glucose level, such as glucagon or dextrose.
  • a blood 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 blood glucose 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.
  • Glucose control agents can be delivered to a subject via subcutaneous injection, via intravenous injection, or via another suitable delivery method.
  • An ambulatory medicament pump 100 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, or an AMD.
  • Ambulatory medical devices include ambulatory medicament pumps and other devices configured to be carried by a subject and to deliver therapy to the subject. Multiple AMDs 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.
  • 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.
  • FIGS.1A-1C show examples of blood glucose control systems that provide blood glucose control via an ambulatory medicament pump connected to a subject.
  • the medicament pump 100 is connected to an infusion site 102 using an infusion set 104.
  • the medicament pump has integrated pump controls 106a that permit a user to view pump data and change therapy settings via user interaction with the pump controls 106a.
  • a glucose level sensor 110 generates a glucose level signal that is received by the blood glucose control system.
  • the medicament pump 100 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 106a and 106b can be manipulated via user interaction with user interface elements of the external electronic device 108.
  • the glucose level sensor 110 can also communicate with the medicament pump 100 via a wireless data connection.
  • the medicament pump 100 includes an integrated cannula that inserts into the infusion site 102 without a separate infusion set. At least some of the pump controls 106b can be manipulated via user interaction with user interface elements 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 medicament pump 100 via a direct or indirect electronic data connection.
  • Glucose 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, or touchscreen interfaces.
  • FIGS.2A-2D illustrate block diagrams showing example configurations of a glucose control system 200a/200b/200c/200d.
  • a glucose control system 200a can include 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 an ambulatory medical device (AMD) 100.
  • the pump 212 can be a regulatory agent pump and/or counter-regulatory agent pump.
  • the AMD 100 can have one or more pumps 212.
  • the AMD 100 can include a transceiver or wireless electronic communications interface 214a for wireless digital data communications with external electronic devices.
  • the controller 202a can implement at least a portion of a control algorithm that generates dose control signals for one or more glucose 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 medicament pump 100) and one or more control parameters.
  • a glucose control system 200b can operate at least partially via execution of instructions 208b by an electronic processor 204b of an electronic device 108 separate from the ambulatory medical device 100.
  • the electronic device 108 can include a transceiver 214b capable of establishing a wireless 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 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, result in dosing operations that control the blood glucose of a subject.
  • the dose control signals are transmitted from the device transceiver 214b to the AMD transceiver 214a 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. [0075] As shown in FIG.
  • a glucose 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.
  • the controller 202c can implement at least a portion of a control algorithm that generates dose control signals for one or more glucose 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, result in dosing operations that control the blood glucose of a subject.
  • the dose control signals are transmitted from the remote computer 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 for dosing operations.
  • a glucose control system 200d can have two or more controllers 202a, 202b, 202c that cooperate to generate a dose control signal for dosing operations by the pump 212.
  • a remote computer 206 can transmit or receive data or instructions passed through a WAN connection interface 220c via a WAN wireless data connection 218 to a WAN connection interface 220b of an electronic device 108.
  • the 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 electronic device 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.
  • 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 control system 200 includes circuitry that implements an electronic communications interface (ECI) 302 configured to send and receive electronic data from one or more electronic devices.
  • ECI electronic communications interface
  • the ECI includes a sensor interface or glucose sensor interface 304 configured to receive a glucose level signal from a glucose level sensor 110 such as a continuous glucose monitor (CGM). Some CGMs generate the glucose level signal at fixed or periodic measurement intervals, such as five-minute intervals.
  • the glucose level sensor 110 can be operatively connected to a subject in order to generate a glucose level signal that corresponds to a blood glucose estimate or measurement of the subject.
  • the glucose level signal can be used by the controller 202 to generate a dose control signal.
  • the dose control signal can be provided to a pump 212 via a pump interface or delivery device 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. In other embodiments, the pump interface 306 connects to the pump 212 via a local data bus, such as when the controller 202, the ECI 306, and the pump 212 are integrated into an AMD 100.
  • the controller 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. Examples of control algorithms that can be used to generate these doses are disclosed in U.S. Patent Application Publication Nos.
  • the correction dose can include regulatory or counter-regulatory agent and can be generated using a model- predictive control (MPC) algorithm such as the one 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. 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.
  • the controller 400 can be configured to operate in “online mode” during time periods when the controller receives a glucose level signal 402 from a glucose level sensor 110.
  • 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 control parameters of the control algorithm.
  • the pump 212 is 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 controller 400 can be configured to operate in “offline mode” during time periods when the controller does not receive a glucose level signal 402 from a sensor 110, at least during periods when the glucose level signal 402 is expected but not received.
  • 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 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) that provides life-saving treatment to a subject by delivering one or more medicaments (e.g., insulin and/or glucagon) to a subject.
  • Some AMDs may continuously monitor the health condition of a subject (e.g., blood glucose level) using a sensor (e.g., a blood glucose level sensor that can measure values corresponding to the blood glucose level) and deliver therapy (e.g., one or more medicaments) to the subject based on the condition of the subject.
  • Certain ambulatory medicament devices 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., heart beat monitor or electrodes monitoring activity of the brain).
  • FIG. 5A illustrates a three-dimensional (3D) view of an example ambulatory medical device (e.g., an ambulatory medicament delivery pump such as an insulin pump) 500 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 AMD 500 shown in FIG. 5A.
  • all the electronic systems 508 are included inside the housing 502, for example, as a single integrated electronic board.
  • 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.
  • 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).
  • a 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.
  • 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.
  • FIG. 6 illustrates different modules that may be included in an example AMD 500 (e.g., a glucose control system).
  • the AMD may comprise a complete glucose control system (e.g., AMD 100 and glucose control system 200a).
  • the AMD may include one or more systems that can facilitate monitoring a subject’s blood glucose level, maintaining the subject’s diabetes, tracking a condition of the AMD, and/or communicating with one or more computing systems.
  • the AMD 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 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 and/or the main unit via a wired or wireless communication link (e.g., Bluetooth).
  • the modules included in the AMD may include a communication module 602, signal processing module 604, a therapy delivery module 606, a user interface module 608, and a control and computing module 610.
  • 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.
  • one or more modules 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, or any other type of non-volatile memory.
  • a module may include several procedures each implemented based on different sets of instructions.
  • the control and computing module 610 may include one or more processors 614, a main memory 616, a storage 618 that may comprise one or more non-transitory and/or non-volatile memories and an interface 612 that enables data and signal communication among systems within the control and computing module 610 as well as communication between the control and computing module 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 via 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 through the main memory 616.
  • the storage 618 may store data while the control and computing system 610 is powered or unpowered.
  • 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”).
  • the 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 system 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 system 610.
  • the interface 612 may also support data and signal exchange among other modules as well as data exchange between any of the modules and 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., A-to-D or ADC conversion and D-to-A conversion 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 signal processing module may receive a digital control signal from the control and computing module 610 and convert it to an analog 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 606.
  • the therapy delivery module 606 may comprise one or more infusion pumps configured to deliver one or more medicaments (e.g., insulin or glucagon) to a subject 627.
  • the medicaments may be stored in one or more medicament cartridges housed in the therapy 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).
  • 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 to request for certain actions (e.g., installing a software) and the like.
  • the alphanumeric pad may include a multitude of keys with numerical, alphabetical, and symbol characters. In different embodiments, the keys of the alphanumeric pad may be capacitive or mechanical.
  • the user may be a subject 627 receiving medicament or therapy, or may be another user, such as a clinician or healthcare provider, or a parent or guardian of the subject 627.
  • the AMD 600 may include a touchscreen display that produces output and also 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 also 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 keypad may be a display of a keypad.
  • 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 to a user enabling the user to modify one or more therapy settings of the ambulatory medicament device.
  • 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.
  • 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 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.
  • WANs wide area networks
  • 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.
  • 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 AMD 600 (e.g., a blood glucose level sensor), a mobile device (e.g., smart phone, a laptop 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 end-to-end communication between the AMD 600 and a server or a cloud network.
  • the AMD may communicate with an intermediary device (e.g., a smart phone or other mobile devices, a personal computer, a notebook, and the like).
  • the AMD may include an eSIM card that stores information that may be used to identify and authenticate a mobile subscriber.
  • the eSIM card may enable the AMD to function as an IoT device that can communicate over a network that supports communication with IoT devices.
  • the AMD may be configured to transmit data using a narrowband communication protocol such as 2G or EDGE.
  • the AMD 600 may be paired with a mobile device at inception and permit real-time data access to the AMD 600 by a healthcare provider.
  • the AMD 600 may include a geolocation receiver or transceiver, such as a global positioning system (GPS) receiver.
  • GPS global positioning system
  • 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.
  • Example Operation of the AMD [0089]
  • the AMD 600 (or AMD 100) may continuously, periodically, or intermittently receive information about one or more parameters that are correlated with a health condition of the subject 627 (e.g., blood glucose level, blood glucose trend, heart rate, body movement indicia, etc.).
  • This information may be encoded to a signal provided to AMD 600 by a glucose level sensor hereinafter referred to as “subject sensor” 620 (e.g., a wearable biomedical sensor that measures an analyte in the interstitial fluid) that is connected to the AMD 600 via a wired or wireless link (e.g., Bluetooth).
  • the signal sent by the subject sensor 620 may be received by the communication module 602 and transmitted to a signal processing module 604 that converts the signal to a machine- readable signal (e.g., a digital signal).
  • a second communication module may be included in the AMD 600 to communicate with the subject sensor 620.
  • the signal processed by the signal processor module 604 may be transmitted to the control and computing module 610 where the signal may be analyzed to determine whether medicament should be delivered to the subject 627. If it is determined that medicament should be administered to the subject, the control and computing module may determine the dosage and type of medicament to administer based on the information received from the subject sensor 620 and send a dose signal to the therapy delivery module 606 (e.g., directly or via the signal processing module 604) to initiate the medicament delivery to the subject (e.g., using an infusion pump of the therapy delivery module 606).
  • the therapy delivery module 606 e.g., directly or via the signal processing module 604 to initiate the medicament delivery to the subject (e.g., using an infusion pump of the therapy delivery module 606).
  • one or more procedures within the control and processing 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, next delivery time, level of certain analytes in the subject’s blood and the like) via the user interface module 608, processing the information received from a subject sensor 620 via the user interface 608, and the like.
  • 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., different version) 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. In some such examples, if needed, the control of the device can be switched from the first software application to the second software application.
  • the AMD 600 may deliver multiple types of therapies that are selectable by a user or the control and computing module 610. For example, the AMD 600 may deliver the therapy of infusing insulin into a user and may also deliver the therapy of infusing glucagon into the 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 in part based on the information received from the subject sensor 620.
  • FIG.7 illustrates various methods and links or communication paths that an AMD 702 may use to communicate (e.g., by establishing a connection) with a host computing system 704, for example, to obtain an application update, send and/or receive therapy reports, receive passcodes, receive control parameters and the like.
  • the host computing system 704 may be a server 706 or a computing system within a cloud computing network 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 healthcare provider).
  • the AMD 600 may establish a connection (e.g., using the communication module 602) with the host computing system 704 through an intermediary device 710 (e.g., a smart phone or other mobile devices, a personal computer a notebook or the like).
  • the AMD 600 may receive an application update from a local 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 600 may communicate with the host computing system 704 through a local area network (LAN) and/or through a Wi-Fi connection.
  • the AMD 600 may establish a communication connection to the host computing system 704 via a wide area network (WAN) 716.
  • WAN wide area network
  • the communication between the AMD 600 medical device and the cloud computing service may be encrypted.
  • the AMD 600 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.
  • WAN wide area network
  • 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 600), 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 600. In some examples, 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 600. In some implementations, the host computing system 704 may establish a direct end-to-end data connection with the AMD 600 based on receiving a device identifier associated with the AMD 600. The device identifier may be a unique identifier specific to the AMD. In some other implementations, establishing the direct end-to-end data connection may include determining that the AMD 600 is permitted to communicate with the host 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 AMD 600 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 600.
  • 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 600.
  • IP Internet Protocol
  • MAC Media Access Control
  • serial number a subject identifier of a subject that receives therapy from the AMD 600.
  • the subject or a user may establish or initiate establishing the direct end-to-end data connection with the host computing system 704.
  • the direct end-to-end data connection may be initiated or established without any action by the subject or the user.
  • the direct end-to-end data connection may be established automatically at particular times and/or when the AMD 600 is in a particular location. In some such cases, this automatic connection may occur using information supplied to the AMD 600 at a time of manufacture, shipment, sale, or prescription to the subject. Alternatively, or in addition, a subject or other user may configure the AMD 600 to automatically connect to the host computing system 704 at particular times and/or locations.
  • the wide area network may include, or may communicate with, the Internet 714. [0095] In some embodiments, the AMD 600 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 600 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 600 to the network provider.
  • IMEI International Mobile Equipment Identity
  • fees can be negotiated between the manufacturer and the network provider or between the subject’s health insurance and the network provider. Similarly, fees may be paid by the manufacturer or health insurance provider, or other entity, without subject involvement.
  • the subject’s AMD 600 may be configured to communicate via the network of the network provider without any action by the subject or the user.
  • the subject may be responsible for obtaining wireless service to connect the AMD 600 to a wide area network 716 (e.g., a cellular network).
  • the AMD 600 may be pre-registered or authenticated with a computing network of the cloud services provider as part of the manufacturing process or before AMD 600 is provided to the subject. This enables the AMD 600 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 600 with the subject at the computing network of the cloud services provider.
  • the AMD 600 may use a whitelist, or approved list, that identifies via a unique identifier (e.g., via an IP address, a MAC address, or a URL) one or more permitted cloud servers or computing systems of the cloud computing system 708 that the AMD 600 is permitted to access.
  • a unique identifier e.g., via an IP address, a MAC address, or a URL
  • the AMD 600 may include a blacklist, or restricted list, that identifies systems the AMD 600 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 computing service may have a whitelist, or approved list, that uses unique identifiers to specify AMD 600 and/or other computing systems (e.g., remote display systems) that are permitted to communicate with the cloud computing system 708.
  • the cloud computing service 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.
  • 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.). It should be understood that 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.
  • a publicly accessible whitelist or a whitelist accessible by more than one authorized system or user may not include passwords or access codes.
  • the AMD 600 may use a whitelist that identifies via, for example, a unique identifier (e.g., via an IP address, a MAC address, or a URL) permitted cloud servers or computing systems of the cloud computing system 708.
  • the cloud computing system may have a whitelist that uses unique identifiers to specify AMD 600 and/or other computing systems (e.g., remote display systems) that are permitted to communicate with the cloud computing system 708.
  • the whitelist may be stored in a memory of AMD 600 and/or in a memory of a trusted computing device that is accessible by the AMD 600.
  • the trusted computing device can include any computing device that a manufacturer of the AMD has identified as trusted. Alternatively, or in addition, the trusted computing device can include any computing device that a subject or user that helps caste for the subject (e.g., parent, guardian, healthcare provider) has identified as a trusted computing device that is designated to store the whitelist.
  • the whitelist may be configured during manufacture of the AMD 600. 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 600 may be configured to execute the specific computer-executable instructions to at least obtain an address of a computing system from the whitelist and to establish a direct end-to-end data connection to the computing (e.g., a computing system in the networked-computing environment), via a wireless wide area network using the address.
  • the AMD 600 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.
  • Application Update of Ambulatory Medical Device [0100] It is often the case that a computer or software application is updated after it is released.
  • an application used to control or provide features for a medical device (e.g., an automated blood glucose control system or other AMD).
  • the application is updated to patch bugs or vulnerabilities.
  • the application is updated or replaced with a new version to introduce new features or improve existing features, or to provide access to newly purchased, licensed, or otherwise obtained features.
  • an application is shutdown or is not executing while the application is updated. For most applications, there is minimal to no harm in shutting down or not executing an application while it is updated or otherwise replaced. For example, it is inconsequential that a video game, word processing, or edutainment application is not executing while it is updated.
  • an application on an ambulatory medical device AMD
  • AMD ambulatory medical device
  • harm may occur to the subject.
  • the AMD is an insulin pump, such as those that may be used by a type-1 diabetic. If the insulin pump becomes inoperative due to an application update process occurring at a time when a subject’s blood glucose level exceeds a set-point or target range, the user may not receive a necessary insulin bolus from the AMD.
  • an AMD includes a computer-implemented method of updating an application executing on the AMD without interrupting, or while causing minimal interruption, to therapy provided by the AMD 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 AMD 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 include a binary executable file that may be executed by various processors of the AMD.
  • the application update may be a new version of the application, a replacement or substitute application, or an application patch. Further, the application update may add or remove features to the version of the application installed on the AMD. In some examples, the application update may be an older version of the application that has been used by instances of the AMD for more than a threshold period of time and has experienced less than a threshold number of faults.
  • the application to be updated on the AMD may be currently executing on the ambulatory medical device or may be executed in future.
  • the application update may be stored in one or more host computing systems. In some cases, the application update may be pushed to the host computing systems by a company that manages or manufactures the ambulatory medical device or other software company that is authorized by the manufacturer or licensee of the device.
  • the host computing system comprises a server computing device, a cloud computing device, a computing device of a healthcare provider, a computing device of a manufacturer of the AMD, an application server, or other network accessible computing device or system.
  • the application update may be stored in a local computing device, for example, a local computing device of the subject (e.g., a smartphone, a laptop or a personal computer).
  • FIG. 8 is a flow diagram showing an example of a computer-implemented method that may be used by the AMD 600 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 may be stored.
  • the AMD 600 may directly communicate with the host computing system.
  • the AMD 600 may communicate with a proxy or other system to determine the availability of an application update or to acquire the application update.
  • the application update may be obtained from a content delivery network (CDN) or cache server.
  • the AMD 600 such as a medicament delivery device or a medicament pump may receive an indication that an update is available for an application, such as control software or other software that controls or facilitates the operation of the AMD 600.
  • the indication may be a determination made by a software or hardware module included in the AMD 600.
  • the AMD 600 may access a particular host computing system (e.g., using its communication module) to determine whether an update is available, based on a set of update trigger conditions stored in a memory of AMD 600.
  • the set of update trigger conditions may include any type of trigger condition that may cause the AMD 600 to determine if a software update is available and/or to update an application executing on the AMD 600.
  • the set of update trigger conditions may be defined/changed by a user and/or received by AMD 600 from a host computing system.
  • an update trigger condition may push the AMD 600 to periodically search for an update at time intervals set by the user or received from a host computing system.
  • an application update availability check may be triggered by the AMD 600. The application update availability check may be performed in response to a time trigger or any other type of trigger.
  • an update availability check trigger can be a user command, the replacement of medicament within the ambulatory medical device, connecting to a particular network (e.g., connecting to a Wi-Fi network using a wireless transceiver, or the like), a scheduled time being reached, an occurrence of a fault, an occurrence of a particular condition in the AMD, or any other type of trigger.
  • the indication that the application update is available comprises an indicator of whether the application update corresponds to a first application version or a second application version of the application.
  • the AMD 600 may access an update server to determine whether the application update exists, and in response to accessing the update server, receive the indication that the application update is available.
  • a trigger to connect to an update server to determine the availability of an application update may include a detection of a fault with the currently executing application or an indication of a change in permitted features that a user or subject is permitted to access with the AMD 600.
  • the host computing system may query or access the AMD 600 to determine an installed software version of the application and/or a hardware configuration to determine the eligibility of the ambulatory medical device for a software upgrade.
  • the eligibility for the software upgrade may be based at least in part on a license or warranty.
  • the serial number, the model number, and/or the software version may be used to determine application update (e.g., a software upgrade) eligibility.
  • the eligibility for an application update may be determined based on the geoposition of the device and/or whether the device is connected to a local area network (e.g., a Wi-Fi network) or a wide area network (e.g., a cellular network).
  • the ambulatory medical device may have a transceiver and an antenna that provides the device with GPS, text or picture messaging, telephone calling, and data transfer capabilities.
  • the application update may be provided on a limited release, such as to test groups of varying size, e.g., 1-100, 1-1000, or 1-10000 users. Further, there may be a phased rollout of the application updates to different groups of users.
  • the AMD 600 may respond to an upgrade eligibility request by transmitting an identity of a version of the application or a model identification information of the AMD 600 or a manufacturing date of the AMD 600 to the host computing system.
  • the AMD 600 may establish a communication connection to a host computing system that hosts the update to the application.
  • Such connection may be established, for example, via one or more links or methods discussed above with reference to FIG. 7.
  • the AMD 600 may communicate with a cloud 708 or a server 706 using a local area network 712, Internet 714, or wide area network 716.
  • a healthcare provider system may push the update to the AMD 600.
  • a communication connection via wide area network 716 may be a direct end-to-end communication connection.
  • the communication connection with the host computing system may be established via an intermediate device 710 (e.g., a personal computing device of the user or the subject).
  • the AMD 600 may establish a direct end-to-end data connection to a host computing system via a wireless wide area network (WAN).
  • WAN wireless wide area network
  • the direct end-to-end data connection may comprise a narrow band long-term evolution (NB-LTE) connection, an NB Internet-of-Things (NB-IoT) connection, a cellular IoT connection, a 4G LTE connection, or a 5G connection.
  • the direct end-to-end data connection may be a connection that is directly between the AMD 600 and the host computing system allowing without an intermediary system or computing device within a local area network of the AMD 600 being involved in the communication.
  • a direct end-to-end data connection may include routing data or the connection through networking hardware, base stations, or other devices included in a wide area network, such as the Internet. However, other computing devices within a local area network that includes the AMD 600 may be omitted.
  • the AMD 600 does not communicate with a smartphone, laptop, smart appliance, or other device within a local area network of a user or subject that uses the AMD 600.
  • the AMD 600 may communicate with an intermediary system to obtain the application update.
  • the application update may be downloaded to a local system (e.g., a laptop or smartphone of the user), and then provided to the AMD 600 via a local area network, a USB connection, a near-field communication technology (e.g., Bluetooth, ZigBee, LoRa, etc.).
  • a local system e.g., a laptop or smartphone of the user
  • a near-field communication technology e.g., Bluetooth, ZigBee, LoRa, etc.
  • the AMD 600 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 may be little or no interruption to therapy provided by the AMD 600 while the application update is being obtained by the AMD 600.
  • the AMD 600 may be linked to an intermediary device 710 (e.g. a mobile device) via a communication link (e.g., Bluetooth, WiFi, NFC or other wireless or wired means of communications).
  • the AMD 600 may include a SIM card or an electronic SIM (eSIM) card that stores information for identifying and authenticating a mobile intermediary device.
  • the eSIM card enables the AMD 600 to function as an IoT device that can communicate or transmit data over a network that supports communication with IoT devices.
  • the ambulatory medical device may be configured to transmit data in a narrowband communication protocol such as 2G or EDGE, NB-LTE, 5G, etc.
  • the intermediary device 710 may also communicate with a cloud 708, a server 706.
  • the software update may be initially downloaded by the intermediary device that communicates with the AMD 600 periodically or at pairing.
  • the intermediary device may determine if the AMD 600 is eligible for the software update based at least partially on the serial number, manufacturing date, current software version, model number, and most recent software image on the cloud 708 or the server 706, and the like.
  • the intermediary device may download the target image and transfer the image to the AMD 600.
  • the application or the application comprises one of a first application version comprising a first feature set or a second application version comprising a second feature set.
  • both application versions may have the same feature set, but the feature set may include an improved or modified version of at least one of the features.
  • one of the application versions may have a user interface that is less cluttered compared to the other application version.
  • one of the application versions may support a meal controller while the other application version may not.
  • the AMD 600 may download the first application update corresponding to the first application version or a second application update corresponding to the second application version.
  • the AMD 600 may download the first application update or the second application based at least in part on the application version of the application. [0112] Once the application update is obtained, at the decision block 808 the AMD 600 may perform one or more operations to confirm that the downloaded copy of the application update is complete and/or is not corrupted (e.g., using its control and computing module 610). To determine that the downloaded application update is complete and/or not corrupted, the AMD 600 may calculate a hash or checksum value from the downloaded application update and may compare the calculated hash or checksum value with a received hash or checksum value 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 complete and/or not corrupted.
  • the AMD 600 may calculate a hash or checksum value from the downloaded application update and may compare the calculated hash or checksum value with a received hash or checksum value received from the application host system. If the calculated hash or checksum value matches the received hash or checksum value
  • the AMD 600 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. If it is determined that the download is corrupt and/or did not download completely, the AMD 600 may discard the corrupted or incomplete copy of the update. The AMD 600 may attempt to download another copy of the update and/or alert a user to the failed attempt to download the application update or to update the application. If it is determined that the download is complete and not corrupt, the AMD 600 may proceed to the installation step 810 where the application update may be installed on the AMD 600 without interrupting the ongoing or upcoming therapy sessions. [0113] FIG.
  • FIG. 9-11 are flow diagrams illustrating examples of computer- implemented methods that may be used by the AMD 600 to install a downloaded application update without disrupting the therapy provided to a subject.
  • the AMD 600 verifies that an uncorrupted copy of the update for an application is successfully downloaded (e.g., using the procedure described above with reference to FIG. 8).
  • AMD 600 e.g., the control and computing module (CCM) 610 of the AMD 600
  • CCM control and computing module
  • the installation time may be an execution time for executing a process to install the downloaded copy of the application update.
  • the installation time may be an amount of time to perform the installation process.
  • the time determined at the block 904 is an estimated install time.
  • a general-purpose computing system may execute any number or type of applications, and it is unknown what applications a particular user may decide to execute.
  • an AMD typically is special purpose and it is generally known what applications it executes.
  • the only application executing may be control software or user interface software.
  • the estimate of installation time will be close to the actual installation time.
  • differences in manufacture of electronic elements or natural deterioration of components (e.g., memory) over time may lead to some small changes in installation time application. Accordingly, the install time for the application may, in some cases be buffered or padded to ensure that the estimated or determined install time is not shorter than the actual install time for the application update.
  • the installation time may be determined by the CCM 610 based on the data or metadata included in the downloaded application update.
  • the application update may include a file (e.g., a text file or configuration file) that includes the install time or an estimate thereof.
  • the installation time may be determined by the manufacturer of the ambulatory medical device or the publisher of the application update.
  • 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 (e.g., by the manufacturer or the CCM 610 of the AMD 600).
  • 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 AMD may notify the user that an application update is available for installation and wait for a trigger signal to initiate the installation process.
  • the AMD 600 may notify the user through a user interface (e.g., a touchscreen display), that an update downloaded and is ready for installation.
  • the notification may include the installation time and information about the update, such as what features are modified or added, or what bugs are patched or fixed.
  • the AMD 600 may determine whether an installation trigger is received or not. If the installation trigger is not received, AMD 600 may send one or more notifications to the user indicating that a new update is ready for installation. In some examples, the installation trigger may be the confirmation that the application was successfully downloaded.
  • the application may be automatically installed.
  • the installation trigger may be an installation command received based on an interaction of a user or subject with a user interface that is part of or that communicates with the ambulatory medical device.
  • the AMD 600 may provide an option to the user to select a time at which the application will be installed and/or may permit the user to request a reminder to install the application update at a later time.
  • the installation trigger may comprise a determination that the downloaded copy of the application update is complete, a determination that the downloaded copy of the application update is not corrupted, or a detection of a fault during execution of an application currently running on or controlling the AMD.
  • the AMD 600 determines if therapy is currently being administered to the subject. If the AMD 600 determines that no therapy is currently being administered, the process proceeds to block 914, If the AMD 600 determines that therapy is currently being administered, the system proceeds to block 912 and waits until the therapy session is completed delaying the installation of the application or application update at least until the therapy session or the administering of the therapy is complete. In some cases, the AMD 600 may continue to check whether there is ongoing therapy occurring. Ongoing therapy may at least include administering a medicament. However, other actions may be included as part of the ongoing therapy, such as performing one or more physiological parameter measurements. Once the current therapy session is complete or is determined to be complete, the process may proceed to block 914.
  • the AMD 600 may determine an amount of time or a time remaining until a scheduled or anticipated next therapy delivery time (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, etc.). Further, in some cases, the determination of the next therapy delivery time period may be determined by querying a user (e.g., the subject).
  • a dose control signal can be generated at a next scheduled dosage period after determining that a resumption condition has occurred as discussed herein. In some examples, a dose control signal can be generated immediately after, or shortly after, determining that the resumption condition has occurred. [0120] As previously described, it is desirable to prevent disruption to therapy during the application update process.
  • the AMD 600 may compare the estimated installation time 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 the AMD 600 determines that the time left until the next therapy session is sufficiently longer (e.g., the length of installation time, or the estimated installation time and a minimum additional time buffer) than the determined time for completing the installation, the process may proceed to block 918 where installation of the application update may be initiated. In some examples, the determined time to the next therapy session may be required to be longer than the determined installation time by a threshold value before installation may be permitted to commence.
  • the threshold value may vary for different application updates and/or the type of therapy to be administered during the next scheduled or anticipated therapy session. If at the decision block 916 it is determined that the application installation cannot be completed before the next therapy delivery (or the time left until the next therapy is not larger than that estimated installation time by a threshold value), the installation of the application may be delayed, regardless of receipt of the trigger. In this case, the process may return to block 914 where the AMD 600 waits for the next therapy to be completed and then determines a new therapy time. This process may be repeated until AMD 600 determines that the update can be installed without interrupting an expected or scheduled therapy delivery by the AMD. In some examples, 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.
  • the AMD may cause an alert to be output for display to a user.
  • 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.
  • FIG. 10 is a flow diagram illustrating an example of a computer- implemented method that may be used by the AMD 600 in order to install a second application that is an update to a first application executing on the AMD 600, without disrupting the therapy provided to a subject.
  • the AMD may identify and download the second application update using the process described with reference to FIG. 8.
  • the second application update may be a new version of the application, a patch to the application, an older version of the second application, or a replacement application for the application.
  • the second application may be a version of the first application that has been determined to operate without fault with a threshold degree of certainty.
  • the AMD 600 verifies that an uncorrupted copy of the second application is successfully downloaded.
  • block 1002 may include one or more of the embodiments previously described with respect to block 808 in FIG. 8 and/or block 902 in FIG. 9.
  • the AMD 600 may initiate the installation process of the second application without interrupting the execution of the first application.
  • the application update may be installed in a different memory location or separate area of the volatile memory than the memory location or area of the volatile memory where the original application (or current version of the application) is installed and executed.
  • the second application may be executed in a second execution space that is separate from the first execution space.
  • the separate execution spaces may be in separate areas of a volatile and/or non-volatile memory.
  • the first and second application may be stored in separate areas of the non-volatile memory.
  • the first and second application may each be allocated separate areas of a volatile memory for execution.
  • the separate areas of the volatile memory may serve as separate sandboxes preventing interference between the execution of the first application and the second application.
  • the first application may be executed by a first controller and the second application may be executed by a second controller. [0124]
  • the AMD 600 may confirm the successful installation of the second application and wait for a trigger signal.
  • the AMD 600 may send a notification to the user via a user interface of the AMD (e.g., a touchscreen display) and request a trigger to execute the second application and switch control of the AMD 600 from the first application to the second application.
  • the AMD 600 may determine whether a trigger is received or not.
  • the AMD 600 may determine the amount of time required for switching the control of AMD 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 AMD.
  • the trigger may be a confirmation of successful installation of the second application or a detection of a fault during execution of the first application by the AMD 600.
  • the trigger may be an indication of an availability of the second application or a detection of an application fault associated with execution of the first application.
  • the trigger may be based at least in part on whether therapy is currently being administered and/or the timing of a subsequent therapy to be delivered. [0125] If at the decision block 1010 the AMD 600 determines that a trigger is not received, the process may return to block 1008 where the AMD 600 may send one or more notifications to the user indicating that a new update is ready for installation.
  • the AMD 600 may check whether a therapy session is ongoing or not. If the AMD 600 determines that therapy is currently being administered, the process proceeds to block 1014 and the AMD 600 waits until the therapy delivery is complete. Once the current therapy session is complete, the process proceeds to block 1016. If at decision block 1012 the AMD 600 determines that therapy is not currently being administered, the process proceeds to block 1016.
  • the block 1012 may include one or more of the embodiments previously described with respect to the block 910. [0126] At block 1016 the AMD 600 determines an amount of time until or a time remaining until the next therapy session.
  • the AMD 600 may determine a condition of the subject based at least in part on a measurement of a physiological parameter of the subject and determine the next therapy delivery time based at least in part on the condition of the subject. In some cases, the AMD 600 may determine the next therapy delivery time based at least in part on a therapy delivery schedule stored at the AMD 600.
  • the block 1016 may include one or more of the embodiments previously described with respect to the block 914. [0127] At decision block 1018 the AMD 600 determines whether the time left until the next therapy delivery session is longer than a set threshold time or threshold time period. The decision block 1018 may include one or more of the embodiments described with respect to the block 916.
  • the process moves to block 1020 where the execution of the second application will be initiated and the execution of the first application will be halted.
  • the AMD 600 may switch the control of the AMD 600 to the second application.
  • the AMD 600 may switch control of one or more features of the AMD 600 from the first application to the second application.
  • one or more features of AMD 600 may remain under control of the first application.
  • at least the control of the therapy delivery module 606 of the AMD 600 may be switched to the second application.
  • the process returns to block 1016 where the AMD 600 determines the next therapy delivery time.
  • the set threshold time may be determined by the CCM at least partly based on the time required to execute the second application and halt the first application.
  • the set threshold time may be received from a host computing system.
  • 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 delivery session.
  • the AMD 600 may receive an indication that a third application is available for download.
  • the AMD 600 may download the third application using the steps and procedures described with respect to the flow diagram in FIG. 8 and switch the control of the AMD from the second application to the third application using the steps and procedures described with respect to the flow diagram in FIG. 10, starting from block 1002.
  • the third application may be an update to the first application that addresses an application-fault of the first or second application.
  • the AMD 600 may notify the user (e.g., via a user interface) and wait for a trigger signal. Once the trigger has been received, the AMD 600 initiates the installation process of the downloaded copy of the application update without interrupting therapy provided by the ambulatory AMD 600.
  • the application update may be transferred to the main memory where it is executed and take control of the AMD 600 or a subset of operations in the AMD 600.
  • the current configuration of the AMD 600 may be stored in a memory of the AMD 600.
  • the performance of an application update may be tested before switching control of the AMD 600 to the application update.
  • FIG. 11 illustrates an example method that may be used for one or more such embodiments.
  • the AMD may identify and download a second application that is an update for a first application and that has been downloaded using the process described with reference to FIG.8.
  • the second application may be a new version of the first application, a patch to the first application, or a set of one or more additional features for the first application.
  • the first application can be a first version of the first application having a first feature set or a second version of the first application having a second feature set.
  • the first feature set may be different from the second feature set, but may include at least one feature included in the second feature set.
  • the AMD 600 may download a particular version of the second application that corresponds to a particular version of the first application. For example, there may be two versions of the first application.
  • a first version of the first application may be for a mono-hormonal pump that can administer insulin.
  • a second version of the first application may be for a bi-hormonal pump that can administer insulin and a counter-regulatory agent.
  • the AMD 600 When the AMD 600 is configured as a mono-hormonal medicament pump, the AMD 600 may download and/or install a first version of the second application that corresponds to the first version of the first application.
  • the AMD 600 when the AMD 600 is configured as a bi-hormonal medicament pump, the AMD 600 may download and/or install a second version of the second application that corresponds to the second version of the first application.
  • the AMD 600 may download and/or install a first version of the second application corresponding to the first version of the first application or a second version of the second application corresponding to the second version of the first application.
  • a first version of the second application corresponding to the first version of the first application or a second version of the second application corresponding to the second version of the first application.
  • the AMD 600 may install an update based on the installed version of the application.
  • the AMD 600 may install a different version of an application to enable or unlock new features (or in some cases to remove a feature, such as if a fault is discovered with a particular feature).
  • the AMD 600 verifies that an uncorrupted copy of the second application is successfully downloaded.
  • block 1102 may include one or more of the embodiments previously described with respect to block 808 in FIG.8 and/or block 902 in FIG. 9.
  • the AMD 600 may install the downloaded copy of the second application without interrupting therapy provided by the AMD 600 to the subject.
  • the second application may be installed in a separate memory space of a memory of the AMD 600 than a location of the first application within the memory.
  • the AMD 600 executes the installed second application without interrupting the execution of the first application and therefore, the therapy that may be provided by the ambulatory medical device to the subject using the first application.
  • the second application update may be installed to a separate portion of a storage space (e.g., a separate execution space or separate memory) from the portion where the first application is installed and is being executed.
  • the AMD 600 may execute the second application using a separate processor than a processor executing the first application.
  • the AMD 600 may execute the second application in a separate execution space than an execution space used to execute the first application.
  • the first application may be executed by a first controller and the second application is executed by a second controller.
  • the AMD 600 may determine that a minimum set of operating conditions are satisfied by the second application.
  • the minimum set of operating conditions may relate to maintaining therapy provided by the ambulatory medical device to the subject.
  • determining a minimum set of operating condition are satisfied may comprise determining that the AMD 600 is not currently administering a medicament or has less than a threshold probability of administering a medicament within a threshold period of time, or has recently administered a medicament within a threshold period of time. [0135] At the decision block 1110, the AMD 600 determines whether the second application satisfies the minimum set of operating parameters. If it is determined that the minimum set of operating conditions are not satisfied by the second application, the AMD 600 may wait a period of time and then repeat the process associated with the decision block 1110.
  • the AMD 600 may proceed to block 1112 where it waits for an indication that a third application is available and repeats the procedure described above to evaluate the performance of the third application. If at decision block 1110 the AMD 600 determines that the minimum set of operating conditions are satisfied by the second application, at decision block 1114 the AMD may check whether therapy is being delivered to the subject (e.g., a medicament is being administered to the subject). If it is determined that currently no therapy is delivered to a subject, at block 1118, the AMD 600 may switch the control of the AMD from the first application to the second application.
  • therapy e.g., a medicament is being administered to the subject
  • the process proceeds to block 1116 where the AMD 600 waits until the therapy delivery session is completed and then process proceeds to block 1118 where the AMD 600 switches the control of the AMD 600 from the first application to the second application.
  • the AMD 600 may switch the control of the AMD 600 from the first application to the second application by generating a dose control signal using the second application.
  • the AMD 600 may determine doses of a medicament to be infused into the subject for the purpose of controlling blood glucose of the subject based at least in part on a glucose level signal obtained from a blood glucose sensor. The doses of the medicament may be determined automatically and/or autonomously.
  • the AMD 600 may provide a dose control signal that is generated using the second application to a medicament delivery interface (e.g., medicament delivery interface of the therapy delivery module 606) that infuses the medicament into the subject.
  • a medicament delivery interface e.g., medicament delivery interface of the therapy delivery module 606
  • the AMD may be updated (or downgraded) to add (or remove) features from the ambulatory medical device.
  • the ambulatory medical device may be or may be configured as a mono-hormonal medicament pump that provides a single medicament, such as providing 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. Similarly, a user may opt to downgrade therapy from bi- hormonal to insulin-only therapy. Alternatively, 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 may be used by the AMD 600 in order to detect, download and install an update to an application executing on the AMD 600 that 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 a partially overlapping set of features with the second feature set.
  • the AMD 600 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 AMD 600 may initiate the installation process of the application update image without interrupting the execution of the application.
  • the indication received by the AMD 600 (block 802 in FIG.
  • any downloaded application update may be installed to a separate portion of a storage space (e.g., a separate execution space or separate memory) from a currently executing version of the application.
  • a storage space e.g., a separate execution space or separate memory
  • the active version of the application can be switched. For example, control of AMD 600 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.
  • the AMD 600 may be configured to store multiple instances of an application (e.g., AMD control software or a control application for the ambulatory medical device).
  • the AMD 600 may have a current, or first, version of the application that is installed in a first memory location (e.g., in the main memory 616) and is executing to, for example, control therapy provided to 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).
  • AMD 600 may initiate the execution of the second version of the application and then switch control of the AMD 600 to the second version of the application to maintain therapy to the subject.
  • a second application update or a second version of the application installed on the AMD 600 may be older than the first application or the first version of the application.
  • the second or older version of the application may be a version of the application that has a track record of stability and reliability.
  • the first application, or newer application may have been released too recently to determine whether it will be reliable or function as desired.
  • the AMD 600 may revert to the second version of the application if a fault is detected in the first version of the application. [0141] In some cases, the AMD 600 may revert to an older stable version of the application until a third version of the application that corrects the application fault in the first version of the application is available.
  • FIG.12 presents a flowchart related to an embodiment of a process of switching from an application with a fault to a known reliable version of the application until the application fault in the original application can be patched in an application update (e.g., a third version of the application).
  • the AMD 600 detects an application-fault while executing the first version of the application.
  • the AMD 600 may transmit an indication of the application-fault to a computing device of a manufacturer or a maintenance service of the ambulatory medical device.
  • the AMD 600 may send an alert to a user indicating that an application-fault has occurred.
  • Sending the alert to the user may include outputting an alert on a display, transmitting an alert to an account or device of the user, generating an audio alert or a visual alert, or any other type of alert.
  • the AMD 600 may switch the control of the AMD 600 to a second version of the application.
  • This second version of the application may be downloaded from a host computing system.
  • the second version of the application may be a standby or backup version of the application that is stored at the AMD 600.
  • This standby or backup version of the application may be an older version of the application that has been determined to be stable and/or fault free or associated with less than a threshold percentage of faults based on a history of use and/or testing.
  • the AMD 600 may establish a communication connection with a host computing system configured to host a third application update and download the third application update (block 1208).
  • the third version of the application update 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 AMD 600 may initiate the installation process of the downloaded copy of the third application and switch control of the AMD 600 form the second version of the application to the third version of the application (block 1210) without interrupting therapy delivery to the subject by the AMD.
  • the operation and processes described with respect to FIG.12 may be performed by the control computing module (CMM) 610 of the AMD 600.
  • CCM control computing module
  • a “safe version” of the application may have been installed on the AMD 600 prior to detection of a fault.
  • the safe version, or safe copy, 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 AMD 600 may switch control of the device to the safe version of the application to maintain therapy to the subject.
  • FIG. 13 is a flow diagram illustrating yet another example of a method of responding to a fault detection by the AMD 600.
  • the AMD 600 may access a second version of the application in the main memory 616 or the storage of the AMD 600. If it is determined that the second version has already been downloaded, at block 1306 the AMD 600 may determine whether the second version of the application is installed in a memory location and whether it is ready to be executed. If at block 1306 it is determined that the second version of the application is installed, at block 1308 the AMD 600 may switch the control of the AMD 600 to the second version of the application.
  • the process proceeds to block 1316 where the control of the AMD 600 is switched to a safe version 1316 that may be already installed.
  • eth AMD 600 may initiate the installation of the second version.
  • the process may proceed to block 1308 where the AMD 600 may switch control of the AMD 600 from the safe version of the application to the second version of the application.
  • the AMD 600 may search for a third version of the application that may be an update to the previously downloaded second version.
  • the AMD 600 may download and install the third version of the application and switch the control of the AMD 600 to the third version (block 1314). If at block 1304, if the AMD 600 cannot find a second version of the application in a memory or storage location, it will switch the control of the AMD 600 to a safe version of the application (block 1320) that may be installed in a memory location (e.g., in the main memory or in the storage) and search for a third version of the application (block 1310). If a third version is found, the system may download and install the third version of the application (block 1312) and switch the control of the device to the third version (block 1314).
  • the AMD 600 may transmit an indication of the application-fault to the host computing system of a manufacturer or maintenance service of the ambulatory medical device. In some other embodiments, the AMD 600 may notify the user when an application-fault occurs through a user interface of the AMD 600 or user interface communicating with the AMD 600.
  • the AMD 600 may offer the option to save the user’s configuration or profile data. For example, the software update should not change the patient state data (patient weight, CGMid, meal size equals volume of meal).
  • the application update may be pushed to a dedicated memory location in CCM 610 of the AMD 600 prior to transfer to executable memory location (e.g., the main memory) for security checks.
  • executable memory location e.g., the main memory
  • a healthcare provider system or the AMD may check the version of application update against the current version.
  • an alert may be sent to the user or the subject with information regarding the difference between the current application and the application update.
  • An ambulatory medical device such as an ambulatory medicament device (e.g., blood glucose control system, an insulin pump (e.g., a mono-hormonal 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 therapy data may be used to generate alerts about the health condition of the subject when therapy data indicates that immediate or urgent attention is needed with regards to the subject’s health condition.
  • Various aspects of accessing the therapy data or other types of data stored in a memory of the AMD needs proper management in order to provide uninterrupted, secure and easy access to authorized users.
  • the procedures and tasks performed by an AMD including those associated with data transfer management, may be associated with certain computer-executable instructions stored in and executed by the control and computing module (CCM) 610 of the AMD 600.
  • CCM control and computing module
  • accessing the data from the AMD can be problematic in some cases. For example, accessing the data may require a user to connect the AMD to a computer to upload the data. This places a burden on the user to remember to connect the AMD. 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.
  • 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 a networked computing environment 1408 (e.g., a data center), or a cloud computing system (e.g., a cloud server) of a cloud service provider.
  • the computing system 1404 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-transitory memories.
  • the procedures performed by the computing system 1404 may be associated with the execution of certain computer-executable instructions stored in a memory of the computing system 1404 by a hardware processor of the computing system 1404.
  • the direct end-to-end data connection may be supported by one or more transceivers (e.g., wireless 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.
  • the connection may use one or more wireless standards and technologies (e.g., 4G, 5G and the like).
  • a transceiver of the AMD 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), Long-Term Evolution Machine Type Communication (LTE-MTC) and the like.
  • 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.
  • the capability of the AMD 1402 to communicate with the computing system 1404 may be activated during manufacture or before providing the device to a subject.
  • the subject or a user establishes or initiates the direct end-to- end data connection with the computing system 1404.
  • the subject may interact with a user interface to cause the AMD 1402 to communicate with the cloud 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 1402 is in particular locations. This automatic connection may occur using information supplied to the AMD 1402 at a time of manufacture, shipment, sale, or prescription to the subject.
  • the AMD 1402 can communicate with the computing system 1404 without having access to a WiFi network or a local area network (LAN).
  • LAN local area network
  • the AMD 1402 may communicate using a cellular or other wide area network. Further, in some cases, the interaction by the user with the AMD 1402 may be relatively minimal or simple compared to traditional network communication. For example, a user may push a single button (e.g., an “upload” button) to trigger establishing of a connection with the cloud computing system 1404 and causing data to be provided from the AMD 1402 to the cloud computing system 1404. [0156] In some cases, the AMD 1402 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.
  • the wireless wide area network e.g., a cellular network
  • the AMD 1402 may be authenticated with the networked- computing environment as part of the manufacturing process [0157] Further, establishing the direct end-to-end data connection may include determining that the AMD 1402 is permitted to communicate with the computing system 1404 based at least in part on the device identifier. [0158] In some implementations, establishing the direct end-to-end data connection may include determining that the AMD 1402 is permitted to communicate with the computing system 1404 based at least in part on a device identifier associated with the AMD 1402. The device identifier may be a unique identifier specific to the AMD 1402.
  • 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 AMD 1402 is permitted to communicate with the computing system 1404 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 AMD 1402 to the subject. For example, the device identifier may be initially provided to the computing system 1404 or the networked-computing environment as part of a manufacturing process for manufacturing the AMD 1402.
  • the AMD 1402 may be configured to at least identify a computing system (or a cloud server) 1404 of a networked-computing environment 1408 (e.g., a cloud network, a data storage services provider, or an application services provider, etc.) based on a whitelist, or approved list, of one or more approved computing systems.
  • the whitelist may be stored in a memory of the AMD 1402 (e.g., a memory in the control and computing module of the AMD). Further, the whitelist may be configured during manufacture of the AMD 1402. 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 1402 may be configured to at least obtain an address of the computing system 1404 from the whitelist and to establish a direct end-to-end data connection to the computing system 1404 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 system 1404s of the cloud services provider.
  • the whitelist may include one or more of the embodiments previously described above with respect to Figure.7.
  • the AMD 1402 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 the networked computing environment.
  • the cloud computing systems (or cloud servers) 1404 may have a whitelist that uses unique identifiers to specify AMD 1402 and/or other computing systems (e.g., remote display systems) that are permitted to communicate with the computing systems 1404 of the networked computing system.
  • the AMD 1402 may communicate with a computing system, such as a computing node in a networked computing environment or a cloud network, based on a secure data transmission method.
  • the AMD 1402 may encrypt all data using an asymmetric key pair.
  • the AMD 1402 may establish a shared secret with the computing system as described below.
  • the therapy data may be encrypted before being transferred to the computing system 1404.
  • the AMD 1402 may have a public key and a private key stored in memory permitting the AMD 1402 to encrypt data transmitted by the AMD 1402 to the computing system 1404.
  • the AMD 1402 may generate the public key based at least in part on the private key.
  • the encryption key(s) may be stored in a protected area of memory or in separate memory that is separate from the application memory.
  • the AMD 1402 may transmit a public key to the computing system 1404. Using the public key, the computing system 1404 can encrypt data to transmit to the AMD 1402.
  • the AMD 1402 can use its private key to decrypt the data, such as an analysis of therapy data generated by the computing system 1404 in response to received therapy data from the AMD 1402.
  • the computing system 1404 may provide a public key to the AMD 1402.
  • the AMD 1402 can encrypt therapy data (and/or device data) to be transmitted to the computing system 1404 for storage, analysis, presentation to a user, reordering medicament, determining a status of the AMD 1402 and/or subject, or any other purpose or process that can be performed responsive to the therapy data.
  • the computing system 1404 may use its private key to decrypt the encrypted data to obtain access to the therapy data (and/or device data).
  • the public key may timeout and a new public key may be obtained from the AMD 1402 (or from the computing system 1404) to facilitate encrypting and/or decrypting subsequent communications from the AMD 1402.
  • the public key may be associated with a time-to-live (TTL) value.
  • TTL time-to-live
  • the public key may timeout and a new public key may be obtained from the AMD 1402 to facilitate encrypting and/or decrypting subsequent communications from the AMD 1402.
  • the secure data transmission may include generating a shared secret based at least in part on a public or common piece of data and a private key.
  • the public or shared piece of data can be a public key.
  • therapy or device data may be encrypted or decrypted using the shared secret.
  • the shared secret may be established using a public key exchange algorithm (e.g., Diffie-Hellman key exchange algorithm).
  • the computing system 1404 may be configured to transfer, or receive, the data after receiving a request to transfer data (e.g., therapy data or device status data) stored on the AMD 1402 to the computing system 1404 over the direct end-to-end data connection, for example, via the wireless wide area network.
  • the request may include a device identifier associated with the AMD 1402.
  • the computing system 1404 may be configured to receive the data, via the direct end-to-end data connection.
  • the computing system 1404 may open or provide a port to the AMD 1402 enabling the AMD 1402 to connect to the identified port and transfer data to the computing system 1404 via the identified port.
  • transferring data may include the computing system 1404 sending an acknowledgement packet that the transfer request is approved or permitted.
  • the AMD 1402 may transfer the data in response to approval by the computing system 1404 to transfer the data.
  • the approval may be based on the computing system 1404 confirming user account information (e.g., such as a username and/or password).
  • the computing system 1404 may analyze the therapy data received from the AMD 1402 and generate a therapy report.
  • the therapy report may include data relating to the subject’s disease, treatment by the AMD 1402, anonymized comparisons with other subjects, statistical data relating to the subject’s treatment, statistical data relating to other subjects’ disease or disease management, and the like.
  • the therapy report may determine whether the subject is maintaining blood glucose levels on average or whether control parameter settings for the AMD 1402 are similar to an average subject with similar physiological characteristics as the subject associated with the AMD 1402.
  • the computing system 1404 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).
  • the therapy data may trigger an automatic response by the computing system 1404.
  • the AMD 1402 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 1404 may periodically receive data (e.g., therapy data) from the AMD 1402 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.
  • the AMD 1402 may transmit the data to the computing system 1404.
  • the AMD 1402 may determine its location based at least in part on a connection to a local area network connection or a geolocation signal, such as from a global positioning system (GPS).
  • GPS global positioning system
  • additional encrypted data is received from the AMD 1402 on an intermittent basis.
  • additional encrypted data may be received from the AMD 1402 basis for at least a time period.
  • the AMD 1402 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 millisecond, 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. In cases where bulk transfer of data occurs at particular time periods, a user may request a data transfer at an unscheduled time, such as when the user is attending a doctor’s appointment or the subject is being attended to by emergency services personnel during an emergency. Data can be made available on-demand by keeping the transceiver always on, which may consume more power compared to keeping the transceiver in sleep mode when not in use.
  • the transceiver may be activated when a data transfer operation is requested.
  • the scheduling of data transfer may be balanced based with other considerations, such as: (1) power consumption and/or (2) a need or desire to share information with authorized users or systems.
  • the computing system 1404 may be used as a backup for the AMD 1402.
  • the AMD 1402 can backup data to the computing system 1404 every night, when it is charging, or when it is in proximity to home or a physician’s office (e.g., when the subject is in the waiting room at the physician’s office, the device may upload data that the physician can access to treat the subject’s disease).
  • the device can automatically synchronize with the computing system 1404 to obtain subject-specific configuration or therapy control data.
  • Therapy Data and Therapy Report [0170]
  • the therapy data comprises dose or dosage data corresponding to one or more doses of medicament provided by the AMD 1402 to the subject.
  • the therapy data may comprise subject data corresponding to a medical or physiological state of the subject as determined by the AMD 1402 device (e.g., using one or more biomedical sensors 1405).
  • the data provided to computing system 1404 may include any type of data that may be measured or obtained by the AMD 1402 and may include a record of therapy provided by the AMD 1402.
  • 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 blood glucose levels (e.g., measured blood glucose level) 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 injection site kits.
  • the computing system 1404 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 AMD 1402 (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 AMD 1402.
  • the data may further comprise error data corresponding to an error in operation of the AMD 1402.
  • the data, therapy data, and/or the therapy report may be stored in a memory of the computing system 1404 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 AMD 1402 to a format that can be stored or processed on the computing system 1404.
  • 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, or other data formats for displaying data to different types of users.
  • the data may be presented in different formats depending on the maturity of the subject.
  • the therapy data collected from different AMDs associated with a plurality of subjects may be aggregated for a group of subjects. The aggregation may be based on any factor or commonality among the plurality of subjects.
  • the therapy data may be aggregated based on an association with an institution or organization (e.g., a clinic, an insurance company, and the like), age, gender, nationality, ethnicity, job, stress factors, recency of being diagnosed with or acquiring the disease, location, diet (e.g., vegetarian, vegan, omnivore, etc.), or any other factor that may link subjects.
  • a therapy report based at least in part on the therapy data may be generated by the computing system 1404.
  • 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 the AMD 1402.
  • the AMD 1402 includes a display, such as, but not limited to, a touchscreen display, the subject or other user may review the therapy report via the display of the AMD 1402.
  • a user may view the therapy report on the display of another electronic device that is in communication with the computing system 1404 and is authorized to access the therapy report.
  • the ambulatory device data and/or data generated by the computing system 1404 based on the ambulatory device data can be viewed on a secondary display system from the computing system 1404.
  • 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. Further, a user (e.g., a subject, clinician, or parent) can access therapeutic recommendations through the cloud in case either the ambulatory medical device (e.g., an insulin pump) or the CGM sensor fails to function.
  • the computing system 1404 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, physician’s assistant, etc.), 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 provider 1420, or a device of the subject 1412 (e.g., cell phone, personal computer, tablet and the like).
  • the display system 1410 can be the AMD.
  • the display system can be a therapy data management system that analyses therapy data associated with a specific type of health problem (e.g., data associated with managing diabetes) and provides information derived from the therapy data to the subject or an authorized user to monitor and manage the corresponding ailment.
  • the request to access the therapy data, therapy report, or other data 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 1404 may be configured to determine whether an account associated with the account identifier is permitted to view the therapy report.
  • 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 network provided by 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 1404.
  • the computing system 1404 may transmit the therapy report to the display system over an encrypted communication channel.
  • the encrypted communication channel may be created by using asymmetric key pairs to encrypt the data transmitted.
  • the computing system 1404 may obtain a public key from the target system (e.g., the display system, AMD 1402, or other computing system that is to receive the therapy report).
  • the computing system 1404 may encrypt the therapy report with the received public key and transmit it to the target system, which may use its private key corresponding to the public key to decrypt the therapy report.
  • a shared secret may be determined for the commuting system 1404 and the target system.
  • 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.15A 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 therapy data received from an AMD 1402.
  • the AMD 1402 may encrypt the therapy data using a public key and/or a shared secret.
  • the encrypted therapy data may be provided to another computing system, such as a computing system of a clinician or a computing system of a networked computing environment (e.g., a computing system at a data center of a cloud computing network).
  • the computing system 1404 may establish a direct end-to- end data connection to the AMD 1402, for example, via a wireless wide area network (WAN) using a Narrowband Long-Term Evolution (NB-LTE) transceiver included in the AMD 1402.
  • the direct end-to-end data connection may be initiated by the computing system 1404 or by the AMD 1402.
  • the direct end-to-end connection may be a connection between the AMD 1402 and the computing system 1404 that omits an intermediary computing system (e.g., a local computing system such as a laptop or smartphone).
  • the direct end-to-end connection may, in some cases, include intermediary connection hardware, such as a router, base station, or switch.
  • the computing system 1404 may receive a request from the AMD 1402 to transfer data (e.g., therapy data) stored on the AMD 1402 to the computing system 1404 over the direct end-to-end data connection.
  • the computing system 1404 may request the data (e.g., therapy data) from the AMD 1402. Regardless of whether the AMD 1402 or the computing system 1404 requests the data transfer, the data transfer may be requested as part of the processes of establishing the direct end-to-end data connection or may be requested after the direct end-to-end data connection is established.
  • the computing system 1404 and the AMD 1402 may exchange public keys.
  • the public key exchange may occur as part of establishing the direct end-to-end data connection so as to establish a secure or encrypted channel. In some cases, the public key exchange may occur after establishing the connection to create a secure data channel.
  • one of the computing systems 1404 or the AMD 1402 may provide a public key, while the other device may not. In some such cases, only one of the devices may provide the public key as data transfer may be unidirectional.
  • the AMD 1402 may use the public key received from the computing system 1404 to encrypt therapy data to be transmitted to the computing system 1404.
  • the computing system 1404 may use the public key received from the AMD 1402 to encrypt a therapy report based on the therapy data, or other data obtained by the computing system 1404, to be transmitted to the AMD 1402. [0190]
  • the computing system 1404 may determine whether the AMD 1402 is authorized to transmit data (e.g., therapy data) to the computing system 1404.
  • the computing system 1404 may determine whether the AMD 1402 is authorized to transmit the data based on a device identifier associated with the AMD 1402, an account identifier associated with the AMD 1402 or a subject, or any other information that may be used to determine whether an operation is authorized.
  • the computing system 1404 may use a whitelist to confirm that the AMD 1402 is authorized to communicate with or transfer data to the computing system 1404. [0191] If it is determined that the AMD 1402 is authorized to transfer data to the computing system 1404, the computing system 1404 may receive the data from the AMD 1402 at block 1512.
  • the data may be encrypted therapy data associated with therapy provided by the AMD 1402 to the subject.
  • the computing system 1404 may store the therapy data at one or more of a storage of the computing system 1404 or a storage of the networked-computing environment 1408.
  • the encrypted data may include at least one of operation data corresponding to operation of the AMD 1402 or error data corresponding to an error in the operation of the AMD 1402.
  • additional encrypted data may be received from the AMD 1402 on an intermittent basis, a periodic basis, a scheduled basis, or on a continuous basis for at least a time period.
  • the computing system 1404 determines that the AMD 1402 is not authorized to transfer data to the computing system 1404, the process may proceed to block 1510 where the request is denied. In some cases, denying the request may include sending an indication to the AMD 1402 that the request is denied. Further, the computing system 1404 may provide a reason why the request is denied, such as incorrect password or unrecognized device identifier. [0193] At block 1514, the computing system 1404 may decrypt the encrypted therapy data received from the AMD 1402.
  • the computing system 1404 may use a private key (e.g., stored in a memory of the computing system 1404) that corresponds to the public key provided by the computing system 1404 to the AMD 1402. Alternatively, or in addition, the computing system 1404 may use a shared secret generated between the computing system 1404 and the AMD 1402 to decrypt the encrypted therapy data. [0194] At block 1516, the computing system 1404, may use the therapy data received from eth AMD 1402, to generate a therapy report. In some examples, the decrypted therapy data and/or therapy report may be stored in a memory of the computing system 1404.
  • the therapy report may include any type of statistics or data that can be extrapolated from the therapy data, or from a series of therapy data received over time from the AMD 1404 and/or from a plurality of AMD associated with a plurality of subjects.
  • the computing system may receive a request from a display system 1410 that is separate from the networked computing environment, to access the therapy report generated at block 1516.
  • the request may comprise an account identifier associated with a user that caused the request for the therapy report to be generated.
  • the request may include an identifier associated with the display system 1410 requesting the therapy report.
  • the request to access the therapy report may include account information and password for the display system 1410 and/or for a user associated with the display system 1410.
  • the display system 1410 may be the AMD 1402.
  • the AMD 1402 may not need to authenticate to receive the therapy report as authentication may occur as part of the block 1502.
  • the AMD 1402 may authenticate with the computing system 1404 before receiving the therapy report.
  • the computing system 1404 may use an account identifier, a device identifier, or other authentication information received at the block 1518 as part of the request to access the therapy report to determine whether the account associated with the account identifier is authorized or permitted to view the therapy report.
  • the display system 1410, or user is authenticated prior to the receipt of the request to access the therapy report.
  • the computing system 1404 may deny the request at the block 1524.
  • the operations associated with the block 1524 may include one or more of the embodiments associated with the block 1510.
  • the computing system 1404 may transmit the therapy report to the display system 1522.
  • the therapy report may be transmitted over a direct connection to the display system 1410 or over a computing network, which may include the Internet. Further, the computing system 1404 may use an encrypted communication channel to communicate the therapy report (or therapy data).
  • the computing system 1404 may request a public key from the display system 1410 and can encrypt the therapy report using the received public key.
  • the display device 1410 may use a private key to decrypt the encrypted therapy report received from the computing system 1404. This private key may correspond to the public key provided by the display system to the computing system 1404.
  • the display system can be the AMD 1402.
  • the subject or an authorized user may be able to view the therapy report received from the computing system 1404, on a user interface (e.g., a touchscreen display) of the AMD 1402.
  • the computing system 1404 may determine that the therapy data or other data received from the AMD 1402 satisfies an alert threshold condition based at least in part on physiological information of the subject obtained from the AMD 1402. In some such implementations, if the computing system 1404 determines that the therapy data or other data received from the AMD 1402 satisfies an alert threshold condition, the computing system 1404 may send an alert to one or more display systems 1410 designated to receive alerts from the computing system 1404. In some cases, the alert may be sent to a user device of the subject, a user device of another user (e.g., a parent, guardian, or medical practitioner), a user device of an emergency services provider, or a user device of any other authorized user associated with the subject.
  • a user device of the subject e.g., a parent, guardian, or medical practitioner
  • the alert threshold condition may be associated with the health condition of the subject.
  • the alert threshold condition may include the subject’s blood glucose level being above (hyperglycemia) or below (hypoglycemia) a set value or setpoint range.
  • the alert threshold condition may be associated with the operation of the AMD.
  • the 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.
  • the alert threshold condition may relate to a quantity of medicament remaining in a medicament cartridge.
  • alert threshold condition may be associated with the temporal behavior of therapy data over a period of time.
  • the alert threshold condition may relate to fluctuations or variations of the subject’s blood glucose level being outside of a particular range.
  • the one or more alert threshold conditions may be defined or specified by a healthcare provider.
  • the healthcare provider may change one or more alert threshold conditions based at least in part on physiological parameters or characteristics of the subject.
  • FIG.15B is a flow diagram that illustrates an example method that may be used by AMD 1402 to transmit therapy data to the computing system 1404 over a direct end- to-end connection. The process illustrated in FIG. 15B may include one or more of the embodiments previously described with respect to the FIG.15A.
  • the AMD 1402 may identify a computing system 1404 of a networked computing environment 1408 based at least in part on a whitelist of one or more approved computing systems stored in the memory of AMD 1402.
  • the whitelist may be stored in a memory of AMD 1402 during manufacture of the ambulatory medical device.
  • the AMD 1402 may accept data packets from and/or communicate exclusively with computing systems identified on the whitelist. Further, in some cases, the AMD 1402 may confirm, for example, by accessing a packet header, that received packets are received from a computing system on the whitelist. Data packets received from computing systems that are not on the whitelist may be ignored or discarded.
  • the AMD 1402 may establish a direct end-to-end data connection to the computing system 1404 using an address of the computing system 1404 obtained from the whitelist.
  • the address may be a network address (e.g., a network address of the networked computing environment 1408).
  • the network address can be an Internet Protocol (IP) address, a Uniform Resource Locator (URL), a Uniform Resource Identifier (URI), or a Uniform Resource Name (URN).
  • IP Internet Protocol
  • URL Uniform Resource Locator
  • URI Uniform Resource Identifier
  • UPN Uniform Resource Name
  • the direct end-to-end data connection may be established via a wireless wide area network (WAN) using a transceiver of the AMD 1402 configured to support communication over one or more communication standards such as a low power wide area network (LPWAN) communication standard, a Narrowband Long-Term Evolution (NB-LTE) standard, a Narrowband Internet-of-Things (NB-IoT) standard, or a Long-Term Evolution Machine Type Communication (LTE-MTC) standard.
  • 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 may be configured to communicate via the wireless wide area network using the address.
  • the direct end-to-end data connection to the computing system 1404 may be established by transmitting a connection request to the computing system 1404.
  • the connection request may include a device identifier of the AMD 1402.
  • the AMD 1402 may receive a public key from the computing system 1404.
  • the AMD 1402 may encrypt therapy data related to therapy delivered by the AMD 1402, based at least in part on the public key received from the computing system.
  • the AMD 1402 may encrypt the therapy data based at least in part on a shared secret generated based on an asymmetric key pair (e.g., a public key and a private key) of the AMD 1402 and an asymmetric key pair of the computing system 1404.
  • the shared secret may be generated using a Diffie-Hellman key exchange.
  • the AMD 1402 may transmit the encrypted therapy data to the computing system 1404 over the direct end-to-end connection.
  • the AMD 1402 may obtain additional therapy data that may be obtained at a different time period than the transmitted therapy data.
  • the AMD 1402 may encrypt the additional therapy data using the same key or shared secret used to encrypt the therapy data at the block 1536.
  • a different key or shared secret may be obtained and used to encrypt the additional therapy data. For example, at the time that the additional therapy data is obtained, a new secure channel may be established using a new asymmetric key pair.
  • the additional encrypted therapy data may be transmitted to the computing system over the direct end-to-end connection.
  • the computing system may decrypt the received encrypted therapy data using the public key sent to the AMD 1402 and a private key stored in a memory of the computing system.
  • AMD 1402 may transmit status information of the AMD 1402 to the computing system 1404.
  • the status information of the AMD 1402 may include one or more of operation data or error data, wherein the operation data corresponds to operation of the ambulatory medical device, and wherein the error data corresponds to an error in operation of the AMD 1402. [0208]
  • the computing system 1404 that performs the steps described with respect to FIGS.
  • the AMD 1402 may receive an account identifier associated with a user authorized to access data associated with the subject at the networked computing environment 1408 and transmit the account identifier to the computing system 1404.
  • the computing system 1404 may allow the authorized user to access the therapy data received from the AMD 1402.
  • the AMD 1402 may also transmit a set of permissions to the computing system 1404 that may authorize the user to access the therapy data associated with a subject.
  • FIG. 16 is a 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 1611 to various display systems 1610 (e.g., alert messages, alert signals and the like) upon determining that data received from the AMD 1602 satisfies a threshold condition.
  • the computing system 1604 may be part of a networked computing environment 1608 (e.g., a data center, networked computing system), or a cloud network 1606 or cloud computing system of a cloud service provider.
  • the computing system may include one or more non-transitory memories and one or more hardware processors configured to execute the computer-executable instructions stored in one or more non-transitory memories.
  • the AMD may receive data from one or more biomedical sensors 1605 (e.g., blood glucose level sensor, analyte sensor, temperature sensor, heart beat sensor, and the like) and/or one or more environmental sensors 1603 (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.
  • the one or more display systems 1610 receiving the alert 1611 may be display systems that have previously received therapy reports from the computing system 1604.
  • the one or more display systems may be selected and/or authorized by the subject who is receiving therapy from the AMD 1602 to receive alerts 1611.
  • the display systems 1610 may receive alerts 1611 from the AMD 1602 may include: a medical practitioner 1614 (e.g., a doctor, a nurse, etc.), a guardian of the subject 1616 (e.g., subject’s parents), an emergency service provider 1618, an authorized user 1620 (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., a mobile device, cell phone, personal computer, tablet, and the like).
  • a medical practitioner 1614 e.g., a doctor, a nurse, etc.
  • a guardian of the subject 1616 e.g., subject’s parents
  • an emergency service provider 1618 e.g., an authorized user 1620 (e.g., a user authorized by the subject such as spouse,
  • an alert may be sent to one or more display systems 1610 (e.g., alert 1611) and/or the AMD 1602 (e.g., alert 1609).
  • 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 data that is generated over the given period of period and/or that satisfies an alert threshold condition.
  • the subject may request a continuous connection between AMD and the computing system when going for a hike alone to make sure that if his/her health condition deteriorates during the hike, an alert is sent to one or more authorized display systems.
  • a geolocation sensor e.g., a Global Positioning System (GPS) receiver
  • GPS Global Positioning System
  • a proximity sensor can be used to enable location-activated features, such as automatic upload of data at certain locations.
  • the AMD 1602 may include, communicate with, or otherwise connect or interface with a motion sensor, an accelerometer, or a geolocation system.
  • the aforementioned sensors may be used to determine or detect the velocity of the AMD and/or the subject.
  • using the data 1607 obtained from the AMD 1602, such as the location and/or velocity information can be used to provide intelligent alerts. For example, if the AMD 1602 (or a computing system 1604 receiving data from the AMD 1602) determines from the location and/or motion data that a user is travelling at a high rate of speed (e.g., likely in a car) and the user’s blood glucose level is low (e.g., below 55 mg/dl), the AMD 1602 (or the computing system 1604) may automatically alert an emergency service provider 1618 that a subject is at risk of hypoglycemia and may be driving. Further, the AMD 1602 and/or the computing system 1604 can provide a location of the subject to the emergency service provider 1618.
  • the determined velocity of the AMD may be used to generate driving alerts to inform the subject to pull over immediately or as soon as it is safe due to a risk of a hypoglycemic event.
  • exercise alerts may be generated, for example, to alert the subject to pause exercising if the subject’s blood sugar level drops below a certain level.
  • the system can enable automatic notification to emergency services.
  • the determined activity level of the subject can be sensed and used to modify the therapy delivery.
  • a determination of the subject’s motion can be used to automatically adjust the rate of therapy delivery (e.g., raise the blood sugar level that triggers the therapy delivery).
  • the computing system 1604 may 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 computing system 1604 can send a text message, call, or generate any other type of alert that may be automatically provided to a device (e.g., smartphone, laptop, etc.) of a follower, healthcare provider, or other user associated with the subject when the therapy data satisfies an alert threshold.
  • These messages or alerts may be provided from the computing system to a third-party device in cases where roaming or disabling of the data plan on the AMD occurs (e.g., no TCP/IP available). Further, the computing system 1604 may send a text message or call 911 in case of a detected emergency. The computing system 1604 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 computing system 1604 may enable an end user to order and re-order medical supplies directly from the viewing device. [0217] In some examples, the computing system 1604 can generate notifications regarding potential medical risks (e.g., generate a message when there is a risk of hypoglycemia).
  • potential medical risks e.g., generate a message when there is a risk of hypoglycemia
  • 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 computing system 1604 may establish a direct end-to-end data connection to an AMD 1602, 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 block 1702 may include one or more of the embodiments described with respect to the block 1502. [0219]
  • the computing system 1604 may receive a public key, from the AMD 1602 over the established connection.
  • the key exchange may be part of the process of establishing the data connection.
  • the block 1704 may include one or more of the embodiments described with respect to the block 1504.
  • the computing system may receive a request from the AMD 1602 to transfer data (e.g., therapy data, medical sensor data or environmental sensor data) generated by the AMD 1602 to the computing system 1604 over the direct end-to-end data connection.
  • data e.g., therapy data, medical sensor data or environmental sensor data
  • the request to transfer data may be the data itself.
  • there may not be a formal request to transfer the data but instead data may be transmitted by the AMD 1602 to the computing system 1604 upon establishing the data connection.
  • the block 1706 may include one or more of the embodiments described with respect to the block 1506.
  • the request may include a time period during which AMD 1602 continuously transmits 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 the subject to the AMD.
  • the computing system 1604 may determine whether the AMD 1602 is authorized to transfer data to the computing system 1604. In some cases, the determination may be based at least in part on the device ID associated with the AMD 1602,
  • the block 1708 may include one or more of the embodiments described with respect to the block 1508.
  • the request received at block 1706 may be denied at block 1710.
  • the block 1710 may include one or more of the embodiments described with respect to the block 1510.
  • the computing system 1604 may permit the AMD 1602 to provide the encrypted therapy data to the computing system 1604.
  • the computing system 1604 may receive the therapy data, which may be encrypted therapy data, from the AMD 1602.
  • the block 1712 may include one or more of the embodiments described with respect to the block 1512.
  • the computing system 1604 may decrypt the received data using a private key.
  • the private key may correspond to a public key of the computing system 1604 provided to the AMD 1602 to encrypt the therapy data. This private key may be stored in a memory of the computing system 1604.
  • the block 1714 may include one or more of the embodiments described with respect to the block 1514.
  • 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. In some examples, the computing system 1404 may determine that the therapy data or other data received from the AMD 1402 satisfies an alert threshold condition based at least in part on physiological information or physiological measurements of the subject obtained from the AMD 1402.
  • the physiological measurements may be obtained from one or more physiological sensors (e.g., glucose monitors, heart rate monitors, blood pressure monitors, etc.) that provide physiological measurements to the AMD 1402.
  • the threshold condition may be provided to the AMD 1602 by the subject or an authorized user (e.g., a guardian of the subject).
  • the threshold condition may be provided by a healthcare provider.
  • the threshold condition may be stored in a memory of the AMD 1602.
  • the computing system 1604 may generate and transmit an alert to one or more display systems 1610 that are authorized (e.g., by the subject or a guardian of the subject) to receive alerts at block 1718.
  • the subject, or other authorized user may authorize one or more display systems 1610 to receive alerts by, for example, providing the account IDs of the one or more display systems to the computing system 1604 or the networked computing environment 1608.
  • the computing system 1604 determines that the therapy data does not satisfy a threshold condition, the process may return to block 1712 where the computing system 1604 continues receiving therapy data from the AMD 1602.
  • the ambulatory medical 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 AMD, 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 AMD can be an ambulatory medicament device.
  • the user may be a subject who is receiving medicament or therapy, a clinician or healthcare provider, a parent or guardian, or any other user who may be permitted to modify settings of the ambulatory medicament device.
  • AMD For AMD that include a user interface, there is a risk that 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). Further, AMD may accidentally have settings modified by inadvertent interactions with a user interface, such as may occur when an AMD is worn against the body of a subject.
  • An ambulatory medicament device may be configured to prevent an inadvertent modification to a control parameter and/or to medicament delivery, for example, in the event of a setting of the AMD being accidentally modified by a user or inadvertent interactions with a user interface of the AMD.
  • the user may modify the control or configuration of the AMD using a user interface.
  • the control or configuration of the AMD is accidentally modified through the user interface.
  • the control and computing module (CCM) 610 of the AMD may include a set of therapy change procedures implemented to prevent therapy change inputs 1829 that are inadvertent.
  • the therapy change procedures implemented by the CCM 610 may be implemented as instructions stored in a memory of CCM (e.g., the main memory 616) and executed by the processor 614.
  • the CCM 610 may verify the therapy change input 1829, received from a user 1827, using one or more therapy change procedures before the AMD 600 administers therapy based on the received therapy change input 1829.
  • the therapy change inputs 1829 may be received in response to a user interaction with a user interface module 1808.
  • the therapy change inputs 1829 may control or relate to one or more therapy change procedures performed by the control and computing module (CCM) 610 or one or more of the controllers (e.g., the controllers 1830- 1836) implemented by the CCM 610.
  • CCM control and computing module
  • the user interface module 1808 may include any type of user interface controller for providing a user interface.
  • the user interface may be provided on a display of the AMD 600, or may be transmitted to a display of an electronic device in communication with the AMD 600.
  • the user interface controller may be a touchscreen controller that is configured to output display signals configured to generate one or more user interface screens on a touchscreen. Further, the touchscreen controller may be configured to receive user input signals corresponding to user interaction with the touchscreen.
  • the user 1827 may wake the AMD from a sleep state or unlock the AMD by interacting with a wake interface 1822. When the AMD is in a sleep state, the touchscreen controller may not receive user input or user input signals corresponding to user input.
  • Waking the AMD 600 may include activating a touchscreen interface or presenting a lock screen to a user. Further, waking the AMD may include waking the touchscreen controller such that it can receive user input or user input signals corresponding to user input.
  • the wake interface 1822 can include one or more of the additional user interfaces mentioned above that are configured to generate and provide a wake input (or wake signal) to the CCM when detecting a pre-set user interaction. Alternatively, or in addition, the wake interface 1822 can be any type of wake interface element of the AMD that a user can interact with to wake at least a feature (e.g., a touchscreen interface) of the AMD.
  • the wake interface element can be a physical button (e.g., a push button, a slide button, etc.), a capacitive element, a resistive element, or an inductive element.
  • the wake interface element can be or can include a biometric element, such as a fingerprint reader, an iris scanner, a face detection scanner, etc.
  • the AMD may wake in response to detection of a particular movement or motion. For example, a determination that the ambulatory medicament device is being moved with a particular motion or within a line of sight or a visual range of a user may cause the AMD to awaken or cause the AMD to awake the touchscreen interface of the AMD.
  • the AMD may determine that the AMD is being moved within a line of sight of the user based on the type of motion and/or the detection of a user’s eyes via, for example, an iris scanner or a camera.
  • 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 provided by the user 1827 may affect the therapy delivery at future time.
  • 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.
  • the therapy change input 1829 is a request to change a control parameter.
  • the control parameter may be changed in response to the request.
  • a confirmation action e.g., a swipe gesture or an interaction with a physical or digital button on the touchscreen
  • a wake input is sent to the control and computing module 610, which may imitate or perform a wake control procedure to wake/unlock the user interface (e.g., a touchscreen display).
  • the CCM 610 may use the wake controller 1834 to perform the wake procedure.
  • a user When in the wake and/or unlocked state, a user may interact with the touchscreen 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 may send an input signal to the control and computing module 610 to determine if the first user interaction relates to a therapy change request or a control parameter change request.
  • the CCM 610 may use the therapy change controller 1836 to determine whether the first user interaction corresponds to a request to change a control parameter, or a request to access a control parameter change interface. If it is determined that the first user interaction satisfies a set of predefined conditions, the therapy change controller 1836 sends a signal to the user interface module 1808 to activate the therapy change user interface.
  • the type of therapy change user interface and/or the available therapy change selections included in the user interface may depend on the user interaction. For example, in response to one of two user interactions, the therapy change control procedure 1836 may send one of two signals to the user interface module 1808.
  • the therapy change user interface may 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 (e.g., more than a magnitude, or more than 3 change increments) increase the rate of insulin or glucagon infusion rate, may require a user interaction that is different from the user interaction that may be required for an insulin or glucagon infusion at a normal or prescribed rate, or a smaller change to the control parameter.
  • the user interaction may be a simple interaction (e.g., a simple gesture or unlock gesture interaction) that unlocks a therapy change user interface with therapy change selections that are limited.
  • Another 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 or simpler 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 second or more complex 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 generated by the user interface module 1808 may provide one or more therapy control elements that enable the user to modify the one or more settings of the AMD 600.
  • the therapy control 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 AMD 600.
  • This change in configuration of the AMD 600 may relate to a change in the therapy provided or in the detection of a triggering event that causes therapy (e.g., medicament delivery) to be provided to a subject.
  • the change in configuration may include a selection between one or more hormones that regulate blood sugar level (e.g., insulin or glucagon) of a user, an amount of the one or more hormones that regulate blood sugar level of the user, a rate of delivery of the one or more hormones, a threshold for determining when to deliver the one or more hormones, a change in an estimated blood absorption rate of the one or more hormones, and the like.
  • the therapy control 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 one or more control parameters of the AMD 600 that control the therapy delivery.
  • a change to the setting (e.g., control parameters or configuration of the AMD) of the AMD is automatically and/or instantly recognized or implemented by the AMD, and/or transmitted to the AMD.
  • a confirmation of the change may be required before the setting change is implemented by or transmitted to the AMD.
  • This confirmation may be entered based on a second user interaction with a 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.
  • 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 indication 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 and/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 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.
  • 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.
  • the second user interaction may be received 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 AMD 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 AMD may begin operating based on the modified setting selected and/or provided by the user.
  • this operation may include triggering therapy delivery based on the new setting or providing therapy based on the new setting.
  • the AMD 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 and control procedures 1832.
  • the device and subject monitoring and control procedures 1832 may be implemented in the CCM 610 to monitor and control one or more modules or systems of the AMD (e.g., therapy delivery configuration) as well as the health condition of the subject 1827 using the subject sensor (e.g., CGM sensor).
  • the device and subject monitoring and control procedures 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 and control procedures 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 and control procedures 1832.
  • the medicament dose control procedure 1830 may control and activate the medicament delivery interface 1806 by providing a medicament dose signal.
  • the medicament does control may be generated at least partially 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 procedures 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 user commands, 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 AMD using a touch screen user interface.
  • the user may initiate the configuration change process by waking/unlocking the touch screen using a wake action.
  • a wake action is received by the wake interface 1822 of the AMD.
  • the wake interface 1822 sends a wake signal to the CCM module 610 of the AMD.
  • the wake procedure generates, activates, or unlocks the touch screen display 1824 (at block 1906).
  • the AMD receives a response or a first gesture from the user.
  • a therapy change user interface is unlocked.
  • the user may modify or change one or more therapy settings (e.g., control parameter or configurations) of the AMD, using one or more therapy control elements provided in the corresponding therapy change user interface.
  • the user may confirm the changes made, by providing a second gesture on the touchscreen display 1824.
  • the requested therapy changes or therapy modification are implemented, and the AMD may begin operating according to a modified configuration or modified set of control parameters.
  • the medicament dose control module 1830 may be sent a dose control signal to the medicament delivery interface 1806 to trigger a therapy delivery to the subject based on the modified therapy settings.
  • AMD or a control device that enables a user to modify a configuration of the AMD, may have a timeout feature. The timeout feature may cause the AMD 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 AMD 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.
  • the timeout feature may cause the user interface (e.g., a touchscreen display) to become inactive or enter a lock state.
  • a user may have a limited period of time to modify the configuration of the AMD.
  • 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 AMD 600 is shown in a graphic representation 2010.
  • the graphic representation 2010 shows that the insulin cartridge in the AMD device 600 is almost full.
  • a current blood sugar 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 sugar 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 AMD 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.
  • FIG. 20C is an illustration of an example therapy change user interface (in this case a touchscreen display 2002).
  • the example screen shown here may prompt the user 1827 to select one or more hormones for regulating the blood sugar level of the subject.
  • the touchscreen display 2002 presents the user 1827 with an option to select between two hormones (e.g., insulin and glucagon), or select both hormones.
  • the selected option by the user is “insulin only” 2008.
  • the user 1827 is also given the options of selecting the “glucagon only” button 2012 or both “insulin & glucagon” button 2004.
  • the “Next” button 2014 may be selected to complete the therapy change selection.
  • selecting the “Next” button may provide the user with more options. For example, selecting the “Next” bottom may prompt the user 1827 to select an amount of the one or more hormones selected by the user 1827.
  • a therapy change user interface may prompt the user 1827 to select a target blood sugar level and the AMD device may automatically select a hormone (or a combination of hormones) and determine the amount of the one or more selected hormones that should be delivered during a therapy session to maintain the blood sugar level at the target level or within a margin of the target level.
  • FIG. 20D is an illustration of another example of user interface on a touchscreen display 2016 that supports therapy change by the user 1827.
  • 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 other AMD functions (e.g., generating a therapy report, replacing a cartridge, and the like).
  • a “Deliver Hormone” button 2030 allows the user 1827 to select a therapy change that delivers a hormone that regulates blood sugar to the user 1827.
  • a “Test Blood Sugar” button 2018 allows the user 1827 to test the blood sugar 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 AMD 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 AMD 600.
  • a “Settings” button 2028 allows the user 1827 to manipulate one or more other settings of the AMD 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 1829 using the user interface 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., touchscreen display 1824) before and/or during the therapy change delivery 1807.
  • an 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.
  • the alarm status indicator may be shown on the user interface when the user interface is inactive or locked.
  • 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 procedures may continuously monitor the status of the AMD 2102 (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).
  • AMD Once a set of status information is received at the block 2104, the device and subject monitoring procedure may determine whether the received status information satisfies an alarm condition at decision block 2106. If the received status information does not satisfy an alarm condition, no action will be taken and device and subject monitoring procedure continuous monitoring the AMD and the subject. If it is determined that the received status information satisfies an alarm condition, the system may determine if a wake signal is received at decision block 2108.
  • the system waits for a wake signal to be received at block 2110.
  • the CCM 610 e.g., using the wake control 1834 and therapy change control 1836
  • the CCM 610 may generate a display of a touchscreen lock screen interface at block 2112 and display one or more alarm status indicators at block 2114, corresponding to the detected alarm condition, on the lock screen.
  • the alarm status indication may be generated and included in one or more user interface screens, such as a touchscreen lock screen interface regardless of the sleep or wake condition of the AMD.
  • the alarm status indicator may not be presented to a user until a user performs wake interaction to awaken the AMD and cause a user interface screen to be presented.
  • additional status information may be received by an AMD at some point in time after the previous status information that satisfies an alarm condition was received. If the AMD determines that the additional status information satisfies the alarm condition for the AMD or for the subject, the AMD may modify one or more alarm status indicators based at least in part on the additional status information. For example, the alarm indicator may indicate an increased severity of the alarm condition via a different status indicator or a modifying of a color or text associated with the status indicator. If the additional status information satisfies a different alarm condition, an additional alarm indicator may be displayed on the touchscreen lock screen interface of the AMD.
  • the AMD may allow the user to provide a therapy change and then cancel the therapy change.
  • the user may provide the therapy change by modifying one or more control parameters of the AMD.
  • 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 changed 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 be 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 (or a particular portion thereof).
  • An example of a restore swipe gesture may be a gesture 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. For instance, a user may position a finger at a point on the touchscreen and drag the finger across at least a portion of the touchscreen towards a left edge (e.g., reminiscent of a back arrow). It should be understood that other gestures are possible to indicate a restore gesture. In some cases, a user can define the gesture to be used as a restore gesture.
  • 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. In some such examples, during the set time period one or more dose control signals may be provided to the medicament delivery interface resulting in one or more therapy change deliveries.
  • the restore gesture can be received at any time after the confirmation gesture or therapy change. In some cases, the restore gesture restores the control parameter modified during a therapy change to an immediately preceding value.
  • the restore gesture restores the control parameter to a value designated as a restore value (e.g., a default value or other designated restore value) or to a most recent value that maintained the subject’s blood glucose level with a target setpoint range.
  • the designated restore value may be specific to a subject or AMD or may be determined based on clinical data for a set of subjects.
  • the set of subjects may be subjects that share certain characteristics with the subject using the AMD. For example, the set of subjects may be of the same gender, similar age range, similar severity of diabetes, etc.
  • 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.
  • the user may be able to cancel a therapy change delivery after confirming the therapy change and before a therapy delivery based on new settings. In some such examples, an alert may notify the user that a therapy delivery based on new settings will occur shortly.
  • 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 delivery.
  • 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 are all 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.
  • 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.
  • a therapy change delivery 1807 may be canceled by an input by a user input comprising a wake action followed by a series of touch inputs (e.g., gestures, alphanumeric inputs and the like).
  • the AMD ambulatory medicament device
  • a subject when a subject suspends the treatment delivered by an AMD, the subject may forget to resume the treatment delivered by the AMD. In some cases, the health condition of the subject may deteriorate during the suspension period requiring therapy delivery to resume prior to the end of the suspension period.
  • Suspending delivery of the medicament can include the processor of the AMD not generating a dose control signal during the temporary suspension period.
  • the AMD may support a therapy suspension and resumption procedure allowing a user (e.g., the subject, a parent or guardian) 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 (e.g., temporary suspension period) or when a threshold condition is met (e.g., a threshold condition associated with the health condition of the subject).
  • the AMD can be a mono-hormonal insulin pump.
  • the AMD can be a bi- hormonal pump capable of administering insulin and a counter-regulatory agent (e.g., glucagon).
  • 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 (e.g., on a touchscreen display or other types of user interface), to suspend and/or resume therapy delivery by the AMD.
  • the gestures may be entered at a particular prompt provided on a user interface to activate or resume a therapy suspension.
  • One particular application of the therapy suspension with automatic resumption feature in an AMD can be in the field of diabetes drug delivery.
  • the subject may need the ability to suspend delivery of insulin during situations such as exercise, which has a blood glucose lowering effect.
  • Suspension of insulin delivery can prevent a subject from entering a hypoglycemic state (extreme low blood glucose), which carries severe complications.
  • a hyperglycemic state high blood glucose that may result in complications such as diabetic ketoacidosis or neurovascular complications
  • the subject s blood glucose level may raise above or below a dangerous level during the period of exercise.
  • 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 a user interface of the AMD 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 AMD.
  • the indication that the therapy or medicament delivery is to be suspended may be received from the AMD itself.
  • the AMD may suspend therapy or medicament delivery responsive to determining that one or more components or modules of the AMD do not satisfy a minimum requirement for operation. For example, if the quantity of medicament available to the AMD 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.
  • suspension of therapy occurs based on a loss of a sensor signal, such as the loss of a glucose level signal.
  • 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 having, for example, a wake interface 2422, touchscreen display 2424, and/or alphanumeric pad 2426.
  • the therapy suspension user interface may send a suspension request along with the corresponding information to CCM wherein the suspension control procedures 2436, implemented in CCM, process and send a therapy suspension signal to the device and subject monitoring and control procedures 2432.
  • the AMD can generate an alert prior to suspending delivery of the medicament to the subject.
  • the alert can indicate a suspension start time at which the delivery of the medicament will be suspended.
  • the therapy suspension control procedures 2436 may include a therapy suspension request verification procedure to verify the therapy suspension requests received from the user interface module 2408 or other devices that may communicate with the AMD via wired or wireless links (e.g., smartwatch, smartphone, laptop or desktop).
  • the subject monitoring and control procedures 2432 when the subject monitoring and control procedures 2432 receives the request for therapy suspension from the therapy control procedures 2436, it may send a signal to the medicament dose control procedures 2430 indicating that no dose control signal should be send to the medicament delivery interface 2406 during the period requested by the user 2427. [0279] In some cases, after receiving a request for suspending the medicament delivery, the AMD may delay the medicament delivery suspension responsive to determine that a medical condition of the subject satisfies a threshold medical condition.
  • the device and subject monitoring and control procedures 2432 may receive a signal from the subject sensor (e.g., a CGM sensor) indicating that blood glucose level of the subject is above a threshold level and therefore do not suspend the medicament (e.g., insulin) delivery at a time request by the user.
  • the AMD may suspend the therapy once it determines that medical condition of the subject is improved and does not satisfy a threshold medical condition anymore.
  • a dose control signal can be generated at a next scheduled dosage period after determining that a resumption condition has occurred as discussed herein.
  • a dose control signal can be generated immediately after determining that the resumption condition has occurred.
  • the AMD can generate an alert responsive to determining that a resumption condition has occurred.
  • the alert can indicate that a medical condition of the subject satisfies a threshold medical condition.
  • the AMD determines that the level of one or more analytes in subject’s blood and/or interstitial fluid above or below a set threshold (e.g., based on the signal received from a subject sensor 2420), it may resume the medicament delivery to the subject 2427 by a sending a dose control signal to the medicament delivery interface 2406. For example, if the signal received from a glucose sensor (e.g., CGM sensor) indicates that the blood glucose level of a subject is above a certain threshold level, it may resume the delivery of insulin to the subject to reduce the level of glucose in subject’s blood.
  • a glucose sensor e.g., CGM sensor
  • the AMD may display the alert on a user interface of the AMD and/or a user interface of another device connected to the AMD (e.g., a local or remote electronic device that is wirelessly connected to the AMD).
  • 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, only if the first and second interaction with the user interface are both 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 local or remote device connected (e.g., wirelessly) to AMD.
  • a user may use a smart watch or smart phone to send a therapy suspension request to the AMD.
  • the suspension information provided by the user may include a set of parameters needed for a suspension.
  • the suspension information may include the dates and/or times for starting and ending the therapy suspension, threshold values needed to define 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 (e.g., suspension start 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 blood glucose 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.
  • the stop condition is met when a timer runs out (e.g., temporary suspension period).
  • the stop condition is met when a threshold is met.
  • a threshold may be related to a measurement taken by AMD (e.g., by a subject sensor 2420), such as a measured blood glucose level of the subject 2427. The threshold may be met if the blood glucose level goes above, goes below, or matches a set blood glucose level.
  • multiple conditions may be included in the suspension information received from the user. For example, a time condition and a threshold condition may be set simultaneously. In such examples, the suspension may end sooner than the set time, for example, 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 (e.g., without or no user action to trigger the resumption condition).
  • the indication may include a request to temporarily suspend delivery of therapy for a defined period of time (e.g., temporary suspension period) or until a further interaction or event occurs.
  • the resumption condition can include an expiration of time (e.g., expiration of a temporary suspension period) 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 AMD 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. For example, 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. 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.
  • a visual guide may assist the user in generating the user interaction. For example, 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 each step during the therapy suspension request process, the user interface will turn off and the therapy suspension 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.
  • 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 (e.g., suspension start time) and stop day/time (or suspension period) and/or a resumption condition).
  • the AMD may wait for second gesture on the user interface 2510. If the second gesture is received and verified by the therapy suspension control procedure 2436, the therapy delivery will be suspended 2512.
  • 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 will be canceled, and the touch screen will 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. [0291] In some examples, once a wake action is received 2502, the AMD may automatically activate a therapy suspension user interface 2506, without the need for a first gesture 2504. In these examples, once the request for therapy suspension is received 2508, a gesture (e.g., a first gesture) may be required to verify the request.
  • a gesture e.g., a first gesture
  • FIG.26 is an illustration 2600 of a plurality of example screens that may be displayed on the touchscreen display 2424 of an AMD when a user activates a therapy suspension user interface.
  • Screen 2602 shows a screen an AMD may display to a user 2427 once the user provides a wake action.
  • the therapy suspension system 600 is not limited to the displays shown in FIG.26.
  • Various other screens 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 may appear on the touchscreen display.
  • the pause screen 2604 allows the user 2427 to select a duration of the medicament suspension (e.g., suspension period or temporary suspension period).
  • the AMD 600 may display various interfaces to allow the user 2427 to select a duration of the medicament suspension.
  • the example pause screen 2604 shows a simple interface, giving the user 2427 one of two duration options (e.g., 1 hour and 2 hours).
  • the pause screen 2606 shows the duration 2607 that the user 2427 selected (e.g., in the figure the user 2427 selected 1 hour. 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. As shown by the prompt 2608, the user 2427 is being prompted to swipe right across the bottom of the screen. Once the user 2427 performs the gesture to begin the medicament suspension, the suspension screen 2610 is displayed on the touchscreen. The suspension screen 2610 informs the user 2427 that the medicament is paused.
  • Suspending the medicament delivery may occur by not generating a dose control signal to deliver a dose of medicament during the suspension period. Alternatively, or in addition, suspending the medicament delivery may occur by sending a signal to the medicament delivery interface, to cease providing therapy or medicament to the subject. [0295] In some cases, the AMD may not immediately suspend therapy upon receiving a command to suspend therapy.
  • the AMD may inform that user that the suspension of therapy is being delayed. Further, the AMD may indicate the reason for the delay. In some cases, the user may be able to override the delay and request immediate suspension of therapy.
  • condition e.g., blood glucose
  • a condition of the subject e.g., blood glucose
  • 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.
  • the AMD may inform that user that the suspension of therapy is being delayed. Further, the AMD may indicate the reason for the delay. In some cases, the user may be able to override the delay and request immediate suspension of therapy.
  • the user may override an indication that the suspension of therapy should be delayed to, for example, a suspension start time.
  • the requested start time may be overridden by a determined condition of the subject.
  • the AMD can delay the suspension of medicament delivery responsive to determining that a medical condition of the subject satisfies a threshold medical condition.
  • 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 (e.g., temporary suspension period), a command from a user (e.g., the subject), detection that the AMD 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 blood 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 AMD may confirm that one or more additional condition of the ambulatory medicament device are satisfied before therapy is resumed. For example, if the AMD determines that medicament has not been refilled or if there is a problem with the refill (e.g., cartridge is incorrectly installed), the AMD may continue to maintain the suspension of therapy despite the trigger to resume therapy.
  • FIG. 27 is a flow diagram illustrating an example method for automatic resumption of a suspended therapy that may be implemented by an AMD.
  • the AMD suspends the delivery of one or more therapies 2704 selected for suspension at suspension initiation time received as part of the suspension information.
  • therapy suspension control procedures 2436 may deactivate the medicament dose control procedures 2430 using the device and subject monitoring and control procedures 2432.
  • the therapy suspension control procedures 2436 may continuously monitor the system clock and the subject and device condition (e.g., using medicament dose control procedure 2430).
  • the therapy suspension control procedures 2436 determine that the time passed since the suspension initiation is less than the requested suspension time period 2706 and none of the conditions for resumption has been met 2708, the therapy suspension may continue. If a suspension resumption condition occurs, the one or more suspended therapies will be resumed 2712. [0302] If the therapy suspension control procedures 2436 determine that the time passed since the suspension initiation is equal to the requested suspension time period 2706, or one or more resumption conditions have been met 2708, it 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.
  • a therapy suspension may be ended before the one or more conditions to end the suspension are met 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 procedures 2436. If the therapy suspension procedures 2436 verify that the third interaction with the user interface is a predetermined third user interface interaction, the device and subject monitoring and control procedures 2432 may activate them medicament dose procedures 2430.
  • 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.
  • 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.
  • the user may need to provide a fourth gesture to end the suspension before the one or more conditions to end the suspension are met.
  • the third and fourth gestures may be simple or complex.
  • FIG.28 is an illustration 2800 of a plurality of example screens that may be displayed on the touchscreen display 2424 of an AMD 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 in user’s blood.
  • various vital measurements that are useful to the user 2427 may be displayed on the screen 2802 that may be displayed during therapy suspension period.
  • the therapy suspension ends if the glucose concentration of the blood of the user meets or passes a threshold.
  • the screen 2804 which may be activated by a user interaction (e.g., a gesture on the touchscreen display), allows the user 2427 to select and execute various functions on the AMD 600.
  • the resume button 2805 may be used to end a therapy suspension.
  • a resume screen 2806 may appear on the touchscreen display.
  • 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 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 by the AMD.
  • a resumption screen 2808 appears on the display indicating that the regular medicament delivery has been resumed.
  • a lock screen 2810 may be displayed. The lock screen 2810 prevents the user 2427 from inadvertently executing more functions on the AMD device 600 after resuming the medicament delivery.
  • the therapy suspension procedures 2436 may activate the medicament dose procedures 2430 using the device and subject monitoring and control procedures 2432. Subsequently, if the medicament dose control procedures 2430 determine that a dose of medicament should be supplied to the user (at least in part based on the information received from one or more subject sensors 2420), it may provide a dose control signal to the medicament delivery interface 2406. In some examples, a dose control signal can be generated at a next scheduled dosage period after determining that a resumption condition has occurred as discussed herein.
  • a dose control signal can be generated immediately after determining that the resumption condition has occurred.
  • the AMD 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 or upon a resumption condition is satisfied (e.g., a suspension time expires).
  • Additional embodiments relating to suspending medicament delivery to a subject that can be combined with one or more embodiments of the present disclosure are described in U.S.
  • An ambulatory medical device such as, but not limited to, an ambulatory medicament device (e.g., an insulin pump), that provides life-saving treatment to subjects, for example, 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 AMD.
  • a user interface e.g., a touchscreen display
  • 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).
  • a healthcare provider can modify the settings of the AMD.
  • a non-healthcare provider modify at least some settings of the AMD.
  • changing the medicament cartridge may include interacting with a user interface and/or one or more settings of the AMD.
  • Another example of when it is desirable for a non-healthcare user (e.g., a subject, parent, or guardian) to modify settings of the AMD is when the initial settings of the AMD are not providing the desired effect (e.g., sufficient medicament, too much medicament, providing the medicament too slowly or too fast, etc.).
  • desired effect e.g., sufficient medicament, too much medicament, providing the medicament too slowly or too fast, etc.
  • normal maintenance of the AMD and/or subject may require interaction with the AMD settings and/or controls.
  • negative consequences may begin to occur when an AMD 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 AMD 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 AMD (e.g., pausing operation until the site change is completed).
  • a healthcare provider e.g., the subject receiving therapy, a parent, or a guardian
  • 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.
  • One solution to regulating access to settings of the AMD is to implement a lock feature to require that a user provide a passcode, password, or other information before the user is permitted to modify a setting of the AMD, such as a control parameter. To simplify the discussion, the disclosure will describe using a passcode.
  • the passcode can be substituted for a password or any other type of secret or semi-secret information.
  • the user may enter a security code into the AMD or an intermediary device that the AMD and/or the intermediary device may validate or verify matches the passcode to access certain functions of the AMD as discussed herein. If the security code cannot be validated after a predetermined number of security code entry attempts, further security code entry attempts can be denied for a period of time. In some examples, when the AMD is in the locked state, it may continue delivering therapy to the subject at the same rate as unlocked state. [0315]
  • 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 (e.g., touchscreen display).
  • the setting may include an on/off toggle (via, for example, 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.
  • a passcode e.g., 4 to 8 numeric digits
  • the passcode e.g., a 4 to 8 numeric digit code
  • the user may program the AMD 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 AMD may periodically generate a new passcode (e.g., an override passcode), or may generate the new passcode at a time when a user supplies the passcode.
  • the user interface element used for accessing a user interface that enables changing one or more settings of the AMD may differ from a user interface for modifying the control parameters associated with that setting. For example, 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.
  • 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 interface may proceed as normal. Otherwise, the user interface may revert back to the original lock screen.
  • 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, parameter control elements, or user parameter control elements, may require a passcode.
  • access to each user parameter control element may require a different passcode.
  • providing a passcode to an AMD in locked state may directly enable access to a subset of parameter control elements.
  • a first gesture may be required before a plurality of user selectable elements are presented.
  • the passcode may be set by the user enabling the user to select a passcode the user is more likely to remember. However, regardless of who sets the passcode, there is a risk that the user will not remember the passcode.
  • embodiments disclosed herein include an AMD that includes an override passcode that enables access to the AMD (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, and 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.
  • the passcode or the override passcode may comprise performing a pattern or sequence on the touchscreen (e.g., drawing an image), a multi-touch interaction or any other type of interaction with a touchscreen, or portion thereof. Another example of a complex gesture is entering a predetermined sequence of touches.
  • the passcode may include a quiz or set of questions.
  • the AMD may be configured to receive therapy settings or modifications to therapy settings from an intermediary device via a communication connection.
  • 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 AMD.
  • this feature may be supported in addition to providing the user with options 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 AMD 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 AMD.
  • access to the user interface of the intermediary device that allows modifying AMD settings may require a passcode.
  • the passcode required for changing one or more settings via an intermediary device may be different from the passcode required for changing the same settings directly using the AMD’s user interface.
  • a user may provide a user-generated passcode or an override passcode via an interface of the intermediary device.
  • the intermediary device may then provide the user-generated passcode or the override passcode to the AMD 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.
  • Embodiments disclosed herein are applicable regardless of whether the user interface for modifying therapy settings or the configuration of the AMD device is generated or presented by the AMD to the user or via another device.
  • 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) established 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 AMD at the time of manufacture and may be shared among multiple AMDs (e.g., a global override passcode), or may be unique to a particular AMD.
  • the override passcode may be managed by the manufacturer or by a third-party service.
  • 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 AMD.
  • 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. In some such cases, it may be necessary for the user to authenticate him or herself. Further, the user may be required to provide a serial number of the AMD. In some cases, each model or each unit of the AMD 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. [0328] In some examples, the AMD may periodically generate a new override passcode or may generate an override passcode at a time when a user supplies the passcode.
  • the AMD 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, using a computing device that can access a common parameter value as the AMD.
  • the override passcode may change over time or be a rotating passcode.
  • the override passcode may change at periodic intervals every thirty seconds, every minute, every hour, etc.
  • the override passcode may be determined from an algorithm executed by an application.
  • the AMD may store a copy of the algorithm in a memory of the AMD 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 AMD 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. For example, the override passcode may be calculated based on a portion of a serial number or model number for the AMD and the time. The determination of the override passcode may be calculated by the AMD, a computer server, and/or an application on a user device. [0330] In some cases, the override passcode can be automatically received by the AMD (e.g., after a user requests an override passcode). Thus, a user may not need to see or enter the override passcode. In some cases, the override passcode may be transmitted to another device of the user (e.g., a smartphone or laptop).
  • another device of the user e.g., a smartphone or laptop.
  • the override passcode can be texted to a user’s smartphone, for example, for the user to then enter the override passcode on the AMD.
  • the override passcode 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 or at the subject’s place of residence.
  • the determination of the location of the AMD be based on a geolocation system (e.g., a Global positioning System (GPS)) available to the AMD.
  • 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 AMD, or other devices that can modify a control of the AMD, 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 AMD.
  • 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 AMD may have an advanced therapy screen, or other user interface, that permits a healthcare provider, or other user, to obtain additional details or advanced settings relating to therapy provided by the AMD.
  • the advanced therapy screen or state 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 or state.
  • the advanced therapy screen may permit the healthcare provider to modify control parameters (e.g., advanced control parameters via one or more advanced parameter control elements) that may not be modifiable by other users.
  • control parameters e.g., advanced control parameters via one or more advanced parameter control elements
  • 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., Tmax).
  • Access to the advanced therapy screen may be limited by requirement of a passcode or advanced settings passcode via, for example, a user entering a security code or an advanced settings security code (using for example one or more advanced settings parameter control elements) that can be validated or verified to match the passcode or advanced settings passcode.
  • the passcode or advanced settings passcode 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. However, 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 a period of time (e.g., set by a subject or another authorized user such as the guardian or apparent of the subject). The clinician passcode may expire after a predetermined period. For example, the clinician passcode may be valid for a day, a week, or a month (expiring at least once per day, per week, or per month).
  • the AMD may allow certain authorized users to terminate the clinician access at any time.
  • access to the advanced therapy screen or state may be limited to a particular period of time. After the time period expires, the AMD may automatically restrict access to the advanced therapy screen or state. 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 or state, the screen or state may remain accessible. [0337] In some cases, 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.
  • a user’s direction may or may not be followed depending, for example, if the request exceeds a threshold or may cause blood 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 AMD 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 or state of the AMD.
  • the passcode may be desired to prevent particular users from inadvertently changing certain control parameters of the AMD device.
  • features of the AMD that do not affect therapy may remain accessible to a user when the AMD is in a locked state. For example, 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. Further, as the passcode feature is generally to prevent control parameter changes, the AMD may provide therapy and continue to provide therapy at the same rate and under the same condition, whether or not the AMD is locked or unlocked. [0340] When the AMD receives the user passcode or the override passcode, the AMD may validate the passcode. The passcode may be validated by comparing the received passcode to a passcode stored in a memory of the AMD or generated by the AMD.
  • the user may be granted access to a user interface to modify one or more control parameters.
  • the user may be requested to re-enter a passcode to confirm a change to a control parameter.
  • the user may be requested to provide a gesture on a touchscreen to confirm a change to a control parameter.
  • the AMD, or other control device that can provide access to control parameters of the AMD 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.
  • 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.
  • the user passcode option may be indefinitely locked or blocked.
  • the control parameters of the AMD 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 AMD.
  • 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 AMD. 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 AMD.
  • 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 AMD upon establishing a connection.
  • the AMD 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. When the AMD determines it is within the geo-fence, the AMD may automatically be unlocked.
  • FIG. 29 is a block diagram illustrating an example of 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 or 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 security code for a passcode input 2933 (e.g., a security code for 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 security code for a passcode input 2946 using an intermediary device 2923 (e.g., a laptop, a smart phone, and/or the like) that is connected to the AMD (e.g., via a wired or wireless link).
  • an intermediary device 2923 e.g., a laptop, a smart phone, and/or the like
  • the security code may be transmitted to the control and computing unit of the AMD where a set of setting change control procedures 2935 determines the validity of or verifies the security code by comparing security code to the one or more user generated passcodes or passwords 2939 or override passcodes or passwords 2937 stored in a memory of the CCM.
  • the access to one or more setting control screens 2940/2942/2944 and/or parameter control elements 2941/2943/2945 may be managed by the setting change procedures 2928.
  • the setting change procedures 2928 may be changed and may be considered the advanced settings as discussed herein, requiring a different passcode for access from the passcode to access, for example, the one or more setting control screens 2940/2942/2944 and/or parameter control elements 2941/2943/2945.
  • Setting change procedures can be machine readable instructions stored in the AMD and executed by one or more hardware processors.
  • the option to provide a security code corresponding to a passcode may become available, when the user 2927 performs a wake action on a wake interface 2923, which can include a user input element associated with recognizing the wake action or some other user interaction.
  • the wake control module 2934 of the CCM determines that a valid wake action is performed (and enters a valid security code) , 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 the element associated with settings change may activate a second screen that presents selectable elements associated with the setting control screens 2940/2942/2944.
  • access to one or more 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.
  • access to the first screen 2940 may require a first passcode
  • the access to the second screen 2942 may require a second passcode
  • the access to the third screen 2944 may not need a passcode.
  • all the control screens 2940/2942/2944 may be presented without the requirement a passcode, but access to the one or more control elements in a control screen may require a passcode.
  • the user may select the second screen 2942 without entering a security code, but in order to select one or more parameter control elements 2943 on that screen, the user may need to enter one or more security codes matching one or more passcodes.
  • FIG.30 is a flow diagram illustrating an example method that may be used by an AMD and/or intermediary device to allow a user to change a setting of the AMD and/or intermediary device using a user generated passcode or an override passcode.
  • a user interface may be activated (e.g., a user interface on the touchscreen display 2924).
  • the wake action may be received by the wake interface 2922 of the AMD).
  • the wake action may directly activate a setting change interface 3004 (e.g., a setting change screen presented on a touchscreen display with one or more parameter control elements).
  • a first gesture may be required after the wake action to activate a setting change interface.
  • a specific wake action may activate the setting change interface.
  • the AMD and/or intermediary device e.g., the setting change procedure in the CCM
  • may request a security code 3006 e.g., by presenting a window to enter a security code such as a passcode display of a keypad).
  • the AMD e.g., the setting change procedure in the CCM
  • the AMD and/or intermediary device may determine whether the security code matches a user generated passcode 3008. If it is determined the security code matches with a user generated passcode, the AMD and/or intermediary device may provide access 3010 to one or more control parameter elements associated with the validated passcode. If the received security code does not match with any of the stored user generated passcodes, the AMD and/or intermediary device may determine whether the security code matches with an override passcode 3012.
  • FIG.31 is a flow diagram illustrating another example method that may be used by an AMD and/or intermediary device to allow a user to change a setting of the AMD using a user generated passcode or an override passcode.
  • the AMD and/or intermediary device 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.
  • a user interface e.g., a touchscreen display
  • the AMD and/or intermediary device may activate 3106 a setting change interface (e.g., a setting change screen on a touchscreen display).
  • the setting change interface may include one or more parameter control elements associated with one or more AMD settings.
  • the setting change interface or a screen may include one or more selectable elements each associated with a setting change screen (e.g., a screen provided on a touchscreen display) that may include one or more control parameters.
  • a request for setting change is received 3108, for example by a user interaction with one or more parameter control elements, the AMD and/or intermediary device may determine whether the requested setting change is passcode protected 3110.
  • 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). [0352] If the AMD and/or intermediary device determines that the requested setting change is not protected by a passcode, it 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 and/or intermediary device may change one or more settings 3118 according to the requested and confirmed changes.
  • the AMD and/or intermediary device may request security code 3120 via a passcode display (e.g., provided on a touchscreen display).
  • the request for the security code may be presented on a display but the security code may be received via a physical keypad.
  • the AMD and/or intermediary device may validate the security code against a passcode 3124 by comparing it with one or more user generated passcodes or an override passcode (e.g., does the entered security code match the passcode). If it is determined that the security code matches with a user generated passcode or an override passcode, the AMD and/or intermediary device may activate 3126 one or more parameter control elements associated with the requested setting change. Subsequently, the AMD and/or intermediary device may receive a setting change via the selected control parameter element 3128. In some examples, the user may need to provide a second gesture on the user interface (e.g., touchscreen display) to confirm the changes made.
  • the user interface e.g., touchscreen display
  • the AMD and/or intermediary device may change one or more settings according to the requested and confirmed changes 3132.
  • AMD with Alarm System [0354]
  • 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 (AMD) 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 AMD may be operating as intended, but the condition of the subject may not satisfy a desired level of health. In either case, it is generally desirable to generate an alarm to inform the subject and/or one or more users of the condition of the AMD and/or the subject.
  • This section of the disclosure relates to an ambulatory medicament device (AMD), 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.
  • AMD ambulatory medicament device
  • Glucagon a combined insulin and counter-regulatory agent
  • 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 annunciation and control system that process the received data and generate alarms if an alarm condition is met.
  • the monitoring system interface and the alarm annunciation and control module are implemented using one or more hardware processors and machine readable instructions.
  • the monitoring system interface and the alarm generation module are separate hardware modules.
  • an alarm system 3222 implements alarm control procedures in the control and computing module 610 (CCM) of the AMD.
  • CCM control and computing module 610
  • the alarm 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 614 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.
  • the hardware processor of the monitoring system may be a separate hardware processor.
  • the alarm system 3222 includes a monitoring system interface 3226 and an alarm annunciation and control system 3228.
  • the alarm annunciation and control system 3228 may include sub-systems for determining the severity of an alarm condition, user notification processing and receiving alarm control commands from the user interface module 3208.
  • the user interface module 3208 may include one or more of the embodiments described with respect to the user interface module 1808.
  • the monitoring system interface 3226 may monitor the condition or status of the AMD and/or the subject at least partially based on signals or status values received from a set of device sensors 3224 and a set of subject sensors 3220.
  • the device sensors 3224 may be configured to track the status of the components or the elements of the AMD, and the subject sensors 3220 can be configured to obtain measurements of one or more physiological characteristics of the subject [0360]
  • 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 sugar, serum levels of various hormones or other analytes).
  • the subject sensor can be a continuous glucose monitoring sensor (CGS).
  • the device and subject monitoring system interface 3226 may continuously receive and analyze signals from device sensors 3224 and subject sensors 3220 to determine the condition of the AMD, 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 AMD.
  • a continuous glucose monitoring CGM sensor may be used to monitor the condition of the subject, and may also 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 AMD, but that may communicate with the AMD.
  • the alarm 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 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 action or a wake action followed by a first gesture on, for example, a touchscreen display.
  • the first gesture may be created by entering predetermined or particular characters on the alphanumeric pad.
  • the alarm 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 3227 to acknowledge the alarm that the ambulatory medical device 600 is delivering to the user.
  • An example of an inadvertent alarm acknowledgment is one that was accidentally executed by the user 3227 by putting pressure on the ambulatory medical device 600 in the jacket pocket of the user 3227.
  • the alarm 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 interface 3226.
  • the alarm annunciation and control system 3228 may place it in the appropriate queue, for example, based on severity or category.
  • a list of alarms may be generated wherein alarms may be sorted numerically in descending order with the highest priority fault displayed at the top.
  • the alarm 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
  • the device and subject monitoring system interface 3226 may provide a status information received from the device 3224 and/or subject sensors 3220 to the alarm annunciation and control system 3228.
  • the status information may comprise one or more status values.
  • the status information may comprise device information pertaining to a condition of the ambulatory medicament device or subject information pertaining to a condition of the subject.
  • the alarm annunciation and control system 3228 is configured to determine based at least in part on the status information 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.
  • each alarm threshold or alarm condition may be associated with an alarm profile.
  • 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.
  • 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).
  • at least some of the alarm profiles may be stored in the storage 618 at the time of manufacture.
  • Each of the alarm profiles may indicate the characteristics or status of the AMD 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 blood 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 blood glucose level.
  • a blood 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 blood 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 AMD 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., blood 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
  • each of these errors or conditions may be associated with different severity levels that cause the annunciation of different alarms.
  • each 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.
  • 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.
  • 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.
  • the AMD 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.
  • 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 AMD may continue to provide therapy.
  • the alarm condition interferes with the delivery of therapy
  • operation of the AMD may be suspended or partially suspended.
  • alarm conditions that interfere with the provisioning of therapy may be associated with a higher severity level.
  • some alarm conditions that interfere with the provisioning of therapy may be associated with lower severity levels. For example, a determination that the AMD cannot supply insulin may normally be associated with a highest severity alarm.
  • 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).
  • the AMD in response to determining that the severity level of the alarm condition matches an unsafe operation (e.g., a condition that may cause the AMD to provide doses of the medicament that are above or below certain values, or to unreliably determine the subject’s condition), the AMD may suspend delivery of the medicament to the subject. Once the condition is resolved, the AMD may resume delivery of medicament to the subject. If on the other hand it is determined that the alarm condition matches a safe operation severity level, the AMD may be configured to maintain delivery of medicament to the subject.
  • an unsafe operation e.g., a condition that may cause the AMD to provide doses of the medicament that are above or below certain values, or to unreliably determine the subject’s condition
  • the AMD may suspend delivery of the medicament to the subject. Once the condition is resolved, the AMD may resume delivery of medicament to the subject. If on the other hand it is determined that the alarm condition matches a safe operation severity
  • the alarm annunciation and control system 3228 can implement an annunciation pattern selected based at least in part on the status information generated by and/or received from the monitoring system 3226.
  • the annunciation pattern may be selected from a plurality of annunciation patterns based at least in part on the alarm condition and/or the status information.
  • the alarm annunciation and control system 3228 Upon verifying that an alarm condition associated with an alarm profile or alarm condition is satisfied, the alarm annunciation and control system 3228 annunciates the alarm condition.
  • the alarm conditions may be associated with a unique annunciation pattern.
  • the AMD may have a wireless electronic communications interface that can be used to transmit an alarm signal, status information, alarm condition data, and/or an annunciation pattern to a remote electronic device. In some such cases, the remote electronic device may annunciate an alarm if an alarm condition is met.
  • the remote electronic device may include any device that can receive alarm information or status information from the AMD.
  • the remote electronic device may be a smartphone, smartwatch, smart glasses, a laptop, a tablet, or any other computing device.
  • 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 comprise a list of elements (e.g., icons, text, and the like) each indicating an alarm condition (e.g., an alarm condition that has been annunciated).
  • the AMD may display an alarm state icon comprising a visual indication of a count of alarm conditions on 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 touchscreen 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 and control 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.
  • 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 pattern, intensity, etc.
  • an alarm with a different severity level than the highest severity level may be permitted to be snoozed or dismisses or snoozed for a longer period of time.
  • 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 these).
  • 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. In some cases, the duplicate alarm is ignored. In some cases, the occurrence of a duplicate alarm may cause an escalation of the existing alarm. For example, if 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 than 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 observed via a user interface (e.g., a touchscreen display) when the user interface is locked.
  • details about the alarms may be accessible when the user interface is locked.
  • it may be necessary to unlock the user interface unlocked e.g., by a wake action and/or a gesture).
  • 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.
  • 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., blood 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.
  • the alarm conditions may be displayed on a display of the AMD.
  • 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 AMD.
  • 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 AMD.
  • annunciating the alarm may include contacting 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 how to replace the insulin cartridge.
  • 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.
  • the alarm may include one or more operations associated with the alarm.
  • the alarm may trigger reordering of insulin or may request that the user confirm a reorder request to reorder insulin. Resolving an alarm
  • 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.
  • a user may be able to acknowledge and/or snooze alarms via a user interface.
  • the user may first need to activate the user interface (e.g., by providing a wake action) and then provide a gesture to unlock the user interface.
  • the user may use the wake button to activate a touchscreen display and then provide a gesture on the screen to unlock display.
  • the touchscreen display may be configured to allow the user or subject to navigate directly to the issue or fault for which an alarm is being delivered. This capability provides the user with access to address the fault causing the alarm so that it could be corrected thereby stopping the alarm.
  • 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.
  • 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.
  • a 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. In some cases, 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.).
  • 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. In some cases, the user can only interact with the alarms when the AMD and/or the user interface is unlocked. In some cases, the user can interact with the alarms to snooze them or to obtain further information, when the AMD is locked. However, the user may not be able to dismiss the alarm without unlocking the ambulatory medicament device.
  • FIG.33A 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 and control 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 at block 3302 from one or more device sensors 3224 and/or one or more subject sensors 3220 via the monitoring system interface 3226.
  • the one or more device sensors 3224 may include any type of sensor that can determine a condition of the AMD.
  • the one or more device sensors 3224 may include a battery charge sensor that determines a charge of a battery, a battery condition sensor that determines a condition of a battery, a medicament sensor that determines a quantity of medicament remaining, or any other type of sensor that can determine a condition of one or more electronic or mechanical components of the AMD.
  • the one or more device sensors may determine if a quantity of medicament is below a threshold or if a battery charge is below a threshold.
  • the one or more subject sensors 3220 can include any type of sensor that can determine a health-related characteristic or physiological parameter of the subject.
  • the one or more subject sensors 3220 can determine a blood glucose measurement, a blood pressure measurement, a respiratory rate, a blood oxygenation level, a pulse rate, or any other physiological characteristics of a subject.
  • the one or more subject sensors 3220 may measure any physiological parameter of the subject that may relate to monitoring, managing, or treating a subject’s diabetes.
  • the alarm annunciation and control system 3228 determines whether the received status information satisfies an alarm condition at decision block 3304.
  • the alarm condition may be an alarm condition in an alarm profile.
  • the alarm system may determine whether the alarm condition is already present in the list of pending alarm conditions at decision block 3308. If the alarm condition is not present in the list of pending alarm conditions, the alarm system may determine the severity level of the alarm condition at block 3310, add the alarm condition to the list of pending alarm conditions at block 3312, and increment an alarm count that tracks a number of occurrences of an alarm or a fault count that tracks a number of faults occurring in the AMD. In some examples, the placement of the alarm condition in the list of pending alarm conditions may depend on the determined severity level of the alarm condition.
  • the alarm conditions may be categorized numerically in descending order with the highest priority fault displayed at the top.
  • the alarm annunciation and control system 3228 may select an annunciation pattern at block 3314 and annunciate the alarm condition using the selected annunciation pattern at block 3316. If the alarm condition is present in the list of pending alarm conditions, the alarm system may select an annunciation pattern at block 3318 and annunciate the alarm condition using the selected annunciation pattern at the block 3316.
  • 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.
  • the annunciation pattern selected at block 3318 may be selected based at least in part on a 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 periodically, intermittently, according to a particular schedule, or while the ambulatory medical device is in use. The frequency with which the process is repeated may depend on the particular alarm condition detected from the status information.
  • the alarm system may wait for user acknowledgment of the alarm at block 3320. If the user acknowledges the alarm, the system proceeds to resolve the alarm 3322. In some cases, resolving the alarm may include providing instructions to a user or indicating where a user can locate instructions to resolve the alarm condition.
  • the user may be provided with repair instructions for repairing the AMD.
  • resolving the alarm may include automatically ordering or requesting that the user confirm an order is to be placed to replenish a medicament. If the user fails to acknowledge the alarm, the annunciation may be repeated after a certain time period at block 3324 determined based on the severity level of the alarm. In some examples, if the user fails to acknowledge the alarm, the annunciation continues and may escalate depending on the severity level of the alarm.
  • a user or the subject may view an alarm using a user interface provided on a touchscreen display both when the display is locked and when the display is unlocked. Fig.
  • the user interface 3326 includes an alarm icon 3328; a pump operation field 3330; and an unlock button (or a first gesture field) 3332.
  • the alarm icon 3328 in this exemplary embodiment, is shaped as an alarm bell with a counter in the middle indicating the number of annunciated alarms (e.g., “0” in the examples shown).
  • the unlock field is configured such that the user may unlock the display by sliding in the direction of the chevrons, for example. However, the user may still view the alarms without unlocking the interface.
  • the display illustrated in 3334 will appear if there is no alarm in the system. If there are existing alarms in the system, the display of 3336 appears wherein a list of alarms is displayed however the user cannot select the alarms (e.g., to see more information or acknowledge the alarms). The inability to select the alarms is exemplified by the absence of chevrons by each alarm. The number of alarms displayed may be limited by the size of the screen. [0405] In some such examples, if the user unlocks the screen by sliding the unlock button 3332, the user interface 3327 illustrated in Fig. 33C may be displayed.
  • the user interface 3327 includes the alarm icon 3328; a menu icon 3329; and the pump operation field 3330.
  • the menu icon 3329 may allow the user to control operation of the AMD 600 and the alarm icon 3328 may provide the user with access to the alarm control functions.
  • the display illustrated in 3335 may appear on the screen if there is no alarm in the system.
  • the display of 3337 may appear wherein a list of alarms is displayed with each alarm having a chevron 3339 that enables selecting the alarm to access further control functions for the selected 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 the 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.
  • 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 a base level when the user acknowledges the fault; however, the base alarm may remain if the 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.
  • Additional embodiments relating to determining a severity of an alarm condition and annunciating the alarm based at least in part on the severity of the alarm condition are described in U.S. Provisional Application No.62/911,017, which was filed on October 4, 2019 and is titled “ALARM SYSTEM AND METHOD IN A DRUG INFUSION DEVICE,” the disclosure of which is hereby incorporated by reference in its entirety herein for all purposes.
  • Non-critical AMD Condition Management a condition may occur that impacts the operation of the ambulatory medical device (AMD) that provides therapy to a subject.
  • AMD ambulatory medical device
  • an AMD can be an ambulatory medicament device. This condition may be associated with the ability of the AMD to operate as intended by the manufacturer, a subject receiving therapy from the AMD, and/or user (e.g., healthcare provider, parent, or guardian of the subject).
  • the condition or malfunction of the AMD may prevent the AMD from providing therapy to the subject.
  • the condition or malfunction may permit, at least for a period of time, the AMD to continue providing at least partial therapy to the subject.
  • the best 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 AMD 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 of device malfunction alert prioritization may be used by other systems.
  • the system disclosed herein can detect a condition in which the AMD does not meet a manufacturer’s specification (e.g.
  • appropriate instructions e.g., call manufacturer for replacement medicament or parts
  • the alert may be re-annunciated, or annunciated again, 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 providing, for example, for a fixed static time period or periodically between alerts).
  • the length of time between annunciations may depend on the severity of the fault.
  • the re-annunciation cannot be stopped by the user, but may only cease if the underlying condition is resolved.
  • the re- annunciation time period may be a variable time period and may gradually increase to minimize fatigue alert.
  • the re-annunciation time period may be a variable time period and may gradually decrease if the alert becomes more urgent or increase in urgency. In some cases, the re-annunciation time period may change during the day based on time of day. For example, alerts may be provided during the day, but silenced or reduced during the night.
  • the method may include detecting a condition of the AMD.
  • the condition of the AMD may comprise a set of operating parameters of the AMD.
  • the condition of the AMD may be determined using one or more sensors of the AMD. Further, the condition of the AMD may be determined by the presence or absence of one or more errors when performing one or more functions of the AMD.
  • the AMD 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 AMD.
  • the AMD 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 AMD 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). In some examples, the condition of the AMD may be determined based on the performance of the AMD over period.
  • the method may include comparing the detected condition of the AMD to a set of normal operating parameters.
  • the set of normal operating parameters may be the specifications set by the manufacturer for when the AMD is operating as intended by the manufacturer.
  • at least some of the normal operating parameters may be provided by a healthcare provider.
  • at least some of the normal operating parameters may be provided by the subject or an authorized user.
  • 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 AMD to the set of normal operating parameters may include comparing each operating parameter in the specification to a corresponding detected operating parameter of the AMD.
  • the AMD may generate a user alert or non-critical malfunction alert based on the determined condition of the AMD. For example, the AMD may generate an alert when the detected condition of the AMD 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. In some cases, 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 AMD to maintain or continue providing therapy to the subject.
  • the minimum operating parameters are the operating parameters sufficient to provide therapy.
  • the minimum operating parameters may not be sufficient to enable all features of the AMD.
  • the minimum operating parameters may permit the AMD to deliver insulin to the subject, but may not be sufficient to deliver the insulin at a normal delivery speed for the particular AMD.
  • 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 be specified by the manufacturer at the time of manufacturing.
  • 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. [0417] When it is determined that the condition of the AMD satisfies at least the minimum operating parameters, the AMD 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 rate or minimum maintenance rate (e.g., providing only basal insulin).
  • a reduced rate e.g., providing only basal therapy and therapy responsive to a meal announcement
  • a minimum rate or minimum maintenance rate e.g., providing only basal insulin
  • the ability of the AMD to distinguish between a minimum set of operating parameters and a normal set of operating parameters enables an AMD with a malfunction to continue providing therapy, which sometimes includes life-saving treatment, to a subject until the AMD can be repaired or until the condition of the device worsens to a point where the minimum operating parameters cannot be maintained.
  • the AMD may temporarily maintain delivery of therapy. Temporarily maintaining therapy may provide a subject time to address the issue that caused the AMD to not satisfy the normal operating parameters before the subject loses access to therapy. In some cases, the AMD temporarily maintains therapy until the device condition makes it no longer possible to maintain therapy. [0418] FIG.
  • 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.
  • 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 AMD (e.g., a memory in CCM 610) and executed by a hardware processor 614 of the AMD (e.g., a processor in CCM 610) 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. In some cases, the hardware processor of the monitoring system may be a separate hardware processor.
  • the alert control procedures 3422 may include a monitoring system 3426, a set of operation monitoring procedures 3425 and a set of alert generation procedures 3428.
  • a set of device sensors 3424 may be configured to track the status of the components of the AMD.
  • a set of operation monitoring procedures 3425 may be configured to monitor the operation of the components, modules and other procedures (e.g., temporal behavior of the signals provided by the components, communication between different devices and modules, performance of the procedures implemented in the CCM 610 and the like).
  • a device sensor may determine that a component is properly connected and it is functional, while the operation monitoring procedures 3425 may provide data related to signals generated by the component over a period.
  • the monitoring system 3426 may monitor and evaluate a set of operating parameters of the AMD at least partially based on the information received from the operation monitoring procedures 3425 and device sensors 3424.
  • the alert generation procedures 3428 may compare the determined operating parameters of the AMD, received from the monitoring system 3426, with a set of normal operating parameters.
  • the alert generation procedures 3428 may also determine whether the operating parameters of the AMD satisfies a minimum set of operating parameters.
  • the alert generation procedures 3428 may generate an alert.
  • the alert may be transmitted to the user interface module 3408 and displayed on a display of the AMD (e.g., a touchscreen display).
  • the AMD may establish a connection (e.g., a wireless connection) with another device using the communication module 3402.
  • 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 local device and/or the computing systems where it may be displayed on user interface associated with the local device or the computing system.
  • the local devices and/or the computing system may receive data from the AMD device enabling the user to monitor the operating parameters of the AMD.
  • 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 procedures 3428 may cause the medicament 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 AMD conditions or different operational parameters of the AMD may be associated with or may trigger different types of alerts.
  • the alert may enable the user to determine the device condition of the AMD based on the type of alert. For example, an indication that the AMD failed to deliver a medicament may trigger one type of alert while an indication that the level of a medicament in the AMD has dropped below a particular level may trigger a different type of alert.
  • the user alert or non-critical malfunction alert is dismissible and/or may be snoozed by the user. In some cases, such as when the AMD fails to satisfy a set of minimum operating parameters, the user alert or non-critical malfunction 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).
  • the snooze options may vary for different alerts or any of the aforementioned conditions.
  • the AMD may escalate or prioritize an alert if it detects that the condition of the AMD has become more critical.
  • the re-annunciation time period or variable time period may gradually increase to minimize fatigue alert, or the condition of the AMD has become less critical.
  • the re- annunciation time period or variable time period may gradually decrease if the condition of the AMD 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 AMD 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 be an acknowledgement of the alert.
  • the alert modification condition may include a worsening of the AMD condition.
  • the modification to the alert may include the substitution or prioritization of the alert to a different alert that indicates a different or more serious condition of the AMD.
  • an urgent condition may become critical if the detected malfunction is not addressed after generating certain number of alerts.
  • it may be prioritized, trigger a different alert types or different user/non-critical malfunction alert types (e.g., a louder sound, different sound, different frequency, brighter image or the like), and/or escalation in the alert frequency.
  • the audible alert may become louder and may be combined with a vibration alert from a haptic annunciator.
  • the AMD 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. [0428] Once the malfunction is addressed, the AMD 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 AMD may automatically dismiss the alert when it determines that the device condition that caused the alert has been resolved (e.g., using the alert control procedures 3422) . In some cases, the AMD 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, using a device or computing systems that is connected to the AMD (e.g., via a wireless connection such as 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 AMD. The notification may be received by the AMD device via a wireless connection (e.g., NB-LTE connection). Alternatively, or in addition, the notification may be received via a computing device, such as a smartphone or laptop. [0430] 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 3502. [0431] 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 3508.
  • the alert system may send a signal to the therapy delivery module 606 or medicament delivery interface 1806 (e.g., using medicament dose control procedures 1830) to stop delivery of therapy to the subject 3509, and to generate a critical user alert or critical alert 3511 that is prioritized by indicating that immediate or urgent 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.
  • the alert system may maintain the delivery of therapy to the subject 3510 and generate a user alert or non-critical malfunction 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.
  • the alert system may determine whether the new device condition satisfies a normal set of parameters 3516.
  • the alert system may resume the normal operation of the AMD 3518 (e.g., deliver the therapy at a normal rate). If at block 3516, it is determined that the new device condition does not satisfy a set of normal operating parameters, the alert system may determine whether the new device condition satisfies a minimum set of parameters 3520. If, at block 3520, it is determined that the new device condition satisfies 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 or non-critical malfunction alert 3524 according to the new device condition.
  • the alert system may send a signal to the therapy delivery module to stop delivery of therapy to the subject 3521, and generate a critical user alert 3523 indicating that immediate or urgent action is required.
  • the critical user alert 3523 may be prioritized over other types of alerts and alarms.
  • 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.
  • An automated blood glucose control system may automatically provide insulin and/or a counter-regulatory agent (e.g., Glucagon) to a subject to help control the blood glucose level of the subject.
  • a control algorithm is implemented by an automated blood glucose control system (BGCS) to determine when to deliver one or more glucose control agents and how much agent to provide to the subject.
  • BGCS automated blood glucose control system
  • 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 blood glucose level to within a desired range.
  • the control algorithm may use blood glucose level readings obtained from a sensor, such as a continuous glucose monitoring (CGM) sensor, that obtained automated blood glucose measurements from the subject.
  • 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.
  • Insulin may be administered subcutaneously into blood of 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.
  • the blood glucose control system may implement a predictive algorithm that implements a bi-exponential pharmacokinetic (PK) model that models the accumulation of insulin doses in the blood plasma of the subject.
  • PK pharmacokinetic
  • the blood glucose control system may modify its predictions based on the type of insulin, one or more blood glucose readings, and/or characteristics of the subject.
  • a subject may receive a manual bolus of insulin or medicament.
  • a user e.g., healthcare provider, parent, or guardian
  • the user or subject may inject a dose of insulin into the subject.
  • the user or subject may manually direct the automated blood glucose control system to provide a bolus of insulin to the subject.
  • the present disclosure relates to an automated blood glucose control system configured to provide automatic delivery of glucose control therapy to a subject and receive information about manual glucose control therapy provided to the subject. Using the received information about the manual glucose therapy, the automated blood glucose control system can adjust the blood glucose control algorithm to account for the manual dosing of insulin (or counter-therapy agents).
  • the manual glucose control therapy may be provided by injection therapy, or it may be provided by an insulin pump.
  • the automated blood glucose control system may receive an indication of insulin or medicament to administer to a subject in place of an automatically calculated dose of insulin.
  • the automated blood glucose control system 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 blood glucose control system 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 blood glucose control system. Moreover, the calculation may be based at least in part on a history of blood glucose level measurements for the subject when consuming particular meals. [0441]
  • 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. For example, the user may determine that for the size meal the subject is consuming or planning to consume, more or less insulin should be administered. In such cases, the user may modify the calculated insulin dosage to match the user’s determination of the amount of insulin to administer.
  • the automated blood glucose control system may modify its control algorithm based on the user’s input.
  • automated blood glucose control system can receive a meal announcement from a user responsive to the user interaction with the user interface.
  • the meal announcement can correspond to an indication of a size of a meal consumed or to be consumed by the subject as discussed herein.
  • the automated blood glucose control system can determine a meal bolus of insulin to administer to the subject based at least in part on the meal announcement.
  • the meal bolus of insulin can correspond to an amount of insulin to administer to the subject to compensate for a change in blood glucose attributable to the meal.
  • the automated blood glucose control system can output for display an indication of the meal bolus of insulin.
  • the automated blood glucose control system can receive an indication of a requested modification to the meal bolus of insulin from the user.
  • the automated blood glucose control system operate a control algorithm for automatic generation of an insulin dosing signal configured to operate the medicament pump to control blood glucose level in the subject based at least in part on a glucose level of the subject and the modification to the meal bolus of insulin.
  • 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, which may be considered a specified gesture interaction required for entry of the manual bolus of medicament.
  • a specified gesture interaction required for entry of the manual bolus of medicament may be a sliding action or other movement on a touchscreen to confirm or initiate desired functions as discussed herein.
  • the automated blood glucose control system 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. At the time of making the meal announcement, the user may have an option to enter the manual bolus.
  • the meal controller of the blood 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 blood glucose control system.
  • 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 blood glucose control system.
  • 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 blood glucose level reading, in advance of exercise, etc.), and any other information that may be useable by the blood glucose control system in controlling the blood glucose level of the subject.
  • a manual bolus e.g., via injection therapy
  • an amount of the manual bolus e.g., a type of the insulin (or other medicament)
  • providing manual dosing information to the automated blood glucose control system can help the blood glucose control system maintain the blood glucose level of the subject within a desired range when the automated features of the blood glucose control system are active or operational. For example, if the automated blood glucose control system determines from a CGM sensor reading that a subject’s blood glucose level is high, the automated blood glucose control system might normally administer a bolus of insulin. However, if the automated blood glucose control system receives an indication that a manual bolus of insulin was administered recently (e.g., within the past thirty minutes), the automated blood glucose control system may reduce or not administer a bolus of insulin, thereby preventing a hypoglycemic event and providing glycemic control.
  • the automated blood glucose control system may continue monitoring the blood glucose level of the subject and may administer additional insulin at a later time if the blood glucose level readings do not reflect an expected blood glucose level based on the reported manual bolus of insulin.
  • it may be unnecessary to receive an indication of the manual bolus because, for example, a user may cause the automated blood glucose control system to provide the manual bolus.
  • the automated blood glucose control system may track the amount of insulin delivered and the timing of the administering of the bolus.
  • the automated blood glucose control system may store the information associated with the manual bolus in a therapy log.
  • the automated blood glucose control system can access the therapy log to determine whether any manual bolus were administered and, if so, the timing and amount of the manual bolus.
  • the automated blood glucose control system 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. In some cases, the model may account for previously administered medicament by the automated blood glucose control system.
  • 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 value, body mass index value). Moreover, 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 blood glucose control system may model an accumulation of insulin, model time course of activity of insulin, or model a finite rate of utilization of insulin. [0448] Based on the model, the automated blood glucose control system may adjust the automated administering of insulin, or other medicament, when operating in an automatic mode to automatically generate an insulin dosing signal configured to operate the medicament pump to control blood glucose level.
  • an input parameter related to the subject’s weight e.g., body mass value, body mass index value
  • the model may account for perfusion over time of the medicament bolus from a subcutaneous infusion site into the blood plasma of the subject.
  • the automated blood glucose control system may model an accumulation of insulin, model time course of activity of insulin, or model a
  • the automated blood glucose control system 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, which can include a time course of activity of the medicament in the subject due to a finite rate of utilization of the medicament as discussed herein.
  • the automated blood glucose control system may confirm that the manual bolus was delivered to the subject. The confirmation may be determined based at least in part on whether blood glucose level readings by the CGM sensor match or are within a threshold level anticipated by the automated blood glucose control system based on the manual dosing information.
  • the automated blood glucose control system 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 blood glucose control system or of a device (e.g., laptop or smartphone, etc.) that communicates with the automated blood glucose control system.
  • 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 blood glucose control system may determine an amount of insulin the automated blood glucose control system would administer in an automatic operating mode based on the manual dosing information if the manual bolus had not been supplied. If the automated blood glucose control system determines it would have supplied a different quantity of the medicament, and if the difference exceeds a threshold, the automated blood glucose control system may adjust a blood glucose control algorithm to account for the difference. For example, the automated blood glucose control system may change the operating setpoint or range of insulin the automated blood glucose control system attempts to maintain in the subject. As another example, the automated blood glucose control system 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 blood glucose control system may maintain a therapy log of manual insulin therapy.
  • This therapy log may be maintained based on the use of the automated blood glucose control system 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 blood glucose control system is not operating, is not operating in an automatic mode, or is not connected to the subject.
  • the automated blood glucose control system 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 blood glucose control system.
  • the automated blood glucose 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 blood glucose control system is operating in a manual mode or an automatic mode by interacting with a user interface of the automated blood glucose control system or of a device that communicate with the automated blood glucose control system.
  • the user interaction may include any type of user interaction with a user interface.
  • the user interaction may include interaction why physical buttons or interactions with a touchscreen including gestures or taps on the touchscreen.
  • 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 blood-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 blood 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 blood-glucose level.
  • the method where the activity that may alter the blood- 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.
  • the method where the intensity and the duration of the exercise is compared to the recommended intensity and duration, and depending on whether it is the same, larger, or smaller than the recommended intensity and duration, the automated delivery system is able to determine the actions that are required to regulate the glucose level of the blood. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.
  • One general aspect includes 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 also includes automated delivery system configured to receive subjective information regarding the activity that may alter the blood-glucose level.
  • the system also includes a manual delivery component configured to receive an amount of the medicament to be infused.
  • the system also includes where the medical device storing a time and the amount of medicament that is infused into an automated delivery system that controls blood glucose levels.
  • 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.
  • an ambulatory medical device needs to provide options which allows the user to either manually request the amount of the desired medicament or choose an automated delivery system that automatically delivers the right amount of the medicament at the right time without further assistance.
  • the user may personally input the desired amount on a keypad that is provided by the medical device. The medical device further confirms and delivers the requested medicament.
  • the data is stored into a model predicative control component which is further used to control and regulate the blood glucose level.
  • a model predicative control component which is further used to control and regulate the blood glucose level.
  • the user decides to use the automated delivery system, the user must provide subjective information regarding the activity or the action that may alter the blood-glucose level. For example, if the blood-glucose level changing activity is consuming food, the user must provide the time and the dosage amount of the food that is going to be digested. This information is tied to 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 sugar 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 blood 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 be made aware of all 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 allows for a risk free or minimized transition from the manual delivery component and the automated delivery system. [0461] 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.
  • MPC algorithm Model Predictive Control
  • 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.
  • 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 is any medical device that a user 3604 may carry around and use with the approval of a medical professional. There are many different types of ambulatory medical devices 3602.
  • the ambulatory medical device 3602 is an insulin and/or glucagon infusion device for user 3604 that have 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 automated delivery mode is unable to determine the amount of medicament in the user’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 user’s blood stream.
  • 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 3602.
  • 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 all steps of the 3608 may be received or transmitted by the signal processing component 3603.
  • the user 3604 is 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 sugar 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 is one or more infusion pumps.
  • An infusion pump is 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 is an insulin infusion pump.
  • the therapy delivery component 3605 is an insulin and 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 is 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 ambulatory medical device 3602 is 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 is 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 FIGS. 23 and 43, a simple message of “Delivering” may be displayed during the therapy change delivery 3610. Alternatively, more exact details, such as “Delivering 2 units of insulin” or “Delivering insulin at 2 units per minute” may be displayed.
  • the ambulatory medical device 3602 plays a sound effect during the therapy change delivery 3610. In an exemplary embodiment that is shown in FIG.
  • 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. For example, 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. In another example.
  • the input components 3607 include a wake button 3620, a touchscreen display 3622, and an alphanumeric pad 3624.
  • the wake button 3620 is 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.
  • 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.
  • 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 in order to find all of their sought-after 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 whether the user is about to conduct activities that will change the blood 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 sugar or eat a meal that will increase their blood sugar.
  • the activity change component 3608 Upon receiving the activity change from the input components 3607, 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 as discussed herein, including via therapy logs.
  • 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 drug type insulin or glucagon; fast or slow acting
  • 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, for example, by determining a time course of activity of the medicament in the subject.
  • step 3710 the medical device provides an option to a user to select between receiving medicament using a manual delivery component or an automated delivery system. By using the mode controller 3613, the user can select the method for the therapy change request between manual delivery component and the automated delivery system.
  • step 3720 the medical device may receive subjective information regarding the activity or action that may alter the blood-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.
  • 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 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 needs to be administered.
  • 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 blood 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 be made aware of all manual medicament infusion amounts and the timing of such infusions, for example, in a therapy log as discussed herein. 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.
  • 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 minimized risk transition from the manual delivery component and the automated delivery system.
  • the user may inform the activity change component 3608 that the user is about to engage in activities that may alter the blood-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 3614 to proceed to block 3830 or the automated system 3612 to proceed to block 3850.
  • the mode controller 3613 may include a display of a manual bolus screen comprising a manual bolus control element and a bolus recommendation comprising the indication of the amount of the bolus of medicament generated by the control algorithm as discussed herein.
  • the ambulatory device 3602 may deliver the medicament to the user.
  • the activity change component 3608 may automatically adjust the insulin dose control signal based on the amount of the manual bolus of insulin.
  • the activity change component 3608 may generate a glucagon dose control signal based at least in part on the indication of the amount of the manual bolus of insulin.
  • the manual delivery component 3614 at block 3830 may inform at least one of the model predictive control component 3616 at block 3840 and the automated delivery system 3612 at block 3850 regarding the type of medicament, amount of medicament and the time when the medicament was delivery.
  • the predictive control component 3616 at block 3840 and automated delivery system 3612 at block 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, for example, in a therapy log as discussed herein.
  • 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.
  • the predictive control component 3616 may store the indication of the amount of the manual bolus of medicament supplied to the subject and an indication of a time when the manual bolus of medicament was supplied to the subject.
  • the predictive control component 3616 may model a diminishment of the medicament in the subject over time based at least in part on the manual bolus of medicament.
  • the predictive control component 3616 may model an accumulation of the manual bolus of the medicament in blood of the subject following subcutaneous infusion of the medicament.
  • Differences from other systems 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 the size of the meal was and learning how the insulin affects the user.
  • Embodiments may include correlating the manual inputs to asking the user what activity the user performed, learning how the glucagon affects the user for a particular activity, and/or storing the information in a therapy log to model a diminishment of the medicament in the subject over time based at least in part on the manual bolus of medicament.
  • 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. Once the screen 3910 is 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. Once the password screen 3920 is 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 official screen 3930 and meal doses official screen 3940 may be displayed.
  • 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 all 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 insulin pump.
  • 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.
  • 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, which can correspond to an indication of a size of a meal consumed or to be consumed by the subject.
  • 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 blood 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, which can correspond to an indication of a size of a meal consumed or to be consumed by the subject.
  • 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 blood glucose level.
  • the AMD can proceed to determine a meal bolus of insulin to administer to the subject based at least in part on the meal announcement as discussed herein.
  • the meal bolus of insulin can correspond to an amount of insulin to administer to the subject to compensate for a change in blood glucose attributable to the meal.
  • FIG. 43 illustrates a plurality of screens 4300 that may be produced by the ambulatory medical device 3602. Upon selecting the delivery request, 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.
  • the cancel button 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 blood glucose level. However, if the user decides to cancel the delivery, the delivery will be canceled and the screen 4320 will be provided.
  • FIG. 45 illustrates an example process 4500 for receiving input, via user interaction with a user interface, for manual glucose control therapy provided by a glucose control system.
  • An automated blood glucose control system can be configured to provide automatic delivery of glucose control therapy to a subject and to also provide manual glucose control therapy when requested by a user.
  • a control algorithm generates an indication of an amount of a bolus of medicament.
  • the control algorithm is configured to provide automatic control of blood glucose level in the subject and can automatically generate bolus amounts for correction doses and for meal doses based on at least one of an indicated glucose level of the subject, a meal announcement, an indicated meal size, control parameters selected manually or automatically by the control system, or any combination of the preceding values.
  • the bolus of medicament can correspond to a meal bolus of medicament or a correction bolus of medicament, and the amount of the bolus of medicament can be selected by the control algorithm based at least in part on preceding periods of glycemic control in the subject.
  • the glucose control system generates a display of a manual bolus screen that can include a manual bolus control element that can facilitate manual entry of an indication of a medicament bolus amount.
  • the indication of the medicament bolus amount can include a volume of medicament, an amount of carbohydrates in a meal, and/or other manual therapy instructions.
  • the manual bolus screen can include a bolus recommendation, which can include an indication of the amount of the bolus of medicament generated by the control algorithm.
  • the bolus recommendation can be for a correction dose or a meal dose, and can be in the form of a volume of medicament and/or, in the case of a meal dose, an estimated amount of carbohydrates consumed in a typical meal or a meal of the size selected by the user.
  • the meal dose can account for the time of the meal and the typical meal composition as indicated by preceding periods of glycemic response in prandial and post- prandial periods.
  • the glucose control system can receive, via user interaction with the manual bolus control element, the indication of an amount of a manual bolus of medicament.
  • the indication can include one or more than one indication entered manually via user interaction with one or more user interface control elements.
  • the glucose control system can store one or more of the following in a therapy log or another suitable location: at least one indication of an amount of a manual bolus of medicament, an amount of a manual bolus of medicament actually supplied to the subject, and/or an indication of a time when the manual bolus of medicament was supplied to the subject.
  • the glucose control system may use a model to determine the diminishment of medicament in the subject over time based at least in part on the manual bolus of medicament. Modeling the diminishment of medicament can account for a finite rate of utilization of the manual bolus of medicament and can use one of more models as described herein and in the Controller Disclosures.
  • the glucose control system can operate the control algorithm for automatic generation of an insulin dosing signal configured to operate a medicament pump to control blood glucose level in the subject based at least in part on a glucose level signal received from a glucose level sensor operatively connected to the subject and a time course of activity of the medicament in the subject due to a finite rate of utilization of the medicament.
  • the medicament in the subject can include the manual bolus of medicament and/or one or more automatically generated boluses of medicament.
  • 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”). In one embodiment, 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. [0498]
  • 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 computers 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.
  • 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.
  • Example Embodiments [0501] The following is a list of multiple sets of example numbered embodiments. The features recited in the below list of example embodiments can be combined with additional features disclosed herein. Further, each set of example numbered embodiments in the following list can be combined with one or more additional sets of example numbered embodiments from the following list. Furthermore, additional inventive combinations of features are disclosed herein, which are not specifically recited in the below list of example embodiments and which do not include the same features as the embodiments listed below.
  • a computer-implemented method of updating an application executing on an ambulatory medical device without interrupting therapy provided by the ambulatory medical device to a subject comprising: by a hardware processor of an ambulatory medical device, receiving an indication that an application update comprising an update to an application executing on the ambulatory medical device is available; establishing a communication connection to a host computing system configured to host the application update; downloading the application update from the host computing system; confirming that a downloaded copy of the application update is complete; confirming that the downloaded copy of the application update is not corrupted; determining an execution time of an installation process that installs the downloaded copy of the application update at the ambulatory medical device, wherein the execution time comprises an amount of time to perform the installation process; receiving a trigger to install the downloaded copy of the application update; responsive to
  • the computer-implemented method of Embodiment 1, wherein the communication connection is established over a cellular network that enables the ambulatory medical device to communicate directly with the host computing system over the cellular network.
  • the communication connection comprises a narrow band long-term evolution (NB-LTE) connection, an NB Internet-of-Things (NB-IoT) connection, a cellular IoT connection, a 4G LTE connection, or a 5G connection.
  • NB-LTE narrow band long-term evolution
  • NB-IoT NB Internet-of-Things
  • a cellular IoT connection a 4G LTE connection
  • 5G connection 5G connection.
  • the computer-implemented method of Embodiment 1, wherein the indication that the application update is available is received in response to an application update availability check triggered by the ambulatory medical device. 7.
  • the computer-implemented method of Embodiment 1, wherein the indication that the application update is available is transmitted to the ambulatory medical device without the ambulatory medical device performing an action to trigger transmission of the indication to the ambulatory medical device.
  • the next therapy delivery time is determined based at least in part on a therapy delivery schedule stored at the ambulatory medical device. 9.
  • determining that the installation process will complete prior to the next therapy delivery time comprises determining that the installation process will complete at least a threshold amount of time prior to the next therapy delivery time. 14.
  • determining that the downloaded copy of the application update is complete is based at least in part on one or more of a size of the downloaded copy of the application update, a tag, a checksum, or a hash.
  • determining that the downloaded copy of the application update is not corrupted is based at least in on a checksum or a hash. 16.
  • the indication that the application update is available comprises an indicator of whether the application update corresponds to the first application version or the second application version.
  • the first feature set comprises a subset of the second feature set or a partially overlapping set of features with the second feature set. 19.
  • the computer-implemented method of Embodiment 16 further comprising determining an application version of the application, wherein downloading the application update comprises downloading one of the first application update or the second application update based at least in part on the application version of the application.
  • the host computing system comprises a server computing device, a cloud computing device, a local computing device, a computing device of the subject, a computing device of a healthcare provider, a computing device of a manufacturer of the ambulatory medical device, a smartphone, or an application server.
  • the computer-implemented method of Embodiment 1, wherein the ambulatory medical device comprises a mono-hormonal medicament pump or a bi-hormonal medicament pump. 22.
  • a computer-implemented method of updating an application executing on an ambulatory medical device without interrupting therapy provided by the ambulatory medical device to a subject comprising: by a hardware processor of an ambulatory medical device, receiving an indication that an application update comprising an update to an application executing on the ambulatory medical device is available; establishing a direct end-to-end data connection to a host computing system configured to host the application update, wherein the direct end-to-end data connection is established via a wireless wide area network; downloading the application update from the host computing system over the direct end-to-end data connection; confirming that a downloaded copy of the application update is complete; confirming that the downloaded copy of the application update is not corrupted; receiving a trigger to install the downloaded copy of the application
  • the direct end- to-end data connection comprises a narrow band long-term evolution (NB-LTE) connection, an NB Internet-of-Things (NB-IoT) connection, a cellular IoT connection, a 4G LTE connection, or a 5G connection.
  • NB-LTE narrow band long-term evolution
  • NB-IoT NB Internet-of-Things
  • cellular IoT a 4G LTE connection
  • 4G LTE connection 4G LTE connection
  • 5G connection 5G connection.
  • the application comprises one of a first application version comprising a first feature set or a second application version comprising a second feature set
  • downloading the application update comprises downloading one of a first application update corresponding to the first application version or a second application update corresponding to the second application version.
  • a computer-implemented method of updating an application executing on an ambulatory medical device without interrupting therapy provided by the ambulatory medical device to a subject comprising: by a hardware processor of an ambulatory medical device, receiving an indication that an application update comprising an update to an application executing on the ambulatory medical device is available; downloading the application update from a host computing system; confirming that a downloaded copy of the application update is complete; confirming that the downloaded copy of the application update is not corrupted; receiving a trigger to install the downloaded copy of the application update; and responsive to the trigger, initiating an installation process of the downloaded copy of the application update without interrupting therapy provided by the ambulatory medical device to the subject.
  • An ambulatory medical device configured to provide therapy to a subject and including an application capable of being updated without interrupting the therapy, the ambulatory medical device comprising: a memory configured to store specific computer-executable instructions and an application that, at least in part, controls the therapy provided to the subject; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: receive an indication that an application update comprising an update to the application executing on the ambulatory medical device is available; download the application update from a host computing system; confirm that a downloaded copy of the application update is complete; confirm that the downloaded copy of the application update is not corrupted; receive a trigger to install the downloaded copy of the application update; and responsive, at least in part, to the trigger, initiate an installation process of the downloaded copy of the application update without interrupting the therapy provided to the subject.
  • the ambulatory medical device of Embodiment 27 further comprising a wireless transceiver that enables the ambulatory medical device to establish a network connection with the host computing system over a wide area network (WAN).
  • WAN wide area network
  • 29. The ambulatory medical device of Embodiment 27, further comprising a medicament delivery interface configured to operatively connect to a medicament pump configured to infuse medicament into the subject, the medicament pump comprising a mono- hormonal medicament pump or a bi-hormonal medicament pump.
  • An ambulatory medicament device configured to generate a dose control signal for delivery of medicament to a subject and configured to secure at least some functionality of a user interface of the ambulatory medicament device, the ambulatory medicament device comprising: a medicament delivery interface configured to operatively connect to a medicament pump for infusing medicament into the subject; a display interface configured to output display signals configured to generate user interface screens on a display device; a memory configured to store specific computer-executable instructions, a user- generated passcode that is selected by a user during a passcode-setting process, and an override passcode that is not selected by the user; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: generate the dose control signal using a control algorithm employing control parameters, wherein at least one control parameter of the control parameters can be modified by a user interaction with a parameter control element displayed via at least one user interface screen of the user interface screens, wherein the ambulatory medicament device does not permit modification of the at least one control parameter via the parameter control element
  • ambulatory medicament device of Embodiment 1 wherein ambulatory medicament device comprises an insulin pump or a bi-hormonal pump capable of administering insulin and a counter-regulatory agent. 3. The ambulatory medicament device of Embodiment 1, wherein access to at least some functionality of the user interface is permitted without validating the security code. 4. The ambulatory medicament device of Embodiment 1, wherein the security code comprises at least one of a numeric code, an alphanumeric code, a shape, an answer to a question, a gesture interaction with a touch-sensitive surface, or a biometric identifier. 5. The ambulatory medicament device of Embodiment 1, wherein the parameter control element comprises an element displayed on a touchscreen display. 6.
  • the ambulatory medicament device of Embodiment 1 wherein the user input element comprises a touch-sensitive surface comprising one or more visual indicia. 7. The ambulatory medicament device of Embodiment 1, wherein the override passcode changes at periodic intervals. 8. The ambulatory medicament device of Embodiment 1, wherein at least some information associated with therapy delivery is accessible to the user in the locked state. 9. The ambulatory medicament device of Embodiment 8, wherein the passcode display comprises a graph of glucose level of the subject over time. 10.
  • the ambulatory medicament device of Embodiment 1 wherein the hardware processor is configured to execute the specific computer-executable instructions to: validate an advanced settings security code to confirm that the user is authorized to modify advanced settings of the ambulatory medicament device by confirming that the advanced settings security code matches an advanced settings passcode; and in response to validating the advanced settings security code, cause the ambulatory medicament device to enter an advanced settings state, wherein the ambulatory medicament device permits modification of at least one advanced control parameter via an advanced parameter control element when the ambulatory medicament device is in the advanced settings state.
  • the advanced settings passcode expires after a predetermined period. 12.
  • the ambulatory medicament device of Embodiment 10 wherein the advanced settings passcode expires at least once per week. 13.
  • the ambulatory medicament device of Embodiment 10, wherein the advanced settings passcode comprises a gesture interaction with a touchscreen display.
  • the ambulatory medicament device of Embodiment 1, wherein the override passcode is fixed during a manufacturing process.
  • the ambulatory medicament device of Embodiment 1, wherein the override passcode is valid for at least some other ambulatory medicament devices.
  • a new override passcode is generated algorithmically. 17.
  • An ambulatory medicament device configured to generate a dose control signal for delivery of medicament to a subject and configured to secure at least some functionality of a user interface of the ambulatory medicament device, the ambulatory medicament device comprising: a medicament delivery interface configured to operatively connect to a medicament pump for infusing medicament into the subject; a memory configured to store specific computer-executable instructions, a user- generated passcode that is selected by a user during a passcode-setting process, and an override passcode that is not selected by the user; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: generate the dose control signal using a control algorithm employing control parameters, wherein at least one control parameter of the control parameters can be modified by a user interaction with a parameter control element, wherein the ambulatory medicament device does
  • ambulatory medicament device of Embodiment 18 wherein ambulatory medicament device comprises an insulin pump or a bi-hormonal pump capable of administering insulin and a counter-regulatory agent.
  • the parameter control element is accessed via the computing system over the direct end-to-end connection.
  • 21. The ambulatory medicament device of Embodiment 18, wherein the direct end- to-end connection is established over a wide area network.
  • 22. The ambulatory medicament device of Embodiment 18, wherein access to at least some functionality of the user interface is permitted without validating the security code. 23.
  • the override passcode changes at periodic intervals.
  • the override passcode is fixed during a manufacturing process.
  • the override passcode is valid for at least some other ambulatory medicament devices.
  • An ambulatory medical device configured to provide therapy to a subject and to share therapy data related to the therapy with a networked computing environment
  • the ambulatory medical device comprising: a memory configured to store specific computer-executable instructions; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: identify a computing system of a networked computing environment based on a whitelist of one or more approved computing systems, wherein the whitelist is stored in the memory of the ambulatory medical device; obtain an address of the computing system from the whitelist; 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; receive a public key from the computing system of the networked computing environment, wherein the public key permits the ambulatory medical device to encrypt data communications transmitted by the ambulatory medical device to the computing system; encrypt therapy data related to therapy delivered by the ambulatory medical device to the subject to obtain encrypted therapy data; and transmit the encrypted therapy data to the
  • the ambulatory medical device of Embodiment 1, wherein the address of the computing system comprises a network address of the computing system.
  • IP Internet Protocol
  • URL Uniform Resource Locator
  • URI Uniform Resource Identifier
  • UPN Uniform Resource Name
  • the ambulatory medical device of Embodiment 1 wherein the address of the computing system comprises a network address of the networked computing environment that includes the computing system.
  • the whitelist comprises access information useable by the ambulatory medical device to access the computing system. 6.
  • the transceiver is configured to support communication over one or more communication standards comprising: a low power wide area network (LPWAN) communication standard, a Narrowband Long- Term Evolution (NB-LTE) standard, a Narrowband Internet-of-Things (NB-IoT) standard, or a Long-Term Evolution Machine Type Communication (LTE-MTC) standard.
  • 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 ambulatory medical device of Embodiment 1 wherein the hardware processor is further configured to establish the direct end-to-end data connection to the computing system of the networked computing environment by transmitting a connection request to the computing system, the connection request comprising a device identifier of the ambulatory medical device.
  • the device identifier comprises or is generated based at least in part on an Internet Protocol (IP) address, a Media Access Control (MAC) address, a serial number, or a subject identifier.
  • the ambulatory medical device of Embodiment 1 wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least generate a shared secret based at least in part on the public key and a private key stored at the ambulatory medical device, and wherein encrypting the therapy data comprises using the shared secret to encrypt the therapy data.
  • the ambulatory medical device of Embodiment 1 wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least: obtain additional therapy data related to therapy delivered by the ambulatory medical device to the subject, wherein the additional therapy data is obtained at a different time period than the therapy data; encrypt the additional therapy data to obtain additional encrypted therapy data; and transmit the additional encrypted therapy data to the computing system over the direct end-to-end data connection.
  • the additional therapy data is obtained on an intermittent basis, a periodic basis, a scheduled basis, or on a continuous basis for at least a time period. 14.
  • the ambulatory medical device of Embodiment 1 wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least: receive an alert from the computing system of the networked computing environment; and output an indication of the alert on a display of the ambulatory medical device. 15. The ambulatory medical device of Embodiment 14, wherein the alert is received in response to the encrypted therapy data transmitted to the computing system. 16. The ambulatory medical device of Embodiment 14, wherein the alert is generated based on physiological measurements of the subject obtained from one or more sensors of the ambulatory medical device. 17.
  • the ambulatory medical device of Embodiment 1 further comprising a glucose level sensor operatively connected to the subject and configured to obtain a glucose level signal, wherein the hardware processor is further configured to execute the specific computer- executable instructions to at least determine a glucose level of the subject based at least in part on the glucose level signal.
  • the therapy data comprises the glucose level of the subject.
  • the therapy data comprises at least one of dose data or subject data, wherein the dose data corresponds to one or more doses of medicament provided by the ambulatory medical device to the subject, and wherein the subject data corresponds to a medical or physiological state of the subject as determined by the ambulatory medical device. 20.
  • the ambulatory medical device of Embodiment 1 wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least transmit status information of the ambulatory medical device to the computing system.
  • the status information comprises one or more of operation data or error data, wherein the operation data corresponds to operation of the ambulatory medical device, and wherein the error data corresponds to an error in operation of the ambulatory medical device.
  • the ambulatory medical device of Embodiment 1 wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least: receive an account identifier associated with a user authorized to access data associated with the subject at the networked computing environment; and transmit the account identifier to the computing system.
  • the hardware processor is further configured to execute the specific computer-executable instructions to at least transmit a set of permissions associated with the account identifier, the set of permissions authorizing the user to access the data associated with the subject at the networked computing environment. 25.
  • a computer-implemented method of sharing, with a networked computing environment, therapy data related to therapy provided by an ambulatory medical device to a subject comprising: by a hardware processor of the ambulatory medical device, obtaining a network address of a computing system of the networked computing environment based on a whitelist of one or more approved computing systems, wherein the whitelist is stored in a memory of the ambulatory medical device; establishing, using the network address, a direct end-to-end data connection to the computing system of the networked computing environment via a wireless wide area network; receiving a public key from the computing system of the networked computing environment; accessing a private key stored on a memory of the ambulatory medical device; generating a shared secret based at least in part on the public key and the private key; encrypting, using the shared secret, therapy data related to the therapy delivered by the ambulatory medical device to the subject to obtain encrypted therapy data; and transmitting the encrypted therapy data to the computing system over the direct end-
  • establishing the direct end-to-end data connection comprises communicating with the computing system via the wireless wide area network using one or more communication standards comprising: a low power wide area network (LPWAN) communication standard, a Narrowband Long-Term Evolution (NB-LTE) standard, a Narrowband Internet-of-Things (NB-IoT) standard, or a Long-Term Evolution Machine Type Communication (LTE-MTC) standard.
  • 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
  • Embodiment 25 further comprising: receiving, responsive at least in part to the encrypted therapy data transmitted to the computing system, an alert from the computing system of the networked computing environment; and outputting an indication of the alert on a display.
  • An ambulatory medicament device configured to generate a dose control signal for delivery of medicament into a subject and to cancel a modification of medicament delivery initiated by a user
  • the ambulatory medicament device comprising: a medicament delivery interface configured to operatively connect to a medicament pump configured to infuse medicament into the subject in response to receiving the dose control signal; a touchscreen controller configured to output display signals configured to generate user interface screens on a touchscreen and to receive user input signals corresponding to user interaction with the touchscreen; a memory configured to store specific computer-executable instructions; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: generate a display of a therapy control element on the touchscreen, wherein the therapy control element permits a user to modify a control parameter having a first setting used in a control algorithm for generating a dose control signal; receive an indication of a modification to the therapy control element; in response to receiving the indication, modify at a first time the control parameter from a first setting to a second setting based on the indication of the modification to the
  • the ambulatory medicament device of Embodiment 1 wherein the swipe gesture is performed at least in part in a region of the touchscreen occupied by the therapy control element. 3. The ambulatory medicament device of Embodiment 1, wherein the swipe gesture is 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. 4. The ambulatory medicament device of Embodiment 1, wherein the restore gesture is received on a user interface screen that presents the therapy control element. 5. The ambulatory medicament device of Embodiment 1, wherein the restore gesture is received on a different user interface screen than a user interface screen that presents the therapy control element. 6.
  • the ambulatory medicament device of Embodiment 1 wherein the restore gesture is performed in an opposite direction from a therapy change confirmation gesture that confirms the modification to the therapy control element. 7.
  • the first setting comprises a default setting or a designated restore setting.
  • the ambulatory medicament device of Embodiment 1, wherein the first setting comprises a setting immediately preceding the second setting. 13.
  • a computer-implemented method of cancelling a modification of a control parameter associated with medicament delivery initiated by a user comprising: by a hardware processor configured to generate a dose control signal for delivery of medicament by a medicament pump into a subject, generating a display of a therapy control element on a touchscreen configured to display one or more user interface screens, wherein the therapy control element permits a user to modify a control parameter having a first setting used in a control algorithm for generating the dose control signal; receiving an indication of a modification to the therapy control element; in response to receiving the indication, modifying at a first time the control parameter from a first setting to a second setting based at least in part on the indication of the modification to the therapy control element; receiving a restore gesture on the touchscreen at a second time, wherein the restore gesture indicates that the control parameter is to be restored to the first setting, and wherein the restore gesture comprises a
  • the computer-implemented method of Embodiment 14 wherein the swipe gesture is performed at least in part in a region of the touchscreen occupied by at least a portion of the therapy control element. 16. The computer-implemented method of Embodiment 14, wherein the swipe gesture is 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. 17. The computer-implemented method of Embodiment 14, wherein the restore gesture is received on a user interface screen that presents the therapy control element. 18. The computer-implemented method of Embodiment 14, wherein the restore gesture is received on a different user interface screen than a user interface screen that presents the therapy control element. 19.
  • the computer-implemented method of Embodiment 14 wherein the restore gesture is performed in an opposite direction from a therapy change confirmation gesture that confirms the modification to the therapy control element.
  • 20 The computer-implemented method of Embodiment 14, wherein the second time is later than the first time.
  • the first setting comprises a default setting or a designated restore setting.
  • the first setting comprises a setting immediately preceding the second setting.
  • the first setting comprises a default setting or a designated restore setting.
  • a computer-implemented method of switching an application executing on an ambulatory medical device without interrupting therapy provided by the ambulatory medical device to a subject comprising: by a hardware processor of an ambulatory medical device, receiving an indication that an application update comprising an update to a first application executing on the ambulatory medical device is available; establishing a communication connection to a host computing system configured to host the application update; downloading a second application from the host computing system, wherein the second application is a version of the first application that includes the application update; installing the second application while maintaining execution of the first application on the ambulatory medical device; confirming successful installation of the second application on the ambulatory medical device; receiving a trigger to execute the second application in place of the first application; responsive to the trigger, determining a next therapy delivery time associated with delivering therapy by the ambulatory medical device to a subject; and responsive to determining that an amount of time until the next therapy delivery time satisfies a threshold time period, switching application control by initiating execution of the second
  • the computer-implemented method of Embodiment 1 wherein the communication connection is established over a cellular network that enables the ambulatory medical device to communicate directly with the host computing system over the cellular network.
  • the application update comprises a new version of the application, a patch to the application, or a replacement application for the application.
  • installing the second application comprises installing the second application in a separate memory space of a nonvolatile memory that is separate from the installation of the first application. 5.
  • the computer-implemented method of Embodiment 1 wherein, responsive to determining that the amount of time until the next therapy delivery time satisfies the threshold time period, the computer-implemented method further comprises switching control of at least one feature of the ambulatory medical device from the first application to the second application. 6.
  • the computer-implemented method of Embodiment 9, wherein the first execution space and the second execution space comprise separate areas of volatile memory.
  • the first feature set comprises a subset of the second feature set or a partially overlapping set of features with the second feature set.
  • the ambulatory medical device comprises a mono-hormonal medicament pump or a bi-hormonal medicament pump. 18.
  • a computer-implemented method of maintaining therapy provided to a subject by an ambulatory medical device during an occurrence of an application-fault of an application executing on the ambulatory medical device comprising: by a hardware processor of an ambulatory medical device, detecting an application-fault associated with a first application executing on the ambulatory medical device, wherein the first application is configured to control therapy provided by the ambulatory medical device; and responsive to detecting the application-fault, initiating execution of a second application on the ambulatory medical device, wherein the second application is configured to control therapy provide by the ambulatory medical device, and wherein the second application comprises an older version of the first application; and switching control of the ambulatory medical device from the first application to the second application. 19.
  • the second application is stored in a portion of memory of the ambulatory medical device that is designated for storing a safe copy of a control application that controls the ambulatory medical device. 24.
  • a computer-implemented method of switching a control application controlling an ambulatory medical device without interrupting therapy provided by the ambulatory medical device to a subject comprising: by a hardware processor of an ambulatory medical device, detecting a trigger associated with a first application executing on the ambulatory medical device, wherein the first application is a control application configured to control therapy provided by the ambulatory medical device; and responsive to detecting the trigger, initiating execution of a second application on the ambulatory medical device, wherein the second application is configured to control therapy provide by the ambulatory medical device, and wherein the second application comprises a different version of the control application than the first application; and switching control of the ambulatory medical device from the first application to the second application. 25.
  • An ambulatory medical device configured to provide therapy to a subject and capable of switching control applications without interrupting the therapy, the ambulatory medical device comprising: a memory configured to store specific computer-executable instructions and a first application that is configured to, at least in part, control the therapy provided to the subject; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: execute the first application to control, at least in part, the therapy provided to the subject; detect a trigger associated with the first application; and responsive to detecting the trigger, the hardware processor is further configured to execute the specific computer-executable instructions to at least: access a second application that is configured to, at least in part, control the therapy provided to the subject; initiate execution of the second application while maintaining execution of the first application on the ambulatory medical device; determine a next therapy delivery time associated with delivering therapy to the subject; and responsive to determining that an amount of time until the next therapy delivery time satisfies a threshold time period, switch control of the therapy from the first application to the second application
  • the trigger comprises an indication of an availability of the second application at a host computing system or a detection of an application fault associated with execution of the first application.
  • the hardware processor is further configured to access the second application by executing the specific computer-executable instructions to at least: establish an end-to-end data connection over a network to a host computing system configured to host the second application; download the second application to the memory; confirm successful download of the second application; and install the second application.
  • the second application comprises an updated version of the first application or a version of the first application that has been determined to operate without fault with a threshold degree of certainty.
  • a computer-implemented method of updating an application executing on an ambulatory medical device without interrupting therapy provided by the ambulatory medical device to a subject comprising: by a hardware processor of an ambulatory medical device, receiving an indication that an application update comprising an update to a first application executing on the ambulatory medical device is available; establishing a communication connection to a host computing system configured to host a second application comprising the application update; downloading the second application from the host computing system to obtain a downloaded copy of the second application; initiating an installation process of the downloaded copy of the second application without interrupting therapy provided by the ambulatory medical device to the subject; executing the second application while the first application continues to execute; determining that a minimum set of operating conditions are satisfied, wherein the minimum set of operating conditions relate to maintaining therapy provided by the ambulatory medical device to the subject; and responsive to determining that the minimum set of operating conditions are satisfied, switching control of
  • determining that the minimum set of operating conditions are satisfied comprises determining that the ambulatory medical device is not currently administering a medicament. 3.
  • determining that the minimum set of operating conditions are satisfied comprises determining that the ambulatory medical device has less than a threshold probability of administering a medicament within a threshold period of time. 4.
  • determining that the minimum set of operating conditions are satisfied comprises determining that the ambulatory medical device has administered a medicament within a threshold period of time. 5.
  • the computer-implemented method of Embodiment 1, wherein the installation process comprises installing the second application in a separate memory space of a memory of the ambulatory medical device than a location of the first application within the memory. 6.
  • switching control of the ambulatory medical device from the first application to the second application comprises: generating a dose control signal using the second application, wherein the second application autonomously determines doses of a medicament to be infused into the subject for controlling blood glucose of the subject based at least in part on a glucose level signal obtained from a sensor; and providing the dose control signal generated using the second application to a medicament delivery interface configured to operatively connect to a medicament pump for infusing the medicament into the subject while not providing a second dose control signal generated using the first application.
  • the computer-implemented method of Embodiment 1, wherein the communication connection is established over a cellular network that enables the ambulatory medical device to communicate directly with the host computing system over the cellular network.
  • the communication connection comprises a narrow band long-term evolution (NB-LTE) connection, an NB Internet-of-Things (NB-IoT) connection, a cellular IoT connection, a 4G LTE connection, or a 5G connection.
  • NB-LTE narrow band long-term evolution
  • NB-IoT NB Internet-of-Things
  • a cellular IoT connection a 4G LTE connection
  • 5G connection a 5G connection.
  • the computer-implemented method of Embodiment 1, wherein the update to the first application comprises a new version of the first application, a patch to the application, or additional features for the first application.
  • the computer-implemented method of Embodiment 1, wherein executing the second application while the first application continues to execute comprises executing the second application using a separate processor than a processor executing the first application.
  • the computer-implemented method of Embodiment 1, wherein executing the second application while the first application continues to execute comprises executing the second application in a separate execution space than an execution space used to execute the first application.
  • the computer-implemented method of Embodiment 1, wherein the first application is executed by a first controller and the second application is executed by a second controller. 14.
  • the computer-implemented method of Embodiment 14 wherein the first feature set and the second feature set differ, and wherein the first feature set includes at least one feature included in the second feature set.
  • the ambulatory medical device comprises a mono-hormonal medicament pump or a bi-hormonal medicament pump. 17.
  • An ambulatory medical device configured to provide therapy to a subject and capable of switching control applications without interrupting the therapy, the ambulatory medical device comprising: a memory configured to store specific computer-executable instructions and a first application that is configured to, at least in part, control the therapy provided to the subject; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: execute the first application to control, at least in part, the therapy provided to the subject; establish a communication connection to a host computing system configured to host a second application that is configured to, at least in part, control the therapy provided to the subject when executed by the hardware processor; download the second application from the host computing system to obtain a downloaded copy of the second application; initiate an installation process of the downloaded copy of the second application without interrupting therapy provided by the ambulatory medical device to the subject; execute the second application without altering execution of the first application; determine that a minimum set of operating conditions are satisfied, wherein the minimum set of operating conditions relate to maintaining therapy provided by the ambulatory medical device to the subject
  • the trigger comprises one or more of: an indication that the second application is available; a detection of a fault with the first application, or an indication of a change in permitted features.
  • the hardware processor is configured to determine that the minimum set of operating conditions are satisfied by at least determining that the ambulatory medical device is not currently administering a medicament. 21.
  • a transceiver configured to establish the communication connection to the host computing system over a wide area network.
  • the first medicament pump comprises a mono-hormonal medicament pump or a bi-hormonal medicament pump.
  • An ambulatory medicament device configured to generate a dose control signal for delivery of medicament into a subject, the ambulatory medicament device comprising: a monitoring system interface configured to receive status information, wherein the status information comprises at least one of device information pertaining to a condition of the ambulatory medicament device or subject information pertaining to a condition of the subject; a medicament delivery interface configured to operatively connect to a medicament pump configured to infuse medicament into the subject in response to receiving the dose control signal; a touchscreen controller configured to output display signals configured to generate user interface screens on a touchscreen and to receive user input signals corresponding to user interaction with the touchscreen; a memory configured to store specific computer-executable instructions; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: receive the status information via the monitoring system interface; determine that the status information satisfies an alarm condition for the ambulatory medicament device or for the subject; and in response to a
  • the hardware processor is further configured to execute the specific computer-executable instructions to at least permit access to a therapy control element of the ambulatory medicament device, wherein the therapy control element permits a user to modify a control parameter used in a control algorithm for generating the dose control signal.
  • the ambulatory medicament device of Embodiment 2 wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least: receive an indication of a modification to the therapy control element; and in response to receiving the indication, modify the control parameter based on the indication to obtain a modified control parameter; generate the dose control signal based at least in part on the modified control parameter; and provide, via the medicament delivery interface, the dose control signal to the medicament pump.
  • the wake interface element comprises a motion sensor, and wherein the wake interaction comprises movement of the ambulatory medicament device.
  • the motion sensor comprises an accelerometer. 6.
  • the ambulatory medicament device of Embodiment 4 wherein the movement of the ambulatory medicament device corresponds to a particular motion. 7.
  • the wake interface element comprises a physical button, a capacitive element, or an inductive element.
  • the wake interaction further comprises receiving a biometric input. 10.
  • the ambulatory medicament device of Embodiment 1 wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least: determine a severity level of the alarm condition; and select the one or more alarm status indicators to display on the touchscreen lock screen interface based at least in part on the severity level of the alarm condition.
  • the ambulatory medicament device comprises an insulin pump.
  • the ambulatory medicament device comprises a bi-hormonal pump capable of administering insulin and a counter-regulatory agent.
  • the hardware processor is further configured to execute the specific computer-executable instructions to at least: receive additional status information via the monitoring system interface; determine that the additional status information satisfies the alarm condition for the ambulatory medicament device or for the subject; and modify the display of the one or more alarm status indicators based on the additional status information satisfying the alarm condition. 15.
  • the ambulatory medicament device of Embodiment 1 wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least: receive additional status information at a point in time subsequent to receiving the status information via the monitoring system interface; determine that the additional status information does not satisfy the alarm condition for the ambulatory medicament device or for the subject; and cease the display on the touchscreen lock screen interface of the one or more alarm status indicators corresponding to the alarm condition. 16.
  • the ambulatory medicament device of Embodiment 1 wherein the status information is received from a sensor that measures at least one of a characteristic of the ambulatory medicament device or a physiological parameter of the subject. 18.
  • the hardware processor is further configured to execute the specific computer-executable instructions to at least: receive additional status information via the monitoring system interface; determine that the additional status information satisfies a second alarm condition for the ambulatory medicament device or for the subject; and display on the touchscreen lock screen interface an additional alarm status indicator corresponding to the second alarm condition. 19.
  • a computer-implemented method of displaying an alarm status indicator corresponding to an alarm condition of a subject or of an ambulatory medicament device configured to generate a dose control signal configured to cause a medicament pump to infuse medicament into the subject comprising: by a hardware processor configured to generate the dose control signal configured to cause the medicament pump to infuse medicament into the subject, receiving status information comprising at least one of device information pertaining to a condition of the ambulatory medicament device or subject information pertaining to a condition of the subject; determining that the status information satisfies an alarm condition for the ambulatory medicament device or for the subject; receiving an indication of a wake interaction with a wake interface element of the ambulatory medicament device when the ambulatory medicament device is in a sleep state, and in response to the wake interaction with the wake interface element, generating a display of a touchscreen lock screen interface; and displaying on the touchscreen lock screen interface the alarm status indicator corresponding to the alarm condition, wherein the alarm status indicator is displayed at least while the ambulatory medicament device remains
  • the computer-implemented method of Embodiment 22 further comprising: receiving an indication of a modification to the therapy control element; and in response to receiving the indication, modifying the control parameter based on the indication to obtain a modified control parameter; generating the dose control signal based at least in part on the modified control parameter; and providing the dose control signal to the medicament pump.
  • the wake interaction comprises a movement of the ambulatory medicament device in a particular motion indicative of a user moving the ambulatory medicament device within a line of sight of the user. 25.
  • the computer-implemented method of Embodiment 20 further comprising: determining a severity level of the alarm condition; and selecting the alarm status indicator to display on the touchscreen lock screen interface based at least in part on the severity level of the alarm condition.
  • the computer-implemented method of Embodiment 20 further comprising: receiving additional status information; determining that the additional status information satisfies the alarm condition for the ambulatory medicament device or for the subject; and modifying the display of the alarm status indicator based on the additional status information satisfying the alarm condition.
  • the computer-implemented method of Embodiment 20 further comprising: receiving additional status information at a point in time subsequent to receiving the status information; determining that the additional status information does not satisfy the alarm condition for the ambulatory medicament device or for the subject; and ceasing the display on the touchscreen lock screen interface of the alarm status indicator corresponding to the alarm condition.
  • determining that the additional status information does not satisfy the alarm condition comprises determining based at least in part on the additional status information that the alarm condition has been resolved.
  • the computer-implemented method of Embodiment 20 further comprising: receiving additional status information; determining that the additional status information satisfies a second alarm condition for the ambulatory medicament device or for the subject; and displaying on the touchscreen lock screen interface an additional alarm status indicator corresponding to the second alarm condition.
  • the computer-implemented method of Embodiment 20 further comprising: receiving additional status information; determining that the additional status information satisfies a second alarm condition for the ambulatory medicament device or for the subject; and modifying the display of the alarm status indicator based on the additional status information satisfying the second alarm condition.
  • An ambulatory medicament device configured to generate a dose control signal configured to cause a medicament pump to infuse medicament into a subject
  • the ambulatory medicament device comprising: a monitoring system interface configured to receive status information, wherein the status information comprises at least one of device information pertaining to a condition of the ambulatory medicament device or subject information pertaining to a condition of the subject; a memory configured to store specific computer-executable instructions and a list of pending alarm conditions; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: receive a first status information via the monitoring system interface; in response to determining that the first status information satisfies an alarm condition for the ambulatory medicament device or for the subject, and determining that the alarm condition is not already present in the list of pending alarm conditions, modify the list of pending alarm conditions based on the alarm condition; determine a severity level of the alarm condition, wherein the severity level is one of a plurality of severity levels; annunciate the alarm condition using one or more an
  • the ambulatory medicament device of Embodiment 1 wherein the ambulatory medicament device comprises an insulin pump. 3. The ambulatory medicament device of Embodiment 1, wherein the ambulatory medicament device comprises a bi-hormonal pump capable of administering insulin and a counter-regulatory agent. 4. The ambulatory medicament device of Embodiment 1, wherein the one or more annunciation patterns are selected from a plurality of annunciation patterns, and wherein at least one severity level of the plurality of severity levels is associated with a unique annunciation pattern of the plurality of annunciation patterns. 5. The ambulatory medicament device of Embodiment 1, wherein the list of pending alarm conditions is sorted according to severity levels of alarm conditions included on the list of pending alarm conditions. 6.
  • the ambulatory medicament device of Embodiment 1 wherein the list of pending alarm conditions is displayed on a user interface of the ambulatory medicament device. 7.
  • the ambulatory medicament device of Embodiment 8 wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least transmit the list of pending alarm conditions via the wireless electronic communications interface to the remote electronic device. 10.
  • the ambulatory medicament device of Embodiment 1 wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least: receive a second status information via the monitoring system interface; and in response to determining that the second status information satisfies the alarm condition for the ambulatory medicament device or for the subject, and determining that the indication of the alarm condition is already present in the list of pending alarm conditions, modify the one or more annunciation patterns used to announce the alarm condition.
  • the first status information is received from a sensor that measures at least one of a characteristic of the ambulatory medicament device or a health-related characteristic of the subject.
  • the ambulatory medicament device of Embodiment 1 wherein, in response to determining that the first status information satisfies the alarm condition for the ambulatory medicament device or for the subject, the hardware processor is further configured to execute the specific computer-executable instructions to at least contact at least one of a healthcare provider or a manufacturer of the ambulatory medicament device. 14. The ambulatory medicament device of Embodiment 1, wherein, when the first status information indicates that a quantity of available medicament is at or below a quantity threshold, the hardware processor is further configured to execute the specific computer- executable instructions to at least order additional medicament without user involvement. 15.
  • the ambulatory medicament device of Embodiment 1 wherein in response to determining that the first status information satisfies the alarm condition for the ambulatory medicament device, the hardware processor is further configured to execute the specific computer-executable instructions to at least cause repair instructions to be output for display on a user interface.
  • the one or more annunciation patterns comprise at least one of text information corresponding to the alarm condition, an audible alarm, a visual alarm, or a haptic alarm. 17.
  • the ambulatory medicament device of Embodiment 1 wherein, in response to determining that the first status information satisfies the alarm condition, and determining that the indication of the alarm condition is present in the list of pending alarm conditions, the hardware processor is further configured to execute the specific computer-executable instructions to at least: modify the severity level of the alarm condition from a first severity level of the plurality of severity levels to a second severity level from the plurality of severity levels, and modify the one or more annunciation patterns of the alarm condition based on the severity level of the alarm condition. 18.
  • the ambulatory medicament device of Embodiment 1 wherein, in response to determining that the severity level of the alarm condition matches an unsafe operation severity level, the hardware processor is further configured to execute the specific computer-executable instructions to at least suspend delivery of the medicament to the subject. 19. The ambulatory medicament device of Embodiment 1, wherein, in response to determining that the severity level of the alarm condition matches a safe operation severity level, the hardware processor is further configured to execute the specific computer-executable instructions to at least maintain delivery of the medicament to the subject. 20. The ambulatory medicament device of Embodiment 1, wherein at least one of the one or more annunciation patterns is accessible by a user when the ambulatory medicament device is in a locked state. 21.
  • the ambulatory medicament device of Embodiment 1 wherein the ambulatory medicament device further comprises a user interface element that enables a user to acknowledge an alarm corresponding to the alarm condition or to dismiss the alarm corresponding to the alarm condition, wherein the alarm is associated with at least one of the one or more annunciation patterns. 22.
  • a computer-implemented method of generating an alarm corresponding to a severity level of an alarm condition of an ambulatory medicament device configured to generate a dose control signal configured to cause a medicament pump to infuse medicament into a subject
  • the computer-implemented method comprising: by a hardware processor configured to generate a dose control signal configured to cause a medicament pump to infuse medicament into a subject, receiving a first status information comprising at least one of device information pertaining to a condition of the ambulatory medicament device or subject information pertaining to a condition of the subject; determining that the first status information satisfies an alarm condition for the ambulatory medicament device or for the subject; in response to determining that the first status information satisfies the alarm condition for the ambulatory medicament device or for the subject, and determining that the alarm condition is not already present in a list of pending alarm conditions, modifying the list of pending alarm conditions based on the alarm condition; determining a severity level of the alarm condition, wherein the severity level is one of a plurality of
  • the computer-implemented method of Embodiment 22 further comprising receiving the first status information from a monitoring system interface of the ambulatory medicament device, the monitoring system interface configured to receive status information.
  • the one or more annunciation patterns are selected from a plurality of annunciation patterns, and wherein at least one severity level of the plurality of severity levels is associated with a unique annunciation pattern of the plurality of annunciation patterns.
  • the computer-implemented method of Embodiment 22 further comprising sending alarm condition data corresponding to the alarm condition to a remote electronic device enabling the remote electronic device to annunciate the alarm condition.
  • the computer-implemented method of Embodiment 22 further comprising outputting, for display on a user interface of the ambulatory medicament device, an alarm state icon comprising a visual indication of a count of alarm conditions on the list of pending alarm conditions.
  • the computer-implemented method of Embodiment 22 further comprising: receiving a second status information; and in response to determining that the second status information satisfies the alarm condition for the ambulatory medicament device or for the subject, and determining that the indication of the alarm condition is already present in the list of pending alarm conditions, modifying the one or more annunciation patterns used to announce the alarm condition. 29.
  • Embodiment 22 further comprising: in response to determining that the severity level of the alarm condition matches an unsafe operation severity level, suspending delivery of the medicament to the subject; and in response to determining that the severity level of the alarm condition matches a safe operation severity level, maintaining delivery of the medicament to the subject.
  • An automated blood glucose control system configured to provide automatic delivery of glucose control therapy to a subject and receive information about manual glucose control therapy provided to the subject, the automated blood glucose control system comprising: a medicament delivery interface configured to operatively connect to a medicament pump configured to infuse medicament into the subject; a user interface controller configured to receive input signals corresponding to user interaction with a user interface; a memory configured to store specific computer-executable instructions and a therapy log; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: generate an indication of an amount of a bolus of medicament via a control algorithm configured to control blood glucose level in the subject, wherein the bolus of medicament corresponds to a meal bolus of medicament or a correction bolus of medicament, and wherein the amount of the bolus of medicament is selected by the control algorithm based at least in part on preceding periods of glycemic control in the subject; generate a display of a manual bolus screen comprising a manual bolus control element and
  • An ambulatory medical device comprising the automated blood glucose control system of Embodiment 1 and the medicament pump.
  • the medicament pump comprises at least one of an insulin pump or a counter-regulatory agent pump.
  • the hardware processor is further configured to execute the specific computer-executable instructions to at least model an accumulation of the manual bolus of the medicament in blood of the subject following subcutaneous infusion of the medicament.
  • receiving the indication of the amount of the manual bolus of medicament comprises detecting a gesture interaction made by a user. 7. The automated blood glucose control system of Embodiment 6, wherein detecting the gesture interaction made by the user comprises confirming that the gesture interaction matches a specified gesture interaction required for entry of the manual bolus of medicament. 8. The automated blood glucose control system of Embodiment 1, wherein receiving the indication of the amount of the manual bolus of medicament comprises receiving an estimate of a meal size or an estimate of a number of carbohydrates consumed by the subject. 9. The automated blood glucose control system of Embodiment 1, wherein receiving the indication of the amount of the manual bolus of medicament comprises receiving an estimate of an intensity of exercise engaged in by the subject. 10.
  • the automated blood glucose control system of Embodiment 1 wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least generate a dose control signal based at least in part on the indication of the amount of the manual bolus of medicament. 11.
  • the automated blood glucose control system of Embodiment 10 wherein the manual bolus of medicament is infused through injection therapy or pump therapy.
  • the automated blood glucose control system of Embodiment 10 wherein modeling the diminishment of the medicament in the subject over time enables an estimate of a future effect of medicament previously infused into the subject. 14.
  • An automated blood glucose control system configured to provide automatic delivery of glucose control therapy to a subject and receive information about manual glucose control therapy provided to the subject, the automated blood glucose control system comprising: a glucose sensor interface operative to receive a glucose level signal from a sensor operative to determine a glucose level of the subject at periodic measurement intervals; a delivery device interface configured to transmit an insulin dose control signal to a medicament pump operative to deliver doses of insulin to the subject; a memory configured to store specific computer-executable instructions; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: receive an indication of an amount of a manual bolus of insulin from a user interface; and automatically generate the insulin dose control signal based at least in part on the glucose level signal, an accumulation of insulin in the subject due to finite rate of utilization of the insulin, an input parameter corresponding to a weight of the subject, the indication of the amount of the manual bolus of insulin, and an indication of a time when the manual bolus of insulin was supplied to the subject.
  • the automated blood glucose control system of Embodiment 14 wherein the input parameter comprises a measure of weight, a body mass value, or a body mass index value. 16. The automated blood glucose control system of Embodiment 14, wherein the insulin dose control signal is automatically adjusted based on the amount of the manual bolus of insulin. 17. The automated blood glucose control system of Embodiment 14, wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least generate a glucagon dose control signal based at least in part on the indication of the amount of the manual bolus of insulin. 18.
  • An automated blood glucose control system configured to provide automatic delivery of glucose control therapy to a subject and receive information about manual glucose control therapy provided to the subject, the automated blood glucose control system comprising: a medicament delivery interface configured to operatively connect to a medicament pump configured to infuse medicament into the subject; a user interface controller configured to receive input signals corresponding to user interaction with a user interface; a memory configured to store specific computer-executable instructions; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: receive a meal announcement from a user responsive to the user interaction with the user interface, wherein the meal announcement comprises an indication of a size of a meal consumed or to be consumed by the subject; determine a meal bolus of insulin to administer to the subject based at least in part on the meal announcement, the meal bolus of insulin comprising an amount of insulin to administer to the subject to compensate for a change in blood glucose attributable to the meal; output for display an indication of the meal bolus of insulin; receive an indication of a requested modification to
  • a computer-implemented method of managing ambulatory medical device data access comprising: by a computing system of a networked computing environment, establishing a direct end-to-end data connection to an ambulatory medical device via a wireless wide area network; transmitting a public key of the computing system to the ambulatory medical device, wherein the public key permits the ambulatory medical device to encrypt data to be transmitted to the computing system, and wherein the computing system stores a private key corresponding to the public key, the private key enabling the computing system to decrypt data received from the ambulatory medical device; receiving, from the ambulatory medical device, 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, and responsive to receiving the request to transfer data stored on the ambulatory medical device to the computing system: receiving, via the direct end-to-end data connection, encrypted data from the ambulatory medical device; decrypting the encrypted data to obtain therapy data related to therapy delivered by
  • the computer-implemented method of Embodiment 1 wherein the request to access the therapy report comprises a device identifier associated with the ambulatory medical device, and wherein the device identifier is a unique identifier specific to the ambulatory medical device. 3.
  • the computer-implemented method of Embodiment 2 wherein the device identifier comprises or is generated based at least in part on an Internet Protocol (IP) address, a Media Access Control (MAC) address, a serial number, or a subject identifier.
  • IP Internet Protocol
  • MAC Media Access Control
  • establishing the direct end-to-end data connection comprises: receiving a device identifier associated with the ambulatory medical device, wherein the device identifier is a unique identifier specific to the ambulatory medical device; and determining that the ambulatory medical device is permitted to communicate with the computing system based at least in part on the device identifier. 7.
  • the computer-implemented method of Embodiment 1 further comprising associating the therapy data with the account identifier at a storage of the networked computing environment.
  • the computer-implemented method of Embodiment 1 further comprising generating a shared secret based at least in part on the public key and the private key, and wherein decrypting the encrypted data comprises using the shared secret to decrypt the encrypted data.
  • the computer-implemented method of Embodiment 1, wherein the computing system is located at a data center that hosts at least some computing systems of the networked computing environment. 11.
  • the computer-implemented method of Embodiment 1, wherein the ambulatory medical device comprises a mono-hormonal medicament pump, a bi-hormonal medicament pump, or a pacemaker.
  • the ambulatory medical device comprises a transceiver that supports communication over one or more communication standards comprising: a low power wide area network (LPWAN) communication standard, a Narrowband Long-Term Evolution (NB-LTE) standard, a Narrowband Internet-of-Things (NB-IoT) standard, or a Long-Term Evolution Machine Type Communication (LTE-MTC) standard.
  • 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 therapy data comprises at least one of dose data or subject data, wherein the dose data corresponds to one or more doses of medicament provided by the ambulatory medical device to the subject, and wherein the subject data corresponds to a medical or physiological state of the subject as determined by the ambulatory medical device.
  • the encrypted data further comprises at least one of operation data or error data, wherein the operation data corresponds to operation of the ambulatory medical device, and wherein the error data corresponds to an error in operation of the ambulatory medical device.
  • the account identifier comprises a unique identifier associated with the subject or with a user that is authorized to access the therapy report.
  • additional encrypted data is received from the ambulatory medical device on an intermittent basis, a periodic basis, a scheduled basis, or on a continuous basis for at least a time period.
  • the display system comprises a computing system of a medical provider or of a guardian of the subject. 19.
  • receiving the request to transfer data stored on the ambulatory medical device to the computing system comprises receiving the encrypted data from the ambulatory medical device.
  • a computing system included in a networked computing environment comprising: a memory configured to store specific computer-executable instructions; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: establish a direct end-to-end data connection to an ambulatory medical device via a wireless wide area network; transmit a public key to the ambulatory medical device, wherein the public key enables the ambulatory medical device to encrypt data to be transmitted to the computing system, and wherein the computing system stores a private key corresponding to the public key, the private key enabling the computing system to decrypt data received from the ambulatory medical device; receive, from the ambulatory medical device, 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; and responsive to receiving the request to transfer data stored on the ambulatory medical device to the computing system, the hardware processor is further configured to execute the specific computer-executable instructions to at least: receive, via
  • the hardware processor is further configured to execute the specific computer-executable instructions to at least generate a shared secret based at least in part on the public key and the private key, and wherein decrypting the encrypted data comprises using the shared secret to decrypt the encrypted data.
  • receiving the request to transfer data stored on the ambulatory medical device to the computing system comprises receiving the encrypted data from the ambulatory medical device.
  • the therapy data comprises at least one of dose data or subject data, wherein the dose data corresponds to one or more doses of medicament provided by the ambulatory medical device to the subject, and wherein the subject data corresponds to a medical or physiological state of the subject as determined by the ambulatory medical device.
  • the hardware processor is further configured to execute the specific computer-executable instructions to at least: determine that the therapy data satisfies an alert threshold; and generate an alert responsive to the therapy data satisfying the alert threshold.
  • the computing system of Embodiment 28 wherein the hardware processor is further configured to output the alert to one or more of the display system, a user device of a medical practitioner, the ambulatory medical device, a user device of an emergency services provider, a user device of the subject, or a user device of an authorized user associated with the subject.
  • the alert threshold is based at least in part on physiological information of the subject obtained from the ambulatory medical device.
  • a computer-implemented method of managing a non-critical malfunction in an ambulatory medical device configured to deliver therapy to a subject, the method comprising: by a processor of the ambulatory medical device, detecting a device condition of the ambulatory medical device; determining that the device condition does not satisfy a set of normal operating parameters for the ambulatory medical device; determining that the device condition satisfies a set of minimum operating parameters, wherein the set of minimum operating parameters are sufficient to permit delivery of therapy by the ambulatory medical device to the subject; and responsive to determining that the device condition does not satisfy the set of normal operating parameters and determining that the device condition satisfies the set of minimum operating parameters: maintaining the delivery of therapy by the ambulatory medical device to the subject; and generating a non-critical malfunction alert based at least in part on the device condition, wherein the non-critical malfunction alert enables a user to determine the device condition, wherein the non- critical malfunction alert is dismissible by the user, and wherein the generating of the non-critical malfunction alert is scheduled
  • the computer-implemented method of Embodiment 1, wherein the ambulatory medical device is a medicament pump.
  • the medicament pump comprises at least one of an insulin pump or a counter-regulatory agent pump.
  • at least some of the set of minimum operating parameters are provided by a manufacturer of the ambulatory medical device, a healthcare provider, the subject, or an authorized user.
  • at least some of the set of normal operating parameters are provided by a healthcare provider, the subject or an authorized user. 6.
  • the non-critical malfunction alert is repeated periodically.
  • the non-critical malfunction alert is repeated at variable time periods, wherein the variable time periods increase or decrease as time from an initial non-critical malfunction alert increases. 10.
  • the computer-implemented method of Embodiment 1, wherein the non-critical malfunction alert is repeated at time periods that change during the day based on time of day.
  • the computer-implemented method of Embodiment 1, wherein the alert modification condition comprises a change in the detected device condition.
  • the computer-implemented method of Embodiment 1, wherein generating the non-critical malfunction alert comprises contacting a manufacturer of the ambulatory medical device or a healthcare provider.
  • the computer-implemented method of Embodiment 1, wherein generating the non-critical malfunction alert comprises ordering medicament.
  • the computer-implemented method of Embodiment 1, wherein generating the non-critical malfunction alert comprises providing instructions for correcting a device malfunction. 15.
  • the computer-implemented method of Embodiment 1 wherein, in response to determining that the device condition does not satisfy the set of normal operating parameters for the ambulatory medical device, the delivery of therapy by the ambulatory medical device to the subject is maintained at a normal rate. 16. The computer-implemented method of Embodiment 1, wherein, in response to determining that the device condition does not satisfy the set of normal operating parameters for the ambulatory medical device, the delivery of therapy by the ambulatory medical device to the subject is maintained at a minimum rate. 17.
  • An ambulatory medical device configured to provide therapy to a subject, the ambulatory medical device comprising: a memory configured to store specific computer-executable instructions; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: detect a device condition of the ambulatory medical device; determine that the device condition does not satisfy a set of normal operating parameters for the ambulatory medical device; determine that the device condition satisfies a set of minimum operating parameters, wherein the set of minimum operating parameters are sufficient to permit delivery of therapy by the ambulatory medical device to a subject; and responsive to determining that the device condition satisfies the set of minimum operating parameters, the hardware processor is further configured to execute the specific computer-executable instructions to at least: maintain the delivery of therapy by the ambulatory medical device to the subject; and generate a user alert based at least in part on the device condition, wherein the user alert enables a user to determine the device condition of the ambulatory medical device, wherein the user alert is dismissible by the user,
  • the ambulatory medical device of Embodiment 17, comprising a medicament pump.
  • the ambulatory medical device of Embodiment 17, wherein the minimum and/or normal operating parameters are provided by the manufacturer of the ambulatory medical device.
  • the ambulatory medical device of Embodiment 17, wherein the minimum and/or normal operating parameters are provided by a healthcare provider.
  • 22. The ambulatory medical device of Embodiment 17, wherein the minimum and/or normal operating parameters are provided by the subject or an authorized user. 23.
  • a user alert type at a given time depends on the detected device condition that triggered the generation of the user alert and/or the number of times the user alert has been generated before the given time.
  • the hardware processor is configured to execute the specific computer-executable instructions to stop the delivery of therapy based at least partially on the detected device condition.
  • the alert modification condition comprises a change in the detected device condition.
  • generating the user alert comprises contacting a manufacturer or a healthcare provider.
  • the ambulatory medical device of Embodiment 17, wherein generating the user alert comprises ordering medicament.
  • generating the user alert comprises generating a display of instructions for resolving the detected device condition.
  • 29. The ambulatory medical device of Embodiment 17, wherein, in response to determining that the device condition does not satisfy the set of normal operating parameters for the ambulatory medical device, the hardware processor is configured to execute the specific computer-executable instructions to maintain the delivery of therapy to the subject at a normal rate.
  • the hardware processor in response to determining that the device condition does not satisfy the set of normal operating parameters for the ambulatory medical device, the hardware processor is configured to execute the specific computer-executable instructions to maintain the delivery of therapy to the subject at a reduced rate.
  • An ambulatory medicament device configured to automatically resume medicament delivery after medicament delivery to a subject is suspended, the ambulatory medicament device comprising: a medicament pump configured to receive dose control signals configured to cause the medicament pump to deliver medicament to the subject; a memory configured to store specific computer-executable instructions; and a hardware processor in communication with the memory and configured to execute the specific computer-executable instructions to at least: receive a request to temporarily suspend delivery of the medicament to the subject, wherein the request comprises an indication of a temporary suspension period associated with a length of time that the delivery of the medicament is to be suspended; suspend delivery of the medicament to the subject, wherein suspending delivery of the medicament includes not generating a dose control signal or generating the dose control signal to cause the medicament pump to administer no medicament to the subject during the temporary suspension period; determine that a resumption condition has occurred during the temporary suspension period, wherein the resumption condition requires no user action to trigger the resumption condition; generate a dose control signal after occurrence of the resumption condition, thereby discontinuing
  • the ambulatory medicament device of Embodiment 1 wherein the resumption condition occurs during the temporary suspension period. 3.
  • the ambulatory medicament device of Embodiment 1, wherein the resumption condition comprises expiration of the temporary suspension period. 4.
  • the ambulatory medicament device of Embodiment 1, wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least generate an alert prior to generating the dose control signal, wherein the alert indicates that the temporary suspension period has ended. 5.
  • the ambulatory medicament device of Embodiment 1, wherein the hardware processor is further configured to execute the specific computer-executable instructions to at least generate an alert upon determining that the resumption condition has occurred, wherein the alert indicates that the temporary suspension period has ended. 6.
  • receiving the request to temporarily suspend delivery comprises receiving a first user interaction with a user interface.
  • receiving the request to temporarily suspend delivery comprises receiving a second user interaction with a user interface.
  • the first user interaction comprises a gesture performed on a touchscreen display of the ambulatory medicament device.
  • determining that a resumption condition has occurred comprises determining that a user interaction with a user interface is received. 10.
  • determining that a resumption condition has occurred comprises determining that a medical condition of the subject satisfies a threshold condition.
  • the hardware processor is further configured to execute the specific computer-executable instructions to at least generate an alert responsive to determining that the resumption condition has occurred, wherein the alert indicates that the medical condition of the subject satisfies the threshold condition.
  • the ambulatory medicament device of Embodiment 11, wherein the threshold condition comprises a measured blood glucose level of the subject being above a threshold level. 14. The ambulatory medicament device of Embodiment 11, wherein the threshold condition comprises a measured blood glucose level of the subject being below a threshold level. 15. The ambulatory medicament device of Embodiment 1, wherein the medicament pump comprises an insulin pump. 16. The ambulatory medicament device of Embodiment 1, wherein the medicament pump comprises a bi-hormonal pump capable of administering insulin and a counter-regulatory agent. 17. The ambulatory medicament device of Embodiment 1, wherein the request comprises an indication of a suspension start time at which the delivery of the medicament is to be suspended. 18.
  • receiving the request to temporarily suspend delivery of the medicament to the subject comprises determining that one or more components of the ambulatory medicament device do not satisfy a minimum requirement for operation.
  • a method of automatically resuming medicament delivery after medicament delivery to a subject is suspended by a blood glucose control system comprising: by a hardware processor of the blood glucose control system configured to generate a dose control signal, wherein the dose control signal, when received by a medicament pump, commands the medicament pump to administer a medicament to the subject or to administer no medicament to the subject: receiving a request to temporarily suspend delivery of the medicament to the subject, wherein the request comprises an indication of a temporary suspension period associated with a length of time that the delivery of the medicament is to be suspended; suspending delivery of the medicament to the subject, wherein suspending delivery of the medicament includes not generating the dose control signal or generating the dose control signal to cause the medicament pump to administer no medicament to the subject during the temporary suspension period; determining that a resumption condition has occurred during the temporary
  • the computing system may include, be implemented as part of, or communicate with an automated blood glucose system, an ambulatory medicament system, or an ambulatory medical device.
  • an automated blood glucose system an ambulatory medicament system
  • an ambulatory medical device an ambulatory medical device.
  • acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (for example, not all described acts or events are necessary for the practice of the algorithms).
  • acts or events can be performed concurrently, for example, through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.
  • a processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like.
  • a processor can include electrical circuitry configured to process computer-executable instructions.
  • a processor includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions.
  • a processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
  • a processor may also include primarily analog components.
  • a computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.
  • Conditional language such as, among others, “can,” “could,” “might” or “may,” unless specifically stated otherwise, are otherwise understood within the context as used in general to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.
  • Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (for example, X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.
  • Such one or more recited devices can also be collectively configured to carry out the stated recitations.
  • a processor configured to carry out recitations A, B and C can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

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)
  • Primary Health Care (AREA)
  • Epidemiology (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Animal Behavior & Ethology (AREA)
  • Veterinary Medicine (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Pathology (AREA)
  • Hematology (AREA)
  • Anesthesiology (AREA)
  • Vascular Medicine (AREA)
  • Surgery (AREA)
  • Molecular Biology (AREA)
  • Biophysics (AREA)
  • Medicinal Chemistry (AREA)
  • Software Systems (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Chemical & Material Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Optics & Photonics (AREA)
  • Computer Security & Cryptography (AREA)
  • Diabetes (AREA)
  • General Physics & Mathematics (AREA)
  • Emergency Medicine (AREA)
  • Pharmacology & Pharmacy (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Infusion, Injection, And Reservoir Apparatuses (AREA)
  • Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • External Artificial Organs (AREA)
PCT/US2020/054025 2019-10-04 2020-10-02 Blood glucose control system WO2021067767A1 (en)

Priority Applications (8)

Application Number Priority Date Filing Date Title
AU2020358856A AU2020358856A1 (en) 2019-10-04 2020-10-02 Blood glucose control system
CA3151777A CA3151777A1 (en) 2019-10-04 2020-10-02 Blood glucose control system
JP2022520424A JP2023503792A (ja) 2019-10-04 2020-10-02 血糖制御システム
CN202080084028.1A CN114868200A (zh) 2019-10-04 2020-10-02 血糖控制系统
DE112020004762.8T DE112020004762T5 (de) 2019-10-04 2020-10-02 Blutzuckerkontrollsystem
MX2022003961A MX2022003961A (es) 2019-10-04 2020-10-02 Sistema de control de glucosa en sangre.
EP20872387.4A EP4042441A4 (en) 2019-10-04 2020-10-02 GLUCOSE REGULATION SYSTEM
IL291671A IL291671A (en) 2019-10-04 2022-03-24 Blood glucose control system

Applications Claiming Priority (16)

Application Number Priority Date Filing Date Title
US201962910970P 2019-10-04 2019-10-04
US201962911017P 2019-10-04 2019-10-04
US201962911143P 2019-10-04 2019-10-04
US62/911,143 2019-10-04
US62/910,970 2019-10-04
US62/911,017 2019-10-04
US202062987842P 2020-03-10 2020-03-10
US62/987,842 2020-03-10
US202063037472P 2020-06-10 2020-06-10
US63/037,472 2020-06-10
PCT/US2020/042195 WO2021011697A1 (en) 2019-07-16 2020-07-15 Blood glucose control system
USPCT/US2020/042195 2020-07-15
PCT/US2020/042198 WO2021011699A1 (en) 2019-07-16 2020-07-15 Ambulatory device and components thereof
USPCT/US2020/042198 2020-07-15
PCT/US2020/042269 WO2021011738A1 (en) 2019-07-16 2020-07-16 Blood glucose control system
USPCT/US2020/042269 2020-07-16

Publications (1)

Publication Number Publication Date
WO2021067767A1 true WO2021067767A1 (en) 2021-04-08

Family

ID=75336591

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/US2020/054130 WO2021067856A1 (en) 2019-10-04 2020-10-02 Blood glucose control system
PCT/US2020/054025 WO2021067767A1 (en) 2019-10-04 2020-10-02 Blood glucose control system

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/US2020/054130 WO2021067856A1 (en) 2019-10-04 2020-10-02 Blood glucose control system

Country Status (9)

Country Link
EP (2) EP4042441A4 (ja)
JP (2) JP2022551265A (ja)
CN (2) CN114868200A (ja)
AU (2) AU2020358856A1 (ja)
CA (2) CA3151782A1 (ja)
DE (2) DE112020004762T5 (ja)
IL (2) IL291671A (ja)
MX (2) MX2022003962A (ja)
WO (2) WO2021067856A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210060244A1 (en) * 2019-08-28 2021-03-04 Medtronic Minimed, Inc. Method and system for verifying whether a non-medical client device is operating correctly with a medical device controlled by the non-medical client device and causing a notification to be generated
US20220148724A1 (en) * 2020-11-11 2022-05-12 Itamar Medical Ltd. Sleep apnea test device
EP4243031A1 (en) * 2022-03-11 2023-09-13 Diabeloop Computerized system for communicating treatment information to a user
US12005234B2 (en) 2022-11-08 2024-06-11 Medtronic Minimed, Inc. Backup notifications in a medical device system

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022204705A1 (en) * 2021-03-25 2022-09-29 Beta Bionics, Inc. Emergency medicament dose control

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130102853A1 (en) * 2011-10-24 2013-04-25 Roche Diagnostics Operations,Inc. Interoperability enhancement that supports connectivity of applications on a medical device
WO2014100557A2 (en) * 2012-12-21 2014-06-26 Deka Products Limited Partnership System and apparatus for electronic patient care
US20150165117A1 (en) * 2013-12-12 2015-06-18 Medtronic Minimed, Inc. Predictive infusion device operations and related methods and systems
US20160030669A1 (en) * 2014-07-30 2016-02-04 Tandem Diabetes Care, Inc. Temporary suspension for closed-loop medicament therapy
US20170068533A1 (en) * 2010-05-24 2017-03-09 Abbott Diabetes Care Inc. Systems and methods for updating a medical device
US20170136198A1 (en) * 2014-05-27 2017-05-18 Resmed Limited Remote respiratory therapy device management
US20170189614A1 (en) * 2016-01-05 2017-07-06 Bigfoot Biomedical, Inc. Operating multi-modal medicine delivery systems
US20170296056A1 (en) * 2016-03-31 2017-10-19 Zoll Medical Corporation Remote access for ambulatory medical device
US20180060529A1 (en) * 2016-08-29 2018-03-01 Bigfoot Biomedical, Inc. Network Topology for Insulin Pump Systems
US20180169330A1 (en) * 2013-03-15 2018-06-21 Tandem Diabetes Care, Inc. Field update of an ambulatory infusion pump system
US20190019573A1 (en) * 2015-03-24 2019-01-17 Ares Trading S.A. Patient care system
US20190132801A1 (en) * 2017-10-30 2019-05-02 Dexcom, Inc. Diabetes management partner interface for wireless communication of analyte data
US20190180869A1 (en) * 2015-02-27 2019-06-13 Zoll Medical Corporation Downloading and booting method and system for a wearable medical device
WO2019125932A1 (en) * 2017-12-21 2019-06-27 Eli Lilly And Company Closed loop control of physiological glucose

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7591801B2 (en) * 2004-02-26 2009-09-22 Dexcom, Inc. Integrated delivery device for continuous glucose sensor
EP1881786B1 (en) 2005-05-13 2017-11-15 Trustees of Boston University Fully automated control system for type 1 diabetes
EP2562664B1 (en) * 2007-06-27 2020-11-25 Roche Diabetes Care GmbH System for determining an insulin delivery and communicating a dose in automated pancreas software
US10231077B2 (en) * 2007-07-03 2019-03-12 Eingot Llc Records access and management
WO2010089306A1 (en) * 2009-02-04 2010-08-12 Sanofi-Aventis Deutschland Gmbh Medical system and method for providing glycemic control based on glycemic response information
EP3936032B1 (en) * 2009-07-23 2024-05-29 Abbott Diabetes Care, Inc. Real time management of data relating to physiological control of glucose levels
WO2012058694A2 (en) 2010-10-31 2012-05-03 Trustees Of Boston University Blood glucose control system
EP2851823A1 (en) * 2013-09-20 2015-03-25 Sanofi-Aventis Deutschland GmbH Data management unit for supporting health control
DK3089667T3 (da) 2014-01-31 2022-05-09 Univ Boston Offline-glucosestyring baseret på forudgående tidsrum
US9486580B2 (en) * 2014-01-31 2016-11-08 Aseko, Inc. Insulin management
JP2018525093A (ja) 2015-08-07 2018-09-06 トラスティーズ オブ ボストン ユニバーシティ グルコース目標の自動適合を備えたグルコース制御システム
EP3337402A4 (en) * 2015-08-20 2019-04-24 Aseko, Inc. THERAPY ADVISER FOR THE MANAGEMENT OF DIABETES
EP3374004B1 (en) * 2016-01-14 2023-06-28 Bigfoot Biomedical, Inc. Adjusting insulin delivery rates
US20170259072A1 (en) * 2016-03-14 2017-09-14 Qualcomm Incorporated System architecture for medical implant
US10937536B2 (en) * 2016-07-15 2021-03-02 Universität Bern Estimation of insulin based on reinforcement learning
EP3603401B1 (en) 2018-08-02 2021-12-08 Radie B.V. Device and method for portioning a dough mass
WO2021011738A1 (en) * 2019-07-16 2021-01-21 Beta Bionics, Inc. Blood glucose control system

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170068533A1 (en) * 2010-05-24 2017-03-09 Abbott Diabetes Care Inc. Systems and methods for updating a medical device
US20130102853A1 (en) * 2011-10-24 2013-04-25 Roche Diagnostics Operations,Inc. Interoperability enhancement that supports connectivity of applications on a medical device
WO2014100557A2 (en) * 2012-12-21 2014-06-26 Deka Products Limited Partnership System and apparatus for electronic patient care
US20180169330A1 (en) * 2013-03-15 2018-06-21 Tandem Diabetes Care, Inc. Field update of an ambulatory infusion pump system
US20150165117A1 (en) * 2013-12-12 2015-06-18 Medtronic Minimed, Inc. Predictive infusion device operations and related methods and systems
US20170136198A1 (en) * 2014-05-27 2017-05-18 Resmed Limited Remote respiratory therapy device management
US20160030669A1 (en) * 2014-07-30 2016-02-04 Tandem Diabetes Care, Inc. Temporary suspension for closed-loop medicament therapy
US20190180869A1 (en) * 2015-02-27 2019-06-13 Zoll Medical Corporation Downloading and booting method and system for a wearable medical device
US20190019573A1 (en) * 2015-03-24 2019-01-17 Ares Trading S.A. Patient care system
US20170189614A1 (en) * 2016-01-05 2017-07-06 Bigfoot Biomedical, Inc. Operating multi-modal medicine delivery systems
US20170296056A1 (en) * 2016-03-31 2017-10-19 Zoll Medical Corporation Remote access for ambulatory medical device
US20180060529A1 (en) * 2016-08-29 2018-03-01 Bigfoot Biomedical, Inc. Network Topology for Insulin Pump Systems
US20190132801A1 (en) * 2017-10-30 2019-05-02 Dexcom, Inc. Diabetes management partner interface for wireless communication of analyte data
WO2019125932A1 (en) * 2017-12-21 2019-06-27 Eli Lilly And Company Closed loop control of physiological glucose

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210060244A1 (en) * 2019-08-28 2021-03-04 Medtronic Minimed, Inc. Method and system for verifying whether a non-medical client device is operating correctly with a medical device controlled by the non-medical client device and causing a notification to be generated
US20220148724A1 (en) * 2020-11-11 2022-05-12 Itamar Medical Ltd. Sleep apnea test device
EP4243031A1 (en) * 2022-03-11 2023-09-13 Diabeloop Computerized system for communicating treatment information to a user
FR3133478A1 (fr) * 2022-03-11 2023-09-15 Diabeloop Système informatisé de communication d’informations de traitement à un utilisateur
US12005234B2 (en) 2022-11-08 2024-06-11 Medtronic Minimed, Inc. Backup notifications in a medical device system

Also Published As

Publication number Publication date
DE112020004762T5 (de) 2022-08-11
DE112020004780T5 (de) 2022-09-01
CA3151777A1 (en) 2021-04-08
CN114868200A (zh) 2022-08-05
AU2020356952A1 (en) 2022-04-14
IL291671A (en) 2022-05-01
EP4042436A1 (en) 2022-08-17
AU2020358856A1 (en) 2022-04-14
JP2023503792A (ja) 2023-02-01
WO2021067856A1 (en) 2021-04-08
MX2022003961A (es) 2022-07-21
JP2022551265A (ja) 2022-12-08
MX2022003962A (es) 2022-07-21
CN114902344A (zh) 2022-08-12
EP4042441A1 (en) 2022-08-17
IL291746A (en) 2022-05-01
EP4042436A4 (en) 2023-10-04
EP4042441A4 (en) 2023-10-11
CA3151782A1 (en) 2021-04-08

Similar Documents

Publication Publication Date Title
US11803367B2 (en) Ambulatory medicament device with alarm
EP4042441A1 (en) Blood glucose control system
WO2022178447A1 (en) Medicament pumps with systems and methods for improving user experience

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: 20872387

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
ENP Entry into the national phase

Ref document number: 3151777

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2022520424

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2020358856

Country of ref document: AU

Date of ref document: 20201002

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2020872387

Country of ref document: EP

Effective date: 20220504