Blood sugar control system

Abstract

A glycemic control system and a mobile medical device for providing therapy to a patient are disclosed. The disclosed system and device can implement one or more features to improve the user experience, such as software update techniques 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.

Description

[Technical Field]

[0001] 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.

[0002] The present disclosure relates to glycemic control systems and ambulatory medical devices that deliver therapy to patients. [Background technology]

[0003] Sustained-delivery, pump-driven medication injection devices generally include a delivery cannula subcutaneously placed through a patient's skin at an 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. Summary of the Invention

[0004] Glycemic control systems and mobile medical devices that provide therapy to patients, such as glycemic control, are disclosed. The disclosed systems and devices can implement one or more features that improve the user experience, such as software update techniques 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.

[0005] 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. [Brief explanation of the drawings]

[0006] [Figure 1A] 1 illustrates an exemplary glycemic control system that provides glycemic control via an ambulatory drug pump.

[0007] [Figure 1B] 1 illustrates another exemplary glycemic control system that provides glycemic control via an ambulatory drug pump.

[0008] [Figure 1C] 1 illustrates another exemplary glycemic control system that provides glycemic control via an ambulatory drug pump.

[0009] [Figure 2A] 1 shows a block diagram of an exemplary glycemic control system.

[0010] [Figure 2B] FIG. 1 shows a block diagram of another exemplary glycemic control system.

[0011] [Figure 2C] FIG. 1 shows a block diagram of another exemplary glycemic control system.

[0012] [Figure 2D] FIG. 1 shows a block diagram of another exemplary glycemic control system.

[0013] [Figure 3] FIG. 1 is a schematic diagram of an exemplary glucose control system including an electronic communication interface.

[0014] [Figure 4A]FIG. 1 shows a block diagram of an exemplary glycemic control system in an online mode of operation.

[0015] [Figure 4B] FIG. 1 shows a block diagram of an exemplary glycemic control system in an offline mode of operation.

[0016] [Figure 5A] 1 is a perspective view of an exemplary ambulatory medical device.

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

[0018] [Figure 6] FIG. 1 illustrates different modules that may be included in an exemplary ambulatory medical device (AMD).

[0019] [Figure 7] 1 illustrates various methods and links that an AMD may use to establish a communications connection with a host computing system.

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

[0021] [Figure 9] 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 treatment provided to a patient.

[0022] [Figure 10]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 treatment provided to the patient.

[0023] [Figure 11] 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 treatment provided to the patient, but only if the second application meets a minimum set of operating conditions.

[0024] [Figure 12] 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.

[0025] [Figure 13] 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 the 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.

[0026] [Figure 14] 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.

[0027] [Figure 15A]FIG. 10 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.

[0028] [Figure 15B] FIG. 1 is a flow diagram illustrating an exemplary method that may be used by an AMD to transmit therapy to a computing system in a networked computing environment.

[0029] [Figure 16] 1 is a block diagram illustrating an exemplary network and data flow configuration in which an AMD is directly connected to a computing system, and the computing system generates and sends alerts to one or more display systems and the AMD.

[0030] [Figure 17] 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.

[0031] [Figure 18] Illustrates the interconnections between AMD modules and procedures involved in receiving, accepting, and / or canceling a treatment change request.

[0032] [Figure 19] 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.

[0033] [Figure 20A] 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.

[0034] [Figure 20B]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.

[0035] [Figure 20C] FIG. 10 is an exemplary therapy change user interface.

[0036] [Figure 20D] FIG. 10 is a diagram of another therapy change user interface on a touch screen display.

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

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

[0039] [Figure 23A] FIG. 10 is a diagram of a touch screen display alerting a user that delivery of one or more medications is about to occur.

[0040] [Figure 23B] FIG. 10 is a diagram of a touch screen display showing medication being delivered to a user.

[0041] [Figure 24] FIG. 1 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.

[0042] [Figure 25] FIG. 10 is a flow diagram illustrating an exemplary method for receiving and implementing an interrupt request that may be implemented by AMD.

[0043] [Figure 26] 10 illustrates several screens that a mobile medical device can display when a user pauses treatment.

[0044] [Figure 27] FIG. 1 is a flow diagram illustrating an exemplary method for resuming interrupted therapy that may be performed by an AMD.

[0045] [Figure 28] 10A-10C illustrate several screens that a mobile medical device can display when a user resumes treatment.

[0046] [Figure 29] FIG. 2 is a block diagram showing the interconnection of AMD modules and procedures involved in changing the configuration of the AMD.

[0047] [Figure 30] 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.

[0048] [Figure 31] 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.

[0049] [Figure 32] FIG. 1 is a schematic diagram showing the interconnections between the modules and procedures of the AMD involved in monitoring the AMD and / or patient condition and generating alerts when alert conditions are met.

[0050] [Figure 33A] FIG. 1 is a flow diagram illustrating an exemplary procedure that may be used by AMD's alarm system to announce an alarm condition upon receiving status information that satisfies the alarm condition.

[0051] [Figure 33B] 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.

[0052] [Figure 33C] 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.

[0053] [Figure 34] 1 is a block diagram illustrating the interconnections between the modules and procedures of the AMD involved in monitoring the state of the AMD and generating alerts when device malfunctions are detected.

[0054] [Figure 35] FIG. 1 is a flow diagram illustrating an exemplary procedure that may be used by an AMD's alert system to monitor the AMD's operation and generate an alert when a device malfunction is detected.

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

[0056] [Figure 37] FIG. 1 is a flow diagram of a process for providing options for meal dose selection on a mobile device.

[0057] [Figure 38] FIG. 10 is another flow diagram of a process for providing options for meal dose selection on a mobile device.

[0058] [Figure 39] 10 is a series of screen displays showing a user initiating activation of a meal dose on a mobile device.

[0059] [Figure 40] 10 is a series of screen displays showing a user initiating a meal dose on a mobile device.

[0060] [Figure 41] 10 is a sequence of screen displays showing a user activating a meal guide on a mobile device.

[0061] [Figure 42] 10 is a series of screen displays showing a user entering a total number of units into a mobile device.

[0062] [Figure 43] 10 is a series of screen displays showing a mobile medical device delivering a unit and canceling the delivery of a unit.

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

[0064] [Figure 45] FIG. 1 is a flow diagram of a process for receiving manual input of a medication dose on a mobile device. DETAILED DESCRIPTION OF THE INVENTION

[0065] 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 for infusing 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. A glycemic control system may operate in conjunction with an 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.

[0066] Overview of the Blood Glucose Control System A blood glucose control system (BGCS) is used to control a patient's blood glucose levels. The BGCS generates a dose control signal for one or more glucose control agents that can be infused into the patient. The glycemic control system may include a controller configured to: (a) generate a dose control signal for a glucose-regulating agent (GRA) even if the drug is unavailable for administration via a drug pump connected to the patient; (b) generate a dose control signal for a drug even if the drug is unavailable for administration via a drug pump connected to the patient; (c) generate a dose control signal for a drug even if the drug is unavailable for administration via a drug pump connected to the patient; (d) generate a dose control signal for a drug even if the drug is unavailable for administration via a drug pump connected to the patient; (e) generate a dose control signal for a drug even if the drug is unavailable for administration via a drug pump connected to the patient; (f) generate a dose control signal for a drug even if the drug is unavailable for administration via a drug pump connected to the patient; (g ...

[0067] 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 ambulatory 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.

[0068] In some examples, the ambulatory medical device (AMD) is an electrical stimulation device, and the 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.

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

[0070] 1B, drug pump 100 communicates with external electronic device 108 (e.g., a smartphone, etc.) 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.

[0071] 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, for example, a cloud computing service, that connects to drug pump 100 via a direct or indirect electronic data connection.

[0072] 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.

[0073] 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.

[0074] 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-controlling agents based on the patient's time-varying glucose level 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.

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

[0076] 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 send 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 send 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.

[0077] 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 glucose level signals at fixed or periodic measurement intervals, such as five-minute intervals. The glucose level sensor 110 can be operably connected to a 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 .

[0078] The controller can be configured to generate a dose control signal using a control algorithm that generates at least one of a basal dose, a correction dose, and / or a meal dose. Examples of control algorithms that can be used to generate these doses are disclosed in U.S. Patent Application Publication Nos. 2008 / 0208113, 2013 / 0245547, 2016 / 0331898, and 2018 / 0220942 (referred to herein as the "controller disclosures"), the entire contents of which are incorporated herein by reference. The correction dose can include a regulator or counter-regulator and can be generated using a model-predictive control (MPC) algorithm such as that disclosed in the controller disclosures. The basal dose can include a regulator and can be generated using a basal control algorithm such as that disclosed in the controller disclosures. The meal dose can include a regulator and can be generated using a meal control algorithm such as that 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.

[0079] 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.

