Recovery of treatment states

Abstract

Techniques for recovery of a treatment state are provided. The technique may involve receiving, at a controller device, an indication that a treatment state for use with a first medical device is to be transferred to a second medical device. The technique may also involve receiving, at the controller device from a cloud device, information indicative of the treatment status for use with the first medical device. The technique may also involve sending, from the controller device to the second medical device, the information indicative of the treatment status for use with the first medical device.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit and priority of U.S. Provisional Application No. 63 / 688,656, filed August 29, 2024, entitled “RESTORATION OF THERAPY STATES”, which has been assigned to the assignee of this application and is incorporated herein by reference in its entirety for all purposes. Technical Field

[0003] This disclosure relates in general to the recovery of the therapeutic state. Background Technology

[0004] Patients can use medical devices to deliver medical treatments. For example, a patient may use an insulin pump configured to deliver insulin to treat diabetes. In some cases, patients can switch from a primary medical device to a replacement device. However, switching medical devices can be difficult and time-consuming, due to factors such as the time required to configure and set up the replacement device. Summary of the Invention

[0005] It provides techniques for restoring the therapeutic state.

[0006] In some implementations, the technology may involve receiving at a controller device an instruction that a treatment state used with a first medical device is to be transferred to a second medical device. The technology may also involve receiving at the controller device information from a cloud device indicating the treatment state used with the first medical device. The technology may further involve sending from the controller device to the second medical device the information indicating the treatment state used with the first medical device.

[0007] According to some implementations, the technology receives treatment status information at a medical device associated with treatment provided by a previously used medical device, wherein the treatment status information is associated with a first point in time when the treatment was provided by the previously used medical device. The technology may also involve the medical device updating the treatment status information. The technology may further involve the medical device providing treatment based on the updated treatment status information. Attached Figure Description

[0008] The above and other aspects and features of this disclosure will become more apparent when considered in conjunction with the accompanying drawings, in view of the following detailed description, wherein similar reference numerals identify similar elements.

[0009] Figure 1 The diagram illustrates examples of treatment delivery systems according to various aspects of this disclosure.

[0010] Figures 2A to 2CAn example information flowchart illustrating the transfer of treatment status information according to various aspects of this disclosure is provided.

[0011] Figure 3 This is a flowchart illustrating an example process for sending treatment status information from a controller device to a medical device, according to various aspects of this disclosure.

[0012] Figure 4 This is a flowchart illustrating an example process for receiving treatment status information by a medical device and using the received treatment status information to provide treatment, according to various aspects of this disclosure.

[0013] Figure 5 The diagram illustrates examples of insulin delivery devices according to various aspects of this disclosure.

[0014] Figure 6 This is a block diagram of an example computer system that can be utilized in an implementation scheme as described herein. Detailed Implementation

[0015] Therapeutic substances (such as insulin) can be delivered to people with diabetes to manage conditions such as type 1 or type 2 diabetes. Delivering the right amount of a therapeutic substance at the right time can help maintain blood glucose levels within a target range (such as the normal range) to prevent hyperglycemia or hypoglycemia.

[0016] Patients can utilize medical devices to deliver medical treatments. For example, a patient may use an insulin pump configured to deliver insulin to treat diabetes. In some cases, a patient may switch from a primary medical device to a replacement device. However, switching devices can be difficult and time-consuming due to factors such as the time required to configure and set up the replacement device. For instance, when a patient switches from a primary insulin pump to a secondary insulin pump using conventional techniques, they may have to reconfigure the secondary pump to connect to a specific paired glucose sensor, initialize a specific insulin delivery algorithm, and so on. This setup process can be time-consuming, potentially causing delays before the replacement device can be used to deliver treatment to the patient. Delays may result in the patient missing their intended medical treatment. Furthermore, because the setup of a replacement device is typically performed manually, errors during configuration can lead to unforeseen problems.

[0017] This document discloses techniques for storing treatment status information corresponding to treatment provided by a first medical device. The treatment status information can be stored as a treatment status data asset. The treatment status information can be stored by a paired controller device and / or a remote cloud device. The treatment status information can be sent (e.g., from the controller device and / or from the remote cloud device) to a replacement medical device, for example, when the replacement medical device is to replace the first medical device in providing medical treatment to a patient. The replacement medical device can receive the treatment status information and can begin providing treatment to the patient based at least in part on the received treatment status information. The techniques disclosed herein allow for the deployment of a replacement medical device without time-consuming configuration. Furthermore, the techniques disclosed herein can abstract parameters associated with treatment status into a format that can be stored by the controller device and / or the remote cloud device and provided to the replacement medical device, regardless of the type or model of the replacement medical device. This allows for compatibility across different brands / models of medical devices. It should be noted that the controller device and / or the remote cloud device can be used to back up the treatment status used by the medical device and then provide information indicating the most recent treatment status to the replacement medical device.

[0018] It should be noted that "treatment status information" and "information indicating treatment status" are generally used interchangeably herein. Treatment status information may be represented and / or stored as a "treatment status data asset." The treatment status data asset may have a defined structure utilized by a controller device, remote cloud device, and / or compatible medical device. The treatment status data asset may include multiple structured objects (e.g., "structures"), each associated with treatment parameters and including one or more fields having values ​​representing the treatment status at the time the treatment status data asset was generated. Structured objects are described in more detail below. In some embodiments, an incompatible device may be considered a medical device not configured to utilize treatment status data assets. Such an incompatible device may send treatment status information in other formats to a controller device and / or a remote cloud device, which may reformat the received treatment status information into a treatment status data asset for storage and / or future use.

[0019] It should be understood that although the techniques described herein are generally described in the context of medical devices providing medical treatment, these techniques can be used to transfer treatment status information from a first medical device to an alternative second medical device that provides treatment for any suitable condition. Examples include pain control devices, hearing devices, etc.

[0020] This disclosure is primarily described in relation to insulin delivery systems. Aspects and embodiments of this disclosure can be practiced with one or more types of insulin (e.g., rapid-acting insulin, intermediate-acting insulin, and / or slow-acting insulin). For example, rapid-acting insulin can be used for both basal and bolus doses.

[0021] Although this disclosure is primarily described with respect to insulin delivery systems, its scope is not limited to insulin delivery systems. Rather, this disclosure is equally applicable to and can be implemented for other therapeutic systems. For example, some techniques of this disclosure are applicable to practices relating to glucagon delivery systems.

[0022] Discussions using terms such as “processing,” “computing,” “operating,” “determining,” “establishing,” “analyzing,” or “checking” may refer to the operation and / or process of a computer, computing platform, computing system, or other electronic computing device that manipulates data represented as physical (e.g., electronic) quantities in the registers and / or memory of a computer and / or transforms such data into other data similarly represented as physical quantities in the registers and / or memory of a computer or other non-transitory information storage medium that may store instructions to perform the operation and / or process by, for example, one or more processors or processor devices (e.g., system-on-a-chip) or devices associated with such processors.

