Blood Glucose Control System

Abstract

Glycemic control systems and portable medical devices for providing therapy, such as glycemic control, to a subject 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.

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 Government has certain rights in this invention. Incorporation by reference of any priority application This application claims the benefit of U.S. Provisional Patent Application Nos. 62 / 987,842, filed March 10, 2020, 63 / 037,472, filed June 10, 2020, 62 / 874,934, filed July 16, 2019, 62 / 874,950, filed July 16, 2019, 62 / 874,968, filed July 16, 2019, 62 / 910,970, filed October 4, 2019, 62 / 911,017, filed October 4, 2019, and 62 / 911,143, filed October 4, 2019. The entire contents of each application referenced in this paragraph are incorporated herein by reference and made a part hereof.

[0002] The present disclosure relates to glycemic control systems and portable medical devices for providing therapy to a subject. [Background technology]

[0003] A continuous delivery pump-driven drug injection device generally includes a delivery cannula attached in a subcutaneous manner through the subject's skin at an injection site. The pump draws drug from a reservoir and delivers the drug to the subject through the cannula. The injection device typically includes a channel that transmits the drug from an inlet to the delivery cannula, resulting in delivery to the subcutaneous tissue layer where the delivery cannula terminates. Some infusion devices are configured to deliver one drug to a subject, while others are configured to deliver multiple drugs to a subject. Summary of the Invention

[0004] Disclosed are glycemic control systems and portable medical devices for providing therapy, such as glycemic control, to a subject. 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 aspect 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 description of the drawings]

[0006] [Figure 1] FIG 1A illustrates an exemplary glycemic control system that provides glycemic control via a portable drug pump. FIG 1B illustrates another exemplary glycemic control system that provides glycemic control via a portable drug pump. FIG 1C illustrates a further exemplary glycemic control system that provides glycemic control via a portable drug pump. [Diagram 2] FIG 2A shows a block diagram of an exemplary glycemic control system. FIG 2B shows a block diagram of another exemplary glycemic control system. FIG 2C shows a block diagram of another exemplary glycemic control system. FIG 2D shows a block diagram of another exemplary glycemic control system. [Diagram 3] FIG. 1 is a schematic diagram of an exemplary glucose control system including an electronic communication interface. [Figure 4] 4A and 4B show block diagrams of an exemplary glycemic control system in an online mode of operation and an offline mode of operation, respectively. [Diagram 5] Figure 5A shows a perspective view of an exemplary portable medical device, and Figure 5B shows a cross-sectional view of the portable medical device shown in Figure 5A. [Figure 6] 1 illustrates various modules that may be included in an exemplary portable medical device. [Figure 7] 1 illustrates various methods and links by which AMD can establish a connection with a host computing system. [Figure 8] FIG. 2 is a flow diagram illustrating an example of a computer-implemented method that may be used by AMD to detect and download application updates. [Figure 9] FIG. 13 is a flow diagram illustrating an example of a computer-implemented method that may be used by AMD to install downloaded application updates without interrupting treatment provided to a subject. [Figure 10] FIG. 11 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 treatment provided to a subject. [Figure 11] FIG. 11 is a flow diagram illustrating an example of a computer-implemented method that may be used by an AMD to install, verify, and switch control of the AMD from a first application to a second application downloaded from a host computing system without interrupting treatment provided to a subject, but only if the second application meets a minimum set of operating conditions. [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. [Figure 13]FIG. 1 is a flow diagram illustrating an example of a computer-implemented method that may be used to switch control of the 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. [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. [Figure 15] FIG. 11 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. [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 to the AMD. [Figure 17] FIG. 1 is a flow diagram illustrating an example method that may be used by a computing system to generate and send an alert to one or more authorized devices. [Figure 18] 1 illustrates the interconnections between modules and procedures in an AMD involved in receiving, accepting, and / or canceling a therapy change request. [Figure 19] FIG. 1 is a flow diagram illustrating an exemplary method that may be used by an AMD to allow a user to change the configuration of a portable medication device using a touch screen user interface. [Figure 20]FIGURE 20A is a diagram of an exemplary AMD touchscreen display after the touchscreen has been woken / unlocked by a user's wake action and before a first user gesture is received. FIGURE 20B is a diagram of an exemplary touchscreen display that can prompt a user to enter a predetermined sequence of inputs for a first gesture or a second gesture. FIGURE 20C is a diagram of an exemplary therapy change user interface. FIGURE 20D is a diagram of another therapy change user interface on a touchscreen display. [Figure 21] 1 is a flow diagram illustrating an example method that may be used by an AMD to generate an alarm status indicator. [Figure 22] FIG. 11 is a flow diagram illustrating an example method that may be used to cancel a therapy change using a touch screen interface. [Diagram 23] 23A is a diagram of a touchscreen display alerting a user that delivery of one or more medications is occurring, and FIG 23B is a diagram of a touchscreen display indicating that medications are being delivered to the user. [Figure 24] 1 is a block diagram showing the interconnections between modules and procedures in an AMD involved in receiving, accepting, and / or canceling a therapy interruption request. [Diagram 25] 1 is a flow diagram illustrating an example method for receiving and implementing an interrupt request that may be implemented by AMD. [Figure 26] 13 illustrates several screens that a portable medical device may display when a user pauses treatment. [Figure 27] FIG. 1 is a flow diagram illustrating an exemplary method for resuming interrupted treatment that may be performed by AMD. [Figure 28] 13 illustrates several screens that the portable medical device may display when a user resumes treatment. [Figure 29] FIG. 2 is a block diagram showing the interconnections between modules and procedures in the AMD involved in changing the configuration of the AMD. [Diagram 30] FIG. 2 is a flow diagram illustrating an example method that may be used by an AMD to allow a user to modify the AMD's settings using a user-generated or override passcode. [Diagram 31] FIG. 2 is a flow diagram illustrating an example method that may be used by an AMD to allow a user to modify the AMD's settings using a user-generated or override passcode. [Diagram 32] FIG. 1 is a schematic diagram showing the interconnections between modules and procedures in an AMD involved in monitoring the status of the AMD and / or the subject and generating alarms when alarm conditions are met. [Diagram 33] FIG. 2 is a flow diagram illustrating an exemplary procedure that may be used by AMD's alarm system to signal an alarm condition upon receiving status information that satisfies the alarm condition. [Diagram 34] FIG. 2 is a block diagram illustrating the interconnections between the modules and procedures in the AMD involved in monitoring the status of the AMD and generating alerts when equipment malfunctions are detected. [Diagram 35] FIG. 2 is a flow diagram illustrating an exemplary procedure that may be used by an AMD's alert system to monitor AMD operation and generate alerts when equipment malfunction is detected. [Diagram 36] FIG. 1 is a schematic diagram illustrating a portable medical device that provides a user with various options for delivering medication. [Figure 37] FIG. 13 is a flow diagram of a process for providing options for meal portion selection on a portable device. [Figure 38] FIG. 13 is another flow diagram of a process for providing options for meal portion selection on a portable device. [Figure 39] 11 is a sequence of screen displays illustrating a user initiating meal portion activation on a portable device. [Diagram 40] 11 is a sequence of screen displays illustrating a user initiating meal portions on a portable device. [Diagram 41]11 is a sequence of screen displays illustrating a user activating a meal announcement on a portable device. [Diagram 42] 1 is a sequence of screen displays illustrating a user entering a total number of units on a portable device. [Diagram 43] 13 is a sequence of screen displays showing the portable medical device delivering the unit and cancelling the delivery of the unit. [Diagram 44] FIG. 1 is a schematic diagram illustrating a computer system on which various embodiments of the described subject matter may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] Some embodiments described herein relate to a drug infusion system for one or more drugs, and components of such a system (e.g., an infusion pump, a drug cartridge, a cartridge connector, a lumen assembly, an infusion connector, an infusion set, etc.). Some embodiments relate to a method of manufacturing the infusion system and its components. Some embodiments relate to a method of using any of the aforementioned systems or components for infusing one or more drugs (e.g., medicines, hormones, etc.) into a subject. As an exemplary illustration, the infusion system may include an infusion pump that may include one or more drug cartridges or may have an integrated reservoir of drug. The infusion system may include a drug cartridge and a cartridge connector, but not a pump. The infusion system may include a cartridge connector and an infusion pump, but not a drug cartridge. The infusion system may include an infusion connector, a lumen assembly, a cartridge connector, an infusion pump, but not a drug cartridge or an infusion set. The glycemic control system may operate with the infusion system to infuse one or more drugs, including at least one glycemic control agent, into a subject. 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. In addition, any feature, structure, component, material, step, or method described and / or illustrated in one embodiment may not be present in another embodiment.

[0008] Overview of the Blood Glucose Control System A glycemic control system (BGCS) is used to control blood glucose levels in a subject. The glycemic control system can include a controller configured to generate a dose control signal for one or more glucose control agents that can be infused into the subject. The glucose control agents include regulators that tend to lower blood glucose levels, such as insulin and insulin analogs, and antagonists that tend to increase blood glucose levels, such as glucagon or dextrose. A glycemic control system configured for use with two or more glucose control agents can generate a dose control signal for each agent. In some embodiments, the glycemic control system can generate a dose control signal for a drug even if the drug is not available for administration via a drug pump connected to the subject.

[0009] The glucose control agent may be delivered to the subject by subcutaneous injection, intravenous injection, or another suitable delivery method. For glycemic control therapy with an ambulatory drug pump, subcutaneous injection is the most common. The ambulatory drug pump 100 is a type of ambulatory medical device, and may also be referred to herein as an ambulatory device, ambulatory drug device, ambulatory ambulatory device, or AMD. Portable medical devices include ambulatory drug pumps and other devices configured to be carried by the subject and deliver therapy to the subject.

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

[0011] 1A-1C show an example of a glycemic control system that provides glycemic control via an ambulatory drug pump connected to a subject. 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 control 106a that allows a user to view pump data and change treatment settings via user interaction with the pump control 106a. A glucose level sensor 110 generates a glucose level signal that is received by the glycemic control system.

[0012] 1B, drug pump 100 communicates with external electronics 108 (e.g., a smartphone, etc.) via a wireless data connection. At least some of pump controls 106a and 106b can be operated via user interaction with user interface elements of external electronics 108. Glucose level sensor 110 can also communicate with drug pump 100 via a wireless data connection.

[0013] 1C, drug pump 100 includes an integrated cannula for insertion into infusion site 102 without a separate infusion set. At least some of the pump controls 106b can be operated via user interaction with user interface elements of external electronics 108. In some cases, the 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.

[0014] A glucose control system typically includes a user interface configured to provide one or more of treatment information, glucose level information, and / or treatment control elements that can change treatment settings via user interaction with an interface control. The user interface can be implemented via electronics that include a display and one or more buttons, switches, dials, capacitive touch interfaces, or touch screen interfaces. In some embodiments, at least a portion of the user interface is integrated with a portable drug pump that can be tethered to the subject'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 electronics that are separate from the portable drug pump, such as a smartphone.

[0015] 2A-2D show block diagrams illustrating an exemplary configuration of a glucose control system 200. As shown in FIG. 2A, the glucose control system 200a can include a controller 202a having an electronic processor 204a and a memory 210a storing instructions 208a executable by the processor 204a. The controller 202a and the pump 212 can be integrated with an ambulatory medical device (AMD) 100. The AMD 100 can include a transceiver 214a for wireless digital data communication with an external electronic device. When the instructions 208a stored in the memory 210a are executed by the electronic processor 204a, the controller 202a can implement at least a portion of a control algorithm that generates a dose control signal for one or more glucose control agents based on the subject's time-varying glucose level and one or more control parameters. The dose control signal, when delivered to the pump 212, results in a dosing action that controls the subject's blood glucose.

[0016] As shown in FIG. 2B, the glucose control system 200b may be implemented at least in part through execution of instructions 208b by an electronic processor 204b of an electronic device 108 separate from the portable medical device 100. The electronics 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 via 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 a dose control signal for one or more glucose controlling agents based on the subject's time-varying glucose level and one or more control parameters. The dose control signal, when delivered to the pump 212, results in a dosing action that controls the subject's blood glucose. In some embodiments, the dose control signal is transmitted from the device's transceiver 214b to the AMD's transceiver 214a via a short-range wireless data connection 216. The AMD 100 receives the dose control signal and passes it to the pump 212 for dosing action.

[0017] As shown in FIG. 2C, the glucose control system 200c can operate at least in part through 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 a dose control signal for one or more glucose control agents based on the subject's time-varying glucose level and one or more control parameters. The dose control signal, when delivered to the pump 212, results in a dosing action that controls the subject's blood glucose. In some embodiments, the dose control signal is transmitted from the remote computer's WAN connection interface 220c to the AMD's WAN connection interface 220a via the end-to-end wireless data connection 218. The AMD 100 receives the dose control signal and passes the signal to the pump 212 for dosing action.

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

[0019] 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 304 configured to receive a glucose level signal from a sensor 110, such as a continuous glucose monitor (CGM). Some CGMs generate a glucose level signal at fixed measurement intervals, such as five minute intervals. The sensor 110 can be operatively connected to a subject to generate a glucose level signal corresponding to a blood glucose estimate or measurement of the subject. The glucose level signal can be used by the controller 202 to generate a dose control signal. The dose control signal can be provided to the pump 212 via a pump interface 306. In some embodiments, the sensor interface 304 can be configured to receive a glucose level signal from a sensor 110, such as a continuous glucose monitor (CGM). Some CGMs generate a glucose level signal at fixed measurement intervals, such as five minute intervals. The sensor 110 can be operatively connected to a subject to generate a glucose level signal corresponding to a blood glucose estimate or measurement of the subject. The glucose level signal can be used by the controller 202 to generate a dose control signal. The dose control signal can be provided to the pump 212 via a pump interface 306. The controller 202, ECI 306, and pump 212 are connected to the AMD 100 via a local data bus.

[0020] The controller can be configured to generate the dose control signal using a control algorithm that generates at least one of the basal dose, the correction dose, and / or the 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 disclosure"), the entire contents of which are incorporated herein by reference and made a part of this specification. The correction dose can include a regulator or antagonist and can be generated using a model predictive control (MPC) algorithm such as that disclosed in the controller disclosure. The basal dose can include a regulator and can be generated using a basal control algorithm as disclosed in the controller disclosure. The meal dose can include a regulator and can be generated using a meal control algorithm as disclosed in the controller disclosure. Additional aspects and improvements of at least some of these controllers are disclosed herein. The dose control signal can be transmitted to the injection motor 306 via the ECI 302, or, if the controller 202a is integrated within the same housing as the injection motor 306, can be transmitted to the injection motor 306 via electrical conductors.

[0021] 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 sensor 110. In the on-line mode, the control algorithm generates a dose control signal 404 that implements regular correction doses based on the value of the glucose level signal 402 and control parameters of the control algorithm. The pump 212 is configured to deliver at least the correction doses and the basal dose to the subject without substantial user intervention while the controller 400 remains in the on-line mode.

[0022] 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 in response to an isolated glucose measurement 406 (e.g., a measurement obtained from the subject using a glucose test strip, etc.) and based on control parameters of the control algorithm. The pump 212 is configured to deliver a basal dose to the subject without substantial user intervention and can deliver a correction dose to the subject in response to the isolated glucose measurement 406 while the controller 400 remains in the offline mode.

[0023] Exemplary Portable Medical Devices In some embodiments, an ambulatory medication device (AMD) can be a portable or wearable device that provides life-saving treatment to a subject or subject by delivering one or more medications (e.g., insulin and / or glucagon) to the subject or subject. Some AMDs can continuously monitor the subject's health using sensors and deliver one or more medications based on the subject's condition. Certain ambulatory medication devices require the subject to be in a constant state (e.g., all day) or for a large portion of the day (e.g., during waking hours, during sleep) to allow for continuous monitoring of the subject's health and to deliver medications as needed. The device may be worn for a period of time (e.g., during periods when not swimming).

[0024] FIG. 5A shows a three-dimensional (3D) view of an exemplary portable medical device 500 comprising a housing 502 having a wake button 506 and a touchscreen display 504. FIG. 5B shows a cross-sectional view of the portable medical device 500 shown in FIG. 5A. In this example, all electronic modules 508 are contained within the housing, for example as a single integrated electronic board. The wake button 506 may be any type of button (e.g., capacitive, mechanical) that registers input generated by user interaction with the wake button 506 to generate 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 retina scanner, an optical or RF proximity sensor, etc.). In various embodiments, the wake signal may be generated by user interaction with the touchscreen display 50 or an alphanumeric pad (not shown). In some other examples, the wake signal may be generated based on facial recognition or other biometric indicia. In still other examples, the wake signal may be generated by a wireless signal, such as an RFID or Bluetooth signal, or by detection of motion using one or more motion sensors, such as an accelerometer. The wake button 506, when touched, pressed, or held for a period of time, 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 such that it cannot accept at least certain types of user interactions or setting changes after the touchscreen display 504 is activated by the wake button 506 until a gesture (e.g., any of the gesture interactions described with reference to any of the embodiments disclosed herein) is received.

[0025] FIG. 6 illustrates various modules that may be included in an exemplary AMD 500. In some examples, all these modules may be integrated into a single housing (as shown in FIG. 5B). In some other examples, one or more modules may be individual modules housed in separate housings that communicate with a main unit via wired or wireless communication links (e.g., Bluetooth). 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 computing module 610.

[0026] The control and computing module 610 may include one or more processors 614, a main memory 616, a storage 618 that may comprise one or more non-transitory memories, and an interface 612 that allows data and signal communication between components within the control and computing module 610 and between the control and computing module and all other modules of AMD. The main memory and storage 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 storage) the main memory, and the processor 614 executes 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 not powered. The storage 618 may exchange data with the main memory directly or via the interface 612. The main memory 616 may be any type of memory capable of storing instructions, communicating the instructions to the processor 614, and receiving executed instructions from the processor 614. Types of main memory include random access memory (RAM) ) and read only memory ("ROM"). Processor 614 may be any type of general purpose central processing unit ("CPU"). In some embodiments, the control and 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"), and the like. Storage 618 may be any type of computer storage capable of receiving data, storing data, and transmitting data to main memory 616 and possibly other modules of AMD. 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, and the like. Interface 612 may include data transfer buses and electronic circuitry configured to support data exchange between various components in the control and computing system 610. In some examples, interface 612 may also support data and signal exchange between other modules, as well as data exchange between any of the modules and the control and computing module 610.

[0027] The signal processing module 604 can include multiple interconnected electronic modules for signal conditioning and signal conversion (e.g., A to D and D to A conversion) configured to support communication and data exchange between the various modules. For example, the signal processing 604 module can convert an analog signal received from the communication module 602 and convert the signal to a digital signal that can be transmitted to the control and computing module 610 (e.g., via an interface 612). As another example, the signal processing module can receive a digital control signal from the control and computing module 610 and convert the signal to an analog signal that can be transmitted to the therapy delivery module 506, for example, to control one or more pumps.

[0028] The therapy delivery module 606 may include one or more infusion pumps configured to deliver one or more medications to the subject. The medications may be stored in one or more medication cartridges housed within the therapy module 606. In some examples, the therapy delivery module 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).

[0029] The user interface module 608 may include a display showing various information about the AMD, the drug type and delivery schedule, software status, etc. Graphical images and text may be displayed by any display technology, including but not limited to OLED, LCD, or e-ink. In some embodiments, the AMD may include a user interface (e.g., an alphanumeric pad) that allows a user to input information or interact with the AMD to change settings on the AMD, respond to requests for specific actions (i.e., software installation), etc. The alphanumeric pad may include a number of keys having numeric, alphabetic, and symbolic characters. The keys of the alphanumeric pad may be capacitive or mechanical. The user may be the subject receiving the drug or treatment, or may be another user, such as a clinician or health care provider, or the subject's parent or guardian. In some other embodiments, the AMD may include a touch screen display that generates output and also accepts inputs that allow two-way interaction between the user and the AMD. The touch screen display may be any input surface that displays graphic images and text and also registers the location of a touch on the input surface. The touch screen display may accept input by capacitive touch, resistive touch, or other touch technologies. The input surface of the screen display can register the location of a touch on the surface. In some examples, the touch screen display can register multiple touches at once. In some embodiments, an alphanumeric pad is displayed on the touch screen display. The touch screen may present the user with one or more user interface screens that allow the user to change one or more treatment settings of the portable medication device.

[0030] The communication module 602 may include one or more wireless transceivers, one or more antennas, and multiple electronic modules. Each transceiver may be configured to receive or transmit different types of signals based on different wireless standards via an antenna (e.g., an antenna chip). The transceiver may support communication using a low power wide area network (LPWAN) communication standard. In some examples, the transceiver may support communication with a wide area network, such as a cellular network transceiver enabling 3G, 4G, 4G-LTE, or 5G. Additionally, the transceiver may support communication via a Narrowband Long Term Evolution (NB-LTE), Narrowband Internet of Things (NB-IoT), or Long Term Evolution Machine Type Communication (LTE-MTC) communication connection with a wireless wide area network. In still other cases, the transceiver may support Wi-Fi® communication. In some examples, the transceiver may be capable of downconverting and upconverting baseband or data signals to and from a carrier signal. In some examples, the communication module can wirelessly exchange data between the portable medical system (e.g., sensors), the mobile device (e.g., smartphones), and other components such as Wi-Fi networks, WLANs, wireless routers, cellular towers, Bluetooth devices, etc. The antenna chip can transmit and receive various types of wireless signals, including but not limited to Bluetooth, LTE, or 3G. In some examples, the communication module can support direct communication between the AMD and a server or cloud network. In some other examples, the AMD can communicate with an intermediate device (e.g., smartphone). In some embodiments, the AMD can include an eSIM card that stores all of the information required to identify and authenticate the mobile subscriber. The eSIM card allows the portable device to transmit data on a very inexpensive IOT device basis. In other embodiments, the portable medical device may be configured to transmit data in a narrowband communication protocol such as 2G or EDGE.Using a cellular connection, the portable medical device can be paired with the mobile device at initiation, allowing real-time data access to the portable medical device by the healthcare provider. In certain implementations, the portable medical device can include a location information receiver or transceiver, such as a Global Positioning System (GPS) receiver.