[0080] 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 that implements a correction dose based on control parameters of the control algorithm in response to an isolated glucose measurement 406 (e.g., a measurement obtained from the patient using a glucose test strip). 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.

[0081] Exemplary Mobile Medical Devices In some embodiments, an ambulatory medical device (AMD) can 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 can continuously monitor a patient's health status (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 a therapy (e.g., one or more medications) to the patient based on the patient's status. To enable continuous monitoring of a patient's health status and deliver medications as needed, certain ambulatory drug devices can 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.). In some embodiments, an AMD can be an ambulatory drug device such as a drug delivery pump. In some examples, an AMD can be a device that provides therapy in the form of electrical stimulation based on a patient's health status (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).

[0082] 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 detection of motion using one or more motion sensors, such as an accelerometer. When touched, pressed, or held for a period of time, the AMD 506 can 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.

[0083] 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 AMD's status, 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 medications 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 within a single housing 502 (as shown in FIGS. 5A and 5B). In some examples, one or more modules may be individual modules contained in separate housings that communicate with other modules and / or the main unit via wired or wireless communication links (e.g., Bluetooth). The modules included 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 computation 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, the 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.

[0084] 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, as well as communication 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. The main memory 616 stores instructions and The main memory 618 may be any type of memory capable of communicating instructions to and receiving executed instructions from the processor 614. Types of main memory include, but are not limited to, random access memory (RAM) and read-only memory (ROM). The processor 614 may be any type of general-purpose central processing unit (CPU). In some embodiments, the control and computing 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. The storage 618 may be any type of computer storage capable of receiving data, storing data, and transmitting data to the main memory 616 and possibly other modules of the AMD 600. Types of storage 618 that may be used in the control and computing system 610 include, but are not limited to, magnetic disk memory, optical disk memory, flash memory, etc. The interface 612 may include data transfer buses and electronic circuitry configured to support data exchange between different components within the control and computation system 610. In some examples, the 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 the control and computation module 610.

[0085] 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 can convert analog signals received from the communications module 602 and convert them to digital signals that can be sent to the control and computing module 610 (e.g., via interface 612). As another example, the signal processing module can receive digital control signals from the control and computing module 610 and convert them to analog signals that can be sent to the therapy delivery module 606 to control, for example, one or more infusion pumps included in the therapy delivery module 606.

[0086] 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).

[0087] The user interface module 608 may include a display that shows various information about the AMD 600, such as the type and delivery schedule of the medication, the status of the software, etc. The display may 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 to respond to requests for certain actions (e.g., software installation). The alphanumeric pad may include a keyboard that can accept numbers, letters, and The AMD 600 may include multiple keys with letter and symbol 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 touchscreen 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 touchscreen display may accept input via capacitive touch, resistive touch, or other touch technology. The input surface of the touchscreen display may register the location of a touch on the surface. In some examples, the touchscreen 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 touchscreen display. In some examples, the touchscreen may present the user with one or more user interface screens that allow the user to change one or more treatment settings of the ambulatory medication device. In some examples, a user interface screen may include one or more parameter control elements. Additionally, a user interface screen may include one or more user input elements displayed on the screen that allow a user to interact with AMD 600.

[0088] In some embodiments, the 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 Narrowband Long-Term Evolution (NB-LTE), Narrowband Internet-of-Things (NB-IoT), or Long-Term Evolution machine type communications (LTE) standards. The AMD 600 may support communication via an LTE (Evolution Machine Type Communication) MTC (Multi-Telecommunication Technology) 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 communication module may wirelessly exchange data between other components of the AMD 600 (e.g., a blood glucose sensor), a mobile device (e.g., a smartphone, a laptop, etc.), a Wi-Fi network, a WLAN, a wireless router, a cellular tower, a Bluetooth device, 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 communication 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 can 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.

[0089] AMD in action In some embodiments, the AMD 600 (or AMD 100) can continuously, periodically, or intermittently receive information regarding one or more parameters that correlate with the health status of the patient 627 (e.g., blood glucose level, blood glucose trend, heart rate, body movement indicators, etc.). This information can be encoded into a signal provided to the AMD 600 by a glucose level sensor 620 (e.g., a wearable biomedical sensor that measures 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 can 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 can be included in the AMD 600 to communicate with the patient sensor 620. In some examples, the signal processed by the signal processing module 604 can be transmitted to the control and computing module 610, which can analyze the signal to determine whether medication should be delivered to the patient 627. If it is determined that a medication should be administered to the patient, the control and calculation module may determine the dosage and type of medication to administer based on information received from the patient sensor 620 and send 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).

[0090] In some embodiments, one or more procedures in 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 of medication and the required dosage, 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 the patient sensor 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 can be switched from the first software application to the second software application as needed.

[0091] In some embodiments, the AMD 600 is a user or control and computing module 6 10 can deliver multiple types of therapy selectable by the AMD 600. For example, the 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 the 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 the patient sensor 620.

[0092] Communications and Networks 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 treatment 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).

[0093] 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.

[0094] 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 not involve a local device, a device accessible by the user or patient (other than the AMD 600), a Wi-Fi network, a short-range wireless link (e.g., Bluetooth), or the like. 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 a direct end-to-end data connection involves at least one device identifier. The method may include determining that the AMD 600 is authorized to communicate with the host computing system 704 based on a device identifier. In some examples, the device identifier may be initially provided to the networked computing environment before 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 be made using information provided to the AMD 600 at the time of manufacture, shipment, 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.

[0095] 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).

[0096] 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, may register or associate the AMD 600 with a patient in the cloud service provider's computing network.

[0097] 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. By limiting access to the set of authorized computing systems, the risk of a malicious actor gaining access to AMD 600 is reduced. Additionally, in some cases, AMD 600 may include a blacklist or restriction list that identifies systems that AMD 600 is not authorized to access. A blacklist may be used to restrict access to more restricted or unsafe websites. The whitelist may be updated as new hosts, network-accessible systems, or computing systems are identified. Similarly, the whitelist may be updated over time as approved systems are added or removed.

[0098] 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. Similarly 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. Establishing a connection based on a whitelist may 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 an AMD and / or authorized AMDs for access by a cloud or network computing service, the whitelist may include any information that can facilitate access to systems identified on the whitelist. For example, the whitelist may include access information (e.g., usernames, passwords, access codes, account identifiers, port identifiers, shared secrets, public keys, etc.). It should be understood that a whitelist may include different information depending on whether the whitelist is publicly accessible, accessible only by 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.

[0099] In some cases, the AMD 600 may use a whitelist that identifies authorized cloud servers or computing systems of the cloud computing system 708, for example, via a unique identifier (e.g., via an 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 the AMD 600 and / or the cloud computing system 708 using a unique identifier. The whitelist may be stored in the memory of the AMD 600 and / or in the memory of a trusted computing device accessible by the AMD 600. A trusted computing device may include any computing device identified as trustworthy by the AMD manufacturer. Alternatively, or additionally, a trusted computing device may include any computing device identified as a trusted computing device by a 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 the AMD 600. For example, the whitelist may be configured with connection information for establishing communication with one or more computing systems of the networked computing environment. In some examples, AMD600 may be configured to execute certain computer-executable instructions to obtain at least an address of a computing system from a whitelist and to establish a direct end-to-end data connection to a computing system (e.g., a computing system in a networked computing environment) over a wireless wide area network using the address. In some embodiments, AMD600 may be configured to execute certain computer-executable instructions to receive at least a public key from a computing system of the networked computing environment.

[0100] 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 medical devices (e.g., automated blood glucose control systems or other AMDs) may 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.

[0101] However, stopping an application on a mobile medical device (AMD) from running 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 they desire or need treatment 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 used by patients 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 an application, such as the mobile medical device's control software.

[0102] 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. The application update may include binary executable files that may be executed by various processors of the AMD. The application update may be a new version of an application, a replacement or alternative application, or an application patch. Additionally, the application update may add or remove functionality from a version of the application installed on the AMD. In some examples, the application update may be an older version of an application that has been used by an instance of the AMD for more than a threshold period and has experienced less than a threshold of failures. The application being updated on the AMD may be currently running on the mobile medical device or may be running in the future. In some examples,

[0103] 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 other software companies 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 are pushed to a local computing device, for example, a patient's local computing device (e.g., a smart The file may be stored on a computer (such as a mobile phone, laptop, or personal computer).

[0104] 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 or obtain application updates. In some cases, application updates may be obtained from a content delivery network (CDN) or a cache server.

[0105] 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 memory of the AMD 600. 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, an application update availability check may be triggered by the AMD 600. The application update availability check may be performed in response to a time trigger or any other type of trigger. 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 fault, 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 contacting 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 a user or patient is authorized to access on the AMD 600.

[0106] 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. The 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, application update eligibility may be determined based on the geographic location of the device and / or the location where the device is located. The determination can be based on whether the mobile medical 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 can have a transceiver and antenna that provide GPS, text or image messaging, calling, and data transfer capabilities to the device. 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 can respond to the upgrade eligibility request by transmitting an identification of the application version, or a model identification of the AMD 600, or a manufacturing date of the AMD 600 to the host computing system.

[0107] 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).