[0023] In the context of this invention, "module" may refer to a set of computer-executable instructions and / or a hardware processor configured to execute a set of computer-executable instructions. The hardware processor may be an integrated circuit device (such as a server or user device (e.g., a desktop computer, laptop computer, tablet computer, mobile phone, etc.)) associated with a computing device, which can be programmed to perform a specific task. In some embodiments, multiple modules may be implemented as a single module. In some embodiments, a single module may be implemented as multiple modules. In some embodiments, two or more modules may be executable by the same device (e.g., the same computing device or delivery device).

[0024] Unless explicitly stated otherwise, the methods described herein are not limited to a particular order or sequence. Additionally, the methods described, or some of the elements thereof, may occur or be executed simultaneously or in parallel.

[0025] Figure 1An example therapeutic delivery system 100 for a person 101 is depicted. Components of the therapeutic delivery system 100 may be used to implement one or more blocks of process 300 and / or process 400. System 100 may be an insulin delivery system. The depicted therapeutic delivery system 100 includes a delivery device 102, a monitoring device 104, a computing device 106, and an optional remote or cloud computing system 108. The delivery device 102, monitoring device 104, and computing device 106 may be embodied in various ways, including being housed in one or more device housings. For example, in some embodiments, all devices 102 to 106 may be housed in a single device housing. In some embodiments, each device among devices 102 to 106 may be housed in a separate device housing. In some embodiments, two or more devices among devices 102 to 106 may be housed in the same device housing, and / or a single device 102, 104, or 106 may have two or more portions housed in two or more housings. Such embodiments and combinations thereof are contemplated within the scope of this disclosure. It should be noted that Figure 1 The location of each device shown is merely an example. For instance, monitoring device 104 is depicted on the patient's chest; however, in some specific implementations, monitoring device 104 may be on the patient's arm.

[0026] Figure 1 Communication links 112 to 118 are also depicted. Each of communication links 112 to 118 can be a wired connection and / or a wireless connection. When the two devices are in the same device housing, the communication link may include, for example, wires, cables, and / or communication buses located on a printed circuit board. When the two devices are in different device housings and separated from each other, the communication link may be a wired connection and / or a wireless connection. Wired connections may include, but are not limited to, Ethernet connections, USB connections, and / or another type of physical connection. Wireless connections may include, but are not limited to, cellular connections, Wi-Fi connections, etc. Connections, mesh network connections, and / or another type of connection using wireless communication protocols. Some implementations of communication links 112 to 118 may use direct connections (such as...) (Connection), and / or may use connections routed through one or more networks or network devices (not shown), such as Ethernet networks, Wi-Fi networks, cellular networks, satellite networks, intranets, extranets, the Internet and / or the Internet backbone, etc. Various combinations of wired and / or wireless connections may be used for communication links 112 to 118.

[0027] The following describes various aspects of the insulin delivery system 100. Further aspects and details can be described in the following U.S. Patents: No. 4,562,751; No. 4,685,903; No. 5,080,653; No. 5,505,709; No. 5,097,122; No. 6,485,465; No. 6,554,798; No. 6,558,320; No. 6,558,351; No. 6,641,533; No. 6,659,980; No. 6,752,787; No. 6,817,990; No. 6,932,584; and No. 7,621,893. The entire contents of each of the foregoing U.S. Patents are hereby incorporated herein by reference.

[0028] Delivery device 102 is configured to deliver a therapeutic substance (e.g., insulin) to person 101. Delivery device 102 may be attached to person 101 (e.g., attached to person 101's body or clothing) or may be implanted on or within person 101's body. In some embodiments, delivery device 102 may include a reservoir, an actuator, a delivery mechanism, and a cannula (not shown). The reservoir may be configured to store a quantity of therapeutic substance. In some embodiments, the reservoir may be refillable or replaceable. The actuator may be configured to drive the delivery mechanism. In some examples, the actuator may include a motor, such as an electric motor. The delivery mechanism may be configured to move the therapeutic substance from the reservoir through the cannula. In some examples, the delivery mechanism may include a pump and / or a plunger. The cannula may facilitate fluid connection between the reservoir and person 101's body. The cannula and / or needle may facilitate delivery of the therapeutic substance to tissue layers, veins, or body cavities of person 101. During operation, the actuator, in response to a signal (e.g., a command signal), can drive the delivery mechanism, thereby moving the therapeutic substance from the reservoir through the cannula and into the body of person 101.

[0029] The components of the delivery device 102 described above are provided merely as examples. The delivery device 102 may include other components, such as, but not limited to, a power supply, a communication transceiver, computing resources, and / or a user interface. Those skilled in the art will recognize various specific embodiments of the delivery device 102 and the components of such embodiments. All such embodiments and components are contemplated within the scope of this disclosure.

[0030] Continue to refer to Figure 1The monitoring device 104 is configured to detect the physiological condition of person 101 (e.g., glucose concentration level) and may also be configured to detect other matters. The monitoring device 104 may be attached to the body of person 101 (e.g., attached to the skin of person 101 via adhesive) and / or may be at least partially implanted in the body of person 101. Depending on the specific location or configuration, the monitoring device 104 may come into contact with the biological material of person 101 (e.g., interstitial fluid and / or blood).

[0031] Monitoring device 104 includes one or more sensors (not shown), such as, but not limited to, electrochemical sensors, electrical sensors, and / or optical sensors. As those skilled in the art will understand, electrochemical sensors may be configured to respond to the interaction or binding of a biomarker to a substrate by generating an electrical signal based on the substrate's potential, conductivity, and / or impedance. The substrate may include a material selected to interact with a specific biomarker, such as glucose. The potential, conductivity, and / or impedance may be proportional to the concentration of the specific biomarker. In the case of electrical sensors, and as those skilled in the art will understand, electrical sensors may be configured to respond to electrobiosignals by generating an electrical signal based on the amplitude, frequency, and / or phase of the electrobiosignal. The electrobiosignal may include changes in current resulting from the sum of potential differences across tissues (such as the nervous system) of person 101. In some embodiments, the electrobiosignal may include portions of potential changes in the heart of person 101 over time, such as those recorded as electrocardiograms indicating glucose levels in person 101. In the case of optical sensors, as those skilled in the art will understand, the optical sensor can be configured to respond to the interaction or binding of a biomarker to the substrate by generating an electrical signal based on changes in substrate brightness. For example, the substrate may include a material selected to fluoresce in response to contact with a selected biomarker (such as glucose). The fluorescence may be proportional to the concentration of the selected biomarker.

[0032] In some embodiments, monitoring device 104 may include other types of sensors that can be worn, carried, or coupled to person 101 to measure activities of person 101 that may affect person 101's glucose levels or glycemic response. For example, the sensor may include an accelerometer configured to detect acceleration of person 101 or a part of person 101 (such as a hand or foot). Acceleration (or lack thereof) may indicate person 101's exercise, sleep, or food / beverage consumption activities, which can affect person 101's glycemic response. In some embodiments, the sensor may include heart rate and / or body temperature, which may indicate the amount of physical exercise experienced by person 101. In some embodiments, the sensor may include a GPS receiver that detects GPS signals to determine the location of person 101.

[0033] The sensors described above are provided merely as examples. Other sensors or other types of sensors for monitoring physiological conditions, activity and / or location, etc., will be recognized by those skilled in the art and are conceived within the scope of this disclosure. For any sensor, the signal provided by the sensor shall be referred to as a "sensor signal".

[0034] Monitoring device 104 may include components and / or circuitry configured to preprocess sensor signals. Preprocessing may include, but is not limited to, amplification, filtering, attenuation, scaling, isolation, normalization, transformation, sampling, and / or analog-to-digital conversion, etc. Those skilled in the art will recognize various specific implementations of such preprocessing, including but not limited to implementations using processors, controllers, ASICs, integrated circuits, hardware, firmware, programmable logic devices, and / or machine-executable instructions, etc. The types of preprocessing and their specific implementations are provided merely as examples. Other types of preprocessing and specific implementations are contemplated within the scope of this disclosure. In some embodiments, monitoring device 104 may not perform preprocessing.

[0035] As used herein, the term "sensed data" means and includes information represented by sensor signals or by preprocessed sensor signals. In some embodiments, sensed data may include glucose levels in person 101, acceleration of a portion of person 101, heart rate of person 101, temperature of person 101, and / or geographic location of person 101 (e.g., GPS location), etc. Monitoring device 104 may transmit sensed data to delivery device 102 via communication link 112 and / or to computing device 106 via communication link 114. The use of sensed data by delivery device 102 and / or computing device 106 will be described later herein.

[0036] Computing device 106 provides processing power and can be implemented in various ways. In some embodiments, computing device 106 may be a consumer device, such as a smartphone, a computerized wearable device (e.g., a smartwatch), a tablet computer, a laptop computer, or a desktop computer, etc., or it may be a dedicated device (e.g., a portable control device) provided by, for example, the manufacturer of delivery device 102. In some embodiments, computing device 106 may be a “processing circuit” (defined below) integrated with another device (such as delivery device 102). In some embodiments, computing device 106 may be attached to person 101 (e.g., attached to person 101’s body or clothing), may be at least partially implanted in person 101’s body, and / or may be held by person 101. In some embodiments, computing device 106 may be configured to perform one or more blocks of process 300 and / or process 400, as follows Figure 3 and Figure 4 As shown in the image.

[0037] For each embodiment of computing device 106, computing device 106 may include various types of logic circuitry, including but not limited to microprocessors, microcontrollers, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), central processing units (CPUs), graphics processing units (GPUs), programmable logic devices, memories (e.g., random access memory, volatile memory, non-volatile memory, etc.) or other discrete or integrated logic circuitry, and combinations of such components. The term "processing circuitry" may generally refer to any of the aforementioned logic circuitry, alone or in combination with other logic circuitry, or any other circuitry used to perform computations.