[0031] Example AMD Operation In some embodiments, the AMD may continuously, periodically, or intermittently receive information regarding one or more parameters (e.g., glucose level, glucose trend, heart rate, physical activity indicia, etc.) that correlate with the subject's health status. This information may be encoded into a signal provided to the AMD by a subject sensor 620 (e.g., a wearable sensor measuring analytes in interstitial fluid) connected to the main unit 600 via a wired or wireless link (e.g., Bluetooth). In some examples, the signal transmitted by the sensor may be received by the communications module 602 and transmitted to a signal processing module 604 that converts the signal into a machine-readable signal (e.g., a digital signal). The signal processed by the signal processor module 604 may be transmitted to the control and computing module 610, where it is analyzed to determine whether a medication should be delivered to the subject. If a medication is determined to be required, the control and computing module determines the amount of medication required based on the information received from the subject sensor 620. The dosage can be calculated and a signal can be sent to the treatment module (eg, via the signal processing module) to initiate the process of drug delivery to the subject.

[0032] All procedures within the control and processing module 610 are executed by the processor 614 (or processors) based on instructions provided by one or more software applications installed in one of the memories (e.g., main memory) of the control and computing module 610. These procedures include, but are not limited to, determining the need to deliver a drug, determining the type of drug and the required dose, determining the delivery rate during a treatment session, providing information (e.g., device status, time of next delivery, level of a particular analyte in the subject's blood, etc.) via the user interface module 108, processing information received from the subject sensor 620 via the user interface 608, etc. In some embodiments, a first software application may control the AMD and may be installed in the main memory 616, while 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 in different locations or segments. In these examples, control of the device may be switched from the first software application to the second software application as needed.

[0033] In some embodiments, the portable medical device 600 can deliver multiple types of therapies selectable by the user or the control and computing module 610. For example, the portable medical device 600 can deliver a therapy that injects insulin to the user and can also deliver a therapy that injects glucagon to the user. In some examples, the user interface can 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 can be delivered. In some examples, the software application executed by the control and computing module 610 can determine the type of hormone that needs to be delivered based at least in part on the information received from the sensor 620.

[0034] Communications and Networking 7 illustrates various methods and links that the AMD 702 may use to establish a connection with a host computing system 704 to obtain application updates. The host computing system 704 may be a server 706 or a computing system in a cloud computing network 708 or other networked computing environment. The host computing system 704 may be part of a data center (e.g., a data center of a healthcare provider).

[0035] To obtain application updates, the AMD may establish a connection (e.g., using a communication module in the AMD) with the host computing system through an intermediary device 710, such as a desktop computer, a mobile device (e.g., smartphone, laptop, etc.). In some such examples, the AMD may receive application updates from a user's local device 712 (e.g., a clinical computer, a subject's home computer, smartphone, etc.) that has obtained a copy of the application update from the host computing system directly or via the Internet 714. In some other examples, the AMD may communicate with the host computing system 704 through a local area network (LAN) via a Wi-Fi connection. Alternatively, or in addition, the portable medical device may communicate with the host computing system 704 through a wide area network 716. A connection to the host computing system 704 may be established via the portable medical device. Additionally, the communication connection established between the portable medical device and the cloud computing service may be encrypted.

[0036] In some embodiments, the portable medical device can establish a direct end-to-end connection with the host computing system 704 via a wide area network 716 (e.g., a cellular network). The method may include receiving a public key from the portable medical device. The public key and a private key stored in the host computing system 704 may be used to enable the host computing system 704 to decrypt data communications transmitted by the portable medical device. In some implementations, establishing the direct end-to-end data connection includes receiving a device identifier associated with the portable medical device. The device identifier may be a unique identifier specific to the portable medical device. Additionally, establishing the direct end-to-end data connection may include determining that the portable medical device is authorized to communicate with the computing system based at least in part on the device identifier. The device identifier may be initially provided to the networked computing environment prior to providing the portable medical device to the subject. For example, the device identifier may be initially provided to the networked computing environment as part of a manufacturing process for manufacturing the portable medical device. 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 subject identifier of the subject receiving treatment from the portable medical device. In some cases, the subject or user establishes or initiates the establishment of a direct end-to-end data connection with the computing system. In other cases, the direct end-to-end data connection may be initiated or established without action by the subject or user. For example, the direct end-to-end data connection may be made automatically at a particular time or when the portable medical device is in a particular location. This automatic connection may be made using information provided to the portable medical device when manufactured, shipped, sold, or prescribed to the subject. In some cases, the wide area network may include or communicate with the Internet 714.

[0037] In some embodiments, the portable medical device may be configured to communicate over a wide area network during manufacture or before being provided to the subject. For example, the manufacturer may register the portable medical device with a wireless wide area network provider (e.g., T-Mobile or Verizon) and provide the portable medical device's International Mobile Equipment Identity (IMEI) number or serial number to the network provider. Additionally, any fees may be negotiated or paid between the manufacturer and the network provider, or between the subject's health insurance and the network provider. Thus, the subject's portable medical device may be configured to communicate over the network provider's network without any action by the subject.

[0038] In some other examples, the portable medical device may be pre-registered or authenticated to the cloud service provider's computing network as part of the manufacturing process or before the portable medical device is provided to the subject, so that the portable medical device can communicate over a wide area network with the cloud service provider's computing system from day one with no or minimal configuration by the subject. In some cases, a user, such as a healthcare provider, can register or associate the portable medical device with the subject in the cloud service provider's computing network.

[0039] To enhance security, portable medical devices are A cloud computing service may use a whitelist that identifies authorized cloud servers or computing systems of the system via a unique identifier (e.g., via an IP address, MAC address, or URL). Additionally, the cloud computing service may have a whitelist that specifies, using a unique identifier, which portable medical devices and / or other computing systems (e.g., remote display systems) are allowed to communicate with the cloud computing system.

[0040] To enhance security, the portable medical device may use a whitelist that identifies authorized cloud servers or computing systems of the cloud computing system via a unique identifier (e.g., via an IP address, a MAC address, or a URL). Furthermore, the cloud computing service may have a whitelist that specifies which portable medical devices and / or other computing systems (e.g., remote display systems) are permitted to communicate with the cloud computing system using a unique identifier. The whitelist may be stored in a memory of the portable medical device. Furthermore, the whitelist may be configured during manufacturing of the portable medical device. 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 portable medical device may be configured to execute certain computer-executable instructions to at least obtain an address of the computing system from the whitelist and use the address to establish a direct end-to-end data connection to the computing system of the networked computing environment via a wireless wide area network. Furthermore, the portable medical device may be configured to execute certain computer-executable instructions to at least receive a public key from the computing system of the networked computing environment.

[0041] Portable medical device software updates Computer applications are often updated after they are released. In some cases, applications are updated to fix bugs or vulnerabilities. In other cases, applications are updated or replaced with new versions to introduce new features or improve existing 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 is not running while it is being updated.

[0042] However, stopping the execution of an application on a portable medical device while the application on the portable medical device is being updated or replaced with a new version of the application can be inconvenient, harmful, or even life threatening. If a subject or subject receiving treatment from a portable medical device enters a state where treatment is desired or required while the application or control software of the portable medical device is being updated or replaced, harm may occur to the subject. For example, assume that the portable medical device is an insulin pump, such as one that may be used by a type 1 diabetes patient. If the insulin pump becomes inoperable due to a software update process that occurs when the subject's blood glucose level exceeds a set value or target range, the user will not be able to receive the required insulin bolus from the portable medical device. It is therefore desirable to reduce or eliminate interruptions to the subject's care or treatment when updating an application, such as the control software of the portable medical device.

[0043] In some embodiments, the portable medical device includes a computer-implemented method for updating an application executed on the portable medical device without interrupting or causing minimal interruption to the treatment provided by the portable medical device to the subject or test subject. The method may generally be executed by a hardware processor (e.g., controller, etc.) included in the portable medical device based on a set of instructions that may be stored, for example, in a non-transitory memory of the AMD. The application update may be a new version of the application, a replacement or replacement application, or an application patch. In some examples, the application may be an older version of an application that has been used by an instance of the portable medical device for more than a threshold period and has experienced less than a threshold number of failures. The application update may be stored on one or more host computing systems. The application update may be pushed to the host computing system by the company that manages or manufactures the portable medical device, or by other software companies authorized by the device manufacturer or licensee.

[0044] FIG. 8 is a flow diagram illustrating an example of a computer-implemented method that may be used by an AMD to detect and download application updates from a host computing system or other computer-readable medium on which a copy of the application update is stored. In certain aspects, a portable medical device, such as a drug delivery device or drug pump, may receive (802) 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 portable medical device. The software update may include binary executable files for various processors of the portable medical device. In some embodiments, the indication may be a determination made by a software or hardware module included in the AMD's portable medical device. For example, the AMD may access a particular host computing system (e.g., using the AMD's communication module) to determine whether an update is available based on a set of update trigger conditions stored in the AMD's memory. The set of update trigger conditions may be defined / modified by a user and / or received by the AMD from the host computing system. For example, the trigger conditions may push the AMD to periodically search for updates at a time interval set by the user or received from the host computing system. Alternatively, or in addition, in response to a trigger (such as a user command, changing medication within the portable medical device, connecting to a particular network, or connecting to a network using a particular communications transceiver (e.g., Wi-Fi), etc.), the portable medical device can access a particular host computing system and determine whether an update is available for an application installed on the AMD. The software updated on the AMD may be currently running on the portable medical device or may run in the future.

[0045] In some embodiments, the indication may be a query received from a host computing system that can access the AMD to retrieve and compare the software version and hardware configuration (and warranty) to determine the eligibility of the portable medical device for the software upgrade. The serial number, model number, and / or software version may be used to determine the software upgrade eligibility. In some embodiments, the eligibility may be determined based on the geographic location of the device and / or whether the device is connected to a local area network (e.g., a Wi-Fi network) or a wide area network (e.g., a cellular network). In various embodiments, the portable medical device may have an antenna that provides the device with GPS, text or picture messaging, phone calls, and data transfer capabilities. The software update may be provided in a limited release with test groups of various sizes, e.g., 1-100, 1-1000, or 1-10000. There may be a phase of software update rollout. In some embodiments, the AMD may provide a first The upgrade eligibility request may be responded to with the software version of the portable medical device, or the model identification of the portable medical device, or the manufacture date of the portable medical device.

[0046] If an update is determined to be available for an application executing on the portable medical device, the portable medical device may establish a connection to a host computing system that hosts the updates to the application (804). Such a connection may be established via one or more links or methods described above with reference to FIG.

[0047] Once the connection is established, the portable medical device may download (806) the application update or application update from the host computing system via the connection. In some examples, the portable medical device 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 portable medical device may continue to run. Thus, there is little or no interruption to the treatment provided by the portable medical device while the application update is being obtained by the portable medical device.

[0048] Once the application update is obtained, the portable medical device may perform one or more operations (using the device's control and computing modules) to verify that the application update was successfully downloaded from the application host system and that the download is not corrupted (808). For example, the portable medical device may calculate a hash or checksum value from the downloaded application update. This hash or checksum value may be compared to that received from the application host system. If the calculated hash or checksum value matches the received hash or checksum value, the download may be determined to be complete and uncorrupted. Additionally, the portable medical device may use a checksum, tag, payload size, or any other method to verify that the application update download is complete and uncorrupted. If the download is determined to be corrupted, the AMD discards the corrupted copy and downloads another copy of the update. If the download is determined to be complete and uncorrupted, the AMD may proceed to an installation step, where the application update may be installed on the AMD without interrupting ongoing or future therapy sessions.

[0049] 9-11 are flow diagrams illustrating an example of a computer-implemented method that may be used by AMD to install downloaded application updates without interrupting treatment provided to a subject.

[0050] In the exemplary method illustrated in FIG. 9, if an uncorrupted copy of the application update is verified to have been successfully downloaded (902) (e.g., using the procedure described above with reference to FIG. 8), the AMD control and computation module (CCM) may determine (904) the amount of time required to install the application update and wait (906) for a trigger signal to initiate the installation process. In some examples, the CCM may notify (908) the user that the update is ready for installation via a user interface (e.g., a touch screen display). The notification may include information regarding the installation time and the update. In such examples, if a trigger is not received, the CCM may send one or more notifications to the user indicating that a new update is ready for installation. In some examples, the trigger may be a confirmation that the application was successfully downloaded. Alternatively, or in addition, the trigger may be part of or may be a part of the portable medical device. The user command may be received based on an interaction by a user or subject with a user interface in communication with the

[0051] The installation time may be determined by the CCM based on data or metadata provided with the downloaded application update. For example, the application update may include a file (e.g., a text file or a configuration file) that includes the installation time. The installation time may be determined by the portable medical device manufacturer or the application update publisher. For example, the software update developer may average the installation time across several test devices to determine the installation time metadata provided with the software update. General purpose computers have a wide variety of configurations, and the performance of general purpose computers may vary depending on the application being run at a particular time. Thus, determining the installation time of an application based on measuring the installation time on a test device is generally unreliable. However, because portable medical devices are often dedicated devices designed to perform a specific function (e.g., provide insulin to a subject), the installation time determined by the manufacturer during testing can often be a reliable determination of the installation time on the subject's portable medical device. As an alternative to or in addition to determining the installation time based on testing by the manufacturer, the installation time of the application update may be determined or estimated based on the size of the application update. In some cases, the provided or estimated installation time may include a buffer. In other words, an additional amount of time may be added to the installation time to account for variations in the operating conditions of the portable medical device or inaccuracies in the estimated installation time.

[0052] If a trigger is received (906), the CCM can check (910) for any ongoing therapy sessions. If therapy is not currently being administered, the CCM can determine (914) the next therapy time (or the time remaining until the next therapy session). If therapy is currently being administered, installation is delayed (912) until the therapy session is completed. Once the current therapy session is completed, the CCM can determine (914) the time remaining until the next therapy session (e.g., during which medication such as insulin is being delivered to the subject).

[0053] In some cases, the determination of the time when therapy will next be delivered may be an estimate based on past deliveries of therapy, the subject's current state (e.g., if the subject's glucose level is in the center of the desired range, the next therapy delivery time may be estimated to be further away than if the glucose level is at the edge of the desired range), and / or an indication provided by the user or subject (e.g., an indication that the user plans to eat, exercise, or go to sleep). Alternatively, or in addition, the determination of the time when therapy will next be delivered may be based on a scheduled delivery of therapy (e.g., every 5 minutes or every hour).

[0054] As previously mentioned, it is desirable to prevent interruptions in therapy during the application update process. Thus, after the next therapy time is determined (914), the estimated installation time can be compared (916) to the determined or estimated next therapy delivery time to determine whether the installation of the application update can be completed before the next therapy delivery to the subject. If it is determined that the time remaining until the next therapy session is sufficiently longer than the determined time to complete the installation, then the installation of the updated application can be initiated (918). In some examples, the determined time until the next therapy session must be longer than the determined installation time by a threshold value. Such a threshold value may be different for different application updates and / or types of next therapy sessions. Completing the application installation before the next therapy delivery If it is determined that the update cannot be installed (or the remaining time until the next treatment is not greater than its estimated installation time by a threshold amount), installation of the application may be delayed regardless of receipt of a trigger. In this case, the CCM may wait for the next treatment to be completed and then determine (914) a new treatment time. This process may be repeated until the CCM determines that the update can be installed without interrupting a predicted or scheduled treatment by the portable medical device. In some examples, a new determination may be made before completion of the next treatment to determine whether the installation can be completed before a subsequent treatment time after the next treatment time.

[0055] In some cases, a time during which the application can be installed without interrupting treatment may not be specified. In some such cases, the user (e.g., a clinician or other healthcare provider, or the subject) may be provided with an alert 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. 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 treatment) may be utilized.

[0056] In some embodiments, once an uncorrupted copy of the application update has been verified to have been successfully downloaded (902), the AMD control and computing module (CCM) may wait for a trigger signal before notifying the user and determining the installation time. Once the trigger is received, the CCM will begin the installation process of the downloaded copy of the application update without interrupting the treatment provided to the subject by the portable medical device. In such embodiments, the application update may be installed in a memory location different from the memory location where the original application is installed and executed.

[0057] 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 that is an update to a first application executing on a portable medical device without interrupting the treatment provided to the subject. In this example, once the control and computing module (CCM) of the AMD verifies (1002) that an uncorrupted copy of the second application has been successfully downloaded (e.g., using the procedure described above with reference to FIG. 8), the CCM may begin (1004) the installation process of the second application without interrupting the execution of the first application. The CCM may verify (1006) that the installation of the second application was successful and wait (1010) for a trigger signal to begin execution of the second application in place of the first application. In some examples, the installation of the second application may be confirmed by sending (1008) a notification to the user via a user interface of the AMD. In some examples, the CCM may determine the amount of time required to switch control of the AMD from the first application to the second application. The notification may include information about the update and the time required to switch between the applications. In some examples, the trigger may be a user command received based on an interaction by the user or subject with a user interface that is part of or in communication with the portable medical device. In such examples, if a trigger is not received, the AMD may send one or more notifications to the user indicating that a new update is ready for installation. If a trigger is received, the CCM may check (1012) for any ongoing therapy sessions. If no therapy is currently being administered, the CCM determines (1016) the next therapy time (or the time remaining until the next therapy session). If no therapy is currently being administered, the CCM may check (1018) for any ongoing therapy sessions. If so, installation is delayed until the therapy session is completed (1014). Upon completion of the current therapy session, the CCM can determine the time remaining until the next therapy session (1016). The estimated next therapy delivery time can be compared to a set threshold time to determine whether a switch from the first application to the second application can occur without interfering with the next therapy session. If it is determined that the time remaining until the next therapy session is longer than the set threshold time, execution of the second application is started and execution of the first application is stopped (1020). In some examples, the set threshold time can 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 other examples, the set threshold time can be received from a host computing system.

[0058] In some embodiments, the performance of the application update may be tested before switching control of the AMD to the application update. FIG. 11 illustrates an exemplary method that may be used by such an embodiment. First, the AMD verifies (1102) that an uncorrupted copy of the update of the first application was successfully downloaded (e.g., using the procedure described above with reference to FIG. 8). The AMD may then install 1104 and execute (1106) the downloaded copy of the second application without interrupting the execution of the first application and thus the treatment that may be provided to the subject by the portable medical device. In some examples, the second application update may be installed in a separate portion (e.g., a separate execution space or separate memory) from the portion in which the first application is installed and executed. The control and computing module (CCM) of the AMD may determine that a minimum set of operating conditions is satisfied (1110) by the second application, the minimum set of operating conditions being related to maintaining the treatment provided to the subject by the portable medical device. If it is determined that the minimum set of operating conditions is not met by the second application, the AMD may wait for an indication that the third application is available and repeat the above procedure to evaluate the performance of the third application. If it is determined that the minimum set of operating conditions is met by the second application, the AMD may check (1114) for an ongoing therapy session. If it is determined that therapy is not currently being provided to the subject, the CCM may switch (1118) control of the portable medical device from the first application to the second application. If therapy is currently being provided to the subject, the CCM may wait (1116) until the therapy session is completed and then switch control of the AMD from the first application to the second application.

[0059] In some cases, the portable medical device may be updated (or downgraded) to add features to (or remove features from) the portable medical device. For example, the portable medical device may initially only provide insulin therapy. At some point, the portable medical device may be upgraded to include bi-hormonal control (e.g., provide both insulin therapy and antagonist (e.g., glucagon) therapy). The upgrade may be based on newly available features and / or the user's decision to purchase or otherwise acquire additional features. Similarly, the user may choose to downgrade therapy from bi-hormonal therapy to insulin-only therapy. Alternatively, the upgrade or downgrade may be based on drug availability. In some examples, the first update may be a first application version including a first feature set (e.g., providing insulin therapy) and the second update may be a second application version including a second feature set (e.g., providing both insulin therapy and glucagon therapy). In some such examples, the first feature set may include a subset of the second feature set. In some other examples, the first feature set may be , may include a set of features that partially overlaps with the second set of features.

[0060] In some examples, a computer-implemented method may be used by an AMD to detect, download, and install an update to an application executing on a portable medical device, the application 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. In some other examples, the first feature set may include a set of features that partially overlap with the second feature set. The AMD may receive an indication of the availability of the application update, download the application update, and verify that an uncorrupted image of the application update was successfully downloaded (e.g., using the procedure described above with reference to FIG. 8). The AMD's control and computing module (CMM) may then initiate an installation process of the application update image without interrupting the execution of the application. In some examples, the indication (802) received by the AMD (see FIG. 8) may include information regarding the application update being an update to the first application version or the second application version. In some such examples, the CCM may determine a version of the application update and download the application update image based on the determined version.

[0061] In some embodiments, any downloaded application updates may be installed in a separate portion (e.g., a separate execution space or separate memory) from the currently running version of the application. Once the application installation is complete and the application is verified to be successfully installed, the active version of the application may be switched. For example, control of the portable medical device may be provided to the updated application, and the previously running application may be aborted or stopped. The old application may then be deleted or kept as a backup. Determining when to switch which version of the application is active may follow a similar process as described above to identify the next therapy delivery time and select a time to switch the active version of the application when there is no interruption in the therapy provided by the portable medical device.

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

[0063] In some examples, the second version of the application installed on the AMD may be an older version than the first version, or a version that may not have a track record of stability and reliability. Figure 12 is a flow diagram of such an example. When an application failure is detected (1202) while the first version is running, the AMD The control and computing module (CMM) of D can switch control of the AMD to a second version of the application (1204) while establishing a connection with a host computing system configured to host and download (1206) the third update. The third version of the application can be a new version, a version older than the first version, an update to the first application that addresses a detected application failure, or an older version that meets a condition to be classified as a "safe version" (e.g., less than a threshold number or percentage of failures over a minimum period of time). The second version (installed on the device) can control the AMD while the third version is downloaded and installed (1208) without interrupting treatment. Once the download of the third version is complete, the CCM can initiate an installation process for the downloaded copy of the third application and switch control of the portable medical device from the second application to the third application (1210) without interrupting treatment provided to the subject by the portable medical device.