[0108] In some examples, the AMD600 can establish a direct end-to-end data connection to a host computing system over 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 AMD600 and a host computing system without an intermediate system or computing device within the AMD600'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 including the AMD600 may be omitted. Thus, for example, the AMD600 does not communicate with smartphones, laptops, smart appliances, or other devices within the local area network of a user or patient who uses the AMD600. In some cases, the AMD600 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 the AMD600 via a local area network, a USB connection, or a near-field communication technology (e.g., Bluetooth, ZigBee, LoRa, etc.).

[0109] Once the communication connection is established in block 804, the AMD 600 may download the application update from the host computing system over 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, the application update may be acquired by the AMD 600. There may be little or no interruption to the therapy provided by the AMD600 while the treatment is in progress.

[0110] 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, WiFi, NFC, or other wireless or wired communications means). In some examples, the AMD 600 may include a SIM card or an 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 communications 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, or 5G. 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 may 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 may download the target image and transfer the image to the AMD 600.

[0111] 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.

[0112] Once the application update is obtained, in decision block 808, AMD600 may perform one or more operations (e.g., using its control and computation module 610) to verify 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, AMD600 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. Additionally, AMD600 may use a checksum, tag, payload size, or any other method to verify that the download of the application update is complete and uncorrupted. If it is determined that the download is corrupted and / or not completely downloaded, AMD600 may continue to download the corrupted version of the update. The AMD 600 may discard any unsuccessful or incomplete copies. 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.

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

[0114] In the exemplary method shown in FIG. 9 , in block 902, the AMD 600 verifies that an uncorrupted copy of the 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. A general-purpose computing system can run any number or type 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 usually 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. 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.

[0115] 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 running 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 can 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 can 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.

[0116] In 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 to install. 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.

[0117] 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 fault during the execution of an application currently running or controlling on the AMD.

[0118] 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, such as performing one or more physiological parameter measurements, may be included as part of the ongoing therapy. Once the current therapy session is completed or determined to be completed, the process may proceed to block 914.

[0119] 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 a 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 deliveries 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 dosage control signal may be generated for the next scheduled administration period. In some examples, the resume condition may be generated based on the next scheduled administration period. A dose control signal can be generated immediately or shortly after determining that an open condition has occurred.

[0120] 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 determine, or compare the estimated installation time to the estimated next therapy delivery time, in decision block 916 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 it is determined in decision block 916 that installation of the application 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 the 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 the 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.

[0121] 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.

[0122] 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.

[0123] At block 1002, 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, AMD 600 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 assigned 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.

[0124] In block 1006, the AMD 600 may confirm successful installation of the second application and wait for a trigger signal. In 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. In 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 about the update and the time required to switch between applications. In some examples, the trigger may be a user command received based on a user or patient's interaction 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 Figure 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.

[0125] 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 a 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 a 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.

[0126] 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 the 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. In some cases, the AMD 600 can determine the time or time remaining until the next treatment session. 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.

[0127] 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.

[0128] 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.

[0129] In some embodiments, the AMD 600 may receive an indication that a third application is available for download. In some such examples, the AMD 600 may download the third application using the steps and procedures described with respect to the flow diagram of Figure 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 Figure 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.

[0130] 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. When 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, when 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.

[0131] In some embodiments, the performance of an application update can be tested before switching control of the AMD 600 to the application update. FIG. 11 illustrates an exemplary method that can be used in one or more such embodiments. The AMD can 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 can 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 can be a first version of the first application having a first feature set or a second version of the first application having a second feature set. In some examples, the first feature set can be different from the second feature set but can include at least one feature included in the second feature set. In some examples, the AMD 600 can download a specific version of the second application that corresponds to a specific version of the first application. For example, there can be two versions of the first application. The first version of the first application can 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 AMD600 is configured as a monohormonal drug pump, the AMD600 may download and / or install a first version of the second application that corresponds to the first version of the first application. Alternatively, if the AMD600 is configured as a bihormonal drug pump, the AMD600 may download and / or install a second version of the second application that corresponds to the second version of the first application.Thus, depending on the version of a first application installed on AMD600, AMD600 may download and / or install a first version of a 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 an application, and AMD600 may install updates based on the installed version of the application. Additionally, in some cases, AMD600 may install different versions of an application to enable or unlock new features (or in some cases, to remove features, such as if a malfunction is discovered in a particular feature).

[0132] At 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, at 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.

[0133] In 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 the 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 executes the second application using a processor separate from the processor that executes the first application. In some examples, the AMD 600 may execute a 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 may be executed by a second controller.

[0134] 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 a medication, is below a threshold probability of administering a medication within a threshold period of time, or recently administered a medication within a threshold period of time.

[0135] At decision block 1110, the AMD 600 determines whether the second application meets 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. Optionally, if the second application does not meet the minimum set of operating conditions, the AMD 600 proceeds to block 1112, waits for an indication that a third application is available, and repeats the above procedure to evaluate the performance of the third application. If, at decision block 1110, the AMD 600 determines that the minimum set of operating conditions is met by the second application, then, at decision block 1114, the AMD may check whether a therapy is being delivered to the patient (e.g., a medication is being administered to the patient). If it is determined that a 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, at block 1114, it is determined 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 completed, 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. Subsequently, the AMD 600 may provide a 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.

[0136] 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 may 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 their 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 include a first set of functionality (e.g., insulin therapy). A first update may be a first application version including a first set of features (e.g., providing both insulin and glucagon therapy), and a second update may be a second application version including a second set of features (e.g., providing both insulin and glucagon therapy). In some such examples, the first set of features may include a subset of the second set of features. In some examples, the first set of features may include a set of features that partially overlap with the second set of features.

[0137] In some examples, a computer-implemented method may be used by AMD600 to detect, download, and install an update to an application running on AMD600, the update including one of 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. AMD600 may receive an indication of the availability of an application update, download the application update, and verify that an uncorrupted image of the application update has been successfully downloaded (e.g., using the procedure described above with reference to FIG. 8). AMD600 may then initiate an installation process for the application update image without interrupting execution of the application. In some examples, the indication received by AMD600 (block 802 of FIG. 8) may include information regarding the application update that is an update to the first application version or the second application version. In some such examples, AMD600 may determine the version of the application update and download the application update image based on the determined version.

[0138] In some embodiments, downloaded application updates 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 AMD600 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 AMD600.

[0139] 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 an 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 have been 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.

[0140] In some instances, a second application update or second version of an application installed on the AMD 600 may be older than the first application update or first version of the application. The second or older version 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 instances, the AMD 600 may revert to a second version of the application if a failure is detected in the first version of the application.

[0141] In some cases, the AMD 600 may revert to an older, stable version of the application until a third version of the application 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.

[0142] 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 a history of use and / or testing. 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 previous version of the first version, an update to the first application that addresses a detected application fault, or an older version that meets conditions to be classified 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 for 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.

[0143] In yet other embodiments, a "safe version" of the application may be installed on the AMD 600 prior to the detection of the failure. A safe version or safe copy of the application may be used by an instance of a mobile medical device for more than a threshold period of time. The safe version of the application may include a version of the application that has experienced fewer than a threshold number of failures. For example, a safe version of the application may be a two-year version of the application that has demonstrated fewer than a threshold number of failures 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 failure is detected while running the first or second version of the application, the AMD 600 may switch control of the device to the safe version of the application to maintain treatment for the patient.

[0144] 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 or safe version installed on the AMD 600.

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

[0146] 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 storage at AMD 600 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 run. 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, ethAMD 600 may begin installing the second version. Once installation of the second version is complete, the process proceeds to block 1308, where AMD 600 may switch control of AMD 600 from the secure version of the application to the second version of the application. In some embodiments, after control of AMD 600 has been switched to the second version of the application (block 1308), 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, AMD 600 may download and install the third version of the application at block 1312 and switch control of AMD 600 to the third version (block 1314).If AMD 600 cannot find the second version of the application in a memory or storage location in block 1304, then AMD 600 switches control of AMD 600 to a safe version of the application that may be installed in a memory location (e.g., main memory or storage) (block 1320) and searches for a third version of the application (block 1310). If a third version is found, the system may download and install the third version of the application (block 1312) and switch control of the device to the third version (block 1314).

[0147] 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 of AMD 600 or a user interface in communication with AMD 600.

[0148] 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's weight, CGMid, meal portion equals meal amount).

[0149] 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.