[0038] The delivery device 102, monitoring device 104, and computing device 106 have been described above. One or more of devices 102 to 106 may include a user interface (not shown) for presenting information to and / or receiving information from person 101. The user interface may include a graphical user interface (GUI), a display device, a keyboard, a touchscreen, a speaker, a microphone, a vibration motor, buttons, switches, and / or other types of user interfaces. Those skilled in the art will recognize the various types of user interfaces that may be used, and all such user interfaces are conceivable within the scope of this disclosure. For example, in the case where computing device 106 is a consumer device (such as a smartphone, tablet computer, laptop computer), the user interface would include a display device, a physical and / or virtual keyboard, and / or audio speakers, etc., provided by such a consumer device. In some embodiments, the user interface may notify person 101 of sensed data (e.g., glucose levels) and / or insulin delivery data (e.g., historical, current, or future insulin delivery rates) and may present warnings to person 101. In some implementations, the user interface may receive input from person 101, which may include, for example, requested changes in insulin delivery and / or meal instructions, etc. The above description and implementation of the user interface are provided by way of example only, and other types and uses of the user interface are contemplated within the scope of this disclosure.

[0039] The following description of insulin delivery details the communication and collaboration between devices 102 and 106. Figure 1As depicted and mentioned above, devices 102 to 106 can communicate with each other via communication links 112 to 116. In some embodiments, computing device 106 can control the operation of delivery device 102 and / or monitoring device 104. For example, computing device 106 can generate one or more signals (e.g., command signals) that cause delivery device 102 to deliver insulin to person 101, for example, at a basal dose and / or bolus dose. In some embodiments, computing device 106 can receive data associated with insulin delivery (e.g., insulin delivery data) from delivery device 102 and / or sensed data (e.g., glucose levels) from monitoring device 104, and can perform calculations to control delivery device 102 based on insulin delivery data, sensed data, and / or other data. Insulin delivery data may include, but is not limited to, the type of insulin delivered, historical insulin delivery rates and / or amounts, current insulin delivery rates and / or amounts, and / or user input affecting insulin delivery. As those skilled in the art will understand, in closed-loop operation mode, computing device 106 can transmit a dosage command to delivery device 102 based on the difference between the current glucose level in the body of person 101 (e.g., received from monitoring device 104) and a target glucose level (e.g., determined by computing device 106). The dosage command may indicate the amount of insulin to be delivered and / or the rate of insulin delivery, and may adjust the current glucose level toward the target glucose level. Examples of closed-loop operation for insulin infusion systems are described in the following U.S. Patents: Nos. 6,088,608, 6,119,028, 6,589,229, 6,740,072, 6,827,702, 7,323,142, and 7,402,153, and described in U.S. Patent Application Publications Nos. 2014 / 0066887 and 2014 / 0066889. The entire contents of each of the aforementioned patents and publications are hereby incorporated herein by reference.

[0040] Continue to refer to Figure 1The remote or cloud computing system 108 may be a proprietary remote / cloud computing system or a commercial cloud computing system comprising one or more server computing devices. When the computing resources of a client computing device (e.g., computing device 106) are insufficient, the remote / cloud computing system 108 may provide additional computing resources on demand. Computing device 106 and the remote / cloud computing system 108 may communicate with each other via a communication link 118, which may traverse one or more communication networks (not shown). Communication networks may include, but are not limited to, Ethernet networks, Wi-Fi networks, cellular networks, satellite networks, intranets, extranets, the Internet, and / or the Internet backbone, etc. Those skilled in the art will recognize specific implementations of the remote / cloud computing system 108 and how to interact with such a system through various types of networks. For example, the remote / cloud computing system 108 may include processing circuitry (as defined above) and may execute machine-readable instructions. Such specific implementations, interfaces, and networks are contemplated within the scope of this disclosure. In some embodiments, the remote or cloud computing system 108 may be configured to execute one or more blocks of process 300 and / or process 400, as respectively in... Figure 3 and Figure 4 As shown in the image.

[0041] An example treatment delivery system has been described above. For convenience, the following description is primarily based on the insulin delivery system as an example of a treatment delivery system. However, any aspect, implementation, or description intended to be related to the insulin delivery system should be applied to treatment delivery systems that deliver treatments other than insulin.