[0064] In yet other embodiments, a "safe version" of the application may be installed on the portable medical device prior to detection of the fault. The safe version of the application may include a version of the application that has been used by an instance of the portable medical device for more than a threshold period of time and has experienced less than a threshold number of faults. For example, the safe version of the application may be a two-year old version of the application that can be demonstrated to have less than a threshold number of faults occurring over a two-year period. This safe version of the application may have fewer features than the first or second version of the application. However, if a fault is detected during execution of the first or second version of the application, the portable medical device may switch control of the device to the safe version of the application to maintain treatment to the subject.

[0065] In some cases, if there is a problem installing an updated version of an application, the portable medical device can revert to the current or safe version installed on the AMD.

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

[0067] FIG. 13 is a flow diagram illustrating yet another example of a method for responding to failure detection by an AMD. In this example, when an application failure is detected during execution of a first version of an application (1302), a control and computing module (CMM) of the AMD may locate (1304) a second version of the application in main memory or storage. If it is determined that the second version has already been downloaded, the CCM determines whether the second version of the application is installed in a memory location and ready to run (1306). If it is determined that the second version of the application is installed, control of the AMD is switched to the second version of the application. Referring to block 1306, if the CCM determines that the second version is present in memory but not installed, the CCM switches control of the AMD to a safe version that may already be installed, and then initiates installation of the second version (1318). Once installation of the second version is complete, the CCM may switch control of the AMD from the safe version of the application to the second version of the application. In some embodiments, after control of the AMD is switched to the second version of the application, the CCM may search for (1310) a third version of the application, which may be an update to the previously downloaded second version. If a third version is found, the CCM may download and install (1312) the third version and switch control of the AMD to the third version (1314). Referring to block 1304, if the CCM cannot find the second version of the application in the memory or storage location, the CCM switches (1320) control of the AMD to a safe version of the application, which may be installed in a memory location (e.g., main memory or storage), and then searches for (1310) the third version of the application. If a third version is found, the system may download and install (1312) the third version and switch control of the device to the third version (1314).

[0068] In some embodiments, upon detection of an application failure of an application running on the portable medical device, the AMD may send an indication of the application failure to a host computing system of the portable medical device manufacturer or maintenance service. In some other embodiments, the AMD may notify a user when an application failure occurs via a user interface of the AMD or a user interface in communication with the AMD.

[0069] Communication and remote viewing of medical devices directly connected to the network Portable medical devices, such as portable pharmaceutical devices (e.g., glycemic control systems (e.g., insulin pumps, or bihormonal pumps containing insulin and antagonists), pacemakers, or any type of medical device that may be connected to a subject to provide therapy to the subject, can generate a significant amount of data (therapy data) related to the therapy provided to the subject. This therapy data may be useful for the subject, a health care provider, or other users (e.g., parents or guardians) to actively manage the subject's health condition. For example, the therapy data may be useful to determine whether a change to a therapy is desirable or to ensure that the intended therapy is being administered at the appropriate time. In other examples, the data may be used to generate an alert regarding the subject's health condition when the therapy data indicates that immediate attention is needed regarding the subject's health condition.

[0070] Various aspects of accessing therapeutic data or other types of data stored in the memory of the 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 associated with data transfer management, may be associated with specific computer-executable instructions stored and executed by the control and computing module 610 of the AMD 600. Thus, the various AMD configurations used for various data transfer management tasks may be configurations of the control and computing module 610 of the AMD 600.

[0071] Accessing data from a portable medical device can be problematic in some cases. For example, accessing the data may require the user to connect the portable medical device to a computer and upload the data. This places a burden on the user to remember to connect the portable medical device. Furthermore, the subject may not be receiving treatment from the portable medical device during the period the device is connected to the computer. In some cases, the subject may not be able to connect the device to the computer (e.g., if the AMD is not within range of the local device) and may not have someone available to assist the subject. Therefore, a computing system (e.g., a healthcare provider's computing system) that can securely share data (e.g., treatment data) with authorized users is required. Direct end-to-end connectivity to data centers (data centers, data processing systems) can facilitate data management and access.

[0072] 14 is a block diagram illustrating an example network configuration in which an AMD 1402 is directly connected to a computing system 1404. The computing system 1404 may be part of a networked computing environment 1408 (e.g., a data center, a networked computing system), may be a cloud network 1406, or a cloud computing system of a cloud service provider. The computing system may include one or more non-transient memories and one or more hardware processors configured to execute computer-executable instructions stored in the one or more non-transient memories. In some such examples, a procedure performed by the computing system may be associated with the execution of certain computer-executable instructions stored in the computing system's memory by the computing system's hardware processor.

[0073] In some examples, a direct end-to-end data connection may be supported by one or more transceivers in the AMD's communication 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 relay systems using various wireless standards and technologies (e.g., 4G, 5G, etc.). In some examples, the transceiver may support communication over a communication standard, including, but not limited to, a low power wide area network (LPWAN), a narrowband long term evolution (NB-LTE), a narrowband Internet of Things (NB-IoT), or a long term evolution machine type communication (LTE-MTC). In some cases, the transceiver is always on, and in other cases, the transceiver may be activated when a data transfer is scheduled, requested, or activated. In some cases, the ability of the portable medical device 1402 to communicate with a computing system may be activated during manufacturing or prior to providing the device to the subject.

[0074] In some cases, the subject or user establishes or initiates the establishment of a direct end-to-end data connection with the computing system. For example, the subject may interact with a user interface to cause the portable medical device to communicate with a cloud computing service. In other cases, the direct end-to-end data connection may be initiated or established without any action by the subject or user. For example, the direct end-to-end data connection may occur automatically at a particular time or when the portable medical device is in a particular location. This automatic connection may occur using information provided to the portable medical device when manufactured, shipped, sold, or prescribed to the subject. Additionally, in some cases, the portable medical device may communicate with the computing system without access to a wifi network or local area network (LAN). For example, the portable medical device may communicate using a cellular or other wide area network. Additionally, in some cases, the user's interaction with the portable medical device may be relatively minimal or simple compared to traditional network communication. For example, the user may press a single button (e.g., an "upload" button) to trigger the establishment of a connection with the cloud computing service and cause the portable medical device to provide data to the cloud computing service.

[0075] In some cases, the portable medical device may be powered on and paired with a wireless wide area network (e.g., a cellular network) at the time of manufacture or before being provided to the subject. Additionally, the portable medical device may be configured to communicate with a networked computer as part of the manufacturing process. The authentication may be performed in a computing environment.

[0076] Additionally, establishing the direct end-to-end data connection may include determining that the portable medical device is authorized to communicate with the computing system based at least in part on the device identifier.

[0077] In some implementations, establishing a direct end-to-end data connection may include determining that the portable medical device is authorized to communicate with the computing system based at least in part on a device identifier associated with the portable medical device. The device identifier may be a unique identifier specific to the portable medical device. 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 subject identifier of a subject receiving treatment from the portable medical device.

[0078] Additionally, establishing the direct end-to-end data connection may include determining that the portable medical device is authorized to communicate with the computing system based at least in part on the device identifier. The device identifier may be initially provided to the networked computing environment prior to providing the portable medical device to the subject. For example, the device identifier may be initially provided to the networked computing environment as part of a manufacturing process for producing the portable medical device. The request may include a device identifier associated with the portable medical device.

[0079] The portable medical device may be configured to at least identify the computing systems 1404 of the networked computing environment 1408 based on a whitelist of one or more approved computing systems. The whitelist may be stored in a memory (e.g., memory in the AMD control and computing module) of the portable medical device 1402. Additionally, the whitelist may be configured during manufacturing of the portable medical device. For example, the whitelist may be configured with connection information for establishing communication with one or more computing systems of the networked computing environment. Additionally, the portable medical device may be configured to at least obtain an address of the computing system from the whitelist and use the address to establish a direct end-to-end data connection to the computing system of the networked computing environment over a wireless wide area network. The whitelist may include a unique identifier, such as a MAC address or a static IP address, associated with the computing system of the cloud service provider.

[0080] To enhance security, the portable medical device can use a whitelist that identifies authorized cloud servers or computing systems in the networked computing environment via a unique identifier (e.g., via an IP address, MAC address, or URL). Additionally, the cloud computing service may have a whitelist that specifies which portable medical devices and / or other computing systems (e.g., remote display systems) are allowed to communicate with the cloud computing system using a unique identifier.

[0081] When the AMD communicates data over a network, there is a risk of data leakage. Therefore, to improve security, all communications between the portable medical device and the computing device may be based on a secure data transmission method. For example, the portable medical device may encrypt all data using an asymmetric key.

[0082] In some instances, the treatment data is encrypted before being transferred to a computing system. In some such cases, the public key may be associated with a time-to-live (TTL) value. ...

[0083] Additionally, the secure data transmission may include generating a shared secret based at least in part on the public key and the private key. In some such cases, decrypting the encrypted data includes decrypting the encrypted data 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).

[0084] In some cases, the computing system may be configured to transfer the data after receiving a request to transfer the data stored on the portable medical device to the computing system via a direct end-to-end data connection over the wireless wide area network. In response to receiving a request to transfer the data stored on the portable medical device to the computing system, the computing system may be configured to receive via the direct end-to-end data connection.

[0085] Once a connection is established and the treatment data is transferred to the computing system, the computing system can analyze the treatment data received from the portable medical device and generate a treatment report. Additionally, the computing system can detect an alarm condition based on the treatment data analysis and generate an alarm that can be provided to an authorized user (e.g., a medical care provider) who is the subject. In some cases, the treatment data can trigger an automatic response by the computing system. For example, the AMD can determine that a medication or another disposable is low based on the received data and can automatically reorder the medication or disposable.

[0086] In some cases, the computing system may receive data from the portable medical device periodically based on a regular schedule. Alternatively, or in addition, the data may be received in response to a command or when the portable medical device is determined to be within a particular location. For example, when the portable medical device is determined to be at the subject's home or at a medical care provider's clinic based on a local area network connection or based on a location information system (e.g., Global Positioning System (GPS)). In some implementations, the additional encrypted data is received intermittently from the portable medical device. Alternatively, or in addition, the additional encrypted data is received from the portable medical device continuously for at least a period of time. The portable medical device may be configured to transmit data as the data is generated, or immediately after data generation (e.g., in real-time or near real-time (e.g., within milliseconds, seconds, or minutes of the data being generated)), or in bulk for a specified period of time. Transmitting a large amount of data for a specified period of time may increase battery life but may not provide the most up-to-date analysis. Data may be made available on demand by keeping the transceiver always on, but this may consume more power. Therefore, the scheduling of data transfers is done in accordance with the following two principles: (1) Power Consumption A balance can be struck based on various considerations, including (1) the cost of providing the information, and (2) the need to share the information with authorized users or systems.

[0087] In some cases, the computing system may be used as a backup for the portable medical device. For example, the portable medical device can back up data to the computing system every night when charging or when near home or the clinic (e.g., when the subject is in the waiting room, the device can upload data that the physician can access). Additionally, when the portable medical device is replaced (e.g., for a new model or to replace a damaged device), the device can automatically sync with the computing system to obtain subject-specific configuration or therapy control data.

[0088] Treatment Data and Treatment Reports In some examples, the treatment data includes dosage or administration data corresponding to one or more doses of a medication provided to the subject by the portable medical device. Additionally, the treatment data can include subject data corresponding to a medical or physiological condition of the subject determined by the portable medical device.

[0089] In other examples, the data provided to the computing system can include any type of data that can be measured or obtained by the portable medical device, and can include a record of the treatment provided by the portable medical device. For example, the data can include the time the treatment was provided, the amount of medication provided as part of the treatment, a baseline of one or more vital signs of the subject, a baseline of the subject's blood glucose levels at different times, the location of the subject, etc.

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

[0091] In some cases, the data transferred to the computing system may include operational data corresponding to the operation of the portable medical device. Alternatively, or in addition, the data may further include error data corresponding to an error in the operation of the portable medical device.

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

[0093] 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 a portable medical device to a format that may be stored or processed on a computing system. 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 format that may be understood by different types of users. For example, the data may be presented in one format for a healthcare provider (e.g., sensor readings), a simplified format for the subject or the subject's parent, and other data formats for displaying the data to different types of users. Good too.

[0094] In some examples, treatment data collected from different AMDs associated with multiple subjects may be aggregated for groups of subjects based on the association of these subjects with a facility or organization (e.g., a clinic, an insurance company, etc.).

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

[0096] In some examples, the treatment report may be sent to the AMD and the subject may view the report via a user interface (e.g., a touch screen display).

[0097] In some cases, the portable device data and / or data generated by the computing system based on the portable device data can be viewed on a secondary display system from the computing system. For example, a clinician or parent can access the data from their 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 can be granted or controlled by the end user (e.g., subject or guardian).

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

[0099] In some cases, the computing system may be configured to at least receive requests 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 professional 1414 (e.g., a doctor, a nurse, etc.), a guardian of the subject 1416 (e.g., a parent of the subject), an authorized user 1418 (e.g., a user authorized by the subject, such as a spouse, relative, friend, etc.), a medical care provider 1410, or a subject's device 1412 (e.g., a mobile phone, a personal computer, a tablet, etc.).

[0100] In some examples, the display system may be a therapeutic data management system that analyzes therapeutic data associated with a particular type of health problem (e.g., data associated with managing diabetes) and provides useful information to a subject or authorized user for monitoring and managing the corresponding disease.

[0101] The request 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 subject. 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. Additionally, the computing system may store a unique identifier associated with the account identifier. The system may be configured to determine whether an associated account is authorized to view the treatment report. In some examples, account permissions may be granted and / or changed by the subject. For example, the subject may access an account in the networked computing environment 1408, e.g., a cloud service provider associated with the subject, and provide one or more identifiers associated with one or more other users to grant permission to access the subject's treatment data or reports stored on the computing system.

[0102] In response to determining that the account is authorized to view the treatment report, the hardware processor can be configured to transmit the treatment report to the display system via an encrypted communications channel.

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

[0104] FIG. 15 is a flow diagram illustrating an exemplary method that may be used by the computing system 1404 to generate and share a treatment report based on encrypted treatment data received from the AMD 1402. In some examples, the AMD 1402 may generate the encrypted treatment data using a public key and a private key. The method may include establishing 1502 a direct end-to-end data connection to the portable medical device via a wireless wide area network (WAN) using, for example, a narrowband long term evolution (NB-LTE) transceiver included in the AMD 1402. Once the direct end-to-end data connection between the AMD 1402 and the computing system 1404 is established, the computing system may receive 1504 a public key (e.g., associated with the encrypted data) from the AMD 1402 via the established connection. The computing system may then receive 1506 a request from the AMD to transfer data (e.g., treatment data) stored in the portable medical device 1402 to the computing system 1404 via the direct end-to-end data connection. In some examples, the computing system 1404 may use a device ID associated with the AMD 1402 to determine whether the AMD 1402 is authorized to transfer data to the computing system 1504. If it is determined based on the device ID that the AMD 1402 is authorized to transfer data to the computing system, the encrypted therapy data may be transferred to the computing system (1512). If it is determined based on the device ID that the AMD 1402 is not authorized to transfer data to the computing system, the request may be denied (1510). The computing system may decrypt (1514) the encrypted therapy data using a private key (e.g., stored in a memory of the computing system) and a public key received from the AMD 1402. In some examples, the therapy data may be used to generate (1516) a therapy report.In some examples, the decoded treatment data and / or the treatment report may be stored in a memory of the computing system 1404.

[0105] An exemplary method includes a display system that is separate from the networked computing environment. The method may further include receiving (1518) a request to access the treatment report from the system 1410. The request may include an account identifier associated with a user generating the request. The method may include using the account identifier to determine whether an account associated with the account identifier is authorized to view the treatment report. The computing system determines that the account associated with the received account identifier does not have the required permissions and the request is denied (1524). In response to determining that the account is authorized to view the treatment report, the method may include transmitting the treatment report to a display system over an encrypted communication channel.

[0106] In certain implementations, the method can further include determining that the therapy data or other data received from the AMD meets an alert threshold condition. In these implementations, the therapy data or other data received from the AMD is determined to meet the alert threshold condition, and the computing system can send an alert to one or more display systems designated to receive alerts from the computing system.

[0107] In some examples, the alert threshold condition may be associated with a health state of the subject. For example, the alert threshold condition may include the subject's blood glucose level being above or below a set value (hyperglycemia or hypoglycemia). In some other examples, the alert threshold condition may be associated with the operation of AMD. For example, the alert threshold condition may include the rate of therapy (e.g., the rate at which insulin is provided to the subject) being above or below a set value.

[0108] In some other 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 include a high or low or fluctuation in the subject's blood glucose level exceeding a set value.

[0109] In some examples, the alert threshold conditions may be defined or set by a health care provider. In some such examples, the health care provider can modify one or more of the alert threshold conditions based on the subject's health condition.

[0110] FIG. 16 is a block diagram illustrating an example 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 1619 (e.g., an alert message, an alert signal, etc.) upon determining that data 1607 received from the AMD meets a threshold condition. The computing system 1604 may be part of a networked computing environment 1608 (e.g., a data center, a networked computing system) or may be a cloud network 1606 or a cloud computing system of a cloud service provider. The computing system may include one or more non-transient memories and one or more hardware processors configured to execute computer-executable instructions stored in the one or more non-transient memories. The AMD may receive data from one or more medical sensors 1605 (e.g., analyte sensors, temperature sensors, heart rate sensors, etc.) and / or one or more environmental sensors (e.g., location receivers, motion sensors, accelerometers, etc.). These sensors may be included in the AMD unit or may be connected to the AMD via a wired or wireless link.

[0111] In some cases, the display system that receives the alert 1611 may be a computing system. The display system may be one that already receives treatment reports from the AMD 1604. In other examples, a group of display systems may be selected and authorized by the subject receiving treatment from the AMD to receive the alert 1611. Display systems that may receive the alert 1611 from the AMD may include a medical professional 1614 (e.g., a doctor, a nurse, etc.), the subject's guardian 1616 (e.g., the subject's parents), an emergency service provider 1618, an authorized user 1420 (e.g., a user authorized by the subject, such as a spouse, relative, friend, etc.), a medical care provider 1622, or the subject's device 1612 (e.g., a mobile phone, a personal computer, a tablet, etc.). In some examples, in addition to sending an alert to one or more display systems 1610, the computing system 1604 may send an alert 1609 to the AMD 1602 if the AMD determines the received data 1607 meets the threshold condition.

[0112] In some examples, the AMD 1602 may be configured to establish a connection that supports continuous data transfer to the computing system 1604 over a predetermined period of time to capture any data generated over that period (e.g., provided to the AMD by the subject) and that meets an alert threshold condition. For example, a subject may request a continuous connection between the AMD and a computing system when going hiking alone to ensure that an alert is sent to an authorized display system if a health condition deteriorates during the hike.

[0113] In some examples, location sensors (e.g., a Global Positioning System (GPS) receiver) and / or proximity sensors may be used to enable location-based functionality such as automatic uploading of data at a particular location.

[0114] In some cases, the portable medical device may include or be connected to an accelerometer or a location information system. This speed of the portable medical device may be determined based at least in part on the accelerometer or location information system. Using the data 1607 obtained from the portable medical device 1602, including the location and / or speed information, the computing system 1604 can provide intelligent alerts. For example, if the data indicates that the user is moving at a high speed (e.g., likely traveling by car) and the user's blood glucose level is low (e.g., less than 55 mg / dl), the computing system can automatically alert emergency services 1618 that the subject is at risk for hypoglycemia and may be driving. Additionally, the computing system can provide the subject's location to the emergency services provider 1618.

[0115] In some examples, the computing system may generate an alert 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.

[0116] Additionally, location and / or motion sensors (e.g., accelerometers) can be used to detect the subject's speed to enable intelligent motion sensing alerts. For example, if the subject is traveling at 60 miles per hour and is experiencing hypoglycemia, the system can enable a set of driving alerts and possibly schedule future treatment. The driving alert can notify the subject to immediately stop due to the risk of a hypoglycemic event. Additionally, emergency responders can be notified of the subject's location based on information obtained from the location sensors. If the subject is traveling at 6-7 miles per hour, for example, a motion alert can be enabled to alert the user to cease exercise and beware of hypoglycemia. If the subject has not moved for 3 hours and has low blood glucose, the system can enable automatic notification to emergency services. Additionally, the determination of the subject's movement can be used to automatically adjust the set point (e.g., increase the set point during exercise). It can sense a subject's activity level and be used for alerts and improved treatment.

[0117] Additionally, the cloud server can send text messages or calls to the follower and / or end user's phone or smart device when the treatment data meets an alert threshold. These messages can be provided from the cloud computing system to third party devices when roaming or deactivation of data plans occurs on the portable medical device (e.g., when no TCP / IP is available). Furthermore, the cloud computing service can send text messages or call 911 when an emergency is detected. The cloud server can track the end user's most recent location, e.g., via GPS, and share that information with the follower and / or emergency personnel. Additionally, the cloud computing system can enable the end user to order and reorder medical supplies directly from the viewing device.

[0118] Additionally, the computing system may generate notifications (e.g., generate a message when there is a risk of hypoglycemia) and further processing in the cloud may result in improved recommendations (e.g., Tmax, set points, or other control parameters).