[0150] Direct network connection for medical device communication and remote viewing An ambulatory medical device (AMD), such as an ambulatory medication device (e.g., a blood glucose control system, an insulin pump (e.g., a monohormonal pump), or a bihormonal pump containing insulin and a counterregulator), a pacemaker, 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 the patient, a healthcare provider, or other users (e.g., parents or guardians) to actively manage the patient's health condition. For example, the therapy data can be useful for determining whether a modification to the therapy is desirable or for verifying that the intended therapy is being delivered at the appropriate time. In some cases, the therapy data may be used to generate an alert regarding the patient's health condition if the therapy data indicates that immediate or urgent attention is needed regarding the patient's health condition.

[0151] 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, can 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 can be different instructions executed by the CCM 610 of the AMD 600.

[0152] Accessing data from an AMD can be problematic in some cases. For example, to access the data, a user may need 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, during periods when the device is connected to a computer, the patient may not be receiving treatment from the mobile medical device. In some cases, the patient may not be able to connect the device to a 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.

[0153] 14 is a block diagram illustrating an exemplary network configuration in which AMD 1402 is directly connected to computing system 1404. 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. 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 computing system 1404 may be associated with the execution by the hardware processor of computing system 1404 of particular computer-executable instructions stored in the memory of computing system 1404.

[0154] 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 communication 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 AMD 1402's ability to communicate with the computing system 1404 may be activated during manufacturing or before providing the device to a patient.

[0155] 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 can 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 can be initiated or established without any action by the patient or user. For example, the direct end-to-end data connection can occur automatically at a specific time or when the AMD 1402 is in a specific location. This automatic connection can 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 can communicate with the computing system 1404 without access to a WiFi network or local area network (LAN). For example, the AMD 1402 can communicate using a cellular or other wide area network. Furthermore, in some cases, user interaction with the AMD 1402 can be relatively minimal or simple compared to traditional network communication. For example, a user may press a single button (eg, 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 .

[0156] 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.

[0157] Additionally, 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.

[0158] 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.

[0159] Further, establishing the direct end-to-end data connection may include determining, based at least in part on the device identifier, that the AMD 1402 is authorized to communicate with the computing system 1404. The device identifier may be initially provided to the networked computing environment prior to provisioning the AMD 1402 to a 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 manufacturing the AMD 1402.

[0160] The AMD 1402 can be configured to at least identify computing systems (or cloud servers) 1404 of a networked computing environment 1408 (e.g., a cloud network, a data storage service provider, or an application service provider, etc.) 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 AMD 1402's manufacture. For example, the whitelist may be configured with connection information for establishing communication with one or more computing systems of the networked computing environment. Furthermore, the AMD 1402 can be configured to obtain addresses of the computing systems 1404 from at least 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.

[0161] 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 other computing systems (e.g., remote display systems) that are allowed to communicate with AMD 1402 and / or the computing systems 1404 of the networked computing environment using unique identifiers.

[0162] When devices communicate data over a network, there is generally a risk of data breach. To reduce or prevent data breaches, the AMD 1402 can 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 can encrypt all data using an asymmetric key pair. In some cases, the AMD 1402 can establish a shared secret with the computing system, as described below.

[0163] In some cases, the treatment data may be encrypted before being transferred to the computing system 1404. To enable encryption, the AMD 1402 stores in memory an encryption key that enables the AMD 1402 to encrypt the data that it transmits to the computing system 1404. The AMD 1402 may have a public key and a private key associated with it. In some cases, the AMD 1402 may generate the 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 the application memory. In some cases, the AMD 1402 may transmit the 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 the therapy data generated by the computing system 1404 in response to the 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 may encrypt therapy data (and / or device data) transmitted to the computing system 1404 for storage, analysis, presentation to a user, reordering medications, determining the status of the AMD 1402 and / or the patient, or any other purpose or process that may be performed in response to the therapy data. The computing system 1404 can use the private key to decrypt the encrypted data and gain access to the treatment data (and / or device data).

[0164] 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.

[0165] Additionally, 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 therapy 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).

[0166] In some cases, the computing system 1404 may be configured to transfer or receive data stored in the AMD 1402 (e.g., therapy data or device status data) after receiving a request to transfer the data to the computing system 1404 via a direct end-to-end data connection, for example, via a wireless wide area network. The request may include a device identifier associated with the AMD 1402. In response to receiving the request to transfer the data stored in the AMD 1402 to the computing system 1404, the computing system 1404 may be configured to receive the data via the direct end-to-end data connection. In some cases, the computing system 1404 may open a port or provide a port to the AMD 1402 to enable the AMD 1402 to connect to the identified port and transfer data to the computing system 1404 via the identified port. Further, transferring the data may include the computing system 1404 sending an acknowledgment packet that the transfer request was approved or permitted. The AMD 1402 may transfer the data in response to approval 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 (eg, username and / or password, etc.).

[0167] In some examples, once a connection is established and treatment data is transferred to the computing system 1404, the computing system 1404 can analyze the treatment data received from the AMD 1402 and generate a treatment report. The treatment report may include information about the patient's disease, treatment by the AMD 1402, anonymous comparisons with other patients, statistical data about the patient's treatment, and information about other patients' diseases or disease management. The therapy report may include data regarding the patient's blood glucose levels, statistical data regarding the patient's blood glucose levels, and the like. For example, the therapy report may 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 may detect alarm conditions based on therapy data analysis and generate alerts that may be provided to the patient's authorized user (e.g., a healthcare provider). In some cases, the therapy data may trigger an automatic response by the computing system 1404. For example, the AMD 1402 may determine that a medication or another disposable is low based on the received data and automatically reorder the medication or disposable.

[0168] In some cases, the computing system 1404 may periodically receive data (e.g., treatment 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 connection to 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 the data is generated or shortly thereafter (e.g., in real time or near real time (e.g., within milliseconds, seconds, or minutes of the generated data)), or in bulk over a specified period of time. Sending data in bulk over a specific period of time can extend battery life but may provide out-of-date analysis. When bulk transfers of data occur over a specific period of time, 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.

[0169] In some cases, the computing system 1404 may be used as a backup for the AMD 1402. For example, the AMD 1402 can 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 can upload data that a doctor can access to treat the patient's ailment). Additionally, if the AMD 1402 is replaced (e.g., for a new model or to replace a damaged device), the device can automatically synchronize with the computing system 1404 to retrieve patient-specific configuration or therapy control data.

[0170] Treatment Data and Treatment Reports In some examples, the treatment data includes dose or administration data corresponding to one or more doses of a medication provided to the patient by the AMD 1402. Additionally, the 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).

[0171] In some examples, the data provided to the computing system 1404 may include any type of data that may be measured or obtained by the AMD 1402, and may include a record of 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.

[0172] 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).

[0173] 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.

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

[0175] 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.

[0176] In some examples, treatment data collected from different AMDs associated with multiple patients may be aggregated for a group of patients. Aggregation may be based on any factor or commonality between multiple patients. For example, treatment data may be aggregated based on association with a facility or organization (e.g., clinic, insurance company, etc.), age, gender, nationality, ethnicity, job, stressors, recentness of diagnosis or acquisition of the disease, 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 specific patients within a group, how to improve care for a set of patients, how to learn more about how diabetes affects specific types of patients, etc.

[0177] 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 data collected by the ambulatory medical device over a specified period of time. The data may include time series therapy data regarding the therapy delivered by the device.

[0178] 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.

[0179] In some cases, the mobile device data and / or data generated by the computing system 1404 based on the mobile device data may be viewable from the 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).

[0180] The association between the patient, clinic, and / or mobile medical device may be performed by associating the device serial number of the mobile medical device with the patient and / or clinic. Additionally, a user (e.g., a patient, clinician, or parent) may access treatment recommendations via the cloud if either the mobile medical device (e.g., insulin pump) or CGM sensor fails.

[0181] 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 in the AMD. In some cases, the display system may be a 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.

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

[0183] In some examples, a request to access treatment data, treatment reports, or other data may include an account identifier associated with a 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 of 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 the treatment data, treatment reports, or other data through the networked computing environment 1408, e.g., a cloud service associated with the patient. A user may access an account on a cloud network provided by the service provider and provide one or more identifiers associated with one or more other users to grant permission to access patient treatment data or reports stored on the computing system 1404.

[0184] 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, the encrypted communication channel can be created by using an asymmetric key pair to encrypt the data to be 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.

[0185] In some cases, the method may include receiving identification information 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 wants access to 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.

[0186] 15A is a flow diagram illustrating an example method that may be used by the computing system 1404 to generate and share a treatment report based on treatment data received from the AMD 1402. In some examples, the AMD 1402 may encrypt the treatment data using a public key and / or a shared private key. The encrypted treatment 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).

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