[0042] As described above, using the techniques described herein, the current treatment status provided to a patient can be represented as "treatment status information," which is generally used herein to refer to information indicating the treatment provided to a patient by a medical device at a given point in time. In some implementations, the treatment status information can be formatted as a data asset that can be stored and transferred across medical devices, such that when a patient transitions from using a first medical device (e.g., a first insulin pump) to using a second medical device (e.g., a second insulin pump), the treatment status representing the treatment delivered by the first medical device can be provided to the second medical device. Therefore, the second medical device can begin providing treatment to the patient based on the information encapsulated in the treatment status data asset without requiring user input, thus allowing for seamless transitions between devices. Treatment status information may include connectivity data, time management data, distributed notification data, manual treatment data, sensor data (e.g., glucose sensor data), or treatment algorithm data, etc. Each of these aspects of the treatment status data asset is described in more detail below.

[0043] Connectivity data may include information that enables the medical device to establish a connection with one or more other devices, such as a controller device, a glucose sensor, etc. For example, connectivity data may include information indicating the serial number of the device to be connected (e.g., the serial number of the glucose sensor), and / or security information (e.g., a password) required to establish a connection between the medical device and another device. For example, connectivity data may include a password required to pair an insulin pump with a glucose sensor.

[0044] Time management data may include timestamp information. For example, timestamp information may indicate the timing of creating or updating treatment status information (e.g., date, time, etc.).

[0045] Distributed notification data may include information about warnings and / or alarms. For example, distributed notification data may include the time when a warning or alarm is provided, the manner in which it is provided (e.g., whether the warning / alarm is to be provided via tactile notification, auditory notification, visible alarm, or message, etc.), or escalation information (e.g., one or more actions to be taken if the warning / alarm is not resolved, the time period for resolving the warning / alarm, etc.). For example, a first medical device may trigger a low glucose level warning or alarm at a first point in time. Information associated with the alarm (e.g., timing information, alarm type, escalation information, etc.) may be stored as treatment status information. Where treatment is transferred to a second medical device, the second medical device may identify the warning triggered by the first medical device based on the transferred treatment status information. The second medical device may then determine, based on information in the treatment status data asset, whether to escalate the warning / alarm or whether to disable it.

[0046] Manual treatment data may include settings (e.g., carbohydrate to insulin ratio, baseline profile parameters, etc.), drug delivery parameters, recent history (e.g., timing information about previously delivered insulin doses), estimates of active insulin (e.g., residual insulin in the body), etc.

[0047] Sensor data may include data received by the medical device from one or more paired sensors (e.g., one or more glucose sensors). In some specific implementations, the sensor data may additionally include thresholds associated with the sensor data, such as hypoglycemia and / or hyperglycemia thresholds associated with glucose sensor data.

[0048] Treatment algorithm data may include internal data used by one or more algorithms to be implemented by a medical device. For example, an insulin pump may execute one or more algorithms to provide closed-loop control of insulin delivery. Treatment algorithm data may include internal data or internal states required by the medical device to execute one or more algorithms.

[0049] In cases where treatment status information is stored as treatment status data assets, each treatment status data asset may consist of a set of data structures (e.g., logical structures), each having a set of fields where the value of a given field specifies an aspect of the treatment provided to the patient when the treatment status data asset is created or updated. For example, a treatment status data asset may have a data structure representing glucose sensor data. Continuing this example, the data structure representing glucose sensor data may have fields representing recent glucose sensor data, a low blood glucose threshold, and / or a high blood glucose threshold. Each of these fields may have an associated value. For example, the field representing recent glucose sensor data may have a value corresponding to the most recent glucose sensor reading.

[0050] In some implementations, treatment status data assets, or information indicating the treatment status used by a medical device, can be sent from the medical device to another device. This other device can be a controller device paired with the medical device (e.g., a mobile phone, tablet, etc.) and / or a remote server or cloud device. It should be noted that in some implementations, treatment status data assets, or information indicating the treatment status, can be sent to and stored by both the controller device and the remote cloud device. The controller device and / or cloud device can maintain up-to-date treatment status information, which can then be provided to a replacement medical device (e.g., a second medical device). The replacement medical device can then use the received treatment status information to update the treatment settings before providing treatment based on the updated treatment status.

[0051] Figures 2A to 2C Sample information flow diagrams based on several implementation schemes are provided, illustrating the transfer of treatment status information across devices and the restoration of treatment status at the point of replacement of medical devices. Note that in each information flow diagram, the X-axis represents time.

[0052] Figure 2A This is an information flow diagram illustrating an example of treatment status information transfer in a scenario where the first medical device 202 is a conventional or incompatible medical device that does not utilize treatment status data assets, and the second medical device 204 is a compatible device that utilizes treatment status data assets. As illustrated, the first medical device 202 delivers treatment to the patient between timestamps t0 and t5. As illustrated, at each time point, as the treatment status information changes (e.g., due to updated glucose sensor readings, insulin delivery by the first medical device 202, triggering of warning / alarm conditions, etc.), updated treatment status information is sent to the cloud device 208. The cloud device 208 stores the received treatment status information.

[0053] Between times t6 and t8, the first medical device 202 is replaced by the second medical device 204. It should be noted that... Figure 2A In the example shown, the second medical device 204 is a compatible device, meaning that the second medical device 204 is configured to receive, parse, and utilize treatment status information encapsulated as a treatment status data asset. Therefore, upon receiving information instructing the second medical device 204 to be put into use, the cloud device 208 can format the treatment status information into a treatment status data asset 210. The treatment status data asset 210 is sent to the second medical device 204 via the controller device 206, as follows: Figure 2A As illustrated. It should be noted that the treatment status data asset 210 is associated with time point t5, which corresponds to the last time the first medical device 202 sent treatment status information to the cloud device 208. Therefore, when the treatment status data asset 210 is received at time point t9, the second medical device 204 can age or update specific information stored in the treatment status data asset 210. Figure 2A In the specific example shown, the second medical device 204 updates the time from t5 to t6 based on the updated treatment status information. 10 The information provided corresponds to the time when the second medical device 204 begins providing treatment to the patient. It should be noted that after performing the aging or update process, the second medical device 204 also sends updated treatment status information to the controller device 206, which in turn sends the updated treatment status information to the cloud device 208. As long as the second medical device 204 is used to provide treatment to the patient, updated treatment status information can continue to be sent from the second medical device 204 to the cloud device 208 via the controller device 206. It should be noted that... Figure 4 An example technique is described that can be used by a second medical device (e.g., a replacement medical device) to update treatment status information based on received treatment status data assets.

[0054] Figure 2B Examples similar to the above combination are shown. Figure 2A The information flow diagram shown and described. However, with Figure 2A The differences shown are in Figure 2B In this context, the first medical device 222 is a compatible device. Therefore, the first medical device 222 can (via controller device 206) send information encapsulated as treatment status data assets to the cloud device 208, instead of sending information indicating the current treatment status. Similar to... Figure 2A Combined with the above Figure 2A As described, the second medical device 204 can receive treatment status data assets in response to being put into use, and can update the information stored in the treatment status data assets to take into account the passage of time before providing treatment using the updated information.