[0119] FIG. 17 is a flow diagram illustrating an example method that may be used by the 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 the AMD. The method may include establishing (1702) a direct end-to-end data connection to the portable medical device over a wireless wide area network (WAN) using, for example, 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 predetermined period of time set by the subject or an authorized user (e.g., the subject's guardian). Once the direct end-to-end data connection between the AMD 1602 and the computing system 1604 is established, the computing system may receive (1704) a public key from the AMD 1602 over the established connection. The computing system may then receive (1706) a request from the AMD to transfer data generated by the portable medical device 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 may include a period during which the AMD will continuously transmit any 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 by the AMD subject or the subject's guardian. In some examples, the computing system 1604 may use a device ID associated with the AMD 1602 to determine whether the AMD 1602 is authorized to transfer data to the computing system 1604. If it is determined based on the device ID that the AMD 1602 is authorized to transfer data to the computing system 1604, the encrypted therapy data may be transferred 1712 to the computing system 1604.If it is determined based on the device ID that the AMD 1602 is not authorized to transfer data to the computing system, the request may be denied (1610). The computing system 1604 may decrypt (1714) the received data using a private key (e.g., stored in memory of the computing system 1604) and the public key received (1702) from the AMD 1602. In some examples, the computing system 1604 may decrypt (1714) the received data (e.g., therapy data, medical sensor data, or environmental. It may be determined (1716) whether the sensor data) satisfies a threshold condition. In some cases, the threshold condition may be provided to the AMD by the subject or an authorized user (e.g., the subject's guardian). In some other examples, the threshold condition may be provided by a medical care provider. In some such examples, the threshold condition may be stored in the memory of the AMD. If the data is determined to meet the threshold condition, an alert may be generated and transmitted (1718) to one or more display systems 1610 authorized (e.g., by the subject or the subject's guardian) to receive the alert. In some examples, the subject or guardian may authorize one or more display systems 1610 to receive the alert by providing an account ID of the one or more display systems to the computing system 1604 or the networked computing environment 1608.

[0120] Preventing inadvertent changes to treatment As mentioned above, the portable medication device may include a user interface (e.g., a touchscreen interface or a non-touchscreen interface) that can present one or more user interface screens to a user, allowing the user to change one or more treatment settings of the portable medication device, such as the amount of medication delivered when a condition is met, or the conditions that trigger delivery of the medication to the subject. The user may be the subject receiving the medication or treatment, or may be another user, such as a clinician or health care provider, or a parent or guardian. In portable medication devices that include a user interface, there is a risk that settings may be accidentally changed or changed (intentionally or unintentionally) by a user who does not fully understand what they are doing (e.g., a child or a user with reduced mental capacity). Additionally, the portable medication device may have settings accidentally changed by inadvertent interaction with the user interface, such as may occur when the portable medication device is worn on the subject's body.

[0121] This section relates to an portable medication device (AMD) for preventing inadvertent changes in medication delivery, for example, when settings on the AMD are accidentally changed by a user or inadvertent interaction with a user interface.

[0122] As described above, in some embodiments, the user can use the user interface to change the control or configuration of the AMD. The control or configuration of the AMD may be changed by the user interface inadvertently. For example, when the user may move the portable medical device, the user may inadvertently activate the input of the portable medical device (e.g., by applying pressure to the portable medical device, which may be placed in the user's jacket pocket) that initiates a treatment change input.

[0123] 18, in some such embodiments, the control and computing module (CCM) of the AMD may include a set of therapy change procedures 1828 implemented to prevent inadvertent therapy change input 1829. The therapy change procedures 1828 may be implemented as instructions stored in the CCM's memory (e.g., main memory 616) and executed by the processor 614. The therapy change input 1829 received from the user 1827 may be verified by the therapy change procedures 1828 before the portable medical device 600 provides a therapy change delivery 1807. All user interactions with the user interface module 1808 may be controlled and analyzed by the control and computing module (CCM) 610 via one or more therapy change procedures 1828.

[0124] In these embodiments, the user 1827 interacts with the wake interface 1822. The AMD can be woken or unlocked by the wake interface 1822. The wake interface 1822 can be any of the additional user interfaces described above that are configured to generate a wake input to the CCM upon detecting a pre-configured user interaction.

[0125] The therapy change input 1829 can be an input provided by the user 1827 to change a therapy currently being delivered to the user 1827. In some embodiments, the therapy change input 1829 can cause an insulin or glucagon infusion pump to begin infusing an amount of insulin or glucagon to the user 1827. Alternatively, the therapy change input 1829 can change the infusion rate of insulin or glucagon to the user 1827. The therapy change input 1829 can also cancel an insulin or glucagon infusion to the user 1827 from an insulin or glucagon infusion pump.

[0126] When a wake action is detected by the wake interface 1822, a wake input is sent to the control and computing module 610, where the wake input mimics a wake control procedure 1834 that generates a wake signal to wake / unlock the user interface (e.g., a touchscreen display).

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

[0128] 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 sends an input signal to the control and computing module 610, which is analyzed by the therapy change control procedure 1836. If the first user interaction is determined to satisfy a set of predetermined conditions, the therapy change control procedure 1836 generates a signal to the user interface module 1808 to activate the therapy change user interface.

[0129] In some embodiments, the therapy change user interface may be restricted based on a first user interaction. For example, the therapy change control procedure 1836 may send one of two signals to the user interface module 1808. The therapy change user interface may then unlock one of two different therapy change user interfaces resulting in different options of therapy change selection for the user 1827. In this example implementation, a therapy change selection to make a significant therapy change, such as dramatically increasing an insulin or glucagon infusion rate, requires a first user interaction that is different from the first user interaction required for insulin or glucagon infusion at a normal or predetermined rate. In some examples, the first user interaction may be a simple interaction (e.g., a simple gesture) that unlocks the therapy change user interface with limited therapy change selections. Another first 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 can perform a first gesture consisting of a series of simple inputs to unlock restricted therapy change selections, and an adult user can perform a first gesture consisting of a series of complex inputs to unlock the therapy change user interface with unrestricted therapy change selections.

[0130] When activated, the therapy change user interface can provide one or more control elements or components that allow the user to change the control or configuration of the portable medication device. The control elements or components can include any type of user interface screen on a touch screen, or other type of user interface in a non-touch screen context, that allows or enables the user to change the configuration of the portable medication device. This change in the configuration of the portable medication device can be related to a change in the therapy provided, or a change in the detection of a trigger event that causes the subject to provide a therapy (e.g., medication). For example, the change in configuration can include a selection between one or more hormones (e.g., insulin or glucagon) that regulate the user's blood glucose level, the amount of one or more hormones that regulate the user's blood glucose level.

[0131] In some cases, changes to the configuration of the portable medication device are automatically and / or immediately recognized or implemented by and / or transmitted to the portable medication device, in other cases confirmation of the change may be required before the change is implemented by or transmitted to the portable medication device.

[0132] The confirmation may be entered based on a second user interaction with a user interface (e.g., touchscreen display 1824). If the second user interaction is detected, the user interface module 1808 sends an input signal to the control and computing module 2110, 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.

[0133] The first and / or second user interaction may include the selection of an icon, a series of taps or inputs, one or more gestures (e.g., linear swipes, arcuate swipes, circular swipes, or other simple or complex movements across the touchscreen), performing a pattern or sequence on the touchscreen (e.g., drawing an image), a multi-touch or multi-input interaction, a combination of the foregoing, or any other type of interaction with the touchscreen, or a portion thereof. The series of inputs may be any combination of touch actions, touch points, numbers, alphabetic characters, and other symbols. The gesture interaction may be guided by visual indicia displayed or printed on the AMD. In some embodiments, the visual indicia may include an animation that suggests or guides a user interaction with the touchscreen. For example, the first user interaction may include an arcuate swipe around at least a portion of a generally circular icon or logo. In some examples, the first and / or second user interaction may include a predetermined sequence of numeric or alphabetic inputs. In some examples, a series of multiple inputs, a range of parameters for 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 that a series of inputs is entered may also be part of the range of parameters. For example, a series of inputs may need to be entered in 3 seconds or more, and 15 seconds or less, or less than 15 seconds.

[0134] Additionally, one or more of the interactions may include interactions with sensors such as an optical sensor (e.g., visible light or IR sensor), a biometric sensor (e.g., fingerprint or retina 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 sequence of numeric inputs to deliver a therapy change selection.

[0135] The types of user interactions that unlock the touch screen, provide access to a configuration screen, and / or confirm changes to the configuration of the portable medication device may be the same or different.

[0136] In an exemplary embodiment, the system can have a timeout such that if no interaction occurs for a set period of time, the user interface is turned off and the therapy change request process must be started again. In one implementation of the timeout, the user interface is deactivated if no interaction occurs for more than 30 seconds after the system is woken / unlocked before a second user interaction is received by the user interface.

[0137] Once the configuration changes have been confirmed, implemented or transmitted, the portable medication device can begin operating with the changed configuration.

[0138] The action may include triggering a therapy based on the new configuration or providing a therapy based on the new configuration. For example, the portable medication device may generate a dose control signal based at least in part on the changed configuration or control parameter, or may detect a trigger based at least in part on the changed configuration or control parameter that leads to the delivery of a therapy.

[0139] 18, in some embodiments, changes made through the therapy change user interface are sent to the CCM, and a therapy control change procedure 1836 in the CCM forwards the changes to the device and subject monitoring procedure 1832. The device and subject monitoring procedure 1832 may be implemented in the CCM 610 to monitor the status of the AMD (e.g., therapy delivery configuration) and the health of the user 1827 (or subject). For example, the subject monitoring procedure 1832 may 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 subject's blood from the subject sensor 1820. The device and subject monitoring procedure 1832 may then send information regarding the subject's health and / or AMD configuration to the drug dosage control procedure 1830. In some examples, parameters in the drug dosage control procedure 1830 may be adjusted based on changes and / or information captured by the device and subject monitoring procedure 1832. The drug dosage control procedure 1830 controls the drug delivery interface 1806 by providing a drug dosage signal. The drug dosage control may be generated based on a detected subject condition or physiological characteristic (e.g., provided by readings of the subject sensor 1820) and according to parameter values ​​received from the therapy change control procedure 1836. The drug delivery interface 1806 may provide therapy change delivery to the user according to information received by the device and subject monitoring procedure 1832.

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

[0141] 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 a portable medication device using a touch screen user interface. The user can initiate the configuration change process by waking / unlocking the touch screen using a wake action. When a wake action is received by the interface (1902), the wake interface sends a wake input to the CCM (1904). Within the CCM, a wake procedure generates a wake signal (1906), which unlocks the touch screen (1908). Then, in response to receiving a first gesture by the user (1910), the therapy change user interface is unlocked (1912). Using one or more therapy control elements or components provided in the therapy change user interface, the user can change the therapy configuration (1914). The user can confirm the change made by providing a second gesture on the touch screen (1916). Once confirmation is received (1916), the requested change is implemented and the portable medication device can begin operating with the changed configuration. In some examples, once the user confirms the change made, a dose control signal can be sent to the medication delivery interface 1806 that triggers a therapy change delivery to the subject.

[0142] In some cases, the portable medication device, or a control device that allows a user to change the configuration of the portable medication device, may have a timeout feature. The timeout feature may put the portable medication device or control device into a sleep or lock state after a period of inactivity by the user. In some cases, the timeout feature may put the portable medication device or control device into a sleep or lock state after a certain period of time, regardless of whether the user is interacting with the portable medication device or control device. Thus, the user may have a limited period of time to change the configuration of the portable medication device.

[0143] 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 after a set time period from receiving the confirmation.

[0144] In some embodiments of the AMD, an alarm status indicator may be presented to the user via a user interface. The alarm status indicator may be an alert message or an alert symbol. The alarm status indicator may be related to a configuration change made by the user, a change in the status of the AMD not related to user input, or a subject's condition (e.g., detected by a subject sensor).

[0145] FIG. 20A is a diagram of an exemplary AMD touchscreen display 2000 after the touchscreen has been woken / unlocked by a user's wake action and before a first user gesture is received. Even while the touchscreen display is locked, the touchscreen display 2000 can display any image, animation, text, or other graphics. A first gesture prompt 2005 displays 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 starting with a greater than symbol and moving right across the "unlock" text is the first gesture that can be accepted. In addition to the first gesture prompt, the refill status of the portable medical device 600 is shown in a graphical display 2010. Here, the graphical display 2010 indicates that the insulin cartridge in the portable medical device 600 is almost full. A 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 cartridge of glucagon 2020. A graphical representation of an alarm 2025 on the touch screen display 2000 indicates that an alert has been set on the portable medical device 600.

[0146] FIG. 20B is a diagram of an exemplary touchscreen display 2050 that can prompt the user to enter a predetermined sequence of inputs for the 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 sequence of numbers as part of the first or second gesture. The sequence of numbers being typed by the user 1827 is displayed in field 2065 as it is entered as an aid to the user 1827. An input 2070 on the touchscreen display 2050 indicates that a swipe touch action across the bottom of the screen to the right is required to complete the predetermined sequence of inputs for the first or second gesture. A Bluetooth connection symbol 2075 indicates that the portable medical device 600 is paired or available to be paired with another electronic device.

[0147] FIG. 20C is an illustration of an exemplary therapy change user interface (in this case, a touch screen display 2002). The touch screen display can prompt the user 1827 to select a hormone that will regulate blood glucose levels. The touch screen display 2002 presents the user 1827 with the option to select between two hormones. The touch screen display 2002 assists the user 1827 by showing the user's 1827 selection 2008. The selected hormone is "insulin only" 2008. The user 1827 is also given the option to select the hormone glucagon only button 2012, or both insulin and glucagon button 2004, to regulate blood glucose levels. Once the user 1827 has selected one or more hormones that will regulate blood glucose levels. A next button 2014 can be selected to complete the therapy change selection or to select additional options. In one embodiment, to select additional options, the therapy change user interface prompts the user 1827 to select an amount of one or more hormones that will regulate the user's 1827 blood glucose levels. In other embodiments, the user 1827 may be prompted to select the blood glucose level and the portable medical device 200 may select the hormone and amount of hormone.

[0148] FIG. 20D is an illustration of another therapy change user interface on the touch screen display 2016. Here, the user 1827 is provided with multiple options. One or more options in the therapy change user interface allow the user 1827 to make a therapy change selection. Other options are related to therapy change selection. A hormone delivery button 2030 allows the user 1827 to select a therapy change that delivers a hormone to the user 1827 that regulates blood glucose. A blood glucose test button 2018 allows the user 1827 to test the user's 1827 blood glucose level. A report generation button 2020 generates a document reporting the therapy change delivered to the user 1827. A cartridge refill button 2022 allows the user 1827 to fill a cartridge in the portable medical device 600 with medication. A cloud upload 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 voice emitted by the portable medical device 600. The settings button 2028 allows the user 1827 to manipulate other settings of the portable medical device 600 .

[0149] 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 in the AMD configuration.

[0150] For example, referring to FIG. 18, a user 1827 may use the user interface to make a therapy change 1829 based on the procedure shown in FIG. 19. Once the therapy change procedure 1836 implements the therapy change, the AMD may alert the user that a therapy change will be implemented. An alert message or symbol may be presented on the user interface (e.g., a touch screen display) prior to and / or during the therapy change delivery 1807. For example, an alarm indicator may inform the user 1827 that a therapy change is about to occur. Any number of details of the therapy change may be displayed as part of the alert message or symbol. In some cases, an alarm status indicator may appear after the user unlocks or wakes the user interface using a wake action.

[0151] FIG. 21 is a flow diagram illustrating an exemplary method that may be used by the AMD to generate an alarm status indicator. In some embodiments, the device and subject monitoring procedures (excluded in the CCM) may continuously monitor the status of the AMD (e.g., the user interface, various modules of the AMD, etc.) as well as the health of the subject (e.g., using various subject sensors such as analyte sensors). Once the status information is received (2104), the device and subject monitoring procedures may determine (2106) whether the received status information satisfies an alarm condition. If the received status information does not satisfy an alarm condition, no action is taken and the device and subject monitoring procedures continuously monitor the AMD and the subject. If it is determined that the received status information satisfies an alarm condition, the system searches for a wake signal (2108). If a wake signal is not detected, the system waits for a wake signal to be received (2110). When a wake signal is received via one or more user interfaces or sensors, the CCM may generate (2112) the display of a touch screen lock screen interface and display one or more alarm status indicators on the lock screen corresponding to the detected alarm condition.

[0152] In some embodiments, the AMD may allow a user to provide a therapy change and then cancel the therapy change. FIG. 22 is a flow diagram illustrating an exemplary method that may be used to cancel a therapy change using a touchscreen interface. A user may unlock the touchscreen display using a wake action (2202) and access (e.g., using a first gesture) a therapy change user interface that may display one or more therapy control elements (2204). An indication of the change to the therapy control element may then be received by the user interface (2206), followed by a confirmation of the change made (e.g., a second gesture) (2208). In response to receiving the indication and confirmation of the change to the therapy control element, the corresponding control parameter may be changed from a first setting to a second setting (2210). In some examples, once the change is implemented (2210), the user may decide to cancel the change, for example, after realizing that the requested change is in error. In these examples, the user may provide a third gesture on the touchscreen (2212). In response to receiving a third gesture from the user interface, the therapy change procedure can restore (2214) the changed 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. One example of a restore swipe gesture can be performed from a swipe start location to a swipe end location that is located closer to the left edge of the touch screen than the swipe start location. In some embodiments, the restore gesture is received on a different user interface screen than the therapy change user interface on which the one or more therapy control elements are provided. In various examples, the restore gesture can be received on a different user interface screen than the therapy change user interface on which the therapy control element or elements are provided. The therapy change confirmation gesture is performed in the opposite direction to confirm a change to a therapy control element.

[0153] In some examples, to cancel the therapy change request, a restore gesture must be provided within a set period of time after a confirmation gesture is received by the user interface. In some such examples, during the set period of time, one or more dose control signals can be provided to the drug delivery interface to effect one or more therapy change deliveries.

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

[0155] 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 other cases, the first setting or the third setting may be a restore setting.

[0156] FIG. 23A is an illustration of a touchscreen display 2300 alerting the user that delivery of one or more medications will occur. The alert may be accompanied by a sound or vibration effect. Here, the alert informs the user 1827 that delivery of medication will occur in 2 seconds (2305). The touchscreen display 2300 further allows the user 1827 to perform a gesture to cancel the therapy change. The gesture to cancel the delivery is a touch action that starts with a less-than symbol 2310 and swipes left on the "Cancel" text. In the embodiment shown in FIG. 23A, a single gesture by the user 1827 can cancel the therapy change. In the exemplary embodiment, 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.

[0157] In some examples, a user can cancel a therapy change delivery that was triggered based on a therapy change made by the user. In these examples, the user can use a wake action to access a user interface and provide a gesture to cancel the ongoing therapy that corresponds to the therapy change delivery.

[0158] FIG. 23B is an illustration of a touch screen display 2350 showing that medication is being delivered to the user 1827. Delivering text 2355 informs the user 1827 that medication is currently being delivered to the user 1827. Progress bar 2360 is a graphical representation of the progress of the delivery. As shown in FIG. 23B, the delivery has just started and the progress is 0. The touch screen display 2350 allows the user 1827 to perform gestures to cancel the delivery, including pausing and aborting the delivery if the delivery has already started but is not yet complete. The gesture to cancel the delivery is a touch action that starts with a less than symbol 2365 and swipes left on the "Cancel" text. In the exemplary embodiment shown in FIG. 23B, the therapy change delivery 1807 may be canceled by an input by the user 1827. The input to cancel the therapy change delivery 1807 may be any input, such as a wake signal input, or a series of touch inputs, such as a gesture.

[0159] Additional embodiments relating to interacting with a portable medication device that may be combined with one or more embodiments of the present disclosure are described in U.S. Provisional Patent Application No. 62 / 874,950, entitled “PREVENTING INADVERTENT THERAPY CHANGES ON AN AMBULATORY MEDICAL DEVICE,” filed July 16, 2019, the disclosure of which is incorporated by reference in its entirety for all purposes. The present application is incorporated herein by reference in its entirety, and is hereby incorporated by reference in its entirety. No. 62 / 874,954, entitled "IMPROVED HYDROPHTHALMIC IMPROVEMENT DEVICE," the disclosure of which is incorporated herein by reference in its entirety for all purposes.

[0160] Automatic resumption of drug delivery after manual interruption In some cases, it may be desirable to suspend the operation of the portable drug device or at least suspend the delivery of a drug by the portable drug device for a period of time. For example, it may be desirable to suspend the operation related to the delivery of a drug when a drug reservoir or cartridge in the portable drug device is empty or requires replacement. As another example, it may be desirable to suspend the delivery of a drug when the portable drug device is removed or moved to another site on the subject. In yet another example, it may be desirable to suspend the delivery of a drug when the subject is taking or ingesting another drug that may pose a contraindication to the drug provided by the portable drug device. In some cases, when a subject suspends a treatment delivered by a medical device, the subject may forget to resume the treatment delivered by the medical device. In other cases, the subject's health condition may deteriorate during the suspension period, requiring a therapeutic delivery before the end of the suspension period. Thus, there is a need for an AMD that allows a subject to temporarily suspend a treatment safely.

[0161] In some embodiments, the AMD may support treatment suspension and resumption procedures that allow a user to suspend all or a subset of treatments for a user-defined period of time, as well as automatic resumption of one or more treatments upon the end of a requested suspension period or when a threshold condition (e.g., a threshold condition related to the subject's health status) is met.

[0162] 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). In some examples to mitigate this risk, the AMD can be configured to avoid inadvertent interruption or resumption of therapy. For example, inadvertent activation of a pause in drug delivery can be prevented by requiring the user to perform a gesture to activate the pause on the portable medical device. The gesture must be entered at a specific prompt to activate the therapy interruption.

[0163] One particular application of treatment interruption with automatic resumption in AMD may be in the field of diabetes drug delivery. For example, situations such as exercise, which have a blood glucose lowering effect, may require the ability to interrupt insulin delivery. Suspension of insulin delivery can prevent the subject from entering a hypoglycemic state (extreme hypoglycemia) with serious complications. When treatment is interrupted, the user is at risk of entering a hyperglycemic state (hyperglycemia that can result in complications such as diabetic ketoacidosis or neurovascular complications) if they forget to restart drug delivery after exercise. Furthermore, the subject's blood glucose level may rise above or below dangerous levels during periods of exercise. In these situations, automatic drug delivery resumption can improve the subject's health.

[0164] In certain cases, the AMD may suspend one or more treatment deliveries upon receiving an indication that the treatment (e.g., delivery of a drug) is to be suspended. The indication that the treatment is to be suspended may be a command from a user. In many cases, the user is the subject, but the user may also include other users who may have a say or interest in the subject's care. For example, the user may be a clinician or other medical care provider, or a parent or guardian.

[0165] In some examples, the indication that treatment or drug delivery is to be interrupted may be a command received via an interface of the portable drug device or from another device that provides an interface to the user to request that drug delivery be interrupted. For example, the device may be a smart watch, smartphone, laptop or desktop, or other control device that can communicate with the portable medical device via a wired or wireless connection.

[0166] In some cases, an indication that therapy or drug delivery is to be interrupted may be received from the portable drug device itself. For example, a signal to interrupt drug delivery may be generated if the amount of drug available to the portable drug device falls below a threshold (e.g., if a cartridge or reservoir is empty or falls below a minimum dosage). In some embodiments, the interruption of therapy occurs based on a loss of a sensor signal, such as a loss of a glucose level signal.

[0167] 24 illustrates the interconnections between modules and procedures involved in receiving, accepting, and / or canceling a treatment interruption request in an exemplary AMD. In some embodiments, a request to interrupt one or more therapies (e.g., delivery of one or more medications to a subject) can be made by a user 2427 by providing input 2429 (e.g., start and stop times for the treatment interruption, selection of the type of treatment to be interrupted, etc.) through a treatment interruption user interface provided by the user interface module 2408. The treatment interruption user interface sends the interruption request along with corresponding information to the CCM, and an interruption control procedure 2436 implemented in the CCM processes and transmits the treatment interruption signal to the device and subject monitoring procedure 2432. To prevent inadvertent treatment interruption request input 2429, the treatment interruption control procedure can include a treatment interruption request validation procedure for validating the treatment interruption request.

[0168] Device and subject monitoring procedures 2432 may be implemented in the CCM 210 to monitor the status of the AMD (e.g., therapy delivery configuration) and the health of the user 2427 (or subject). For example, upon receiving a request to suspend therapy, the subject monitoring procedures 2432 may send a signal to the drug dose control procedures 2430 indicating that a dose control signal should not be sent to the drug delivery interface 2406 during the period requested by the user 2427. In some cases, if certain pre-set conditions are met during the suspension period, the device and subject monitoring procedures 2432 automatically resume therapy delivery by sending a signal to the drug dose control 2430. For example, if during the suspension period, the subject sensor 2420 detects an increase in the level of one or more analytes in the subject's blood and / or interstitial fluid that exceeds a set threshold, the device and subject monitoring procedures may resume drug delivery to the subject 2427 by sending a dose control signal to the drug delivery interface 2406.

[0169] To prevent inadvertent activation of an interruption, a user can initiate a therapy interruption request that begins with a wake action (e.g., received by the wake interface 2422 and processed by a wake control procedure 2434) that activates the user interface module 2408. Using a first interaction with the user interface (e.g., a touch screen display), the user can unlock the 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 verified by the therapy interruption control procedure 2436.

[0170] In some examples, the therapy interruption control procedure 2436 may receive an interruption request and interruption information from another device connected to the portable medical device 600 (eg, via a communication module).

[0171] 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 beginning and ending the treatment interruption, thresholds required to define threshold conditions that may trigger early resumption of treatment delivery, etc. In some other examples, the interruption information may indicate that the interruption of treatment should occur at a particular time or after a particular event (e.g., after the next dose of medication is delivered or after the subject's condition reaches a particular state, such as the middle of a desired blood glucose range). In some examples, the thresholds may be associated with input provided by the subject sensor 2420 or other type of sensor that may be used to monitor one or more parameters associated with the health status of the user 2427.

[0172] The parameters of the interruption may include a start state and a stop state of the interruption. The start state of the interruption may be a state that, when met, activates the interruption. In some such examples, the start state is met when a timer expires. Similarly, the stop state is a state that, when met, ends the interruption. In one example, the stop state is met when a timer expires. In another example, the stop state is met when a threshold is met. The threshold may be related to a measurement taken by the portable medical device (e.g., by the subject sensor 2420), such as the glucose concentration of the user's blood. The threshold may be met if the glucose concentration is above, below, or meets a set concentration. Multiple states may be set by the interruption request interface component. For example, a time condition and a threshold condition may be set simultaneously. A user may specify that the interruption should end after a set time. However, if the user's glucose concentration meets the threshold, the interruption may end sooner than the set time.

[0173] In some cases, the request to suspend a therapy may include an indefinite suspension period. In other words, the request may not include a user-specified period or an identification of a resume state. In some other cases, the indication may include a request to temporarily suspend delivery of a therapy for a defined period or until further interaction or event occurs. Thus, a resume state may include the expiration of a time or an active event (e.g., a command or a determined state of the subject). Furthermore, the therapy to be suspended may include any type of therapy. For example, the therapy to be suspended may be the suspension of delivery of a medication, which may include insulin, an antagonist (e.g., glucagon), or both insulin and an antagonist. In some cases, the portable medication device may be capable of and / or configured to administer multiple medications (e.g., both insulin and an antagonist). In some such cases, the request to suspend a therapy may include a request to suspend one of these medications (e.g., insulin or an antagonist) or both.

[0174] An interaction with a user interface may include the selection of an icon, a series of taps or inputs, one or more gestures (e.g., swiping or other simple or complex movements across the touchscreen), performing a pattern or sequence on the touchscreen (e.g., drawing an image), a multi-touch or multi-input interaction, a combination of the foregoing, or any other type of interaction with a touchscreen, or a subset thereof. A series of inputs may be any combination of touch actions, touch points, numbers, alphabetic characters, and other symbols. In some examples, the first and / or second user interaction may include a predefined sequence of numeric or alphabetic inputs. In some examples, a series of multiple inputs, a range of parameters for an input may depend on other inputs in the series. For example, a required starting position of a touch action may be determined based on the position of a previous touch. The time at which the sequence of inputs is entered may also be part of the range of parameters. For example, the sequence of inputs may need to be entered in 3 seconds or more, or more than 3 seconds, and 15 seconds or less, or less than 15 seconds. In some cases, visual guides 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 pause the delivery of therapy.

[0175] Additionally, one or more of the interactions may include interactions with sensors such as an optical sensor (e.g., visible light or IR sensor), a biometric sensor (e.g., fingerprint or retina 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 sequence of numeric inputs to deliver a therapy change selection.

[0176] The type of user interaction that unlocks the touch screen, provides access to the therapy pause user interface, or confirms the pause request may be the same or different.

[0177] In an exemplary embodiment, the system can have timeouts such that if no interaction occurs for a set amount of time at each step in the treatment interruption request process, the user interface is turned off and the treatment interruption request process must be started again. In one implementation of the timeouts, the user interface is deactivated if no interaction occurs for more than 30 seconds after the system is woken / unlocked before a second user interaction is received by the user interface.

[0178] FIG. 25 is a flow diagram illustrating an exemplary method for receiving and implementing an interruption request that may be implemented by an AMD. In this example, a user may request and confirm a therapy interruption using a touchscreen interface. When the user activates the touchscreen using a wake action (2502), the AMD may wait for a first gesture on the touchscreen. After the user provides a first gesture and the gesture is verified by the therapy interruption control procedure 2436, a therapy user interface may be activated (2506) and the user may request a therapy interruption and provide interruption information (e.g., start date / time and stop date / time and / or resume status) (2508). The AMD may then wait for a second gesture on the user interface (2510). If a second gesture is received and verified by the therapy interruption control procedure 2436, therapy delivery is interrupted (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.

[0179] In some examples, when a wake action is received (2502), the AMD can automatically launch (2506) a therapy interruption user interface without requiring a first gesture (2504). In these examples, when a request to interrupt therapy is received (2508), a gesture (e.g., a first gesture) may be required to validate the request. In some such examples, when therapy delivery is interrupted, a second gesture may be required. The program can stop the interruption before any of the stop parameter conditions are met, allowing the user the flexibility to modify the initiated interruption.

[0180] FIG. 26 is a diagram 2600 of multiple screens that the portable medical device may display when a user activates a treatment interruption user interface. Screen 2602 illustrates a user interface that the portable medical device may display to the user 2427. The display may be a touch screen display 2424 that may accept inputs including the first and second gestures. The treatment interruption system 600 is not limited to the display illustrated in FIG. 26. A variety of displays may convey the same information illustrated in FIG. 26 to the user 2427. Screen 2602 allows the user 2427 to select a variety of functions. A pause button 2603 illustrated on screen 2602 is a function that interrupts the delivery of medication to the user 2427. When pause button 2603 is selected, the user 2427 is greeted with a pause screen 2604. The pause screen 2604 allows the user 2427 to select the duration of the medication interruption. The portable medical device 600 may display a variety of interfaces to allow the user 2427 to select the duration of the medication interruption. The pause screen 2604 shows a simple interface that gives the user 2427 one of two duration options.

[0181] When the user 2427 selects a duration on the pause screen 2604, the pause screen 2606 shows the user 2427 the duration 2607 selected by the user 2427 (e.g., in the figure the user 2427 selects one hour, thus drug delivery will be suspended for one hour after the suspension begins). The pause screen 2606 has a prompt 2608 for the user to make a gesture to confirm the requested suspension before the drug suspension begins. As indicated by the prompt 2608, the user 2427 is prompted to swipe right on the bottom of the screen. Once the user 2427 performs a gesture to initiate drug suspension, a pause screen 2610 is displayed on the touch screen. The pause screen 2610 informs the user 2427 that the drug will be paused. The user 2427 has the option to perform another gesture to unlock the portable medical device. A prompt 2612 for the user 2427 to unlock the device causes the user to perform another swipe to perform more functions on the portable medical device 600.

[0182] Interrupting drug delivery can occur by not generating a dose control signal to deliver a dose of drug. Alternatively, or in addition, interrupting drug delivery may occur by sending a signal to the drug pump to cease providing therapy or drug to the subject.

[0183] In some cases, the portable drug device may not immediately suspend therapy upon receiving a command to suspend therapy. For example, if the portable drug device is in the process of delivering a drug, or if the subject's condition indicates that a drug may be needed soon to maintain the subject's condition (e.g., blood glucose) within a particular condition (e.g., within a desired blood glucose range), the suspension of therapy may be delayed at least until the time during which no drug is delivered is predicted to be needed during the suspension period, or until the next therapy is delivered. In some such cases, the portable drug device may notify the user that the suspension of therapy is delayed. Additionally, the portable drug device may indicate the reason for the delay. In some cases, the user may be able to override the delay and request an immediate suspension of therapy. For example, if the user is changing a drug cartridge, the user may disable the indication that the suspension of therapy should be delayed. In some cases, the requested start time may be overridden by the determined subject's condition.

[0184] The interruption in treatment or delivery of an agent may continue until a resumption condition occurs. In certain cases, once a resumption condition is met, the interruption period may end automatically without any action by the user or subject.

[0185] A resume state may include expiration of a period of time, a command from a user (e.g., subject), detection of the portable medication device fulfilling a condition (e.g., medication has been refilled), detection of the subject's condition fulfilling a particular criterion (e.g., the subject's blood glucose level falls below a threshold range or rises above a threshold range), or any other state that may fulfill a reason for interruption of therapy or override a request for interruption of therapy. For example, the drug delivery device may be configured to automatically resume drug delivery when a glucose threshold is reached or exceeded. This threshold may be set, for example, at 300 mg / dl. A resume state may include detection of an imminent risk of hypoglycemia or hyperglycemia, or a hypoglycemia or hyperglycemia event. Additionally, a resume state may include a meal notification, or an "end of exercise notification," a motion sensing event, a pause in other administered medication, the end of an undefined pause 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., ordered by a caregiver management software or a clinician), or any other type of resume event. In some cases, a resume condition may include a combination of criteria.

[0186] In some cases, automatically resuming treatment may include ceasing the interruption of treatment prior to expiration of the interruption period. For example, treatment may be resumed if the condition that caused the treatment to be interrupted is resolved prior to expiration of the interruption period.

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

[0188] In some examples, the treatment interruption may be terminated if a third interaction (e.g., a gesture) with the user interface is detected. The third user interface interaction may be detected by the user interface module 2408 and sent to the treatment interruption procedure 2436. If the treatment interruption procedure 2436 verifies that the third interaction with the user interface is a predetermined third user interface interaction, the treatment interruption procedure may send a signal to the device and subject monitoring procedure 2432 to activate the drug dose procedure 2430. This allows the user the flexibility to end an activated interruption at a user-set interruption period prior to confirmation (second interface with the user interface). In some cases, the user may decide to end the treatment interruption in order to change one or more interruption conditions set prior to activation of the current treatment interruption. In some other examples, the user may decide to end the treatment interruption due to a change in the user's health condition that is not included in one or more treatment resumption conditions provided prior to activation of the current treatment interruption.

[0189] 27 is a flow diagram illustrating an exemplary method of resuming a suspended therapy that may be implemented by an AMD. Once a therapy suspension is requested and confirmed by a user (e.g., using the procedure shown in FIG. 10) (2702), the AMD suspends one or more therapies selected for suspension at the suspension start time received as part of the suspension information. For example, the therapy suspension control module 2436 may use device and subject monitoring procedures 2432 to suspend or resume one or more therapies selected for suspension. Deactivate the dose control procedure 2430. During the interruption period, the therapy interruption control module 2436 continuously monitors the system clock and subject and device status (eg, using the drug dose control procedure 2430).

[0190] If the therapy interruption control module 2436 determines 2706 that the time that has elapsed since the interruption began is less than the requested interruption duration and determines 2708 that none of the conditions for resumption have been met, the therapy interruption continues.

[0191] If the therapy interruption control module 2436 determines (2706) that the time elapsed since the start of the interruption is equal to the requested interruption duration or determines (2708) that one or more resume conditions are met, the therapy interruption control module may check other AMD or subject conditions (not included in the therapy interruption information) to determine (2710) whether therapy delivery can be safely resumed. If it is determined that therapy delivery cannot be safely resumed, an alert message is sent to the user interface to inform about the reason for such determination. If it is determined that therapy delivery can be safely resumed, one or more interrupted therapies are resumed.

[0192] 28 is a diagram 2800 of multiple screens that may be displayed, for example, on a touch screen display, when a user 2427 resumes a suspended treatment. Screen 2802 informs the user that delivery of medication is now in suspended mode. Screen 2803 also shows the user 2427 the current glucose concentration of the user's 2427 blood. The portable medical device 600 may display various vital measurements useful to the user 2427. In one implementation, medication suspension ends when the glucose concentration of the user's blood meets or exceeds a threshold value.

[0193] The interface screen 2804 allows the user 2427 to select and perform various functions on the portable medical device 600. The resume button 2805 is a function that ends the medication pause. When the resume button 2805 is selected, the portable medical device 600 displays a resume screen 2806. The resume screen 2806 has a prompt 2807 that prompts the user 2427 to perform a gesture. In the illustrated example, the user 2427 is prompted in the resume screen 2807 to swipe right on the bottom of the resume screen 2806. The requirement to perform a gesture to resume medication delivery prevents the user 2427 from inadvertently resuming medication delivery on the portable medical device 600.

[0194] When the user 2427 performs a gesture to resume drug delivery, the drug suspension ends. The resume screen 2808 indicates to the user 2427 that normal drug delivery has resumed. Once the resume screen 2808 has been displayed to the user 2427 long enough to inform the user 2427 that the suspension has ended, the portable medical device 600 may display a lock screen 2810. The lock screen 2810 prevents the user 2427 from inadvertently performing more functions on the portable medical device 600.

[0195] In one embodiment, the portable medical device 600 must receive the second gesture to end the interruption before one or more conditions for ending the interruption are met. The purpose of the second gesture is to ensure that the user 2427 does not inadvertently end the interruption. Like the first gesture, the second gesture may be simple or complex.

[0196] Referring to FIG. 24, once the AMD device is instructed to resume treatment and / or determines that treatment is to be resumed, the portable medication device may instruct the user to administer a dose of medication based on a control algorithm used by the portable medication device to control delivery of medication to the subject. It can be determined whether the drug should be delivered. For example, the treatment interruption procedure 2436 can receive user input from the user interface module 2408 indicating that a resume condition has been met or that the treatment interruption should be terminated (a third interaction with the user interface). The treatment interruption control procedure 2436 can then send a signal to the device and subject monitoring procedure 2432 to initiate the drug dose procedure 2430. If the drug is to be delivered, the drug dose control can generate and send a dose control signal to the drug delivery interface 2406.

[0197] In some cases, the portable medication device can alert the user and / or subject that therapy is being resumed. This alert can occur before generating the dose control signal and / or after a resume condition has been met (e.g., the pause time has expired). In some cases, the user can request that the pause in therapy be terminated early. The user can request early resumption of therapy by interacting with the user interface described above using one or more of the interaction methods described above (e.g., gestures or taps).

[0198] Additional embodiments relating to suspending drug delivery to a subject that may be combined with one or more embodiments of the present disclosure are described in detail in the accompanying drawings, which are incorporated herein by reference in their entirety, and are not to be construed as limiting the scope of the present disclosure. No. 62 / 910,970, entitled "METHOD OF DELIVERY," the disclosure of which is incorporated herein by reference in its entirety for all purposes.

[0199] AMD with security functionality An ambulatory medication device (AMD), such as, but not limited to, an insulin pump, that provides life-saving treatment to a subject or subjects based on the subject's condition, may include a user interface (e.g., a touch screen display) that allows a user to change settings of the ambulatory medication device. Settings may include, but are not limited to, conditions that trigger delivery of medication to the subject, the amount of medication delivered when the condition is met, the type of medication, and the like. Settings may also include features of the AMD that may not be directly related to medication delivery (e.g., screen brightness, alarm sounds, and the like). In some instances, it may be desirable to manage access to various settings of the AMD to avoid 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., health care providers) while allowing access to some other settings for other authorized users (e.g., the subject, the subject's guardian or parent).

[0200] In many cases, a medical care provider can change the settings of the portable medication device. However, it is often desirable for a non-medical care provider to change at least some of the settings of the portable medication device. For example, when the portable medication device 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 medical care provider. In some cases, replacing the medication cartridge may include interacting with the user interface and / or one or more settings of the portable medication device. Another example of when it is desirable for a non-medical care user (e.g., a subject, parent, or guardian) to change the settings of the portable medication device is when the initial settings of the portable medication device are not providing the desired effect (e.g., not enough medication, too much medication, delivery of medication too slowly or too quickly, etc.). In some cases, normal maintenance of the portable medication device and / or the subject may require interaction with the settings and / or controls of the portable medication device. For example, a user may need to refill or replace the medication cartridge after a threshold period (e.g., 2-3 days, 5 days, etc.). Negative consequences may occur if the portable medication device remains connected to the subject at the same site for more than one day (e.g., one hour, one week, etc.). Thus, the portable medication device may need to be periodically moved from one site on the subject to another site on the subject (e.g., from left to right side, arm to leg, stomach to back, etc.). A change in site location may require interaction with the settings of the portable medication device (e.g., pausing operation until the site change is complete).

[0201] As explained above, there are several reasons why it may be desirable to allow users other than a medical care provider (e.g., a subject receiving treatment, a parent, or a guardian) to access at least some of the user settings of a portable medication device, but it may also be desirable to regulate access to at least some of the portable medication device settings. For example, it is generally undesirable for children (subject or otherwise) or users below a certain age to access portable medication device settings that, if altered, may cause harm to the subject. Additionally, it may be undesirable for certain subjects with reduced mental capacity, regardless of age, to access at least some of the portable medication settings.

[0202] The user may be the subject receiving the drug or treatment, or may be another user, such as a clinician or health care provider, or the subject's parent or guardian. In some examples, the passcode required to change one or more settings via the relay device may be different than the passcode required to change the same settings using the AMD's user interface directly.

[0203] One solution to regulate access to settings of the portable drug device is to implement a lock function that requires the user to provide a passcode, a passcode, or other information before the user is allowed to change settings of the AMD, such as control parameters. For ease of explanation, the present disclosure uses a passcode for explanation. However, it should be understood that the passcode can be replaced with a passcode or any other type of secret or semi-secret information. In some examples, when the AMD is in a locked state, the AMD can continue to deliver therapy to the subject at the same rate as in an unlocked state.

[0204] The lock feature may be activated by default or may be activated by the user. In some examples, the lock feature may be enabled through a setting within a control menu of the AMD device provided on a user interface (i.e., a touch screen display). The setting may include an on / off toggle (e.g., a software interface element or a hardware interface element) such that when the toggle is on, a passcode (e.g., a 4-8 digit number) may be required. In some cases, when the lock feature is on, a passcode (e.g., a 4-8 digit number code) may be required to turn off the lock feature. Once the lock feature is activated, the user may program the portable medication device 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 other cases, the portable medication device may generate a new passcode (eg, an override passcode) periodically or may generate a passcode when the user supplies a passcode.

[0205] In some cases, the user interface elements used to access a user interface that allows one or more settings of the AMD to be modified may be different from the user interface for modifying the control parameters associated with that setting. For example, a keypad may be used to access a user interface for modifying the control parameters. A passcode can be entered to unlock the face, and the touch screen can be used to change control parameters.

[0206] When the lock feature is enabled, the user interface screen may look and function in the same way as if the lock feature had not been enabled. If the lock feature is enabled, a passcode entry interface (e.g., a keypad user interface element) may be displayed when a visual guide to unlock the device (e.g., a linear unlock slider, an arcuate unlock slider, or another unlock user interface element, etc.) is activated. If either a user passcode or a global override passcode is entered, the user interface may proceed normally. If not, the user interface may revert to the original lock screen.

[0207] 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 touch screen 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 those that allow a user to change a therapy control parameter, may require a passcode. In some cases, access to each user parameter control element may require a different passcode. In some other examples, providing a passcode to an AMD in a locked state may directly enable access to a subset of the control parameter elements.

[0208] To aid in remembering the passcode, the passcode may be set by the user, allowing the user to select a passcode that is easy for the user to remember. However, regardless of 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 that may provide life-saving care), it is desirable for certain users not to be restricted from accessing certain settings of the portable medication device, but to be able to gain access to certain settings quickly (e.g., within seconds, minutes, before the next treatment event, or before harm may occur to the subject) when needed. Thus, while some non-medical devices may implement lockout periods or other restrictions to prevent malicious users from brute-forcing attempts to determine the device's passcode, such features are generally undesirable for portable medication devices. Thus, embodiments disclosed herein include portable medication devices that include an override passcode that allows access to (or control settings of) the portable medication device regardless of whether a user passcode is provided.

[0209] 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 during which the series of inputs is entered may also be part of the range of parameters. For example, the series of inputs may need to be entered in 3 seconds or more, or more than 3 seconds, and 15 seconds or less, or less than 15 seconds. One example of a complex gesture is a swipe.

[0210] In some other examples, the passcode or override passcode may be a complex or simple gesture (e.g., swiping or other movement across the touchscreen), performing a pattern or sequence on the touchscreen (e.g., drawing an image), a multi-touch interaction, a combination of the foregoing, or any other type of interaction with the touchscreen, or a portion thereof. Another example of a complex gesture is entering a predetermined series of touches. In some cases, the passcode may be a quiz or a series of The questions may include:

[0211] In some examples, the portable medication device may be configured to receive treatment settings or changes to treatment settings from the relay device via a communication connection. In some cases, this functionality may be supported in addition to providing the user with an option to change one or more settings with a user interface of the AMD. The communication connection between the relay device and the AMD may be, for example, a direct connection via Bluetooth® or a connection via a network, such as a local area network or a wide area network. In some such cases, the portable medication device may include a wireless transceiver, such as a NB-LTE transceiver, a Wi-Fi transceiver, or a Bluetooth transceiver. The relay device that provides the user with a user interface for changing the settings of the AMD includes any type of device (e.g., a computing device) that can communicate with the portable medication device. For example, the relay device may be a laptop or desktop computer, a smart watch, a smartphone, or a hardware control device that may be configured to interact with the portable medication device. The embodiments disclosed herein are applicable regardless of whether the user interface for changing the treatment settings or configuration of the portable medication device is generated by the portable medication device or presented to the user or presented via another device. In some such cases, the user can provide a user-generated or override passcode via an interface on the computing device, which can then provide the user-generated or override passcode to the portable medication device via a network connection between the devices.

[0212] In some examples, even when the AMD is in a locked state, certain relay 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 subject's guardian or parent's smartphone may be used to change one or more settings of the AMD while the AMD is in a locked state.

[0213] 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 transmit the passcode to the AMD, and if the passcode is validated by the AMD, may modify one or more settings of the AMD.

[0214] If the 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 general fixed passcode (e.g., an 8-digit override passcode) that can be used in place of a user-set passcode. The override passcode may be stored in the portable medication device at the time of manufacture, may be shared among multiple portable medication devices (e.g., a global override passcode), or may be unique to a particular portable medication device. 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, enabling a passcode prevents a user with reduced mental capacity (e.g., a child) from changing the settings of the portable medication device. The override passcode may be present to prevent unauthorized access to the device from the manufacturer. Thus, security may not be much of an issue, and any user may contact the manufacturer or a passcode management service to obtain an override passcode. In some such cases, a single global override may be used for all devices produced by the manufacturer. In some cases, however, some level of security may be desired. In some such cases, it may be necessary for the user to authenticate themselves. Additionally, the user may be required to provide the serial number of the portable medication device. In some cases, each model or each unit of the portable medication device may have a different override passcode. The user may provide the authorization information and the serial number of the portable medication device to the manufacturer or a passcode management service to obtain an override passcode.

[0215] In some examples, a new override passcode may be generated periodically, or an override passcode may be generated when the user supplies the passcode. In these examples, the portable medication device may generate the override passcode using the same parametric values ​​that another device may use, thereby ensuring agreement between the override passcodes. In some cases, by using an algorithm to generate the override passcode, it is advantageous to be able to obtain the override passcode regardless of whether the user is able to 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 portable medication device.

[0216] In some cases, the override passcode can change over time or may be a rotating passcode. For example, in some cases, the override passcode can change every 30 seconds, every minute, every hour, etc. In some such cases, the override passcode can be determined from an algorithm executed by an application. The portable medication device can store a copy of the algorithm in a memory of the portable medication device and execute the algorithm to determine a currently active override passcode. The copy of the algorithm may be executed by a separate computing device accessible by the user. The output of the algorithm may be based on values ​​generally accessible by the portable medication device 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 may 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 can be calculated based on a portion of the serial number or model number of the portable medication device and the time. The determination of the override passcode can be calculated by an application on the portable medication device, a computer server, and / or the user device.

[0217] In some cases, the override code may be automatically received by the portable medication device. Thus, the user may not need to see or enter the override code. In some cases, the override code may be transmitted to another device of the user (e.g., a smartphone or laptop). For example, the override code may be texted to the user's smartphone. In some cases, the override code may be received in a coded manner that may not be understandable by children or users with reduced mental capacity.

[0218] In some cases, the override passcode may be linked to a location. For example, the override passcode may only be enterable at a healthcare provider's clinic or at the subject's residence. Determining the location of the portable medication device may be based on a location information system available to the portable medication device (e.g., Global Positioning System (GPS)).

[0219] In some examples, for at least a subset of the treatment settings, the passcode can 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 other 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).

[0220] As described above, by interacting with a user interface, the portable medication device, or other device capable of modifying the control of the portable medication device, may present a passcode entry screen to the user. The user may enter a 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 portable medication device. The control parameter may be modified based on interaction with a parameter control element of the user interface. Additionally, modifying the control parameter may cause a modification of the generation of a dose control signal generated by a control algorithm based at least in part on the control parameter.

[0221] In some embodiments, the portable medication device may have a detailed treatment screen or other user interface that allows a healthcare provider or other user to obtain additional details regarding the treatment provided by the portable medication device. The detailed treatment screen may generally be intended for knowledgeable users such as clinicians, although in some cases, any user may gain access to the detailed treatment screen. The detailed treatment screen may allow the healthcare provider to modify control parameters that may not be modifiable by other users. For example, the healthcare provider may be able to modify the insulin accumulation rate, the rate at which insulin decreases in the subject's blood, set the glucose set point, when the subject's glucose level is outside of the set point range, or when insulin reaches a maximum concentration point (e.g., T max The parameters associated with the calculation of the aggressiveness level or therapeutic factor related to the amount of insulin provided when the circulating insulin level is reached can be controlled.

[0222] Access to the detailed treatment screens may be restricted by the requirement of a passcode, which may be 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 user-generated. However, the clinician passcode may be a separate passcode from the user-generated passcode that allows access to the non-detailed treatment screen interface. Additionally, the clinician passcode may be separate from the override passcode that allows the user to override the user-generated passcode to gain access to the non-detailed treatment screen interface. In some cases, the clinician passcode may be used as an override passcode. In some examples, the clinician passcode may be valid for a period of time (e.g., set by the subject or another authorized user, such as the subject's guardian or successor). For example, the clinician passcode may be valid for one day, one week, or one month. In some examples, the AMD may allow certain authorized users to terminate clinician access at any time.

[0223] In some cases, access to the detailed treatment screen may be limited to a certain period of time. After this period has expired, the portable medication device automatically restricts access to the detailed treatment screen. In some cases, the window of access may be extended: for example, if the care provider continues to interact with a detailed treatment screen, the screen may remain accessible.

[0224] In some cases, the detailed treatment screen may provide additional functionality. For example, the user may indicate that more or less insulin should be provided for a meal or as a correction factor, but the healthcare provider may specifically adjust the amount of insulin. Additionally, the user's instructions may or may not be followed, depending on, for example, if demand exceeds a threshold or blood glucose does not meet a setpoint range, but may follow indications provided via the detailed treatment screen regardless, or may have wider ranges or different thresholds that may control whether instructions are followed. Additionally, the detailed treatment screen may be used to temporarily pause treatment and / or prevent subject access.

[0225] In some cases, the manufacturer of the portable medication device may provide a remote unlock signal that may be used to unlock access to the portable medication device and / or detailed treatment screens on the portable medication device.

[0226] As mentioned above, a passcode may be desired to prevent certain users from inadvertently changing certain control parameters of the portable drug device. However, functions of the portable drug device that do not affect therapy may remain accessible to the user when the portable drug device is in a locked state. For example, the user may access the therapy history, the screen brightness settings or color, or any other functions that are unlikely to cause harm to the subject if changed in a certain way. Furthermore, since the passcode function is generally to prevent control parameter changes, the portable drug device can provide therapy and continue to provide therapy at the same rate and in the same state whether the portable drug device is locked or unlocked.

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

[0228] If the passcode is not validated, the portable medication device, or other control device that may provide access to the control parameters of the portable medication device, may prevent access to a user interface to modify one or more control parameters. In some cases, a user interface that presents the user with the ability to enter a passcode may allow the user a certain number of attempts, or a certain number of attempts within a certain 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 certain period of time, the user interface may enter a locked state (e.g., the screen is turned off) and prevent further attempts to enter the passcode for at least a period of time. In some cases, the user passcode option may be locked or blocked indefinitely. In some such cases, the control parameters of the portable medical device may be accessible only if an override passcode is provided. Alternatively, or in addition, a user passcode for a different user may be provided to allow the user a certain number of attempts, or a certain number of attempts within a certain period of time. It may be used to provide access to control parameters of the portable medical device. 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.

[0229] In some cases, once the passcode has been successfully entered or validated, the user may disable the passcode feature of the portable medication device, which may require the use of another passcode or an override passcode in addition to the user passcode.

[0230] In some cases, the passcode may be optional or omitted based on the computing device connected to the portable medication device. For example, if an end-to-end connection is established between a smartphone registered to a particular user (e.g., the subject's parent), the portable medication device may automatically unlock without requiring a passcode. In other cases, the smartphone or other computing device may automatically provide a user-generated or override passcode to the portable medication device upon establishing a connection. In some cases, the portable medication device may automatically unlock when connected to a charger or when within a particular geographic area. For example, a geofence may be configured at one or more locations, such as the subject's home or a clinician's office. Upon determining that the portable medication device is within the geofence, the portable medication device may automatically unlock. Similarly, upon determining that the portable medication device is not within the geofenced area, the portable medication device may automatically lock. Determining the location of the portable medication device may be based on a geolocation system, such as a global positioning system (GPS).

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

[0232] Exemplary AMD with Security Code 29 is a block diagram showing the interconnections between modules and procedures in the AMD involved in changing the settings of the AMD. In some cases, one or more settings of the AMD can be changed using another parameter control element 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 can be protected by a passcode. For the control parameters 2941 / 2943 / 2945, the user can provide a passcode 2933 (e.g., a user-generated passcode or an override passcode) via the user interface module 2908 (e.g., using the touchscreen display 2924 or the alphanumeric pad 2926). Alternatively, or in addition, the user 2927 can provide the passcode 2946 using an intermediate device (e.g., laptop, smartphone, etc.) connected to the AMD (e.g., via a wireless link). 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 stored in memory in the CCM of the AMD. A hard processor can execute machine-readable instructions associated with the setting change procedure 2928.

[0233] In some instances, the option to provide a passcode is not available when the user 2927 wakes up. The wake control module 2934 of the CCM may be available when performing a wake action on the interface 2922. In these examples, if the wake control module 2934 of the CCM determines that a valid wake action is to be performed, it may present selectable elements associated with the settings control screen 2940 / 2942 / 2944, for example, on a touch screen display. In some other examples, the first screen presented on the touch screen display may provide other selectable elements, including elements for changing the settings of the AMD. In such examples, selecting an element associated with the setting change may launch a second screen presenting selectable elements associated with the settings control screen 2940 / 2942 / 2944. When the lock function is activated, access to any of the settings 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 other 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 yet another example, all of the control screens 2940 / 2942 / 2944 may be presented without the need to provide a passcode, but access to one or more control elements within the control screens may require a passcode. For example, a user may be able to select the second screen 2942 without entering a passcode, but to select one or more parameter control elements 2943 on this screen, the user may be required to enter one or more passcodes.

[0234] In some examples, a passcode or override passcode received from the relay device 2922 or interface module 2908 may be transmitted to the AMD control and computing unit, where a configuration change control procedure 2935 determines the validity of the passcode by comparing it to one or more user-generated passcodes 2939 or override passcodes 2937 stored in the CCM's memory.

[0235] FIG. 30 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 passcode or an override passcode. When the AMD (e.g., a wake action procedure in a CCM) receives a valid wake action (3002), a user interface may be launched. In some examples, the wake action may directly launch (3004) a setting change interface (e.g., a setting change screen presented on a touch screen display). In some examples, a particular wake action may launch a setting change interface. In the setting change interface (3006), the AMD (e.g., a setting change procedure in a CCM) may request a passcode (e.g., by presenting a window for entering a passcode). When the passcode is received, the AMD (e.g., a setting change procedure in a CCM) may determine (3008) whether the passcode matches the user-generated passcode. If it is determined that the passcode matches the user-generated passcode, the AMD may provide (3010) access to one or more control parameter elements associated with the received passcode. If the received passcode does not match any of the stored user-generated passcodes, the AMD may determine whether the passcode matches an override passcode. If it is determined that the passcode matches an override passcode stored in the AMD's memory or the memory of the authorized computing device, the AMD may select one of the override passcodes associated with the received override passcode. Or, access to a plurality of control parameter elements may be provided 3014. If it is determined that the passcode does not match the override passcode, the AMD denies access to one or more passcode-protected control elements.

[0236] FIG. 31 is a flow diagram illustrating another exemplary method that may be used by an AMD to allow a user to change settings of the AMD using a user-generated passcode or an override passcode. When the AMD (e.g., a wake action procedure in a CCM) receives a valid wake action (3102), the AMD may provide a user interface (e.g., a touchscreen display) through which a user may provide a first gesture to activate a setting change interface or screen. When a first gesture is received from a user or subject (3104), the AMD may activate a setting change interface or screen. In some examples, the setting change interface or screen may include one or more parameter control elements associated with one or more settings of the AMD. In some other examples, the setting change interface or screen may include one or more selectable elements each associated with a setting change screen (e.g., a screen provided on a touchscreen display) that may include one or more control parameters. When a request for a setting change is received (3108), the AMD may determine whether the requested setting change is passcode protected. In some examples, the request for a setting change may include selecting a parameter control element. In some other examples, the request to change the setting may include selecting a list of parameter control elements (eg, contained on another screen provided on a touch screen display).

[0237] If the AMD determines that the requested setting change is not protected by a passcode, it may allow access to one or more parameter control elements associated with the requested setting change (3112). In some examples, once a 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 touchscreen display) to confirm the change made. In response to receiving the second gesture (3116), the AMD may modify the one or more settings in accordance with the requested and confirmed change.

[0238] If the AMD determines that the requested setting change is protected by a passcode, it may request (3120) a passcode via a passcode display (e.g., provided on a touchscreen display). In some examples, the request for a passcode may be presented on a display, but the passcode may be received via a physical keypad. Once a passcode is received from the user or subject (3122), the AMD may verify (3124) the validity of the passcode by comparing the passcode to one or more user-generated or override passcodes. If it is determined that the passcode matches the user-generated or override passcodes, the AMD may activate (3126) one or more parameter control elements associated with the requested setting change. The AMD may then receive (3128) the setting change via the selected control parameter element. 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 may modify (3132) one or more settings according to the requested and confirmed changes.

[0239] AMD with alarm system In some cases, conditions may arise that affect the operation of the ambulatory medication device. These conditions include: The alarm may relate to the ability of the portable medication device to operate as intended by the manufacturer, the subject receiving treatment from the portable medication device, and / or the user (e.g., the subject's health care provider, parent, or guardian). In some cases, the portable medication device may operate as intended, but the subject's condition may not meet a desired health level. In either case, it is generally desirable to generate an alarm to inform the subject and / or one or more users of the condition of the portable medication device and / or the subject. Furthermore, it is desirable to track the alarm until the condition that caused the alarm is resolved. Furthermore, it is desirable to issue different types of alarms for different conditions to allow the subject or user to easily distinguish the severity of the condition that triggered the alarm. The user may be the subject receiving the medication or treatment, or another user, such as a clinician or health care provider, or a parent or guardian.

[0240] This section of the disclosure relates to a portable medication device, such as an insulin pump or a combination insulin and antagonist (e.g., glucagon) pump, configured to generate a dose control signal configured to cause the medication pump to infuse a medication into a subject. Additionally, the disclosure relates to a portable medication device configured to detect a condition of the portable medication device and / or the subject and generate an alarm when the detected condition is determined to meet an alarm condition.

[0241] As discussed above, the portable medication device may include an alarm system configured to monitor the portable medication device and / or the subject and generate an alarm when it is determined that a condition satisfying an alarm condition has been detected. In some examples, the alarm system may organize a list of alarms and notify a user of these alarms and enable the user to acknowledge the alarms.

[0242] In some embodiments, the alarm system may include a number of sensors that monitor the AMD or the subject, a monitoring system interface that receives data from the sensors, and an alarm generation module that processes the received data and generates an alarm if an alarm condition is met. In some examples, the monitoring system interface and the alarm generation module are implemented using one or more hardware processors and machine readable. In some other examples, the monitoring system interface and the alarm generation module are separate hardware modules.

[0243] 32, in some embodiments, the alarm control system 3222 implements an alarm control procedure in the AMD's control and computing module 210 (CCM). The alarm control system 3222 may be implemented as instructions stored in the CCM's memory (e.g., main memory 216) and executed by the hardware processor 214 to generate an alarm upon detection of a condition of the portable medication device and / or the subject. In some cases, the hardware processor of the monitoring system is the hardware processor of the portable medication device that controls medication delivery. In other cases, the hardware processor of the monitoring system may be a separate hardware processor.

[0244] In some examples, the alarm control system 3222 includes a monitoring system 3226 and an alarm annunciation system 3228. The monitoring system 3226 monitors a condition or status of the AMD and / or the subject based at least in part on signals or status values ​​received from the set of device sensors 3224 and the set of subject sensors 3220. In some examples, the device sensors may be configured to track the status of components or elements of the portable medication device and the subject sensors may be configured to obtain measurements of one or more physiological characteristics of the subject.

[0245] In some examples, the device sensors 3224 may include AMD modules, interfaces, A sensor that generates a signal or status value associated with the state of an accessory, disposable, etc. In some examples, the device sensor 3224 can generate a signal corresponding to a parameter associated with a component in 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 a pump of the drug delivery interface 3206.

[0246] In some examples, the subject sensor 3220 may be any sensor that generates a signal or status value associated with one or more physiological indicators (or parameters) of the subject (e.g., heart rate, blood pressure, temperature, blood glucose level, serum levels of various hormones or other analytes). The device and subject monitoring system 3226 may include continuously receiving and analyzing signals received from the device sensors 3224 and the subject sensors 3206 to determine the status of the portable medication device, the subject, the sensors, and / or other accessories.

[0247] In some cases, a single sensor may be used to monitor the condition of both the subject and the portable medication device, or accessory and sensor connected to the AMD. For example, a continuous glucose monitoring CGM sensor may be used to monitor the condition of the subject, 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).

[0248] Although described as sensors in the portable medication device, the sensor or sensors may or may not be part of the portable medication device, but may be an accessory capable of communicating with the portable medication device.

[0249] In some examples, the alarm processing system 3222 implements procedures to allow a user or subject to change alarm settings and / or acknowledge alarm notification via the user interface 3208. In some examples, the user can see one or more alarms that have been alerted on the user interface (e.g., as a list of alarms) even when the AMD is in a locked state. In these examples, the user may not be able to acknowledge or respond to alarms when the AMD is in a locked state.

[0250] In some such examples, the user or subject can access an alarm setting screen or acknowledge an alarm announcement by providing a wake signal and a first gesture (e.g., on a touch screen display). In some cases, the first gesture may be made by entering a predetermined character on an alphanumeric pad. In some such examples, the alarm control system 3222 distinguishes inadvertent alarm control inputs from intentional alarm control inputs. An inadvertent alarm control input is an alarm acknowledgment input made without the user's intent to acknowledge an alarm that the portable medical device 600 is delivering to the user.

[0251] In some examples, the alarm control system 3222 implements a process for determining and classifying an alarm condition based on the severity level of the alarm condition (e.g., severity levels from 0 to 5) according to information received through the monitoring system 3226.

[0252] In some other examples, the alarm control system 3222 implements procedures for controlling the notification of an alarm condition via the user interface module 3208 based at least in part on the severity level of the alarm condition. In some such examples, the user interface (e.g., a touch screen display) may include a user interface that allows the user to easily view and control the notification of an alarm condition. The system may be configured to allow a user to navigate directly to the problem or fault for which an alarm is being delivered. This functionality provides the user with access to address the fault that is causing the alarm so that the fault can be corrected, thereby stopping the alarm.

[0253] Alarm Condition In some examples, the equipment and subject monitoring module 3226 may provide status information received from the equipment sensors 3224 and / or the subject sensors 3220 to the alarm reporting system 3228. In some examples, the status information may include one or more status values. In some such examples, the alarm generation system 3228 is configured to determine whether an alarm condition is met based at least in part on the status information received from the subject monitoring module 3226.

[0254] Determining whether an alarm condition is met may include comparing one or more status values ​​associated with the portable medication device and / or the subject 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 the status information to one or more alarm thresholds or alarm conditions included in one or more alarm profiles. In some examples, the alarm profiles may be stored in the storage 218 of the CCM 210. In some such examples, at least some of the alarm profiles may be provided to the CCM by an authorized user or subject via a user interface, or may be transferred directly from another device to the storage (e.g., from a USB drive, laptop, smartphone, PC, etc.). In some other examples, at least some of the alarm profiles may be stored in the storage 218 at the time of manufacture.

[0255] Each of the alarm profiles may indicate a characteristic or status of the portable medication device and / or the subject that will trigger an alarm corresponding to the alarm profile. For example, at least some of the alarm profiles may indicate a status threshold above and below which an alarm should be triggered. For example, one alarm profile may indicate that a particular alarm is generated and / or signaled when the subject's blood glucose level exceeds a particular threshold. As another example, an alarm profile may indicate that a particular alarm is generated and / or signaled when the amount of medication available is below a particular threshold. The type of alarm and / or alarm frequency or intensity associated with a medication level may differ from an alarm triggered based on a blood glucose level. While the previous 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, a blood glucose level above an upper threshold or below a lower threshold may be associated with different alarm profiles or the same alarm profile. As another example, a blood glucose level above an upper threshold or a medication pump that is unable to deliver insulin may be associated with the same alarm profile. On the other hand, a medication pump that is unable to deliver insulin due to an empty insulin cartridge may be associated with a different alarm profile than when the medication pump is unable to deliver insulin due to damage to the medication pump.

[0256] Some non-limiting examples of portable medication device or subject conditions that may be associated with an alarm profile include battery capacity (e.g., below a threshold charge capacity or below a capacity associated with a particular amount of operating time (e.g., one day)), battery status (e.g., high temperature or low voltage), medication or drug delivery status (e.g., medication empty or below a threshold, motor stalled, catheter occluded, etc.), subject sensor status (e.g., blood glucose sensor The possible error or condition conditions include conditions related to: a blood glucose level that has expired or a signal has not been received from the sensor, calibration failure, high or low glucose levels, network (e.g., Bluetooth or BN-LTE) communication errors, haptic interface errors (e.g., motor unresponsiveness), speaker errors (e.g., noise or low volume), medication cartridge errors (e.g., empty cartridge, cartridge detected error, etc.), etc. As described below, each of these errors or conditions may be associated with a different severity level that causes the issuance of a different alarm.

[0257] In some cases, each alarm profile may be associated with an alarm severity level. The severity level may be associated with how urgently the condition that triggered the alarm should be addressed or resolved. Additionally, the severity level may be associated with the amount of harm that may be caused to the subject if the condition that triggered the alarm is not resolved or is not resolved within a certain period of time. The number of severity levels may vary based on the type of portable medication device. In general, there is no limit to the number of severity levels. However, once the number of severity levels exceeds a certain number, there may be a point of diminishing returns, 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. Thus, the number of severity levels may be limited to a certain number, such as 3, 5, 6, 9, or a number in between. However, it is also possible that there are more than 9 severity levels.

[0258] There may be multiple alarm profiles associated with a severity level, or each ambulatory medication device and / or subject condition associated with the same severity level may be associated with the same alarm profile.

[0259] The portable medication device may determine the severity of the alarm condition based on a condition of the portable medication device and / or the subject that caused the alarm condition. In some cases, the portable medication device may determine the severity of the alarm condition based at least in part on an alarm profile associated with the alarm condition.

[0260] Generally, if an alarm condition does not prevent the portable medication device from providing therapy, the portable medication device may continue to provide therapy. However, if an alarm condition prevents delivery of therapy, operation of the portable medication device may be interrupted or partially interrupted. Generally, alarm conditions that prevent the delivery of therapy may be associated with a higher severity level. However, some alarm conditions that prevent the delivery of therapy may be associated with a lower severity level. For example, a determination that the portable medication device is unable to deliver insulin may typically be associated with the highest severity alarm. However, if the user indicates that the site location is currently 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).

[0261] Alarm notification The alarm notification system 3228 may implement a selected notification pattern based at least in part on the status information generated by and received from the monitoring interface 3226, regardless of whether an alarm condition is met. Determining whether an alarm condition is met may include comparing one or more status values ​​associated with the portable medication device and / or the subject to one or more alarm thresholds or alarm conditions associated with the alarm profile.

[0262] Verifying that an alarm condition associated with an alarm profile is met An alarm notification system 3228 notifies of alarm conditions.

[0263] In some examples, the alarm system may generate a list of pending alarm conditions and store this list in a memory of the AMD (e.g., storage 218 in CCM 210). 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 a new alarm condition to the list of pending alarm conditions.

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

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

[0266] In some other examples, the alarm status may be transmitted to other devices via the AMD's communications module 3202, where the alarm status may be viewed, for example, by an authorized user (e.g., a guardian or parent of the subject), the subject, or an emergency provider. In yet other examples, the alarm notification system 3228 may use the communications module 3202 to establish a direct end-to-end connection with a computing system (e.g., a cloud computing system) and transmit the alarm status to the computing system via the end-to-end connection.

[0267] 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 signaled. Different alarm conditions and / or alarm profiles may result in different types of alarms or signaling of different alarms. For example, an alarm associated with the highest severity level may be an audible alarm having a loudness above a particular decibel level (e.g., above 70 or 80 decibels), a loudness value above a particular brightness value (e.g., above 10 5 or 10 6 The severity levels may include a visible alarm (e.g., a flashing or steady light) having a brightness greater than 1000 Hz (brightness between 1000 and 2000 candelas per square meter), and / or a vibration alarm. Additionally, alarms associated with the highest severity level may not be snoozed or dismissed. Alternatively, alarms 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 are the presence of audible, visual, and vibration alarms different for different severity levels, but the characteristics of each alarm type are also different. For example, audible alarms may have different sound patterns, loudness, frequency, etc. Visible alarms may be different intensities, colors, patterns, etc. Vibration alarms may be different patterns, intensities, etc. Additionally, alarms having severity levels different from the highest severity level may be snoozed, dismissed, 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 alarm type that is generated (eg, audio, text, graphic, or any combination thereof).

[0268] 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 other cases, the number of occurrences of an alarm may be increased to reflect the duplicate alarm. In some cases, the duplicate alarm may result in the reporting of the duplicate alarm. In other cases, the duplicate alarm is 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 reporting of an alarm having a first severity level is detected as occurring a second time, the alarm may be reported at a second severity level indicating a severity greater 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 insulin cartridge exchange is incomplete or empty).

[0269] In some cases, the list of alarms may be accessed when the portable medication device is locked. Additionally, details regarding the alarms may be accessible when the portable medication device is locked.

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

[0271] In some cases where an alarm is presented on a display, the information displayed may include details about what caused the alarm, the severity of the alarm, how to respond to or address the alarm, or any other information that may be information about why the alarm was generated and / or how to respond to the alarm. In some cases, the information may provide a workflow or instructions on how to respond to the alarm. The instructions may include a link to a workflow provided by the manufacturer of the portable medication device or another entity, such as an entity providing the medication or a site change kit.

[0272] In some cases, different views of the alarm or different information associated with the alarm may be provided based on the identity or role of the user viewing the alarm. For example, a child may be instructed to contact a parent to address the alarm; however, the parent may be provided with information to resolve the alarm. A parent may receive simplified information about what caused the alarm (e.g., high blood glucose), while a healthcare provider may receive more detailed information about the alarm (e.g., internal control parameter values, insulin flow rate, curvature prediction of insulin decline, etc.) that facilitates the healthcare provider in caring for the subject.

[0273] The alarm condition may be displayed on a display of the portable medication device. Alternatively, or in addition, the alarm condition may be displayed on a remote display that is separate from the portable medication device. The remote display may be a display that is authenticated or associated with a computing device that is authenticated to access data, such as the alarm condition, from the portable medication device. In some cases, the alarm condition may be displayed on a remote display that is separate from the portable medication device. The list may be presented on a mobile device (e.g., a smart watch or smartphone) or a computing device (e.g., a laptop or desktop) that can obtain data directly or indirectly from the portable medication device.

[0274] In some cases, reporting the alarm may include contacting the manufacturer and / or the user (e.g., a health care worker, a parent or guardian, or other registered user). Additionally, the alarm may include instructions regarding servicing the portable medication device and / or addressing the alarm condition. For example, the alarm may provide the user with instructions for replacing the insulin cartridge and how to replace the insulin cartridge. As another example, the alarm may provide instructions on how to change the battery of the device or how to change the site at which the insulin pump connects to the subject. In some cases, the alarm may include one or more actions associated with the alarm. For example, the alarm may trigger a reorder of insulin or may request that the user confirm a reorder request to reorder insulin.

[0275] A user can acknowledge and / or snooze an alarm. Certain alarms, such as informational alarms, can be dismissed. In general, however, an alarm may remain on the alarm list until the condition that caused the alarm is resolved.

[0276] Resolving an alarm can include any action that addresses the condition that generated the alarm. For example, resolving an alarm can include replacing the insulin cartridge, changing the site at which the portable medication device is connected to the subject, charging the battery of the portable medication device, providing insulin or antagonist to the subject and / or the portable medication device, or any other action that can be taken to address the alarm condition. In some cases, the resolution action may be acknowledging the alarm. For example, if the alarm is informational (e.g., informing the user that more insulin has been ordered), acknowledging the alarm may be a sufficient resolution action.

[0277] In some cases, whether an alarm condition is resolved may depend on the identity of the user. For example, if a child interacts with an alarm related to insulin reordering, the alarm may remain until a parent or guardian acknowledges the alarm. However, the child may snooze the alarm. In some cases, the user interface displaying the alarm may differ based on who is viewing the alarm. For example, a child may be able to view the alarm but not interact with it. However, the parent or guardian may snooze or dismiss the alarm. Additionally, the child may be instructed to take the device to a parent or adult to address the alarm. In some cases, the child may be informed how urgently they should contact the parent (e.g., immediately, within a day, within a week, etc.). Additionally, the designated adult may be individually alerted (e.g., via a text or email alarm). The parent or guardian may receive additional information (e.g., a link to remediation instructions or a workflow for addressing the alarm condition) that is not provided to the child or subject.

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

[0279] However, in some cases, the alarm condition may or may not be resolvable when the portable medication device is locked.

[0280] A user may interact with the alarm that is generated based on the alarm condition. In some cases, the user may only interact with the alarm when the portable medication device is unlocked. In other cases, the user may interact with the alarm to snooze the alarm or obtain further information. However, the user may not dismiss the alarm without unlocking the portable medication device. Interacting with the alarm may include providing the user with information associated with the alarm or providing an indicator representative of the alarm in response to the user interacting with the alarm.

[0281] Exemplary AMD with Alarm Management System 33 shows a flow diagram illustrating an example procedure that may be used by AMD's alarm system to report an alarm condition upon receiving status information that meets the alarm condition. In some examples, the alarm reporting system 3228 implements the reporting process by execution of instructions by a processor in AMD's CCM, which may be stored in main memory, AMD's storage, or memory of a connected electronic device or computing system.

[0282] The alarm system may receive (3302) status information using the device and subject monitoring interface 3226, one or more device sensors, and / or one or more subject sensors. In some examples, the alarm annunciation system 3228 determines whether the received status information meets an alarm condition. In some examples, the alarm condition may be an alarm condition in an alarm profile. If the received status information does not meet the alarm condition, nothing is done (3306). If the received status information meets the alarm condition, the alarm system may determine (3308) whether the alarm condition is already present in a list of pending alarm conditions. If the alarm condition is not present in the list of pending alarm conditions, the alarm system may add (3310) the alarm condition to the list of pending alarm conditions. The alarm system may then determine (3312) the severity of the alarm condition. Based on the determined level of severity, the alarm annunciation system 3228 may select (3314) an annunciation pattern and announce the alarm condition using the selected annunciation pattern. If the alarm condition is present in the list of pending alarm conditions, the alarm system may select an annunciation pattern and annunciate the alarm condition using the selected annunciation pattern. In some examples, the annunciation pattern selected in block 3318 may be a different annunciation pattern than the one previously used for the alarm condition. In some such examples, the annunciation pattern selected in block 3318 may be selected based on the number of times the same alarm condition is met by the received status information. The process of alarm detection and control functions may repeat each processing cycle as long as the portable medical device is in use. In some examples, after an alarm is annunciated, the alarm system may wait for user acknowledgment of the alarm. If the user acknowledges the alarm, the system proceeds to perform alarm processing. However, if the user does not acknowledge the alarm, annunciation continues and may escalate depending on the level of the alarm.

[0283] As discussed above, alarm conditions may be classified and annunciated based on the severity level of the alarm condition. In some examples, alarms may be classified and annunciated based on the severity level of the alarm condition, with the highest priority faults at the top of the list. They are sorted numerically in descending order as displayed.

[0284] In some examples, a level 0 severity may be for a trivial failure that does not require any action by the user and thus does not warrant an alarm notification. In some other examples, a level 1 severity may be an information type notification that repeats at a certain frequency (e.g., every 30 minutes) until acknowledged and reset by the user. The annunciation may include, for example, a short vibration and a beep. In some examples, a level 2 severity may be one that pertains to an imminent loss of system functionality. Thus, such an annunciation may include, for example, two short vibrations and two beeps, and repeat at a certain frequency (e.g., every 30 minutes). Thus, the user still needs to address the situation that caused the failure and stop the annunciation entirely. In some other examples, a level 3 failure may be when the system is no longer fully functional and therefore requires user intervention to correct the problem. The annunciation may start at a base level intensity with, for example, three short vibrations and three audio beeps, and repeat at a certain frequency (e.g., every 5 minutes). The annunciation escalates to a maximum intensity level at a second frequency, for example every 30 minutes. The escalation may be, for example, a change in vibration intensity and / or audio level. The escalation may be cleared to a base level when the user acknowledges the fault, but the base alarm remains if the underlying condition persists. Thus, the user must still address the situation causing the fault to stop the annunciation entirely. In some examples, a level 4 severity may be when the system is no longer functioning and is not correctable by the user. The annunciation may start at a base level intensity, for example, with 3 audio beeps, and repeat at a certain frequency (for example, every 5 minutes). The annunciation escalates to a maximum intensity level at a second frequency, for example, every 30 minutes. The escalation may be, for example, a change in audio level. The escalation may be cleared to a base level when the user acknowledges the fault, but the base alarm remains since the underlying condition persists. In some other examples, a level 5 severity may be for a high priority alarm according to IEC 60601-1-8.The triggered alert may only be cleared when the underlying problem is resolved, for example when glucose levels rise.

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

[0286] Non-Critical AMD State Management In some cases, a condition may arise that affects the operation of the portable medication device. The condition may relate to the ability of the portable medication device to operate as intended by the manufacturer, the subject receiving treatment from the portable medication device, and / or the user (e.g., the subject's health care provider, parent, or guardian). In some cases, a condition or malfunction of the portable medical device may prevent the portable medical device from providing treatment to the subject. In other cases, the condition or malfunction may allow the portable medical device to continue to provide at least partial treatment to the subject, at least for a period of time. In either case, it is generally desirable to generate an alert to inform the subject and / or one or more users of the condition of the portable medical device and / or the subject. Furthermore, it is desirable to track the alert until the condition that caused the alert is resolved. Furthermore, it is desirable to issue different types of alerts for different conditions to allow the subject or user to easily distinguish the severity of the condition that triggered the alert.

[0287] In many cases, if the nature of the alert is non-critical, it may be safer to continue the underlying therapy and notify the user of the condition rather than discontinue therapy. In some such cases, the best response to a device problem for the subject is to notify the device manufacturer, or other user who can address the problem, but the subject continues to receive therapy until a replacement device can be obtained or a repair can be made.

[0288] In addition, alert fatigue can be a problem in medical devices due to excessive alerts that do not necessarily require user interaction. Alert fatigue can be dangerous because it can cause users to ignore serious alerts or alerts that require short-term action.

[0289] The methods described herein may be executed by an AMD (e.g., by one or more processors of the AMD) to detect device malfunctions for the AMD, and the methods may generate corresponding alerts on a portable medical device and prioritize the alerts to enable a subject or user to quickly and easily determine whether the device malfunction will impact treatment, should be addressed within a short period of time (e.g., immediately, within 1-2 hours, within a day, etc.), and / or can be addressed at the subject's convenience (e.g., within a month or longer). In some cases, the methods may be used by other systems.

[0290] In certain embodiments, the systems disclosed herein can detect conditions in which the portable medical device does not meet the manufacturer's specifications (e.g., haptic indicator failure, Bluetooth radio malfunction, glucagon or insulin depletion, medication delivery malfunction, touch screen failure, etc.). In some cases, there may be several layers of critical and / or non-critical faults. If it is determined that the underlying condition is not sufficient to stop treatment (e.g., insulin delivery is not stopped), the fault may be considered non-critical. In some cases, the fault may not be a failure of the device, but may indicate needed maintenance (e.g., recharging battery indicator, ordering more medication indicator, etc.). The condition may be alerted to the user along with appropriate instructions to address the fault or problem (e.g., contact the manufacturer for replacement medication or parts).

[0291] After the notification is acknowledged, the alert may be re-notified at a later date as a reminder (e.g., the alert may be re-notified at 4:00 PM every day or at noon on Saturdays). The interval between notifications may depend on the severity of the fault. In some cases, the re-notification may not be stopped by the user, but may only be stopped if the underlying condition is resolved.

[0292] The method may include detecting a state of the portable medical device. The state of the portable medical device may be determined by one or more sensors of the portable medical device. Furthermore, the state of the portable medical device may be determined by the presence or absence of one or more errors in performing one or more functions of the portable medical device. For example, if the portable medical device fails to establish a communication connection with a control system or a data storage system, it may be determined that the portable medical device may be malfunctioning. As another example, if the portable medical device fails to deliver a drug or detects an error in attempting to deliver a drug, a drug pump may be malfunctioning. In some cases, the state of the portable medical device may be determined based on one or more configuration values ​​that are outside of a normal operating range. For example, if a delivery rate of a drug is faster or slower than a configured operating range, it may be determined that a drug pump or a connection with a drug delivery tube (e.g., a catheter) is malfunctioning.

[0293] The method can include comparing the detected condition of the portable medical device to a set of normal operating parameters, the set of normal operating parameters being set by the portable medical device as specified by the manufacturer. Thus, the normal operating parameters may be specifications set by the manufacturer when operating as intended. In some cases, the normal operating parameters may be associated with a range of values. For example, an operating parameter for a rate of drug delivery may be associated with a range of rates, which may vary based on user settings, drug type, site location of drug delivery, or manufacturing tolerances, among other parameters. Comparing the detected state of the portable medical device to the set of normal operating parameters may include comparing each operating parameter in the specification to a corresponding detected operating parameter of the portable medical device. The portable medical device may generate a user alert based on the determined state of the portable medical device. For example, the AMD may generate an alert if the detected state of the portable medical device does not meet the set of normal operating parameters.

[0294] The method may further include determining whether the detected condition satisfies a minimum set of operating parameters. In some cases, the minimum set of operating parameters may coincide with the normal operating parameters. Typically, however, the minimum set of operating parameters differs from the normal operating parameters. The minimum operating parameters may include minimum specifications, minimum parameters, or minimum conditions required by the portable medical device to maintain or continue providing therapy to the subject. In other words, the minimum operating parameters are operating parameters sufficient to provide therapy. However, the minimum operating parameters may not be sufficient to enable all functions of the portable medical device. For example, the minimum operating parameters may enable the portable medical device to deliver insulin to the subject, but may not be sufficient to deliver insulin at a normal delivery rate for the particular portable medical device. As another example, the minimum operating parameters may enable delivery of therapy, but may not be sufficient to track a log of the therapy or transmit the therapy log to another computing system. In some cases, the normal operating parameters and / or the minimum operating parameters may be specified by the subject or a health care provider (e.g., a minimum amount of medication provided in each bolus may be specified by the health care provider). In some cases, the normal or minimum operating parameters may be changed.

[0295] If the conditions of the portable medical device are determined to meet at least the minimum operating parameters, the portable medical device may be configured to maintain delivery of the therapy to the subject. Maintaining delivery of the therapy may include maintaining the therapy at the same rate, at a reduced rate (e.g., providing only basal therapy and therapy responsive to meal notifications), or at a minimum maintenance rate (e.g., providing only basal insulin). Advantageously, the ability of the portable medical device to distinguish between a minimum set of operating parameters and a normal set of operating parameters allows a malfunctioning portable medical device to continue providing therapy, which may include life-saving treatment, to the subject until the portable medical device can be repaired or until device conditions deteriorate to the point where the minimum operating parameters cannot be maintained. In some cases, the portable medical device may temporarily maintain delivery of the therapy. Temporarily maintaining the therapy may provide the subject time to address the issue that caused the portable medical device to not meet the normal operating parameters before the subject loses access to the therapy. In some cases, the portable medical device temporarily maintains the therapy until device conditions make it impossible to maintain the therapy.

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

[0297] In some examples, the alert control procedure 3422 can include a monitoring interface 3426, an operation monitoring procedure 3425, and an alert generation procedure 3428. The monitoring interface 3426 can monitor and evaluate the AMD and / or the subject's condition based at least in part on information received from the operation monitoring procedure 3425 and the device sensors 3424. In some examples, the device sensors may be configured to track the status of components or modules of the portable medication device, and the operation monitoring procedure 3425 may be configured to monitor the operation of the modules and other procedures. In some examples, the detection of AMD can be provided to the alert generation procedure monitoring interface. The alert generation procedure 3428 can compare the detected AMD condition to a set of normal operating parameters. In some examples, the alert generation procedure can also determine whether the detected AMD condition meets a minimum set of operating parameters. In some examples, if it is determined that the detected AMD condition does not meet the normal operating parameters, the alert generation procedure can generate an alert. In some examples, the alert can be sent to the user interface module 3408 and displayed on a display (e.g., a touch screen display) of the AMD. In some other examples, when an alert is generated, the AMD can establish a connection (e.g., a wireless connection) with another device. This other device can include a local device (e.g., a user's laptop, smartphone, or smartwatch) or a computing system of a cloud-based service. In some such examples, the alert can be transmitted by the communication module 3402 to the computing system and displayed on a user interface associated with the computing system. In some cases, the additional device can receive data from the portable medical device to enable monitoring of the status of the portable medical device.

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

[0299] In some examples, if it is determined that the detected AMD condition does not meet the set of normal operating parameters, the alert generation procedure may cause the drug delivery interface 606 to stop therapy delivery or to modify one or more delivery parameters (e.g., therapy delivery rate). In some examples, if it is determined that the detected AMD condition does not meet the set of normal operating parameters but does meet the set of minimum operating parameters, therapy delivery may be maintained at the normal rate.

[0300] The alerts may include any type of alert. For example, the alerts may be a visual alert (e.g., a light or a changing light), an audible alert (e.g., a beep or a series of beeps), a tactile or vibration alert, an email alert, a text alert, or any other type of alert. Different device states may be associated with or may trigger different alerts. Thus, user alerts allow a user to determine the device state of the portable medical device based on the alerts. For example, an indication that the portable medical device has failed to deliver a medication may trigger one type of alert, while an indication that the portable medical device has less than a certain level of medication available may trigger a different alert. In some cases, user alerts may be dismissible and / or snoozeable by the user. In other cases, such as when the portable medical device is unable to meet a set of minimum operating parameters, user alerts may not be dismissible or may not be snoozeable.

[0301] A dismissible alert may be scheduled to repeat on a particular schedule until an alert-changing condition occurs. The frequency with which a dismissible alert is repeated may depend on the severity of the condition or on certain operating parameters not meeting normal or minimum operating parameters. More urgent device conditions may cause the alert to be repeated more frequently. Additionally, the alert may vary based on when the condition was detected, the time of day, or the subject's detected activity (e.g., sleep, unusual activity, or strenuous activity such as exercise). Similarly, snooze options may vary for different alerts or any of the aforementioned conditions. In some cases, the portable medical device may escalate an alert if it detects that a condition on the portable medical device has become more critical.

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

[0303] The alert change state may include any action that returns the operating parameters of the portable medical device to normal operating parameters. For example, the alert change state may be repair or replacement of a failed component. In some cases, the alert change state may include acknowledgment of the alert. In other cases, the alert change state may include a worsening of the portable medical device condition. In such cases, the change to the alert may include replacement of the alert with a different alert indicating a different or more severe condition of the portable medical device. For example, if a detected malfunction is addressed after generating a certain number of alerts, the emergency condition may become critical. The critical emergency condition may trigger an escalation of a different alert type (e.g., a louder sound, or a brighter image) and / or alert frequency. For example, an audible alert may become louder or be combined with a vibration alert from a haptic annunciator. Additionally, if the condition reaches a critical condition, the portable medical device may stop providing treatment to the subject.

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

[0305] Once the malfunction is addressed, the portable medical device is repaired, or the condition that caused the alert is resolved, the user may permanently dismiss the alert (or until the next time a device condition triggers the alert). Alternatively, or in addition, the portable medical device may automatically dismiss the alert if it senses that the device condition that caused the alert has been resolved. In some cases, the portable medical device may periodically recheck the device condition to determine whether the alert condition has been resolved.

[0306] In some cases, the manufacturer or healthcare provider may be able to remotely clear or stop the alert, for example, using a NB-LTE connection. and / or only the healthcare provider can clear or stop the alert. Additionally, in some cases, the manufacturer and / or healthcare provider can notify a user (e.g., the subject, or a parent or guardian) of a problem or impending problem with the portable medical device. The notification may be received by the portable medical device via a NB-LTE connection. Alternatively, or in addition, the notification may be received via a computing device such as a smartphone or laptop.

[0307] FIG. 35 is a flow diagram illustrating an exemplary procedure that may be used by an alert system of an AMD to monitor the operation of the AMD and generate an alert when an equipment malfunction is detected. In some examples, the alert system continuously monitors the status of all modules and components associated with the AMD, as well as the operation of all modules and procedures of the AMD. When an equipment condition is detected (3502), the alert system may determine whether the detected equipment condition meets a set of normal operating parameters (3504). If it is determined that the detected equipment condition meets the set of normal operating parameters, the alert system does nothing and continues to monitor the AMD. If it is determined that the equipment condition does not meet the set of normal operating parameters, the alert system determines whether the detected equipment condition meets a set of minimum operating parameters. If it is determined in block 3508 that the equipment condition does not meet the set of minimum operating parameters, the alert system may send a signal to a therapy delivery module to stop delivery of therapy to the subject (3509) and immediately generate a critical user alert indicating that immediate action is required (3511). In some examples, upon generating a critical alert, the alarm system of the AMD may contact a healthcare provider or an authorized user (e.g., a parent or guardian of the subject) and may also send a critical alert to one or more computing devices (e.g., a laptop, a cell phone, a personal computer, etc.) of the healthcare provider or authorized user. If, in block 3508, it is determined that the equipment condition meets a set of minimum operating parameters, the alert system may maintain (3510) the delivery of the treatment to the subject and generate (3512) a user alert. In some such examples, the alert system may maintain (3514) the delivery of the treatment at a rate associated with the detected condition of the AMD (e.g., a normal rate or a minimum maintained rate) until an alert change condition is detected (3514). Upon detecting (3514), the alert system may determine (3516) whether the new equipment condition meets the normal set parameters.If, in block 3516, it is determined that the new device state meets the set of normal operating parameters, the alert system may resume normal operation of the AMD (3518) (e.g., deliver therapy at a normal rate). If, in block 3516, it is determined that the new device state does not meet the set of normal operating parameters, the alert system may determine (3520) whether the new device state meets minimum configured parameters. If, in block 3520, it is determined that the new device state meets the set of minimum operating parameters. The alert system may maintain or modify (3522) the rate of therapy delivery according to the new device state and generate (3524) a user alert according to the new device state. If, in block 3520, it is determined that the new device state does not meet the set of minimum operating parameters, the alert system may send a signal to the therapy delivery module to stop delivery of therapy to the subject (3509) and immediately generate (3511) a critical user alert indicating that immediate action is required. In some examples, upon generating a critical alert, AMD's alarm system may contact a healthcare provider or authorized user (e.g., the subject's parent or guardian) and may also send the critical alert to one or more computing devices (e.g., a laptop, cell phone, personal computer, etc.) of the healthcare provider or authorized user.

[0308] Glucose control agent dosage management Portable medical devices allow subjects the freedom to self-medicate while mobile. Self-administered medical procedures carry inherent risks for the subject.

[0309] An automated glycemic control system can automatically provide insulin and / or antagonists (e.g., glucagon) to a subject to assist in controlling the subject's blood glucose levels. Generally, a control algorithm is implemented by an automated glycemic control system (BGCS) to determine when to deliver one or more glucose control agents and how much of the agent to provide to the subject. Additionally, the control algorithm can control both the continuous or periodic delivery of insulin (e.g., basal doses) and correction boluses that may be provided to regulate the subject's blood glucose levels within a desired range. The control algorithm can use blood glucose readings obtained from a sensor, such as a continuous glucose monitoring (CGM) sensor, that obtains automated blood glucose measurements from the subject. Additionally, in some cases, the control algorithm can deliver a bolus of insulin in response to an indication of a meal to be or being consumed by the subject.

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

[0311] In some cases, the subject may receive a manual bolus of insulin or medication. For example, a user (e.g., a health care provider, parent, or guardian) or the subject may inject a dose of insulin into the subject. As another example, a user or subject may manually instruct an automated glycemic control system to provide a bolus of insulin to the subject.

[0312] It is generally undesirable to use too much insulin. Excess insulin can result in hypoglycemia. As mentioned above, it may take time for insulin to reach a maximum concentration in the subject's plasma. Thus, the blood glucose reading from the sensor may not reflect the amount of insulin in the subject immediately or even after a certain period of time. Thus, a manual bolus of insulin may not be detected by the automated glycemic control system. As a result, if the automated glycemic control system is operating during the delivery of a manual bolus or is configured to operate on the subject before a blood glucose reading reflecting the effect of the manual bolus on the subject, the automated glycemic control system may unnecessarily administer additional insulin to the subject which may result in hypoglycemia.

[0313] The present disclosure relates to an automated glycemic control system configured to provide an automated delivery of a glucose control therapy to a subject and to receive information regarding a manual glucose control therapy to be provided to the subject. Using the received information regarding the manual glucose therapy, the automated glycemic control system can adjust a glycemic control algorithm to account for manual administration of insulin (or an anti-therapeutic agent). The manual glucose control therapy may be provided by an injection therapy or may be provided by an insulin pump.

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

[0315] The calculated amount of insulin for the meal announced by the user may be presented to the user. The user (e.g., the subject) may modify the amount of insulin to administer. For example, the user may determine that more or less insulin should be administered for a meal of a size that the subject is consuming or planning to consume. In such a case, the user may modify the calculated insulin dose to match the user's determination of the amount of insulin to be administered. In some cases, the automated glycemic control system may modify its control algorithms based on the user's input. Thus, future meal announcements may result in calculation of insulin that meets the insulin needs and / or preferences of the subject.

[0316] In some cases, an indication of the amount of the manual bolus may be received by the user entering a numerical value associated with administering insulin (e.g., an amount of insulin, a number of carbohydrates, or another calculation). As described above, the automated glycemic control system can automatically calculate a meal dose of insulin and present this meal dose to the user via a user interface where the user can enter manual bolus information. At the time of making the meal announcement, the user may have the option to enter a manual bolus. The meal controller of the glycemic pump may provide a recommendation for manual entry if there is a previous history of online operation or a basis for making a recommendation.

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

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

[0319] In some cases, for example, receiving an indication of a manual bolus may not be necessary because the user can have the automated glycemic control system provide a manual bolus. In such cases, the automated glycemic control system can track the amount of insulin delivered and the timing of the bolus administration. To track the manual bolus, the automated glycemic control system can store information associated with the manual bolus in a treatment log. Thus, when the automated glycemic control system is operating in an automatic mode, the automated glycemic control system can access the treatment log to determine whether a manual bolus was administered, and if so, the timing and amount of the manual bolus.

[0320] In some cases, the automated glycemic control system can model the decline of insulin or other medication in plasma over time based on information associated with the manual bolus. Modeling the decline of medication over time can be used to estimate the future effect of a previously administered medication. In some cases, the model can account for medication previously administered by the automated glycemic control system. Additionally, in some cases, the model can account for physiological characteristics of the subject, such as the subject's weight or an input parameter related to the subject's weight (e.g., body mass index). Additionally, the model can account for the perfusion of the medication bolus from the subcutaneous injection site into the subject's plasma over time. Additionally, the automated glycemic control system can model insulin accumulation, model the time course of insulin activity, or model the finite utilization rate of insulin.

[0321] Based on the model, the automated glycemic control system can adjust the automatic administration of insulin or other medication when operating in an automatic mode. Additionally, the automated glycemic control system can manipulate the administration of medication (e.g., by controlling a medication pump) based on the subject's glucose level and the modeled concentration of the medication in the subject.

[0322] In some cases, the automated glycemic control system can confirm that the manual bolus has been delivered to the subject. The confirmation can be determined at least in part based on whether the blood glucose reading by the CGM sensor matches or is within a threshold level predicted by the automated glycemic control system based on the manual administration information. Alternatively, or in addition, the automated glycemic control system can request, via a user interface, that the user confirm that the manual bolus has been delivered. In the case of a manual bolus delivered by the automated glycemic control system, the user may be requested to confirm the administration of the manual bolus by using a particular gesture or series of interactions with a user interface (e.g., a touch screen) of the automated glycemic control system or a device (e.g., a laptop or smartphone) that communicates with the automated glycemic control system.

[0323] As previously mentioned, in some cases, the information about the manual bolus may include the amount of insulin and the reason the manual bolus was administered (e.g., for a particular sized meal). In some such cases, the automated glycemic control system may notify the user that the manual bolus was delivered. If not, the automated glycemic control system can determine the amount of insulin that the automated glycemic control system would administer in an automatic mode of operation based on the manual administration information. If the automated glycemic control system determines that a different amount of drug would have been delivered, and if the difference exceeds a threshold, the automated glycemic control system can adjust the glycemic control algorithm to account for the difference. For example, the automated glycemic control system can change the operating set point or range of insulin that the automated glycemic control system attempts to maintain in the subject. As another example, the automated glycemic control system can top up the manual bolus with additional insulin to account for an under-dosage of insulin, or reduce subsequent doses of insulin to account for an over-dosage of insulin.

[0324] As previously discussed, the automated glycemic control system can maintain a treatment log of manual insulin treatments. This treatment log can be maintained based on information provided by a user based on use of the automated glycemic control system to provide a manual bolus or based on manual administration of insulin (e.g., by injection). A manual bolus may be delivered when the automated glycemic control system is not operating, not operating in automatic mode, or not connected to a subject. Once the automated glycemic control system is connected to a subject and configured in automatic mode, the automated glycemic control system can determine what treatment, if any, to provide to the subject based on a combination of the treatment log and a glucose control algorithm implemented by the automated glycemic control system.

[0325] The automated glycemic control system can generate a dose control signal based on the determined therapy, which can be provided to a drug pump that can control the delivery of a drug (e.g., insulin) to the subject.

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

[0327] Additional embodiments relating to managing meal drug doses and manual administration that may be combined with one or more embodiments of the present disclosure are described in detail in the accompanying drawings, which are incorporated herein by reference in their entirety. No. 62 / 911,143, entitled "IN AN AMBULATORY MEDICAL DEVICE," the disclosure of which is incorporated herein by reference in its entirety for all purposes.

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

[0329] Implementations may include one or more of the following features: A method in which the automated delivery system alters drug delivery based on the time and amount of drug received from either the manual delivery component or the automated delivery system; A method in which the manual delivery component includes a keypad that allows a user to key in a desired dose of drug; A method in which the providing an option to select is provided before a user engages in an activity that may change blood glucose levels; A method in which the activity that may change blood glucose levels includes ingesting food or exercising; A method in which the subjective information regarding the activity of ingesting food includes an approximate relative size of the food to be digested; A method in which the approximate relative size of the food is compared to a recommended meal dose for the user, and depending on whether the approximate relative size is the same as, greater than, or less than the recommended dose, the model predictive control component can determine the action needed to regulate blood glucose levels; A method in which the subjective information regarding the activity of exercising includes the intensity and duration of the exercise. The method in which the intensity and duration of the exercise is compared to a recommended intensity and duration, and depending on whether it is the same as, greater than, or less than the recommended intensity and duration, the automated delivery system can determine the action required to regulate blood glucose levels. Implementations of the described technology can include hardware, methods or processes, or computer software on a computer accessible medium.

[0330] One general aspect includes a system having a medical device configured to provide a user with an option to select to receive medication using a manual delivery component or an automated delivery system. The system also includes an automated delivery system configured to receive subjective information regarding an activity that may alter blood glucose levels. The system also includes a manual delivery component configured to receive an amount of medication to be injected. The system also includes a case where the medical device stores a time and an amount of medication to be injected into the automated delivery system that controls blood glucose levels. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0331] When utilizing a portable medical device to request a treatment change, users may have different preferences. Therefore, it is desirable to provide selectivity features in modern technology, especially portable medical devices. These selectivity features can satisfy different user and subject preferences. Selectivity features can allow users to have more control over treatment changes and can allow users to be more engaged with the medical assistance of the portable medical device.

[0332] To satisfy various preferences, the portable medical device needs to provide an option that allows the user to manually request the amount of the desired medication or to select an automated delivery system that automatically delivers the right amount of medication at the right time without further assistance. In the manual component, the user can personally input the desired amount on a keypad provided by the medical device. The medical device further confirms and delivers the requested medication. After the medication is injected through the manual delivery component, the data is stored in a model predictive control component that is further used to control and regulate blood glucose levels. However, if the user decides to use the automated delivery system, the user must be able to manually input the desired amount of medication ... The user must provide subjective information regarding the activity or behavior that may change the blood glucose level. For example, if the activity that changes the blood glucose level is ingesting food, the user must provide the time and dosage of the food that will be consumed. This information is tied to the automated delivery system, and the subjective information is further stored in the model predictive control component.

[0333] The embodiments described herein include a portable medical device having a keypad that allows a user to key in a dose of insulin or glucagon to be administered to the user. The user may wish to receive a single dose of insulin before ingesting food and determine how much insulin needs to be administered. In other embodiments, the user may choose to receive a burst of glucagon due to hypoglycemia for physical activity. The embodiments may include options for manual entry of medication and an automated delivery system of medication. In various implementations, the automated delivery system of medication is driven by blood glucose levels or related trends. The embodiments herein address issues that may arise when a user has just received a manual dose and turns on the automated delivery system. In such cases, the automated delivery system can be aware of all manual medication injection amounts and the timing of such injections. Thus, upon delivery of any medication, the manual delivery component can inform the automated delivery system of the type of medication delivered, the amount of medication, and the timing of the medication delivered. By having the above information, the automated delivery system can determine the amount of medication that is in the user's bloodstream and adjust the automated delivery of medication and the timing of the automated delivery. Thus, embodiments are directed to enabling a risk-free transition from manual delivery components and automated delivery systems.

[0334] Differences from other systems may include that manual delivery may be tied to an automated delivery system, and then the dose input from the user is stored in and processed by the MPC algorithm (Model Predictive Control) instead of the meal delivery algorithm. Other embodiments may include a selection that can have a relativistic algorithmically adjusted value. Other embodiments may include a learning algorithm that includes normal size meals, or larger size meals, or smaller size meals. An embodiment may include associating manual input with asking the user what the size of the meal was and learning how insulin affects the user. An embodiment may include associating manual input with asking the user what activities the user performed and learning how glucagon affects the user for a particular activity.

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

[0336] The portable medical device 3602 is any medical device that may be carried by a user 3604 and used with the approval of a medical professional. There are many different types of portable medical devices 3602. In one embodiment, the portable medical device 3602 is for a user 3604 with type I diabetes. The portable medical device 3602 is an insulin and / or glucagon infusion device. The portable medical device 3602 allows the user 3604 the freedom to receive medical care at their own convenience in any situation. However, a drawback of using the portable medical device 3602 is the user 3604 making mistakes when the user is away from a medical professional. One possible problem may result from the user 3604 switching from a manual delivery mode to an automatic delivery mode when the automatic delivery mode is unable to determine the amount of medication in the user's bloodstream. An embodiment is directed to manual medication delivery information being provided to an automated medication delivery system so that the operation of the automated medication delivery system can be adjusted based on the current and future medication in the user's bloodstream. In some cases, such as an embodiment in which the portable medical device 3602 is an insulin and / or glucagon infusion device, it may be problematic to perform automatic delivery of medication.

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

[0338] The signal processing component 3603 is a computing system that performs computing functions for the portable medical device 3602. The signal processing component 3603 includes a processor, memory, and storage. The signal processing component 3603 may be a single computing system or may be composed of several computing systems. The signal processing component 3603 can perform computing functions for a single portable medical device 3602 or multiple portable medical devices 3602. The signal processing component 3603 receives signals from the therapy delivery component 3605 and the input component 3607. The signal processing component 3603 also transmits signals to the therapy delivery component 3605 and the input component 3607. The signals of all steps of therapy change input 3606, therapy change delivery 3610, and 3608 can be received or transmitted by the signal processing component 3603.

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

[0340] The therapy delivery component 3605 provides medication to the user 3604. The signal received from the signal processing component 3603 is executed by the therapy delivery component 3605 to modify the therapy, such as starting, changing, or stopping the therapy. The therapy delivery component 3605 can have a computing component to interpret and execute instructions from the signal processing component 3603. Thus, the therapy delivery component 3605 can follow a program controlled by the signal processing component 3603. In one embodiment, the therapy delivery component 3605 is one or more infusion pumps. The infusion pumps can deliver fluids at various rates to the user 3604. The infusion pumps can deliver any fluid, including medication. The infusion pumps can be connected to the user 3604 via any means. In one example, the infusion pumps are connected to the body via a cannula. In an exemplary embodiment, the therapy delivery component 3605 is connected to the body via a cannula. The therapy delivery component 3605 is an insulin infusion pump. And in an exemplary embodiment, the therapy delivery component 3605 is an insulin and glucagon infusion pump. The signals received from the signal processing component 3603 can be interpreted by the insulin and glucagon pump to start, stop, or change the rate of insulin and glucagon delivered to the user 3604.

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

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

[0343] The therapy change delivery 3610 is the performance of a therapy change input 3606, verified by 3608, by the portable medical device 3602. The therapy change delivered by the therapy change delivery 3610 corresponds to the therapy change selection made by the user 3604. In one embodiment, the portable medical device 3602 alerts the user 3604 that it is performing the therapy change delivery 3610. In one example of various embodiments, the portable medical device 3602 displays the therapy change during the therapy change delivery 3610. Any number of details of the therapy change may be displayed during the therapy change delivery 3610. As shown in FIG. 43B, a simple message saying "Delivering" may be displayed during the therapy change delivery 3610. Alternatively, more precise details such as "Delivering 2 units of insulin" or "Delivering 2 units of insulin per minute" may be displayed. In another example, the portable medical device 3602 plays a sound effect during the therapy change delivery 3610. 43B, the therapy change delivery 3610 may be cancelled by an input by the user 3604. The input for cancelling the therapy change delivery 3610 may be any input, such as a wake signal input, or a series of touch inputs, such as a gesture.

[0344] The input component 3607 allows the user 3604 to interact with and control the portable medical device 3602. The amount of control the user 3604 has may vary based on the type of portable medical device 3602 and the user 3604. For example, a portable medical device 3602 that delivers pain medication may allow the user more control than a portable medical device 3602 that controls heart rate. In another example, a young child (under about 10, 11, or 12 years of age) may be able to control the user's movements. A user 3604 who is aged 20 to 65 years may have less control over the portable medical device 3602 than a user 3604 who is a teen or adult. The input components 3607 include a wake button 3620, a touch screen display 3622, and an alphanumeric pad 3624.

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

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

[0347] The alphanumeric pad 3624 registers numeric, alphabetic, and symbolic inputs. The alphanumeric pad 3624 includes a number of keys that correspond to numeric, alphabetic, and symbolic inputs. The alphanumeric pad 3624 may have a computing component for interpreting and executing instructions from the signal processing component 3603. Thus, the alphanumeric pad 3624 may follow instructions dictated by the signal processing component 3603. The alphanumeric pad 3624 may be configured to provide tactile feedback from its keys. The one or more alphanumeric pads 3624 may have any number of keys and any number of characters and may span multiple screens that the user 3604 may switch between to find all of the characters he or she is looking for. In one embodiment, the wake button 3620 is incorporated into the alphanumeric pad 3624...

Claims

[Claim 1] 1. A computer-implemented method for updating an application executing on a portable medical device without interrupting a treatment provided to a subject by the portable medical device, comprising: The hardware processor in the portable medical device receiving an indication that an application update is available, the application update including an update to a first application executing on the portable medical device; establishing a communications connection to a host computing system configured to host the application update; downloading a second application from the host computing system, the second application being a version of the first application that includes the application update; installing the second application while maintaining execution of the first application on the portable medical device; confirming successful installation of the second application on the portable medical device; and receiving a trigger to execute the second application instead of the first application; determining a next treatment delivery time associated with delivering a treatment to a subject by the portable medical device in response to the trigger; in response to determining that the amount of time until the next therapy delivery time meets a threshold period, starting execution of the second application and stopping execution of the first application; A method comprising:

Images