[0188] 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., treatment 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 data (e.g., treatment 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.

[0189] 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, one of 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 treatment data sent to the computing system 1404. Alternatively, or additionally, the computing system 1404 may use the public key received from the AMD 1402 to encrypt a treatment report based on treatment data to be sent to the AMD 1402 or other data acquired by the computing system 1404.

[0190] 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.

[0191] If it is determined that the AMD 1402 is authorized to transfer data to the computing system 1404, the computing system 1404 may receive 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.

[0192] 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 was 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.

[0193] In block 1514, the computing system 1404 may decrypt the encrypted treatment 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 The system 1404 can decrypt the encrypted treatment data using a shared secret generated between the computing system 1404 and the AMD 1402 .

[0194] At block 1516, the computing system 1404 may generate a treatment report using the treatment data received from the ethAMD 1402. In some examples, the decrypted 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.

[0195] 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 in 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 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 can authenticate with the computing system 1404 before receiving the treatment report.

[0196] 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.

[0197] 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 account 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.

[0198] 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 may transmit the treatment report to the display system 1410. The treatment report may 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 may 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 a treatment report (e.g., as part of block 1518), the computing system 1404 may request a public key from the display system 1410 and may encrypt the treatment report using the received public key. In some such examples, the display device 1410 may use a private key to decrypt the encrypted treatment report received from the computing system 1404. This private key may correspond to a public key provided to the computing system 1404 by the display system. In some examples, the display device 1410 may use a public key to decrypt the encrypted treatment report received from the computing system 1404. The spray system may be an AMD 1402. In some such examples, a patient or authorized user may view treatment reports received from the computing system 1404 on a user interface (e.g., a touch screen display) of the AMD 1402.

[0199] In particular implementations, 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 services provider, or a user device of any other authorized user associated with the patient.

[0200] 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.

[0201] In some examples, the alert threshold condition may be associated with 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.

[0202] 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 a patient's physiological parameters or characteristics.

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

[0204] 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.

[0205] In block 1532, the AMD 1402 receives the computation system obtained from the whitelist. The address of the computing system 1404 may be used to establish a direct end-to-end data connection to the computing system 1404. 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 over one or more communication standards, such as a Low Power Wide Area Network (LPWAN) communication standard, a Narrowband Long Term Evolution (NB-LTE) standard, a Narrowband Internet of Things (NB-IoT) standard, or a Long Term Evolution Machine Type Communication (LTE-MTC) standard. In some such embodiments, the transceiver may be configured to communicate over the wireless wide area network using the address. In some examples, a direct end-to-end data connection to the computing system 1404 can be established by sending a connection request to the computing system 1404. In some such examples, the connection request can include a device identifier of the AMD 1402.

[0206] At block 1534, the AMD 1402 may receive a public key from the computing system 1404. At block 1536, the AMD 1402 may encrypt treatment data associated with a treatment 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 treatment data based at least in part on a shared secret generated based on an asymmetric key pair (e.g., a public key and a private key) of the AMD 1402 and an asymmetric key pair of the computing system 1404. For example, the shared secret may be generated using a Diffie-Hellman key exchange.

[0207] 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, a new secure channel may be established using a new asymmetric key pair once the additional therapy data is acquired. 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 an operation of the mobile medical device and the error data corresponds to an error in the operation of the AMD 1402.

[0208] In various embodiments, the computing system 1404 that performs the steps described with respect to Figures 15A and 15B can 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.

[0209] In some embodiments, the AMD 1402 is 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.

[0210] 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.

[0211] In some cases, the one or more display systems 1610 receiving the alert 1611 may be display systems that previously received the 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., doctor, 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 received data from AMD 1602 is determined to meet a threshold condition, an alert may be sent to one or more display systems 1610 (e.g., alert 1611) and / or AMD 1602 (e.g., alert 1609).

[0212] 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.

[0213] In some examples, geolocation sensors (e.g., a global positioning system (GPS) receiver) and / or proximity sensors may be used to enable location-triggered functionality such as automatic uploading of data at a specific location.

[0214] In some cases, the AMD 1602 may include, communicate with, or connect or interface 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 a 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 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 computing system 1604 may provide the patient's location to the emergency services provider 1618. In some cases, the AMD's determined speed 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 the 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 the 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, the determination of the patient's movement can be used to automatically adjust the rate of therapy delivery (e.g., to increase blood glucose levels that trigger therapy delivery).

[0215] 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.

[0216] 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 call 911 in the event of a detected emergency. The computing system 1604 can track the end user's most recent location, for example, 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.

[0217] 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).

[0218] 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.

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

[0220] At 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.

[0221] 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.

[0222] 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.

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

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

[0225] At 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 that is provided to the AMD 1602 to encrypt the therapy data. This private key may be stored in memory of the computing system 1604. Block 1714 may include one or more of the embodiments described with respect to block 1514.

[0226] In block 1716, the computing system 1604 processes the received data (e.g., treatment data). The computing system 1404 may determine whether therapy data or other data received from the AMD 1402 meets a threshold condition based at least in part on the patient's 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.

[0227] 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 have been 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 an account ID for 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.

[0228] 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 the medication to the patient. In some cases, the AMD may be a mobile medication device. The user may be a patient receiving a 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, an AMD may have settings accidentally changed due to inadvertent interaction with the user interface, such as may occur when the AMD is worn on a patient's body.

[0229] An 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.

[0230] As described above, in some embodiments, a user can 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).

[0231] Referring to FIG. 18, in some embodiments, the control and computation module ( The control and computation module (CCM) 610 may include a set of therapy change procedures implemented to prevent inadvertent therapy change input 1829. The therapy change procedures implemented 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 executed by the control and computation module (CCM) 610 or one or more of the controllers (e.g., controllers 1830-1836) implemented by the CCM 610.

[0232] The user interface module 1808 may include any type of user interface controller for providing a user interface. The user interface may be provided on a display of the AMD 600 or transmitted to a display of an electronic device in communication with the AMD 600. In some cases, the user interface controller may be a touchscreen controller configured to output display signals configured to generate one or more user interface screens on a touchscreen. Additionally, the touchscreen controller may be configured to receive user input signals corresponding to user interaction with the touchscreen.

[0233] 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 waking up the touchscreen interface or presenting a lock screen to the user. Additionally, waking up the AMD may include waking up 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 predetermined 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 may 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 may be or include a biometric element such as a fingerprint reader, iris scanner, or face detection scanner. In some cases, the AMD may wake up in response to a specific motion or detection of 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 may wake the AMD or cause the AMD to wake its touch screen interface. The AMD may 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.

[0234] In some examples, therapy change input 1829 may be 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 change a therapy delivery at a future point in time. In some examples, the therapy change input 1829 can change the insulin or glucagon infusion rate to the user 1827. The therapy change input 1829 can also cancel insulin or glucagon infusion from an insulin or glucagon infusion pump to the user 1827. In some cases, the 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.

[0235] In some cases, when a wake action 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 a user interface (e.g., a touch screen display). In some cases, the CCM 610 can execute the wake procedure using the wake controller 1834.

[0236] 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.

[0237] 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 relates 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.

[0238] 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 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 may be a complex interaction (e.g., a series of complex gestures) that unlocks the therapy change user interface with unlimited therapy change selections. One example of this implementation may be useful for child users. A child user may unlock the limited therapy change selections. An adult user can perform a first or simpler gesture consisting of a series of simple inputs to unlock a therapy change user interface with unlimited therapy change selections. An adult user can perform a second or more complex gesture consisting of a series of complex inputs to unlock a therapy change user interface with unlimited therapy change selections.

[0239] When activated, the therapy change user interface generated by the user interface module 1808 can provide one or more therapy control elements that enable 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 the one or more hormones that regulate the user's blood glucose levels, delivery rates of the one or more hormones, thresholds for determining when to deliver the one or more hormones, changes in the estimated blood absorption rates of the 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.

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

[0241] This confirmation may be entered based on a second user interaction with the user interface (e.g., touch screen display 1824). If 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.

[0242] 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), 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 inputs 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, a series of inputs may last for more than or equal to 3 seconds, up to 15 seconds. or may need to be entered in less than 15 seconds.

[0243] Additionally, 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.

[0244] 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.

[0245] In some examples, the system can 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 begin 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.

[0246] In some embodiments, once a change or modification to a treatment setting (e.g., a change to a control parameter or configuration of the AMD) is confirmed, implemented, or transmitted, the AMD may begin operating based on the modified settings selected and / or provided by the user.

[0247] 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.

[0248] 18 , in some embodiments, changes made via the therapy change user interface are sent to the CCM, and a therapy control change procedure 1836 in the CCM 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 a therapy change 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 the 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 is administered based on a detected condition or physiological characteristic of the patient (e.g., provided by readings of the patient sensor 1820). The control may be generated based at least in part on and in accordance with parameter values ​​received from the therapy change control procedure 1836. The medication delivery interface 1806 may provide therapy change delivery to the user in accordance with information received by the device and patient monitoring procedure 1832.