[0055] It should be noted that in some cases, such as Figure 2BAs illustrated at time point t3, the medical device may attempt to send treatment status data assets to the controller device 206, but the communication channel between the first medical device 222 and the controller device 206 may be inoperable. In such cases, the first medical device 222 may continue to attempt to send the treatment status data assets, and the controller device 206 may receive the treatment status data assets when the communication channel is restored. A similar process occurs when the communication channel between the controller device 206 and the cloud device 208 is inoperable, for example, at time point t5.

[0056] Figure 2C Examples similar to Figure 2B Combined with the above Figure 2B The information flow diagram described is an information flow diagram. However, with Figure 2B The content shown is different, in Figure 2C In the example shown, a second controller device 226, distinct from controller device 206, is paired with the second medical device 204. Therefore, when the first medical device 222 is operational, treatment status data assets are sent to the cloud 208 via controller device 206. When the second medical device 204 is put into use, the cloud device 208 sends the treatment status data assets to the second medical device 204 via the second controller device 226. Figure 2C The example shown illustrates the use of cloud device 208 as a public backup, regardless of which controller devices and / or medical devices are utilized.

[0057] As described above, in some implementations, the controller device may act as an intermediary to send treatment status information (which may be encapsulated as a treatment status data asset) associated with treatment provided by a first medical device to a cloud device, and to receive the treatment status data asset from the cloud device and send it to a second replacement medical device. In some cases, the treatment status information received from the medical device may be a complete treatment status data asset indicating all data fields and associated values. In other cases, the treatment status information may include the difference between a previously sent treatment status data asset and the current treatment status provided by the medical device. Regardless of how the treatment status information is encapsulated and provided to the controller device, the controller device may send the treatment status information to the cloud device for storage and future use (e.g., to provide to the replacement device). It should be noted that in cases where, for example, the treatment status data asset is provided to a replacement device, the treatment status data asset may include security information. For example, the security information may include a signature of the sending device (e.g., a signature associated with the controller device and / or the cloud device), which may be used by the receiving device (e.g., the replacement medical device) to verify the sender of the treatment status data asset. As another example, the security information may include an identifier of the receiving medical device.

[0058] Figure 3 This is a flowchart of an example process 300 for sending treatment status information from a controller device to a medical device, according to various aspects of this disclosure. An example of such a controller device is... Figure 2A Controller device 206 Figure 2C Controller device 226 and / or Figure 1 The computing device 106. In some embodiments, the block of process 300 may be executed by one or more processors of the controller device. In some specific embodiments, the block of process 300 may differ from... Figure 3 The order in which the steps are executed is as shown. In some embodiments, two or more blocks of process 300 may be executed substantially in parallel. In some embodiments, one or more blocks of process 300 may be omitted.

[0059] Process 300 may be initiated at 302 by receiving an instruction at the controller device that the treatment state used with the first medical device is to be transferred to the second medical device. The first and second medical devices may have the same model and / or type (e.g., such as...). Figure 2B and Figure 2C Combined with the above Figure 2B and Figure 2C (as described) and / or different models and / or types (e.g., such as) Figure 2A Combined with the above Figure 2A (As described). Each medical device may be a medical device configured to deliver insulin to a patient. In some embodiments, an indication that the treatment state is to be transferred may be received from a first medical device, for example, a message indicating that the first medical device is being converted to unusable status. Alternatively, in some embodiments, an indication that the treatment state is to be transferred may be received from a second medical device, for example, as a message indicating that the second medical device is being put into use. In some embodiments, the indication may be received from a cloud device.

[0060] At point 304, process 300 can receive information from the cloud device at the controller device indicating the treatment status used with the first medical device. For example... Figures 2A to 2C Combined with the above Figures 2A to 2C As described, information indicating treatment status can be encapsulated as a treatment status data asset. For example, this information can be sent as multiple structured objects, each associated with treatment status parameters. Each structured object may include one or more fields having values ​​representing the treatment status used with the first medical device. As described above, by way of example, the structured object may include data associated with sensor readings obtained by sensors communicatively coupled to the first medical device, wherein fields indicate the most recent sensor reading, hyperglycemia and / or hypoglycemia thresholds, and / or sensor identifiers.

[0061] At point 306, process 300 may send information from the controller device to the second medical device indicating the treatment status used in conjunction with the first medical device. Note that this information may be sent from the controller device to the second medical device as a series of messages. For example, each message may include information that can be used to reconstruct one or more structured objects associated with the treatment status data asset. In some embodiments, each message may be signed by the controller device (and optionally by a cloud device that provides information to the controller device), where the signature may serve as security information that can be verified by the second medical device. Each message may include an identifier of the second medical device.

[0062] It should be noted that, although now in Figure 3 As shown, but as Figure 2B and Figure 2C Combined with the above Figure 2B and Figure 2C As described, in some specific implementations, the controller device may have already received treatment status information from the first medical device. In some implementations, the treatment status information may have been sent as treatment status data assets, for example, as information that can be used to reconstruct a set of structured objects, each associated with an aspect or treatment parameter of the medical device. In some implementations, the treatment status information sent by the first medical device may be a previously sent treatment status data asset or a difference between previously sent treatment status information and the current treatment status. For example, in some implementations, the first medical device may determine whether to send the complete treatment status data asset or the difference by determining whether the difference between the previously sent treatment status data asset and the current treatment status exceeds a different threshold. The difference threshold may be related to the amount of data that has changed, for example, to determine how to minimize the data to be sent. In the case where the complete treatment status data asset is sent, the controller device may store the complete treatment status data asset (and send the treatment status data asset to a cloud device for storage). In the case where the difference is sent by the medical device, the controller device may store the previous treatment status data asset and the difference, such that a replacement medical device can reconstruct an updated treatment status data asset based on the previous treatment status data asset and the difference.

[0063] As mentioned above Figures 2A to 2CAs described, the medical device can receive treatment status information from a controller device associated with treatment previously provided by a previously used medical device. As described above, the treatment status information can be provided to the medical device as a treatment status data asset. The treatment status information can be received as a series of messages, each including a portion or aspect of the treatment status information. The treatment status information received by the medical device can be associated with a first time point. The first time point can correspond to the time when the previously used medical device generated the treatment status information. Therefore, the treatment status information received by the medical device at that time can represent the treatment status provided by the previously used medical device at the first time point. The medical device can update the treatment status information accordingly, for example, to be relevant to the current time point. Updating the treatment status information may involve updating the prediction of the current amount of unmetabolized insulin in the patient's body (e.g., based on the duration elapsed between the first time point and the current time point), updating warnings or alarms triggered by the previously used medical device (e.g., to discard warnings and / or alarms that are no longer relevant), updating the predicted blood glucose level (e.g., based on the duration elapsed between the first time point and the current time point), etc. The process of updating treatment status information based on the elapsed time since the time previously used equipment generated the treatment status information is sometimes referred to as "aging" in this article.

