JP7730109B2 - Blood sugar control system - Google Patents

Description

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
This invention was made with United States government support under Contract No. DK120234 awarded by the National Institutes of Health. The United States government has certain rights in this invention.
INCORPORATION-BY-REFERENCE OF PRIORITY APPLICATIONS All applications for which a foreign or domestic priority claim is identified in the Application Data Sheet filed with this application are hereby incorporated by reference under 37 CFR 1.57.

The present disclosure relates to a glycemic control system and a mobile medical device that provides treatment to a patient.

Continuous-delivery, pump-driven medication injection devices generally include a delivery cannula placed subcutaneously through the patient's skin at the injection site. The pump draws medication from a reservoir and delivers it to the patient through the cannula. The injection device typically includes a channel that routes medication from an entry port to the delivery cannula, resulting in delivery to the subcutaneous tissue layer where the delivery cannula terminates. Some infusion devices are configured to deliver a single medication to a patient, while others are configured to deliver multiple medications to a patient.

Disclosed are glycemic control systems and mobile medical devices that provide therapy, such as glycemic control, to patients. The disclosed systems and devices can implement one or more features that improve the user experience, such as software update technology to avoid interruptions in therapy delivery, 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.

The systems, methods, and devices of the present disclosure each have several innovative aspects, no single one of which is solely responsible for all of the desirable attributes disclosed herein. Details of one or more implementations of the subject matter described herein are set forth in the accompanying drawings and the description below.

1 illustrates an exemplary glycemic control system that provides glycemic control via an ambulatory drug pump.

1 illustrates another exemplary glycemic control system that provides glycemic control via an ambulatory drug pump.

1 illustrates another exemplary glycemic control system that provides glycemic control via an ambulatory drug pump.

1 shows a block diagram of an exemplary glycemic control system.

FIG. 1 shows a block diagram of another exemplary glycemic control system.

FIG. 1 shows a block diagram of another exemplary glycemic control system.

FIG. 1 shows a block diagram of another exemplary glycemic control system.

FIG. 1 is a schematic diagram of an exemplary glucose control system including an electronic communication interface.

FIG. 1 shows a block diagram of an exemplary glycemic control system in an online mode of operation.

FIG. 1 shows a block diagram of an exemplary glycemic control system in an offline mode of operation.

1 is a perspective view of an exemplary ambulatory medical device.

5B shows a cross-sectional view of the ambulatory medical device shown in FIG. 5A.

FIG. 1 illustrates different modules that may be included in an exemplary ambulatory medical device (AMD).

1 illustrates various methods and links that an AMD can use to establish a communications connection with a host computing system.

FIG. 1 is a flow diagram illustrating an example of a computer-implemented method that may be used by an AMD to detect and download application updates.

FIG. 10 is a flow diagram illustrating an example of a computer-implemented method that may be used by an AMD to install downloaded application updates without interrupting the treatment provided to a patient.

FIG. 10 is a flow diagram illustrating 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 a second application without interrupting the therapy provided to the patient.

FIG. 10 is a flow diagram illustrating an example of a computer-implemented method that may be used by an AMD to install a second application downloaded from a host computing system, and to verify and switch control of the AMD from a first application to a second application without interrupting the therapy provided to the patient, but only if the second application meets a minimum set of operating conditions.

FIG. 1 is a flow diagram illustrating an example of a computer-implemented method that may be used to switch control of an AMD to a second version of an application installed on the AMD in response to detecting an application failure while a first version of the application is running.

FIG. 1 is a flow diagram illustrating an example of a computer-implemented method that may be used to switch control of an AMD to a second version of an application installed on the AMD and/or download a third version of the application in response to detecting an application failure while a first version of the application is running.

FIG. 1 is a block diagram illustrating an exemplary network configuration in which an AMD is directly connected to a computing system, and the computing system shares treatment reports with one or more display systems and the AMD.

FIG. 1 is a flow diagram illustrating an example method that may be used by a computing system to generate and share a treatment report based on encrypted treatment data received from an AMD.

FIG. 1 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. 2 is a block diagram illustrating an exemplary network and data flow configuration in which an AMD is directly connected to a computing system, which generates and sends alerts to one or more display systems and the AMD.

1 is a flow diagram illustrating an exemplary method that may be used by a computing system to generate and transmit an alert to one or more authorized devices.

1 illustrates the interconnections between the modules and procedures of the AMD involved in receiving, accepting, and/or canceling a therapy change request.

FIG. 10 is a flow diagram illustrating an exemplary method that may be used by an AMD to allow a user to change the configuration of an ambulatory medication device using a touch screen user interface.

FIG. 2 is a diagram of an exemplary AMD touch screen display after the touch screen has been activated/unlocked by a user wake action and before a first user gesture is received.

FIG. 1 is a diagram of an exemplary touch screen display that can prompt a user to enter a predetermined sequence of inputs for a first gesture or a second gesture.

FIG. 10 is an exemplary therapy change user interface.

FIG. 10 is a diagram of another therapy change user interface on a touch screen display.

FIG. 10 is a flow diagram illustrating an example method that may be used by an AMD to generate an alarm condition indicator.

FIG. 10 is a flow diagram illustrating an exemplary method that may be used to cancel a therapy change using a touch screen interface.

FIG. 10 is a diagram of a touch screen display alerting a user that delivery of one or more medications is about to occur.

FIG. 10 is a diagram of a touch screen display showing medication being delivered to a user.

FIG. 2 is a block diagram illustrating the interconnections between modules and procedures within an AMD involved in receiving, accepting, and/or canceling a therapy interruption request.

FIG. 1 is a flow diagram illustrating an exemplary method for receiving and implementing an interrupt request that may be implemented by an AMD.

10 illustrates several screens that a mobile medical device can display when a user pauses treatment.

FIG. 1 is a flow diagram illustrating an exemplary method for resuming a suspended therapy that may be performed by an AMD.

10A-10C illustrate several screens that a mobile medical device can display when a user resumes treatment.

FIG. 2 is a block diagram illustrating the interconnection of modules and procedures of an AMD involved in changing the configuration of the AMD.

FIG. 1 is a flow diagram illustrating an example method that may be used by an AMD to allow a user to change the settings of the AMD using a user-generated or override passcode.

FIG. 1 is a flow diagram illustrating an example method that may be used by an AMD to allow a user to change the settings of the AMD using a user-generated or override passcode.

FIG. 1 is a schematic diagram showing the interconnections between the modules and procedures of an AMD involved in monitoring the AMD and/or patient condition and generating an alert when an alert condition is met.

FIG. 1 is a flow diagram illustrating an exemplary procedure that may be used by an alarm system of an AMD to announce an alarm condition upon receiving status information that satisfies the alarm condition.

FIG. 10 is a diagram of a user interface provided on the touch screen display for accessing an alarm notification screen when the touch screen display is locked.

FIG. 10 is a diagram of a user interface provided on the touch screen display for accessing an alarm notification screen when the touch screen display is unlocked.

1 is a block diagram illustrating the interconnections between the modules and procedures of an AMD involved in monitoring the state of the AMD and generating alerts when device malfunction is detected.

FIG. 1 is a flow diagram illustrating an exemplary procedure that may be used by an alert system of an AMD to monitor the operation of the AMD and generate an alert when a device malfunction is detected.

FIG. 1 is a schematic diagram illustrating a mobile medical device that provides a user with various options for delivering medication.

FIG. 1 is a flow diagram of a process for providing options for meal dose selection on a mobile device.

FIG. 10 is another flow diagram of a process for providing options for meal dose selection on a mobile device.

10 is a series of screen displays showing a user initiating activation of a meal dose on a mobile device.

10 is a series of screen displays showing a user initiating a meal dose on a mobile device.

10 is a sequence of screen displays showing a user activating a meal guide on a mobile device.

10 is a series of screen displays showing a user entering a total number of units into a mobile device.

10 is a series of screen displays showing a mobile medical device delivering a unit and canceling the delivery of a unit.

FIG. 1 is a schematic diagram illustrating a computer system in which various embodiments of the described subject matter may be implemented.

FIG. 1 is a flow diagram of a process for receiving manual input of a medication dose on a mobile device.

Some embodiments described herein relate to drug infusion systems and components of such systems (e.g., infusion pumps, drug cartridges, cartridge connectors, lumen assemblies, infusion connectors, infusion sets, etc.) for one or more medications. Some embodiments relate to methods of manufacturing the infusion systems and their components. Some embodiments relate to methods of using any of the aforementioned systems or components to infuse one or more medications (e.g., medications, hormones, etc.) into a patient. As illustrative examples, an infusion system may include an infusion pump that may include one or more drug cartridges or may have an integrated reservoir of medication. An infusion system may include a drug cartridge and a cartridge connector, but not a pump. An infusion system may include a cartridge connector and an infusion pump, but not a drug cartridge. An infusion system may include an infusion connector, a lumen assembly, a cartridge connector, an infusion pump, but not a drug cartridge or an infusion set. A glycemic control system can operate in conjunction with the infusion system to infuse one or more medications, including at least one glycemic control agent, into a patient. Any feature, structure, component, material, step, or method described and/or illustrated in any embodiment herein may be used in conjunction with or in place of any feature, structure, component, material, step, or method described and/or illustrated in any other embodiment herein. Additionally, any feature, structure, component, material, step, or method described and/or illustrated in one embodiment may not be present in another embodiment.

Overview of Blood Glucose Control Systems Blood glucose control systems (BGCSs) are used to control a patient's blood glucose levels. A blood glucose control system may include a controller configured to generate a dose control signal for one or more glucose control agents that can be infused into a patient. Glucose control agents include regulators that tend to decrease blood glucose levels, such as insulin and insulin analogs, and counter-regulators that tend to increase blood glucose levels, such as glucagon or dextrose. A blood glucose control system configured for use with two or more glucose control agents can generate a dose control signal for each of the agents. In some embodiments, the blood glucose control system can generate a dose control signal for a drug even if the drug is not available for administration via a drug pump connected to the patient.

The glucose control agent may be delivered to the patient via subcutaneous injection, intravenous injection, or another suitable delivery method. For glycemic control therapy via an ambulatory drug pump, subcutaneous injection is most common. The ambulatory drug pump 100 is a type of ambulatory medical device (AMD), sometimes referred to herein as an ambulatory device, ambulatory drug device, ambulatory mobility device, or AMD. Ambulatory medical devices include ambulatory drug pumps and other devices configured to be carried by a patient and deliver therapy to the patient. 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.

In some examples, the ambulatory medical device (AMD) is an electrical stimulation device, and therapy delivery includes providing electrical stimulation to the patient. One example of an electrical stimulation device is a cardiac pacemaker. A cardiac pacemaker generates electrical stimulation of the myocardium to control cardiac rhythm. Another example of an electrical stimulation device is a deep brain stimulation device for treating Parkinson's disease or movement disorders.

Figures 1A-1C show an example of a glycemic control system that provides glycemic control via an ambulatory drug pump connected to a patient. In Figure 1A, a drug pump 100 is connected to an infusion site 102 using an infusion set 104. The drug pump has an integrated pump control 106a that allows a user to view pump data and change treatment settings through user interaction with the pump control 106a. A glucose level sensor 110 generates a glucose level signal that is received by the glycemic control system.

In FIG. 1B, drug pump 100 communicates with external electronic device 108 (e.g., a smartphone) via a wireless data connection. At least a portion of pump controls 106a and 106b can be operated via user interaction with user interface elements of external electronic device 108. Glucose level sensor 110 can also communicate with drug pump 100 via the wireless data connection.

In FIG. 1C, drug pump 100 includes an integrated cannula for insertion into infusion site 102 without a separate infusion set. At least a portion of pump control 106b can be operated via user interaction with user interface elements of external electronic device 108. In some cases, pump controls can be operated via user interaction with user interface elements generated by a remote computing environment (not shown), such as a cloud computing service, that connects to drug 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 that can change therapy settings through user interaction with the interface controls. For example, a user can provide instructions for a manual bolus amount of medication from an electronic device separate from the medication pump. The user interface may include a display and
The user interface may be implemented via an electronic device including one or more buttons, switches, dials, a capacitive touch interface, or a touch screen interface. In some embodiments, at least a portion of the user interface is integrated with an ambulatory drug pump that can be connected to a patient's body via an infusion set configured to facilitate subcutaneous injection of one or more glucose control agents. In certain embodiments, at least a portion of the user interface is implemented via an electronic device separate from the ambulatory drug pump, such as a smartphone.

2A-2D show block diagrams illustrating exemplary configurations of glucose control systems 200a/200b/200c/200d. As shown in FIG. 2A, glucose control system 200a may include a controller 202a having an electronic processor 204a and a memory 210a storing instructions 208a executable by processor 204a. Controller 202a and pump 212 may be integrated into ambulatory medical device (AMD) 100. Pump 212 may be a regulator pump and/or a counterregulator pump. AMD 100 may have one or more pumps 212. AMD 100 may include a transceiver or wireless electronic communication interface 214a for wireless digital data communication with an external electronic device. When the instructions 208a stored in memory 210a are executed by electronic processor 204a, controller 202a can implement at least a portion of a control algorithm that generates dose control signals for one or more glucose-controlling agents based on the patient's time-varying glucose level (e.g., received from glucose level sensor 110 in communication with drug pump 100) and one or more control parameters. The dose control signals, when delivered to pump 212, result in dosing action that controls the patient's blood glucose.

As shown in FIG. 2B , the glucose control system 200b can operate at least in part through execution of instructions 208b by an electronic processor 204b of an electronic device 108 separate from the mobile 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 the controller 202b can implement at least a portion of a control algorithm through execution of instructions 208b stored in memory 210b. When the instructions 208b stored in memory 210b are executed by the electronic processor 204b, 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 the patient's time-varying glucose levels and one or more control parameters. The dose control signals, when delivered to the pump 212, result in dosing actions that control the patient's blood glucose. In some embodiments, the dose control signals are transmitted from the device transceiver 214b to the AMD transceiver 214a via a short-range wireless data connection 216. The AMD 100 receives the dose control signals and sends them to the pump 212 for dosing operations.

As shown in FIG. 2C, glucose control system 200c can operate at least in part through execution of instructions 208c on electronic processor 204c integrated with a remote computer 206, such as a cloud service. When instructions 208c stored in memory 210c are executed by electronic processor 204c, 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 the patient's time-varying glucose level and one or more control parameters. When delivered to pump 212, the dose control signals result in dosing actions that control the patient's blood glucose. In some embodiments, the dose control signals are transmitted from remote computer WAN connection interface 220c to AMD WAN connection interface 220a via end-to-end wireless data connection 218. AMD 100 receives the dose control signals and sends them to pump 212 for dosing actions.

As shown in FIG. 2D , glucose control system 200d can have two or more controllers 202a, 202b, 202c that cooperate to generate dose control signals for administration by pump 212. Remote computer 206 can transmit or receive data or instructions passed through WAN connection interface 220c to WAN connection interface 220b of electronic device 108 via WAN wireless data connection 218. Electronic device 108 can transmit or receive data or instructions passed through transceiver 214b to transceiver 214a of AMD 100 via short-range wireless data connection 216. In some embodiments, the electronic device can be omitted, and controllers 202a, 202c of AMD 100 and remote computer 206 cooperate to generate dose control signals that are passed to pump 212. In such embodiments, AMD 100 can have its own WAN connection interface 220a to support a direct end-to-end wireless data connection to remote computer 206.

As shown in FIG. 3 , in some embodiments, the glucose control system 200 includes circuitry implementing an electronic communications interface (ECI) 302 configured to receive and transmit electronic data from one or more electronic devices. 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 a glucose level signal at fixed or periodic measurement intervals, such as five-minute intervals. The glucose level sensor 110 can be operably connected to the patient to generate a glucose level signal corresponding to the patient's blood glucose estimate or measurement. The glucose level signal can be used by the controller 202 to generate a dosage control signal. The dosage control signal can be provided to the pump 212 via a pump interface or delivery device interface 306. In some embodiments, the sensor interface 304 connects to the sensor 110 via a short-range wireless connection 308. In some embodiments, 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, ECI 306, and pump 212 are integrated into the AMD 100.

The controller can be configured to generate dose control signals using a control algorithm that generates at least one of the basal dose, correction dose, and/or meal dose. Examples of control algorithms that can be used to generate these doses are disclosed in U.S. Patent Application Publication Nos. 2008/0208113, 2013/0245547, 2016/0331898, and 2018/0220942 (herein referred to as the "controller disclosures"), the entire contents of which are incorporated herein by reference. Correction doses can include regulators or counter-regulators and can be generated using a model-predictive control (MPC) algorithm, such as those disclosed in the controller disclosures. Basal doses can include regulators and can be generated using a basal control algorithm, such as those disclosed in the controller disclosures. Meal doses can include regulators and can be generated using a meal control algorithm, such as those disclosed in the controller disclosures. At least some additional aspects and improvements of these controllers are disclosed herein. The dosage control signal can be transmitted to the pump interface 306 via the ECI 302, or, if the controller 202a is incorporated into the same housing as the pump interface 306, can be transmitted to the pump interface 306 via electrical conductors.

As shown in FIG. 4A, the controller 400 can be configured to operate in an "online mode" during periods when the controller receives a glucose level signal 402 from the glucose level sensor 110. In the on-line mode, the control algorithm generates a dose control signal 404 that implements a regular correction dose based on the value of the glucose level signal 402 and the control parameters of the control algorithm. The pump 212 is configured to deliver at least the correction dose and the basal dose to the patient without substantial user intervention while the controller 400 remains in the on-line mode.

As shown in FIG. 4B, the controller 400 can be configured to operate in an "offline mode" during periods when the controller does not receive a glucose level signal 402 from the sensor 110, at least during periods when a glucose level signal 402 is expected but not received. In the offline mode, the control algorithm generates a dose control signal 404 in response to an isolated glucose measurement 406 (e.g., a measurement obtained from the patient using a glucose test strip) that implements a correction dose based on the control parameters of the control algorithm. The pump 212 is configured to deliver a basal dose to the patient without substantial user intervention and can deliver a correction dose to the patient in response to the isolated glucose measurement 406 while the controller 400 remains in the offline mode.

Exemplary Mobile Medical Devices In some embodiments, an ambulatory medical device (AMD) may be a portable or wearable device (e.g., an insulin or bihormonal drug pump) that provides life-saving treatment to a patient by delivering one or more medications (e.g., insulin and/or glucagon) to the patient. Some AMDs may continuously monitor a patient's health (e.g., blood glucose levels) using a sensor (e.g., a blood glucose sensor capable of measuring a value corresponding to blood glucose levels) and deliver therapy (e.g., one or more medications) to the patient based on the patient's condition. Certain ambulatory medication devices may be worn by a patient all the time (e.g., all day) or for a large portion of the day (e.g., while awake, sleeping, not swimming, etc.) to enable continuous monitoring of the patient's health and deliver medication as needed. In some embodiments, the AMD may be a mobile medication device such as a medication delivery pump. In some examples, the AMD may be a device that provides therapy in the form of electrical stimulation based on a patient's health (e.g., cardiac rhythm or brain activity) determined using signals received from one or more sensors (e.g., a heart rate monitor or electrodes that monitor brain activity).

FIG. 5A shows a three-dimensional (3D) view of an exemplary ambulatory medical device (e.g., an ambulatory medication delivery pump such as an insulin pump) 500 comprising a housing 502 having a wake button 506 and a touchscreen display 504. FIG. 5B shows a cross-sectional view of the AMD 500 shown in FIG. 5A. In this example, all electronic systems 508 are contained within the housing 502, e.g., 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 input generated by user interaction with the wake button 506 and generates a wake signal. In some embodiments, the wake signal is generated by a sensor (e.g., a biometric sensor such as a fingerprint reader or retinal scanner, an optical or RF proximity sensor, etc.). In various embodiments, the wake signal may be generated by user interaction with the touchscreen display 504 or an alphanumeric pad (not shown). In some examples, the wake signal may be generated based on facial recognition or other biometric indicators. In some examples, the wake signal may be generated by a wireless signal, such as a signal generated by an RFID system or a Bluetooth signal received from the electronic device, or by detecting motion using one or more motion sensors, such as an accelerometer. The wake button 506, when touched, pressed, or held for a period of time, may generate a wake signal that activates the touchscreen display 504. In some examples, a touch on the touchscreen display 504 is not registered until the wake button activates the touchscreen display. In some such examples, the AMD remains locked from accepting at least certain types of user interactions or setting changes until a gesture (e.g., 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. In some examples, a passcode may be required to unlock the touchscreen display after the touchscreen display 504 is activated by a wake signal.

FIG. 6 illustrates different modules that may be included in an exemplary AMD 500 (e.g., a glucose control system). As described above, in some examples, the AMD may include a complete glucose control system (e.g., AMD 100 and glucose control system 200a). In some embodiments, the AMD may include one or more systems that can facilitate monitoring a patient's blood glucose levels, maintaining the patient's diabetes, tracking the status of the AMD, and/or communicating with one or more computing systems. For example, the AMD may include a monohormonal or bihormonal drug pump configured to administer one or more types of insulin and possibly a counter-regulator (e.g., glucagon or other medication that can reduce or address hypoglycemia). As another example, the AMD may include one or more alarm generators, transceivers, touchscreen controllers, display controllers, encryption modules, etc. In some examples, two or more of the modules or systems may be integrated into a single housing 502 (as shown in FIGS. 5A and 5B). In some examples, one or more modules may be individual modules contained in a separate housing that communicate with other modules and/or the main unit via wired or wireless communication links (e.g., Bluetooth). Modules contained in the AMD may include a communications module 602, a signal processing module 604, a therapy delivery module 606, a user interface module 608, and a control and computing module 610. In some embodiments, one or more modules may include one or more single-purpose or multi-purpose electronic systems. In some such examples, one or more electronic systems may perform procedures related to different features of the AMD. In some other embodiments, one or more modules may include non-transitory memory that stores machine-readable instructions and a processor that executes the instructions stored in the memory. The memory may be non-volatile memory, such as flash memory, a hard disk, or any other type of non-volatile memory. In some such examples, a module may include several procedures, each implemented based on a different instruction set.

The control and computing module 610 may include one or more processors 614, a main memory 616, storage 618, which may include one or more non-transitory and/or non-volatile memories, and an interface 612 that enables data and signal communication between systems within the control and computing module 610 and between the control and computing module and all other modules of the AMD. The main memory 616 and storage 618 may each be divided into two or more memory locations or segments. The main memory 616 may communicate with other components of the control and computing module 610 as well as other modules via the interface 612. Instructions may be sent to (e.g., from) the main memory, and the processor 614 may execute instructions communicated to it via 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. Main memory 616 may be any type of memory capable of storing instructions, communicating them to processor 614, and receiving instructions for execution from processor 614. Types of main memory include, but are not limited to, random access memory (RAM) and read-only memory (ROM). Processor 614 may be any type of general-purpose central processing unit (CPU). In some embodiments, the control and computation module may include two or more processors of any type, including, but not limited to, complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc. Storage 618 may be any type of computer storage capable of receiving data, storing data, and transmitting data to main memory 616 and possibly other modules of AMD 600. Types of storage 618 that may be used in control and computation system 610 include, but are not limited to, magnetic disk memory, optical disk memory, flash memory, etc. Interface 612 may include data transfer buses and electronic circuitry configured to support data exchange between different components within control and computing system 610. In some examples, interface 612 may also support the exchange of data and signals between other modules, as well as data exchange between any of the modules and control and computing module 610.

The signal processing module 604 may include multiple interconnected electronic modules for signal conditioning and conversion (e.g., A/D or ADC conversion and D/A or DAC conversion) configured to support communication and data exchange between different modules. For example, the signal processing module 604 may convert analog signals received from the communications module 602 and convert them to digital signals that can be transmitted to the control and computing module 610 (e.g., via interface 612). As another example, the signal processing module may receive digital control signals from the control and computing module 610 and convert them to analog signals that can be transmitted to the therapy delivery module 606 to, for example, control one or more infusion pumps included in the therapy delivery module 606.

In some embodiments, the therapy delivery module 606 may include one or more infusion pumps configured to deliver one or more medications (e.g., insulin or glucagon) to the patient 627. In some examples, the medications may be stored in one or more medication cartridges housed in the therapy module 606. In some examples, the therapy delivery module 606 may include electronic and mechanical components configured to control the infusion pumps based on signals received from the control and computing module 610 (e.g., via the signal processing module 604).

The user interface module 608 may include a display that shows various information about the AMD 600, such as the type of medication and delivery schedule, the status of the software, etc. The display can display graphic images and text using any display technology, including, but not limited to, OLED, LCD, or e-ink. In some embodiments, the AMD 600 may include a user interface (e.g., an alphanumeric pad) that allows a user to input information or interact with the AMD 600, such as to change settings on the AMD 600 and respond to requests for specific actions (e.g., software installation). The alphanumeric pad may include multiple keys with numeric, alphabetic, and symbolic characters. In different embodiments, the keys of the alphanumeric pad may be capacitive or mechanical. The user may be the patient 627 receiving the medication or treatment, or another user, such as a clinician or healthcare provider, or the patient's 627 parent or guardian. In some other embodiments, the AMD 600 may include a touchscreen display that generates output and also accepts input, allowing for two-way interaction between the user and the AMD 600. The touch screen display may be any input surface that displays graphic images and text and also registers the location of a touch on the input surface. The touch screen display may accept input via capacitive touch, resistive touch, or other touch technologies. The input surface of the touch screen display may register the location of a touch on the surface. In some examples, the touch screen display may register multiple touches at once. In some embodiments, the keypad may be a keypad display. For example, an alphanumeric pad containing user-selectable letters, numbers, and symbols may be displayed on the touch screen display. In some examples, the touch screen may present one or more user interface screens to the user that allow the user to change one or more treatment settings of the ambulatory medication device. In some examples, the user interface screen may include one or more parameter control elements. Additionally, the user interface screen may include one or more user input elements displayed on the screen that allow the user to interact with the AMD 600.

In some embodiments, communications 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 communications over one or more communications networks. In some examples, each transceiver may be configured to receive or transmit, via an antenna (e.g., an antenna chip), different types of signals based on different wireless standards. The transceivers may be configured to transmit signals over low power wide area networks (LWWANs),
In some examples, the transceiver may support communication with a wide area network (WAN), such as a cellular network transceiver enabling 3G, 4G, 4G-LTE, or 5G. Additionally, the transceiver may support communication with a wireless wide area network using a Narrowband Long-Term Evolution (NB-LTE), Narrowband Internet-of-Things (NB-IoT), or Long-Term Evolution machine type communications (LTM) standard.
The AMD 600 may support communication via a Long Term Evolution Machine Type Communication (LTE-MTC) communication connection. In some cases, the transceiver may support Wi-Fi® communication. In some examples, the transceiver may downconvert and upconvert baseband or data signals to and from wireless carrier signals. In some examples, the communications module may wirelessly exchange data between other components of the AMD 600 (e.g., a blood glucose sensor), mobile devices (e.g., smartphones, laptops, etc.), Wi-Fi networks, WLANs, wireless routers, cellular towers, Bluetooth devices, etc. The antenna may transmit and receive various types of wireless signals, including, but not limited to, Bluetooth, LTE, or 3G. In some examples, the communications module 602 may support direct end-to-end communication between the AMD 600 and a server or cloud network. In some examples, the AMD may communicate with an intermediate device (e.g., a smartphone or other mobile device, a personal computer, a notebook, etc.). In some embodiments, the AMD may include an eSIM card that stores information that may be used to identify and authenticate a mobile subscriber.
The IM card may enable the AMD to function as an IoT device capable of communicating over a network that supports communication with IoT devices. In other embodiments, the AMD may be configured to transmit data using a narrowband communication protocol such as 2G or EDGE. Using a cellular connection, the AMD 600 may initially pair with a mobile device, allowing real-time data access to the AMD 600 by a healthcare provider. In certain implementations, the AMD 600 may include a geolocation receiver or transceiver, such as a global positioning system (GPS) receiver. As previously mentioned, each AMD described herein may include one or more of the embodiments described with respect to other AMDs, unless otherwise specified.

Example Operation of an AMD In some embodiments, the AMD 600 (or AMD 100) may continuously, periodically, or intermittently receive information regarding one or more parameters correlated with the health status of a patient 627 (e.g., blood glucose level, blood glucose trend, heart rate, body movement indicators, etc.). This information may be encoded into a signal provided to the AMD 600 by a glucose level sensor 620 (e.g., a wearable biomedical sensor measuring an analyte in interstitial fluid), hereinafter referred to as a “patient sensor,” connected to the AMD 600 via a wired or wireless link (e.g., Bluetooth). In some examples, the signal transmitted by the patient sensor 620 may be received by the communications module 602 and transmitted to the signal processing module 604, which converts the signal into a machine-readable signal (e.g., a digital signal). In some examples, a second communications module may be included in the AMD 600 for communicating with the patient sensor 620. In some examples, the signal processed by the signal processing module 604 may be transmitted to the control and computation module 610, which may analyze the signal to determine whether a medication should be delivered to the patient 627. If it is determined that a medication should be administered to the patient, the control and computation module may determine the dosage and type of medication to administer based on the information received from the patient sensors 620 and transmit a dosage signal to the therapy delivery module 606 (e.g., directly or via the signal processing module 604) to initiate delivery of the medication to the patient (e.g., using an infusion pump of the therapy delivery module 606).

In some embodiments, one or more procedures within the control and processing module 610 may be executed by the processor 614 (or multiple processors) based on instructions provided by one or more software applications installed in one of the memories (e.g., main memory 616) of the control and processing module 610. These procedures include, but are not limited to, determining the need to deliver a medication, determining the type and required dose of a medication, determining the delivery rate during a treatment session, providing information (e.g., device status, next delivery time, level of a particular analyte in the patient's blood, etc.) via the user interface module 608, processing information received from patient sensors 620 via the user interface 608, etc. In some embodiments, a first software application may control the AMD 600 and may be installed in the main memory 616, and a second software application (e.g., a different version) may be stored in the storage 618. In some examples, the first and second software applications may both be installed in the main memory 616, but may be installed in different locations or segments. In some such examples, control of the device may be switched from the first software application to the second software application as needed.

In some embodiments, the AMD 600 is connected to a user or control and computing module 6
10 can deliver multiple types of selectable therapies. For example, AMD 600 may deliver a therapy to the user that injects insulin or a therapy to the user that injects glucagon. In some examples, the user interface may include options for the user to select the infusion of insulin, glucagon, or both insulin and glucagon. In other embodiments, other hormones, fluids, or therapies may be delivered. In some examples, a software application executed by control and calculation module 610 can determine the type of hormone that needs to be delivered based at least in part on information received from patient sensors 620.

7 illustrates various methods and links or communication paths that the AMD 702 may use to communicate (e.g., by establishing a connection) with a host computing system 704, for example, to obtain application updates, send and/or receive therapy reports, receive passcodes, receive control parameters, etc. In some examples, the host computing system 704 may be a server 706 or a computing system within a cloud computing network 708 that provides networking computing services (e.g., network storage, application hosting, and/or network processing services), or other networked computing environment. In some examples, the host computing system 704 may be part of a data center (e.g., a healthcare provider's data center).

In some embodiments, the AMD 600 can establish a connection (e.g., using the communications module 602) with the host computing system 704 through an intermediate device 710 (e.g., a smartphone or other mobile device, a personal computer, a notebook, etc.). In some such examples, the AMD 600 can receive application updates from a user's local device 710 (e.g., a clinical computer, a patient's home computer, a smartphone, etc.) that has obtained a copy of the application update from the host computing system, either directly or via the Internet 714. In some examples, the AMD 600 can communicate with the host computing system 704 via a local area network (LAN) and/or via a Wi-Fi connection. Alternatively, or in addition, the AMD 600 can establish a communications connection with the host computing system 704 via a wide area network (WAN) 716. In some examples, communications between the AMD 600 medical device and the cloud computing service may be encrypted.

In some embodiments, the AMD 600 can establish a direct end-to-end communication connection with the host computing system 704 over a wide area network (WAN) 716 (e.g., a cellular network). In some cases, the direct end-to-end communication connection may be a connection that does not involve a local device, a device accessible by a user or patient (other than the AMD 600), a Wi-Fi network, a short-range wireless link (e.g., Bluetooth), etc. In such cases, the direct end-to-end communication may pass through one or more wireless systems (e.g., receivers, transmitters, or antennas) of the WAN. In some examples, the host computing system 704 can establish the end-to-end connection by receiving a public key from the AMD 600. In some examples, the public and private keys stored on the host computing system 704 can be used to enable the host computing system 704 to decrypt data communications transmitted by the AMD 600. In some implementations, the host computing system 704 can 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 authorized to communicate with the host computing system 704 based at least in part on the device identifier. In some examples, the device identifier may be initially provided to the networked computing environment prior to provisioning the AMD 600 to a patient. For example, the device identifier may be initially provided to the networked computing environment as part of a manufacturing process for manufacturing the AMD 600. In some examples, the device identifier may include or be based on one or more of an Internet Protocol (IP) address, a Media Access Control (MAC) address, a serial number, or a patient identifier of a patient receiving treatment from the AMD 600. In some cases, the patient or user may establish or initiate a direct end-to-end data connection with the host computing system 704. In some cases, the direct end-to-end data connection may be initiated or established without any action by the patient or user. For example, the direct end-to-end data connection may be automatically established at a particular time and/or when the AMD 600 is in a particular location. In some cases, this automatic connection may occur using information provided to the AMD 600 at the time of manufacture, shipping, sale, or prescription to the patient. Alternatively, or in addition, the patient or other user may configure the AMD 600 to automatically connect to the host computing system 704 at a particular time and/or location. In some cases, the wide area network may include or be in communication with the Internet 714.

In some embodiments, the AMD 600 may be configured to communicate over a wide area network during manufacture or before being provided to a patient. For example, the manufacturer may register the AMD 600 with a wireless wide area network provider (e.g., T-Mobile or Verizon) and provide the AMD 600's International Mobile Equipment Identity (IMEI) number or serial number to the network provider. Additionally, fees may be negotiated between the manufacturer and the network provider, or between the patient's health insurance and the network provider. Similarly, fees may be paid by the manufacturer or health insurance provider, or other entity, without patient involvement. Thus, the patient's AMD 600 may be configured to communicate over a network provider's network without any action by the patient or user. In some cases, the patient may be responsible for obtaining wireless service to connect the AMD 600 to the wide area network 716 (e.g., a cellular network).

In some examples, the AMD 600 may be pre-registered or authenticated with the cloud service provider's computing network as part of the manufacturing process or before the AMD 600 is provided to the patient. This allows the AMD 600 to communicate with the cloud service provider's computing system over a wide area network from day one with no or minimal configuration by the subject. In some cases, a user, such as a healthcare provider, can register or associate the AMD 600 with a patient on the cloud service provider's computing network.

In some embodiments, AMD 600 may use a whitelist or authorization list that identifies, via a unique identifier (e.g., via IP address, MAC address, or URL), one or more authorized cloud servers or computing systems of cloud computing system 708 that AMD 600 is authorized to access. Restricting access to a set of authorized computing systems reduces the risk of a malicious actor gaining access to AMD 600. Additionally, in some cases, AMD 600 may include a blacklist or restriction list that identifies systems to which AMD 600 is not authorized to access. The blacklist may be updated as more restricted or unsafe websites, network-accessible systems, or computing systems are identified. Similarly, the whitelist may be updated over time as authorized systems are added or removed.

Additionally, the cloud computing service may have a whitelist or authorization list that specifies other computing systems (e.g., remote display systems) that are authorized to communicate with the AMD 600 and/or the cloud computing system 708 using unique identifiers. Furthermore, similar to the AMD 600, the cloud computing service may have a blacklist or restriction list that identifies AMDs or other computing devices that are not authorized to access the cloud computing service. An AMD may be added to the restriction list if it is decommissioned, damaged, or no longer owned by the patient. It may be desirable to remove an AMD's access to the cloud computing service to help protect the patient's private or personal data. Preferably, establishing a connection based on a whitelist can enhance the security of the communication link established between the AMD 600 and the cloud computing system 708 or other computing systems. In addition to identifiers identifying authorized computing systems for access by the AMD and/or authorized AMDs for access by the cloud or network computing service, the whitelist may include any information that can facilitate access to systems identified on the whitelist. For example, a whitelist may include access information (e.g., username, password, access code, account identifier, port identifier, shared secret, public key, etc.). It should be understood that a whitelist may include different information depending on whether the whitelist is publicly accessible, accessible only by the AMD, accessible by authorized users or devices, etc. For example, a publicly accessible whitelist or a whitelist accessible by more than one authorized system or user may not include a password or access code.

In some cases, AMD 600 may use a whitelist that identifies authorized cloud servers or computing systems, for example, of cloud computing system 708, via a unique identifier (e.g., via IP address, MAC address, or URL). In some examples, the cloud computing system may have a whitelist that specifies other computing systems (e.g., remote display systems) that are authorized to communicate with AMD 600 and/or cloud computing system 708 using unique identifiers. The whitelist may be stored in memory of AMD 600 and/or in memory of a trusted computing device accessible by AMD 600. A trusted computing device may include any computing device identified as trustworthy by the manufacturer of the AMD. Alternatively, or additionally, a trusted computing device may include any computing device identified as a trusted computing device by the patient or a user assisting the patient (e.g., a parent, guardian, healthcare provider) that is designated to store the whitelist. In some examples, the whitelist may be configured during manufacture of AMD 600. For example, the whitelist may be configured with connection information for establishing communications with one or more computing systems of the networked computing environment. In some examples, the AMD 600 may be configured to execute certain computer-executable instructions to obtain at least the addresses of the computing systems from the whitelist and to establish direct end-to-end data connections to the computing systems (e.g., computing systems in the networked computing environment) over a wireless wide area network using the addresses. In some embodiments, the AMD 600 may be configured to execute certain computer-executable instructions to receive at least public keys from the computing systems of the networked computing environment.

Mobile Medical Device Application Updates Computers or software applications are often updated after their release. Similarly, in some cases, software or applications used to control or provide functionality in a medical device (e.g., an automated blood glucose control system or other AMD) can be updated. In some cases, applications are updated to patch bugs or vulnerabilities. In some cases, applications are updated or replaced with new versions to introduce new features, improve existing features, or provide access to newly purchased, licensed, or otherwise acquired features. Regardless of the reason, applications are often shut down or not running while they are being updated. For most applications, there is minimal or no harm in shutting down or not running the application while it is being updated or otherwise replaced. For example, it is not critical that a video game, word processing, or edutainment application not be running while it is being updated.

However, ceasing execution of an application on a mobile medical device (AMD) while it is being updated or replaced with a new version of the application can be inconvenient, harmful, or even life-threatening. If a patient receiving treatment from the mobile medical device experiences a condition in which treatment is desired or required while the AMD's application or control software is being updated or replaced, harm to the patient could result. For example, assume the AMD is an insulin pump, such as one that may be used by a patient with type 1 diabetes. If the insulin pump becomes inoperable due to the application update process, which occurs when the patient's blood glucose level exceeds a set point or target range, the user may not receive a needed insulin bolus from the AMD. Therefore, it is desirable to reduce or eliminate interruptions to patient care or treatment when updating applications, such as the mobile medical device's control software.

In some embodiments, the AMD includes a computer-implemented method for updating applications running on the AMD without interrupting or causing minimal interruption to the patient or the therapy provided to the patient by the AMD. The method may generally be executed by a hardware processor (e.g., a controller, etc.) based on an instruction set included in the AMD and stored, for example, in non-transitory memory of the AMD. Application updates may include binary executable files that may be executed by various processors of the AMD. Application updates may be new versions of applications, replacement or alternative applications, or application patches. Additionally, application updates may add or remove functionality from versions of applications installed on the AMD. In some examples, application updates may be older versions of applications that have been used by instances of the AMD for more than a threshold period and have experienced less than a threshold of failures. The applications updated on the AMD may currently be running on the mobile medical device or may be running in the future. In some examples,

Application updates can be stored on one or more host computing systems. In some cases, application updates may be pushed to the host computing system by the company that manages or manufactures the mobile medical device, or by another software company authorized by the device manufacturer or licensee. In some cases, the host computing system includes a server computing device, a cloud computing device, a healthcare provider computing device, an AMD manufacturer computing device, an application server, or other network-accessible computing device or system. In some cases, application updates may be stored on a local computing device, such as a patient's local computing device (e.g., a smartphone, laptop, or personal computer).

FIG. 8 is a flow diagram illustrating an example of a computer-implemented method that may be used by AMD 600 to detect and download application updates from a host computing system or other computer-readable medium on which a copy of the application update may be stored. In some examples, AMD 600 may communicate directly with the host computing system. In some cases, AMD 600 may communicate with a proxy or other system to determine the availability of application updates or to obtain application updates. In some cases, application updates may be obtained from a content delivery network (CDN) or a cache server.

In block 802, an AMD 600, such as a drug delivery device or drug 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. In some embodiments, the indication may be a determination made by a software or hardware module included in the AMD 600. For example, the AMD 600 may access a particular host computing system (e.g., using its communications module) to determine whether an update is available based on a set of update trigger conditions stored in the AMD 600's memory. The set of update trigger conditions may include any type of trigger condition that causes the AMD 600 to determine whether a software update is available and/or update applications running on the AMD 600. In some cases, the set of update trigger conditions may be defined/modified by a user and/or received by the AMD 600 from a host computing system. For example, the update trigger conditions may push the AMD 600 to periodically search for updates at a time interval set by a user or received from the host computing system. In other words, the 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. For example, the update availability check trigger may be a user command, a change of medication in the mobile medical device, connecting to a particular network (e.g., connecting to a Wi-Fi network using a wireless transceiver), an estimated time of arrival, the occurrence of a failure, the occurrence of a particular condition in the AMD, or any other type of trigger. In some examples, the indication that an application update is available includes an indicator of whether the application update corresponds to a first application version or a second application version of the application. In some examples, the AMD 600 may access an update server to determine whether an application update exists and, in response to accessing the update server, receive an indication that an application update is available. In some cases, the trigger for connecting to the update server to determine the availability of an application update may include detecting a failure of a currently running application or an indication of a change in the authorized functionality that the user or patient is authorized to access on the AMD 600.

In some examples, the host computing system may query or access the AMD 600 to determine the installed software version and/or hardware configuration of the application to determine the mobile medical device's eligibility for a software upgrade. In some cases, eligibility for a software upgrade may be based at least in part on a license or warranty. A serial number, model number, and/or software version may be used to determine eligibility for an application update (e.g., a software upgrade). In some embodiments, eligibility for an application update may be determined based on the device's geographic location 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). In various embodiments, the mobile medical device may have a transceiver and antenna that provide the device with GPS, text or picture messaging, calling, and data transfer capabilities. In some cases, application updates may be provided in limited releases to test groups of various sizes, e.g., 1-100, 1-1000, or 1-10,000 users. Additionally, there may be a phased rollout of application updates to different user groups. In some embodiments, the AMD 600 may respond to the upgrade entitlement request by transmitting an identification of the version of the application or a model identification of the AMD 600 or a manufacturing date of the AMD 600 to the host computing system.

If the AMD 600 determines in block 802 that an update is available for an application (e.g., an application that may be running on the AMD 600), then in block 804 the AMD 600 may establish a communications connection with a host computing system that hosts the update to the application. Such a connection may be established, for example, via one or more links or methods described above with reference to FIG. 7. For example, the AMD 600 may communicate with the cloud 708 or server 706 using a local area network 712, the Internet 714, or a wide area network 716. In some embodiments, a healthcare provider system may push updates to the AMD 600. In some examples, the communications connection via the wide area network 716 may be a direct end-to-end communications connection. In some examples, the communications connection with the host computing system may be established via an intermediate device 710 (e.g., a user's or patient's personal computing device).

In some examples, the AMD 600 can establish a direct end-to-end data connection to a host computing system via a wireless wide area network (WAN). The direct end-to-end data connection may include a Narrowband Long Term Evolution (NB-LTE) connection, a 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 direct connection between the AMD 600 and the host computing system without an intermediate system or computing device within the AMD 600's local area network being involved in the communication. The direct end-to-end data connection may include routing of data or connections through network hardware, base stations, or other devices included in a wide area network, such as the Internet. However, other computing devices within the local area network that includes the AMD 600 may be omitted. Thus, for example, the AMD 600 does not communicate with smartphones, laptops, smart appliances, or other devices within the local area network of a user or patient using the AMD 600. In some cases, AMD 600 may communicate with an intermediate system to obtain application updates. For example, application updates may be downloaded to a local system (e.g., a user's laptop or smartphone) and then provided to AMD 600 via a local area network, a USB connection, or a near-field communication technology (e.g., Bluetooth, ZigBee, LoRa, etc.).

Once the communication connection is established in block 804, the AMD 600 may download the application update from the host computing system via the communication connection in block 806. In some examples, the AMD 600 may download an image of the application update from the host computing system. While the application update is being downloaded, the existing version of the application on the mobile medical device may continue to run. Thus, there may be little or no interruption to the therapy provided by the AMD 600 while the application update is being obtained by the AMD 600.

In some examples, the AMD 600 may be linked to an intermediate device 710 (e.g., a mobile device) via a communications link (e.g., Bluetooth, Wi-Fi, NFC, or other wireless or wired communications means). In some examples, the AMD 600 may include a SIM card or electronic SIM (eSIM) card that stores information for identifying and authenticating the mobile intermediate device. The eSIM card enables the AMD 600 to function as an IoT device capable of communicating or transmitting data over a network supporting communication with IoT devices. Additionally, the mobile medical device may be configured to transmit data over a narrowband communications protocol such as 2G or EDGE, NB-LTE, 5G, etc. The intermediate device 710 may also communicate with the cloud 708, server 706, etc. In some such examples, software updates may be initially downloaded by the intermediate device communicating with the AMD 600 periodically or upon pairing. The intermediate device can determine whether the AMD 600 is eligible for a software update based at least in part on the serial number, the manufacturing date, the current software version, the model number, the latest software image on the cloud 708 or the server 706, etc. If the AMD 600 is eligible for a software upgrade, the intermediate device can download the target image and transfer the image to the AMD 600.

In some examples, the application or applications include one of a first application version including a first feature set or a second application version including a second feature set. In some cases, 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. For example, one of the application versions may have a less cluttered user interface compared to the other application version. As another example, one of the application versions may support a meal controller, while the other application version may not. In some examples, the AMD 600 may download a first application update corresponding to the first application version or a second application update corresponding to the second application version. In some examples, 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.

Once the application update is obtained, at decision block 808, AMD 600 may perform one or more operations to verify (e.g., using its control and computation module 610) that the downloaded copy of the application update is complete and/or uncorrupted. To determine that the downloaded application update is complete and/or uncorrupted, AMD 600 may calculate a hash or checksum value from the downloaded application update and 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, it may be determined that the download is complete and/or uncorrupted. Furthermore, AMD 600 may use a checksum, tag, payload size, or any other method to verify that the application update download is complete and uncorrupted. If it is determined that the download is corrupted and/or not completely downloaded, 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 the user of the failed attempt to download or update the application. If the download is determined to be complete and uncorrupted, the AMD 600 may proceed to an installation step 810, where the application update may be installed on the AMD 600 without interrupting any ongoing or future therapy sessions.

Figures 9-11 are flow diagrams illustrating an example computer-implemented method that may be used by AMD 600 to install downloaded application updates without interrupting the care provided to the patient.

In the exemplary method shown in FIG. 9 , in block 902, the AMD 600 verifies that an uncorrupted copy of an application update was successfully downloaded (e.g., using the procedure described above with reference to FIG. 8 ). In block 904, the AMD 600 (e.g., the control and compute module (CCM) 610 of the AMD 600) may determine the amount of time required to install the application update. In some examples, the installation time may be the execution time for executing a process for installing the downloaded copy of the application update. Alternatively, or in addition, the installation time may be the amount of time to execute the installation process. In some cases, the time determined in block 904 is an estimated installation time. General-purpose computing systems can run any number or types of applications, and it is unknown which applications a particular user may decide to run. However, AMDs are typically dedicated and it is generally known what applications they will run. In many cases, the only applications that are run may be control software or user interface software. Therefore, the estimated installation time is typically close to the actual installation time. However, variations in the manufacturing of electronic devices or natural degradation of components (e.g., memory) over time may result in some small variations in the installation time usage. Therefore, application installation times may be buffered or padded, in some cases, to ensure that the estimated or determined installation time is not shorter than the actual installation time of the application update.

The installation time may be determined by the CCM 610 based on data or metadata included in the downloaded application update. For example, the application update may include a file (e.g., a text file or a configuration file) containing the installation time or an estimate thereof. The installation time may be determined by the mobile medical device manufacturer or the application update publisher. For example, a software update developer may average installation times across several test devices to determine the installation time metadata to provide with the software update. General-purpose computers have a wide variety of configurations, and their performance may vary depending on the application being run at a particular time. Therefore, determining the installation time of an application based on measuring the installation time on a test device is typically unreliable. However, because the AMD 600 is often a dedicated device designed to perform a specific function (e.g., delivering insulin to a patient), the installation time determined during testing by the manufacturer may often be a reliable determination of the installation time on a patient's mobile medical device. Alternatively or additionally, the installation time of an application update may be determined or estimated based on the size of the application update (e.g., by the AMD 600 manufacturer or the CCM 610). In some cases, the provided or estimated installation time may include a buffer. In other words, an additional amount of time may be added to the installation time to account for variations in the operating conditions of the mobile medical device or inaccuracies in the estimated installation time.

At block 906, the AMD may notify the user that an application update is available for installation and wait for a trigger signal to begin the installation process. In some examples, the AMD 600 may notify the user via a user interface (e.g., a touch screen display) that the update has been downloaded and is ready for installation. The notification may include information about the update, such as the installation time and what features have been fixed or added, or what bugs have been patched or fixed.

At decision block 908, the AMD 600 may determine whether an installation trigger has been received. If an installation trigger has not been received, the 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 confirmation that the application has been successfully downloaded. That is, the application may be automatically installed once a successful application download has been confirmed. Alternatively, or in addition, the installation trigger may be an installation command received based on a user or patient interaction with a user interface that is part of or in communication with the mobile medical device. In some such examples, the AMD 600 may provide the user with the option to select the time at which the application will be installed and/or may allow the user to request a reminder to install the application update at a later time. In some examples, the installation trigger may include 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 the detection of a failure during the execution of an application currently running or controlling on the AMD.

In block 910, the AMD 600 determines whether a therapy is currently being administered to the patient. If the AMD 600 determines that a therapy is not currently being administered, the process proceeds to block 914. If the AMD 600 determines that a therapy is currently being administered, the system proceeds to block 912, where it waits until the therapy session is complete and delays installation of the application or application update until at least the therapy session or therapy administration is complete. In some cases, the AMD 600 may continue to check whether an ongoing therapy is occurring. Continuing therapy may include at least administering medication. However, other operations may be included as part of the ongoing therapy, such as performing one or more physiological parameter measurements. Once the current therapy session is completed or is determined to be completed, the process may proceed to block 914.

In block 914, the AMD 600 may determine the time remaining or remaining until the next scheduled or expected therapy delivery time (e.g., during which medication such as insulin is delivered to the patient). In some cases, the determination of the next time therapy should be delivered may be an estimate based on past delivery of therapy, the patient's current state (e.g., if the patient's glucose level is in the center of the desired range, the next therapy delivery time may be estimated to be further off than if the glucose level is at the edge of the desired range), and/or instructions provided by the user or patient (e.g., an indication that the user is about to eat, exercise, or go to bed). Alternatively or additionally, the determination of the next time therapy should be delivered (e.g., the next scheduled administration period) may be based on the scheduled delivery of therapy (e.g., every 5 minutes or every hour, etc.). Further, in some cases, the determination of the next therapy delivery period may be determined by querying the user (e.g., the patient). In some examples, after determining that a resume condition has occurred as discussed herein, a dose control signal may be generated for the next scheduled administration period. In some examples, a dose control signal may be generated immediately or shortly after determining that a resume condition has occurred.

As mentioned above, it is desirable to prevent interruptions in therapy during the application update process. Thus, after the next therapy time is determined in block 914, the AMD 600 may, in decision block 916, determine an estimated installation time or compare it to the estimated next therapy delivery time to determine whether installation of the application update can be completed before the next therapy delivery to the patient. If the AMD 600 determines that the time remaining until the next therapy session is sufficiently longer than the determined time to complete installation (e.g., the length of installation time, or the estimated installation time and a minimum additional time buffer), the process proceeds to block 918, and installation of the application update may begin. In some examples, the determined time until 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 begin. The threshold value may vary for different application updates and/or types of therapy to be administered during the next scheduled or anticipated therapy session. If, in decision block 916, it is determined that application installation cannot be completed before the next therapy delivery (or the next therapy will not be longer than its estimated installation time by the threshold value), installation of the application may be delayed regardless of receipt of a trigger. In this case, the process returns to block 914, where the AMD 600 waits for the next treatment to complete and can then determine a new treatment time. This process may be repeated until the AMD 600 determines that the update can be installed without interrupting expected or scheduled treatment delivery by the AMD. In some examples, a new determination may be made before the completion of the next treatment to determine whether installation can be completed before the next treatment time after the next treatment time. In some cases, if the AMD determines at decision block 916 that the installation process will not be completed before the next treatment time, the AMD may output a warning for display to the user.

In some cases, a time when an application can be installed without interrupting treatment may not be identified. In some such cases, a user (e.g., a clinician or other healthcare provider, or a patient) may be provided with a warning that an application update is available and/or that the application update cannot be installed without interrupting treatment. The user may be provided with options regarding whether to allow the update and/or when to install the application update. The options may include presenting the user with an estimated installation time that allows the user to schedule the application update when treatment interruption may be minimal or when an alternative source of treatment (e.g., injection therapy) is available.

FIG. 10 is a flow diagram illustrating an example of a computer-implemented method that may be used by the AMD 600 to install a second application that is an update to a first application running on the AMD 600 without interrupting the treatment provided to the patient. The AMD may identify and download the second application update using the process described with reference to FIG. 8. In some cases, 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. In some examples, the second application may be a version of the first application that has been determined to operate without impairment with a threshold degree of certainty.

At block 1002, the AMD 600 verifies that an uncorrupted copy of the second application was successfully downloaded. In some embodiments, block 1002 may include one or more of the embodiments described above with respect to block 808 of FIG. 8 and/or block 902 of FIG. 9. At block 1004, the AMD 6
The controller may initiate the installation process of the second application without interrupting the execution of the first application. In some examples, the application update may be installed in a memory location or a separate area of volatile memory that is different from the memory location or area of volatile memory where the original application (or the current version of the application) is installed and executed. In some embodiments, the second application may execute in a second execution space that is separate from the first execution space. The separate execution spaces may be in separate areas of volatile and/or non-volatile memory. For example, the first and second applications may be stored in separate areas of non-volatile memory. Furthermore, the first and second applications may each be allocated separate areas of volatile memory for execution. The separate areas of volatile memory can function as separate sandboxes that prevent interference between the execution of the first application and the execution of the second application. In some embodiments, the first application may be executed by the first controller, and the second application may be executed by the second controller.

At block 1006, the AMD 600 may confirm successful installation of the second application and wait for a trigger signal. At block 1008, the AMD 600 may send a notification to the user via the AMD's user interface (e.g., a touchscreen display) to execute the second application and request a trigger to switch control of the AMD 600 from the first application to the second application. At decision block 1010, the AMD 600 may determine whether a trigger has been received. In some examples, the AMD 600 may determine the amount of time required to switch control of the AMD from the first application to the second application. In some such examples, the notification may include information regarding the update and the time required to switch between applications. In some examples, the trigger may be a user command received based on interaction by the user or patient with a user interface that is part of or in communication with the AMD. In some examples, the trigger may be confirmation of successful installation of the second application or detection of a fault in the execution of the first application by the AMD 600. In some examples, the trigger may be an indication of the availability of a second application or the detection of an application failure associated with the execution of the first application. Similar to the process described in FIG. 9, the trigger may be based at least in part on whether a therapy is currently being administered and/or the timing of a subsequent therapy to be delivered.

If, at decision block 1010, the AMD 600 determines that a trigger has not been received, the process returns 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. If, at decision block 1010, it is determined that a trigger has been received, then, at block 1012, the AMD 600 may check whether a therapy session is in progress. If the AMD 600 determines that therapy is currently being administered, the process proceeds to block 1014, where the AMD 600 waits until 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. Block 1012 may include one or more of the embodiments described above with respect to block 910.

In block 1016, the AMD 600 determines the time or time remaining until the next treatment session. In some cases, the AMD 600 can determine a patient's condition based at least in part on measurements of the patient's physiological parameters and determine the next treatment delivery time based at least in part on the patient's condition.
The next treatment delivery time may be determined based at least in part on a treatment delivery schedule stored in MD 600. Block 1016 may include one or more of the embodiments described above with respect to block 914.

At decision block 1018, the AMD 600 determines whether the time remaining until the next therapy delivery session is greater than the set threshold time or threshold times. Decision block 1018 may include one or more of the embodiments described with respect to block 916. If at decision block 1018 it is determined that the time remaining until the next therapy delivery session is greater than the set threshold time or threshold times, the process proceeds to block 1020, where execution of the second application is initiated and execution of the first application is stopped. At block 1020, the AMD 600 may switch control of the AMD 600 to the second application. In some examples, at block 1020, the AMD 600 may switch control of one or more functions of the AMD 600 from the first application to the second application. In some such examples, one or more functions of the AMD 600 may be under the control of the first application. In some examples, at least control of the therapy delivery module 606 of the AMD 600 may be switched to the second application.

If, at decision block 1018, it is determined that the time remaining until the next therapy delivery session is less than the set threshold time, the process returns to block 1016, where the AMD 600 determines the next therapy delivery time. In some examples, the set threshold time may be determined by the CCM based at least in part on the time required to execute the second application and stop the first application. In some examples, the set threshold time may be received from a host computing system. In some examples, the estimated next therapy delivery time may be compared to the set threshold time to determine whether a switch from the first application to the second application can be performed without disrupting the next therapy delivery session.

In some embodiments, AMD 600 may receive an indication that a third application is available for download. In some such examples, AMD 600 may download the third application using the steps and procedures described with respect to the flow diagram of FIG. 8 and, beginning at block 1002, switch control of the AMD from the second application to the third application using the steps and procedures described with respect to the flow diagram of FIG. 10. In some examples, the third application may be an update to the first application that addresses an application failure of the first or second application.

In some examples, once block 902 or 1002 confirms that an uncorrupted copy of the application update has been successfully downloaded, the AMD 600 may notify the user (e.g., via a user interface) and wait for a trigger signal. Once the trigger is received, the AMD 600 begins the installation process of the downloaded copy of the application update without interrupting the therapy provided by the portable AMD 600. In some examples, once a new application is installed, patient or user approval may be required to upgrade the application. In these examples, once approval is received, the application update is transferred to main memory where it executes and may control the AMD 600 or a subset of the AMD 600's operations. In some cases, the current configuration of the AMD 600 may be stored in the AMD 600's memory before the application update is installed or before control of the AMD 600 switches to the newly installed application update.

In some embodiments, the performance of an application update may be tested before switching control of the AMD 600 to the application update. FIG. 11 illustrates an exemplary method that may be used in one or more such embodiments. The AMD may identify and download a second application that is an update to the first application downloaded using the process described with reference to FIG. 8. In some embodiments, 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 of the first application. In some cases, the first application may 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. In some examples, the first feature set may differ from the second feature set but may include at least one feature included in the second feature set. In some examples, the AMD 600 may download a specific version of the second application that corresponds to a specific version of the first application. For example, there may be two versions of the first application. The first version of the first application may be for a monohormone pump capable of administering insulin. The second version of the first application may be for a bihormonal pump capable of administering insulin and a counterregulator. If the AMD 600 is configured as a monohormonal drug pump, the AMD 600 may download and/or install a first version of the second application corresponding to the first version of the first application. Alternatively, if the AMD 600 is configured as a bihormonal drug pump, the AMD 600 may download and/or install a second version of the second application corresponding to the second version of the first application. Thus, depending on the version of the first application installed on the AMD 600, 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. Although described as two versions, it should be understood that there may be more versions of the application, and the AMD 600 may install updates based on the installed version of the application. Additionally, in some cases, the AMD 600 may install different versions of an application to enable or unlock new features (or in some cases, to remove features, such as when a malfunction is discovered in a particular feature).

In block 1102, the AMD 600 verifies that an uncorrupted copy of the second application was successfully downloaded. In some embodiments, block 1102 may include one or more of the embodiments described above with respect to block 808 of FIG. 8 and/or block 902 of FIG. 9. Then, in block 1104, the AMD 600 may install the downloaded copy of the second application without interrupting the therapy provided to the patient by the AMD 600. In some cases, the second application may be installed in a memory space in the AMD 600's memory that is separate from the location of the first application in memory.

At block 1106, the AMD 600 executes the installed second application without interrupting the execution of the first application and, therefore, the treatment that may be provided to the patient by the mobile medical device using the first application. In some examples, the second application update may be installed in a portion of a storage space (e.g., a separate execution space or separate memory) separate from the portion where the first application is installed and running. In some examples, the AMD 600 may execute the second application using a processor separate from the processor that executes the first application. In some examples, the AMD 600 may execute the second application in an execution space separate from the execution space used to execute the first application. In some examples, the first application may be executed by a first controller and the second application by a second controller.

At block 1108, the AMD 600 may determine that a minimum set of operating conditions is met by the second application. In some embodiments, the minimum set of operating conditions may be related to maintaining therapy provided to the patient by the mobile medical device. In some example embodiments, determining that the minimum set of operating conditions is met may include determining that the AMD 600 is not currently administering medication, is below a threshold probability of administering medication within a threshold time period, or recently administered medication within a threshold time period.

At decision block 1110, the AMD 600 determines whether the second application satisfies a minimum set of operating parameters. If it is determined that the minimum set of operating conditions is not met by the second application, the AMD 600 may wait a period of time and then repeat the process associated with decision block 1110. In some cases, if the second application does not meet the minimum set of operating conditions, the AMD 600 may proceed to block 1112, wait for an indication that a third application is available, and repeat the above procedure to evaluate the performance of the third application. If the AMD 600 determines at decision block 1110 that the minimum set of operating conditions is met by the second application, then at decision block 1114, the AMD may check whether therapy is being delivered to the patient (e.g., medication is being administered to the patient). If it is determined that therapy is not currently being delivered to the patient, then at block 1118, the AMD 600 may switch control of the AMD from the first application to the second application. If it is determined in block 1114 that therapy is currently being provided to the patient, the process proceeds to block 1116, where the AMD 600 waits until the therapy delivery session is complete. Then, the process proceeds to block 1118, where the AMD 600 switches control of the AMD 600 from the first application to the second application. In some embodiments, the AMD 600 may switch control of the AMD 600 from the first application to the second application by generating a dose control signal using the second application. In some examples, using the second application, the AMD 600 may determine a dose of a medication to be infused into the patient for the purpose of controlling the patient's blood glucose based at least in part on a glucose level signal obtained from a blood glucose sensor. The dose of the medication may be determined automatically and/or autonomously. The AMD 600 may then provide the dose control signal generated using the second application to a medication delivery interface (e.g., a medication delivery interface of the therapy delivery module 606), which injects the medication into the patient.

In some cases, the AMD may be updated (or downgraded) to add (or remove) functionality to the mobile medical device. For example, the mobile medical device may be or be configured as a monohormonal drug pump that provides a single medication, such as providing only insulin therapy. At some point, the mobile medical device may be upgraded to include bihormonal control (e.g., to provide both insulin therapy and insulin regulator (e.g., glucagon) therapy). The upgrade may be based on newly available functionality and/or a decision by the user to purchase or otherwise acquire additional functionality. Similarly, the user may choose to downgrade therapy from bihormonal therapy to insulin-only therapy. Alternatively, the upgrade or downgrade may occur based on medication availability. In some examples, a first update may be a first application version that includes a first set of functionality (e.g., providing insulin therapy), and a second update may be a second application version that includes a second set of functionality (e.g., providing both insulin therapy and glucagon therapy). In some such examples, the first set of functionality may include a subset of the second set of functionality. In some examples, the first set of features may include a set of features that partially overlap with the second set of features.

In some examples, a computer-implemented method may be used by the AMD 600 to detect, download, and install an update to an application running on the AMD 600, the update including either a first application version including a first feature set or a second application version including a second feature set. In some examples, the first feature set may include a set of features that partially overlap with the second feature set. The AMD 600 may receive an indication of the availability of the application update, download the application update, and verify that an uncorrupted image of the application update was successfully downloaded (e.g., using the procedure described above with reference to FIG. 8). The AMD 600 may then initiate an application update image installation process without interrupting execution of the application. In some examples, the indication received by the AMD 600 (block 802 of FIG. 8) may include information regarding the application update being an update to the first application version or the second application version. In some such examples, the AMD 600 may determine the version of the application update and download the application update image based on the determined version.

In some embodiments, a downloaded application update may be installed in a separate portion of the storage space (e.g., a separate execution space or separate memory) from the currently running version of the application. Once application installation is complete and successful installation of the application is confirmed, the active version of the application can be switched. For example, control of the AMD 600 can be provided to the updated application, and the previously running application can be stopped or terminated. The old application can then be deleted or kept as a backup. Determining when to switch to the active version of the application can follow a similar process as described above for identifying the next treatment delivery time and selecting a time to switch the active version of the application when there is no interruption in the treatment provided by the AMD 600.

In some embodiments, the AMD 600 may be configured to store multiple instances of an application (e.g., AMD control software or a control application for a mobile medical device). For example, the AMD 600 may have a current, or first, version of the application installed in a first memory location (e.g., in main memory 616) and running, e.g., to control therapy provided to a patient. Additionally, the mobile medical device may include an updated, or second, version of the application installed in a second memory location (e.g., in main memory 616). The second version update may be downloaded and installed (e.g., prior to detection of a fault). In such an embodiment, if a fault is detected during execution of the first version of the application, the AMD 600 may begin executing the second version of the application and then switch control of the AMD 600 to the second version of the application to maintain therapy for the patient.

In some examples, a second application update or second version of an application installed on AMD 600 may be older than a first application or first version of the application. In some cases, the second or older version of the application may be a version of the application that has a track record of stability and reliability. In contrast, the first application, or a newer application, may have been released too recently to determine whether it is reliable or functions as desired. In some such examples, AMD 600 may revert to a second version of the application if a failure is detected in the first version of the application.

In some cases, the AMD 600 may revert to an older, stable version of the application until a third version of the application is available that fixes the application fault in the first version of the application. FIG. 12 presents a flowchart of one embodiment of a process for switching from a faulty application to a known, trusted version of the application until the application fault in the original application can be patched with an application update (e.g., a third version of the application). At block 1202, the AMD 600 detects the application fault while the first version of the application is running. In some examples, the AMD 600 may send an indication of the application fault to the manufacturer's computing device or a maintenance service for the mobile medical device. In some examples, the AMD 600 may send an alert to a user indicating that an application fault has occurred. Sending the alert to a user may include outputting an alert on a display, sending an alert to the user's account or device, generating an audio or visual alert, or any other type of alert.

At block 1204, the AMD 600 may switch 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. Alternatively or additionally, the second version of the application may be a standby or backup version of the application stored on 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 usage and/or testing history. At block 1206, the AMD 600 may establish a communications connection with a host computing system configured to host and download a third application update (block 1208). The third version of the application update may be a new version, a version previous to the first version, an update to the first application that addresses a detected application fault, or an older version that meets criteria for classification as a "safe version" (e.g., less than a threshold number or percentage of faults over a minimum period of time). The second version (installed on the device) can control the AMD without interrupting therapy while the third version is downloaded and installed (1208). Once the AMD verifies that the third version has been downloaded and that the downloaded copy is not corrupted, the AMD 600 can begin the installation process of the downloaded copy of the third application and switch control of the AMD 600 from the second version of the application to the third version of the application without interrupting therapy delivery to the patient by the AMD (block 1210). In various embodiments, the operations and processes described with respect to FIG. 12 may be performed by the control and computation module (CMM) 610 of the AMD 600.

In yet other embodiments, a "safe version" of the application may have been installed on the AMD 600 prior to the detection of the fault. A safe version or safe copy of the application may include a version of the application that has been used by an instance of a mobile medical device for more than a threshold period of time and has experienced fewer than a threshold number of faults. For example, a safe version of the application may be a two-year version of the application that has been shown to experience fewer than a threshold number of faults over a two-year period. This safe version of the application may have fewer features than the first or second version of the application. However, if a fault is detected while the first or second version of the application is running, the AMD 600 may switch control of the device to the safe version of the application to maintain treatment for the patient.

In some cases, if a failure is detected during installation or execution of an updated version of an application, the AMD 600 may revert to the current version or a safe version installed on the AMD 600.

In some embodiments, when a failure is detected during execution of a first version of the application, the AMD 600 may be triggered to establish a communications connection with the host computing system and retrieve a second version of the application. In these examples, the AMD may revert to a safe version (installed on the device) while downloading and installing the second version without interrupting treatment.

FIG. 13 is a flow diagram illustrating yet another example of a method for responding to fault detection by the AMD 600. In this example, if an application failure is detected during execution of a first version of an application at block 1302, the AMD 600 may access a second version of the application in main memory 616 or in the AMD 600's storage at block 1304. If it is determined that the second version has already been downloaded, the AMD 600 may determine at block 1306 whether the second version of the application is installed in a memory location and whether it is ready to execute. If it is determined at block 1306 that the second version of the application is installed, the AMD 600 may switch control of the AMD 600 to the second version of the application at block 1308. If the AMD 600 determines at block 1306 that the second version is present in memory but not installed, the process proceeds to block 1316, where control of the AMD 600 is switched to a safe version 1316 that may already be installed. At block 1318, the ethAMD 600 may begin installing the second version. Once installation of the second version is complete, the process proceeds to block 1308, where the AMD 600 may switch control of the AMD 600 from the secure version of the application to the second version of the application. In some embodiments, after control of the AMD 600 has switched to the second version of the application (block 1308), the AMD 600 may search for a third version of the application, which may be an update to the previously downloaded second version, at block 1310. If a third version is found, the AMD 600 may download and install the third version of the application at block 1312 and switch control of the AMD 600 to the third version (block 1314). If the AMD 600 cannot find the second version of the application in a memory or storage location at block 1304, it switches control of the AMD 600 to a secure version of the application, which may be installed in a memory location (e.g., main memory or storage) (block 1320), and searches for the 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 control of the device to the third version (block 1314).

In some embodiments, when an application fault is detected in an application running on AMD 600, AMD 600 may send an indication of the application fault to a host computing system of the mobile medical device manufacturer or maintenance service. In some other embodiments, AMD 600 may notify a user when an application failure occurs via a user interface on AMD 600 or a user interface in communication with AMD 600.

In some of the above examples, when a software update is installed, the AMD 600 may provide the option to preserve the user's configuration or profile data. For example, the software update should not change the patient's status data (patient weight, CGMid, meal portion equals meal portion).

In various examples, the application update may be pushed to a dedicated memory location within the CCM 610 of the AMD 600 before being transferred to an executable memory location (e.g., main memory) for security checks. In some examples, the healthcare provider system or the AMD may check the version of the application update against the current version. In some such examples, an alert may be sent to the user or patient with information about the differences between the current application and the application update.

Direct Networked Medical Device Communication and Remote Viewing. Ambulatory medical devices (AMDs), such as ambulatory medication devices (e.g., blood glucose control systems, insulin pumps (e.g., monohormonal pumps), or bihormonal pumps including insulin and counterregulators), pacemakers, or any type of medical device that can be connected to a patient to provide therapy to the patient, can generate a significant amount of data (therapy data) regarding the therapy provided to the patient. This therapy data can be useful for patients, healthcare providers, or other users (e.g., parents or guardians) to actively manage the patient's health condition. For example, therapy data can be useful for determining whether modifications to therapy are desirable or for verifying that the intended therapy is being delivered at the appropriate time. In some cases, therapy data can be used to generate alerts regarding the patient's health condition if the therapy data indicates that the patient's health condition requires immediate or urgent attention.

Various aspects of accessing therapy data or other types of data stored in the memory of an AMD require appropriate management to provide uninterrupted, secure, and easy access to authorized users. As described above, procedures and tasks performed by the AMD, including those related to data transfer management, may be associated with specific computer-executable instructions stored in and executed by the control and computation module (CCM) 610 of the AMD 600. Thus, different AMD configurations used for various data transfer management tasks may result in different instructions being executed by the CCM 610 of the AMD 600.

Accessing data from an AMD can be problematic in some cases. For example, accessing the data may require the user to connect the AMD to a computer and upload the data. This places a burden on the user to remember to connect the AMD. Furthermore, the patient may not be receiving treatment from the mobile medical device during periods when the device is connected to the computer. In some cases, the patient may not be able to connect the device to the computer (e.g., if the AMD is not within range of a local device) and may not have someone available to assist the patient. Therefore, a direct end-to-end connection to a computing system (e.g., a healthcare provider's computing system) that can securely share data (e.g., treatment data) with authorized users can facilitate data management and access.

FIG. 14 is a block diagram illustrating an exemplary network configuration in which an 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-transitory memories and one or more hardware processors configured to execute computer-executable instructions stored in the one or more non-transitory memories. In some such examples, procedures performed by the computing system 1404 may be associated with the execution by the hardware processors of the computing system 1404 of particular computer-executable instructions stored in the memory of the computing system 1404.

In some examples, a direct end-to-end data connection may be supported by one or more transceivers (e.g., wireless transceivers) within the AMD's communications module 602. For example, 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 the use of an intermediate system. The connection may use one or more wireless standards and technologies (e.g., 4G, 5G, etc.). In some examples, the AMD's transceivers may support communications over communications standards including, but not limited to, low-power wide area networks (LPWANs), narrowband long-term evolution (NB-LTE), narrowband Internet of Things (NB-IoT), long-term evolution machine-type communications (LTE-MTC), etc. In some cases, the transceivers are always on, and in some cases, the transceivers may be activated when a data transfer is scheduled, requested, or initiated. In some cases, the ability of the AMD 1402 to communicate with the computing system 1404 may be activated during manufacturing or before the device is provided to a patient.

In some cases, the patient or user establishes or initiates a direct end-to-end data connection with the computing system 1404. For example, the patient may interact with a user interface to cause the AMD 1402 to communicate with a cloud computing system. In some cases, the direct end-to-end data connection may be initiated or established without any action by the patient or user. For example, the direct end-to-end data connection may occur automatically at a specific time or when the AMD 1402 is in a specific location. This automatic connection may occur using information provided to the AMD 1402 at the time of manufacture, shipment, sale, or prescription for the subject. Furthermore, in some cases, the AMD 1402 may communicate with the computing system 1404 without access to a Wi-Fi network or local area network (LAN). For example, the AMD 1402 may communicate using a cellular or other wide area network. Furthermore, in some cases, user interaction with the AMD 1402 may be relatively minimal or simple compared to traditional network communications. For example, a user can press a single button (e.g., an "upload" button) to trigger the establishment of a connection with the cloud computing system 1404 and cause data to be provided from the AMD 1402 to the cloud computing system 1404.

In some cases, the AMD 1402 may be turned on and paired with a wireless wide area network (e.g., a cellular network) at the time of manufacture or before being provided to a patient. Additionally, the AMD 1402 may be authenticated in a networked computing environment as part of the manufacturing process.

Furthermore, establishing the direct end-to-end data connection may include determining that the AMD 1402 is authorized to communicate with the computing system 1404 based at least in part on the device identifier.

In some implementations, establishing the direct end-to-end data connection may include determining that the AMD 1402 is authorized 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 be based on one or more of an Internet Protocol (IP) address, a Media Access Control (MAC) address, a serial number, or a patient identifier of a patient receiving care from the mobile medical device.

Furthermore, establishing the direct end-to-end data connection may include determining that the AMD 1402 is authorized 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 the AMD 1402 to the patient. 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 producing the AMD 1402.

The AMD 1402 may be configured to at least identify computing systems (or cloud servers) 1404 of the networked computing environment 1408 (e.g., a cloud network, a data storage service provider, or an application service provider) based on a whitelist or approved list of one or more approved computing systems. The whitelist may be stored in memory of the AMD 1402 (e.g., memory within the AMD's control and computing module). The whitelist may also be configured at the time of manufacture of the AMD 1402. For example, the whitelist may be configured with connection information for establishing communication with one or more computing systems of the networked computing environment. The AMD 1402 may also be configured to at least obtain addresses of the computing systems 1404 from the whitelist and use the addresses to establish direct end-to-end data connections to the computing systems 1404 of the networked computing environment over a wireless wide area network. The whitelist may include unique identifiers, such as MAC addresses or static IP addresses, associated with the cloud service provider's computing systems 1404. The whitelist may include one or more of the embodiments described above with respect to FIG. 7.

To enhance security, AMD 1402 can use a whitelist that identifies authorized cloud servers or computing systems within the networked computing environment via unique identifiers (e.g., via IP addresses, MAC addresses, or URLs). Additionally, cloud computing system (or cloud server) 1404 can have a whitelist that specifies, via unique identifiers, other computing systems (e.g., remote display systems) that are authorized to communicate with AMD 1402 and/or computing system 1404 of the networked computing environment.

When devices communicate data over a network, there is generally a risk of data breach. To reduce or prevent data breaches, the AMD 1402 may communicate with computing systems, such as computing nodes in a networked computing environment or cloud network, based on secure data transmission methods. For example, the AMD 1402 may encrypt all data using an asymmetric key pair. In some cases, the AMD 1402 may establish a shared secret with the computing system, as described below.

In some cases, the therapy data may be encrypted before being transferred to the computing system 1404. To enable encryption, the AMD 1402 may have a public key and a private key stored in memory that allows the AMD 1402 to encrypt data that it transmits to the computing system 1404. In some cases, the AMD 1402 may generate a public key based at least in part on the private key. The encryption key may be stored in a protected area of memory or in memory separate from application memory. In some cases, the AMD 1402 may transmit a public key to the computing system 1404. Using the public key, the computing system 1404 may encrypt data for transmission to the AMD 1402. The AMD 1402 may use its private key to decrypt data, such as analysis of therapy data generated by the computing system 1404 in response to therapy data received from the AMD 1402. Similarly, the computing system 1404 may provide the public key to the AMD 1402. Using the public key, the AMD 1402 can encrypt therapy data (and/or device data) that is transmitted to the computing system 1404 for storage, analysis, presentation to a user, reordering medications, determining the status of the AMD 1402 and/or patient, or any other purpose or process that may be performed in response to the therapy data. The computing system 1404 can use its private key to decrypt the encrypted data and gain access to the therapy data (and/or device data).

In some cases, the public key may time out and a new public key may be obtained from the AMD 1402 (or from the computing system 1404) to facilitate encryption and/or decryption of subsequent communications from the AMD 1402. In some cases, the public key may be associated with a time-to-live (TTL) value. In some such cases, the public key may time out and a new public key may be obtained from the AMD 1402 to facilitate encryption and/or decryption of subsequent communications from the AMD 1402.

Furthermore, the secure data transmission may include generating a shared secret based at least in part on public or shared data and a private key. In some cases, the public or shared data may be a public key. In some such cases, the treatment or device data may be encrypted or decrypted using the shared secret. In some examples, the shared secret may be established using a public key exchange algorithm (e.g., a Diffie-Hellman key exchange algorithm).

In some cases, computing system 1404 may be configured to transfer or receive data stored in AMD 1402 (e.g., therapy data or device status data) after receiving a request to transfer the data to computing system 1404 via a direct end-to-end data connection, e.g., via a wireless wide area network. The request may include a device identifier associated with AMD 1402. In response to receiving the request to transfer the data stored in AMD 1402 to computing system 1404, computing system 1404 may be configured to receive the data via the direct end-to-end data connection. In some cases, computing system 1404 may open or provide a port to AMD 1402 that enables AMD 1402 to connect to the identified port and transfer data to computing system 1404 via the identified port. Further, transferring the data may include computing system 1404 sending an acknowledgment packet that the transfer request was approved or permitted. The AMD 1402 may transfer data in response to authorization by the computing system 1404 to transfer the data. In some cases, authorization may be based on the computing system 1404 verifying user account information (e.g., username and/or password, etc.).

In some examples, once a connection is established and therapy data is transferred to the computing system 1404, the computing system 1404 can analyze the therapy data received from the AMD 1402 and generate a therapy report. The therapy report can include data regarding the patient's disease, treatment with the AMD 1402, anonymous comparisons with other patients, statistical data regarding the patient's treatment, statistical data regarding other patients' diseases or disease management, etc. For example, the therapy report can determine whether the patient is maintaining average blood glucose levels or whether the control parameter settings of the AMD 1402 are similar to an average patient with similar physiological characteristics as the patient associated with the AMD 1402. Additionally, the computing system 1404 can detect alarm conditions based on the therapy data analysis and generate alerts that can be provided to the patient's authorized user (e.g., a healthcare provider). In some cases, the therapy data can trigger an automated response by the computing system 1404. For example, the AMD 1402 can determine that a medication or another disposable is low based on the received data and automatically reorder the medication or disposable.

In some cases, the computing system 1404 may periodically receive data (e.g., therapy data) from the AMD 1402 based on a regular schedule. Alternatively or additionally, the data may be received in response to a command or when the mobile medical device determines that it is within a particular location. For example, if the AMD 1402 determines that it is within a patient's home or a healthcare provider's office, the AMD 1402 may transmit data to the computing system 1404. The AMD 1402 may determine its location based, at least in part, on a local area network connection or a geographic location signal, such as from a Global Positioning System (GPS). In some implementations, additional encrypted data is intermittently received from the AMD 1402. Alternatively or additionally, the additional encrypted data may be received from the AMD 1402 base over at least a period of time. The AMD 1402 may be configured to transmit data as data is generated or immediately thereafter (e.g., in real time or near real time (e.g., within milliseconds, seconds, or minutes of generated data)), or in bulk at specified time periods. Sending data in bulk at specified time periods may extend battery life but may provide out-of-date analysis. When bulk data transfers occur at specified time periods, a user may request data transfers at unscheduled times, such as when the user is attending a doctor's appointment or when a patient is being attended to by emergency services personnel in an emergency. By keeping the transceiver always on, data can be made available on demand, which may consume more power compared to keeping the transceiver in sleep mode when not in use. Alternatively, the transceiver may be activated when a data transfer operation is requested. Thus, scheduling of data transfers can be balanced based on other considerations, such as (1) power consumption and/or (2) the need or desire to share information with authorized users or systems.

In some cases, the computing system 1404 may be used as a backup for the AMD 1402. For example, the AMD 1402 may back up data to the computing system 1404 overnight while charging or in close proximity to home or a doctor's office (e.g., when a patient is in a doctor's office waiting room, the device may upload data that a doctor can access to treat the patient's condition). Additionally, if the AMD 1402 is replaced (e.g., for a new model or to replace a damaged device), the device may automatically synchronize with the computing system 1404 to obtain patient-specific configuration or therapy control data.

Treatment Data and Treatment Reports In some examples, treatment data includes dose or administration data corresponding to one or more doses of a medication provided to a patient by AMD 1402. Additionally, treatment data may include patient data corresponding to a medical or physiological condition of the patient determined by the AMD 1402 device (e.g., using one or more biomedical sensors 1405).

In some examples, the data provided to the computing system 1404 may include any type of data that can be measured or obtained by the AMD 1402, and may include a record of the treatment provided by the AMD 1402. For example, the data may include the time the treatment was provided, the amount of medication provided as part of the treatment, measurements of one or more vital signs of the patient, measurements of blood glucose levels (e.g., measured blood glucose levels) of the patient at different times, the location of the patient, etc.

In some cases, the treatment data can be used to track the use of insulin or other medications, or disposables, such as insulin injection site kits. In some cases, the computing system 1404 can automatically order or reorder disposables at specific times based on tracking the use of the disposables. Alternatively or additionally, reordering of disposables may be initiated or performed from the AMD 1402 (e.g., via a wireless wide area network or via a local connection via a separate electronic device).

In some cases, the data transferred to the computing system may include operational data corresponding to the operation of AMD 1402. Alternatively or additionally, the data may further include error data corresponding to an error in the operation of AMD 1402.

In some examples, the data, treatment data, and/or treatment reports may be stored in memory of the computing system 1404 and/or storage in a networked computing environment.

In some cases, the method may include converting the therapy data from one format to another. For example, the method may include converting the therapy data from a format used to store and/or present the data on the AMD 1402 to a format that can be stored or processed on the computing system 1404. In some cases, 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 form that can be understood by different types of users. For example, the data may be presented in one format for healthcare providers (e.g., sensor readings), a simplified format for the patient or the patient's parent, or other data formats for displaying the data to different types of users. In some cases, the data may be presented in different formats depending on the patient's maturity level. For example, simplified data may be presented to pre-teens, more detailed data may be presented to teenagers, and even more detailed information may be presented to adults.

In some examples, treatment data collected from different AMDs associated with multiple patients may be aggregated for a group of patients. The aggregation may be based on any factor or commonality among the multiple patients. For example, treatment data may be aggregated based on association with facility or organization (e.g., clinic, insurance company, etc.), age, gender, nationality, ethnicity, job, stressors, recency of disease diagnosis or acquisition, location, diet (e.g., vegetarian, vegan, omnivore, etc.), or any other factor that may associate patients. Advantageously, aggregating data based on specific demographic and/or physiological characteristics may be useful for determining how best to care for particular patients within a group, how to improve care for a set of patients, how to learn more about how diabetes affects particular types of patients, etc.

In some examples, a treatment report based at least in part on the treatment data may be generated by the computing system 1404. The treatment report may include time series treatment data regarding treatments delivered by the ambulatory medical device over a particular period of time.

In some examples, the treatment report may be transmitted to AMD 1402. If AMD 1402 includes a display, such as, but not limited to, a touch screen display, the patient or other user may review the treatment report via the display of AMD 1402. Alternatively or additionally, the user may view the treatment report on the display of another electronic device that is in communication with computing system 1404 and is authorized to access the treatment report.

In some cases, mobile device data and/or data generated by computing system 1404 based on the mobile device data may be viewable from computing system 1404 on a secondary display system. For example, a clinician or parent may access the data from their own personal device. Communications between the computing system and the viewing device may be encrypted. Additionally, permission to share end-user data with "followers" (e.g., family members) or clinicians may be granted or controlled by the end-user (e.g., patient or guardian).

Association between the patient, clinic, and/or mobile medical device may be performed by associating the mobile medical device's device serial number with the patient and/or clinic. Furthermore, a user (e.g., patient, clinician, or parent) may access treatment recommendations via the cloud in the event that either the mobile medical device (e.g., insulin pump) or the CGM sensor fails.

In some cases, the computing system 1404 may be configured to receive at least a request from one or more display systems 1410 separate from the networked computing environment to access treatment reports, treatment data, or other data received by or stored on the AMD. In some cases, the display system may be the computing system of a medical practitioner 1414 (e.g., a doctor, nurse, physician's assistant, etc.), a patient's guardian 1416 (e.g., a patient's parents), an authorized user 1418 (e.g., a user authorized by the subject, such as a spouse, relative, friend, etc.), a healthcare provider 1420, or a patient's device 1412 (e.g., a mobile phone, personal computer, tablet, etc.). In some cases, the display system 1410 may be an AMD.

In some examples, the display system may be a therapy data management system that analyzes therapy data related to a particular type of health problem (e.g., data related to diabetes management) and provides information derived from the therapy data to a patient or authorized user to monitor and manage the corresponding disease.

In some examples, a request to access treatment data, treatment reports, or other data may include an account identifier associated with the user generating the request. In some examples, the account identifier may include a unique identifier associated with the patient. Alternatively, or in addition, the account identifier may include a unique identifier associated with a user authorized to access the treatment report. The user may or may not be the subject. In some aspects of the present disclosure, the method may further include associating the treatment data with the account identifier in storage in the networked computing environment. Furthermore, the computing system 1404 may be configured to determine whether an account associated with the account identifier is authorized to view the treatment report. In some examples, account permissions may be granted and/or changed by the patient. For example, the patient may access an account in the networked computing environment 1408, e.g., a cloud network provided by a cloud service provider associated with the patient, and provide one or more identifiers associated with one or more other users to grant permission to access the patient's treatment data or reports stored on the computing system 1404.

In response to determining that the account is authorized to view the treatment report, the computing system 1404 can transmit the treatment report to the display system via an encrypted communication channel. As previously described, an encrypted communication channel can be created by using an asymmetric key pair to encrypt the data being transmitted. Thus, the computing system 1404 can obtain a public key from the target system (e.g., the display system, the AMD 1402, or another computing system that will receive the treatment report). The computing system 1404 can encrypt the treatment report with the received public key and transmit it to the target system, which can decrypt the treatment report using its private key that corresponds to the public key. Alternatively or additionally, a shared secret can be determined for the commuter system 1404 and the patient system. The shared secret can be used to encrypt the treatment report.

In some cases, the method may include receiving an identification or identifying information of one or more users authorized to access the treatment data stored in the networked computing environment. For example, a user or patient may authorize a clinician or other healthcare provider, a parent or guardian, or other user to whom the patient desires access the treatment data. The identification information of one or more users may include any type of information that can identify a user or allow a user to be authenticated. For example, the identification information may include a name, a unique identifier (e.g., a social security number), an email address, an address, a phone number, the user's account information in the networked computing environment, or any other identifying information.

FIG. 15A is a flow diagram illustrating an exemplary method that may be used by computing system 1404 to generate and share a therapy report based on therapy data received from AMD 1402. In some examples, AMD 1402 may encrypt the therapy data using a public key and/or a shared private key. The encrypted therapy data may be provided to another computing system, such as a clinician's computing system or a computing system in a networked computing environment (e.g., a computing system in a data center of a cloud computing network).

In block 1502, computing system 1404 can establish a direct end-to-end data connection to AMD 1402 over a wireless wide area network (WAN), for example, using a Narrowband Long Term Evolution (NB-LTE) transceiver included in AMD 1402. The direct end-to-end data connection may be initiated by computing system 1404 or AMD 1402. A direct end-to-end connection may be a connection between AMD 1402 and computing system 1404 that omits an intermediate computing system (e.g., a local computing system such as a laptop or smartphone). However, a direct end-to-end connection may include intermediate connecting hardware, such as a router, base station, or switch, in some cases.

Once the direct end-to-end data connection between the AMD 1402 and the computing system 1404 is established, in block 1504, the computing system 1404 may receive a request from the AMD 1402 to transfer data (e.g., therapy data) stored in the AMD 1402 to the computing system 1404 via the direct end-to-end data connection. Alternatively, 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 process of establishing the direct end-to-end data connection or may be requested after the direct end-to-end data connection has been established.

In block 1506, the computing system 1404 and the AMD 1402 may exchange public keys. In some cases, the public key exchange may occur as part of establishing a direct end-to-end data connection to establish a secure or encrypted channel. In some cases, the public key exchange may occur after establishing a connection to create a secure data channel. In some cases, either the computing system 1404 or the AMD 1402 may provide a public key, but the other device may not. In some such cases, data transfer may be one-way, so only one of the devices may provide a public key. In some examples, the AMD 1402 may use the public key received from the computing system 1404 to encrypt therapy data sent to the computing system 1404. Alternatively, or in addition, the computing system 1404 may use the public key received from the AMD 1402 to encrypt a therapy report based on therapy data to be sent to the AMD 1402 or other data acquired by the computing system 1404.

In block 1508, the computing system 1404 may determine whether the AMD 1402 is authorized to send data (e.g., therapy data) to the computing system 1404. The computing system 1404 may determine whether the AMD 1402 is authorized to send data based on a device identifier associated with the AMD 1402, an account identifier associated with the AMD 1402 or the patient, or any other information that may be used to determine whether an action is permitted. In some cases, the computing system 1404 may use a whitelist to verify that the AMD 1402 is authorized to communicate with or transfer data to the computing system 1404.

If it is determined that the AMD 1402 is authorized to transfer data to the computing system 1404, the computing system 1404 may receive data from the AMD 1402 at block 1512. The data may be encrypted therapy data related to therapy provided to the patient by the AMD 1402. In some embodiments, the computing system 1404 may store the therapy data in one or more of the computing system 1404's storage or the networked computing environment 1408's storage. In some examples, the encrypted data may include at least one of operational data corresponding to the operation of the AMD 1402 or error data corresponding to an error in the operation of the AMD 1402. In some embodiments, the additional encrypted data may be received from the AMD 1402 intermittently, periodically, periodically, or continuously over at least a period of time.

If, at block 1508, the computing system 1404 determines that the AMD 1402 is not authorized to transfer data to the computing system 1404, the process proceeds 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 has been denied. Additionally, the computing system 1404 may provide a reason why the request is denied, such as an incorrect password or an unrecognized device identifier.

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 memory of the computing system 1404) that corresponds to the public key provided by the computing system 1404 to the AMD 1402. Alternatively or additionally, the computing system 1404 may decrypt the encrypted therapy data using a shared secret generated between the computing system 1404 and the AMD 1402.

In block 1516, the computing system 1404 may generate a treatment report using the treatment data received from the ethAMD 1402. In some examples, the decoded treatment data and/or the treatment report may be stored in memory of the computing system 1404. The treatment report may include any type of statistics or data that can be inferred from the treatment data or from a series of treatment data received over time from the AMD 1404 and/or multiple AMDs associated with multiple patients.

At block 1518, the computing system may receive a request from a display system 1410, separate from the networked computing environment, to access the treatment report generated at block 1516. The request may include an account identifier associated with the user that generated the request for the treatment report. Alternatively, or additionally, the request may include an identifier associated with the display system 1410 requesting the treatment report. Further, the request to access the treatment report may include account information and a password for the display system 1410 and/or the user associated with the display system 1410. In some such cases, the display system 1410 may be the AMD 1402. In some such cases, the AMD 1402 may not need to authenticate to receive the treatment report, as authentication may occur as part of block 1502. In some cases, such as when the treatment report is generated at a different time than the reception of the treatment data, the AMD 1402 may authenticate with the computing system 1404 before receiving the treatment report.

In block 1520, the computing system 1404 may use the account identifier, device identifier, or other authentication information received in block 1518 as part of the request to access the treatment report to determine whether the account associated with the account identifier is authorized or permitted to view the treatment report. In some cases, the display system 1410 or user is authenticated prior to receiving the request to access the treatment report.

If the display system 1410 or account associated with the request to access the treatment report (or treatment data) is not successfully authenticated and/or it is determined that the user is not authorized to access the treatment report (or treatment data), the computing system 1404 may deny the request at block 1524. The operations associated with block 1524 may include one or more of the embodiments associated with block 1510.

If, in block 1520, the computing system 1404 determines that the account is authorized to view the treatment report, then, in block 1522, the computing system 1404 can transmit the treatment report to the display system 1410. The treatment report can be transmitted via a direct connection to the display system 1410 or via a computing network, which may include the Internet. Additionally, the computing system 1404 can communicate the treatment report (or treatment data) using an encrypted communication channel. In some cases, when the computing system 1404 receives a request to provide access to or transmit the treatment report (e.g., as part of block 1518), the computing system 1404 can request a public key from the display system 1410 and can encrypt the treatment report using the received public key. In some such examples, the display device 1410 can use a private key to decrypt the encrypted treatment report received from the computing system 1404. This private key can correspond to a public key provided to the computing system 1404 by the display system. In some examples, the display system can be the AMD 1402. In some such examples, the patient or authorized user can view treatment reports received from the computing system 1404 on a user interface (e.g., a touch screen display) of the AMD 1402 .

In certain embodiments, the computing system 1404 may determine that the therapy data or other data received from the AMD 1402 meets an alert threshold condition based at least in part on the patient's physiological information 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 meets an alert threshold condition, the computing system 1404 may transmit 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 transmitted to the patient's user device, a user device of another user (e.g., a parent, guardian, or physician), a user device of an emergency service provider, or a user device of any other authorized user associated with the patient.

In some examples, the warning threshold condition may be associated with a patient's health status. For example, the warning threshold condition may include the patient's blood glucose level being above (hyperglycemia) or below (hypoglycemia) a set value or range of values. In some examples, the warning threshold condition may be associated with the operation of the AMD. For example, the warning threshold condition may include the rate of therapy (e.g., the rate at which insulin is delivered to the patient) being above or below a set value. As another example, the warning threshold condition may be related to the amount of medication remaining in the medication cartridge.

In some examples, the alert threshold condition may be related to the temporal behavior of the therapy data over a period of time. For example, the alert threshold condition may be related to fluctuations or variations in the patient's blood glucose levels being outside of a particular range.

In some cases, one or more alert threshold conditions may be defined or specified by a healthcare provider. In some such instances, the healthcare provider may modify one or more alert threshold conditions based at least in part on the patient's physiological parameters or characteristics.

FIG. 15B is a flow diagram illustrating an exemplary method that may be used by AMD 1402 to transmit therapy data to computing system 1404 via a direct end-to-end connection. The process illustrated in FIG. 15B may include one or more of the embodiments described above with respect to FIG. 15A.

At block 1530, the AMD 1402 may identify computing systems 1404 in the networked computing environment 1408 based at least in part on a whitelist of one or more approved computing systems stored in memory of the AMD 1402. In some examples, the whitelist may be stored in memory of the AMD 1402 during manufacture of the mobile medical device. In some instances, the AMD 1402 may accept data packets from and/or communicate exclusively with computing systems identified in the whitelist. Further, in some instances, the AMD 1402 may verify that a received packet was received from a computing system on the whitelist, for example, by accessing the packet header. Data packets received from computing systems not on the whitelist may be ignored or discarded. In some instances, a user may be able to add computing systems, such as a patient's laptop or smartphone or the patient's guardian, to the whitelist.

At block 1532, the AMD 1402 may establish a direct end-to-end data connection to the computing system 1404 using the address of the computing system 1404 obtained from the whitelist. In some examples, the address may be a network address (e.g., a network address of the networked computing environment 1408). In some such examples, the network address may be an Internet Protocol (IP) address, a Uniform Resource Locator (URL), a Uniform Resource Identifier (URI), or a Uniform Resource Name (URN). In some embodiments, the direct end-to-end data connection may be established over a wireless wide area network (WAN) using a transceiver of the AMD 1402 configured to support communication via one or more communication standards, such as the Low Power Wide Area Network (LPWAN) communication standard, the Narrowband Long Term Evolution (NB-LTE) standard, the Narrowband Internet of Things (NB-IoT) standard, or the Long Term Evolution Machine Type Communications (LTE-MTC) standard. In some such embodiments, the transceiver may be configured to communicate over a wireless wide area network using the address. In some examples, a direct end-to-end data connection to the computing system 1404 may be established by sending a connection request to the computing system 1404. In some such examples, the connection request may include a device identifier of the AMD 1402.

At block 1534, the AMD 1402 may receive a public key from the computing system 1404. At block 1536, the AMD 1402 may encrypt therapy data associated with a therapy delivered by the AMD 1402 based at least in part on the public key received from the computing system. In some embodiments, the AMD 1402 may encrypt the therapy data based at least in part on a shared secret generated based on the asymmetric key pair (e.g., public and private keys) of the AMD 1402 and the asymmetric key pair of the computing system 1404. For example, the shared secret may be generated using a Diffie-Hellman key exchange.

In block 1538, the AMD 1402 may transmit the encrypted therapy data to the computing system 1404 via a direct end-to-end connection. In some embodiments, the AMD 1402 may acquire additional therapy data, which may be acquired 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 in block 1536. Alternatively, a different key or shared secret may be acquired and used to encrypt the additional therapy data. For example, once the additional therapy data is acquired, 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 via a direct end-to-end connection. In some embodiments, the computing system may decrypt the received encrypted therapy data using the public key transmitted to the AMD 1402 and a private key stored in the computing system's memory. In some cases, in addition to the therapy data, the 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 operational data or error data, where the operational data corresponds to the operation of the mobile medical device and the error data corresponds to an error in the operation of the AMD 1402.

In various embodiments, the computing system 1404 that performs the steps described with respect to Figures 15A and 15B may be a computing system within a networked computing environment 1408/1608, a data center, a computing system in a hosted services environment, or a cloud network 1406/1606.

In some embodiments, the AMD 1402 is connected to a networked computing environment 1408
In some embodiments, the AMD 1402 may receive an account identifier associated with a user authorized to access the data associated with the patient and transmit the account identifier to the computing system 1404. In these embodiments, the computing system 1404 may allow the authorized user to access the treatment data received from the AMD 1402. In some embodiments, the AMD 1402 may also transmit to the computing system 1404 a set of permissions that may authorize the user to access the treatment data associated with the patient.

FIG. 16 is a block diagram illustrating an exemplary network and data flow configuration in which an AMD 1602 directly connected to a computing system 1604 (e.g., a computing system in a cloud network 1606) can generate and transmit an alert 1611 to various display systems 1610 (e.g., an alert message, an alert signal, etc.) when it determines that data received from the AMD 1602 meets a threshold condition. The computing system 1604 may be part of a networked computing environment 1608 (e.g., a data center, a network computing system), or a cloud service provider's cloud network 1606 or cloud computing system. The computing system may include one or more non-transitory memories and one or more hardware processors configured to execute computer-executable instructions stored in the one or more non-transitory memories. The AMD can receive data from one or more biomedical sensors 1605 (e.g., a blood glucose sensor, an analyte sensor, a temperature sensor, a heart rate sensor, etc.) and/or one or more environmental sensors 1603 (e.g., a geolocation receiver, a motion sensor, an accelerometer, etc.). These sensors may be included in the AMD unit or may be connected to the AMD via a wired or wireless link.

In some cases, the one or more display systems 1610 receiving the alert 1611 may be display systems that previously received a treatment report from the computing system 1604. In some examples, one or more display systems may be selected and/or authorized by the patient receiving treatment from the AMD 1602 to receive the alert 1611. The display systems 1610 may receive the alert 1611 from the AMD 1602 and may include a physician 1614 (e.g., a doctor, a nurse, etc.), a guardian of the patient 1616 (e.g., the patient's parents), an emergency services provider 1618, an authorized user 1620 (e.g., a user authorized by the subject, such as a spouse, relative, friend, etc.), a healthcare provider 1622, or a device of the patient 1612 (e.g., a mobile device, cell phone, personal computer, tablet, etc.). In some examples, if it is determined that the received data from the AMD 1602 meets a threshold condition, 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).

In some examples, the AMD 1602 may be configured to establish a connection to support continuous data transfer to the computing system 1604 over a given period of time (e.g., provided to the AMD by the patient) to capture data generated over the given period and/or meeting alert threshold conditions. For example, a patient may request a continuous connection between the AMD and the computing system when going hiking alone to ensure that an alert is sent to one or more authorized display systems if their health condition deteriorates during the hike.

In some examples, geolocation sensors (e.g., Global Positioning System (GPS) receivers) and/or proximity sensors may be used to enable location-triggered functionality, such as automatic uploading of data at specific locations.

In some cases, the AMD 1602 may include, communicate with, or be connected or interfaced with a motion sensor, accelerometer, or geolocation system. In some examples, the aforementioned sensors may be used to determine or detect the speed of the AMD and/or the patient. In some such examples, data 1607 obtained from the AMD 1602, such as location and/or speed information, may be used to provide intelligent alerts. For example, if the AMD 1602 (or the computing system 1604 receiving data from the AMD 1602) determines from the location and/or motion data that the user is traveling at a high 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 services provider 1618 that the patient is at risk for hypoglycemia and may be driving. Additionally, the AMD 1602 and/or the computing system 1604 may provide the patient's location to the emergency services provider 1618. In some cases, the determined speed of the AMD can be used to generate a driving alert to notify the patient to stop immediately or as soon as it is safe due to the risk of a hypoglycemic event. In some examples, if a patient is determined to be traveling at 6-7 mph, for example, an exercise alert can be generated to warn the patient to discontinue exercise if the patient's blood glucose level drops below a certain level. In some examples, if a patient has not moved for three hours and has low blood glucose, the system can enable automatic notification to emergency services. Additionally, the patient's determined activity level can be sensed and used to modify therapy delivery. For example, a determination of patient movement can be used to automatically adjust the rate of therapy delivery (e.g., increasing blood glucose levels that trigger therapy delivery).

In some examples, the computing system 1604 may generate alerts based on trends in aggregated treatment data or based on treatment data that is an outlier relative to the aggregated treatment data or a time-based average of the treatment data.

Additionally, the computing system 1604 can send text messages, make calls, or generate any other type of alert that can be automatically provided to devices (e.g., smartphones, laptops, etc.) of followers, healthcare providers, or other users associated with the patient when treatment data meets an alert threshold. These messages or alerts may also be provided from the computing system to third-party devices in the event of roaming or data plan deactivation on the AMD (e.g., no TCP/IP available). Additionally, the computing system 1604 can send text messages or 911 calls in the event of a detected emergency. The computing system 1604 can track the end user's most recent location, e.g., via GPS, and share that information with followers and/or emergency personnel. Additionally, the computing system 1604 can enable the end user to order and reorder medical supplies directly from the viewing device.

In some examples, the computing system 1604 can generate notifications regarding potential medical risks (e.g., generating a message when there is a risk of hypoglycemia). Additionally, more detailed processing in the computing system can result in improved recommendations (e.g., trigger levels for therapy delivery or other control parameters).

17 is a flow diagram illustrating an exemplary method that may be used by a computing system 1604 to generate and transmit an alert (e.g., an alert message, an alert signal, etc.) to one or more authorized devices and an AMD. In block 1702, the computing system 1604 may establish a direct end-to-end data connection to the AMD 1602 over a wireless wide area network (WAN), for example, using a Narrowband Long Term Evolution (NB-LTE) transceiver included in the AMD 1602. In some examples, the direct end-to-end connection may be established for a given period of time set by the patient or an authorized user (e.g., the patient's guardian). Block 1702 may include one or more of the embodiments described with respect to block 1502.

Once the direct end-to-end data connection between the AMD 1602 and the computing system 1604 is established, in block 1704, the computing system 1604 may receive a public key from the AMD 1602 over the established connection. As previously mentioned, in some cases, a key exchange may be part of the process of establishing the data connection. Furthermore, block 1704 may include one or more of the embodiments described with respect to block 1504.

In block 1706, the computing system may receive a request from the AMD 1602 to transfer data generated by the AMD 1602 (e.g., therapy data, medical sensor data, or environmental sensor data) to the computing system 1604 via a direct end-to-end data connection. In some cases, the request to transfer the data may be the data itself. In other words, in some cases, there may not be a formal request to transfer the data; instead, upon establishing the data connection, the data may be sent by the AMD 1602 to the computing system 1604. Block 1706 may include one or more of the embodiments described with respect to block 1506.

In some cases, the request may include a period during which the AMD 1602 is to continuously transmit data generated by the AMD 1602 or obtained from one or more sensors (e.g., medical sensor 1603 or environmental sensor 1605) to the computing system 1604. In some such cases, the period for continuous data transfer from the AMD 1602 to the computing system 1604 may be provided to the AMD by the patient or the patient's guardian.

In block 1708, 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 a device ID associated with the AMD 1602, and block 1708 may include one or more of the embodiments described with respect to block 1508.

If it is determined that AMD 1602 is not authorized to transfer data to the computing system, the request received in block 1706 may be denied in block 1710. Block 1710 may include one or more of the embodiments described with respect to block 1510.

If computing system 1604 determines that AMD 1602 is authorized to transfer data to computing system 1604, then in block 1712, computing system 1604 may authorize AMD 1602 to provide encrypted therapy data to computing system 1604. In other words, computing system 1604 may receive therapy data, which may be encrypted therapy data, from AMD 1602. Block 1712 may include one or more of the embodiments described with respect to block 1512.

In block 1714, the computing system 1604 may decrypt the received data using a private key. The private key may correspond to the computing system's 1604 public key provided to the AMD 1602 to encrypt the therapy data. This private key may be stored in the computing system's 1604 memory. Block 1714 may include one or more of the embodiments described with respect to block 1514.

At block 1716, the computing system 1604 may determine whether the received data (e.g., therapy data, medical sensor data, or environmental sensor data) meets a threshold condition. In some examples, the computing system 1404 may determine that the therapy data or other data received from the AMD 1402 meets an alert threshold condition based at least in part on patient physiological information or physiological measurements obtained from the AMD 1402. In some cases, the physiological measurements may be obtained from one or more physiological sensors (e.g., a glucose monitor, a heart rate monitor, a blood pressure monitor, etc.) that provide physiological measurements to the AMD 1402. In some cases, the threshold condition may be provided to the AMD 1602 by the patient or an authorized user (e.g., the patient's guardian). In some examples, the threshold condition may be provided by a healthcare provider. In some such examples, the threshold condition may be stored in a memory of the AMD 1602.

If the computing system 1604 determines that the treatment data meets the threshold condition, the computing system may generate an alert and transmit the alert to one or more display systems 1610 that are authorized to receive the alert (e.g., by the patient or the patient's guardian) at block 1718. In some examples, the patient or other authorized user may authorize one or more display systems 1610 to receive the alert, for example, by providing the computing system 1604 or the networked computing environment 1608 with the account ID of the one or more display systems. If, at block 1716, the computing system 1604 determines that the treatment data does not meet the threshold condition, the process returns to block 1712 and the computing system 1604 may continue to receive the treatment data from the AMD 1602.

Preventing Inadvertent Treatment Changes As described above, an ambulatory medical device (AMD) may include a user interface (e.g., a touchscreen interface or a non-touchscreen interface) that can present a user with one or more user interface screens that allow the user to change one or more treatment settings of the AMD, such as the amount of medication delivered when a condition is met or the conditions that trigger delivery of medication to the patient. In some cases, the AMD may be a mobile medication device. The user may be a patient receiving medication or treatment, a clinician or healthcare provider, a parent or guardian, or any other user who may be authorized to change the settings of the mobile medication device. In an AMD with a user interface, settings may be accidentally changed when the user is not fully aware of their actions (e.g., a child or a user with reduced mental capacity), or the user may change settings unintentionally. Furthermore, AMD settings may be accidentally changed due to inadvertent interaction with the user interface, such as may occur when the AMD is worn on a patient's body.

The ambulatory medication device (AMD) may be configured to prevent inadvertent changes to control parameters and/or medication delivery, for example, if the AMD's settings are accidentally changed by a user or inadvertent interaction with the AMD's user interface.

As described above, in some embodiments, a user may modify the controls or configuration of the AMD using a user interface. It is possible that the controls or configuration of the AMD may be inadvertently changed via the user interface. For example, because a user may be transporting the AMD, there is a risk that the user may inadvertently activate an input on the AMD that initiates a therapy change input (e.g., by applying pressure to the AMD, which may be placed in the user's jacket pocket).

Referring to FIG. 18, in some embodiments, the control and computation module (
The control and computing module (CCM) 610 may include a set of therapy change procedures implemented to prevent inadvertent therapy change input 1829. The therapy change procedures performed by the CCM 610 may be implemented as instructions stored in a memory of the CCM (e.g., main memory 616) and executed by the processor 614. The CCM 610 may validate a therapy change input 1829 received from a user 1827 using one or more therapy change procedures before the AMD 600 performs therapy based on the received therapy change input 1829. In some cases, the therapy change input 1829 may be received in response to a user interaction with the user interface module 1808. The therapy change input 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., controllers 1830-1836) implemented by the CCM 610.

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 AMD 600 or transmitted to a display of an electronic device in communication with AMD 600. In some cases, the user interface controller may be a touch screen controller configured to output display signals configured to generate one or more user interface screens on a touch screen. Additionally, the touch screen controller may be configured to receive user input signals corresponding to user interaction with the touch screen.

In particular embodiments, a user 1827 can wake the AMD from a sleep state or unlock the AMD by interacting with the wake interface 1822. When the AMD is in a sleep state, the touchscreen controller may not receive user input or a user input signal corresponding to the user input. Waking up the AMD 600 may include activating the touchscreen interface or presenting a lock screen to the user. Additionally, waking up the AMD may include activating the touchscreen controller so that it can receive user input or a user input signal corresponding to the user input. The wake interface 1822 may include one or more of the additional user interfaces described above configured to generate and provide a wake input (or wake signal) to the CCM upon detecting a predefined user interaction. Alternatively or additionally, the wake interface 1822 may be any type of wake interface element of the AMD with which a user can interact to activate at least one feature of the AMD (e.g., a touchscreen interface). For example, 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. In some cases, the wake interface element can be or include a biometric element, such as a fingerprint reader, an iris scanner, or a face detection scanner. In some cases, the AMD can wake up in response to a specific motion or the detection of a motion. For example, a determination that the mobile medication device is being moved with a specific motion or within the user's line of sight or visual range can wake the AMD or cause the AMD to wake a touchscreen interface of the AMD. The AMD can determine that the AMD is moving within the user's line of sight based on the type of motion and/or detection of the user's eyes, for example, via an iris scanner or camera.

In some examples, therapy change input 1829 may be an input provided by user 1827 to change a therapy currently being delivered to user 1827. For example, therapy change input 1829 may cause an insulin infusion pump or a glucagon infusion pump to begin infusing an amount of insulin or glucagon to user 1827. In some examples, therapy change input 1829 provided by user 1827 may affect therapy delivery at a future time. In some examples, therapy change input 1829 may change an insulin or glucagon infusion rate to user 1827. The therapy change input 1829 may also cancel an insulin or glucagon infusion from an insulin or glucagon infusion pump to user 1827. In some cases, therapy change input 1829 is a request to change a control parameter. The control parameter may be changed in response to the request. Alternatively or additionally, a confirmation action (e.g., a swipe gesture or interaction with a physical or digital button on a touch screen) may be required to confirm the requested control parameter change before the control parameter is changed.

In some cases, when a wake operation is detected by the wake interface 1822, a wake input is sent to the control and computation module 610, which can mimic or execute a wake control procedure to wake up/unlock the user interface (e.g., a touchscreen display). In some cases, the CCM 610 can execute the wake procedure using the wake controller 1834.

When in the activated and/or unlocked state, the user can interact with the touch screen 1824, alphanumeric pad 1826, or other type of user interface that may be included in the user interface module 1808 to gain access to the therapy change user interface.

The therapy change user interface may be activated by a first user interaction with a user interface (e.g., touch screen display 1824). When the first user interaction is detected, the user interface module 1808 may send an input signal to the control and calculation module 610 to determine whether the first user interaction is related to a therapy change request or a control parameter change request. In some cases, 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 the first user interaction is determined to satisfy a set of predetermined conditions, the therapy change controller 1836 sends a signal to the user interface module 1808 to activate the therapy change user interface.

In some embodiments, 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, therapy change control procedure 1836 can send one of two signals to user interface module 1808. The therapy change user interface or therapy change controller 1836 can unlock one of two different therapy change user interfaces that provide different options for therapy change selection to user 1827. In this example implementation, a therapy change selection to make a significant therapy change, such as dramatically increasing the rate of an insulin or glucagon infusion rate (e.g., by more than a magnitude or more than three change increments), may require a different user interaction or a smaller change in a control parameter than may be required for insulin or glucagon infusion at a normal or prescribed rate. In some examples, the user interaction may be a simple interaction (e.g., unlocking a simple gesture or gesture operation) that unlocks a therapy change user interface with limited therapy change selections. Another user interaction can be a complex interaction (e.g., a series of complex gestures) that unlocks a therapy change user interface with unlimited therapy change selections. One example of this implementation can be useful for a child user. A child user can perform a first or simpler gesture consisting of a series of simple inputs to unlock the limited therapy change selections. An adult user can perform a second or more complex gesture consisting of a series of complex inputs to unlock the therapy change user interface with unlimited therapy change selections.

When activated, the therapy change user interface generated by the user interface module 1808 can provide one or more therapy control elements that allow a user to change one or more settings of the AMD 600. In some examples, the therapy control element may include any type of user interface screen on a touch screen, or other type of user interface in a non-touch screen context, that enables or permits a user to change the configuration of the AMD 600. This change in the configuration of the AMD 600 may be related to a change in the therapy provided or the detection of a triggering event that causes therapy (e.g., drug delivery) to be provided to the patient. For example, the configuration change may include a selection between one or more hormones that regulate the user's blood glucose levels (e.g., insulin or glucagon), amounts of one or more hormones that regulate the user's blood glucose levels, delivery rates of one or more hormones, thresholds for determining when to deliver one or more hormones, changes in estimated blood absorption rates of one or more hormones, etc. In some examples, the therapy control element may include any type of user interface screen on a touch screen, or other type of user interface in a non-touch screen context, that enables or permits a user to change one or more control parameters of the AMD 600 that control therapy delivery.

In some cases, changes to the settings of the AMD (e.g., control parameters or configuration of the AMD) are automatically and/or immediately recognized or implemented by and/or transmitted to the AMD. In some cases, confirmation of the settings changes may be required before they are implemented or transmitted by the AMD.

This confirmation may be entered based on a second user interaction with the user interface (e.g., touch screen display 1824). When the second user interaction is detected, the user interface module 1808 sends an input signal to the control and calculation module 610, which is analyzed by the therapy change control procedure 1836. If the second user interaction is determined to satisfy a set of predetermined conditions, the therapy change control procedure 1836 implements a change to the configuration of the AMD.

The first and/or second user interactions may include selecting an icon, a series of taps or inputs, one or more gestures (e.g., a linear swipe, an arc swipe, a circular swipe, or other simple or complex movements across the touch screen), performing a pattern or sequence on the touch screen (e.g., drawing an image), a multi-touch or multi-input interaction, a combination of the above, or any other type of interaction with the touch screen, or portions thereof. The series of inputs may be any combination of touch movements, touch points, numbers, alphabetic characters, and other symbols. The gesture interaction may be guided by a visual display displayed or printed on the AMD. In some embodiments, the visual instructions may include an animation suggesting or guiding the user interaction with the touch screen. For example, the first user interaction may include an arc swipe around at least a portion of a generally circular icon or logo. In some examples, the first user interaction and/or the second user interaction may include a predetermined sequence of numeric and/or alphabetic inputs. In some examples, the series of multiple inputs, the range of parameters of the inputs may depend on other inputs in the series. For example, the required starting position of a touch action may depend on the position of a previous touch action. The time over which a series of inputs is entered may be part of a range of parameters. For example, the series of inputs may need to be entered in greater than or equal to 3 seconds, or greater than or equal to 15 seconds.

Furthermore, one or more of the interactions may include interacting with a sensor such as an optical sensor (e.g., a visible light or IR sensor), a biometric sensor (e.g., a fingerprint or retinal scanner), a proximity sensor, a gyroscope, or a combination of an accelerometer and a gyroscope. Also, in some cases, the second user interaction may be received via a wireless signal such as RFID or Bluetooth. In some embodiments, the second user interaction may include receiving a selection of an indicator box corresponding to either insulin or glucagon and receiving a predetermined series of numeric inputs to deliver the therapy change selection.

The type of user interaction that unlocks the touch screen, provides access to the configuration screen, and/or confirms changes to the AMD's configuration may be the same or different.

In some examples, the system may have a timeout, where if no interaction occurs for a set period of time, the user interface is turned off and the therapy change request process must be initiated again. In one implementation of a timeout, if no interaction occurs for more than 30 seconds after the system is started/unlocked before a second user interaction is received by the user interface, the user interface is disabled.

In some embodiments, once changes or modifications to treatment settings (e.g., changes to control parameters or configurations of the AMD) are identified, implemented, or transmitted, the AMD may begin operating based on the modified settings selected and/or provided by the user.

In some cases, this action may include triggering therapy delivery based on the new settings or providing therapy based on the new settings. For example, the AMD may generate a dose control signal based at least in part on the modified configuration or control parameters, or may detect a trigger based at least in part on the modified configuration or control parameters that results in the delivery of therapy.

18 , in some embodiments, changes made via the therapy change user interface are sent to the CCM, and the CCM's therapy control change procedure 1836 forwards the changes to a device and patient monitoring and control procedure 1832. The device and patient monitoring and control procedure 1832 can 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 status of the patient 1827 using patient sensors (e.g., CGM sensors). For example, the device and patient monitoring and control procedure 1832 can receive information regarding therapy changes requested by the user 1827 via the user interface (touch screen display 1824 or alphanumeric pad 1826) or information regarding the glucose level in the patient's blood from the patient sensors 1820. The device and patient monitoring and control procedure 1832 can then send information regarding the patient's health status and/or AMD configuration to a drug dosage control procedure 1830. In some examples, parameters of the drug dosage control procedure 1830 can be adjusted based on changes and/or information captured by the device and patient monitoring and control procedure 1832. The drug dosage control procedure 1830 can control and activate the drug delivery interface 1806 by providing a drug dosage signal. In some examples, the drug can generate control based at least in part on a detected condition or physiological characteristic of the patient (e.g., provided by readings of the patient sensors 1820) and according to parameter values received from the therapy change control procedure 1836. The drug delivery interface 1806 can provide therapy change delivery to the user according to the information received by the device and patient monitoring procedure 1832.

In some examples, the dose control signal may be generated based on time (e.g., medication may be delivered periodically), one or more user commands, an indication that the patient is about to or is engaged in a particular activity (e.g., eating, exercising, sleeping, fasting, etc.), or any other factor that may be related to or cause the initiation of treatment (e.g., medication delivery).

FIG. 19 is a flow diagram illustrating an exemplary 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 can initiate the configuration change process by activating/unlocking the touch screen using a wake action. In block 1902, a wake action is received by the AMD's wake interface 1822. In block 1904, the wake interface 1822 sends a wake signal to the AMD's CCM module 610. Within the CCM 610, the wake procedure generates, activates, or unlocks the touch screen display 1824 (in block 1906). In block 1908, the AMD receives a response or a first gesture from the user. In block 1908, the therapy change user interface is unlocked. In block 1912, the user can modify or change one or more therapy settings (e.g., control parameters or configurations) of the AMD using one or more therapy control elements provided in the corresponding therapy change user interface. At block 1914, the user may confirm the changes made by providing a second gesture on the touch screen display 1824. Once confirmation is received, at block 1916, the requested therapy change or therapy modifications are implemented, and the AMD may begin operating in accordance with the modified configuration or modified set of control parameters. In some examples, once the user confirms that the changes have been made, the drug dose control module 1830 may send a dose control signal to the drug delivery interface 1806 to trigger therapy delivery to the patient based on the modified therapy settings.

In some cases, the AMD, or a control device that allows a user to change the configuration of the AMD, may have a timeout feature. The timeout feature may cause the AMD or control device to go into a sleep or locked state after a period of inactivity by the user. In some cases, the timeout feature may cause the AMD or control device to go into a sleep or locked state after a specific period of time, regardless of whether the user is interacting with the ambulatory medication device or control device. In some cases, the timeout feature may cause the user interface (e.g., a touch screen display) to become inactive or lock. Thus, the user may have a limited period of time to change the configuration of the AMD.

In some examples, a therapy change made by a user can trigger delivery of medication according to the therapy change received and confirmed by the user. This therapy change delivery may occur a set time after confirmation is received.

In some embodiments of the AMD, an alarm status indicator may be presented to the user via a user interface. The alarm status indicator may be a warning message or a warning symbol. The alarm status indicator may be related to a configuration change made by the user, a change in the state of the AMD unrelated to user input, or a patient condition (e.g., detected by a patient sensor).

FIG. 20A is a diagram of the touch screen display 2000 of an exemplary AMD after the touch screen has been activated/unlocked by a user wake action and before a first user gesture is received. While the touch screen display is locked, the touch screen display 2000 can display any image, animation, text, or other graphic. A first gesture prompt 2005 indicates to the user 1827 the input required to unlock the therapy change user interface. Here, the first gesture prompt 2005 indicates to the user 1827 that a touch action beginning with a greater-than sign (>) and moving to the right across the "Unlock" text is an acceptable first gesture. In addition to the first gesture prompt, the refill status of the AMD 600 is shown in a graphical representation 2010. Here, the graphical representation 2010 indicates that the insulin cartridge in the AMD device 600 is almost full. The current blood glucose level 2015 is shown at the top of the touch screen display 2000, allowing the user 1827 to be informed of the need for hormones to regulate blood glucose levels. The touch screen display 2000 also shows a graphical representation of a glucagon cartridge 2020. A graphical representation of an alarm 2025 within the touch screen display 2000 indicates that an alarm has been set on the AMD 600.

FIG. 20B is a diagram of an exemplary touch screen display 2050 that can prompt a user for a predetermined sequence of inputs for a first or second gesture. In various embodiments, such as the embodiment shown in FIG. 20B , the touch screen display 2050 can display touchable numeric keys 2055. In various embodiments, the touch screen display 2050 prompts the user 1827 to enter a sequence of inputs that complete the first or second gesture. "Enter Code" text 2060 prompts the user 1827 to enter a predetermined or preselected string of numbers as part of the first or second gesture. The numeric sequence being entered by the user 1827 is displayed in field 2065 as it is entered as an aid to the user 1827. Input 2070 on the touch screen display 2050 indicates that a right swipe touch movement across the bottom of the screen is required to complete the predetermined sequence of inputs for the first or second gesture. The Bluetooth connection symbol 2075 indicates that the AMD600 is paired or available to pair with another electronic device.

FIG. 20C is a diagram of an exemplary therapy change user interface, in this case, a touch screen display 2002. The exemplary screen shown here may prompt the user 1827 to select one or more hormones for regulating the patient's blood glucose levels. The touch screen display 2002 presents the user 1827 with the option to choose between two hormones (e.g., insulin and glucagon) or to select both hormones. In the screen shown in FIG. 20C, the option selected by the user is "insulin only" 2008. The user 1827 is also given the option to select a "glucagon only" button 2012 or both an "insulin and glucagon" button 2004. If the user 1827 selects either of the options provided on the touch screen display, they can select a "next" button 2014 to complete the therapy change selection. In some instances, selecting the "next" button may provide the user with more options. For example, selecting the "next" section may prompt the user 1827 to select the amount of the hormone or hormones selected by the user 1827. In some implementations, the therapy modification user interface prompts the user 1827 to select a target blood glucose level, and the AMD device can automatically select a hormone (or combination of hormones) and determine the amount of the one or more selected hormones to be delivered during a therapy session to maintain the blood glucose level at the target level or within a margin of the target level.

20D is a diagram of another example of a user interface on the touch screen display 2016 supporting a therapy change by the user 1827. Here, the user 1827 is presented with a number of choices. One or more options within the therapy change user interface allow the user 1827 to make a therapy change selection. Other choices relate to other AMD functions (e.g., generating a therapy report, replacing a cartridge, etc.). The "Deliver Hormones" button 2030 allows the user 1827 to select a therapy change that delivers a blood glucose-regulating hormone to the user 1827. The "Test Blood Glucose" button 2018 allows the user 1827 to test the user's 1827 blood glucose levels. The "Generate Report" button 2020 generates a document reporting the therapy change delivered to the user 1827. The "Refill Cartridge" button 2022 allows the user 1827 to fill a cartridge within the AMD device 600 with medication. The "Upload to Cloud" button 2026 allows the user 1827 to send therapy change information to a cloud-based server. The "Audio Control" button 2024 allows the user 1827 to control the audio emitted by the AMD 600. The "Settings" button 2028 allows the user 1827 to manipulate one or more other settings of the AMD 600.

As described above, in some embodiments of the AMD, an alarm status indicator may be presented to the user via the user interface to alert the user to changes that have been made or occurred to the AMD configuration.

18 , a user 1827 may use the user interface 1808 to make a therapy change 1829 based on the procedure shown in FIG. 19 . When the therapy change procedure 1836 implements the therapy change, the AMD may alert the user that the therapy change has been implemented. A warning message or symbol may be presented on the user interface (e.g., touch screen display 1824) before and/or during the therapy change delivery 1807. For example, an alert indicator may notify 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 warning message or symbol. In some examples, the alert status indicator may be displayed after the user unlocks or activates the user interface using a wake action. In some examples, the alert status indicator may be displayed on the user interface when the user interface is inactive or locked.

21 is a flow diagram illustrating an exemplary method that may be used by an AMD to generate an alarm status indicator. In some embodiments, the device and patient monitoring procedures may continuously monitor the status of the AMD 2102 (e.g., the user interface, various modules of the AMD, etc.) as well as the patient's health status (e.g., using various patient sensors, such as analyte sensors). When the AMD receives a set of status information at block 2104, the device and patient monitoring procedures may determine whether the received status information meets an alarm condition at decision block 2106. If the received status information does not meet an alarm condition, nothing is done and the device and patient monitoring procedures continue to monitor the AMD and the patient. If it is determined that the received status information meets an alarm condition, the system may determine whether a wake signal has been received at decision block 2108. If a wake signal is not detected, the system waits for a wake signal to be received at block 2110. When a wake signal is received via one or more user interfaces or sensors, the CCM 610 (e.g., using the wake control 1834 and the therapy change control 1836) may generate a display of the touch screen lock screen interface in block 2112 and display one or more alarm status indicators on the lock screen corresponding to the detected alarm condition in block 2114. Alternatively, in some cases, the alarm status indicators may be generated and included in one or more user interface screens, such as the touch screen lock screen interface, regardless of the sleep or wake state of the AMD. However, in some cases, the alarm status indicators may not be presented to the user until the user wakes up the AMD and performs a wake interaction to cause the user interface screen to be presented.

In some cases, the additional status information may be received by the AMD at some point after the previous status information that met the alarm condition has been received. If the AMD determines that the additional status information meets an alarm condition for the AMD or the patient, 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 increase in the severity of the alarm condition via a different status indicator or a modification of the color or text associated with the status indicator. If the additional status information meets a different alarm condition, the additional alarm indicator may be displayed on a touch screen, lock screen, or interface of the AMD. On the other hand, if the additional status information indicates that the alarm condition has been resolved, the alarm indicator may be removed or modified to indicate the resolution of the alarm condition.

In some embodiments, the AMD may allow a user to provide a therapy change and then cancel the therapy change. The user may provide a therapy change by changing one or more control parameters of the AMD. FIG. 22 is a flow diagram illustrating an exemplary method that may be used to cancel a therapy change using a touch screen interface. The user may unlock the touch screen display using a wake action 2202 and access a therapy change user interface (e.g., using a first gesture) 2204, where one or more therapy control elements may be displayed. An indication of a change to the therapy control element may then be received by the user interface 2206, followed by confirmation of the change made (e.g., a second gesture) 2208. In response to receiving the indication of a change to the therapy control element and confirmation, the corresponding control parameter may be changed 2210 from a first setting to a second setting. In some examples, once the change is implemented 2210, the user may decide to cancel it, for example, after realizing that the requested change is incorrect. In these examples, the user may provide a third gesture 2212 on the touch screen. In response to receiving a third gesture from the user interface, the therapy change procedure can restore 2214 the modified control parameters to the first settings. In some examples, the third gesture can be a restore gesture. In some cases, the restore gesture can be a swipe gesture. In some examples, the swipe gesture can be performed in the vicinity or within an area of the therapy change user interface occupied by the therapy control element (or a particular portion thereof). An example of a restore swipe gesture can be a gesture performed from a start swipe position to an end swipe position located closer to the left edge of the touch screen than the start swipe position. For example, a user can place a finger at a point on the touch screen and drag the finger across at least a portion of the touch screen toward the left edge (e.g., reminiscent of a backward arrow). It should be understood that other gestures are possible for indicating a restore gesture. In some cases, a user can define a gesture to be used as a restore gesture. In some embodiments, the restore gesture is received on a different user interface screen than the therapy change user interface in which one or more therapy control elements are provided. In various examples, the restore gesture is performed in the opposite direction to a therapy change confirmation gesture that confirms the modification to the therapy control element.

In some examples, a restore gesture must be provided within a set time after a confirmation gesture is received by the user interface to cancel the therapy change request. In some such examples, during the set period, one or more dose control signals can be provided to the drug delivery interface to effect one or more therapy change deliveries. In some cases, a restore gesture can be received at any time after the confirmation gesture or therapy change. In some cases, the restore gesture restores a control parameter that was changed during the therapy change to its most recent value. In some cases, the restore gesture restores a control parameter to a value designated as a restore value (e.g., a default value or other designated restore value) or to the most recent value that maintained the patient's blood glucose level in a target set point range. The designated restore value may be specific to the patient or AMD, or may be determined based on clinical data for a set of patients. The set of patients may be patients who share certain characteristics with patients with AMD. For example, the set of patients may be the same gender, a similar age range, a similar severity of diabetes, etc.

In some cases, the system may allow the user to modify the therapy change before confirmation. In these cases, the user may modify the therapy control element a second time to change the corresponding control parameter from a second setting to a third setting.

In some examples, the third setting may be the same as the first setting. In some cases, the first setting or the third setting may be a default setting. In some cases, the first setting or the third setting may be a restore setting.

In some examples, the user may be able to cancel the therapy change delivery after confirming the therapy change and prior to therapy delivery based on the new settings. In some such examples, an alert may notify the user that therapy delivery based on the new settings is imminent. FIG. 23A is an illustration of a touch screen display 2300 alerting the user that delivery of one or more medications is about to occur. The alert may be accompanied by a sound or vibration effect. Here, the alert informs the user 1827 that medication delivery will occur in two seconds 2305. The touch screen display 2300 further allows the user 1827 to perform a gesture to cancel therapy delivery. The gesture to cancel delivery is a touch action starting with the small symbol 2310 and swiping left across the "Cancel" text. In the embodiment shown in FIG. 23A, a single gesture by the user 1827 can cancel the therapy change. In some cases, the input of a wake signal, a first gesture, a therapy change selection, and a second gesture are all required to cancel the therapy being delivered.

In some examples, a user may be able to cancel a therapy change delivery that was triggered based on a therapy change made by the user. In these examples, the user may use a wake action to access the user interface and provide a gesture to cancel an ongoing therapy delivery based on the therapy change delivery.

FIG. 23B is an illustration of touch screen display 2350 showing medication being delivered to user 1827. "Delivering" text 2355 informs user 1827 that medication is currently being delivered to user 1827. Progress bar 2360 is a graphical representation of the progress of the delivery. As shown in FIG. 23B, delivery has only begun and progress is not complete. Touch screen display 2350 allows user 1827 to perform a gesture to cancel delivery, which includes pausing and halting delivery if delivery has already begun but not yet completed. The gesture to cancel delivery is a touch action beginning with small symbol 2365 and swiping left across the "Cancel" text. In some examples, therapy change delivery 1807 can be canceled by user input including a wake action followed by a series of touch inputs (e.g., gestures, alphanumeric inputs, etc.).

Additional embodiments relating to interaction with ambulatory medication devices that may be combined with one or more embodiments of the present disclosure are described in U.S. Provisional Application No. 62/874,950, filed July 16, 2019, entitled "PREVENTING INADVERTENT"
No. 62/874,954, filed July 16, 2019, entitled "CAPACITIVE TOUCH WAKE BUTTON FOR AN AMBULATORY MEDICAL DEVICE," the disclosure of which is incorporated herein by reference in its entirety for all purposes.

Automatic resumption of drug delivery after manual suspension In some cases, it may be desirable to suspend the operation of an ambulatory drug device (AMD) or to suspend at least one delivery of one or more drugs to a patient by the AMD for a certain period of time. For example, it may be desirable to suspend drug delivery-related operations when a drug reservoir or cartridge in the AMD is empty or needs to be replaced. As another example, it may be desirable to suspend drug delivery when the ambulatory drug device is removed or moved to another part of the patient. In yet another example, it may be desirable to suspend drug delivery if the patient is taking or ingesting another drug that may be incompatible with the drug provided by the AMD. In some cases, when a patient suspends a treatment delivered by the AMD, the patient may forget to resume the treatment delivered by the AMD. In some cases, the patient's health condition may deteriorate during the suspension period, requiring treatment delivery to resume before the end of the suspension period. Therefore, there is a need for an AMD that allows a patient to safely suspend treatment for a temporary period of time (e.g., a temporary suspension period) and can automatically resume drug delivery as needed. Suspending delivery of the medication may include a processor of the AMD not generating a dose control signal during the temporary suspension period.

In some embodiments, the AMD may support treatment suspension and resumption procedures that allow a user (e.g., patient, parent, or guardian) to suspend all or a subset of treatments for a user-defined period of time and automatically resume one or more treatments at the end of the requested suspension period (e.g., a temporary suspension period) or when a threshold condition is met (e.g., a threshold condition related to the patient's health status). In some such embodiments, the AMD may be a monohormonal insulin pump. In some other embodiments, the AMD may be a bihormonal pump capable of administering insulin and a counterregulator (e.g., glucagon).

In an AMD that supports therapy interruption, inadvertent activation and/or resumption of therapy delivery can be dangerous (e.g., when the AMD is an insulin and/or glucagon infusion device). To mitigate this risk, in some examples, the AMD can be configured to avoid inadvertent interruption or resumption of therapy. For example, inadvertent activation of a drug delivery suspension can be prevented by requiring the user to perform a gesture (e.g., on a touch screen display or other type of user interface) to interrupt and/or resume therapy delivery by the AMD. In some examples, the gesture can be entered at a specific prompt provided on the user interface to activate or resume therapy interruption.

One particular application of treatment interruption with automatic resumption in AMD may be in the field of diabetes drug delivery. For example, patients may need the ability to suspend insulin delivery during situations such as exercise, which has a blood glucose-lowering effect. Suspending insulin delivery can prevent patients from entering a hypoglycemic state (extreme hypoglycemia), which can have severe complications. When treatment is interrupted, users may be at risk of entering a hyperglycemic state (hyperglycemia, which can lead to complications such as diabetic ketoacidosis or neurovascular complications) if they forget to resume drug delivery after exercise. Furthermore, patients' blood glucose levels may rise above or below dangerous levels during periods of exercise. In these situations, automatic drug delivery resumption may improve patient health.

In certain cases, the AMD may suspend one or more treatment deliveries when the AMD receives an indication that the treatment (e.g., medication delivery) should be suspended. The indication that the treatment should be suspended may be a command from a user. Often, the user is the patient, but users may also include other users who may have a voice or interest in the patient's care. For example, the user may be a clinician or other healthcare provider, or a parent or guardian.

In some examples, the indication that treatment or drug delivery should be suspended may be a command received via a user interface on the AMD or from another device that provides an interface to the user requesting that drug delivery be suspended. For example, the device may be a smartwatch, smartphone, laptop or desktop, or other control device capable of communicating via a wired or wireless connection with the AMD.

In some cases, an indication that therapy or drug delivery should be suspended may be received from the AMD itself. In some such embodiments, the AMD may suspend therapy or drug delivery in response to determining that one or more components or modules of the AMD do not meet minimum requirements for operation. For example, a signal to suspend drug delivery may be generated when the amount of drug available to the AMD device falls below a threshold (e.g., a cartridge or reservoir is empty or is below a minimum dosage). In some aspects, therapy suspension is based on loss of a sensor signal, such as loss of a glucose level signal.

FIG. 24 illustrates the interconnections between modules and procedures involved in receiving, accepting, and/or canceling a therapy interruption request in an exemplary AMD. In some examples, these procedures may be implemented in the CCM 2428 (and/or 610) of the AMD. In some embodiments, a user 2427 may make a request to interrupt one or more therapies (e.g., delivery of one or more medications to a patient) by providing input 2429 (e.g., start and stop times for the therapy interruption, selection of the type of therapy to be interrupted, etc.) via a therapy interruption user interface provided by a user interface module 2408 having, for example, a wake interface 2422, a touchscreen display 2424, and/or an alphanumeric pad 2426. The therapy interruption user interface may transmit the interruption request along with corresponding information to the CCM, and an interruption control procedure 2436 implemented in the CCM processes and transmits the therapy interruption signal to a device and patient monitoring and control procedure 2432. In some examples, the AMD may generate a warning before interrupting delivery of medication to the patient. The warning may indicate an interruption start time at which delivery of the medication will be interrupted. In some examples, to prevent inadvertent therapy interruption request entry 2429, the therapy interruption control procedure 2436 may include a therapy interruption request validation procedure to validate a therapy interruption request received from the user interface module 2408 or other device that may communicate with the AMD via a wired or wireless link (e.g., a smartwatch, smartphone, laptop, or desktop).

In some examples, when the patient monitoring and control procedure 2432 receives a request to discontinue therapy from the therapy control procedure 2436, it can send a signal to the medication dose control procedure 2430 indicating that dose control signals should not be sent to the medication delivery interface 2406 during the period requested by the user 2427.

In some cases, after receiving a request to suspend medication delivery, the AMD may delay suspending medication delivery in response to determining that the patient's medical condition meets a threshold medical condition. For example, the device and patient monitoring and control procedures 2432 may receive a signal from a patient sensor (e.g., a CGM sensor) indicating that the patient's blood glucose level is above a threshold level, and therefore will not suspend medication (e.g., insulin) delivery when timed as requested by the user. In some such examples, the AMD may suspend treatment if it determines that the patient's medical condition has improved and no longer meets the threshold medical condition.

In some cases, if certain preset or resumption conditions (e.g., one or more medical conditions of the patient) are met during the pause period, the device and patient monitoring and control procedure 2432 automatically resumes therapy delivery by sending a signal to the drug dose control procedure 2430, which generates and provides a dose signal to the drug delivery interface 2406. In some examples, after determining that a resumption condition has occurred as discussed herein, a dose control signal may be generated for the next scheduled administration period. In some examples, a dose control signal may be generated immediately after determining that a resumption condition has occurred. In some examples, the AMD may generate an alert in response to determining that a resumption condition has occurred. The alert may indicate that the patient's medical condition meets a threshold medical condition. In some examples, if, during the pause period, the AMD determines that the levels of one or more analytes in the patient's blood and/or interstitial fluid are above or below a set threshold (e.g., based on signals received from the patient sensor 2420), drug delivery to the patient 2427 may be resumed by sending a dose control signal to the drug delivery interface 2406. For example, if a signal received from a glucose sensor (e.g., a CGM sensor) indicates that the patient's blood glucose level is above a certain threshold level, delivery of insulin to the patient can be resumed to reduce the level of glucose in the patient's blood. In some cases, if a signal received from a glucose sensor (e.g., a CGM sensor) indicates that the patient's blood glucose level is below a certain threshold level, delivery of insulin to the patient can be resumed to reduce the level of glucose in the patient's blood. In some examples, if, during the suspension period, the patient's medical condition meets a threshold medical condition, the AMD can generate a warning indicating that the medical condition has met the threshold medical condition. In some such examples, the AMD can display the warning 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 wirelessly connected to the AMD).

To prevent inadvertent activation of an interruption, a user can initiate a therapy interruption request beginning with a wake action (e.g., received by wake interface 2422 and processed by wake control procedure 2434) that activates the user interface module 2408. The user can use a first interaction with the user interface (e.g., a touch screen display) to unlock a therapy interruption user interface where information regarding the therapy interruption is provided. The user can then use a second interaction with the user interface to confirm the requested therapy interruption. In some examples, the system can allow access to the therapy interruption user interface and accept the interruption request only if both the first and second interactions with the user interface are verified by therapy interruption control procedure 2436.

In some examples, the therapy interruption control procedure 2436 may receive a request for interruption and interruption information from another local or remote device connected (e.g., wirelessly) to the AMD. For example, a user may use a smartwatch or smartphone to send a therapy interruption request to the AMD.

The interruption information provided by the user may include a set of parameters required for interruption. For example, the interruption information may include dates and/or times for starting and ending the treatment interruption, thresholds required to define threshold conditions that may trigger early resumption of treatment delivery, etc. In some examples, the interruption information may indicate that the treatment interruption should occur at a specific time (e.g., interruption start time) or after a specific event (e.g., after the next dose of medication is delivered or after the patient's condition reaches a specific state, such as the middle of a desired blood glucose range). In some examples, the thresholds may be associated with input provided by patient sensor 2420 or other types of sensors that may be used to monitor one or more parameters related to the health status of user 2427.

The parameters for the pause may include a pause start condition and a pause stop condition. The pause start condition may be a condition that, when met, activates the pause. In some such examples, the start condition is met when a timer expires. Similarly, the pause condition is a condition that, when met, terminates the pause. In one example, the pause condition is met when a timer expires (e.g., a temporary pause period). In another example, the pause condition is met when a threshold is met. The threshold may be related to a measurement made by the AMD (e.g., by the patient sensor 2420), such as the measured blood glucose level of the patient 2427. The threshold may be met if the blood glucose level is above, below, or matches a set blood glucose level. In some examples, the pause information received from the user may include multiple conditions. For example, a time condition and a threshold condition may be set simultaneously. In such an example, for example, if the user's glucose concentration meets a threshold, the suspension may terminate earlier than the set time.

In some cases, the request to suspend therapy may include an indefinite suspension period. In other words, the request may not include a user-specified period or identification of a resume condition (e.g., no user action to trigger the resume condition, or no user action). In some cases, the instructions may include a request to temporarily suspend delivery of therapy for a defined period (e.g., a temporary suspension period) or until a further interaction or event occurs. Thus, a resume condition may include the expiration of a time period (e.g., expiration of a temporary suspension period) or an active event (e.g., a patient command or determined condition). Furthermore, the therapy being suspended may include any type of therapy. For example, the therapy being suspended may be the suspension of delivery of a medication, which may include insulin, a counterregulator (e.g., glucagon), or both insulin and a counterregulator. In some cases, the AMD may be capable of and/or configured to administer multiple medications (e.g., both insulin and a counterregulator). In some such cases, the request to suspend therapy may include a request to suspend one of the medications (e.g., insulin or a counterregulator) or both.

In some examples, an interaction with a user interface may include selecting an icon, a series of taps or inputs, one or more gestures (e.g., swiping or other simple or complex movements across a touch screen), performing a pattern or sequence on a touch screen (e.g., drawing an image), a multi-touch or multi-input interaction, a combination of the above, or any other type of interaction with a touch screen, or portions thereof. The series of inputs may be any combination of touch movements, touch points, numbers, alphabetic characters, and other symbols. In some examples, the first user interaction and/or the second user interaction may include a predetermined sequence of numeric or alphabetic inputs. In some examples, a series of multiple inputs, a range of parameters for the inputs may depend on other inputs in the series. For example, the required starting position of a touch action may depend on the position of a previous touch action. The time over which the series of inputs is entered may be part of a range of parameters. For example, the series of inputs may need to be entered in greater than or equal to 3 seconds, or less than or equal to 15 seconds. In some cases, 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 a command to interrupt the delivery of therapy.

Furthermore, one or more of the interactions may include interacting with a sensor such as an optical sensor (e.g., a visible light or IR sensor), a biometric sensor (e.g., a fingerprint or retinal scanner), a proximity sensor, a gyroscope, or a combination of an accelerometer and a gyroscope. Also, in exemplary embodiments, the second user interaction may occur via a wireless signal such as RFID or Bluetooth. In some embodiments, the second user interaction may include receiving a selection of an indicator box corresponding to either insulin or glucagon and receiving a predetermined series of numeric inputs to deliver the therapy change selection.

The type of user interaction that unlocks the touch screen, provides access to the treatment interruption user interface, or confirms the interruption request may be the same or different.

In an exemplary embodiment, the system may have a timeout, where if no interaction occurs for a set period of time at each step in the treatment interruption request process, the user interface is turned off and the treatment interruption request process must be started again. In one implementation of the timeout, if no interaction occurs for more than 30 seconds after the system is started/unlocked before a second user interaction is received by the user interface, the user interface is disabled.

FIG. 25 is a flow diagram illustrating an exemplary method for receiving and implementing a pause request that may be implemented by an AMD. In this example, a user may request and confirm a therapy pause using a touch screen interface. When the user activates the touch screen using a wake operation 2502, the AMD may wait for a first gesture on the touch screen. After the user provides the first gesture and the gesture is verified by the therapy pause control procedure 2436, a therapy user interface may be activated 2506, and the user may request a therapy pause and provide pause information 2508 (e.g., start date/time (e.g., pause start time) and stop date/time (or pause duration) and/or resume conditions). The AMD may then wait 2510 for a second gesture on the user interface. If the second gesture is received and verified by the therapy pause control procedure 2436, therapy delivery is paused 2512. If the second gesture is not received or verified by the therapy interruption control procedure 2436, the therapy interruption control procedure 2436 may determine 2514 whether a set time has elapsed since receiving the therapy interruption request. If it is determined that the set time has elapsed since receiving the therapy interruption request, the request is canceled and the touch screen is locked 2516. If it is determined that the time since receiving the therapy interruption is less than the set time, the AMD may wait for a second gesture to be received.

In some examples, when a wake action is received 2502, the AMD can automatically activate 2506 a therapy interruption user interface without requiring a first gesture 2504. In these examples, when a therapy interruption request is received 2508, a gesture (e.g., a first gesture) may be required to validate the request. In some such examples, once therapy delivery is interrupted, a second gesture can stop the interruption before any of the conditions of the stop parameters are met. This allows the user the flexibility to modify the initiated interruption.

26 is a diagram 2600 of several exemplary screens that may be displayed on the touch screen display 2424 of the AMD when a user activates a therapy interruption user interface. Screen 2602 illustrates a screen that the AMD may display to the user 2427 when the user provides a wake action. The therapy interruption system 600 is not limited to the display shown in FIG. 26. Various other screens may communicate the same information shown in FIG. 26 to the user 2427. Screen 2602 allows the user 2427 to select various functions. The pause button 2603 shown in screen 2602 is a function that pauses delivery of medication to the user 2427. When the pause button 2603 is selected, a pause screen 2604 may be displayed on the touch screen display. The pause screen 2604 allows the user 2427 to select the duration of the medication suspension (e.g., a pause period or a temporary pause period). The AMD 600 may display various interfaces that allow the user 2427 to select the duration of the medication suspension. The exemplary pause screen 2604 shows a simple interface, giving the user 2427 one of two duration options (e.g., 1 hour and 2 hours).

Once the user 2427 selects a duration on the pause screen 2604, the pause screen 2606 displays the duration selected by the user 2427 (e.g., the illustration shows the user 2427 selecting a duration 2607 of one hour, thus suspending drug delivery for one hour after suspension begins). The pause screen 2606 includes a prompt 2608 for the user to perform a gesture to confirm the requested suspension before starting drug suspension. As indicated by the prompt 2608, the user 2427 is prompted to swipe right on the bottom of the screen. Once the user 2427 performs a gesture to start drug suspension, a pause screen 2610 appears on the touch screen. The pause screen 2610 notifies the user 2427 that the drug has been paused. On the pause screen 2610, the user 2427 has the option to perform another gesture to unlock the AMD 2612 if the user wishes to end the pause and/or access other features of the AMD 600.

The interruption of drug delivery may occur by not generating a dose control signal to deliver a dose of drug during the interruption period. Alternatively or additionally, the interruption of drug delivery may occur by sending a signal to the drug delivery interface to stop providing therapy or drug to the patient.

In some cases, the AMD may not immediately interrupt therapy upon receiving a command to interrupt therapy. For example, if the AMD is in the process of delivering medication or the patient's condition indicates that medication may soon be needed to maintain the patient's condition (e.g., blood glucose) within a particular state (e.g., within a desired blood glucose range), the interruption of therapy may be delayed until at least a time when medication is not being delivered or is not predicted to be needed during the interruption period, or until the next therapy is being delivered. In some such cases, the AMD may inform the user that the interruption of therapy is being delayed. The AMD may also indicate the reason for the delay. In some cases, the user may override the delay and request an immediate cessation of therapy. For example, if the user is changing a medication cartridge, the user may override an indication that the interruption of therapy should be delayed, e.g., to the interruption start time. In some cases, the requested start time may be overridden by a patient-determined condition. The AMD may delay the interruption of therapy delivery in response to determining that the patient's condition meets a threshold condition.

The interruption in treatment or drug delivery may continue until a resumption condition occurs. In some cases, when a resumption condition is met, the interruption period may end automatically without any action by the user or patient.

Resume conditions may include the expiration of a period of time (e.g., a temporary suspension period), a command from a user (e.g., a patient), detection by the AMD device of a condition (e.g., a medication being refilled), a patient condition meeting a specific criterion (e.g., a patient's blood glucose level falling below or exceeding a threshold range), or any other condition that satisfies a reason for or overrides a request to suspend therapy. For example, a drug delivery device may be configured to automatically resume drug delivery when a glucose threshold is reached or exceeded. This threshold may be set at, for example, 300 mg/dL. Resume conditions may include detection of hypoglycemia or hyperglycemia, or an imminent risk of a hypoglycemia or hyperglycemia event. Additionally, resume conditions may include a meal notification or "end of exercise notification," a motion-sensing event, the suspension of another administered medication, the conclusion of an undefined suspension length (e.g., during a cartridge change), a rate-based resume event, a location-based resume, a remote resume in case of an emergency (e.g., directed by caregiver management software or a clinician), or any other type of resume event. In some cases, the restart conditions may include a combination of criteria.

In some cases, automatically resuming treatment may include suspending treatment before the expiration of the suspension period. For example, treatment may be resumed if the condition that caused treatment to be suspended is resolved before the expiration of the suspension period.

In some cases, once a resume condition (provided by the user) is met, the AMD may verify that one or more additional conditions of the ambulatory medication device are met before therapy is resumed. For example, if the AMD determines that the medication has not been refilled or there is an issue with the refill (e.g., the cartridge is not properly installed), the AMD may continue to maintain therapy suspension despite a trigger to resume therapy.

FIG. 27 is a flow diagram illustrating an exemplary method for automatic resumption of a suspended therapy that may be implemented by an AMD. When a therapy suspension is requested and confirmed by a user (e.g., using the procedure shown in FIG. 24) 2702, the AMD suspends delivery of one or more therapies 2704 selected for suspension at the suspension start time received as part of the suspension information. For example, the therapy suspension control procedure 2436 may suspend the medication dosage control procedure 2430 using the device and patient monitoring and control procedure 2432. During the suspension period, the therapy suspension control procedure 2436 may continuously monitor the system clock and patient and device status (e.g., steps using the medication dosage control procedure 2430).

If the therapy interruption control procedure 2436 determines 2708 that the time elapsed since the start of the interruption is less than the requested interruption duration 2706 and none of the conditions for resumption have been met, the therapy interruption may continue. If an interruption-resume condition occurs, one or more interrupted therapies are resumed 2712.

If the therapy interruption control procedure 2436 determines 2706 that the time elapsed since the start of the interruption is equal to the requested interruption duration, or if it determines 2708 that one or more resume conditions have been met, it may check other AMD or patient conditions (not included in the therapy interruption information) to determine if therapy delivery can be safely resumed 2710. If it determines that therapy delivery cannot be safely resumed, a warning message may be sent to the user interface to inform the user of the reason for such determination 2714.
If it is determined that therapy delivery can be safely resumed, one or more interrupted therapies are resumed 2712.

In some examples, if a third interaction with the user interface (e.g., a gesture) is detected, a treatment interruption can be terminated before one or more conditions for terminating the interruption are met. The third user interface interaction may be detected by the user interface module 2408 and transmitted to the treatment interruption procedure 2436. If the treatment interruption procedure 2436 confirms that the third interaction with the user interface is a predetermined third user interface interaction, the device and patient monitoring and control procedure 2432 can activate their medication dosage procedure 2430. This may provide the user with the flexibility to terminate an active pause during the pause period (second interaction with the user interface) set by the user prior to confirmation. In some cases, the user may decide to terminate a treatment interruption in order to change one or more interruption conditions set prior to the activation of the current treatment interruption. In some examples, the user may decide to terminate a treatment interruption due to a change in the user's health status that is not included in one or more treatment resumption conditions provided prior to the activation of the current treatment interruption. In some examples, the user may need to provide a fourth gesture to terminate the interruption before one or more conditions for terminating the interruption are met. Like the first and second gestures, the third and fourth gestures can be simple or complex.

FIG. 28 is a diagram 2800 of several exemplary screens that may be displayed on the touch screen display 2424 of the AMD when a user 2427 resumes a suspended treatment. Screen 2802 informs the user that medication delivery is currently in suspended mode. Screen 2803 also shows the user 2427 the current glucose concentration in the user's blood. In some examples, various biometric measurements useful to the user 2427 may be displayed on screen 2802 that may be displayed during the treatment suspension period. In one embodiment, the treatment suspension ends when the glucose concentration in the user's blood meets or exceeds a threshold value.

Screen 2804 may be activated by user interaction (e.g., a gesture on a touch screen display) to allow user 2427 to select and perform various functions on AMD 600. For example, resume button 2805 may be used to end a treatment pause. When resume button 2805 is selected by the user, resume screen 2806 may be displayed on the touch screen display. Resume screen 2806 has a prompt 2807 that prompts user 2427 to perform a gesture. In the illustrated example, user 2427 is prompted to swipe right on the bottom of resume screen 2806 within resume screen 2807. The requirement to perform a gesture to resume medication delivery prevents user 2427 from inadvertently resuming medication delivery by the AMD.

When the user 2427 performs a gesture to resume medication delivery, a resume screen 2808 appears on the display, indicating that the treatment pause has ended and normal medication delivery has resumed. Once the resume screen 2808 has been displayed to the user 2427 for a sufficient period of time (to inform the user 2427 that the pause has ended), a lock screen 2810 may be displayed. The lock screen 2810 prevents the user 2427 from inadvertently performing more functions on the AMD device 600 after resuming medication delivery.

24 , in some examples, if the treatment interruption procedure 2436 determines that a resume condition has been met or receives user input 2429 from the user interface module 2408 indicating that the treatment interruption should end, they can use the device and patient monitoring and control procedure 2432 to invoke the drug dosage procedure 2430. Thereafter, if the drug dosage control procedure 2430 determines (based at least in part on information received from one or more patient sensors 2420) that a dose of drug should be delivered to the user, it can provide a dose control signal to the drug delivery interface 2406. In some examples, after determining that a resume condition has occurred as discussed herein, a dose control signal can be generated for the next scheduled administration period. In some examples, a dose control signal can be generated immediately after determining that a resume condition has occurred.

In some cases, the AMD device may alert the user and/or patient that treatment is being resumed. This alert may occur before generating the dose control signal and/or after or when a resume condition is met (e.g., a pause time expires).

Additional embodiments relating to suspending drug delivery to a patient that may be combined with one or more embodiments of the present disclosure are described in U.S. Pat. No. 6,629,497, filed Oct. 4, 2019, entitled "METHOD FOR SUSPENDING DELIVERY OF A DRUG INFUSION" and entitled "Drug Infusion Disorders and Therapeutic Devices for Patients with Disorders."
No. 62/910,970, entitled "DEVICE WITH AUTOMATIC RESUMPTION OF DELIVERY," the disclosure of which is incorporated herein by reference in its entirety for all purposes.

AMD with security features
For example, an ambulatory medical device (AMD), such as, but not limited to, an ambulatory medication device (e.g., an insulin pump) that provides life-saving treatment to a patient based on the patient's condition, may include a user interface (e.g., a touch screen display) that allows a user to change settings on the AMD. Settings may include, but are not limited to, symptoms that trigger delivery of medication to the patient, the amount of medication delivered when the symptoms are met, the type of medication, etc. Settings may also include features of the AMD that may not be directly related to medication delivery (e.g., screen brightness, alarm sounds, etc.). In some instances, it may be desirable to manage access to various settings on the AMD to prevent inadvertent changes while allowing changes that may be necessary for uninterrupted, proper operation of the AMD. For example, it may be desirable to restrict access to some settings to certain authorized users (e.g., a healthcare provider) and allow access to some other settings to other authorized users (e.g., the patient, the patient's guardian, or a parent).

In many cases, a healthcare provider can change the settings of the AMD. However, it is often desirable for a non-healthcare provider to modify at least some of the settings of the AMD. For example, when the AMD runs out of a threshold amount of medication or has less than a threshold amount of medication, it is often desirable for the user to be able to refill or replace the medication cartridge without visiting a healthcare provider. In some cases, changing the medication cartridge may involve interacting with the 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 patient, parent, or guardian) to change the settings of the AMD is when the initial settings of the AMD are not providing the desired effect (e.g., delivering enough medication, too much medication, medication too slowly or too quickly, etc.). In some cases, successful maintenance of the AMD and/or patient may require interaction with the AMD settings and/or controls. For example, if the AMD remains connected to the patient at the same site for more than a threshold period (e.g., more than 2-3 days, more than 5 days, more than 1 week, etc.), negative consequences may begin to occur. Thus, the AMD may need to be periodically moved from one location on the patient to another location on the patient (e.g., left to right side, arm to leg, stomach to back, etc.). Changes in location may require interaction with the AMD's settings (e.g., pausing operation until the field change is complete).

As explained above, while there are several reasons why it may be desirable to allow users other than healthcare providers (e.g., patients receiving treatment, parents, or guardians) to access at least some of the AMD user settings, it may also be desirable to regulate access to at least some of the AMD settings. For example, it is generally undesirable for children (patient or otherwise) or users under a certain age to access AMD settings that, if modified, could cause harm to the patient. Additionally, it may be undesirable for certain patients with reduced mental capacity, regardless of age, to access at least some of the AMD settings.

The user may be the patient receiving the medication or treatment, or may be another user, such as a clinician or healthcare provider, or the patient's parent or guardian.

One solution to regulating access to the AMD's settings is to implement a locking feature that requires a user to provide a passcode, password, or other information before being allowed to change the AMD's settings (e.g., control parameters). For simplicity, this disclosure will be described using a passcode. However, it should be understood that the passcode can be replaced with a password or any other type of secret or semi-secret information. A user can enter a security code into the AMD or intermediate device, and the AMD and/or intermediate device can confirm or verify that the passcode matches in order to access certain features of the AMD as described herein. If the security code cannot be verified after a predetermined number of security code entry attempts, further security code entry attempts can be rejected for a period of time. In some examples, when the AMD is in a locked state, it can continue to deliver therapy to a patient at the same rate as in an unlocked state.

The lock feature may be activated by default or may be activated by the user. In some examples, the lock feature may be enabled via a setting within a control menu of the AMD device provided on a user interface (e.g., a touchscreen display). The setting may include an on/off toggle (e.g., via a software interface element or a hardware interface element), and when the toggle is on, a passcode (e.g., a 4- to 8-digit number) may be required. In some cases, when the lock feature is on, a passcode (e.g., a 4- to 8-digit number code) may be required to turn the lock feature off. Once the lock feature is activated, the user can program the AMD with a user passcode selected by the user. Alternatively, or in addition, a user passcode may be set in response to a passcode change request. In some cases, the user passcode may expire. In such cases, the user may be required to generate a new passcode after the previous passcode has expired or before the previous passcode is allowed to expire. In some cases, the AMD may generate a new passcode periodically (e.g., an override passcode) or when the user provides a passcode.

In some cases, the user interface elements used to access a user interface that allows one or more settings of the AMD to be changed may be different from the user interface for changing the control parameters associated with that setting. For example, a keypad may be used to enter a passcode to unlock the user interface for changing the control parameters, and a touch screen may be used to change the control parameters.

In some examples, when the lock feature is enabled, the user interface screen may look and function the same as when the lock feature is not enabled. In these examples, when the lock feature is enabled, a passcode entry interface (e.g., a keypad user interface element) may be displayed when a visual guide to unlock the device (e.g., a linear unlock slider, an arcuate unlock slider, or another unlock user interface element) is activated. If either the user passcode or another passcode (e.g., a global override passcode) is entered, the user interface may proceed normally. Otherwise, the user interface may return to the original lock screen.

In some examples, a user action that allows a user to change one or more settings of the AMD may be different from a wake action that activates a user interface. For example, a wake action may be used to activate a touchscreen display that can display multiple user-selectable elements, some of which may be accessible without a passcode. In such examples, a subset of the user-selectable elements, e.g., a subset that allows a user to change therapy control parameters, parameter control elements, or user parameter control elements, may require a passcode. In some cases, access to each user parameter control element may require a different passcode. In some examples, providing a passcode to a locked AMD may directly enable access to a subset of the parameter control elements. In some examples, a first gesture may be required after the user interface (e.g., touchscreen display) is activated and before the multiple user-selectable elements are presented.

To aid in passcode recall, the passcode may be set by the user, allowing the user to select a passcode that the user is more likely to remember. However, regardless of who sets the passcode, there is a risk that the user may not remember the passcode. Due to the nature of the device (e.g., a device capable of providing life-saving care), it is desirable for certain users not to be restricted from accessing certain settings of the AMD, and to be able to gain access to certain settings quickly (e.g., within seconds, minutes, before the next treatment event, or before harm may occur to the patient) when needed. Thus, while some non-medical devices may implement lockout periods or other restrictions to prevent malicious users from attempting to brute-force determine the device's passcode, such features may generally be undesirable for ambulatory medication devices. Accordingly, embodiments disclosed herein include AMDs that include an override passcode that allows access to the AMD (or its control settings) regardless of whether a user passcode is provided.

In some examples, the passcode or override passcode may be a series of taps, a series of inputs, a complex or simple gesture (e.g., a swipe or other movement across a touch screen). The series of inputs may be any combination of touch movements, touch points, numbers, alphabetic characters, and other symbols. In some examples, the time over which the series of inputs is entered may also be part of a parameter range. For example, the series of inputs may need to be entered in greater than or equal to 3 seconds, or less than or equal to 15 seconds. An example of a complex gesture is a swipe.

In some examples, the passcode or override passcode may include performing a pattern or sequence on a touchscreen (e.g., drawing an image), multi-touch interaction, or any other type of interaction with the touchscreen, or a portion thereof. Another example of a complex gesture is entering a predetermined series of touches. In some cases, the passcode may include a quiz or set of questions.

In some examples, the AMD may be configured to receive therapy settings or therapy setting changes from an intermediate device via a communications connection. For example, the intermediate 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. In some cases, this functionality may be supported in addition to providing a user with the option to change one or more settings using a user interface of the AMD. The communications connection between the intermediate device and the AMD may be a direct connection, e.g., via Bluetooth, or a connection over a network, such as a local area network or a wide area network. In some such cases, the AMD may include a wireless transceiver, such as an NB-LTE transceiver, a Wi-Fi transceiver, or a Bluetooth transceiver. The intermediate device that provides a user with a user interface for changing the AMD's settings may include any type of device (e.g., a computing device) capable of communicating with the AMD. In some cases, access to the intermediate device's user interface that allows for changes to the AMD's settings may require a passcode. In some examples, the passcode required to change one or more settings via an intermediate device may be different from the passcode required to change the same settings using the AMD's user interface directly.

In some such cases, the user can provide a user-generated or override passcode through the interface of the intermediate device. The intermediate device can then provide the user-generated or override passcode to the AMD via a network connection between the devices.

In some examples, even when the AMD is in a locked state, certain intermediate devices may have access to a user interface that can be used to change one or more settings (e.g., treatment settings) of the AMD. For example, a guardian's or patient's parent's smartphone may be used to change one or more settings of the AMD while the AMD is in a locked state.

The embodiments disclosed herein are applicable regardless of whether the user interface for changing treatment settings or configuration of the AMD device is generated or presented to the user by the AMD or presented via another device.

In some examples, the AMD may be configured to receive a passcode from or through a computing system (e.g., a cloud computing system). In these examples, the AMD may receive the passcode through a direct end-to-end connection established with the computing system (e.g., a wireless connection over a wide area network). In some such examples, another computing device connected to the computing system (e.g., a smartphone, laptop, personal computer, etc.) may send a passcode to the AMD, which, if the passcode is verified by the AMD, may modify one or more settings of the AMD.

If a user cannot remember the user passcode, the user can gain access to a user interface that allows modification of control parameters by providing an override passcode. In some examples, the override passcode may be a universal fixed passcode (e.g., an 8-digit override passcode) that can be used in place of a user-configured passcode. The override passcode may be stored in the AMD at the time of manufacture, shared among multiple AMDs (e.g., a global override passcode), or unique to a particular AMD. The override passcode may be managed by the manufacturer or a third-party service. To obtain the override passcode, the user can contact the manufacturer or a passcode management service. Generally, a passcode may be enabled to prevent users with reduced mental capacity (e.g., children) from changing the settings of the AMD. Therefore, security is not as important, and the user can contact the manufacturer or a passcode management service to obtain the override passcode. In some such cases, a single global override can be used for all devices manufactured by the manufacturer. However, in some cases, a level of security may be desired. In such cases, the user may be required to authenticate themselves. Additionally, the user may be required to provide the serial number of the AMD. In some cases, each model or unit of an AMD may have a different override passcode. A user can provide authorization information and the serial number of the ambulatory medication device to the manufacturer or a passcode management service to obtain an override passcode.

In some examples, the AMD may generate a new override passcode periodically or may generate an override passcode when the user supplies a passcode. In these examples, the AMD may generate the override passcode using the same parametric values that another device can use, thereby ensuring a match between the override passcodes. Advantageously, in some cases, using an algorithm to generate the override passcode allows the user to obtain the override passcode regardless of whether the user can contact the manufacturer or other passcode management service. In some cases, the user may generate the override passcode without network or telephone access, for example, using a computing device that has access to common parameter values as the AMD.

In some cases, the override passcode changes over time or may be a rotating passcode. For example, in some cases, the override passcode may change at periodic intervals, such as every 30 seconds, every minute, every hour, etc. In such cases, the override passcode may be determined from an algorithm executed by an application. The AMD may store a copy of the algorithm in its memory and execute the algorithm to determine the currently active override passcode. The copy of the algorithm may be executed by a separate computing device accessible by the user. The output of the algorithm may be based on values publicly accessible by the AMD and a copy of the algorithm accessible by the computing device. For example, the output of the algorithm may be generated based on time, a user identifier, a provided value, or any other factor that can be used to repeatedly generate the same output. In some cases, 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 the AMD's serial number or model number and the time. The override passcode determination may be calculated by an application on the AMD, a computer server, and/or the user device.

In some cases, the override passcode may be received automatically by the AMD (e.g., after the user requests the override passcode). Thus, the 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). For example, the override passcode may be texted to the user's smartphone, for example, for the user to enter the override passcode into the AMD. In some cases, the override passcode may be received in a coded manner that may be incomprehensible to a child with reduced mental capacity or the user.

In some cases, the override passcode may be linked to a location. For example, the override passcode may only be enterable at a healthcare provider's office or at the patient's residence. Determining the location of the AMD is based on a geolocation system available to the AMD (e.g., a global positioning system (GPS)).

In some examples, for at least a subset of the treatment settings, the passcode may provide a second level of security in addition to other interactions with the user interface (e.g., first and second gestures on a touch screen display) that may be used to change the treatment settings and/or accept changes made to the treatment settings. In some examples, for at least a subset of the settings, the passcode may be used in place of other interactions with the user interface (described above).

As described above, upon interaction with a user interface, the AMD, or other device capable of modifying control of the AMD, may present a passcode entry screen to the user. The user may enter the passcode to unlock additional user interface features, including, for example, a user interface that allows the user to modify at least one control parameter of the AMD. The control parameter may be modified based on interaction with a parameter control element of the user interface. Additionally, a change in the control parameter may cause a change in the generation of a dose control signal generated by a control algorithm based at least in part on the control parameter.

In some embodiments, the AMD may have an advanced therapy screen or other user interface that allows a healthcare provider or other user to obtain additional details or advanced settings regarding the therapy provided by the AMD. Advanced therapy screens or states may generally be targeted to knowledgeable users, such as clinicians, although in some cases, any user may gain access to the advanced therapy screen or state. An advanced therapy screen (e.g., displaying advanced settings for the AMD) may allow a healthcare provider to change control parameters (e.g., advanced control parameters via one or more advanced parameter controls) that may not be modifiable by other users. For example, a healthcare provider may control parameters related to the rate of insulin accumulation, the rate at which insulin decreases in the patient's blood, setting a glucose setpoint, and calculating a therapy attack level or factor related to the amount of insulin to be delivered when the patient's glucose level is outside a setpoint range or when insulin reaches a maximum concentration point (e.g., T _max ) in the patient's blood.

Access to the advanced therapy screens may be restricted by a passcode or advanced settings passcode requirement, for example, via a user entering a security code or advanced settings security code (e.g., using one or more advanced settings parameter control elements) that can be verified or validated to match the passcode or advanced settings passcode. The passcode or advanced settings passcode is sometimes referred to as a clinician passcode to distinguish it from a user-generated passcode and/or an override passcode. This clinician passcode may or may not be generated by the user. However, the clinician passcode may be separate from a user-generated passcode that allows access to non-advanced therapy screen interfaces. Furthermore, the clinician passcode may be separate from an override passcode that allows a user to override a user-generated passcode to gain access to a non-advanced therapy screen interface. In some instances, the clinician passcode may be used as an override passcode. In some examples, the clinician passcode may be valid for a certain period of time (e.g., set by the patient or another authorized user, such as a guardian or apparent patient). The clinician passcode may expire after a predetermined period of time. For example, a clinician passcode may be valid for one day, one week, or one month (expiring at least once per day, week, or month). In some examples, the AMD may allow certain authorized users to terminate clinician access at any time.

In some cases, access to an advanced therapy screen or state may be limited to a specific time period. After the time period expires, the AMD may automatically restrict access to the advanced therapy screen or state. In some cases, the access window may be extended. For example, if a healthcare provider continues to interact with the advanced therapy screen or state, the screen or state may remain accessible.

In some cases, the advanced therapy screen may offer additional features. For example, the user may indicate that the amount of insulin provided should be more or less for a meal or correction factor, while the healthcare provider may specifically adjust the amount of insulin. Additionally, while user instructions may or may not be adhered to depending, for example, on whether demand exceeds a threshold or blood glucose levels may not meet a set range, instructions provided via the advanced therapy screen may be adhered to regardless or may have a wider range or different threshold that can control whether instructions are adhered to. Additionally, the advanced therapy screen may be used to temporarily pause therapy and/or prevent patient access.

In some cases, the manufacturer of the AMD may provide a remote unlock signal that can be used to unlock access to advanced treatment screens or status on the mobile medication device and/or the AMD.

As mentioned above, a passcode may be desirable to prevent certain users from inadvertently changing certain control parameters of the AMD device. However, features of the AMD that do not affect therapy may remain accessible to the user when the AMD is in a locked state. For example, the user may have access to therapy history, screen brightness settings or color, or any other feature that is unlikely to cause harm to the patient if changed in a particular way. Furthermore, because the passcode feature is generally intended to prevent changes to control parameters, the AMD can continue to provide therapy at the same speed and under the same conditions whether the AMD is locked or unlocked.

When the AMD receives a user passcode or an override passcode, the AMD may verify the passcode. The passcode may be verified by comparing the received passcode with a passcode stored in the AMD's memory or a passcode generated by the AMD. If the passcode received from the user is successfully verified, the user may be granted access to a user interface to modify one or more control parameters. In some cases, the user may be requested to re-enter the passcode to confirm the changes to the control parameters. In some examples, the user may be requested to provide a gesture on a touch screen to confirm the changes to the control parameters.

If the passcode is not verified, the AMD, or other control device that can provide access to the AMD's control parameters, can prevent access to a user interface for changing one or more control parameters. In some cases, a user interface that presents a user with the ability to enter a passcode can allow the user to enter the user passcode a specific number of attempts or a specific number of attempts within a specific period of time. If the correct user passcode is not entered within the provided number of attempts or within a specific period of time, the user interface can enter a locked state (e.g., the screen turns off) and prevent further attempts to enter the passcode for at least a certain period of time. In some cases, the user passcode option may be locked or blocked indefinitely. In some such cases, the AMD's control parameters may only be accessible if an override passcode is provided. Alternatively or additionally, a user passcode of a different user can be used to provide access to the AMD's control parameters. In some examples, if the correct override passcode is not entered within the provided number of attempts or within a specific period of time, the user interface can block any attempt to change the override passcode for at least a certain period of time.

In some cases, once the passcode is successfully entered or verified, the user may be able to disable the passcode functionality of the AMD. Disabling the passcode functionality may require the use of a separate or override passcode in addition to the user passcode.

In some cases, a passcode may be optional or omitted based on the computing device connected to the AMD. For example, if an end-to-end connection is established between a smartphone registered to a particular user (e.g., a patient's parent), the mobile medication device may automatically unlock without requiring a passcode. In some cases, the smartphone or other computing device may automatically provide a user-generated or override passcode to the AMD upon establishing a connection. In some cases, the AMD may automatically unlock when connected to a charger or when in a particular geographic area. For example, a geofence may be configured around one or more locations, such as a patient's home or a clinician's office. If the AMD determines that it is within the geofence, the AMD may automatically unlock. Similarly, if the AMD determines that it is not within the geofenced area, it may automatically lock. Determining the location of the AMD may be based on a geolocation system, such as the Global Positioning System (GPS).

In some cases, after a certain number of unsuccessful passcodes have been entered (e.g., after five attempts), the user interface screen may be turned off or may only accept a global override passcode.

FIG. 29 is a block diagram illustrating an example of the interconnection of modules and procedures of an AMD involved in changing settings of the AMD. In some cases, 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. In some examples, when a lock function is activated, 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. To access one or more control parameters 2941/2943/2945, a user may provide a security code for passcode entry 2933 (e.g., a user-generated passcode or an override passcode security code) via the user interface module 2908 (e.g., using the touchscreen display 2924 or alphanumeric pad 2926). Alternatively or additionally, a user 2927 can use an intermediate device 2923 (e.g., a laptop, smartphone, etc.) connected to the AMD (e.g., via a wired or wireless link) to provide a security code for passcode entry 2946. In some examples, once a security code or override security code is received (e.g., from the intermediate device 2923 or the interface module 2908), the security code may be transmitted to the control and computation unit of the AMD, and a set of configuration change control procedures 2935 determines or verifies the validity of the security code by comparing it with a user-generated passcode or password 2939 or override passcode or password 2937 stored in the memory of the CCM.

In some examples, access to one or more setting control screens 2940/2942/2944 and/or parameter control elements 2941/2943/2945 can be managed by a setting change procedure 2928. In some examples, the setting change procedure 2928 can be modified, and may be considered an advanced setting as described herein, requiring a different passcode, e.g., one or more setting control screens 2940/2942/2944 and/or parameter control elements 2941/2943/2945, to access from a passcode. The setting change procedure can be machine-readable instructions stored in an AMD and executed by one or more hardware processors.

In some examples, the option to provide a security code corresponding to the passcode may become available when the user 2927 performs a wake operation on the wake interface 2923, which may include a user input element associated with recognition of the wake operation or some other user interaction. In these examples, if the CCM's wake control module 2934 determines that a valid wake operation has been performed (and a valid security code has been entered), it may present selectable elements associated with the settings control screen 2940/2942/2944, for example, on a touch screen display. In some examples, a first screen presented on the touch screen display may provide other selectable elements, including elements for changing settings of the AMD. In such examples, selecting an element associated with changing settings may launch a second screen presenting selectable elements associated with the settings control screen 2940/2942/2944.

When the lock feature is activated, 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. In some examples, each of the control screens 2940/2942/2944 and/or parameter control elements 2941/2943/2945 may require a different passcode. In some examples, one or more of the control screens 2940/2942/2944 and/or parameter control elements 2941/2943/2945 may not require a passcode. For example, access to the first screen 2940 may require a first passcode, access to the second screen 2942 may require a second passcode, and access to the third screen 2944 may not require a passcode. In some examples, all control screens 2940/2942/2944 may be presented without requiring a passcode, but access to one or more control elements within a control screen may require a passcode. For example, a user may select second screen 2942 without entering a security code, but to select one or more parameter control elements 2943 on that screen, the user may need to enter one or more security codes that match one or more passcodes. In some cases, after a user provides a security code that matches a passcode to access parameter control elements 2941/2943/2945, the user can interact with the parameter control element to provide a setting change input 2931 that changes the corresponding control parameter.

30 is a flow diagram illustrating an example method that may be used by an AMD and/or intermediate device to allow a user to change the settings of the AMD and/or intermediate device using a user-generated passcode or an override passcode.
When the AMD and/or intermediate device 2923 receives a valid wake operation 3002, it can launch a user interface (e.g., a user interface on the touchscreen display 2924). In some examples, the wake operation may be received by the AMD's wake interface 2922. In some examples, the wake operation can directly launch the settings change interface 3004 (e.g., a settings change screen presented on the touchscreen display having one or more parameter control elements). In some examples, a first gesture may be required after the wake operation to launch the settings change interface. In some examples, a specific wake operation can launch the settings change interface.

In some cases, for example, in a configuration change interface or another user interface, the AMD and/or intermediate device (e.g., a configuration change procedure in a CCM) may request a security code 3006 (e.g., by presenting a window for entering a security code, such as a keypad passcode display). Once the security code is received, the AMD (e.g., a configuration change procedure in a CCM) and/or intermediate device may determine whether the security code matches a user-generated passcode 3008. If the security code is determined to match the user-generated passcode, the AMD and/or intermediate device may provide access 3010 to one or more control parameter elements associated with the verified passcode. If the received security code does not match any stored user-generated passcodes, the AMD and/or intermediate device may determine whether the security code matches an override passcode 3012. If the security code is determined to match an override passcode stored in the AMD and/or intermediate device's memory (or the memory of an authorized computing device), the AMD and/or intermediate device may provide access 3014 to one or more control parameter elements associated with the verified override passcode. If the security code is determined not to match the override passcode, the AMD and/or intermediate device denies access to one or more passcode-protected parameter control elements 3016.

FIG. 31 is a flow diagram illustrating another exemplary method that may be used by an AMD and/or intermediate device to allow a user to change settings on an AMD using a user-generated or override passcode. When the AMD (e.g., a wake operation procedure of a CCM) and/or intermediate device receives a wake operation 3102, the AMD and/or intermediate device may provide a user interface (e.g., a touchscreen display) through which a user can provide a first gesture to activate a settings change interface or screen. When a first gesture is received from a user or patient 3104, the AMD and/or intermediate device may activate a settings change interface (e.g., a settings change screen on a touchscreen display) 3106. In some examples, the settings change interface may include one or more parameter control elements related to one or more AMD settings. In some examples, the settings change interface or screen may include one or more selectable elements each associated with a settings change screen (e.g., a screen provided on a touchscreen display) that may include one or more control parameters. For example, upon receiving a request for a setting change through user interaction with one or more parameter control elements 3108, the AMD and/or intermediate device may determine whether the requested setting change is passcode protected 3110. In some examples, the setting change request may include selecting a list of parameter control elements (e.g., included on a separate screen provided on a touch screen display).

If the AMD and/or intermediate device determines that the requested setting change is not passcode protected, it may allow access to one or more parameter control elements associated with the requested setting change 3112. In some examples, once the change is received via the parameter control element 3114, the user may be required to provide a second gesture on a user interface (e.g., a touch screen display) to confirm the change made. In response to receiving the second gesture 3116, the AMD and/or intermediate device may modify 3118 one or more settings in accordance with the requested and confirmed change.

If the AMD and/or intermediate device determines that the requested setting change is protected by a passcode, it may request a security code via a passcode display (e.g., provided on a touchscreen display) 3120. In some examples, the security code request may be presented on a display, but the security code may be received via a physical keypad. Once a security code is received from the user or patient 3122, the AMD and/or intermediate device may verify the security code against one or more user-generated or override passcodes 3124 (e.g., does the entered security code match the passcode(s)?). If it is determined that the security code matches the user-generated or override passcode(s), the AMD and/or intermediate device may activate one or more parameter control elements associated with the requested setting change 3126. The AMD and/or intermediate device may then receive the setting change via the selected control parameter element 3128. In some examples, the user may be required to provide a second gesture on the user interface (e.g., touchscreen display) to confirm the change made. In response to receiving the second gesture 3130, the AMD and/or intermediate device may modify one or more settings according to the requested and confirmed changes 3132.

AMD with alarm system
In some cases, a condition may occur that affects the operation of the ambulatory medication device. This condition may relate to the ability of the ambulatory medication device (AMD) to operate as intended by the manufacturer, the patient receiving treatment from the ambulatory medication device, and/or the user (e.g., the patient's healthcare provider, parent, or guardian). In some cases, the AMD may be operating as intended, but the patient's condition may not meet a desired health level. In either case, it is generally desirable to generate an alarm to inform the patient and/or one or more users of the AMD and/or the patient's condition. Furthermore, it is desirable to track the alarm until the condition that generated the alarm is resolved. Furthermore, it is desirable to issue different types of alarms for different conditions so that the patient or user can easily distinguish the severity of the condition that triggered the alarm. The user may be a patient receiving a medication or treatment, or another user such as a clinician or healthcare provider, or a parent or guardian.

This section of the disclosure relates to ambulatory medication devices (AMDs), such as insulin pumps or combined insulin and proton pumps (e.g., glucagon) configured to generate dose control signals configured to cause the medication pump to infuse a medication into a patient. Additionally, the disclosure relates to ambulatory medication devices configured to detect a condition of the ambulatory medication device and/or patient and generate an alert when the detected condition is determined to meet an alert condition.

As described above, the ambulatory medication device may include an alarm system configured to monitor the ambulatory medication device and/or the patient and generate an alarm when it is determined that a condition meeting an alarm condition has been detected. In some examples, the alarm system may compile a list of alarms, notify the user of these alarms, and allow the user to acknowledge the alarms.

In some embodiments, the alarm system may include multiple sensors that monitor the AMD or patient, a monitoring system interface that receives data from the sensors, and an alarm annunciation and control system that processes the received data and generates an alarm when an alarm condition is met. In some examples, the monitoring system interface and the alarm annunciation and control module are implemented using one or more hardware processors and machine-readable instructions. In some examples, the monitoring system interface and the alarm generation module are separate hardware modules.

Referring to FIG. 32 , in some embodiments, an alarm system 3222 implements alarm control procedures within the control and computing module 610 (CCM) of the AMD. The alarm system 3222 may be implemented as instructions stored in a memory (e.g., main memory 616) of the CCM and executed by the hardware processor 614 to generate an alarm upon detection of a condition of the ambulatory medication device and/or patient. In some cases, the hardware processor of the monitoring system is the hardware processor of the ambulatory medication device that controls medication delivery. In some cases, the hardware processor of the monitoring system may be a separate hardware processor.

In some examples, 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 subsystems for determining the severity of an alarm condition, processing user notifications, 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 state or condition of the AMD and/or patient based at least in part on signals or state values received from the set of device sensors 3224 and the set of patient sensors 3220. In some examples, the device sensors 3224 may be configured to track the state of a component or element of the AMD, and the patient sensors 3220 may be configured to obtain measurements of one or more physiological characteristics of the patient.

In some examples, device sensors 3224 are sensors that generate signals or status values related to the status of modules, interfaces, accessories, or disposables of the AMD. In some examples, device sensors 3224 may generate signals corresponding to parameters related to components within a module or interface. For example, one device sensor may record the voltage of a battery, while another device sensor may record the tracking speed of pumping the medication delivery interface 3206.

In some examples, the patient sensor 3220 may be any sensor that generates a signal or status value related to one or more physiological indicators (or parameters) of the patient (e.g., heart rate, blood pressure, body temperature, blood glucose level, serum levels of various hormones or other analytes). In some such examples, the patient sensor may be a continuous glucose monitoring sensor (CGS). The device and patient monitoring system interface 3226 may continuously receive and analyze signals from the device sensor 3224 and the patient sensor 3220 to determine the status of the AMD, the patient, the sensor, and/or other accessories.

In some cases, a single sensor may be used to monitor both the patient's condition and the accessories and sensors connected to the ambulatory medication device or AMD. For example, a continuous glucose monitoring (CGM) sensor may be used to monitor the patient's condition and may also be monitored to determine if the CGM's condition meets an alarm condition (e.g., to alert the user that the CGM should be replaced).

Although described as sensors of the AMD, one or more of the sensors may or may not be part of the AMD, but may be an accessory capable of communicating with the AMD.

In some examples, the alarm system 3222 implements procedures to allow a user or subject to change alarm settings and/or acknowledge alarm announcements via the user interface 3208. In some examples, even when the AMD is in a locked state, the user can still see one or more alarms announced in the user interface (e.g., as a list of alarms). In these examples, the user may not be able to acknowledge or respond to an alarm when the AMD is in a locked state.

In some such examples, a user or patient may access an alarm settings screen or acknowledge an alarm notification by providing a wake action or a wake action followed by a first gesture, for example, on a touch screen display. In some cases, the first gesture may be created by entering a predetermined or specific character on an alphanumeric pad. In some such examples, the alarm system 3222 distinguishes unintentional alarm control inputs from intentional alarm control inputs. An inadvertent alarm control input is an alarm acknowledgement input made without the user's 3227 intention to acknowledge an alarm that the mobile medical device 600 is delivering to the user. An example of an inadvertent alarm acknowledgement is one accidentally performed by the user 3227 by applying pressure to the mobile medical device 600 in the user's 3227 jacket pocket.

In some examples, the alarm system 3222 implements a process for determining and classifying alarm conditions based on their severity level (e.g., severity levels 0-5) according to information received via the monitoring system interface 3226. In some examples, once an alarm condition is detected, the alarm annunciation and control system 3228 may place it in an appropriate queue, for example, based on severity or category. In one or more embodiments, a list of alarms may be generated, and the alarms may be sorted numerically in descending order with the highest priority faults displayed at the top.

In some examples, the alarm system 3222 implements procedures for controlling the annunciation of alarm conditions via the user interface module 3208 based at least in part on their severity level. In some such examples, the user interface (e.g., a touch screen display) may be configured to allow a user to navigate directly to the problem or fault for which the alarm is being delivered and to address the fault causing the alarm so that it can be corrected and the alarm can be stopped.

Alarm Conditions In some examples, the device and patient monitoring system interface 3226 can provide status information received from the device 3224 and/or patient sensors 3220 to the alarm reporting and control system 3228. In some examples, the status information can include one or more status values. In some examples, the status information can include device information regarding the status of the ambulatory medication device or patient information regarding the status of the patient. In some such examples, the alarm reporting and control system 3228 is configured to determine whether an alarm condition has been met based at least in part on the status information received from the monitoring system 3226.

Determining whether an alarm condition is met may include comparing one or more status values associated with the ambulatory medication device and/or the patient to one or more alarm thresholds or alarm conditions. In some cases, each alarm threshold or alarm condition may be associated with an alarm profile. In some such cases, determining whether an alarm condition is met may include comparing status information to one or more alarm thresholds or alarm conditions included in one or more alarm profiles. In some examples, the alarm profiles may be stored in storage 618 of the CCM 610. In some such examples, at least some of the alarm profiles may be provided to the CCM by an authorized user or patient via a user interface, or may be transferred directly to storage from another device (e.g., from a USB drive, laptop, smartphone, PC, etc.). In some examples, at least some of the alarm profiles may be stored in storage 618 at the time of manufacture,

Each alarm profile may indicate a characteristic or condition of the AMD and/or patient that will trigger the corresponding alarm. For example, at least some alarm profiles may indicate threshold condition values below or above which an alarm should be triggered. For example, one alarm profile may indicate that a particular alarm should be generated and/or signaled when a patient's blood glucose level exceeds a particular threshold. As another example, an alarm profile may indicate that a particular alarm should be generated and/or signaled when the amount of available medication falls below a particular threshold. The type of medication-level-related alarm and/or the frequency or intensity of the alarm may differ from an alarm triggered based on blood glucose levels. While the preceding example described a single condition associated with a single alarm profile, it should be understood that multiple conditions may be associated with an alarm profile. For example, blood glucose levels above an upper threshold or below a lower threshold may be associated with different alarm profiles or the same alarm profile. As another example, blood glucose levels above an upper threshold or a drug pump that is unable to deliver insulin may be associated with the same alarm profile. On the other hand, a drug pump that is unable to deliver insulin due to an empty insulin cartridge may be associated with a different alarm profile than a drug pump that is unable to deliver insulin due to damage to the drug pump.

Some non-limiting examples of AMD or patient conditions that may be associated with an alert profile include conditions related to battery capacity (e.g., below a threshold charge capacity or below a capacity associated with a particular amount of operating time (e.g., 1 day)), battery condition (e.g., high temperature or low voltage), medication or drug delivery condition (e.g., medication empty or below a threshold, motor stalled, catheter occluded, etc.), patient sensor condition (e.g., blood glucose sensor about to expire or no signal received from the sensor), calibration failure, high or low glucose level, network (e.g., Bluetooth® or BN-LTE) communication error, tactile interface error (e.g., motor unresponsive), speaker error (e.g., noise or low volume), medication cartridge error (e.g., empty cartridge, cartridge detection error, etc.), etc. As described below, each of these errors or conditions may be associated with a different severity level that triggers the issuance of a different alert.

In some cases, each alarm profile may be associated with an alarm severity level. The severity level may be related to how urgently the condition that triggered the alarm should be addressed or resolved. Furthermore, the severity level may be related to the amount of harm that may be caused to the patient if the condition that triggered the alarm is not resolved or resolved within a certain period of time. The number of severity levels may vary based on the type of ambulatory medication device. Generally, there is no limit to the number of severity levels. However, there may be a point of diminishing returns once the number of severity levels exceeds a certain number, for example, because it may be difficult for a user to distinguish between different severity levels or to identify which severity level a particular alarm is associated with. Therefore, the number of severity levels may be limited to a certain number, such as 3, 5, 6, 9, or some number in between. However, there may be more than 9 severity levels.

There may be multiple alert profiles associated with a severity level, or each AMD and/or patient condition associated with the same severity may be associated with the same alert profile.

The AMD may determine the severity of the alarm condition based on the condition of the mobile medication device and/or the patient that triggered the alarm condition. In some cases, the mobile medication device may determine the severity of the alarm condition based at least in part on an alarm profile associated with the alarm condition.

Generally, if an alarm condition does not prevent the AMD from providing therapy, the AMD may continue to provide therapy. However, in some examples, if an alarm condition prevents therapy delivery, operation of the AMD may be paused or partially paused. Generally, alarm conditions that prevent therapy delivery may be associated with a higher severity. However, some alarm conditions that prevent therapy delivery may be associated with a lower severity level. For example, a determination that the AMD is unable to deliver insulin may typically be associated with the highest severity alarm. However, if the user indicates that the site location is currently in the process of being changed, the alarm condition may be associated with a lower severity level (e.g., an informational alarm reminding the user that insulin cannot be delivered during the site change). In some examples, in response to determining that the severity of the alarm condition is consistent with unsafe operation (e.g., a condition that may cause the AMD to deliver a dose of medication above or below a certain value, or a condition that may cause the patient's condition to be uncertainly determined), the AMD may suspend delivery of medication to the patient. Once the symptoms resolve, the AMD may resume delivery of medication to the patient. On the other hand, if the alarm condition is determined to be consistent with a safe surgical severity level, the AMD may be configured to maintain delivery of the medication to the patient.

Alarm Notification When an alarm condition is met, the alarm notification and control system 3228 can implement an notification pattern selected based at least in part on status information generated by and/or received from the monitoring system 3226. The notification pattern can be selected from a plurality of notification patterns based at least in part on the alarm condition and/or status information. The notification pattern can include one or more different text patterns or information, an audible alert, a visual alert, or a tactile alert. Determining whether an alarm condition is met can include comparing one or more status values associated with the ambulatory medication device and/or the patient to one or more alarm thresholds or alarm conditions associated with the alarm profile.

Upon determining that the alarm conditions associated with an alarm profile or alarm condition are met, the alarm reporting and control system 3228 reports the alarm condition. In some cases, at least some of the alarm conditions may be associated with unique reporting patterns. Advantageously, by having unique reporting patterns for at least certain alarm conditions, a user may be immediately aware of the AMD and/or patient description based on the reporting pattern of the alarm.

In some cases, the AMD may have a wireless electronic communications interface that can be used to transmit alarm signals, status information, alarm condition data, and/or alarm patterns to a remote electronic device. In some such cases, the remote electronic device may announce an alarm when an alarm condition is met. The remote electronic device may include any device capable of receiving alarm or status information from the AMD. For example, the remote electronic device may be a smartphone, a smartwatch, smart glasses, a laptop, a tablet, or any other computing device.

In some examples, the alarm system may generate a list of pending alarm conditions and store it in the AMD's memory (e.g., storage 618 in CCM 610). In these examples, whenever an alarm condition associated with an alarm profile is met, the alarm system may update the list of pending alarm conditions by adding the new alarm condition to the list of pending alarm conditions. In some examples, the list of pending alarm conditions may include a list of elements (e.g., icons, text, etc.), each of which indicates an alarm condition (e.g., an announced alarm condition). In some examples, the AMD may display an alarm status icon that includes a visual indication of the number of alarm conditions on the list of pending alarm conditions.

In some examples, the list of pending alarm conditions may be sorted according to the severity level associated with the alarm condition.

In some examples, the alarm system may signal an alarm condition via the user interface module 3208 of the AMD 600. For example, the alarm condition may be signaled via one or more user interfaces (e.g., a display, a touch screen display, a speaker, etc.). In some such examples, the alarm may include an audio alert, a text message, a graphic message, a text or graphic message with audio, a vibration, a flashing light, and any combination thereof.

In some examples, the alarm condition may be transmitted to another device via the AMD's communications module 3202, for example, allowing an authorized user (e.g., the patient's guardian or parent), the patient, or an emergency provider to view the alarm condition. In some examples, the alarm notification and control system 3228 may use the communications module 3202 to establish a direct end-to-end connection with a computing system (e.g., a cloud computing system) and transmit the alarm condition to the computing system via the end-to-end connection.

Based on the severity of the alarm condition and/or the corresponding alarm profile, an alarm associated with the severity and/or type of alarm condition may be generated and/or announced. Different alarm conditions and/or alarm profiles may result in different types of alarms or different announcements of alarms. For example, an alarm associated with the highest severity may include an audible alarm having a volume above a certain decibel level (e.g., above 70 or 80 decibels), a visual alarm (e.g., a flashing or steady light) having an intensity above a certain brightness value (e.g., ¹⁰ or ¹⁰ candelas per square meter), and/or a vibration alarm. Furthermore, an alarm associated with the highest severity level may not be snoozed or ignored. Alternatively, an alarm associated with the highest severity level may be snoozed for a shorter period of time (e.g., 5 minutes, 10 minutes, etc.) than alarms of lower severity levels. Alarms associated with severity levels different from the highest severity level may include different combinations of audible, visual, and vibration alarms. Not only may the presence of audible, visual, and vibratory alarms differ at different severity levels, but the characteristics of each alarm type may also differ. For example, audible alarms may have different sound patterns, volumes, frequencies, etc. Visual alarms may be of different intensities, colors, patterns, etc. Vibratory alarms may be of different patterns, intensities, etc. Additionally, alarms having a severity level different from the highest severity level may be snoozed or discarded or allowed to be snoozed for a longer period of time. In some examples, the severity of the alarm condition may determine the type of type of alarm generated (e.g., audio, text, graphic, or any combination thereof).

Additionally, 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. In some cases, duplicate alarms may be omitted from the list of alarms. In some cases, a count of alarm occurrences may be incremented to reflect the duplicate alarms. In some cases, duplicate alarms may result in the issuance of a duplicate alarm. In some cases, duplicate alarms are ignored. In some cases, the occurrence of a duplicate alarm may cause an escalation of an existing alarm. For example, if an alarm condition that causes the issuance of an alarm having a first severity level is detected occurring a second time, the alarm may be issued at a second severity level indicating a higher severity than the first severity level. It should be understood that an alarm that occurs after an alarm condition is resolved may not be considered a duplicate alarm, but may instead be an indicator of a reoccurrence of the alarm condition and/or a failed resolution of the alarm condition (e.g., an incomplete or empty insulin cartridge replacement).

In some cases, the list of alerts may be observed via a user interface (e.g., a touch screen display) when the user interface is locked. In some such cases, further details regarding the alerts may be accessible when the user interface is locked. In some cases, it may be necessary to unlock the unlocked user interface (e.g., via a wake action and/or gesture) to access more details regarding the alerts and/or to resolve the alerts.

Each alarm condition, or information related thereto, can be added to an indicator or user interface (e.g., a list or other data structure or user interface element) that can be accessed by a user. The user interface can maintain the alarm condition on the user interface until the alarm condition is resolved. Additionally, the alarm conditions may be sorted or ranked based on the severity level of the alarm condition, the time the alarm condition occurred, whether the alarm condition is related to the patient or the ambulatory medication device, any combination of the above, or any other factor for sorting or ranking the alarm conditions.

In some cases where an alert is presented on a display, the displayed information may include the cause of the alert, the severity of the alert, details on how to respond to or address the alert, or any other information that may be useful regarding why the alert was generated and/or how to respond to the alert. In some cases, the information may provide a workflow or instructions on how to respond to the alert. The instructions may include a link to a workflow provided by the manufacturer of the mobile medication device or by the manufacturer of another entity, such as an entity providing medication or site replacement kits.

In some cases, different views of the alert or different information associated with the alert may be provided based on the identity or role of the user viewing the alert. For example, a child may be instructed to contact a parent to address the alert, while the parent may be provided with information to resolve the alert. A parent may receive simplified information about what triggered the alert (e.g., high blood glucose), while a healthcare provider may receive more detailed information about the alert (e.g., internal control parameter values, insulin flow rate, curvature of predicted insulin decline, etc.), making it easier for the healthcare provider to care for the patient.

The alarm conditions may be displayed on a display of the AMD. Alternatively, or additionally, the alarm conditions may be displayed on a remote display separate from the ambulatory medication device. The remote display may be a display authenticated or associated with a computing device authenticated to access data, such as alarm conditions, from the AMD. In some cases, the list of alarms may be presented on a mobile device (e.g., a smartwatch or smartphone) or computing device (e.g., a laptop or desktop) that can obtain data directly or indirectly from the AMD.

In some cases, reporting the alert may include contacting the manufacturer and/or the user (e.g., a healthcare professional, a parent or guardian, or other registered user). Additionally, the alert may include instructions regarding servicing the ambulatory medication device and/or addressing the alert condition. For example, the alert may provide the user with instructions for replacing the insulin cartridge and how to replace the insulin cartridge. As another example, the alert may provide instructions on how to change the device's battery or how to change the site at which the insulin pump connects to the patient. In some cases, the alert may include one or more actions related to the alert. For example, the alert may trigger a reordering of insulin or may request that the user confirm the reordering request to reorder insulin.

Resolving Alerts Certain alerts, such as informational alerts, may not be acceptable, however, an alert generally can remain on the alert list until the condition that caused the alert is resolved.

A user can acknowledge and/or snooze an alarm via the user interface. In some examples, to acknowledge and/or snooze an alarm, a user may first need to activate the user interface (e.g., by providing a wake motion) and then provide a gesture to unlock the user interface. For example, a user can use a wake button to activate a touchscreen display and then provide a gesture on the screen to unlock the display. In some examples, the touchscreen display may be configured to allow a user or patient to navigate directly to the problem or fault that is causing the alarm to be delivered. This functionality provides the user with access to address the fault that is causing the alarm, thereby allowing the alarm to be corrected and thereby stopped. In some examples,

Resolving an alert may include any action that addresses the condition that generated the alert. For example, resolving an alert may include replacing the insulin cartridge, changing the site at which the mobile medication device connects to the patient, charging the battery of the mobile medication device, providing insulin or counterregulator to the patient and/or the mobile medication device, or any other action that can be performed to address the alert condition. In some cases, the resolution action may be acknowledging the alert. For example, if the alert is informational (e.g., to inform the user that more insulin has been ordered), acknowledging the alert may be a sufficient resolution.

In some cases, whether an alarm condition is resolved may depend on the identity of the user.
For example, if a child interacts with an alert related to insulin sorting, the alert may remain until a parent or guardian acknowledges the alert. However, the child may be able to snooze the alert. In some cases, the user interface displaying the alert may differ based on who is viewing the alert. For example, a child may be able to see the alert but not interact with it. However, the parent or guardian may be able to snooze or ignore the alert. Additionally, the child may be instructed to bring the device to a parent or adult to address the alert. In some cases, the child may be informed of how to urgently contact the parent (e.g., contact the parent immediately, within one day, within one week, etc.). Additionally, a designated adult may receive the alert separately (e.g., via text or email alert). The parent or guardian may receive additional information not provided to the child or patient (e.g., a link to repair instructions or a workflow for addressing the alert condition).

In some cases, certain conditions may self-resolve over time. For example, a low battery alarm may resolve when the battery is charged. In such cases, the alarm may be automatically canceled when the battery charge level exceeds a certain threshold. Further, in some cases, one or more alarms and/or alarm lists may be viewed and/or accessed on a home screen, main screen, or other non-alarm-based user interface screen in addition to a user interface screen designated for displaying alarms. The alarm list may be accessible from the mobile medication device and/or a computing system in communication with the mobile medication device.

However, in some cases, the alarm condition may or may not be resolvable when the mobile medication device is locked.

A user may interact with an alert generated based on an alert condition. In some cases, a user may only interact with an alert when the AMD and/or user interface are unlocked. In some cases, a user may interact with an alert to snooze the alert or obtain more information when the AMD is locked. However, a user may not be able to dismiss an alert without unlocking the mobile medication device. Interacting with an alert may include providing the user with information related to the alert or an indicator representing the alert in response to the user interacting with the alert.

Exemplary AMD with Alarm Management System
33A is a flow diagram illustrating an exemplary procedure that may be used by an alarm system of an AMD to annunciate an alarm condition upon receiving status information that satisfies the alarm condition. In some examples, the alarm annunciator and control system 3228 performs the annunciator process through execution of instructions by a processor in the CCM of the AMD, which instructions may be stored in main memory, storage of the AMD, or memory of a connected electronic device or computing system.

The alarm system, in block 3302, may receive status information from one or more device sensors 3224 and/or one or more patient sensors 3220 via the monitoring system interface 3226. The one or more device sensors 3224 may include any type of sensor capable of determining the status of the AMD. For example, the one or more device sensors 3224 may include a battery charge sensor that determines the charge on the battery, a battery status sensor that determines the status of the battery, a medication sensor that determines the amount of medication remaining, or any other type of sensor that can determine the status of one or more electronic or mechanical components of the AMD. The one or more device sensors may determine whether the amount of medication is below a threshold or whether the battery charge is below a threshold.

The one or more patient sensors 3220 may include any type of sensor capable of determining a health-related characteristic or physiological parameter of the patient. For example, the one or more patient sensors 3220 may determine the patient's blood glucose reading, blood pressure reading, respiratory rate, blood oxygen level, pulse rate, or any other physiological characteristic. In particular, but not limited to such, the one or more patient sensors 3220 may measure any physiological parameter of the patient that may be relevant to the monitoring, management, or treatment of the patient's diabetes.

In some examples, the alarm annunciation and control system 3228 determines whether the received status information meets an alarm condition in decision block 3304. In some examples, the alarm condition may be an alarm condition in an alarm profile. If the received status information does not meet the alarm condition, no action is taken in block 3306. If the received status information meets the alarm condition 3304, the alarm system may determine whether the alarm condition already exists in a list of pending alarm conditions in decision block 3308. If the alarm condition does not exist in the list of pending alarm conditions, the alarm system may determine a severity level for the alarm condition in block 3310, add the alarm condition to the list of pending alarm conditions in block 3312, and increment an alarm count that tracks the number of occurrences of alarms or a fault count that tracks the 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. In some such examples, the alarm conditions may be sorted numerically in descending order with the highest priority faults displayed at the top.

Based on the determined severity level, the alarm annunciation and control system 3228 may then select an annunciation pattern at block 3314 and annunciate the alarm condition using the selected annunciation pattern at block 3316. If the alarm condition exists 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 block 3316. In some examples, the annunciation pattern selected at block 3318 may be a different annunciation pattern than a previously used annunciation pattern for the alarm condition. In some such examples, the annunciation pattern selected at block 3318 may be selected based at least in part on the number of times the same alarm condition has been met by the received status information. The process of alarm detection and control functions may be repeated periodically, intermittently, according to a particular schedule, or during use of the mobile medical device. The frequency at which the process is repeated may depend on the particular alarm condition detected from the status information. In some examples, after the alarm is announced, the alarm system may wait for user acknowledgment of the alarm at block 3320. If the user acknowledges the alert, the system proceeds to resolve the alert 3322. In some cases, resolving the alert may include providing instructions to the user or indicating where the user can find instructions to resolve the alert condition. For example, repair instructions for repairing the AMD may be provided to the user. Additionally, in some cases, resolving the alert may include automatically ordering or requesting that the user confirm that an order be placed to refill the medication. If the user does not acknowledge the alert, then in block 3324, the alert may be repeated after a certain period of time determined based on the severity level of the alert. In some examples, if the user fails to acknowledge the alert, the alert may continue and escalate depending on the severity level of the alert.

As mentioned above, in some instances, the user or patient can view the alarms both when the display is locked and when the display is unlocked using a user interface provided on the touch screen display.
is a diagram of such a user interface 3326 for accessing an alarm notification screen when the display is locked. As shown, user interface 3326 includes an alarm icon 3328, a pump operation area 3330, and an unlock button (or first gesture field) 3332. Alarm icon 3328, in this exemplary embodiment, is shaped as an alarm bell with a counter in the center indicating the number of alarms that have been signaled (e.g., "0" in the example shown).

In some examples, the unlock field is configured to allow the user to unlock the display, for example, by sliding in the direction of the chevron. However, the user can view alerts without unlocking the interface. Thus, for example, if the user selects the alerts icon, and there are no alerts in the system, the display shown in 3334 is displayed. If there are existing alerts in the system, the display 3336 is displayed, displaying a list of alerts but not allowing the user to select an alert (e.g., to see more information or acknowledge the alert). The inability to select an alert is exemplified by the absence of a chevron with each alert. The number of alerts displayed may be limited by the size of the screen.

In some such examples, when a user unlocks the screen by sliding unlock button 3332, user interface 3327 shown in FIG. 33C may be displayed. As shown, user interface 3327 includes an alarm icon 3328, a menu icon 3329, and a pump operation area 3330. In some cases, menu icon 3329 may allow a user to control the operation of the AMD 600, and alarm icon 3328 may provide the user with access to alarm control functions. Thus, for example, if a user selects alarm icon 3328, and there are no alarms in the system, display 3335 may be displayed on the screen. If there are existing alarms in the system, display 3337 may be displayed, displaying a list of alarms, each with a chevron 3339 that allows the user to select the alarm to access further control functions for the selected alarm.

As described above, alarm conditions may be classified and annunciated based on their severity level. In some examples, alarms are sorted numerically in descending order, with the highest priority faults appearing at the top of the list. In some examples, a level 0 severity may be for a minor fault that does not require any action by the user and therefore does not require an alarm notification. In some examples, a level 1 severity may be an informational type notification that repeats at a specific frequency (e.g., every 30 minutes) until acknowledged and reset by the user. The annunciator may include, for example, a short vibration or a beep. In some examples, a level 2 severity may be associated with an imminent loss of system functionality. Thus, such an annunciator may include, for example, two short vibrations and two beeps, repeating at a specific frequency (e.g., every 30 minutes). Thus, the user must still address the condition causing the fault in order to completely stop the annunciator. In some examples, a level 3 fault may be when the system is no longer fully functional and therefore requires user intervention to correct the problem. The alert may start at a base level intensity, for example, with three short vibrations and three audio beeps, and repeat at a particular frequency (e.g., every five minutes). The alert escalates at a second frequency, for example, every 30 minutes, to a maximum intensity level. The escalation may be, for example, a change in vibration intensity and/or audio level. The escalation may be cleared to the base level when the user acknowledges the fault. However, the base alarm may remain if the underlying condition persists. Thus, the user must still address the condition that caused the fault to completely stop the alert. In some examples, a level 4 severity may be for cases where the system is no longer functioning and cannot be corrected by the user. The alert may start at a base level intensity, for example, with three audio beeps, and repeat at a particular frequency (e.g., every five minutes). The alert escalates at a second frequency, for example, every 30 minutes, to a maximum intensity level. The escalation may be, for example, a change in audio level. The escalation may be cleared when the user acknowledges the fault. However, the base alarm remains because the underlying condition persists. In some examples, a level 5 severity may be for a high priority alarm per IEC 60601-1-8. The triggering alarm may only be cleared if the underlying problem is resolved, e.g., if the glucose level rises.

Additional embodiments relating to determining the severity of an alarm condition and announcing an alarm based at least in part on the severity of the alarm condition that can be combined with one or more embodiments of the present disclosure are described in U.S. Provisional Application No. 62/911,017, entitled "ALARM SYSTEM AND METHOD IN A DRUG INFUSION DEVICE," filed October 4, 2019, the disclosure of which is incorporated herein by reference in its entirety for all purposes.

Non-Critical AMD Condition Management In some cases, a condition may occur that affects the operation of an ambulatory medical device (AMD) that provides treatment to a patient. In some examples, the AMD may be a mobile medication device. The condition may relate to the ability of the AMD to operate as intended by the manufacturer, the patient receiving treatment from the AMD, and/or the user (e.g., the patient's healthcare provider, parent, or guardian). In some cases, a condition or malfunction of the AMD may prevent the AMD from providing treatment to the patient. In some cases, the condition or malfunction may allow the AMD to continue providing at least partial therapy to the patient for at least a certain period of time. In general, to provide and facilitate non-critical malfunction management in ambulatory medical devices, it is desirable to generate an alert to inform the patient and/or one or more users of the AMD and/or patient's condition. It is also desirable to track the alert until the condition that caused the alert is resolved. Furthermore, it is desirable to issue different types of alerts for different conditions to allow the patient or user to easily distinguish the severity of the condition that triggered the alert.

In many cases, if the nature of the warning is not critical, it may be safer to continue the underlying treatment and notify the user of the condition rather than discontinue treatment. In some such cases, the best response to a device problem for the patient is to notify the device manufacturer, or another user who can address the problem, while the patient continues receiving treatment until a replacement device can be obtained or repairs can be made.

Additionally, alert fatigue can be a problem with medical devices due to excessive alerts that do not necessarily require user interaction. Alert fatigue can be dangerous because it can lead users to ignore serious alerts or warnings that require action in the short term.

The methods described herein may be executed by an AMD (e.g., by one or more processors of the AMD) to detect device malfunctions in the AMD, generate corresponding alerts in the AMD, and prioritize the alerts to allow a patient or user to quickly and easily determine whether the device malfunction impacts therapy, should be addressed in the short term (e.g., immediately, within 1-2 hours, within a day, etc.), and/or can be addressed at the patient's convenience (e.g., within a month or longer). In some cases, the device malfunction alert prioritization methods may be used by other systems.

In certain embodiments, the systems disclosed herein can detect conditions in which the AMD does not meet manufacturer specifications (e.g., tactile annunciator failure, Bluetooth® radio malfunction, glucagon or insulin depletion, medication delivery malfunction, touch screen failure, etc.). In some cases, several tiers of critical and/or non-critical failures may exist. A failure may be considered non-critical if the underlying condition is determined not to be sufficient to stop therapy (e.g., cessation of insulin delivery). In some cases, a failure may indicate required maintenance (e.g., recharging a battery indicator, ordering more medication indicators, etc.) rather than a device failure. The condition may be alerted to the user with appropriate instructions to address the failure or problem (e.g., contacting the manufacturer for replacement medication or parts).

After the alert is acknowledged, the alert may be re-alerted or re-alerted as a reminder at a later time period (e.g., the alert may be re-alerted daily at 4:00 PM or noon, for a fixed static period of time, or at regular intervals). The length of time between alerts may depend on the severity of the fault. In some cases, the re-alerting cannot be stopped by the user, but may only cease if the underlying condition is resolved. In some cases, the re-alerting period may be a variable period and may gradually increase to minimize fatigue alerts. In some cases, the re-alerting period may be a variable period and may gradually decrease as the alert becomes more urgent or critical. In some cases, the re-alerting period may vary during the day based on the time of day. For example, alerts may be provided during the day but muted or reduced at night.

The method may include detecting a state of the AMD. In some examples, the state of the AMD may include a set of operating parameters of the AMD. In some such examples, the state of the AMD may be determined using one or more sensors of the AMD. The state of the AMD may also be determined by the presence or absence of one or more errors in performing one or more functions of the AMD. For example, if the AMD is unable to establish a communication connection with a control system or a data storage system, a possible malfunction with the AMD may be determined. As another example, if the AMD fails to deliver a drug or detects an error when attempting to deliver a drug, a drug pump may be malfunctioning. In some cases, the state of the AMD may be determined based on one or more configuration values being outside of a normal operating range. For example, if a drug delivery rate is faster or slower than a configured operating range, a fault may be determined in the drug pump or its connection to the drug delivery tube (e.g., a catheter). In some examples, the state of the AMD may be determined based on the performance of the AMD over a period of time.

The method may include comparing the detected state of the AMD to a set of normal operating parameters. In some examples, the set of normal operating parameters may be specifications established by a manufacturer when the AMD is operating as intended by the manufacturer. In some examples, at least some of the normal operating parameters may be provided by a healthcare provider. In some examples, at least some of the normal operating parameters may be provided by a patient or an authorized user. In some cases, the normal operating parameters may be associated with a range of values. For example, an operating parameter for a drug delivery rate may be associated with a range of rates, which may vary based on user settings, drug type, site location of drug delivery, or manufacturing tolerances, among other parameters. Comparing the detected state of the AMD to the set of normal operating parameters may include comparing each operating parameter herein to a corresponding detected operating parameter of the AMD. The AMD may generate a user alert or a non-critical malfunction alert based on the determined state of the AMD. For example, the AMD may generate an alert if the detected state of the AMD does not meet the 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 coincide with normal operating parameters. However, typically, the minimum set of operating parameters differ from the normal operating parameters. The minimum operating parameters may include minimum specifications, minimum parameters, or minimum conditions required by the AMD to maintain or continue to provide therapy to the patient. In other words, the minimum operating parameters are operating parameters sufficient to provide therapy. However, the minimum operating parameters may not be sufficient to enable all features of the AMD. For example, the minimum operating parameters may enable the AMD to deliver insulin to the patient, but may not be sufficient to deliver insulin at a delivery rate normal for the particular AMD. As another example, the minimum operating parameters may enable delivery of therapy, but may not be sufficient to track a log of the therapy or transmit the therapy log to another computing system. In some cases, the normal operating parameters and/or minimum operating parameters may be specified by the manufacturer at the time of manufacture. In some cases, normal and/or minimum operating parameters may be specified by the patient or a healthcare provider (e.g., the minimum amount of medication to be provided in each bolus may be specified by a healthcare provider). In some cases, the normal or minimum operating parameters can be changed.

If the condition of the AMD is determined to meet at least the minimum operating parameters, the AMD may be configured to maintain delivery of therapy to the patient. Maintaining delivery of therapy may include maintaining therapy at the same rate, at a reduced rate (e.g., providing only basal therapy and meal-notification-responsive therapy), or at a minimum or minimum maintenance rate (e.g., providing only basal insulin). Advantageously, the AMD's ability to distinguish between a minimum set of operating parameters and a normal set of operating parameters allows a malfunctioning AMD to continue providing therapy, which may include life-saving treatment, to the patient until the AMD can be repaired or until the device condition deteriorates to the point where the minimum operating parameters cannot be maintained. In some cases, the AMD may temporarily maintain delivery of therapy. Temporarily maintaining therapy can provide the patient time to address the issue that caused the AMD to not meet normal operating parameters before the patient loses access to therapy. In some cases, the AMD temporarily maintains therapy until the device condition no longer makes it possible to maintain therapy.

FIG. 34 is a block diagram illustrating an example of the interconnections between modules and procedures of an AMD that may be involved in monitoring the status of the AMD and generating an alert when a device malfunction is detected. In some examples, the status of the AMD may include the status of modules and components of the AMD and/or the operation of modules and procedures of the AMD. In some embodiments, the alert system may be implemented as a set of alert control procedures 3422 within the control and computation module 610 (CCM) of the AMD. The alert control procedures 3422 may be implemented as instructions stored in memory of the AMD (e.g., memory within the CCM 610) and executed by the AMD's hardware processor 614 (e.g., the processor of the CCM 610) to generate an alert upon detection of an AMD malfunction. In some cases, the hardware processor may be the AMD's hardware processor that controls medication delivery. In some cases, the monitoring system's hardware processor may be a separate hardware processor.

In some examples, 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. In some examples, the set of device sensors 3424 may be configured to track the status of components of the AMD. The set of operation monitoring procedures 3425 may be configured to monitor the operation of components, modules, and other procedures (e.g., the temporal behavior of signals provided by components, communications between different devices and modules, the execution of procedures implemented in the CCM 610, etc.). For example, the device sensors may determine that components are properly connected and functioning, while the operation monitoring procedures 3425 may provide data related to signals generated by components over a period of time. The monitoring system 3426 may monitor and evaluate a set of operational parameters of the AMD based at least in part on information received from the operation monitoring procedures 3425 and the device sensors 3424.

In some embodiments, the alert generation procedure 3428 may compare the determined operating parameters of the AMD received from the monitoring system 3426 with a set of normal operating parameters. In some examples, the alert generation procedure 3428 may also determine whether the operating parameters of the AMD meet a minimum set of operating parameters. In some examples, if it is determined that one or more operating parameters of the AMD do not meet the normal operating parameters, the alert generation procedure 3428 may generate an alert. In some examples, the alert may be sent to the user interface module 3408 and displayed on a display (e.g., a touch screen display) of the AMD. In some examples, once the alert is generated, the AMD may establish a connection (e.g., a wireless connection) with another device using the communications module 3402. This other device may include a local device (e.g., a user's laptop, smartphone, or smartwatch) or a computing system of a cloud-based service. In some such examples, the alert may be sent by the communications module 3402 to the local device and/or computing system and displayed on a user interface associated with the local device or computing system. In some cases, the local device and/or computing system may receive data from the AMD device that allows a user to monitor the operating parameters of the AMD.

The type of alert, and how often the alert is repeated, or whether the alert is permissible, may be determined by the alert generation procedure based on the detected condition of the AMD and alert information stored in the AMD's memory. In some examples, the alert information may be provided by the patient, an authorized user, or a healthcare provider. In some examples, the alert information may be stored in the AMD at the time of manufacture.

In some examples, upon determining that the detected AMD condition (e.g., including a set of operating parameters) does not meet the normal condition (e.g., a set of normal operating parameters), the alert generation procedure 3428 may cause the drug delivery interface 606 to stop therapy delivery or modify one or more delivery parameters (e.g., therapy delivery rate). In some examples, when the AMD operating parameters are detected or determined to not meet the set of normal operating parameters but do meet the set of minimum operating parameters, therapy delivery may be maintained at the normal rate.

The alert may include any type of alert. For example, the alert may be a visual alert (e.g., a light or a changing light), an audible alert (e.g., a beep or a series of beeps), a tactile or vibration alert, an email alert, a text alert, or any other type of alert. In some examples, different AMD conditions or different operating parameters of the AMD may be associated with or trigger different types of alerts. Thus, the alert may allow a user to determine the device status of the AMD based on the type of alert. For example, an indication that the AMD has failed to deliver medication may trigger one type of alert, while an indication that the AMD medication level has dropped below a certain level may trigger a different type of alert. In some cases, a user alert or a non-critical malfunction alert may be inhibited and/or snoozed by the user. In some cases, such as when the AMD does not meet a set of minimum operating parameters, a user alert or a non-critical malfunction alert may not be ignored or snoozed.

Inhibition warnings may be scheduled to repeat on a specific schedule until a warning-modifying condition occurs. The frequency with which the inhibition warning is repeated may depend on the severity of the condition or the specific operating parameters not meeting normal or minimum operating parameters. More urgent device conditions may result in more frequently repeated warnings. Additionally, warnings may vary based on when the condition is detected, the time of day, or the patient's detected activity (e.g., increased activity such as sleep, abnormal activity, or exercise). Similarly, snooze options may differ for different warnings or any of the aforementioned conditions. In some cases, the AMD may escalate or prioritize warnings if it detects that the AMD condition has become more severe. In some cases, the re-alert period or variable period may gradually increase to minimize fatigue warnings or if the AMD condition is becoming less severe. In some cases, the re-alert period or variable period may gradually decrease if the AMD condition becomes more severe.

The alert frequency may be a static period (e.g., every 5 hours), or may increase towards more frequent intervals (e.g., every 5 hours for 1-3 reminders, every 4 hours for 3-6 reminders, etc.), or may vary based on time of day (e.g., snoozing alerts during sleep hours for non-urgent alerts), etc.

In some examples, the alert modification condition may include any action that returns the operating parameters of the AMD to normal operating parameters. For example, the alert modification condition may be repair or replacement of a failed component. In some cases, the alert modification condition may be acknowledgment of the alert. In some examples, the alert modification condition may include a worsening of the AMD condition. In such cases, the alert modification may include replacing or prioritizing the alert with a different alert indicating a different or more severe condition of the AMD. For example, if a detected malfunction is not addressed after generating a certain number of alerts, an emergency condition may become critical. Once the emergency condition becomes critical, it may be prioritized and trigger a different alert type or a different user/non-critical malfunction alert type (e.g., a louder sound, a different sound, a different frequency, a brighter image, etc.) and/or trigger an escalation of the alert frequency. For example, an audible alert may become louder and be combined with a vibration alert from a tactile annunciator. Additionally, if the condition reaches a critical state, the AMD may cease providing therapy to the patient.

In some cases, generating the alert may further include contacting the manufacturer and/or a healthcare provider (e.g., a clinician). Additionally, generating the alert may include ordering a replacement part. In some cases, the alert may instruct the patient or user on how to repair the mobile medical device.

Once the malfunction is addressed, the AMD is repaired, or the condition that caused the alert is resolved, the user may permanently dismiss the alert (or until the next time the device condition triggers the alert). Alternatively or additionally, the AMD may automatically dismiss the alert if it determines (e.g., using alert control procedure 3422) that the device condition that caused the alert has been resolved. In some cases, the AMD may periodically recheck the device condition to determine whether the alert condition has been resolved.

In some cases, the manufacturer or healthcare provider can remotely clear or stop the alert, for example, using a device or computing system 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, the manufacturer and/or healthcare provider can notify a user (e.g., a patient, or a parent or guardian) of a problem or impending problem with the AMD. The notification can be received by the AMD device via a wireless connection (e.g., an NB-LTE connection). Alternatively or additionally, the notification can be received via a computing device such as a smartphone or laptop.

Figure 35 is a flow diagram illustrating an exemplary procedure that may be used by an alert system of an AMD to monitor the operation of the AMD and generate an alert when a device malfunction is detected. In some examples, the alert system continuously monitors the status of all modules and components associated with the AMD, as well as the operation of all modules and procedures of the AMD. When an AMD condition is detected 3502, the alert system may determine 3504 whether the detected device condition meets a set of normal operating parameters. If it is determined that the detected device condition meets the set of normal operating parameters, the alert system takes no action and continues to monitor the AMD 3502.

If it is determined that the device condition does not meet the set of normal operating parameters, the alert system determines 3508 whether the detected device condition meets a set of minimum operating parameters. If it is determined in block 3508 that the device condition does not meet the set of minimum operating parameters, the alert system may send a signal to the therapy delivery module 606 or the drug delivery interface 1806 (e.g., using the drug dose control procedure 1830) to stop delivery of therapy to the patient 3509 and generate a critical user alert or severe alert prioritized by indicating that immediate or urgent action is required 3511. In some examples, when a severe alert is generated, the AMD's alert system may contact a healthcare provider or authorized user (e.g., the patient's parent or guardian) and may also send a severe alert to one or more computing devices (e.g., laptop, cell phone, personal computer, etc.) of the healthcare provider or authorized user.

If, in block 3508, it is determined that the device condition meets the set of minimum operating parameters, the alert system may maintain delivery of therapy to the patient 3510 and generate a user alert or a non-critical malfunction alert 3512. In some such examples, the alert system may maintain delivery of therapy at a rate associated with the detected condition of the AMD (e.g., a normal rate or a minimum maintenance rate) until an alert correction condition is detected 3514.

Upon detecting 3514 an alert modification condition, the alert system may determine 3516 whether the new device state meets the normal set of parameters. If, in block 3516, it is determined that the new device state meets the set of normal operating parameters, the alert system may resume 3518 normal operation of the AMD (e.g., deliver therapy at a normal rate). If, in block 3516, it is determined that the new device state does not meet the set of normal operating parameters, the alert system may determine 3520 whether the new device state meets a set of minimum parameters. If, in block 3520, it is determined that the new device state meets the set of minimum operating parameters, the alert system may maintain 3522 or change the rate of therapy delivery according to the new device state and generate 3524 a user alert or a non-critical malfunction alert according to the new device state. If, in block 3520, it is determined that the new device state does not meet the set of minimum operating parameters, the alert system may send a signal to the therapy delivery module to stop 3521 delivery of therapy to the patient and may generate 3523 a critical user alert indicating that immediate or emergency action is required. Critical user alerts 3523 may take priority over other types of alerts and alarms. In some examples, when a critical alert is generated, the AMD's alert system may contact a healthcare provider or authorized user (e.g., the patient's parent or guardian) and may also send the critical alert to one or more computing devices (e.g., laptop, cell phone, personal computer, etc.) of the healthcare provider or authorized user.

Managing the Doses of Glucose Control Agents Mobile medical devices allow patients the freedom to treat themselves while on the move. Self-managing medical procedures carries inherent risks for the patient.

An automated glycemic control system can automatically provide insulin and/or counter-regulatory agents (e.g., glucagon) to a patient to help control the patient's blood glucose levels. Generally, a control algorithm is implemented by the automated glycemic control system (BGCS) to determine when to deliver one or more glucose-controlling agents and how much of each agent to provide to the patient. Additionally, the control algorithm can control both the continuous or periodic delivery of insulin (e.g., a basal dose) and correction boluses that can be provided to adjust the patient's blood glucose levels within a desired range. The control algorithm can use blood glucose readings obtained from a sensor, such as a continuous glucose monitoring (CGM) sensor, that obtains automated blood glucose measurements from the patient. Additionally, in some cases, the control algorithm can deliver a bolus of insulin in response to instructions about a meal the patient should or is consuming.

Insulin may be administered subcutaneously into a patient's blood. There is often a delay between when the insulin is provided and when the amount of insulin in the patient's plasma reaches a maximum concentration. This amount of time can vary based on the type of insulin and the particular patient's physiology. For example, with fast-acting insulin, it may take approximately 65 minutes for a bolus of insulin to reach a maximum concentration in the patient's plasma. For some other types of insulin, it may take anywhere from 3 to 5 hours to reach a maximum concentration in the patient's plasma. Therefore, the glycemic control system may implement a predictive algorithm that implements a biexponential pharmacokinetic (PK) model that models the accumulation of an insulin dose in the patient's plasma. The glycemic control system may modify its predictions based on the type of insulin, one or more blood glucose measurements, and/or patient characteristics.

In some cases, a patient may receive a manual bolus of insulin or medication. For example, a user (e.g., a healthcare provider, parent, or guardian) or the patient may inject a dose of insulin into the patient. As another example, a user or patient may manually instruct an automated blood glucose control system to provide a bolus of insulin to the patient.

Generally, too much insulin is undesirable. Excess insulin can result in hypoglycemia. As mentioned above, it can take time for insulin to reach a peak concentration in a subject's plasma. Therefore, blood glucose readings from the sensor may not reflect the amount of insulin in the patient immediately, or even after a certain period of time. Therefore, a manual bolus of insulin may not be detected by the automated blood glucose control system. As a result, if the automated blood glucose control system is operating during the delivery of a manual bolus or is configured to operate on the patient before a blood glucose measurement reflecting the effect of the manual bolus on the patient, the automated blood glucose control system may unnecessarily administer additional insulin to the patient, which could cause hypoglycemia.

The present disclosure relates to an automated glycemic control system configured to provide automatic delivery of a glucose control therapy to a patient and to receive information regarding a manual glucose control therapy to be provided to the patient. Using the received information regarding the manual glucose therapy, the automated glycemic control system can adjust a glycemic control algorithm to account for manual administration of insulin (or a counter therapy). The manual glucose control therapy may be provided by injection therapy or by an insulin pump.

In some cases, the automated glycemic control system may receive instructions for insulin or medication to administer to the patient instead of an automatically calculated dose of insulin. For example, the automated glycemic control system may receive an indication that the patient is eating or will eat a meal. The instructions may include the type of meal to be consumed (e.g., breakfast, lunch, or dinner) and an estimate of the amount of food or carbohydrates to be consumed (e.g., less than usual, a normal amount, more than usual, 30-40 grams of carbohydrates, 45-60 grams of carbohydrates, etc.). Based on the instructions or meal notification, the automated glycemic control system can calculate the amount of insulin to administer to the patient. The calculation may be based on an insulin-to-carbohydrate ratio provided by a clinician and/or determined by the automated glycemic control system. Additionally, the calculation may be based at least in part on the patient's history of blood glucose measurements when consuming particular meals.

The calculated amount of insulin for the user-announced meal may be presented to the user. The user (e.g., the patient) may change the amount of insulin to administer. For example, the user may determine that more or less insulin should be administered for the size of the meal the patient is consuming or about to consume. In such a case, the user may modify the calculated insulin dose to be consistent with the user's determination of the amount of insulin to administer. In some cases, the automated glycemic control system may modify its control algorithm based on user input. Thus, future meal announcements may result in insulin calculations that meet the patient's insulin needs and/or preferences.

For example, the automated glycemic control system may receive a meal notification from a user in response to user interaction with a user interface. The meal notification may correspond to an indication of the size of a meal consumed or to be consumed by the patient, as discussed herein. The automated glycemic control system may determine an insulin meal bolus to administer to the patient based at least in part on the meal notification. The insulin meal bolus may correspond to an amount of insulin to administer to the patient to compensate for changes in blood glucose due to the meal. The automated glycemic control system may output an indication of the insulin meal bolus for display. The automated glycemic control system may receive an indication of a requested modification to the insulin meal bolus from the user. The automated glycemic control system operates a control algorithm for automatically generating an insulin administration signal configured to operate a drug pump to control the patient's blood glucose level based at least in part on the patient's glucose level and the modification to the insulin meal bolus.

In some cases, an indication of the manual bolus amount may be received by the user entering a numerical value related to the administration of insulin (e.g., an amount of insulin, a number of carbohydrates, or another calculation), which can be considered the specific gesture interaction required for entering a manual bolus of medication. In some cases, the specific gesture interaction required for entering a manual bolus of medication can be a sliding motion or other movement on a touch screen to confirm or initiate a desired function, as described herein. As described above, the automated glycemic control system can automatically calculate a meal dose of insulin and present it to the user via a user interface where the user can enter manual bolus information. When providing a meal announcement, the user can have the option to enter a manual bolus. The blood glucose pump's meal controller can provide recommendations for manual entry if there is a previous history of online operation or a basis for making a recommendation.

The information can be received from the user via a user interface. This user interface may be provided by the automated glycemic control system. Alternatively or additionally, the user interface may be generated by another device, such as a laptop or desktop, a smartphone, a smartwatch, or any other computing device capable of communicating with the automated glycemic control system via wired or wireless communication. The information may include one or more of instructions for delivery of the manual bolus (e.g., via injection therapy), the amount of the manual bolus, the type of insulin (or other medication), the time the manual bolus was delivered, the general location where the manual bolus was administered to the patient (e.g., back, stomach, arm, leg, etc.), the reason for the manual bolus (e.g., meal, maintenance dose, pre-exercise blood glucose reading, etc.), and any other information that may be usable by the glycemic control system in controlling the patient's blood glucose levels.

Advantageously, in certain embodiments, providing manual dosing information to the automated glycemic control system can assist the glycemic control system in maintaining the patient's blood glucose level within a desired range when the automated features of the glycemic control system are active or operable. For example, if the automated glycemic control system determines from a CGM sensor reading that the patient's blood glucose level is high, the automated glycemic control system may typically administer a bolus of insulin. However, if the automated glycemic control system receives an indication that a manual bolus of insulin was recently administered (e.g., within the past 30 minutes), the automated glycemic control system may reduce or not administer the insulin bolus, thereby preventing a hypoglycemic event and providing glycemic control. In some such cases, the automated glycemic control system may continue to monitor the patient's blood glucose level and may later administer additional insulin if the blood glucose reading does not reflect the expected blood glucose level based on the reported manual bolus of insulin.

In some cases, it may not be necessary to receive a manual bolus instruction because, for example, the user may have the automated glycemic control system provide a manual bolus. In such cases, the automated glycemic control system may track the amount of insulin delivered and the timing of the bolus administration. To track manual boluses, the automated glycemic control system may store information related to the manual bolus in a treatment log. Thus, when the automated glycemic control system is operating in automatic mode, the automated glycemic control system may access the treatment log to determine whether a manual bolus was administered, and if so, the timing and amount of the manual bolus.

In some cases, the automated glycemic control system can model the decrease in insulin or other medication in plasma over time based on information related to the manual bolus. Modeling of medication decrease over time can be used to estimate the future effects of previously administered medications. In some cases, the model can account for medications previously administered by the automated glycemic control system. Additionally, in some cases, the model can consider physiological characteristics of the patient, such as the patient's weight or input parameters related to the patient's weight (e.g., body mass, body mass index). Furthermore, the model can account for the perfusion of a medication bolus from a subcutaneous injection site into the patient's plasma over time. Additionally, the automated glycemic control system can model insulin accumulation, model the time course of insulin activity, or model the finite utilization rate of insulin.

Based on the model, the automated glycemic control system, when operating in an automatic mode, can automatically generate an insulin administration signal configured to regulate the automatic administration of insulin or other medication to operate a drug pump to control blood glucose levels. Additionally, the automated glycemic control system can operate the administration of the medication (e.g., by controlling a drug pump) based on the patient's glucose level and the modeled concentration of the medication in the patient, which may include the time course of the medication's activity in the patient due to the medication's finite availability rate as discussed herein.

In some cases, the automated glycemic control system may confirm that a manual bolus has been delivered to the patient. Confirmation may be determined at least in part based on whether the blood glucose reading from the CGM sensor matches or is within a threshold level expected by the automated glycemic control system based on the manual dosing information. Alternatively or additionally, the automated glycemic control system may request, via a user interface, that the user confirm that the manual bolus has been delivered. When a manual bolus is delivered by the automated glycemic control system, the user may be requested to confirm administration of the manual bolus by using a specific gesture or series of interactions with the user interface (e.g., a touch screen) of the automated glycemic control system or a device (e.g., a laptop or smartphone) communicating with the automated glycemic control system.

As mentioned above, in some cases, the information about the manual bolus may include the amount of insulin and the reason the manual bolus was administered (e.g., for a meal of a particular size). In some such cases, the automated glycemic control system may determine the amount of insulin the automated glycemic control system would administer in automatic operation mode if a manual bolus had not been delivered based on the manual dosing information. If the automated glycemic control system determines that a different amount of medication was delivered, and if the difference exceeds a threshold, the automated glycemic control system may adjust the glycemic control algorithm to account for the difference. For example, the automated glycemic control system may change the insulin operating setpoint or range that the automated glycemic control system attempts to maintain in the patient. As another example, the automated glycemic control system may supplement the manual bolus with additional insulin to account for an underdose of insulin, or reduce subsequent insulin doses to account for an overdose of insulin.

As previously described, the automated glycemic control system may maintain a treatment log of manual insulin therapy. This treatment log may be maintained based on information provided by a user based on use of the automated glycemic control system to deliver a manual bolus or based on manual administration of insulin (e.g., by injection). A manual bolus may be delivered when the automated glycemic control system is not operating, not operating in automatic mode, or not connected to a patient. When the automated glycemic control system is connected to a patient and configured in automatic mode, the automated glycemic control system may determine the treatment to deliver to the patient based on a combination of the treatment log, if any, and the glycemic control algorithm implemented by the automated glycemic control system.

The automated glycemic control system can generate a dose control signal based on the determined therapy. This dose control signal can be provided to a drug pump that can control the delivery of a medication (e.g., insulin) to the patient.

In some cases, a user can control whether the automated glycemic control system is operating in manual mode or automatic mode by interacting with a user interface of the automated glycemic control system or a device that communicates with the automated glycemic control system. User interaction may include any type of user interaction with the user interface. For example, user interaction may include interaction with a physical button or interaction with a touch screen, including gestures or taps on the touch screen.

Additional embodiments relating to managing meal drug doses and manual administration that may be combined with one or more embodiments of the present disclosure are described in U.S. Provisional Application No. 62/911,143, filed October 4, 2019, and entitled "SYSTEM AND METHOD OF MANAGING MEAL DOSES IN AN AMBULATORY MEDICAL DEVICE," the disclosure of which is incorporated herein by reference in its entirety for all purposes.

One or more computer systems can be configured to perform a particular operation or actions by installing software, firmware, hardware, or a combination thereof on the system that, when in operation, causes the system to perform the operation. One or more computer programs can be configured to perform a particular operation or actions by including instructions that, when executed by a data processing device, cause the device to perform the operation. One general aspect includes a method that includes providing a user with the option of administering medication using a manual delivery component or an automated delivery system. The method also includes receiving, by the automated delivery system, subjective information regarding an activity or behavior that may alter blood glucose levels. The method also includes receiving, by the manual delivery component, an amount of medication to be infused. The method also includes storing the time and the amount of medication to be infused in the automated delivery system to control blood glucose levels. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the operations of the method.

Implementations may include one or more of the following features: A method in which the automated delivery system alters medication delivery based on the time and amount of medication received from either the manual delivery component or the automated delivery system; A method in which the manual delivery component includes a keypad that allows a user to input a desired medication dosage; A method in which the option to select is provided before a user engages in an activity that may alter blood glucose levels; A method in which the activity that may alter blood glucose levels includes ingesting food or exercising; A method in which the subjective information regarding the food consuming activity includes an approximate relative size of the food to be consumed; A method in which the approximate relative size of the food is compared to the user's recommended meal dose, and depending on whether the approximate relative size is the same as, larger than, or smaller than the recommended dose, the model predictive control component can determine the action required to regulate blood glucose levels; A method in which the subjective information regarding the exercise activity includes the intensity and duration of the exercise; A method in which the intensity and duration of the exercise are compared to a recommended intensity and duration, and depending on whether the intensity and duration are the same as, larger than, or smaller than the recommended intensity and duration, the automated delivery system can determine the action required to regulate blood glucose levels. Implementations of the described techniques may include hardware, methods or processes, or computer software on a computer-accessible medium.

One general aspect includes a system having a medical device configured to provide a user with an option to select whether to receive medication using a manual delivery component or an automated delivery system. The system also includes an automated delivery system configured to receive subjective information regarding an activity that may alter blood glucose levels. The system also includes a manual delivery component configured to receive an amount of medication to be infused. The system also includes the medical device storing the time and amount of medication to be infused in the 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 operations of the method.

When requesting a treatment change using a mobile medical device, users may have different preferences. Therefore, it is desirable for the latest technology, especially mobile medical devices, to have optional features. These optional features can satisfy different preferences of users and patients. The optional features can allow users to have more control over treatment changes and can allow users to be more involved in the medical assistance of the mobile medical device.

To satisfy various preferences, mobile medical devices should provide options that allow users to manually request the desired medication amount or select an automated delivery system that automatically delivers the appropriate amount of medication at the appropriate time without further assistance. For the manual component, the user can personally input the desired amount into a keypad provided by the medical device. The medical device then confirms and delivers the requested medication. After the medication is infused via the manual delivery component, the data is stored in the model predictive control component, which is further used to control and regulate blood glucose levels. However, if the user decides to use an automated delivery system, the user must provide subjective information regarding the activity or behavior that may alter blood glucose levels. For example, if the blood glucose altering activity is consuming food, the user must provide the time and dosage of the food that is about to be consumed. This information is tied to the automated delivery system, and the subjective information is further stored in the model predictive control component.

Embodiments described herein include a mobile medical device with a keypad that allows a user to input the dose of insulin or glucagon to be administered to the user. The user may want to receive a single dose of insulin before ingesting food and determine how much insulin needs to be administered. In other embodiments, the user can choose to receive a burst of glucagon due to hypoglycemia due to physical activity. Embodiments may include options for manual entry of medication and an automatic medication delivery system. In various implementations, the automatic medication delivery system is driven by blood glucose levels or related trends. Embodiments herein address issues that may arise when a user has just received a manual dose and has switched on the automatic delivery system. In such cases, the automatic delivery system is aware of all manual medication injections and the timing of such injections. Thus, when the manual delivery component delivers any medication, it can inform the automatic delivery system of the type of medication to be delivered, the amount of medication, and the timing of the medication to be delivered. With this information, the automatic delivery system can determine the amount of medication in the user's bloodstream and adjust the automatic delivery of medication and the timing of the automatic delivery. Thus, embodiments aim to enable a risk-free or minimal transition from manual delivery components and automated delivery systems.

Differences from other systems may include manual delivery being tied to an automated delivery system, and dosage input from the user being stored in and processed by an MPC (Model Predictive Control) algorithm instead of a meal delivery algorithm. Other embodiments may include a selection that can have values adjusted algorithmically. Other embodiments may include a learning algorithm that includes a regular size meal or a larger size meal or a small size meal. An embodiment may include correlating manual input with asking the user what the meal size was and learning how insulin affects the user. An embodiment may include correlating manual input with asking the user what activities the user performed and learning how glucagon affects the user for specific activities.

BGCS with manual dose management
36 shows a schematic diagram of a therapy change delivery system 3600 within a mobile medical device 3602 that allows a user to select to receive manual delivery of medication or automatic delivery of medication. Additionally, therapy change delivery system 3600 allows a user to easily transition between manual and automatic modes. The therapy change delivery system 3600 includes a mobile medical device 3602, a signal processing component 3603, a user 3604, a therapy delivery component 3605, a therapy change input 3606, an input component 3607, an activity change component 3608, and therapy change delivery 3610. If the user intends to receive therapy from the mobile medical device 3602, the user 3604 can initiate therapy change input 3606 to request manual or automated medication.

The mobile medical device 3602 is any medical device that can be carried by a user 3604 and used with the approval of a medical professional. Many different types of mobile medical devices 3602 exist. In one embodiment, the mobile medical device 3602 is an insulin and/or glucagon infusion device for a user 3604 with Type 1 diabetes. The mobile medical device 3602 allows the user 3604 the freedom to receive medical care in any setting that is convenient for them. However, a drawback to using a mobile medical device 3602 can be the user 3604 making mistakes when the user is away from a medical professional. Potential problems can occur when the user 3604 switches from a manual delivery mode to an automatic delivery mode when the automatic delivery mode is unable to determine the amount of medication in the user's bloodstream. An embodiment relates to manual medication delivery information being provided to an automated medication delivery system so that it can adjust its operation based on current and future medication in the user's bloodstream. In some cases, such as in embodiments where the ambulatory medical device 3602 is an insulin and/or glucagon infusion device, providing automated delivery of medications can be problematic.

The mobile medical device 3602 includes a signal processing component 3603, a therapy delivery component 3605, and an input component 3607. The signal processing component 3603, the therapy delivery component 3605, and the input component 3607 may be physically connected, wirelessly connected, connected via a cloud-based computer system, or connected in other ways.

The signal processing component 3603 is a computing system that performs the computing functions for the mobile 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 composed of several computing systems. The signal processing component 3603 can perform the computing functions for a single mobile medical device 3602 or for many mobile medical devices 3602. The signal processing component 3603 receives signals from the therapy delivery component 3605 and the input component 3607. The signal processing component 3603 also sends signals to the therapy delivery component 3605 and the input component 3607. Signals for all steps of therapy change input 3606, therapy change delivery 3610, and 3608 can be received or sent by the signal processing component 3603.

User 3604 is any individual who uses mobile medical device 3602. In one embodiment, user 3604 is an individual with diabetes who requires regular injections of insulin or glucagon to maintain healthy blood glucose levels. In various embodiments, mobile medical device 3602 injects insulin or glucagon into user 3604. User 3604 may carry mobile medical device 3602. Thus, as user 3604 moves about, there is a risk that user 3604 may inadvertently activate an input in mobile medical device 3602 that initiates a therapy change input 3606.

The therapy delivery component 3605 provides medication to the user 3604. Signals received from the signal processing component 3603 are executed by the therapy delivery component 3605 to modify the therapy, such as starting, modifying, or stopping the 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 may follow a program controlled by the signal processing component 3603. In one embodiment, the therapy delivery component 3605 is one or more infusion pumps. The infusion pumps can deliver fluids to the user 3604 at various rates. The infusion pumps can deliver any fluid, including medication. The infusion pumps may be connected to the user 3604 via any means. In one example, the infusion pumps are connected to the body via a cannula. In an exemplary embodiment, the therapy delivery component 3605 is an insulin infusion pump. Also in an exemplary embodiment, the therapy delivery component 3605 is an insulin and glucagon infusion pump. The signals received from the signal processing component 3603 can be interpreted by the insulin and glucagon pumps to start, stop, or change the rate at which insulin and glucagon are delivered to the user 3604.

In an exemplary embodiment, the therapy delivery component 3605 is an electrical stimulation device. One example of an electrical stimulation device is a cardiac pacemaker. A cardiac pacemaker stimulates the heart muscle to control the heart rhythm. Commands received from the signal processing component 3603 may be interpreted by the cardiac pacemaker to start stimulation of the heart muscle, stop stimulation of the heart muscle, or change the rate of stimulation of the heart muscle. Another example of an electrical stimulation device is a deep brain stimulation device for treating Parkinson's disease or movement disorders. Commands received from the signal processing component 3603 may be interpreted by the deep brain stimulation device to start, stop, or modify stimulation of the brain.

The therapy change input 3606 is an input provided by the user 3604 to change the therapy currently being provided to the user 3604. The therapy change can be to start a therapy, change a therapy, or stop a therapy. There are many types of possible therapy changes, and the type of therapy change depends on the type of mobile medical device 3602. In one embodiment, the mobile medical device 3602 is an insulin or glucagon infusion device. However, there are many possible embodiments of the mobile medical device 3602 for the disclosed subject matter. The therapy change input 3606 in an insulin or glucagon infusion device can be a command that, when executed, causes the insulin or glucagon infusion device to begin infusing a certain amount of insulin or glucagon to the user 3604. Alternatively, the therapy change input 3606 can be an instruction to the user 3604 to change the rate of insulin or glucagon infusion. The therapy change input 3606 can also be an instruction to cancel an insulin or glucagon infusion from the insulin or glucagon infusion device to the user 3604. In an exemplary embodiment, the mobile medical device 3602 is an electrical implant that stimulates a part of the body when operated. An example is an electrical brain implant for a user 3604 with Parkinson's disease or for pain management. The therapeutic modification can be to change the rate of electrical stimulation to the body.

The therapy change delivery 3610 is the performance by the mobile medical device 3602 of the therapy change input 3606 verified by 3608. The therapy change delivered by the therapy change delivery 3610 corresponds to the therapy change selection made by the user 3604. In one embodiment, the mobile medical device 3602 alerts the user 3604 that it is performing the therapy change delivery 3610. In an example of various embodiments, the mobile medical device 3602 displays the therapy change during the therapy change delivery 3610. Any number of details of the therapy change can be displayed during the therapy change delivery 3610. As shown in FIGS. 23 and 43 , a simple message saying "Delivering" can be displayed during the therapy change delivery 3610. Alternatively, more precise details such as "Delivering 2 units of insulin" or "Delivering insulin at 2 units/minute" may be displayed. In another example, the mobile medical device 3602 plays a sound effect during the therapy change delivery 3610. 43, the therapy change delivery 3610 may be canceled by an input by the user 3604. The input to cancel the 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 component 3607 allows the user 3604 to interact with and control the mobile medical device 3602. The amount of control the user 3604 has may vary based on the type of mobile medical device 3602 and the user 3604. For example, a mobile medical device 3602 that delivers pain medication may allow the user more control than a mobile medical device 3602 that controls heart rhythm. In another example, a user 3604 who is a young child (under approximately 10, 11, or 12 years) may be granted less control over the mobile medical device 3602 than a user 3604 who is a teen or adult. The input component 3607 includes a wake button 3620, a touch screen display 3622, and an alphanumeric pad 3624.

The wake button 3620 is activated by the user 3604 to generate a wake signal input to unlock the mobile medical device 3602. The wake button 3620 may be any input button. In one embodiment, the wake button 3620 is a capacitive button that detects changes in capacitance. The wake button 3620 may have a computational component for interpreting and executing instructions from the signal processing component 3603. Thus, the wake button 3620 may follow a program dictated by the signal processing component 3603.

The touchscreen display 3622 can display a therapy modification user interface for the user 3604 and receive input from the user 3604 on the input surface of the touchscreen display 3622. Input on the touchscreen display 3622 can be registered by any touch technology, including, but not limited to, capacitive and resistive sensing. The touchscreen display 3622 can be part of a mobile computing device, such as a cell phone, tablet, laptop, or computer. The touchscreen display 3622 can have a computing component for interpreting and executing instructions from the signal processing component 3603. Thus, the touchscreen display 3622 can follow instructions dictated by the signal processing component 3603. To receive input, the touchscreen display 3622 can display buttons, alphanumeric characters, symbols, graphic images, animations, or videos. The touchscreen display 3622 can display an image indicating when the mobile medical device 3602 is locked or inaccessible via the touchscreen display 3622. The touchscreen display can receive a series of inputs comprising a first gesture and a second gesture.

The alphanumeric pad 3624 registers numeric, alphabetic, and symbolic inputs. The alphanumeric pad 3624 includes a number of keys corresponding to numeric, alphabetic, and symbolic inputs. The alphanumeric pad 3624 may have a computational component for interpreting and executing instructions from the signal processing component 3603. Thus, the alphanumeric pad 3624 can follow instructions directed by the signal processing component 3603. The alphanumeric pad 3624 may be configured to provide tactile feedback from its keys. The alphanumeric pad 3624 may have any number of keys and any number of characters and may span multiple screens that the user 3604 can switch between to find all the characters they are looking for. In one embodiment, the wake button 3620 is incorporated into the alphanumeric pad 3624. In various embodiments, the wake button 3620 may be any one or more keys of the alphanumeric pad 3624. In an exemplary embodiment, the alphanumeric pad 3624 is displayed as part of the touch screen display 3622. Characters from the alphanumeric pad 3624 can be used as input for the wake signal input, the first gesture, the therapy change selection, and the second gesture. In an exemplary embodiment, the first gesture and/or the second gesture are created by entering predetermined characters on the alphanumeric pad 3624.

The activity modification component 3608 may be a portion of dedicated software executing on the mobile medical device or may include dedicated hardware that performs the various functions described herein. The activity modification component 3608 can receive input from the user regarding whether the user is about to engage in an activity that will alter the user's blood glucose level. For example, the user can use the input component 3607 to provide input that the user is about to engage in exercise that may lower blood glucose or eat a meal that will increase blood glucose. Upon receiving the activity modification from the input component 3607, the activity modification component 3608, via the mode controller 3613, provides the user with the option to select between the automatic delivery system 3612 and the manual delivery component 3614. As shown in FIG. 36 , the manual delivery system can notify the automatic delivery system 3612 and the model predictive control component 3616 regarding any manual drug delivery of insulin or glucagon discussed herein, including via a treatment log.

In various embodiments, the user can select the dosage, drug type (insulin or glucagon; fast or slow acting), and delivery time, and the manual delivery component 3614 can receive such information and deliver the medication accordingly. In one embodiment, the manual delivery component 3614 can 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 delivery time.

When a user activates the automated delivery system 3612, data from previous manual drug injections can be readily available so that the automated delivery system 3612 can determine how much drug is still present in the user's bloodstream. The automated delivery system 3612 can make this determination by tracking the patient's finite utilization of the injected insulin based on the time and amount of any manual drug injections reported to the automated delivery system 3612, for example, by determining the time course of the drug's activity in the patient.

Figure 37 is a flowchart of process 3700 detailing the medication selection process, according to an exemplary embodiment. In step 3710, the medical device provides the user with the option to select whether to receive the medication using a manual delivery component or an automated delivery system. Using mode controller 3613, the user can select the method for therapy change requests between the manual delivery component and the automated delivery system.

In step 3720, the medical device can receive subjective information regarding an activity or movement that may change blood glucose levels. The subjective information may include meal size and/or type of physical activity. In step 3730, the manual delivery component can receive a quantity of medication to be infused. The medication may be multiple hormones, including but not limited to glucagon or insulin. In step 3740, the medical device can store the time and amount of medication infused in the automatic delivery component that controls blood glucose levels. The system disclosed in FIG. 36 includes steps 3710, 3720, and 3730.
It is utilized to accomplish all steps from 0, 3730, and 3740.

FIG. 38 is another flow diagram of a process 3800 for providing options for a user's meal dose selection or physical activity on a mobile device. Embodiments described herein include a mobile medical device with a keypad that allows a user to input the dose of insulin or glucagon to be administered to the user. The user may want to receive a single dose of insulin before ingesting food and determine how much insulin needs to be administered. In some cases, the user may choose to receive a burst of glucagon due to hypoglycemia due to physical activity. Embodiments may include options for manual entry of medication and an automatic medication delivery system. In various implementations, the automatic medication delivery system is driven by blood glucose levels or related trends. Embodiments herein address issues that may arise when a user has just received a manual dose and has switched on the automatic delivery system. In such cases, the automatic delivery system can recognize all manual medication injections and the timing of such injections, for example, in a treatment log as discussed herein. Thus, when the manual delivery component delivers any medication, it can inform the automatic delivery system of the type of medication being delivered, the amount of medication, and the timing of the medication being delivered. Armed with this information, the automated delivery system can determine the amount of medication in the user's bloodstream and coordinate the automated delivery and timing of the medication. Thus, embodiments are directed to enabling a risk-free or minimal-risk transition away from manual delivery components and automated delivery systems.

In block 3810, the user may notify the activity change component 3608 that the user is about to engage in an activity that may change the user's blood glucose level. The mode controller 3613 may be invoked in decision block 3820 to ask whether the user would like to proceed to block 3830 using the manual delivery component 3614 or to block 3850 using the automated system 3612. The mode controller 3613 may include displaying a manual bolus screen that includes manual bolus control elements and bolus recommendations that include indications of medication bolus amounts generated by the control algorithm as discussed herein.

If the user selects to use the manual delivery component 3614 in block 3830 and the user provides input to inject the medication (e.g., an indication of a manual bolus amount of the medication), the mobile device 3602 can deliver the medication to the user. The activity modification component 3608 can automatically adjust the insulin dose control signal based on the manual bolus amount of insulin. The activity modification component 3608 can generate a glucagon dose control signal based at least in part on the indication of the manual bolus amount of insulin. Upon completion of the manual delivery process, the manual delivery component 3614 in block 3830 can notify at least one of the model predictive control component 3616 in block 3840 and the automated delivery system 3612 in block 3850 of the type of medication, the amount of medication, and the time the medication was delivered. The predictive control component 3616 of block 3840 and the automated delivery system 3612 of block 3850 can track these manual injections of medication and determine the total amount of medication remaining in the user's bloodstream for a particular time or period based on the drug's decay rate or half-life, e.g., in a treatment log as discussed herein. Thus, when the automated delivery system 3850 is activated by the user, the automated delivery system 3850 can modify its medication injection based on the medication remaining in the user's bloodstream after the user's manual injection. The predictive control component 3616 can store an indication of the amount of the manual bolus of medication delivered to the patient and an indication of the time the manual bolus of medication was delivered to the patient. The predictive control component 3616 can model the decline of the medication in the patient over time based at least in part on the manual bolus of medication. The predictive control component 3616 can model the accumulation of the manual bolus of medication in the patient's blood following a subcutaneous injection of the medication.

Differences from other systems may include manual delivery being tied to an automated delivery system, and dosage input from the user being stored in and processed by an MPC (Model Predictive Control) algorithm instead of a meal delivery algorithm. Other embodiments may include a selection that can have values adjusted algorithmically. Other embodiments may include a learning algorithm that includes averaging a regular size meal or a larger size meal or a small size. Embodiments may include correlating the manual input with asking the user what the meal size was and learning how insulin affects the user. Embodiments may include correlating the manual input with asking the user what activities the user performed, learning how glucagon affects the user for specific activities, and/or storing information in a treatment log to model drug reduction in the patient over time based at least in part on manual boluses of drug.

FIG. 39 illustrates multiple screens 3900 that may be generated by the mobile medical device 100. The multiple screens 3900 illustrate the process a user can take to enter a meal dose. When the mode controller 3608 is activated, a meal dose entry screen 3910 may be displayed. When screen 3910 is displayed, warning text may be displayed to the user to ensure safety. The warning text states that entering the dose may be unsafe and that the device will not match the meal dose. This warning text alerts the user to the risks that may be involved in the process of using the mobile medical device 3602. After the user acknowledges the warning signs and chooses to continue, a password screen 3920 may be displayed. When the password screen 3920 is displayed, a keypad is provided for the user to enter a predetermined series of numbers to ensure that the user is an actual registered user of the mobile medical device 3602. Note that if the mobile medical device 3602 receives the correct predetermined password from the user, a meal dose entry formula screen 3930 and a meal dose formula screen 3940 may be displayed. The user may decide to access extension screen 3960, which allows the user to double-check CGM insulin levels and change the speed of the insulin pump. In screens 3930 and 3940, the user is provided with the option to turn the meal keypad on or off. If the user chooses to turn the keypad on, the user may be provided with the option to select a maximum dose limit. If the user decides to select a maximum dose limit, an official maximum dose limit screen 3950 is displayed, allowing the user to enter a dose of up to 10 units. The number of units provided is then stored in the model predictive control component 116 for further adjustment of blood glucose levels.

FIG. 40 illustrates multiple screens 4000 that may be generated by the mobile medical device 3602. Upon powering up the mobile medical device 3602, an initial menu screen 4010 may be displayed. The menu screen 4010 provides options related to the functionality of the mobile medical device 3602. The list of features may cover all aspects of the mobile medical device 3602. A user can access and control many aspects of the device by selecting a settings option. The settings option allows the user to further evaluate and adjust adjustable features of the mobile medical device 3602. Selecting the settings option displays a settings screen 4020, allowing the user to select an advanced settings option. Selecting the advanced options displays an advanced settings screen 4030, providing the user with the option to double-check CGM insulin levels and change the speed of the insulin pump. The user can speed up or slow down the process depending on the adjustment statistics provided by the model predictive control component 3616. The advanced settings screen or state 4030 may be passcode protected as described herein.

FIG. 41 illustrates multiple screens 4100 that may be generated by the mobile medical device 3602. The multiple screens 4100 are processes a user can perform to input meal notifications. The home screen 4110 provides information and statistics about the cartridge of the mobile medical device 3602. The user can select the Meal button with or without installing a new cartridge. If the user selects the Meal button without installing a new cartridge, the mobile device 3602 displays a warning screen 4130, where the user is alerted that the insulin cartridge is empty and the device further advises the user to replace the cartridge. However, if a new cartridge has already been installed and the Food button is pressed, the mobile medical device 3602 displays a Carbohydrate screen 4120, where the user is given the option to select a meal dose option, which may correspond to an indication of the size of the meal consumed or to be consumed by the patient. The Carbohydrate screen 4120 allows the user to provide subjective information regarding the food consumed. This subjective data provided by the user is further stored in the model predictive control component 3616 to further adjust blood glucose levels.

FIG. 42 shows multiple screens 4200 that may be generated by the ambulatory medical device 3602. The multiple screens 4200 illustrate the user's process of being alerted to an empty cartridge and having the option to replace the cartridge and further enter a meal dose. Warning screen 4210 alerts the user that the insulin cartridge is empty and needs to be replaced. Once the cartridge is replaced, screens 4220 and 4230 are displayed. Screen 4220 is displayed initially, allowing the user to enter a specified dose for each meal into the numeric pad, which may correspond to an indication of the size of the meal consumed or to be consumed by the patient. Once the numeric specified dose is inserted, screen 4230 is displayed, providing a next button for the user to further complete the therapy change. The numeric specified dose is further stored in the model predictive control component 3616 for further adjustment of blood glucose levels. For example, the AMD can proceed to determine a meal bolus of insulin to administer to the patient based at least in part on the meal announcements discussed herein. The meal bolus of insulin can correspond to the amount of insulin to administer to the patient to compensate for changes in blood glucose due to the meal.

FIG. 43 illustrates multiple screens 4300 that may be generated by the mobile medical device 3602. Upon selecting a delivery request, the user may cancel the medication delivery before completion of delivery. The mobile medical device 3602 displays a countdown prior to delivery. The initial countdown screen 4310 advances to a secondary countdown screen 4330. During these countdown screens, a cancel button is provided for the user to cancel the therapy change. The user may cancel the delivery at any time during the initial countdown screen 4310 or the secondary countdown screen 4330. By swiping the cancel button, the user may formally stop the delivery of the therapy change. If the user does not cancel, the therapy change may be successfully delivered. Additionally, the time and amount of therapy change delivery are stored in the model predictive control component 3616 for further adjustment of blood glucose levels. However, if the user decides to cancel the delivery, the delivery is canceled and screen 4320 is provided. When delivery cancellation is requested and screen 4320 is displayed, pressing the OK button causes the mobile medical device 3602 to display lock screen 4340, and the treatment change request is officially canceled over time.

FIG. 45 shows an exemplary process 4500 for receiving input for a manual glucose control therapy provided by a glucose control system via user interaction with a user interface. The automated glycemic control system can be configured to provide automatic delivery of a glucose control therapy to a patient and also provide a manual glucose control therapy when requested by a user. In block 4510, the control algorithm generates an indication of a medication bolus amount. The control algorithm is configured to provide automatic control of the patient's blood glucose level and can automatically generate correction dose and meal dose bolus amounts based on at least one of the patient's indicated blood glucose level, a meal notification, an indicated meal size, a control parameter selected manually or automatically by the control system, or any combination of the aforementioned values. In block 4520, the medication bolus can correspond to a medication meal bolus or a medication correction bolus, and the medication bolus amount can be selected by the control algorithm based at least in part on a previous period of glycemic control in the patient.

In block 4530, the glucose control system generates a display of a manual bolus screen, which may include a manual bolus control element that can facilitate manual entry of medication bolus amount instructions. The medication bolus amount instructions may include the amount of medication, the amount of carbohydrates in a meal, and/or other manual therapy instructions. The manual bolus screen may include a bolus recommendation generated by the control algorithm that may include an indication of the amount of medication bolus. The bolus recommendation may be for a correction dose or a meal dose, may be in the form of a certain amount of medication, and/or, in the case of a meal dose, may be an estimate of the amount of carbohydrates ingested in a typical meal or meal of a size selected by the user. The meal dose may account for the time of the meal and typical meal composition, as indicated by the period preceding and following the postprandial glycemic response.

At block 4540, the glucose control system may receive an indication of a manual bolus amount of medication via user interaction with a manual bolus control element. The indication may include one or more instructions manually entered via user interaction with one or more user interface control elements.

In block 4550, the glucose control system may store in a treatment log or another suitable location one or more of the manual bolus amount of medication, the manual bolus amount of medication actually delivered to the patient, and/or an indication of the time the manual bolus of medication was delivered to the patient.

In block 4560, the glucose control system can use a model to determine the patient's medication decline over time based at least in part on the manual boluses of medication. Modeling the medication decline can account for the finite utilization rate of the manual boluses of medication and can use one or more models as described herein and in the controller disclosure.

At block 4570, the glucose control system may operate a control algorithm for automatically generating an insulin delivery signal configured to operate a drug pump to control blood glucose levels in the patient based at least in part on a glucose level signal received from a glucose level sensor operably connected to the patient and a time course of activity of the drug in the patient due to a finite utilization rate of the drug. The drug in the patient may include a manual bolus of the drug and/or one or more automatically generated boluses of the drug.

44 is a block diagram illustrating a computer system 4400 that may be implemented in various embodiments of the described subject matter. The computer system 4400 includes a processor 4402, a main memory 4404, storage 4406, a bus 4408, and an input 4410. The processor 4402 may be one or more processors. The processor 4402 executes instructions communicated to it via the main memory 4404. The main memory 4404 provides instructions to the processor 4402. The main memory 4404 is also connected to the bus 4408. The main memory 4404 may communicate with other components of the computer system via the bus 4408. Instructions for the computer system 4400 are transmitted to the main memory 4404 via the bus 4408. These instructions may be executed by the processor 4402. The executed instructions may be returned to the main memory 4404 for distribution to other components of the computer system 4400. The storage 4406 can hold a large amount of data and can retain that data while the computer system 4400 is powered off. The storage 4406 is connected to the bus 4408, and the data held by the storage can be communicated to the main memory 4404 via the bus 4408.

The processor 4402 may be any type of general-purpose processor, including, but not limited to, a central processing device ("CPU"), a graphics processing device ("GPU"), a complex programmable logic device ("CPLD"), a field programmable gate array ("FPGA"), or an application-specific integrated circuit ("ASIC"). One embodiment of the computer system 4400 within the mobile medical device 100 features a CPU as the processor 4402. However, embodiments of the computer system of the mobile medical device 100 incorporating other types of processors 4402 are contemplated.

Main memory 4404 may be any type of main memory capable of communicating instructions to and receiving instructions for execution from 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, computer system 4400 incorporates RAM as a form of main memory 4404 for communicating instructions to and receiving instructions for execution from processor 4402. Other embodiments may be envisioned that incorporate other types of main memory 4404 into computer system 4400.

Storage 4406 may be any type of computer storage capable of receiving data, storing data, and transmitting data to main memory 4404 via bus 4408. Types of storage 4406 that may be used in computer system 4400 include, but are not limited to, magnetic disk memory, optical disk memory, and flash memory. In one embodiment, flash memory is used as storage 4406 in computer system 4400 of ambulatory medical device 100. Other embodiments may be envisioned that use other types of storage 4406 for computer system 4400.

The bus 4408 connects the internal components of the computer system 4400. The bus 4408 may include multiple wires connecting the components of the computer system 4400. The wiring of the bus 4408 may vary based on the components of the computer system 4400 to which the bus 4408 connects. In various embodiments, the bus 4408 connects the processor 4402 to the main memory 4404. In various embodiments, 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 generates output and accepts input. The bus 4408 may be coupled to the touchscreen display 4412 to generate visual output. The touchscreen display 4412 can also accept input via capacitive touch, resistive touch, or other touch technologies. The input surface of the touchscreen display 4412 can register the location of a touch on the surface. Some types of touchscreen displays 4412 can register multiple touches at a time. The alphanumeric pad 4414 includes multiple keys with numeric, alphabetic, and symbolic characters. Signals from the alphanumeric pad 4414 are communicated to the main memory 4404 by the bus 4408. The keys of the alphanumeric pad 4414 can be capacitive or mechanical. In some embodiments, the alphanumeric pad 4414 is displayed on the touchscreen display 4412. Button 4416, such as wake button 120, may be a capacitive, mechanical, or other type of input button.

EXEMPLARY EMBODIMENTS Below is a list of multiple sets of exemplary numbered embodiments. The features listed in the following list of exemplary embodiments can be combined with additional features disclosed herein. Furthermore, each set of exemplary numbered embodiments in the list below can be combined with one or more additional sets of exemplary numbered embodiments from the list below. Furthermore, additional inventive combinations of features are disclosed herein that are not specifically listed in the list of exemplary embodiments below and that do not include the same features as the embodiments listed below. For the sake of brevity, the following list of exemplary embodiments does not identify all inventive aspects of the present disclosure. The following list of exemplary embodiments is not intended to identify key features or essential features of the subject matter described herein.
1. A computer-implemented method for updating an application executing on a mobile medical device without interrupting care provided to a patient by the mobile medical device, comprising:
The hardware processor in the mobile medical device
receiving an indication that an application update is available, the application update including an update to an application running on the mobile medical device;
establishing a communications connection to a host computing system configured to host the application update;
downloading an application update from a host computing system;
Verifying that the downloaded copy of the application update is complete;
Verifying that the downloaded copy of the application update is not corrupted;
determining a running time for an installation process for installing the downloaded copy of the application update on the mobile medical device, the running time comprising an amount of time to run the installation process;
receiving a trigger to install the downloaded copy of the application update;
determining a next treatment delivery time associated with delivering treatment to the patient by the ambulatory medical device in response to the trigger;
determining, based at least in part on the execution time, that the installation process will be completed before the next treatment delivery time;
and initiating an installation process of the downloaded copy of the application update without interrupting treatment provided to the patient by the mobile medical device.
2. The computer-implemented method of embodiment 1, wherein the communication connection is established via a cellular network that allows the mobile medical device to communicate directly with the host computing system via the cellular network.
3. The computer-implemented method of embodiment 1, wherein the communication connection comprises a Narrowband Long Term Evolution (NB-LTE) connection, a NB Internet of Things (NB-IoT) connection, a cellular IoT connection, a 4G LTE connection, or a 5G connection.
4. The computer-implemented method of embodiment 1, wherein the communication connection comprises a direct end-to-end wireless connection over a wide area network (WAN).
5. The computer-implemented method of embodiment 1, wherein the application update comprises a new version of the application, a patch to the application, or a replacement application for the application.
6. The computer-implemented method of embodiment 1, wherein the indication that an application update is available is received in response to an application update availability check triggered by the mobile medical device.
7. The computer-implemented method of embodiment 1, wherein the indication that an application update is available is transmitted to the mobile medical device without the mobile medical device performing an action that triggers transmission of the indication to the mobile medical device.
8. The computer-implemented method of embodiment 1, wherein the next treatment delivery time is determined based at least in part on a treatment delivery schedule stored on the mobile medical device.
9. The computer-implemented method of embodiment 1, wherein the next treatment delivery time is determined based at least in part on the determined condition of the patient.
10. The computer-implemented method of embodiment 1, wherein determining a next treatment delivery time comprises estimating a next treatment delivery time based at least in part on measurements of physiological parameters of the patient.
11. The computer-implemented method of embodiment 1, wherein determining the execution time comprises estimating an amount of time to perform the installation process.
12. The computer-implemented method of embodiment 1, wherein the trigger comprises 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, an install command, or detection of a failure during execution of the application.
13. The computer-implemented method of embodiment 1, wherein determining that the installation process will complete before the next treatment delivery time comprises determining that the installation process will complete at least a threshold time before the next treatment delivery time.
14. The computer-implemented method of embodiment 1, wherein determining that the downloaded copy of the application update is complete is based at least in part on one or more of a size, a tag, a checksum, or a hash of the downloaded copy of the application update.
15. The computer-implemented method of embodiment 1, wherein determining that the downloaded copy of the application update is not corrupted is based on at least a checksum or a hash.
16. The computer-implemented method of embodiment 1, wherein the application comprises one of a first application version having a first feature set or a second application version having a second feature set, and 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.
17. The computer-implemented method of embodiment 16, wherein the indication that an application update is available comprises an indicator of whether the application update corresponds to the first application version or the second application version.
18. The computer-implemented method of embodiment 16, wherein the first feature set comprises a subset of the second feature set or a feature set that partially overlaps with the second feature set.
19. The computer-implemented method of embodiment 16, further comprising determining an application version of the application, and 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.
20. The computer-implemented method of embodiment 1, wherein the host computing system comprises a server computing device, a cloud computing device, a local computing device, a patient computing device, a healthcare provider computing device, a mobile medical equipment manufacturer computing device, a smartphone, or an application server.
21. The computer-implemented method of embodiment 1, wherein the ambulatory medical device comprises a monohormonal drug pump or a bihormonal drug pump.
22. The computer-implemented method of embodiment 1, wherein initiating an installation process of the downloaded copy of the application update without interrupting therapy comprises initiating the installation process without interrupting or preventing delivery of medication to the patient during a next therapy delivery period.
23. A computer-implemented method for updating an application running on a mobile medical device without interrupting treatment provided to a patient by the mobile medical device, comprising:
The hardware processor in the mobile medical device
receiving an indication that an application update is available, the application update including an update to an application running on the mobile medical device;
establishing a direct end-to-end data connection to a host computing system configured to host the application update, the direct end-to-end data connection being established over a wireless wide area network;
downloading the application update from a host computing system via a direct end-to-end data connection;
Verifying that the downloaded copy of the application update is complete;
Verifying that the downloaded copy of the application update is not corrupted;
receiving a trigger to install the downloaded copy of the application update;
and in response to the trigger, initiating an installation process of the downloaded copy of the application update without interrupting treatment provided to the patient by the mobile medical device.
24. The computer-implemented method of embodiment 23, wherein the direct end-to-end data connection comprises a Narrowband Long Term Evolution (NB-LTE) connection, a NB Internet of Things (NB-IoT) connection, a cellular IoT connection, a 4G LTE connection, or a 5G connection.
25. The computer-implemented method of embodiment 23, wherein the application comprises one of a first application version having a first feature set or a second application version having a second feature set, and 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.
26. A computer-implemented method for updating an application running on a mobile medical device without interrupting treatment provided to a patient by the mobile medical device, comprising:
The hardware processor in the mobile medical device
receiving an indication that an application update is available, the application update including an update to an application running on the mobile medical device;
downloading an application update from a host computing system;
Verifying that the downloaded copy of the application update is complete;
Verifying that the downloaded copy of the application update is not corrupted;
receiving a trigger to install the downloaded copy of the application update;
and in response to the trigger, initiating an installation process of the downloaded copy of the application update without interrupting treatment provided to the patient by the mobile medical device.
27. A mobile medical device configured to provide treatment to a patient and including an application that can be updated without interrupting the treatment, comprising:
a memory configured to store specific computer-executable instructions and applications that at least partially control the treatment provided to the patient;
communicate with the memory and, at a minimum,
receiving an indication that an application update is available, including an update to an application running on the mobile medical device;
Downloading application updates from a host computing system;
Verify that the download copy of the application update is complete;
Verify that the downloaded copy of the application update is not corrupted;
1. A mobile medical device comprising: a hardware processor configured to execute certain computer-executable instructions to: receive a trigger to install a downloaded copy of an application update; and, in response to at least part of the trigger, initiate an installation process for the downloaded copy of the application update without interrupting treatment provided to a patient.
28. The mobile medical device of embodiment 27, further comprising a wireless transceiver that enables the mobile medical device to establish a network connection with a host computing system over a wide area network (WAN).
29. The ambulatory medical device of embodiment 27, further comprising a drug delivery interface configured to operatively connect to a drug pump configured to infuse a drug into a patient, wherein the drug pump comprises a monohormonal drug pump or a bihormonal drug pump.
30. The hardware processor includes at least:
determining whether the installation process of the downloaded copy of the application update is completed before the next treatment time associated with administering treatment to the patient;
28. The mobile medical device of embodiment 27, further configured to execute certain computer-executable instructions to: initiate an installation process, at least in part, in response to determining that the trigger and installation process will be completed before the next treatment time; and output a warning for display to a user, at least in part, in response to determining that the installation process will not be completed before the next treatment time.

Further embodiments of the present disclosure can be described in view of the following numbered embodiments:
1. A mobile medication device configured to generate a dose control signal for delivery of a medication to a patient and configured to ensure functionality of at least a portion of a user interface of the mobile medication device,
a drug delivery interface configured to operably connect to a drug pump for infusing a drug into a patient;
a display interface configured to output a display signal configured to generate a user interface screen on a display device;
a memory configured to store certain computer-executable instructions, a user-generated passcode selected by a user during a passcode setting process, and an override passcode not selected by the user;
communicate with the memory and, at a minimum,
generating a dose control signal using a control algorithm that uses control parameters, at least one of the control parameters being modifiable by user interaction with a parameter control element displayed via at least one user interface screen of a user interface screen, and the mobile medication device not allowing modification of the at least one control parameter via the parameter control element when the mobile medication device is in a locked state;
generating a keypad passcode display including user-selectable letters, numbers, symbols, or combinations thereof in response to user interaction with a user input element of the mobile medication device when the mobile medication device is in a locked state, the keypad being configured to accept user entry of a security code;
a hardware processor configured to execute certain computer-executable instructions that, in response to verifying the security code, cause the mobile medication device to enter an unlocked state, the mobile medication device enabling modification of at least one control parameter via the parameter control element when the mobile medication device is in the unlocked state, configured to verify a security code to confirm that the user is authorized to change the lock state of the mobile medication device by verifying that the security code matches a user-generated passcode or an override passcode; and
2. The ambulatory medication device of embodiment 1, wherein the ambulatory medication device comprises an insulin pump or a bihormonal pump capable of administering insulin and a counter-regulator.
3. The ambulatory medication device of embodiment 1, wherein access to at least some functions of the user interface is permitted without verifying a security code.
4. The ambulatory medication 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 medication device of embodiment 1, wherein the parameter control elements comprise elements displayed on a touch screen display.
6. The ambulatory medication device of embodiment 1, wherein the user input element comprises a touch-sensitive surface that includes one or more visual indications.
7. The ambulatory medication device of embodiment 1, wherein the override passcode changes at periodic intervals.
8. The ambulatory medication device of embodiment 1, wherein at least some information related to therapy delivery is accessible to the user in a locked state.
9. The ambulatory medication device of embodiment 8, wherein the passcode display includes a graph of the patient's glucose levels over time.
10. A hardware processor executes specific computer-executable instructions to
configured to verify the advanced settings security code to confirm that the user is authorized to change the advanced settings of the mobile medication device by verifying that the advanced settings security code matches the advanced settings passcode; and configured to cause the mobile medication device to enter an advanced settings state in response to verifying the advanced settings security code, and when the mobile medication device is in the advanced settings state, to enable modification of at least one advanced control parameter via the advanced parameter control element.
2. The ambulatory medication device of embodiment 1.
11. The ambulatory medication device of embodiment 10, wherein the advanced passcode expires after a predetermined period of time.
12. The ambulatory medication device of embodiment 10, wherein the advanced passcode expires at least once a week.
13. The ambulatory medication device of embodiment 10, wherein the advanced passcode comprises gesture interaction with a touch screen display.
14. The ambulatory medication device of embodiment 1, wherein the override passcode is fixed during the manufacturing process.
15. The ambulatory medication device of embodiment 1, wherein the override passcode is valid for at least some other ambulatory medication devices.
16. The ambulatory medication device of embodiment 1, wherein a new override passcode is algorithmically generated when the override passcode expires.
17. The ambulatory medication device of embodiment 1, wherein if the security code cannot be verified after a predetermined number of security code entry attempts, further security code entry attempts are denied for a period of time.
18. A mobile medication device configured to generate a dose control signal for delivering medication to a patient and configured to ensure functionality of at least a portion of a user interface of the mobile medication device, comprising:
a medication delivery interface configured to operably connect to a medication pump for infusing a medication into a patient;
a memory configured to store specific computer-executable instructions, a user-generated passcode selected by a user during a passcode setting process, and an override passcode not selected by the user; and
generating a dose control signal using a control algorithm that uses control parameters, at least one of the control parameters being modifiable by user interaction with a parameter control element, and the mobile medication device not allowing modification of the at least one control parameter via the parameter control element when the mobile medication device is in a locked state;
receiving a request from the computing system via a direct end-to-end connection with the computing system to unlock the ambulatory medication device, the request including a security code;
verifying the security code to confirm that the user is authorized to change the lock status of the ambulatory medication device by verifying that the security code matches the user-generated passcode or the override passcode;
A mobile medication device comprising: a hardware processor configured to execute certain computer-executable instructions that, in response to verifying a security code, cause the mobile medication device to enter an unlocked state, and enable the mobile medication device to modify at least one control parameter via a parameter control element when the mobile medication device is in the unlocked state.
19. The ambulatory medication device according to embodiment 18, wherein the ambulatory medication device comprises an insulin pump or a bihormonal pump capable of administering insulin and a counterregulatory agent.
20. The ambulatory medication device according to embodiment 18, wherein the parameter control element is accessed via a computing system via a direct end-to-end connection.
21. The ambulatory medication device according to embodiment 18, wherein the direct end-to-end connection is established via a wide area network.
22. The ambulatory medication device according to embodiment 18, wherein access to at least some functions of the user interface is permitted without verifying a security code.
23. The ambulatory medication device of embodiment 18, 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.
24. The ambulatory medication device of embodiment 18, wherein the override passcode changes at periodic intervals.
25. The ambulatory medication device according to embodiment 18, wherein the override passcode is fixed during the manufacturing process.
26. The ambulatory medication device of embodiment 18, wherein the override passcode is valid for at least some other ambulatory medication devices.
27. The ambulatory medication device of embodiment 18, wherein a new override passcode is algorithmically generated upon expiration of the override passcode.

Further embodiments of the present disclosure can be described in view of the following numbered embodiments:
1. A mobile medical device configured to provide a treatment to a patient and share treatment-related treatment data with a networked computing environment, comprising:
a memory configured to store specific computer-executable instructions;
communicate with the memory and, at a minimum,
identifying computing systems in the networked computing environment based on a whitelist of one or more approved computing systems, the whitelist stored in a memory of the mobile medical device;
Obtain the address of the computing system from the whitelist,
using the address to establish a direct end-to-end data connection to a computing system of the networked computing environment over a wireless wide area network;
receiving a public key from a computing system of the networked computing environment, the public key enabling the mobile medical device to encrypt data communications transmitted by the mobile medical device to the computing system;
encrypting treatment data associated with a treatment delivered to the patient by the mobile medical device to obtain encrypted treatment data;
A mobile medical device comprising: a hardware processor configured to execute specific computer-executable instructions to transmit encrypted treatment data to a computing system via a direct end-to-end data connection.
2. The mobile medical device of embodiment 1, wherein the address of the computing system comprises a network address of the computing system.
3. The mobile medical device of embodiment 2, wherein the network address comprises an Internet Protocol (IP) address, a uniform resource locator (URL), a uniform resource identifier (URI), or a uniform resource name (URN).
4. The mobile medical device of embodiment 1, wherein the address of the computing system comprises a network address of a networked computing environment that includes the computing system.
5. The mobile medical device of embodiment 1, wherein the whitelist includes access information usable by the mobile medical device to access the computing system.
6. The mobile medical device of embodiment 1, wherein the whitelist is stored in a memory of the mobile medical device during manufacture of the mobile medical device.
7. The mobile medical device of embodiment 1, further comprising a transceiver configured to communicate over a wireless wide area network using the address.
8. The mobile medical device of embodiment 7, wherein the transceiver is configured to support communication via one or more communication standards including 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 Communications (LTE-MTC) standard.
9. The mobile medical device of embodiment 1, wherein the hardware processor is further configured to establish a direct end-to-end data connection to a computing system of the networked computing environment by sending a connection request to the computing system, the connection request including a device identifier of the mobile medical device.
10. The mobile medical device of embodiment 9, wherein the device identifier includes 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 patient identifier.
11. The mobile medical device of embodiment 1, wherein the hardware processor is further configured to execute certain computer-executable instructions to at least generate a shared secret key based at least in part on the public and private keys stored on the mobile medical device, and wherein encrypting the therapy data includes encrypting the therapy data using the shared secret key.
12. A hardware processor executes specific computer-executable instructions to perform at least the following:
acquiring additional treatment data related to a treatment delivered to the patient by the mobile medical device, the additional treatment data being acquired at a different time period than the treatment data;
encrypting the additional treatment data to obtain the additional encrypted treatment data;
10. The mobile medical device of embodiment 1, further configured to transmit additional encrypted treatment data to a computing system via a direct end-to-end data connection.
13. The ambulatory medical device of embodiment 12, wherein the additional therapy data is acquired intermittently, periodically, periodically, or continuously over at least some period of time.
14. A hardware processor executes specific computer-executable instructions to perform at least the following:
10. The mobile medical device of embodiment 1, further configured to: receive an alert from a computing system of the networked computing environment; and output an indication of the alert on a display of the mobile medical device.
15. The mobile medical device of embodiment 14, wherein the alert is received in response to encrypted treatment data being transmitted to the computing system.
16. The mobile medical device of embodiment 14, wherein the alert is generated based on physiological measurements of the patient obtained from one or more sensors of the mobile medical device.
17. The mobile medical device of embodiment 1, further comprising a glucose level sensor operably connected to the patient and configured to acquire a glucose level signal, wherein the hardware processor is further configured to execute certain computer-executable instructions to at least determine a glucose level of the patient based at least in part on the glucose level signal.
18. The mobile medical device of embodiment 17, wherein the treatment data includes a glucose level of the patient.
19. The mobile medical device of embodiment 1, wherein the treatment data includes at least one of dosage data or patient data, wherein the dosage data corresponds to one or more doses of a medication provided to the patient by the mobile medical device, and the patient data corresponds to a medical or physiological condition of the patient as determined by the mobile medical device.
20. The mobile medical device of embodiment 1, wherein the hardware processor is further configured to execute specific computer-executable instructions to transmit at least status information of the mobile medical device to the computing system.
21. The mobile medical device of embodiment 20, wherein the status information includes one or more of operational data or error data, the operational data corresponding to an operation of the mobile medical device, and the error data corresponding to an error in the operation of the mobile medical device.
22. The ambulatory medical device of embodiment 1, further comprising a monohormonal drug pump, a bihormonal drug pump, or a pacemaker.
23. A hardware processor executes specific computer-executable instructions to perform at least the following:
10. The mobile medical device of embodiment 1, configured to receive an account identifier associated with a user authorized to access data associated with a patient in a networked computing environment; and transmit the account identifier to a computing system.
24. The mobile medical device of embodiment 23, wherein the hardware processor is further configured to execute certain computer-executable instructions to transmit a set of permissions associated with at least the account identifier, the set of permissions authorizing the user to access data associated with the patient in the networked computing environment.
25. A computer-implemented method for sharing treatment data related to treatment provided to a patient by a mobile medical device in a networked computing environment, comprising:
The hardware processor in the mobile medical device
obtaining network addresses of computing systems of the networked computing environment based on a whitelist of one or more approved computing systems, the whitelist being stored in a memory of the mobile medical device;
establishing a direct end-to-end data connection to a computing system of the networked computing environment over a wireless wide area network using the network address;
receiving a public key from a computing system in the networked computing environment;
accessing a private key stored in a memory of the mobile medical device;
generating a shared secret based at least in part on the public key and the private key;
encrypting treatment data related to a treatment delivered to the patient by the mobile medical device using the shared secret to obtain encrypted treatment data;
transmitting the encrypted treatment data to a computing system via a direct end-to-end data connection.
26. The computer-implemented method of embodiment 25, wherein the whitelist is stored in a memory of the mobile medical device or a memory of a trusted computing device accessible by the mobile medical device.
27. The computer-implemented method of embodiment 25, wherein establishing the direct end-to-end data connection includes communicating with the computing system over a wireless wide area network using one or more communications standards including a Low Power Wide Area Network (LPWAN) communications standard, a Narrowband Long Term Evolution (NB-LTE) standard, a Narrowband Internet of Things (NB-IoT) standard, or a Long Term Evolution Machine Type Communications (LTE-MTC) standard.
28. The computer-implemented method of embodiment 25, wherein the treatment data is acquired over a specific period of time, and the encrypted treatment data acquired and generated by encrypting the treatment data is transmitted after the specific period of time.
29. The computer-implemented method of embodiment 25, further comprising:
acquiring additional therapy data intermittently, periodically, periodically, or continuously over at least one period of time;
encrypting the additional therapy data using the shared secret to obtain additional encrypted therapy data;
transmitting the additional encrypted treatment data to the computing system via a direct end-to-end data connection.
30. The computer-implemented method of embodiment 25, further comprising:
receiving an alert from a computing system of the networked computing environment at least in part in response to the encrypted treatment data transmitted to the computing system;
and outputting an indication of the warning on a display.

Further embodiments of the present disclosure can be described in view of the following numbered embodiments:
1. An ambulatory medication device configured to generate a dose control signal for delivery of a medication to a patient and to cancel a user-initiated change in medication delivery, comprising:
a drug delivery interface configured to operably connect to a drug pump configured to infuse a drug into a patient in response to receiving a dose control signal;
a touch screen controller configured to output display signals configured to generate a user interface screen on the touch screen and to receive user input signals corresponding to user interactions with the touch screen;
a memory configured to store specific computer-executable instructions;
communicate with the memory and, at a minimum,
generating a display of a therapy control element on the touch screen, the therapy control element allowing a user to change control parameters having a first setting used in a control algorithm to generate the dosage control signal;
receiving instructions for modifications to treatment control elements;
In response to receiving the instruction, modifying the control parameter from a first setting to a second setting at a first time based on the instruction to modify the therapy control element;
receiving a restore gesture on the touch screen at a second time, the restore gesture indicating that the control parameter should be restored to the first setting, the restore gesture including a swipe gesture performed by the user;
a hardware processor configured to execute specific computer-executable instructions to restore a control parameter to a first setting in response to receiving a restore gesture.
2. The ambulatory medication device of embodiment 1, wherein the swipe gesture is performed at least partially within an area of the touch screen occupied by the therapy control element.
3. The ambulatory medication device of embodiment 1, wherein the swipe gesture is performed from a start swipe position to an end swipe position that is located closer to the left edge of the touch screen than the start swipe position.
4. The ambulatory medication device of embodiment 1, wherein the restore gesture is received on a user interface screen presenting the therapy control element.
5. The ambulatory medication device of embodiment 1, wherein the restore gesture is received on a user interface screen different from the user interface screen presenting the therapy control element.
6. The ambulatory medication device of embodiment 1, wherein the restore gesture is performed in an opposite direction to the therapy change confirmation gesture that confirms a modification to the therapy control element.
7. The ambulatory medication device of embodiment 1, wherein the second time is later than the first time.
8. The ambulatory medication device of embodiment 1, wherein the second time is after one or more dose control signals are provided to the medication pump.
9. A hardware processor executes specific computer-executable instructions to perform at least the following:
receiving a second instruction of a second modification to the therapy control element;
10. The ambulatory medication device of embodiment 1, further configured to, in response to receiving a second instruction, change the control parameter from the second setting to a third setting at a third time point based on the second instruction of a second change to the therapy control element.
10. The ambulatory medication device of embodiment 9, wherein the third time is after the first time but before the second time.
11. The ambulatory medication device of embodiment 9, wherein the first settings comprise default settings or designated recovery settings.
12. The ambulatory medication device of embodiment 1, wherein the first setting comprises a setting immediately preceding the second setting.
13. The ambulatory medication device of embodiment 1, wherein the first settings include default settings or designated recovery settings.
14. A computer-implemented method for canceling a user-initiated change in a control parameter associated with drug delivery, comprising:
a hardware processor configured to generate a dose control signal for delivery of a drug by a drug pump to a patient;
generating a display of a therapy control element on a touch screen configured to display one or more user interface screens, the therapy control element allowing a user to change control parameters having first settings used in a control algorithm to generate a dosage control signal;
receiving instructions for modifications to a therapy control element;
In response to receiving the instruction, changing the control parameter from a first setting to a second setting at a first time based at least in part on the instruction to change to the therapy control element;
receiving a restore gesture on the touch screen at a second time, the restore gesture indicating that the control parameter should be restored to the first setting, the restore gesture comprising a swipe gesture performed by the user;
Restoring the control parameter to the first setting in response to receiving the restore gesture;
11. A computer-implemented method comprising:
15. The computer-implemented method of embodiment 14, wherein the swipe gesture is performed at least partially within an area of the touch screen 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 that is located closer to the left edge of the touch screen than the starting swipe position.
17. The computer-implemented method of embodiment 14, wherein the restore gesture is received on a user interface screen presenting the therapy control element.
18. The computer-implemented method of embodiment 14, wherein the restore gesture is received on a user interface screen different from the user interface screen presenting the therapy control element.
19. The computer-implemented method of embodiment 14, wherein the restore gesture is performed in the opposite direction to the 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.
21. The computer-implemented method of embodiment 14, wherein the second time is after one or more dose control signals are provided to the drug pump.
22. The computer-implemented method of embodiment 14, further comprising:
receiving a second instruction of a second modification to the therapy control element;
and in response to receiving the second instruction, changing the control parameter from the second setting to a third setting at a third time based on the second instruction of a second change to the therapy control element.
23. The computer-implemented method of embodiment 22, wherein the third time occurs at a point in time between the first time and the second time.
24. The computer-implemented method of embodiment 22, wherein the first settings comprise default settings or specified restore settings.
25. The computer-implemented method of embodiment 14, wherein the first setting comprises a setting that immediately precedes the second setting.
26. The computer-implemented method of embodiment 14, wherein the first settings comprise default settings or specified restore settings.

Further embodiments of the present disclosure can be described in view of the following numbered embodiments:
1. A computer-implemented method for switching between applications running on a mobile medical device without interrupting care provided to a patient by the mobile medical device, comprising:
The hardware processor in the mobile medical device
receiving an indication that an application update is available, the application update including an update to a first application running on the mobile medical device;
establishing a communications connection to a host computing system configured to host the application update;
downloading a second application from a host computing system, the second application being a version of the first application that includes an application update;
installing a second application on the mobile medical device while keeping the first application running;
confirming successful installation of the second application on the mobile medical device;
receiving a trigger to execute a second application in place of the first application;
determining a next treatment delivery time associated with delivering treatment to the patient by the ambulatory medical device in response to the trigger;
and in response to determining that the amount of time until the next therapy delivery time meets the threshold time, switching application control by commencing execution of the second application and stopping execution of the first application.
Computer-implemented methods.
2. The computer-implemented method of embodiment 1, wherein the communication connection is established via a cellular network that allows the mobile medical device to communicate directly with the host computing system via the cellular network.
3. The computer-implemented method of embodiment 1, wherein the application update comprises a new version of the application, a patch to the application, or a replacement application for the application.
4. The computer-implemented method of embodiment 1, wherein installing the second application includes installing the second application in a separate memory space of non-volatile memory separate from the installation of the first application.
5. A computer-implemented method as recited in embodiment 1, wherein in response to determining that the amount of time until the next therapy delivery time meets the threshold time, the computer-implemented method further includes switching control of at least one function of the ambulatory medical device from the first application to the second application.
6. The computer-implemented method of embodiment 5, wherein at least one feature comprises a controller configured to control a therapy delivered to the patient.
7. The computer-implemented method of embodiment 1, further comprising: accessing an update server to determine whether an application update exists; and receiving, in response to accessing the update server, an indication that an application update is available.
8. The computer-implemented method of embodiment 1, wherein the indication that an application update is available is received automatically without any action by the mobile medical device.
9. The computer-implemented method of embodiment 1, wherein the first application executes in a first execution space, and wherein initiating execution of the second application includes executing the second application in a second execution space separate from the first execution space.
10. A computer-implemented method as recited in embodiment 9, wherein the first execution space and the second execution space comprise separate regions of volatile memory.
11. A computer-implemented method as recited in embodiment 1, wherein the first application is executed by a first controller and the second application is executed by a second controller.
12. The computer-implemented method of embodiment 1, wherein the next treatment delivery time is determined based at least in part on a treatment delivery schedule stored on the mobile medical device.
13. The computer-implemented method of embodiment 1, further comprising determining a patient status based at least in part on measurements of a physiological parameter of the patient, wherein the next therapy delivery time is determined based at least in part on the patient status.
14. The computer-implemented method of embodiment 1, wherein the trigger includes confirmation of successful installation of the second application or detection of a failure during execution of the first application.
15. The computer-implemented method of embodiment 1, wherein the first application comprises one of 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, and downloading the second application comprises downloading one of 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.
16. The computer-implemented method of embodiment 15, wherein the first feature set comprises a subset of the second feature set or a feature set that partially overlaps with the second feature set.
17. The computer-implemented method of embodiment 1, wherein the ambulatory medical device comprises a monohormonal drug pump or a bihormonal drug pump.
18. A computer-implemented method for maintaining therapy provided to a patient by a mobile medical device during an application failure of an application running on the mobile medical device, comprising:
The hardware processor in the mobile medical device
Detecting an application failure associated with a first application executing on the mobile medical device, the first application configured to control a therapy provided by the mobile medical device;
In response to detecting an application failure,
commencing execution of a second application on the mobile medical device, the second application configured to control a therapy provided by the mobile medical device, the second application comprising an older version of the first application;
switching control of the mobile medical device from the first application to the second application;
11. A computer-implemented method comprising:
19. The computer-implemented method of embodiment 18, further comprising sending an indication of the application failure to a computing device of a manufacturer or maintenance service of the mobile medical device.
20. The computer-implemented method of embodiment 18, further comprising alerting a user to the occurrence of an application failure.
21. The computer-implemented method of embodiment 18, further comprising:
receiving an indication that a third application is available, the third application being configured to control therapy provided by the mobile medical device;
establishing a direct end-to-end data connection to a host computing system configured to host a third application, the direct end-to-end data connection being established over a wireless wide area network;
downloading the third application from the host computing system via a direct end-to-end data connection to obtain a downloaded copy of the third application;
initiating an installation process of the downloaded copy of the third application without interrupting the treatment provided to the patient by the mobile medical device;
and switching control of the mobile medical device from the second application to a third application.
22. The computer-implemented method of embodiment 21, wherein the third application includes an update to the first application that addresses the application failure.
23. The computer-implemented method of embodiment 18, wherein the second application is stored in a portion of the memory of the mobile medical device designated to store a secure copy of a control application that controls the mobile medical device.
24. A computer-implemented method for switching control applications that control a mobile medical device without interrupting treatment provided to a patient by the mobile medical device, comprising:
The hardware processor in the mobile medical device
Detecting a trigger associated with a first application running on the mobile medical device, the first application being a control application configured to control a therapy provided by the mobile medical device;
In response to detecting the trigger,
commencing execution of a second application on the mobile medical device, the second application configured to control therapy provided by the mobile medical device, the second application including a different version of a control application than the first application;
switching control of the mobile medical device from the first application to the second application;
11. A computer-implemented method comprising:
25. The computer-implemented method of embodiment 24, wherein the trigger comprises an indication of availability of the second application or detection of an application failure associated with execution of the first application.
26. The computer-implemented method of embodiment 24, wherein the second application comprises an older version of the first application.
27. A mobile medical device configured to provide therapy to a patient and capable of switching control applications without interrupting therapy, comprising:
a memory configured to store specific computer-executable instructions; and a first application configured to at least partially control a therapy provided to a patient;
communicate with the memory and, at a minimum,
Executing a first application to at least partially control the therapy provided to the patient;
Detecting a trigger associated with the first application;
In response to detecting the trigger, the hardware processor performs at least
accessing a second application configured to at least partially control the treatment provided to the patient;
commencing execution of a second application while maintaining execution of the first application on the mobile medical device;
determining a next treatment delivery time associated with delivering treatment to the patient;
a hardware processor configured to execute specific computer-executable instructions to switch control of the therapy from a first application to a second application and stop execution of the first application in response to determining that the amount of time until the next therapy delivery time meets a threshold time;
A mobile medical device comprising:
28. The mobile medical device of embodiment 27, wherein the trigger comprises an indication of availability of the second application on the host computing system or detection of an application failure associated with execution of the first application.
29. The hardware processor includes at least:
establishing an end-to-end data connection over a network to a host computing system configured to host a second application;
downloading a second application into memory;
Verify the successful download of the second application,
28. The mobile medical device of embodiment 27, further configured to access the second application by executing specific computer-executable instructions for performing: installing the second application.
30. The mobile medical device of embodiment 27, wherein 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 impairment with a threshold degree of certainty.

Further embodiments of the present disclosure can be described in view of the following numbered embodiments:
1. A computer-implemented method for updating an application executing on a mobile medical device without interrupting care provided to a patient by the mobile medical device, comprising:
The hardware processor in the mobile medical device
receiving an indication that an application update is available, the application update including an update to a first application running on the mobile medical device;
establishing a communications connection to a host computing system configured to host a second application that includes 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 the treatment provided to the patient by the mobile medical device;
executing a second application while continuing to execute the first application;
determining that a minimum set of operating conditions is met, the minimum set of operating conditions relating to maintaining therapy provided to the patient by the mobile medical device;
responsive to determining that a minimum set of operating conditions is met, switching control of the ambulatory medical device from the first application to the second application;
12. A computer-implemented method comprising:
2. The computer-implemented method of embodiment 1, wherein determining that a minimum set of operating conditions is met includes determining that the mobile medical device is not currently administering a medication.
3. The computer-implemented method of embodiment 1, wherein determining that a minimum set of operating conditions is met includes determining that the mobile medical device has less than a threshold probability of administering the medication within a threshold time period.
4. The computer-implemented method of embodiment 1, wherein determining that a minimum set of operating conditions is met includes determining that the mobile medical device administered the medication within a threshold period of time.
5. The computer-implemented method of embodiment 1, wherein the installation process includes installing the second application in a memory space of the memory of the mobile medical device that is separate from the location of the first application in the memory.
6. Switching control of the mobile medical device from a first application to a second application comprises:
generating a dose control signal using a second application, the second application autonomously determining a dose of a medication to be infused into the patient to control the patient's blood glucose based at least in part on the glucose level signal obtained from the sensor;
and providing a dose control signal generated using the second application to a drug delivery interface configured to operably connect to a drug pump for infusing the drug into the patient without providing a second dose control signal generated using the first application.
7. The computer-implemented method of embodiment 1, wherein the communication connection is established via a cellular network that allows the mobile medical device to communicate directly with the host computing system via the cellular network.
8. The computer-implemented method of embodiment 1, wherein the communication connection comprises a Narrowband Long Term Evolution (NB-LTE) connection, a NB Internet of Things (NB-IoT) connection, a cellular IoT connection, a 4G LTE connection, or a 5G connection.
9. The computer-implemented method of embodiment 1, wherein the communication connection comprises a direct end-to-end wireless connection over a wide area network (WAN).
10. 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 functionality of the first application.
11. A computer-implemented method as recited in embodiment 1, wherein executing a second application while the first application continues to run comprises executing the second application using a processor separate from the processor executing the first application.
12. A computer-implemented method as recited in embodiment 1, wherein executing a second application while the first application continues to run includes executing the second application in an execution space separate from the execution space used to run the first application.
13. A computer-implemented method as recited in 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 1, wherein the first application comprises one of 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, and downloading the second application comprises downloading one of 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.
15. The computer-implemented method of embodiment 14, wherein the first feature set and the second feature set are different, and the first feature set includes at least one feature included in the second feature set.
16. The computer-implemented method of embodiment 1, wherein the ambulatory medical device comprises a monohormonal drug pump or a bihormonal drug pump.
17. A mobile medical device configured to provide therapy to a patient and capable of switching control applications without interrupting therapy, comprising:
a memory configured to store specific computer-executable instructions; and a first application configured to at least partially control a therapy provided to a patient;
communicate with the memory and, at a minimum,
Executing a first application to at least partially control the therapy provided to the patient;
establishing a communications connection to a host computing system configured to host a second application that, when executed by the hardware processor, is configured to at least partially control a therapy provided to the patient;
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 the treatment provided to the patient by the mobile medical device;
Executing the second application without modifying the execution of the first application;
determining that a minimum set of operating conditions related to maintaining treatment provided to the patient by the mobile medical device are met;
a hardware processor configured to execute specific computer-executable instructions to switch control of the mobile medical device from the first application to the second application in response to determining that a minimum set of operating conditions is met;
Mobile medical equipment.
18. The ambulatory medical device of embodiment 17, wherein the hardware processor establishes the communication connection in response to a trigger.
19. The mobile medical device of embodiment 18, wherein the trigger includes one or more of an indication that the second application is available, a detection of a failure of the first application, or an indication of a change in allowed functionality.
20. The mobile medical device of embodiment 17, wherein the hardware processor is configured to determine that the minimum set of operating conditions is met by at least determining that the mobile medical device is not currently administering a medication.
21. The ambulatory medical device of embodiment 17, wherein the hardware processor is configured to determine that the minimum set of operating conditions is met by determining that the probability of administering the medication within at least a particular time period is less than or equal to a threshold.
22. The mobile medical device of embodiment 17, wherein the hardware processor is configured to determine that a minimum set of operating conditions is met by determining that at least the mobile medical device has delivered the medication within a specified time period.
23. A hardware processor having at least:
generating a dose control signal using a second application, the second application autonomously determining a dose of a medication to be infused into the patient to control the patient's blood glucose based at least in part on the glucose level signal obtained from the sensor;
and providing a dose control signal generated using the second application to a drug delivery interface configured to operatively connect to a drug pump for infusing the drug into a patient without providing a second dose control signal generated using the first application, thereby switching control of the ambulatory medical device from the first application to the second application.
18. A mobile medical device according to embodiment 17.
24. The mobile medical device of embodiment 17, further comprising a transceiver configured to establish a communications connection with a host computing system over a wide area network.
25. The ambulatory medical device of embodiment 17, further comprising a first drug pump configured to administer a first drug to a patient in response to a first control signal generated by execution of the first application or the second application.
26. The ambulatory medical device of embodiment 25, wherein the first drug pump comprises a monohormonal drug pump or a bihormonal drug pump.
27. The ambulatory medical device of embodiment 25, further comprising a second drug pump configured to administer a second drug to the patient in response to a second control signal generated by execution of the first application or the second application.

Further embodiments of the present disclosure can be described in view of the following numbered embodiments:
1. An ambulatory medication device configured to generate a dose control signal for delivery of a medication to a patient, comprising:
a monitoring system interface configured to receive status information, the status information including at least one of device information regarding a status of the ambulatory medication device or patient information regarding a status of the patient;
a drug delivery interface configured to operably connect to a drug pump configured to infuse a drug into a patient in response to receiving a dose control signal;
a touch screen controller configured to output display signals configured to generate a user interface screen on the touch screen and to receive user input signals corresponding to user interactions with the touch screen;
a memory configured to store specific computer-executable instructions;
communicate with the memory and, at a minimum,
receiving status information via a monitoring system interface;
determining that the status information satisfies an alert condition for the ambulatory medication device or the patient;
In response to a wake interaction with the wake interface element when the mobile medication device is in a sleep state, the touch screen controller does not receive user input signals when the mobile medication device is in a sleep state and generates a display of a touch screen lock screen interface;
a hardware processor configured to execute specific computer-executable instructions to display, on a touchscreen lock screen interface, one or more alarm status indicators corresponding to the alarm condition; and
1. An ambulatory medication device comprising:
2. The mobile medication device of embodiment 1, wherein in response to an unlock gesture interaction with the touch screen lock screen interface, the hardware processor is further configured to execute certain computer-executable instructions to enable access to at least a therapy control element of the mobile medication device, wherein the therapy control element allows a user to modify control parameters used in a control algorithm to generate the dose control signal.
3. A hardware processor executes specific computer-executable instructions to perform at least the following:
receiving instructions for modifications to the therapy control element; and in response to receiving the instructions,
modifying the control parameters based on the instructions to obtain modified control parameters;
generating a dosage control signal based at least in part on the altered control parameter;
3. The ambulatory medication device of embodiment 2, configured to provide a dose control signal to the medication pump via the medication delivery interface.
4. The ambulatory medication device of embodiment 1, wherein the wake interface element comprises a motion sensor and the wake interaction comprises motion of the ambulatory medication device.
5. The ambulatory medication device of embodiment 4, wherein the motion sensor comprises an accelerometer.
6. The ambulatory medication device according to embodiment 4, wherein the movement of the ambulatory medication device corresponds to a specific movement.
7. The ambulatory medication device of embodiment 6, wherein the particular movement indicates that the user is moving the ambulatory medication device within the user's visual range.
8. The ambulatory medication device according to embodiment 1, wherein the wake interface element comprises a physical button, a capacitive element, or an inductive element.
9. The ambulatory medication device of embodiment 1, wherein the wake interaction further comprises receiving a biometric input.
10. A hardware processor executes specific computer-executable instructions to perform at least the following:
determining a severity level of the alarm condition;
and further configured to select one or more alarm condition indicators to display on the touch screen lock screen interface based at least in part on a severity level of the alarm condition.
2. The ambulatory medication device of embodiment 1.
11. The ambulatory medication device of embodiment 1, wherein the ambulatory medication device comprises an insulin pump.
12. The ambulatory medication device of embodiment 1, wherein the ambulatory medication device comprises a bi-hormonal pump capable of administering insulin and a counter-regulatory agent.
13. One or more alarm status indicators may include text information corresponding to the alarm condition;
10. The ambulatory medication device of embodiment 1, comprising at least one of an audible alarm, a visual alarm, or a tactile alarm.
14. A hardware processor executes specific computer-executable instructions to perform at least the following:
receiving additional status information via a monitoring system interface;
determining that the additional status information satisfies an alert condition for the ambulatory medication device or the patient;
and further configured to modify the display of the one or more alarm condition indicators based on additional status information that satisfies a pre-alarm condition.
2. The ambulatory medication device of embodiment 1.
15. A hardware processor executes specific computer-executable instructions to perform at least the following:
receiving additional status information at a time subsequent to receiving the status information via the monitoring system interface;
determining that the additional status information does not meet an alarm condition for the ambulatory medication device or the patient;
and further configured to stop displaying, on the touch screen, lock screen, or interface, one or more alarm status indicators corresponding to the alarm condition.
2. The ambulatory medication device of embodiment 1.
16. The ambulatory medication device of embodiment 15, wherein the hardware processor is further configured to determine that the additional status information does not satisfy the alarm condition by determining that the additional status information indicates clearance of the alarm condition.
17. The ambulatory medication device of embodiment 1, wherein the status information is received from a sensor that measures at least one of a characteristic of the ambulatory medication device or a physiological parameter of the patient.
18. A hardware processor executes specific computer-executable instructions to perform at least the following:
receiving additional status information via a monitoring system interface;
determining that the additional status information satisfies a second alarm condition for the ambulatory medication device or the patient;
and further configured to display, on the touch screen lock screen interface, an additional alarm status indicator corresponding to the second alarm condition.
2. The ambulatory medication device of embodiment 1.
19. A hardware processor executes specific computer-executable instructions to perform at least the following:
receiving additional status information via a monitoring system interface;
determining that the additional status information satisfies a second alarm condition for the ambulatory medication device or the patient;
and further configured to modify the display of the one or more alarm condition indicators based on additional condition information that satisfies a second alarm condition.
2. The ambulatory medication device of embodiment 1.
20. A computer-implemented method for displaying an alarm status indicator corresponding to an alarm condition in a patient or ambulatory medication device configured to generate a dose control signal configured to cause a medication pump to infuse a medication into a patient, comprising:
a hardware processor configured to generate a dose control signal configured to cause a drug pump to infuse a drug into a patient;
receiving status information including at least one of device information regarding the status of the ambulatory medication device or patient information regarding the status of the patient;
determining that the status information satisfies an alert condition for the ambulatory medication device or the patient;
receiving an indication of a wake interaction with a wake interface element of the mobile medication device when the mobile medication device is in a sleep state;
in response to a wake interaction with the wake interface element;
generating a touch screen/lock screen/interface display;
and displaying an alarm status indicator on a touch screen lock screen interface corresponding to the alarm condition, the alarm status indicator being displayed at least while the ambulatory medication device remains in the locked state.
21. The computer-implemented method of embodiment 20, wherein the touch screen controller of the ambulatory medication device does not receive user input signals when the ambulatory medication device is in a sleep state.
22. The computer-implemented method of embodiment 20, wherein in response to receiving an unlock gesture interaction with the touch screen lock screen interface, the computer-implemented method further comprises granting access to a therapy control element of the ambulatory medication device, the therapy control element allowing a user to modify control parameters used in a control algorithm to generate the dose control signal.
23. The computer-implemented method of embodiment 22, further comprising:
receiving instructions for modifications to a therapy control element;
In response to receiving the instruction,
modifying the control parameters based on the instructions to obtain modified control parameters;
generating a dosage control signal based at least in part on the altered control parameter;
and providing a dose control signal to the drug pump.
24. The computer-implemented method of embodiment 20, wherein the wake interaction comprises movement of the mobile medication device in a particular motion indicative of the user moving the mobile medication device within the user's line of sight.
25. The computer-implemented method of embodiment 20, further comprising:
determining a severity level of the alarm condition;
selecting an alarm status indicator for display on the touch screen lock screen interface based at least in part on the severity level of the alarm condition;
21. The computer-implemented method of embodiment 20.
26. The computer-implemented method of embodiment 20, further comprising:
receiving additional state information;
determining that the additional status information satisfies an alert condition for the ambulatory medication device or the patient;
and modifying the display of the alarm status indicator based on additional status information that satisfies an alarm condition.
21. The computer-implemented method of embodiment 20.
27. The computer-implemented method of embodiment 20, further comprising:
receiving additional state information at a time subsequent to the time the state information was received;
determining that the additional status information does not meet an alarm condition for the ambulatory medication device or the patient;
ceasing to display on the touch screen lock screen interface an alarm status indicator corresponding to the alarm condition.
28. The computer-implemented method of embodiment 27, wherein determining that the additional state information does not satisfy the alarm condition comprises determining that the alarm condition is resolved based at least in part on the additional state information.
29. The computer-implemented method of embodiment 20, further comprising:
receiving additional state information;
determining that the additional status information satisfies a second alarm condition for the ambulatory medication device or the patient;
21. The computer-implemented method of embodiment 20, further comprising: displaying an additional alarm status indicator on the touch screen lock screen interface corresponding to the second alarm condition.
30. The computer-implemented method of embodiment 20, further comprising:
receiving additional state information;
determining that the additional status information satisfies a second alarm condition for the ambulatory medication device or the patient;
and modifying the display of the alarm status indicator based on additional status information that satisfies a second alarm condition.

Further embodiments of the present disclosure can be described in view of the following numbered embodiments:
1. An ambulatory medication device configured to generate a dose control signal configured to cause a medication pump to infuse a medication into a patient, comprising:
a monitoring system interface configured to receive status information, the status information including at least one of device information regarding a status of the ambulatory medication device or patient information regarding a status of the patient;
a memory configured to store specific computer-executable instructions and a list of pending alarm conditions;
communicate with the memory and, at a minimum,
receiving first status information via a monitoring system interface;
modifying the list of pending alarm conditions based on the alarm condition in response to determining that the first status information satisfies an alarm condition for the ambulatory medication device or the patient and determining that the alarm condition does not already exist in the list of pending alarm conditions;
determining a severity level of the alarm condition, the severity level being one of a plurality of severity levels;
further configured to notify the alarm condition using one or more notification patterns, the one or more notification patterns being selected based on a severity level of the alarm condition for the ambulatory medication device or the patient;
a hardware processor configured to execute specific computer-executable instructions to maintain an indication of the alarm condition in a list of pending alarm conditions until the alarm condition is resolved;
1. An ambulatory medication device comprising:
2. The ambulatory medication device of embodiment 1, wherein the ambulatory medication device comprises an insulin pump.
3. The ambulatory medication device according to embodiment 1, comprising a bi-hormonal pump capable of administering insulin and a counter-regulatory agent.
4. The ambulatory medication device of embodiment 1, wherein one or more notification patterns are selected from a plurality of notification patterns, and at least one severity level among the plurality of severity levels is associated with a unique notification pattern among the plurality of notification patterns.
5. The ambulatory medication device of embodiment 1, wherein the list of pending alarm conditions is sorted according to the severity levels of the alarm conditions included in the list of pending alarm conditions.
6. The ambulatory medication device of embodiment 1, wherein the list of pending alarm conditions is displayed on a user interface of the ambulatory medication device.
7. The ambulatory medication device of embodiment 6, wherein the list of pending alarm conditions is available when the ambulatory medication device is in a locked state.
8. The ambulatory medication device of embodiment 1, further comprising a wireless electronic communication interface configured to communicate with a remote electronic device, wherein the hardware processor is further configured to execute certain computer-executable instructions to transmit an alarm signal to the remote electronic device via at least the wireless electronic communication interface, enabling the remote electronic device to announce the alarm condition.
9. The ambulatory medication device of embodiment 8, wherein the hardware processor is further configured to execute certain computer-executable instructions to transmit at least a list of pending alarm conditions to a remote electronic device via a wireless electronic communication interface.
10. The ambulatory medication device of embodiment 1, wherein the hardware processor is further configured to execute certain computer-executable instructions to generate at least a display of an alarm status icon including a visual indication of the number of alarm conditions on the list of pending alarm conditions.
11. A hardware processor executes specific computer-executable instructions to perform at least the following:
receiving second status information via the monitoring system interface;
The ambulatory medication device of embodiment 1, further configured to modify one or more notification patterns used to notify the alarm condition in response to determining that the second status information meets an alarm condition for the ambulatory medication device or the patient and determining that an indication of the alarm condition is already present in a list of pending alarm conditions.
12. The ambulatory medication device of embodiment 1, wherein the first status information is received from a sensor that measures at least one of a characteristic of the ambulatory medication device or a health-related characteristic of the patient.
13. The ambulatory medication device of embodiment 1, wherein in response to determining that the first status information satisfies an alert condition for the ambulatory medication device or the patient, the hardware processor is further configured to execute certain computer-executable instructions to at least contact at least one of a healthcare provider or a manufacturer of the ambulatory medication device.
14. The ambulatory medication device of embodiment 1, wherein if the first status information indicates that the amount of available medication is less than or equal to a quantity threshold, the hardware processor is further configured to execute certain computer-executable instructions to at least order additional medication without user intervention.
15. The ambulatory medication device of embodiment 1, wherein in response to determining that the first status information satisfies an alarm condition for the ambulatory medication device, the hardware processor is further configured to execute certain computer-executable instructions to cause at least repair instructions to be output for display on a user interface.
16. The ambulatory medication device of embodiment 1, wherein the one or more alert patterns include at least one of text information corresponding to an alarm condition, an audible alarm, a visual alarm, or a tactile alarm.
17. In response to determining that the first status information satisfies an alarm condition and determining that an indication of the alarm condition exists in the list of pending alarm conditions, the hardware processor executes certain computer-executable instructions to at least:
modifying a severity level of the alarm condition from a first severity level of the plurality of severity levels to a second severity level of the plurality of severity levels;
10. The ambulatory medication device of embodiment 1, further configured to modify one or more notification patterns of the alarm condition based on the severity of the alarm condition.
18. The ambulatory medication device of embodiment 1, wherein in response to determining that the severity level of the alarm condition matches the unsafe operation severity level, the hardware processor is further configured to execute certain computer-executable instructions to suspend delivery of at least the medication to the patient.
19. The ambulatory medication device of embodiment 1, wherein in response to determining that the severity level of the alarm condition matches the safe operating severity level, the hardware processor is further configured to execute certain computer-executable instructions to maintain at least delivery of the medication to the patient.
20. The ambulatory medication device of embodiment 1, wherein at least one of the one or more notification patterns is accessible to the user when the ambulatory medication device is in a locked state.
21. The ambulatory medication device of embodiment 1, wherein the ambulatory medication device further comprises a user interface element that allows a user to acknowledge an alert corresponding to an alert condition or to dismiss an alert corresponding to the alert condition, wherein the alert is associated with at least one of the one or more notification patterns.
22. A computer-implemented method for generating an alert corresponding to a severity level of an alert condition in an ambulatory medication device configured to generate a dose control signal configured to cause a medication pump to infuse a medication into a patient, comprising:
a hardware processor configured to generate a dose control signal configured to cause a drug pump to infuse a drug into a patient;
receiving first status information, the first status information including at least one of device information regarding a status of the ambulatory medication device or patient information regarding a status of the patient;
determining that the first status information satisfies an alarm condition for the ambulatory medication device or the patient;
modifying the list of pending alarm conditions based on the alarm condition in response to determining that the first status information satisfies an alarm condition for the ambulatory medication device or the patient and determining that the alarm condition does not already exist in the list of pending alarm conditions;
determining a severity level of the alarm condition, the severity level being one of a plurality of severity levels;
announcing an alarm condition using one or more notification patterns, the one or more notification patterns being selected based on a severity level of the alarm condition for the ambulatory medication device or the patient;
maintaining an indication of the alarm condition on a list of pending alarm conditions until the alarm condition is resolved.
23. The computer-implemented method of embodiment 22, further comprising receiving first status information from a monitoring system interface of the ambulatory medication device, wherein the monitoring system interface is configured to receive the status information.
24. The computer-implemented method of embodiment 22, wherein one or more notification patterns are selected from a plurality of notification patterns, and at least one severity level of a plurality of severity levels is associated with a unique notification pattern of the plurality of notification patterns.
25. The computer-implemented method of embodiment 22, further comprising displaying a list of pending alarm conditions on a user interface of the mobile medication device that is accessible when the mobile medication device is in the locked state.
26. The computer-implemented method of embodiment 22, further comprising transmitting alarm condition data corresponding to the alarm condition to a remote electronic device, enabling the remote electronic device to announce the alarm condition.
27. The computer-implemented method of embodiment 22, further comprising outputting an alarm status icon for display on a user interface of the ambulatory medication device, the alarm status icon including a visual indication of the number of alarm conditions on the list of pending alarm conditions.
28. The computer-implemented method of embodiment 22, further comprising:
receiving second status information;
23. The computer-implemented method of embodiment 22, comprising: determining that the second status information satisfies an alarm condition for the ambulatory medication device or the patient, and modifying one or more notification patterns used to notify the alarm condition in response to determining that an indication of the alarm condition is already present in the list of pending alarm conditions.
29. In response to determining that the first status information satisfies an alarm condition and an indication of the alarm condition is present in a list of pending alarm conditions, the computer-implemented method comprises:
modifying a severity level of the alarm condition from a first severity level of the plurality of severity levels to a second severity level of the plurality of severity levels;
23. The computer-implemented method of embodiment 22, comprising modifying one or more notification patterns of the alarm condition based on the severity of the alarm condition.
30. The computer-implemented method of embodiment 22, further comprising:
interrupting delivery of medication to the patient in response to determining that the severity of the alarm condition is consistent with an unsafe operation severity;
and maintaining delivery of the medication to the patient in response to determining that the severity of the alarm condition matches the safe operating severity.

Further embodiments of the present disclosure can be described in view of the following numbered embodiments:
1. An automated glycemic control system configured to provide automatic delivery of a glucose control therapy to a patient and to receive information regarding a manual glucose control therapy to be provided to the patient, comprising:
a drug delivery interface configured to operably connect to a drug pump configured to infuse a drug into a patient;
a user interface controller configured to receive input signals corresponding to user interactions with the user interface;
a memory configured to store specific computer-executable instructions and a treatment log;
communicate with the memory and, at a minimum,
generating an indication of a medication bolus amount via a control algorithm configured to control the patient's blood glucose level, the medication bolus corresponding to a medication meal bolus or a medication correction bolus, the medication bolus amount being selected by the control algorithm based at least in part on a previous period of blood glucose control of the patient;
generating a display of a manual bolus screen including a manual bolus control element and a bolus recommendation including an indication of the amount of a bolus of medication generated by the control algorithm;
receiving an indication of a manual bolus amount of medication via user interaction with a manual bolus control element;
storing in the treatment log an indication of the amount of the manual bolus of medication delivered to the patient and an indication of the time the manual bolus of medication was delivered to the patient;
modeling the attenuation of the medication in the patient over time based at least in part on manual boluses of the medication;
and a hardware processor configured to execute certain computer-executable instructions to operate a control algorithm for automatically generating an insulin administration signal configured to operate a drug pump to control blood glucose levels in the patient based at least in part on a glucose level signal received from a glucose level sensor operably connected to the patient and a time course of a drug's activity in the patient due to a finite utilization rate of the drug.
2. An ambulatory medical device comprising the automated blood glucose control system of embodiment 1 and a drug pump.
3. The ambulatory medical device of embodiment 2, wherein the medication pump comprises at least one of an insulin pump or a counterregulator pump.
4. The automated glycemic control system of embodiment 1, wherein the hardware processor is further configured to execute certain computer-executable instructions to at least model the accumulation of a manual bolus of the medication in the patient's blood following subcutaneous injection of the medication.
5. The automated glycemic control system of embodiment 1, further comprising a wireless electronic communication interface configured to receive an indication of the amount of a manual bolus of medication from an electronic device remote from the medication pump.
6. The automated glycemic control system of embodiment 1, wherein receiving an indication of the amount of the manual bolus of medication comprises detecting a gesture interaction performed by a user.
7. The automated glycemic control system of embodiment 6, wherein detecting a gesture interaction made by a user includes verifying that the gesture interaction matches a specified gesture interaction required for inputting a manual bolus of medication.
8. The automated glycemic control system of embodiment 1, wherein receiving an indication of the amount of a manual bolus of medication comprises receiving an estimate of a meal size or an estimate of the number of carbohydrates consumed by the patient.
9. The automated glycemic control system of embodiment 1, wherein receiving an indication of the amount of the manual bolus of medication includes receiving an estimate of the intensity of exercise in which the patient is engaged.
10. The automated glycemic control system of embodiment 1, wherein the hardware processor is further configured to execute specific computer-executable instructions to generate at least a dose control signal based at least in part on an indication of an amount of a manual bolus of medication.
11. The automated glycemic control system of embodiment 10, wherein the hardware processor is further configured to execute specific computer-executable instructions to provide a dose control signal to at least the drug pump.
12. The automated glycemic control system of embodiment 10, wherein a manual bolus of medication is infused through injection therapy or pump therapy.
13. The automated glycemic control system of embodiment 10, wherein modeling the decline of a drug in a patient over time allows for the prediction of future effects of a drug previously infused into the patient.
14. An automated glycemic control system configured to provide automatic delivery of a glucose control therapy to a patient and to receive information regarding a manual glucose control therapy to be provided to the patient, comprising:
a glucose sensor interface operative to receive a glucose level signal from the sensor operative to determine a glucose level of the patient at periodic measurement intervals;
a delivery device interface configured to send an insulin dose control signal to a drug pump operative to deliver a dose of insulin to the patient;
a memory configured to store specific computer-executable instructions;
communicate with the memory and, at a minimum,
receiving an indication of a manual bolus amount of insulin from a user interface;
and a hardware processor configured to execute specific computer-executable instructions to automatically generate an insulin dose control signal based at least in part on a glucose level signal, input parameters corresponding to insulin accumulation in the patient due to a finite utilization rate of insulin, the patient's weight, an indication of an amount of a manual bolus of insulin, and an indication of a time at which the manual bolus of insulin is delivered to the patient.
15. The automated glycemic control system of embodiment 14, wherein the input parameters include a measure of body weight, body mass value, or body mass index value.
16. The automated glycemic control system of embodiment 14, wherein the insulin dose control signal is automatically adjusted based on the amount of a manual bolus of insulin.
17. The automated glycemic control system of embodiment 14, wherein the hardware processor is further configured to execute specific computer-executable instructions to at least generate a glucagon dose control signal based at least in part on an indication of a manual bolus amount of insulin.
18. An automated glycemic control system configured to provide automatic delivery of a glucose control therapy to a patient and to receive information regarding a manual glucose control therapy to be provided to the patient, comprising:
a drug delivery interface configured to operably connect to a drug pump configured to infuse a drug into a patient;
a user interface controller configured to receive input signals corresponding to user interactions with the user interface;
a memory configured to store specific computer-executable instructions;
communicate with the memory and, at a minimum,
receiving a meal announcement from the user in response to the user interacting with the user interface, the meal announcement including an indication of the size of the meal consumed or to be consumed by the patient;
determining a meal bolus of insulin to administer to the patient based at least in part on the meal announcement, the meal bolus of insulin comprising an amount of insulin to administer to the patient to compensate for changes in blood glucose resulting from the meal;
output for displaying insulin meal bolus instructions;
receiving from the user an indication of a requested change to the insulin meal bolus;
and a hardware processor configured to execute certain computer-executable instructions to operate a control algorithm for automatically generating an insulin administration signal configured to operate a drug pump to control blood glucose levels in the patient based at least in part on the patient's glucose level and modifications to an insulin meal bolus.
19. The automated glycemic control system according to embodiment 18, wherein the user is a patient or a caregiver of the patient.
20. The automated glycemic control system of embodiment 18, wherein the meal announcements are received via a wireless electronic communication interface configured to connect to a remote electronic device.

Further embodiments of the present disclosure can be described in view of the following numbered embodiments:
1. A computer-implemented method for managing data access for a mobile medical device, comprising:
Through the computing system of the networked computing environment,
establishing a direct end-to-end data connection to the mobile medical device over a wireless wide area network;
transmitting a public key of the computing system to the mobile medical device, the public key enabling the mobile medical device to encrypt data transmitted to the computing system, the computing system storing a private key corresponding to the public key, the private key enabling the computing system to decrypt data received from the mobile medical device;
receiving a request from the mobile medical device to transfer data stored on the mobile medical device to a computing system via a direct end-to-end data connection over a wireless wide area network;
In response to receiving a request to transfer data stored on the mobile medical device to a computing system;
receiving encrypted data from the mobile medical device via a direct end-to-end data connection;
decrypting the encrypted data to obtain treatment data related to a treatment delivered to the patient by the mobile medical device;
generating a treatment report based at least in part on the treatment data, the treatment report including time series treatment data regarding treatments delivered by the ambulatory medical device over a specified period of time;
receiving a request from a display system separate from the networked computing environment to access the treatment report, the request including an account identifier associated with a user generating the request;
determining whether the account associated with the account identifier is authorized to view the treatment report based on the permissions modified by the patient in the networked computing environment;
transmitting the treatment report to the display system via an encrypted communication channel in response to determining that the account is authorized to view the treatment report;
11. A computer-implemented method comprising:
2. The computer-implemented method of embodiment 1, wherein the request to access the treatment report includes a device identifier associated with the mobile medical device, the device identifier being a unique identifier specific to the mobile medical device.
3. The computer-implemented method of embodiment 2, further comprising determining whether the mobile medical device is authorized to transfer data to the computing system based at least in part on the device identifier.
4. The computer-implemented method of embodiment 2, wherein the device identifier is initially provided to the networked computing environment as part of a manufacturing process for manufacturing the mobile medical device or prior to provisioning the mobile medical device to a patient.
5. 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 patient identifier.
6. Establishing a direct end-to-end data connection
receiving a device identifier associated with the mobile medical device, the device identifier being a unique identifier specific to the mobile medical device;
and determining that the mobile medical device is authorized 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 treatment data with the account identifier in storage in the networked computing environment.
8. The computer-implemented method of embodiment 1, further comprising generating a shared secret key based at least in part on the public key and the private key, and wherein decrypting the encrypted data comprises decrypting the encrypted data using the shared secret key.
9. The computer-implemented method of embodiment 1, further comprising storing the treatment data in one or more of a storage of the computing system or a storage of the networked computing environment.
10. The computer-implemented method of embodiment 1, wherein the computing system is located in 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 monohormonal drug pump, a bihormonal drug pump, or a pacemaker.
12. The computer-implemented method of embodiment 1, wherein the mobile medical device comprises a transceiver that supports communication via one or more communication standards, including 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 Communications (LTE-MTC) standard.
13. The computer-implemented method of embodiment 1, wherein the treatment data includes at least one of dosage data or patient data, the dosage data corresponding to one or more doses of a medication provided to the patient by the mobile medical device, and the patient data corresponding to a medical or physiological condition of the patient as determined by the mobile medical device.
14. The computer-implemented method of embodiment 1, wherein the encrypted data further includes at least one of operational data or error data, the operational data corresponding to an operation of the mobile medical device, and the error data corresponding to an error in the operation of the mobile medical device.
15. The computer-implemented method of embodiment 1, wherein a direct end-to-end data connection enables communication with the mobile medical device without communicating through an intermediate computing device.
16. The computer-implemented method of embodiment 1, wherein the account identifier comprises a unique identifier associated with a patient or a user authorized to access the treatment report.
17. The computer-implemented method of embodiment 1, wherein the additional encrypted data is received from the mobile medical device intermittently, periodically, periodically, or continuously over at least one period of time.
18. The computer-implemented method of embodiment 1, wherein the display system comprises a computing system of the patient's healthcare provider or guardian.
19. The computer-implemented method of embodiment 1, further comprising determining that the treatment data meets an alert threshold.
20. The computer-implemented method of embodiment 19, further comprising generating an alert in response to the therapy data meeting an alert threshold.
21. The computer-implemented method of embodiment 20, further comprising outputting an alert to one or more of a display system, a physician user device, a mobile medical device, an emergency services provider user device, a patient user device, or a user device of an authorized user associated with the patient.
22. The computer-implemented method of embodiment 1, wherein receiving a request to transfer data stored on a mobile medical device to a computing system includes receiving encrypted data from the mobile medical device.
23. A computing system included in a networked computing environment, comprising:
a memory configured to store specific computer-executable instructions;
communicate with the memory and, at a minimum,
establishing a direct end-to-end data connection to the mobile medical device over a wireless wide area network;
transmitting a public key to the mobile medical device, the public key enabling the mobile medical device to encrypt data transmitted to the computing system, the computing system storing a private key corresponding to the public key, the private key enabling the computing system to decrypt data received from the mobile medical device;
receiving a request from the mobile medical device to transfer data stored on the mobile medical device to a computing system via a direct end-to-end data connection over a wireless wide area network;
In response to receiving a request to transfer data stored on the mobile medical device to the computing system, the hardware processor executes certain computer-executable instructions to at least:
receiving encrypted data from the mobile medical device via a direct end-to-end data connection;
further configured to decrypt the encrypted data to obtain treatment data related to a treatment delivered to the patient by the mobile medical device;
generating a treatment report based at least in part on the treatment data, the treatment report including time series treatment data regarding treatments delivered by the mobile medical device over a specified period of time;
receiving a request from a display system separate from the networked computing environment to access the treatment report, the request including an account identifier associated with a user generating the request;
determining whether the account associated with the account identifier is authorized to view the treatment report based on the patient's modified permissions in the networked computing environment;
and a hardware processor configured to execute certain computer-executable instructions to transmit the treatment report to a display system over an encrypted communication channel in response to determining that the account is authorized to view the treatment report.
24. The hardware processor further executes specific computer-executable instructions to perform at least:
further configured to receive a device identifier associated with the mobile medical device, the device identifier being a unique identifier specific to the mobile medical device;
and further configured to determine, based at least in part on the device identifier, that the mobile medical device is authorized to communicate with the computing system.
24. A computing system as described in embodiment 23.
25. The computing system of embodiment 23, wherein the hardware processor is further configured to execute certain computer-executable instructions to at least generate a shared secret key based at least in part on the public key and the private key, and wherein decrypting the encrypted data includes decrypting the encrypted data using the shared secret key.
26. The computing system of embodiment 23, wherein receiving a request to transfer data stored on the mobile medical device to the computing system includes receiving encrypted data from the mobile medical device.
27. The computing system of embodiment 23, wherein the treatment data includes at least one of dosage data or patient data, the dosage data corresponding to one or more doses of the medication provided to the patient by the mobile medical device, and the patient data corresponding to a medical or physiological condition of the patient determined by the mobile medical device.
28. A hardware processor executes specific computer-executable instructions to perform at least the following:
determining that the treatment data meets an alert threshold;
further configured to generate an alert in response to the treatment data meeting an alert threshold;
24. A computing system as described in embodiment 23.
29. The computing system of embodiment 28, wherein the hardware processor is further configured to output an alert to one or more of a display system, a physician user device, a mobile medical device, an emergency services provider user device, a patient user device, or a user device of an authorized user associated with the patient.
30. The computing system of embodiment 28, wherein the alert threshold is based at least in part on patient physiological information obtained from the ambulatory medical device.

Further embodiments of the present disclosure can be described in view of the following numbered embodiments:
1. A computer-implemented method for managing a non-critical malfunction in an ambulatory medical device configured to deliver therapy to a patient, comprising:
The mobile medical device processor
detecting a device status of the mobile medical device;
determining that the device conditions do not meet a set of normal operating parameters for the mobile medical device;
determining that the device conditions satisfy a set of minimum operating parameters, the set of minimum operating parameters being sufficient to enable delivery of therapy to the patient by the ambulatory medical device;
determining that the device state does not meet a set of normal operating parameters and in response to determining that the device state meets a set of minimum operating parameters;
maintaining delivery of treatment to the patient by the mobile medical device;
generating a non-critical malfunction alert based at least in part on a device status, the non-critical malfunction alert allowing a user to determine the device status, the non-critical malfunction alert being disabled by the user, and the generation of the non-critical malfunction alert being scheduled to repeat on a specific schedule until a warning correction condition occurs.
2. The computer-implemented method of embodiment 1, wherein the ambulatory medical device is a drug pump.
3. The computer-implemented method of embodiment 2, wherein the medication pump comprises at least one of an insulin pump or a counterregulator pump.
4. The computer-implemented method of embodiment 1, wherein at least some of the set of minimum operating parameters are provided by a manufacturer, a healthcare provider, a patient, or an authorized user of the mobile medical device.
5. The computer-implemented method of embodiment 1, wherein at least some of the set of normal operating parameters are provided by a healthcare provider, a patient, or an authorized user.
6. The computer-implemented method of embodiment 1, further comprising announcing the non-critical malfunction alert using an annunciation pattern that depends on at least one of the detected device condition that triggered the generation of the non-critical malfunction alert, or the number of times the non-critical malfunction alert was generated on the mobile medical device.
7. The computer-implemented method of embodiment 1, wherein delivery of therapy is stopped based at least in part on the detected device state.
8. A computer-implemented method as recited in embodiment 1, wherein the non-critical malfunction warning is repeated periodically.
9. A computer-implemented method as recited in embodiment 1, wherein the non-critical malfunction warnings are repeated at variable intervals, said variable intervals increasing or decreasing as the time since the first non-critical malfunction warning increases.
10. A computer-implemented method as recited in embodiment 1, wherein the non-critical malfunction warning is repeated at a time period that varies during the day based on the time of day.
11. The computer-implemented method of embodiment 1, wherein the alert remediation condition comprises a detected change in device state.
12. The computer-implemented method of embodiment 1, wherein generating a non-critical malfunction alert includes contacting a manufacturer of the mobile medical device or a healthcare provider.
13. The computer-implemented method of embodiment 1, wherein generating a non-critical malfunction alert includes ordering a medication.
14. A computer-implemented method as recited in embodiment 1, wherein generating a non-critical malfunction alert includes providing instructions for correcting the device malfunction.
15. A computer-implemented method as recited in embodiment 1, wherein, in response to determining that the device conditions do not meet a set of normal operating parameters for the mobile medical device, delivery of therapy to the patient by the mobile medical device is maintained at a normal rate.
16. A computer-implemented method as recited in embodiment 1, wherein, in response to determining that the device conditions do not meet a set of normal operating parameters for the mobile medical device, delivery of therapy to the patient by the mobile medical device is maintained at a minimum rate.
17. A mobile medical device configured to provide treatment to a patient, comprising:
a memory configured to store specific computer-executable instructions;
communicate with the memory and, at a minimum,
Detecting the device status of mobile medical devices;
determining that the device state does not meet a set of normal operating parameters for the mobile medical device;
determining that the device conditions satisfy a set of minimum operating parameters, the set of minimum operating parameters being sufficient to enable delivery of therapy to the patient by the ambulatory medical device;
In response to determining that the device conditions meet a set of minimum operational parameters, the hardware processor executes certain computer-executable instructions to at least:
Maintaining delivery of care to patients through mobile medical devices;
a hardware processor configured to execute specific computer-executable instructions to generate a user alert based at least in part on a device status, the user alert allowing a user to determine a device status of the ambulatory medical device, the user alert being further configured to be inhibited by the user, and the user alert being scheduled to repeat on a specific schedule until an alert modification condition occurs;
A mobile medical device comprising:
18. The ambulatory medical device of embodiment 17, comprising a drug pump.
19. The ambulatory medical device of embodiment 18, wherein the medication pump comprises at least one of an insulin pump or a counterregulator pump.
20. The mobile medical device of embodiment 17, wherein the minimum operating parameters and/or normal operating parameters are provided by a manufacturer of the mobile medical device.
21. 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 patient or an authorized user.
23. The ambulatory medical device of embodiment 17, wherein the 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 a user alert was generated prior to the given time.
24. The ambulatory medical device of embodiment 17, wherein the hardware processor is configured to execute specific computer-executable instructions to cease delivery of therapy based at least in part on the detected device condition.
25. The ambulatory medical device of embodiment 17, wherein the alert modification condition comprises a detected change in device state.
26. The ambulatory medical device of embodiment 17, wherein generating a user alert includes contacting the manufacturer or a healthcare provider.
27. The mobile medical device of embodiment 17, wherein generating a user alert includes ordering a medication.
28. The ambulatory medical device of embodiment 17, wherein generating a user alert includes generating a display of instructions for resolving the detected device condition.
29. The mobile medical device of embodiment 17, wherein, in response to determining that the device conditions do not meet a set of normal operating parameters for the mobile medical device, the hardware processor is configured to execute certain computer-executable instructions to maintain delivery of therapy to the patient at a normal rate.
30. The mobile medical device of embodiment 17, wherein in response to determining that the device conditions do not meet a set of normal operating parameters for the mobile medical device, the hardware processor is configured to execute certain computer-executable instructions to maintain delivery of therapy to the patient at a reduced rate.

Further embodiments of the present disclosure can be described in view of the following numbered embodiments:
1. An ambulatory medication device configured to automatically resume medication delivery to a patient after medication delivery has been interrupted, comprising:
a drug pump configured to receive a dose control signal configured to cause the drug pump to deliver a drug to the patient;
a memory configured to store specific computer-executable instructions;
communicate with the memory and, at a minimum,
receiving a request to temporarily suspend delivery of the medication to the patient, the request including an indication of a temporary suspension period relating to the length of time the delivery of the medication should be suspended;
suspending delivery of the drug to the patient, wherein suspending delivery of the drug includes not generating a dose control signal or generating a dose control signal to cause the drug pump to not administer the drug to the patient during a suspension period;
determining that a resume condition has occurred during the pause period, the resume condition not requiring user action to trigger the resume condition;
generating a dose control signal after the occurrence of a resume condition, thereby interrupting the pause period;
a hardware processor configured to execute specific computer-executable instructions to automatically resume drug delivery by providing a dose control signal to the drug pump;
1. An ambulatory medication device comprising:
2. The ambulatory medication device of embodiment 1, wherein the resumed state occurs during a temporary suspension period.
3. The ambulatory medication device of embodiment 1, wherein the resumed state comprises the expiration of a temporary suspension period.
4. The ambulatory medication device of embodiment 1, wherein the hardware processor is further configured to execute certain computer-executable instructions to generate a warning prior to generating at least the dose control signal, the warning indicating that the temporary suspension period has ended.
5. The ambulatory medication device of embodiment 1, wherein the hardware processor is further configured to execute certain computer-executable instructions to generate an alert upon determining that at least a resume condition has occurred, the alert indicating that the temporary suspension period has ended.
6. The ambulatory medication device of embodiment 1, wherein receiving a request to temporarily suspend delivery comprises receiving a first user interaction with a user interface.
7. The ambulatory medication device of embodiment 6, wherein receiving a request to temporarily suspend delivery comprises receiving a second user interaction with a user interface.
8. The mobile medication device of embodiment 6, wherein the first user interaction comprises a gesture performed on a touch screen display of the mobile medication device.
9. The ambulatory medication device of embodiment 1, wherein determining that a resume condition has occurred comprises determining that a user interaction with a user interface is received.
10. The ambulatory medication device of embodiment 1, wherein the hardware processor is further configured to execute certain computer-executable instructions to generate a warning prior to at least suspending delivery of the medication to the patient, the warning indicating a suspension start time at which delivery of the medication will be suspended.
11. The ambulatory medication device of embodiment 1, wherein determining that a resumption condition has occurred comprises determining that the patient's medical condition meets a threshold condition.
12. The ambulatory medication device of embodiment 11, wherein the hardware processor is further configured to execute certain computer-executable instructions to generate an alert in response to determining that at least a resume condition has occurred, the alert indicating that the patient's medical condition meets a threshold condition.
13. The ambulatory medication device of embodiment 11, wherein the threshold condition comprises the patient's measured blood glucose level exceeding a threshold level.
14. The ambulatory medication device of embodiment 11, wherein the threshold condition comprises the patient's measured blood glucose level being below a threshold level.
15. The ambulatory medication device of embodiment 1, wherein the medication pump comprises an insulin pump.
16. The ambulatory medication device of embodiment 1, wherein the medication pump comprises a bi-hormonal pump capable of administering insulin and a counter-regulatory agent.
17. The ambulatory medication device of embodiment 1, wherein the request includes an indication of a start time at which delivery of the medication is to be suspended.
18. The ambulatory medication device of embodiment 17, wherein the hardware processor is configured to suspend delivery of the medication to the patient at an interruption start time.
19. The ambulatory medication device of embodiment 1, wherein the hardware processor is further configured to execute certain computer-executable instructions to delay discontinuation of medication delivery in response to determining that the patient's medical condition meets a threshold medical condition.
20. The ambulatory medication device of embodiment 1, wherein the hardware processor is configured to execute certain computer-executable instructions to generate a dosage control signal for the next scheduled administration period after determining that a resume condition has occurred.
21. The ambulatory medication device of embodiment 1, wherein the hardware processor is configured to execute certain computer-executable instructions to generate the dose control signal immediately after determining that a resume condition has occurred.
22. The ambulatory medication device of embodiment 1, wherein the hardware processor is configured to execute certain computer-executable instructions to generate the dose control signal after determining that a resume condition has occurred and after determining the patient's medical condition.
23. The ambulatory medication device of embodiment 22, wherein determining the patient's medical condition comprises receiving a measured blood glucose level of the patient.
24. The ambulatory medication device of embodiment 1, wherein receiving a request to temporarily suspend delivery of medication to the patient comprises determining that one or more components of the ambulatory medication device do not meet minimum requirements for operation.
25. A method for automatically resuming drug delivery to a patient after drug delivery has been interrupted by a glycemic control system, comprising:
a hardware processor of the glycemic control system configured to generate a dose control signal, when the dose control signal is received by the drug pump, instructing the drug pump to administer a drug to the patient or not to administer a drug to the patient;
receiving a request to temporarily suspend delivery of medication to the patient, the request including an indication of a temporary suspension period relating to the length of time delivery of the medication should be suspended;
suspending delivery of the drug to the patient, the suspending of delivery of the drug comprising not generating a dose control signal or generating a pre-dose control signal to prevent the drug pump from administering the drug to the patient during a suspension period;
determining that a resume condition has occurred during the pause period, the resume condition not requiring user action to trigger the resume condition;
and in response to determining that a resumption condition has occurred, generating a dose control signal for administering the medication to the patient after the occurrence of the resumption condition, thereby interrupting the temporary suspension period.
26. The method of embodiment 25, further comprising generating an alert before or when the suspension period expires.
27. The method of embodiment 25, further comprising generating a warning before suspending delivery of the medication to the patient, the warning indicating a suspension start time at which delivery of the medication will be suspended.
28. The method of embodiment 25, further comprising generating an alert in response to determining that a resume condition has occurred, the alert indicating that the patient's medical condition meets a threshold medical condition.
29. The method of embodiment 25, wherein the restart condition occurs during a temporary suspension period.
30. The method of embodiment 25, wherein the resumption condition includes the expiration of a temporary suspension period.

Terminology It is to be understood that not necessarily all objectives or advantages may be achieved in accordance with any particular embodiment described herein. Thus, for example, those skilled in the art will recognize that a particular embodiment may be configured to operate to achieve or optimize one advantage or advantages taught herein without necessarily achieving other objectives or advantages that may be taught or suggested herein.

All of the processes described herein may be embodied in and fully automated via software code modules executed by a computing system including one or more computers or processors. The code modules may be stored on any type of non-transitory computer-readable medium or other computer storage device. Some or all of the methods may be implemented in dedicated computer hardware. Furthermore, the computing system may include, be implemented as part of, or communicate with an automated blood glucose system, a mobile medication system, or a mobile medical device.

Many other variations beyond those described herein will be apparent from this disclosure. For example, depending on the embodiment, certain operations, events, or functions of any of the algorithms described herein may be performed in a different order, added, merged, or omitted entirely (e.g., not all acts or events described may be necessary to implement an algorithm). Furthermore, in certain embodiments, operations or events may be performed simultaneously rather than sequentially, for example, via multithreading, interrupt processing, or multiple processors or processor cores, or on other parallel architectures. Furthermore, different tasks or processes may be performed by different machines and/or computing systems that can function together.

The various illustrative logic blocks and modules described in connection with the embodiments disclosed herein may be implemented or executed by a machine, such as a processing device or processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. The processor may be a microprocessor, but in alternative examples, the processor may be a controller, microcontroller, or state machine, combinations thereof, etc. The processor may include electrical circuitry configured to process computer-executable instructions. In another embodiment, the processor includes an FPGA or other programmable device that performs logical operations without processing computer-executable instructions. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration. While described herein primarily with reference to digital technology, a processor may also include primarily analog components. The computing environment may include any type of computing system, including, but not limited to, a computing system based on a computing engine within a microprocessor, mainframe computer, digital signal processor, portable computing device, device controller, or appliance, to name a few.

In particular, conditional language such as "can," "could," "might," or "may" is understood otherwise within the context in which it is generally used to convey that certain embodiments include certain features, elements, and/or steps, while other embodiments do not, unless otherwise specified. Thus, such conditional language is not generally intended to imply that features, elements, and/or steps are somehow required in one or more embodiments, or that one or more embodiments necessarily include logic for determining whether those features, elements, and/or steps should be included in or performed in any particular embodiment, with or without user input or prompting.

Disjunctive language, such as the phrase "at least one of X, Y, or Z," is understood in the context in which it is generally used to indicate that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z), unless otherwise specified. Thus, such disjunctive language generally does not and should not imply that a particular embodiment requires at least one of X, at least one of Y, or at least one of Z, respectively, to be present.

Any process descriptions, elements, or blocks in the flow diagrams described herein and/or shown in the accompanying drawings should be understood as potentially representing modules, segments, or portions of code that comprise one or more executable instructions for implementing a particular logical function or element in the process. As will be understood by those skilled in the art, alternative implementations in which elements or functions may be omitted, performed, or described in a different order than that shown or described, including substantially simultaneously or in reverse order, depending on the functionality involved, are included within the scope of the embodiments described herein.

Unless otherwise noted, articles such as "a" or "an" should generally be construed to include one or more listed items. Thus, phrases such as "a device configured to" are intended to include one or more of the listed devices. Such one or more listed devices may also be collectively configured to perform the stated enumeration. For example, "a processor configured to perform enumerations A, B, and C" may include a first processor configured to perform enumeration A working in conjunction with a second processor configured to perform enumerations B and C.

It should be understood that many variations and modifications can be made to the above-described embodiments, and that the elements thereof are among other acceptable examples. All such modifications and variations are intended to be included within the scope of this disclosure.

Claims (1)

1. A computer-implemented method for updating an application executing on a mobile medical device without interrupting treatment provided to a patient by the mobile medical device, comprising:
The hardware processor in the mobile medical device
receiving an indication that an application update is available, the application update including an update to an application running on the mobile medical device;
establishing a communications connection to a host computing system configured to host the application update;
downloading the application update from the host computing system;
verifying that the downloaded copy of the application update is complete;
verifying that the downloaded copy of the application update is not corrupted;
determining a running time for an installation process to install the downloaded copy of the application update on the mobile medical device, the running time comprising an amount of time to run the installation process;
receiving a trigger for installing the downloaded copy of the application update, the trigger including detecting a failure during execution of the application;
determining a next treatment delivery time associated with delivering treatment to a patient by the ambulatory medical device in response to the trigger;
determining, based at least in part on the execution time, that the installation process will be completed before the next treatment delivery time;
initiating the installation process of the downloaded copy of the application update without interrupting treatment provided to the patient by the mobile medical device;
Equipped with
The application includes one of a first application version including a first feature set or a second application version including a second feature set, and the step of downloading the application update includes downloading the first application version to a second application version including a second feature set.
downloading one of a first application update corresponding to the version or a second application update corresponding to the second application version;
the first feature set includes a subset of the second feature set or a set of features that partially overlap with the second feature set;
Computer-implemented methods.