[0249] In some examples, the dose control signal may be generated based on time (e.g., the drug 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 may cause the initiation of treatment (e.g., drug delivery).

[0250] 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, the 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.

[0251] 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 enter 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 enter 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 enter a locked state. Thus, the user may have a limited period of time to change the configuration of the AMD.

[0252] 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, which may occur a set time after confirmation is received.

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

[0254] FIG. 20A is a diagram of an exemplary AMD touch screen display 2000 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 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 to inform the user 1827 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 in the touch screen display 2000 indicates that an alarm has been set on the AMD 600.

[0255] FIG. 20B is a diagram of an exemplary touchscreen 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 touchscreen display 2050 can display touchable numeric keys 2055. In various embodiments, the touchscreen 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 touchscreen 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 be paired with another electronic device.

[0256] 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 a user 1827 to select one or more hormones for regulating a 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 choice 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, the user can select a "next" button 2014 to complete the therapy change selection. In some examples, 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 embodiments, the therapy modification user interface prompts the user 1827 to select a target blood glucose level, and the AMD device automatically selects a hormone (or combination of hormones) and administers a therapy session to maintain blood glucose levels at or within a margin of the target level. The amount of one or more selected hormones to be delivered during the treatment can be determined.

[0257] FIG. 20D is a diagram of another example of a user interface on the touch screen display 2016 that supports a therapy change by a user 1827. Here, the user 1827 is presented with a number of choices. One or more options in 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.). A "Deliver Hormones" button 2030 allows the user 1827 to select a therapy change that delivers a blood glucose-regulating hormone to the user 1827. A "Test Blood Glucose" button 2018 allows the user 1827 to test the user's 1827 blood glucose level. A "Generate Report" button 2020 generates a document reporting the therapy change delivered to the user 1827. A "Refill Cartridge" button 2022 allows the user 1827 to fill a cartridge in the AMD device 600 with medication. A "Upload to Cloud" button 2026 allows the user 1827 to send therapy change information to a cloud-based server. A "Voice Control" button 2024 allows the user 1827 to control the sounds emitted by the AMD 600. A "Settings" button 2028 allows the user 1827 to manipulate one or more other settings of the AMD 600.

[0258] As mentioned 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.

[0259] For example, referring to FIG. 18 , a user 1827 can 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 can 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 alarm indicator can 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, an alarm status indicator may be displayed after a user unlocks or activates the user interface using a wake action. In some examples, an alarm status indicator may be displayed on the user interface when the user interface is inactive or locked.

[0260] 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) initiates a wake signal on the touch screen in block 2112. A display of a lock screen interface may be generated, and one or more alarm status indicators corresponding to the detected alarm condition may be displayed on the lock screen 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 a 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 the AMD and performs a wake interaction to cause the user interface screens to be presented.

[0261] In some cases, additional status information may be received by the AMD at some point after the previous status information that met an 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, an 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 the AMD's touchscreen, lockscreen, or interface. 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.

[0262] In some embodiments, the AMD may allow a user to provide a therapy change and then cancel the therapy change. The user can 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 can 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 can 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 2208 (e.g., a second gesture). 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 can 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 near 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 on 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 user interface screen that is different from 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 modifications to a therapy control element.

[0263] In some examples, a restore gesture must be provided within a set time period 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 within 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.

[0264] 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.

[0265] 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.

[0266] In some examples, the user may be able to cancel the therapy change delivery after confirming the therapy change and before 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.

[0267] 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 a user interface and provide a gesture to cancel an ongoing therapy delivery based on the therapy change delivery.

[0268] FIG. 23B is an illustration of the touch screen display 2350 showing that medication is being delivered to the user 1827. The "Delivering" text 2355 informs the user 1827 that medication is currently being delivered to the user 1827. The progress bar 2360 is a graphical representation of the progress of the delivery. As shown in FIG. 23B, the delivery has only begun and progress is not complete. The touch screen display 2350 allows the user 1827 to perform a gesture to cancel the delivery, which includes pausing and stopping the delivery if it has already started but not yet completed. The gesture to cancel delivery is a touch action starting from the small symbol 2365 and swiping left across the "Cancel" text. In some embodiments, the therapy change delivery 1807 can be performed by using a The touchscreen may be cancelled by user input, including a click action followed by a series of touch inputs (e.g., gestures, alphanumeric input, etc.).

[0269] 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 PHARMACY" and "PREVENTING INADVERTENT PHARMACY" 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. 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.

[0270] Automatic resumption of drug delivery after manual suspension In some cases, it may be desirable to suspend operation of an ambulatory medication device (AMD) or at least one delivery of one or more medications to a patient by the AMD for a certain period of time. For example, it may be desirable to suspend operations related to medication delivery when a medication reservoir or cartridge in the AMD is empty or needs to be replaced. As another example, it may be desirable to suspend medication delivery when the ambulatory medication device is removed or moved to another site on the patient. In yet another example, it may be desirable to suspend medication delivery if the patient is taking or ingesting another medication that may be contraindicated with the medication provided by the AMD. In some cases, when a patient suspends a therapy delivered by an AMD, the patient may forget to resume the therapy delivered by the AMD. In some cases, the patient's health condition may deteriorate during the suspension period, requiring therapy 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 therapy for a temporary period of time (e.g., a temporary suspension period) and can automatically resume medication delivery when necessary. Suspending medication delivery may include a processor in the AMD not generating a dose control signal during the temporary suspension period.

[0271] In some embodiments, the AMD can support treatment suspension and resumption procedures that allow a user (e.g., a 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 can be a monohormonal insulin pump. In some other embodiments, the AMD can be a bihormonal pump capable of administering insulin and a counterregulatory agent (e.g., glucagon).

[0272] 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 a 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.

[0273] 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. Suspension of insulin delivery can prevent patients from entering a hypoglycemic state (extreme hypoglycemia), which can lead to severe complications. If treatment is interrupted and the user forgets to resume drug delivery after exercise, the user may be at risk of entering a hyperglycemic state (hyperglycemia, which can lead to complications such as diabetic ketoacidosis or neurovascular complications). Furthermore, the patient's blood glucose levels may rise above or below dangerous levels during periods of exercise. In these situations, automatic drug delivery resumption may improve the patient's health.

[0274] In certain cases, the AMD can suspend one or more therapy deliveries when the AMD receives an instruction that the therapy (e.g., medication delivery) should be suspended. The instruction that the therapy 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 say or interest in the patient's care. For example, the user may be a clinician or other healthcare provider, or a parent or guardian.

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

[0276] 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 can 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 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.

[0277] 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 the user interface module 2408, e.g., having 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 the device and patient monitoring and control procedure 2432. In some examples, the AMD may generate a warning before interrupting delivery of medication to a patient. The warning may indicate the interruption start time at which delivery of medication will be interrupted. In some embodiments, to prevent inadvertent therapy interruption request input 2429, the therapy interruption control procedure 2436 may receive a therapy interruption request 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). The method may include a treatment interruption request verification procedure for verifying a received treatment interruption request.

[0278] 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 drug dose control procedure 2430 indicating that no dose control signals should be sent to the drug delivery interface 2406 during the period requested by the user 2427.

[0279] 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 upon a time request 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.

[0280] 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, the dose control signal may be generated for the next scheduled administration period. In some examples, the 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 glucose level 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).

[0281] 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 about 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 the first and second interactions with the user interface are both verified by therapy interruption control procedure 2436.

[0282] 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.

[0283] 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 therapy interruption, thresholds required to define threshold conditions that may trigger early resumption of therapy delivery, etc. In some examples, the interruption information may indicate that the therapy 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 the patient sensor 2420 or other type of sensor that may be used to monitor one or more parameters related to the health status of the user 2427.

[0284] The parameters of 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, multiple conditions may be included in the pause information received from the user. 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 be terminated earlier than the set time.

[0285] 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 resumption condition (e.g., no user action or no user action to trigger the resumption condition). 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, the resumption 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.

[0286] 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 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 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 parameter range of an input 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 at which a series of inputs is entered may be part of a parameter range. For example, a series of inputs may need to be entered in greater than or equal to 3 seconds, or greater 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.

[0287] Further, 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.

[0288] 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.

[0289] In an exemplary embodiment, the system may have a timeout such that 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 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.

[0290] 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 a 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.

[0291] In some examples, when a wake action is received 2502, the AMD may automatically launch 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 such an example, once therapy delivery has been interrupted, a second gesture can stop the interruption before any of the conditions of the stop parameters are met, allowing the user the versatility to modify the initiated interruption.

[0292] FIG. 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 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. A 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 lull period). The AMD 600 can 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 (eg, 1 hour and 2 hours).