[0064] In some implementations, the medical device may verify and / or authenticate the treatment status information received from the controller device before updating and / or utilizing it. For example, the medical device may verify that the sender of the message, as indicated in the message signature, corresponds to a known controller device and / or a known cloud device. As another example, the medical device may verify that the recipient identifier in the message corresponds to the medical device itself. In some implementations, in response to determining that the treatment status information cannot be verified and / or authenticated, the medical device may present a warning or alarm. In such cases, the medical device may use default settings or previously used settings instead of based on the received treatment status information to provide treatment.

[0065] Figure 4 This is a flowchart of an example process 400 for receiving treatment status information by a medical device and providing treatment using the received treatment status information, according to various aspects of this disclosure. An example of such a controller device is... Figure 2A , Figure 2B and / or Figure 2C Medical device 204. In some embodiments, the block of process 400 may be executed by one or more processors of the controller device. In some specific embodiments, the block of process 400 may differ from... Figure 4The order in which the steps are executed is as shown. In some embodiments, two or more blocks of process 400 may be executed substantially in parallel. In some embodiments, one or more blocks of process 400 may be omitted.

[0066] Process 400 may begin at 402 by receiving treatment status information from the controller device at the medical device that is associated with treatment previously provided by a previously used medical device and associated with a first point in time. It should be noted that the medical device receiving the treatment status information may be considered a replacement medical device for the first medical device. For example, the medical device may be a medical device to be put into use, and the previously used medical device may be a medical device that is being discontinued. The treatment status information may be received as a treatment status data asset, which may be received as a series or set of messages. In some specific implementations, in response to receiving the series or set of messages, the medical device may verify the treatment status messages. For example, the medical device may verify that the signer of the message is a known controller device (e.g., the controller device that sent the treatment status information) and / or a known cloud device. As another example, the medical device may verify that the recipient identifier is the medical device itself.

[0067] At 404, process 400 may update the treatment status information. For example, process 400 may update the treatment status information based on the difference between a first time point (e.g., the time point at which the treatment status information was generated by a previously used medical device) and the current time point. Updating the treatment status information may include: updating the prediction of the amount of active or unmetabolized insulin in the patient's body (e.g., based on timing information including timestamps and doses of previously delivered insulin in the treatment status information), discarding or updating previously triggered warnings and / or alarm conditions, and / or updating the prediction of the patient's glucose level. In some specific implementations, updating the treatment status information may involve obtaining one or more measurement or parameter values ​​corresponding to a first time point as indicated in the received treatment status information, and applying the measurement and / or parameter values ​​to a model or algorithm to age the measurement and / or parameter values. By way of example, updating the amount of active or unmetabolized insulin may involve obtaining the insulin dose and the time point at which insulin was delivered from the received treatment status information, and providing timing and dose information to a model that generates an output indicating the amount of active insulin remaining at the current time based on a model of active insulin decay. The model used can be patient-specific. For example, in some implementations, the model can be a patient-specific physiological simulator.

[0068] At 406, process 400 may optionally establish communication with the sensor device. For example, the medical device may use Bluetooth or another short-range wireless communication protocol to establish a communication channel with the glucose sensor device that provides glucose sensor readings to the medical device. It should be noted that information included in the received treatment status information may be used to establish the communication channel. For example, the received treatment status information may include the sensor device's serial number, a password required to establish the communication channel, etc.

[0069] At 408, process 400 may provide treatment based on updated treatment status information. For example, process 400 may escalate actions based on previously triggered alarms that were not discarded as part of the updated treatment status information. As another example, process 400 may continue to provide basal insulin doses and / or bolus insulin doses based on glucose sensor readings obtained from a glucose sensor paired with a medical device, for example, as described above in conjunction with box 406. As yet another example, process 400 may predict glucose levels based on updated predictions of active or unmetabolized insulin (e.g., as updated in conjunction with box 404).

[0070] It should be noted that, although not in Figure 4 As shown, process 400 may periodically send updates of the treatment status used by the medical device to the controller device and / or cloud device. For example, the medical device may periodically (e.g., every X minutes) send updates of the treatment status. As another example, the medical device may send updates of the treatment status in response to an action (e.g., in response to insulin delivery). As described above, updates of the treatment status may be sent as treatment status data assets. In some implementations, the medical device may determine the difference between the current treatment status and previously sent treatment status information (e.g., previously sent treatment status data assets) instead of sending the complete treatment status data asset. In response to determining that the difference is below a predetermined threshold, the medical device may send the difference between the current treatment status and the previously sent treatment status information to reduce the required bandwidth.

[0071] Example device

[0072] In some implementations, treatment can be achieved based on delivering treatment decisions toward a treatment delivery device. The following is in conjunction with... Figure 5 A non-limiting example of such a device is described, the figure depicting an example insulin delivery device 500 according to aspects of this disclosure.