[0293] Once the user 2427 selects a duration on the pause screen 2604, a 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, drug delivery will suspend 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 encouraged 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 2612 the AMD if the user wishes to end the pause and / or access other features of the AMD 600.

[0294] 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.

[0295] In some cases, the AMD may not immediately suspend therapy upon receiving a command to suspend therapy. For example, if the AMD is in the process of delivering medication or if the patient's condition indicates that medication may soon be needed to maintain the patient's condition (e.g., blood glucose) within a certain state (e.g., within a desired blood glucose range), the suspension of therapy may be delayed until at least the time when medication is not being delivered or is predicted not to be needed during the suspension period, or until the next therapy is being delivered. In some such cases, the AMD may notify the user that the suspension 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 replacing a medication cartridge, the user may override an indication that the suspension of therapy should be delayed, for example, to the suspension start time. In some cases, the requested start time may be overridden by a patient-determined condition. The AMD may delay the suspension of medication delivery in response to determining that the patient's condition meets a threshold condition.

[0296] 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.

[0297] 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), the AMD device detecting a condition (e.g., a medication is refilled), a patient condition meeting a specific criterion (e.g., a patient's blood glucose level falls below or exceeds a threshold range), or any other condition that satisfies a reason for or overrides a request for treatment suspension. 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 the 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," an exercise-sensing event, the suspension of other administered medications, the conclusion of an undefined suspension length (e.g., during a cartridge change), a speed-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 condition may include a combination of criteria.

[0298] In some cases, automatically resuming treatment may include suspending treatment before the expiration of the suspension period, e.g., treatment may be resumed if the condition that caused treatment to be suspended is resolved before the expiration of the suspension period.

[0299] 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 a problem with the refill (e.g., the cartridge is not installed properly), the AMD may continue to maintain the suspension of therapy despite a trigger to resume therapy.

[0300] 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, a therapy suspension control procedure 2436 may suspend a drug dosage control procedure 2430 using a 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., using the drug dosage control procedure 2430).

[0301] If the therapy interruption control procedure 2436 determines 2708 that the time elapsed since the interruption began 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.

[0302] 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 treatment delivery can be safely resumed, one or more interrupted treatments are resumed 2712.

[0303] In some examples, if a third interaction with the user interface (e.g., a gesture) is detected, the 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 dose procedure 2430. This allows the user the flexibility to terminate an activated pause for a pause period set by the user prior to confirmation (second interaction with the user interface). In some cases, the user may decide to terminate the treatment interruption 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 the 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.

[0304] 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 drug 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 of the user's blood meets or exceeds a threshold value.

[0305] Screen 2804 can be activated by user interaction (e.g., a gesture on a touch screen display) to allow the user 2427 to select and perform various functions on the AMD 600. For example, resume button 2805 can be used to end a therapy pause. When resume button 2805 is selected by the user, resume screen 2806 can be displayed on the touch screen display. Resume screen 2806 has a prompt 2807 that prompts the user 2427 to perform a gesture. In the illustrated example, the 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 the user 2427 from inadvertently resuming medication delivery by the AMD.

[0306] Once the user 2427 performs a gesture to resume drug delivery, a resume screen 2808 appears on the display, indicating that the treatment pause has ended and normal drug 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 drug delivery.

[0307] Referring to FIG. 24 , in some examples, if the treatment interruption procedure 2436 determines that the resume condition has been met or receives user input 2429 from the user interface module 2408 indicating that the treatment interruption should end, they may use a device and patient monitoring and control procedure 2432 to initiate a drug dosage procedure 2430. Thereafter, if the drug dose 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 restart condition has occurred as discussed herein, the dose control signal can be generated at the next scheduled administration period. In some examples, the dose control signal can be generated immediately after determining that a restart condition has occurred.

[0308] 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).

[0309] Additional embodiments relating to suspending drug delivery to a patient that can be combined with one or more embodiments of the present disclosure are described in U.S. Pat. No. 6,619,523, filed on October 4, 2019, entitled "METHOD FOR SUSPENDING DELIVERY OF A DRUG INFUSION." 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.

[0310] 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).

[0311] In many cases, healthcare providers can change the settings of an 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 an AMD is when the AMD's initial settings are not providing the desired effect (e.g., delivering enough medication, too much medication, medication too slowly or too quickly, etc.). In some cases, maintaining the AMD and / or patient's health 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 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.) The change in location may require interaction with the AMD's settings (e.g., pausing operation until the field change is complete).

[0312] 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 harm the patient. Furthermore, it may be undesirable for certain patients with reduced mental capacity, regardless of age, to access at least some of the AMD settings.

[0313] 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.

[0314] One solution to regulating access to AMD 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 certain 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.

[0315] 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 off the lock feature. Once the lock feature is activated, the user can program the AMD with a user passcode selected by the user. Alternatively, or in addition, the 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.

[0316] In some cases, the user interface elements used to access a user interface that allows changing one or more settings of the AMD 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.

[0317] 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 visual prompt to unlock the device may be displayed. When a visual guide (e.g., a linear unlock slider, an arcuate unlock slider, or another unlock user interface element) is activated, a passcode entry interface (e.g., a keypad user interface element) may be displayed. If either the user passcode or 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.

[0318] 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, such as 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, after a user interface (e.g., a touchscreen display) is activated, a first gesture may be required before the multiple user-selectable elements are presented.

[0319] 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, no matter who sets the passcode, there is a risk that the user will not remember the passcode. Due to the nature of the device (e.g., a device capable of providing life-saving care), it is desirable that certain users are not restricted from accessing certain settings of the AMD and be able to gain access to certain settings quickly (e.g., within seconds, minutes, before the next treatment event, or before harm to the patient may occur) 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.

[0320] 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 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. One example of a complex gesture is a swipe.

[0321] In some examples, the passcode or override passcode may include performing a pattern or sequence on a touchscreen (e.g., drawing an image), a multi-touch interaction, or any other type of interaction with a 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.

[0322] In some examples, the AMD may be configured to receive treatment settings or changes to treatment settings from an intermediate device via a communications connection. For example, the intermediate device may be a laptop or desktop computer, a smartwatch, or the like that may be configured to interact with the AMD. The intermediate device may be a touch, smartphone, or hardware control device. In some cases, this functionality may be supported in addition to providing the user with the option to change one or more settings using the AMD's user interface. The communication connection between the intermediate device and the AMD may be a direct connection, for example, 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 the 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 through the intermediate device may be different from the passcode required to change the same settings using the AMD's user interface directly.

[0323] In some such cases, the user may provide a user-generated or override passcode through an interface of the intermediate device, which may then provide the user-generated or override passcode to the AMD via a network connection between the devices.

[0324] In some examples, even when the AMD is in a locked state, certain intermediary devices may have access to a user interface that may 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.

[0325] 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.

[0326] 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 (e.g., a smartphone, laptop, personal computer, etc.) connected to the computing system 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.

[0327] If a user cannot remember the user passcode, the user can gain access to a user interface that allows modification of control parameters by supplying 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 on the AMD at the time of manufacture, may be shared among multiple AMDs (e.g., a global override passcode), or may be unique to a particular AMD. The override passcode may be managed by the manufacturer or a third-party service. To obtain the override passcode, the user may contact the manufacturer or a passcode management service. In general, a passcode may be enabled to prevent users with reduced mental capacity (e.g., children) from modifying the settings of the AMD. Thus, security is not as important, and the user can contact the manufacturer or a passcode management service to obtain an 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 the AMD may have a different override passcode. The user can provide authorization information and the serial number of the mobile medication device to the manufacturer or a passcode management service to obtain an override passcode.

[0328] 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.

[0329] 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, or every hour. 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 to 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 the AMD, a computer server, and / or an application on the user device.