[0073] As mentioned above, a treatment determination can be communicated toward insulin delivery device 500 (e.g., from cloud computing system 108, via an intermediate computing device 106 communicatively coupled to device 500). Insulin delivery device 500 can be an example of delivery device 102 as described throughout this disclosure. In such devices, insulin delivery can be performed based on internal communication between a central computing module (e.g., a microcontroller for the entire device 500) and an insulin delivery module (e.g., including a motor and pump). For example, insulin delivery can be initiated by the central computing module by communicating a delivery command in the form of an electrical signal traveling to the insulin delivery module via a communication structure. The central computing module can also be configured to communicatively couple to a remote or cloud computing system (e.g., Figure 1 108) computing devices (e.g., Figure 1 (106) Communication (e.g., via transceiver). In some implementations, insulin delivery device 500 may communicate various event data (e.g., meal data, exercise data, and / or insulin delivery data) to a remote or cloud computing system, which may communicate insulin delivery determinations to insulin delivery device 500. Figure 6 Components that may be included in the insulin delivery device 500 are also illustrated.

[0074] The insulin delivery device 500 delivers rapid-acting insulin via a tubing 510 configured for fluid connection to a cannula (not shown). The cannula is inserted subcutaneously under a fixation dressing 540, which includes an inlet for the tubing 510, an outlet for the cannula, and an adhesive surface for securing the dressing 540 to the skin. The device 500 delivers at least two types of doses: a basal dose, delivered periodically (e.g., every five minutes) throughout the day and night in micro-dose amounts; and a bolus dose, which covers the increase in blood glucose caused by meals and / or otherwise corrects hyperglycemia levels. The depicted insulin delivery device 500 includes a user interface with button elements 520 operable for administering insulin boluses, changing treatment settings, altering user preferences, and selecting display features, etc. The insulin delivery device 500 also includes a display device 530 for presenting various types of information or data to the user, such as notifications or warnings of the types described above. According to various aspects of this disclosure, a user of the insulin delivery device 500 can use button element 520 to input certain event data (e.g., event type, event start time, event details, etc.) and can use display device 530 to confirm the user input. Figure 5 The insulin delivery device 500 described herein is provided by way of example only, and other types of insulin delivery devices and other technologies different from those described above are considered to be within the scope of this disclosure.

[0075] Figure 6 This is a block diagram of an embodiment of a computer system 600 that can be utilized in the embodiments described herein. It should be noted that... Figure 6 This is intended only to provide a generalized illustration of the various components; any or all of these components may be used appropriately. Furthermore, it can be noted that... Figure 6 The illustrated components may be located to a single device (e.g., delivery device 102, monitoring device 104, computing device 106, or computing system 108) and / or distributed among various networked devices that may be located in different geographical locations.

[0076] In some implementations, computer system 600 may include hardware elements that can be electrically coupled (or otherwise communicated) via a bus. These hardware elements may include processor 610, which may include, but is not limited to, one or more microcontrollers, one or more microprocessors, one or more general-purpose processors, one or more special-purpose processors (such as digital signal processing chips, graphics accelerators, etc.), and / or other processing architectures that can be configured to perform one or more of the methods or functions described herein.

[0077] In some embodiments, the computer system 600 may also include one or more input devices 615, which may include, but are not limited to, button elements 520, microphones, and / or glucose sensors. The computer system 600 may also include one or more output devices 620, which may include, but are not limited to, display devices (e.g., 530), speakers, and / or buzzers.

[0078] In some embodiments, the computer system 600 may also include one or more non-transitory storage devices 625, which may include, but are not limited to, local and / or network-accessible storage devices, and / or may include, but are not limited to, disk drives, drive arrays, optical storage devices, solid-state storage devices, such as programmable, flash-uppable read-only memory (“RAM”) and / or read-only memory (“ROM”). Such storage devices may be configured to implement any suitable data storage, including but not limited to various file systems and / or database structures. Such data storage may include databases and / or other data structures for storing and managing messages and / or other information to be transferred to one or more other components or external devices.

[0079] In some implementations, computer system 600 may further include a communication subsystem 630 that implements wireless communication technologies managed and controlled by wireless communication interface 633. Additionally or alternatively, communication subsystem 630 may implement wired technologies (such as Ethernet, coaxial communication, or Universal Serial Bus (USB)). Wireless communication interface 633 may include one or more wireless transceivers that can transmit and receive wireless signals (e.g., Bluetooth, Bluetooth Low Energy (BLE) signals). Therefore, communication subsystem 630 may include modems, network interface cards (wireless or wired), infrared communication devices, wireless communication devices, and / or chipsets, which enable computer system 600 to communicate with... Figure 1 The communication subsystem 630 can be used to receive and transmit data as described in the embodiments herein (e.g., SG, Ip, insulin delivery information).

[0080] In some embodiments, computer system 600 will also include working memory 635, which may include RAM or ROM devices as described above. Software elements shown to be located within working memory 635 may include computer-readable and computer-executable instructions 640; device drivers; executable libraries; and / or other code that may include computer programs used in various embodiments and / or may be designed to implement methods and / or configure systems according to the embodiments described herein. By way of example only, one or more operations described with respect to the methods or functions discussed above may be implemented as code and / or instructions executable by a computer (and / or a processor within a computer). Such code and / or instructions may be used to configure and / or adapt a general-purpose computer (or other device) to perform one or more operations according to the described methods.

[0081] In some embodiments, a set of these instructions and / or code may be stored on a non-transitory computer-readable storage medium (such as storage device 625 described above). In some cases, the storage medium may be incorporated into a computer system (such as computer system 600). In other embodiments, the storage medium may be separate from the computer system (e.g., a removable medium, such as an optical disc) and / or contained in a downloadable installation package, such that the storage medium can be used to program, configure, and / or adapt to a general-purpose computer on which the instructions and / or code are stored. These instructions may take the form of executable code that can be executed by computer system 600, and / or may take the form of source code and / or installable code, which take the form of executable code when compiled and / or installed on computer system 600 (e.g., using any of a variety of commonly available compilers, installers, compression / decompression utilities, etc.).

[0082] The embodiments disclosed herein are examples of this disclosure and may be embodied in various forms. For example, while some embodiments herein are described as separate embodiments, each of these embodiments may be combined with one or more embodiments of other embodiments herein. The specific structural and functional details disclosed herein should not be construed as limiting, but rather form the basis of the claims and serve as a representative basis for teaching those skilled in the art to apply this disclosure differently with virtually any suitable detailed structure. Throughout the description of the drawings, similar reference numerals may refer to similar elements.

[0083] Any of the techniques, operations, methods, programs, algorithms, or code described herein can be translated into or expressed in a programming language or computer program embodied on a computer, processor, or machine-readable medium. As used herein, the terms "programming language" and "computer program" each include any language used to specify instructions for a computer or processor, and include (but are not limited to) the following languages ​​and their derivatives: assembler, Basic, batch file, BCPL, C, C+, C++, Delphi, Fortran, Java, JavaScript, machine code, operating system command languages, Pascal, Perl, PL1, Python, scripting languages, visual Basic, self-defining program meta-languages, and all first-, second-, third-, fourth-, fifth-, or higher generation computer languages. Databases and other data schemas, as well as any other meta-languages, are also included. No distinction is made between interpreted, compiled languages, or languages ​​that use both compilation and interpretation methods. No distinction is made between compiled and source versions of a program. Therefore, a reference to a program that can exist in more than one state (such as source, compiled, target, or linked) is a reference to any and all such states. A reference to a program can encompass the actual instructions and / or the intent of those instructions.

[0084] It should be understood that the foregoing description is merely illustrative of this disclosure. To the extent possible, any or all aspects of the aspects described in detail herein may be used in combination with any or all other aspects of the aspects described in detail herein. Various alternatives and modifications can be devised by those skilled in the art without departing from this disclosure. Therefore, this disclosure is intended to cover all such alternatives, modifications, and variations. The embodiments described with reference to the accompanying drawings are presented merely to illustrate certain examples of this disclosure. Other elements, steps, methods, and techniques that are not materially different from those described above and / or in the appended claims are also intended to be included within the scope of this disclosure.

[0085] While several embodiments of this disclosure have been depicted in the accompanying drawings, it is not intended to limit this disclosure, as it is intended to be as broad as permitted by the art and to be read in the same manner. Therefore, the foregoing description should not be construed as restrictive, but merely as illustrative of particular embodiments. Those skilled in the art will be able to conceive of other modifications within the scope and spirit of the appended claims.

[0086] Based on this description, implementation schemes may include different combinations of features. Specific implementation examples are described in the following numbered clauses:

[0087] Example 1: A method comprising: receiving at a controller device an instruction that a treatment state used with a first medical device is to be transferred to a second medical device; receiving at the controller device information from a cloud device indicating the treatment state used with the first medical device; and sending from the controller device to the second medical device the information indicating the treatment state used with the first medical device.

[0088] Example 2: According to the method of Example 1, sending the information indicating the treatment status includes: sending multiple messages from the controller device to the second medical device, wherein each of the multiple messages includes security information.

[0089] Example 3: According to the method described in Example 2, the security information includes the identifier of the controller device and the identifier of the second medical device.

[0090] Example 4: The method according to any one of Examples 1 to 3, wherein the information indicating the treatment state used with the first medical device includes: connectivity data indicating communication information for communicatively coupling the second medical device to one or more other devices; timestamp information indicating the time when the treatment state used with the first medical device was stored; alarm or notification data; drug delivery parameters; sensor data; treatment delivery algorithm data; or any combination thereof.

[0091] Example 5: The method according to any one of Examples 1 to 4, wherein the information indicating the treatment state is sent as a plurality of structured objects, each structured object being associated with a treatment state parameter, and each structured object including one or more fields having values ​​representing the treatment state used with the first medical device.

[0092] Example 6: The method according to any one of Examples 1 to 5, the method further includes: before receiving the instruction to transfer the treatment state used with the first medical device to the second medical device: receiving the information indicating the treatment state used with the first medical device; and sending the received information indicating the treatment state to the cloud device for storage by the cloud device.

[0093] Example 7: The method according to any one of Examples 1 to 6, wherein the first medical device and the second medical device are medical devices of the same type and model.

[0094] Example 8: The method according to any one of Examples 1 to 7, wherein the first medical device and the second medical device are different types and / or models of medical devices.

[0095] Example 9: A method comprising: receiving at a medical device treatment status information associated with treatment provided by a previously used medical device, wherein the treatment status information is associated with a first time point in which the treatment was provided by the previously used medical device; updating the treatment status information by the medical device; and providing treatment by the medical device based on the updated treatment status information.

[0096] Example 10: According to the method of Example 9, the medical device updates the treatment status information based at least in part on the difference between the second time point at which the medical device receives the treatment status information and the first time point.

[0097] Example 11: According to the method of Example 10, updating the treatment status information includes: updating one or more alarm conditions indicated in the treatment status information based on the difference between the second time point and the first time point.

[0098] Example 12: The method according to any one of Examples 10 or 11, wherein updating the treatment status information includes: updating the estimate of insulin levels in the patient associated with the medical device based on the difference between the second time point and the first time point.

[0099] Example 13: The method according to any one of Examples 9 to 12, the method further includes: verifying the security of the received treatment status information before updating the treatment status information.

[0100] Example 14: According to the method of Example 13, verifying the security of the received treatment status information includes: verifying the authenticity of the transmitter of the treatment status information.

[0101] Example 15: The method according to any one of Examples 9 to 14, wherein the treatment status information is received from a controller device communicatively coupled to the medical device.

[0102] Example 16: According to the method described in Example 15, the method further includes: sending information indicating the updated treatment status information to the controller device.

[0103] Example 17: According to the method of Example 16, the information indicating the updated treatment status information includes: sending the difference between the previous treatment status and the updated treatment status information.

[0104] Example 18: According to the method of Example 17, the method further includes: determining to use the difference to send the updated treatment status information by comparing the difference between the previous treatment status and the updated treatment status information with a threshold difference and determining that the difference is less than the threshold difference.

[0105] Example 19: The method according to any one of Examples 9 to 18, the method further includes: using connectivity information included in the treatment status information to establish a communication channel with at least one sensor device.

[0106] Example 20: A system comprising: one or more processors; and one or more processor-readable media storing instructions that are to be executed by the one or more processors. The one or more processors cause the following operations to be performed: receiving at a controller device an instruction to transfer a treatment state used with a first medical device to a second medical device; receiving at the controller device information from a cloud device indicating the treatment state used with the first medical device; and sending from the controller device to the second medical device the information indicating the treatment state used with the first medical device.

Claims

1. A method comprising: receiving, at a controller device, an indication that a therapy state used with a first medical device is to be transferred to a second medical device; receiving, at the controller device from a cloud device, information indicative of the therapy state used with the first medical device; and sending, from the controller device to the second medical device, the information indicative of the therapy state used with the first medical device. sending, from the controller device to the second medical device, a plurality of messages, wherein each message of the plurality of messages includes security information.

2. The method of claim 1, wherein transmitting the information indicative of the therapy status comprises:

3. The method of claim 2, wherein the security information includes an identifier of the controller device and an identifier of the second medical device. connectivity data indicative of communication information for communicatively coupling the second medical device to one or more other devices; 4. The method of claim 1, wherein the information indicative of the treatment status used with the first medical device comprises: timestamp information indicative of a time at which the therapy state used with the first medical device was stored; alert or notification data; medication delivery parameters; sensor data; therapy delivery algorithm data; or any combination thereof.

5. The method of claim 1, wherein the information indicative of the therapy state is sent as a plurality of structured objects, each structured object relating to a therapy state parameter, and each structured object including one or more fields having values representative of the therapy state used with the first medical device. prior to receiving the indication that the therapy state used with the first medical device is to be transferred to the second medical device:

6. The method of claim 1, further comprising: receiving the information indicative of the therapy state used with the first medical device; and sending the received information indicative of the therapy state to the cloud device for storage by the cloud device.

7. The method of claim 1, wherein the first medical device and the second medical device are the same type and model of medical device.

8. The method of claim 1, wherein the first medical device and the second medical device are different types and / or models of medical devices.

9. A method comprising: receiving, at a medical device, therapy state information associated with a therapy provided by a previously used medical device, wherein the therapy state information is associated with a first point in time at which the therapy was provided by the previously used medical device; updating, by the medical device, the therapy state information; and providing, by the medical device, a therapy in accordance with the updated therapy state information.

10. The method of claim 9, wherein updating, by the medical device, the therapy state information is based at least in part on a difference between a second point in time at which the therapy state information was received by the medical device and the first point in time. updating one or more alert conditions indicated in the therapy state information based on the difference between the second point in time and the first point in time.

11. The method of claim 10, wherein updating the therapy status information comprises: ​ 12. The method of claim 10, wherein updating the therapy status information comprises: update an estimate of an amount of insulin in a patient associated with the medical device based on the difference between the second time point and the first time point.

13. The method of claim 9, further comprising: verify a security of the received therapy status information prior to updating the therapy status information.

14. The method of claim 13, wherein verifying the security of the received therapy status information comprises: verify an authenticity of a transmitter of the therapy status information.

15. The method of claim 9, wherein the therapy status information is received from a controller device communicatively coupled to the medical device.

16. The method of claim 15, further comprising: send information indicative of the updated therapy status information to the controller device.

17. The method of claim 16, wherein transmitting the information indicative of the updated therapy status information comprises: send a difference between a previous therapy status and the updated therapy status information.

18. The method of claim 17, further comprising: determine to use the difference to send the updated therapy status information by comparing the difference between the previous therapy status and the updated therapy status information to a threshold difference and determining that the difference is less than the threshold difference.

19. The method of claim 9, further comprising: establish a communication channel with at least one sensor device using connectivity information included in the therapy status information.

20. A system comprising: one or more processors; and one or more processor-readable media storing instructions that, when executed by one or more processors, cause performance of: receiving, at a controller device, an indication that a therapy status used with a first medical device is to be transferred to a second medical device; receiving, at the controller device from a cloud device, information indicative of the therapy status used with the first medical device; and sending, from the controller device to the second medical device, the information indicative of the therapy status used with the first medical device.

Images