[0330] In some cases, the override passcode may be received automatically by the AMD (e.g., after a user requests an 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.

[0331] In some cases, the override passcode may be linked to a location. The override passcode may only be enterable at the healthcare provider's office or 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)).

[0332] 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 (discussed above).

[0333] As described above, by interacting with a user interface, the AMD, or other device capable of modifying control of the AMD, can present a passcode entry screen to the user. The user can 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 can be modified based on interaction with a parameter control element of the user interface. Furthermore, modifying the control parameter can 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.

[0334] 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. The 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 screens or states. An advanced therapy screen (e.g., displaying the advanced settings of the AMD) may allow a healthcare provider to change control parameters (e.g., advanced control parameters via one or more advanced parameter control elements) that may not be modifiable by other users. For example, a healthcare provider may be able to change the rate of insulin accumulation, the rate at which insulin decreases in the patient's blood, set glucose set points, when the patient's glucose level is outside of a set range, or when insulin reaches a maximum concentration point in the patient's blood (e.g., T max The parameters for calculating the treatment aggression level or factor for the amount of insulin provided when the ATP level is reached can be controlled.

[0335] Access to 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 a separate passcode 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, the clinician passcode is , 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 a clinician's access at any time.

[0336] In some cases, access to an advanced therapy screen or state may be limited for 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.

[0337] In some cases, the advanced therapy screen can offer additional features. For example, the user can indicate that the amount of insulin provided should be more or less for a meal or correction factor, while the healthcare provider can specifically adjust the amount of insulin. Furthermore, 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.

[0338] In some cases, the manufacturer of the AMD may provide a remote unlock signal that can be used to unlock access to advanced therapy screens or states of the mobile medication device and / or the AMD.

[0339] 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 locked. 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 certain 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.

[0340] 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.

[0341] 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 modifying 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 a specific number of attempts within a specific period of time to enter a user passcode. 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 is turned off). The user interface may enter a lock (becoming locked) 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 be accessible only if an override passcode is provided. Alternatively or additionally, a user passcode for a different user may be used to provide access to the AMD's control parameters. In some examples, if the correct override passcode is not entered within a provided number of attempts or within a certain period of time, the user interface may block any attempts to change the override passcode for at least a certain period of time.

[0342] In some cases, once the passcode is successfully entered or verified, the user can disable the AMD's passcode feature, which may require the use of a separate or override passcode in addition to the user passcode.

[0343] In some cases, the 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 a global positioning system (GPS).

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

[0345] AMD example with passcode 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 passcode protected. 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 the alphanumeric pad 2926). Alternatively or additionally, the user 2927 may provide a security code for passcode entry 2946 using an intermediate device 2923 (e.g., laptop, smartphone, etc.) connected to the AMD (e.g., via a wired or wireless link). In some examples, once the security code or override security code is received (e.g., via the intermediate device 2923 or interface module 2908), the security code may be sent to the AMD's control and computing unit, 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.

[0346] 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 changed, and may be considered advanced settings as described herein, requiring a different passcode to access from a passcode, e.g., one or more setting control screens 2940 / 2942 / 2944 and / or parameter control elements 2941 / 2943 / 2945. The setting change procedure can be machine-readable instructions stored on an AMD and executed by one or more hardware processors.

[0347] In some examples, the option to provide a security code corresponding to the passcode may become available when the user 2927 performs a wake action on the wake interface 2923, which may include a user input element associated with recognition of the wake action or some other user interaction. In these examples, if the CCM's wake control module 2934 determines that a valid wake action 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 touchscreen display. In some examples, a first screen presented on the touchscreen display may provide other selectable elements, including elements for changing the AMD's settings. In such examples, selecting an element associated with a setting change may launch a second screen presenting selectable elements associated with the settings control screen 2940 / 2942 / 2944.

[0348] When the lock function 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 of the 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 the 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 a parameter control element 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.

[0349] 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 settings on 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, a user interface can be launched (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 setting change interface 3004 (e.g., a setting 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 setting change interface. In some examples, a specific wake operation can launch the setting change interface.

[0350] In some cases, for example, in a settings change interface or another user interface, the AMD and / or intermediate device (e.g., a settings 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 settings change procedure in a CCM) and / or intermediate device may determine whether the security code matches a user-generated passcode 3008. If it is determined that the security code matches 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 it is determined that the security code matches 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 it is determined that the security code does not match the override passcode, the AMD and / or intermediate device denies access to one or more passcode-protected parameter control elements 3016 .

[0351] 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 AMD settings using a user-generated passcode 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 the user can provide a first gesture to activate a settings change interface or screen. When a first gesture is received from the 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 due to 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 request for a setting change may include selecting a list of parameter control elements (e.g., contained on a separate screen provided on a touch screen display).

[0352] 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 change 3118 the one or more settings in accordance with the requested and confirmed change.

[0353] 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 also 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 3130 the second gesture, the AMD and / or intermediate device may modify 3132 one or more settings according to the requested and confirmed changes.

[0354] 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 alert 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 alert until the condition that generated the alert is resolved. Furthermore, it is desirable to issue different types of alerts for different conditions so that the patient or user can easily distinguish the severity of the condition that triggered the alert. The user may be the patient receiving the medication or treatment, or may be another user, such as a clinician or healthcare provider, or a parent or guardian.

[0355] 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 the patient and generate an alert when the detected condition is determined to meet an alert condition.

[0356] As discussed above, the ambulatory medication device may include a monitoring system for the ambulatory medication device and / or the patient. and an alarm system configured to generate an alarm when it is determined that a condition satisfying an alarm condition has been detected. In some examples, the alarm system can compile a list of alarms, notify a user of these alarms, and allow the user to acknowledge the alarms.

[0357] 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.

[0358] 32 , in some embodiments, the alarm system 3222 implements alarm control procedures within the control and computation 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 alert 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.

[0359] 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.

[0360] In some examples, the device sensors 3224 are sensors that generate signals or status values ​​related to the status of a module, interface, accessory, or disposable of the AMD. In some examples, the device sensors 3224 can generate signals corresponding to parameters related to components within a module or interface. For example, one device sensor can record the voltage of a battery, while another device sensor can record the tracking speed of pumping the drug delivery interface 3206.

[0361] In some examples, the patient sensors 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 levels, serum levels of various hormones or other analytes). In some such examples, the patient sensors may be continuous glucose monitoring sensors (CGS). The device and patient monitoring system interface 3226 may continuously receive and analyze signals from the device sensors 3224 and the patient sensors 3220 to determine the status of the AMD, the patient, the sensors, and / or other accessories.

[0362] In some cases, a single sensor can 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 condition of the CGM meets an alarm condition (e.g., to alert the user that the CGM should be replaced).

[0363] 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.

[0364] 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 the alarms when the AMD is in a locked state.

[0365] 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. One 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.

[0366] 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 can place it in an appropriate queue, for example, based on severity or category. In one or more embodiments, a list of alarms can be generated, and the alarms can be sorted numerically in descending order with the highest priority faults displayed at the top.

[0367] 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.

[0368] 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 annunciation 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 annunciation and control system 3228 can provide status information received from the monitoring system 3226 ... The system is configured to determine whether an alarm condition is met based at least in part on the received status information.

[0369] Determining whether an alarm condition is met may include comparing one or more state 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 state 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,

[0370] Each alarm profile may indicate an AMD and / or patient characteristic or condition 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.

[0371] Some non-limiting examples of AMD or patient conditions that may be associated with an alarm 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, haptic 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 alarm.

[0372] In some cases, each alarm profile may be associated with a severity level for the alarm. The severity level may relate to how urgently the condition that triggered the alarm should be addressed or resolved. Additionally, the severity level may relate to the amount of harm that could be caused to the patient if the condition that triggered the alarm is not or will not be 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 numbers of 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.

[0373] 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.

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

[0375] Generally, if an alarm condition does not prevent the AMD from providing therapy, the AMD can 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 a 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.

[0376] Alarm notification When an alarm condition is met, the alarm annunciation and control system 3228 can implement an annunciation pattern selected based at least in part on status information generated by and / or received from the monitoring system 3226. The annunciation pattern can be selected from a plurality of annunciation patterns based at least in part on the alarm condition and / or the status information. The annunciation 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.

[0377] 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.

[0378] 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.

[0379] In some examples, the alarm system may generate a list of pending alarm conditions and store it in the memory of the AMD (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.

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

[0381] In some examples, the alarm system can annunciate an alarm condition via the user interface module 3208 of the AMD 600. For example, the alarm condition may be annunciated 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.

[0382] In some examples, the alarm condition may be transmitted to other devices via the AMD's communications module 3202, for example, allowing an authorized user (e.g., a guardian or parent of the patient), the patient, or an emergency provider to view the alarm condition. In some examples, the alarm annunciation and control system 3228 can 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.

[0383] Based on the severity of the alarm condition and / or the alarm profile corresponding to the alarm condition, an alarm associated with the severity of the alarm condition and / or the 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 be an audible alarm having a volume above a particular decibel level (e.g., above 70 or 80 decibels), an audio alert with a particular brightness value (e.g., above 10 decibels), or an audio alert with a volume above a particular brightness value (e.g., above 10 decibels). 5 or 10 6 The severity levels may include a visual alarm (e.g., a flashing or steady light) with a brightness greater than 1000 candela per square meter (luminance), and / or a vibration alarm. Additionally, the alarm associated with the highest severity level may not be snoozed or ignored. Alternatively, the 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 vibration 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, sounds, or vibrations. The visual alerts may have different intensities, colors, patterns, etc. The vibration alerts may have different patterns, intensities, etc. Additionally, alerts 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 alert generated (e.g., audio, text, graphic, or any combination thereof).

[0384] 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 to be 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).

[0385] 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 m...

Claims

[Claim 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.

Images