Automatic configuration of user-specific data based on placement into service

A method for automatically configuring a medical device with user-specific configuration data includes determining, by a first medical device, that the first medical device is being placed into service to provide medical therapy to a patient, wherein the first medical device is a replacement medical device for a second medical device that was previously placed into service to provide medical therapy to the patient in accordance with user-specific configuration data stored on the second medical device, communicating, by the first medical device, data indicative of the first medical device being placed into service, after communicating the data indicative of the first medical device being placed into service, obtaining, by the first medical device, the user-specific configuration data stored on the second medical device, and configuring, by the first medical device, the first medical device to provide therapy in accordance with the obtained user-specific configuration data.

TECHNICAL FIELD

The disclosure relates to device autoconfiguration and, more particularly, to automatic configuration of user-specific data.

BACKGROUND

While they are in service, many devices update the information they store about their users. For example, in the medical device field, therapies are often tailored to the idiosyncrasies of patients. Thus, when devices are rotated out of service, replacement devices may not be configured with updated information.

To address this problem, the replacement devices can be manually configured with the updated information. However, the tedious task of manually configuring replacement devices may result in user frustration and improper configuration.

SUMMARY

Devices, systems, and techniques for device autoconfiguration are described. This disclosure describes example techniques to automate transfer of user-specific configuration data from a first device (e.g., an “in-use” insulin pump) to a second device (e.g., a replacement insulin pump). This enables a substantially seamless handoff between the devices.

In one example, the disclosure describes a method for automatically configuring a medical device with user-specific configuration data, the method comprising determining, by a first medical device, that the first medical device is being placed into service to provide medical therapy to a patient, wherein the first medical device is a replacement medical device for a second medical device that was previously placed into service to provide medical therapy to the patient in accordance with user-specific configuration data stored on the second medical device, communicating, by the first medical device, data indicative of the first medical device being placed into service, after communicating the data indicative of the first medical device being placed into service, obtaining, by the first medical device, the user-specific configuration data stored on the second medical device, and configuring, by the first medical device, the first medical device to provide therapy in accordance with the obtained user-specific configuration data.

In one example, the disclosure describes a system for automatically configuring a medical device with user-specific configuration data, the system comprising one or more processors, and one or more processor-readable storage media storing instructions which, when executed by the one or more processors, cause performance of determining that a first medical device is being placed into service to provide medical therapy to a patient, wherein the first medical device is a replacement medical device for a second medical device that was previously placed into service to provide medical therapy to the patient in accordance with user-specific configuration data stored on the second medical device, communicating data indicative of the first medical device being placed into service, after communicating the data indicative of the first medical device being placed into service, obtaining the user-specific configuration data stored on the second medical device, and configuring the first medical device to provide therapy in accordance with the obtained user-specific configuration data.

In one example, the disclosure describes one or more non-transitory processor-readable storage media storing instructions which, when executed by one or more processors, cause performance of determining that a first medical device is being placed into service to provide medical therapy to a patient, wherein the first medical device is a replacement medical device for a second medical device that was previously placed into service to provide medical therapy to the patient in accordance with user-specific configuration data stored on the second medical device, communicating data indicative of the first medical device being placed into service, after communicating the data indicative of the first medical device being placed into service, obtaining the user-specific configuration data stored on the second medical device, and configuring the first medical device to provide therapy in accordance with the obtained user-specific configuration data.

In one example, the disclosure describes a method for automatically configuring a medical device with user-specific configuration data, the method comprising determining, by a first medical device, that the first medical device is being removed from service, wherein the first medical device was previously placed into service to provide therapy to a patient in accordance with user-specific configuration data stored on the first medical device, and wherein the first medical device is to be replaced with a second medical device that is a replacement medical device for the first medical device, and causing, by the first medical device in response to determining that the first medical device is being removed from service, configuration of the second medical device to provide therapy to the patient in accordance with the user-specific configuration data, wherein causing configuration of the second medical device comprises communicating the user-specific configuration data toward the second medical device.

In one example, the disclosure describes a system for automatically configuring a medical device with user-specific configuration data, the system comprising one or more processors, and one or more processor-readable storage media storing instructions which, when executed by the one or more processors, cause performance of determining that a first medical device is being removed from service, wherein the first medical device was previously placed into service to provide therapy to a patient in accordance with user-specific configuration data stored on the first medical device, and wherein the first medical device is to be replaced with a second medical device that is a replacement medical device for the first medical device, and in response to determining that the first medical device is being removed from service, causing configuration of the second medical device to provide therapy to the patient in accordance with the user-specific configuration data, wherein causing configuration of the second medical device comprises communicating the user-specific configuration data toward the second medical device.

In one example, the disclosure describes one or more non-transitory processor-readable storage media storing instructions which, when executed by one or more processors, cause performance of determining that a first medical device is being removed from service, wherein the first medical device was previously placed into service to provide therapy to a patient in accordance with user-specific configuration data stored on the first medical device, and wherein the first medical device is to be replaced with a second medical device that is a replacement medical device for the first medical device, and in response to determining that the first medical device is being removed from service, causing configuration of the second medical device to provide therapy to the patient in accordance with the user-specific configuration data, wherein causing configuration of the second medical device comprises communicating the user-specific configuration data toward the second medical device.

In one example, the disclosure describes a method for automatically configuring a medical device with user-specific configuration data, the method comprising obtaining, by a charger device from one or more server computing devices, user-specific configuration data stored on a first medical device that is configured to provide therapy to a patient in accordance with the user-specific configuration data, and causing, by the charger device, configuration of a second medical device based on communicating the user-specific configuration data to the second medical device while the second medical device is being charged by the charger device, wherein the second medical device is a replacement device for the first medical device.

In one example, the disclosure describes a system for automatically configuring a medical device with user-specific configuration data, the system comprising one or more processors, and one or more processor-readable storage media storing instructions which, when executed by the one or more processors, cause performance of obtaining, from one or more server computing devices, user-specific configuration data stored on a first medical device that is configured to provide therapy to a patient in accordance with the user-specific configuration data, and causing configuration of a second medical device based on communicating the user-specific configuration data to the second medical device while the second medical device is being charged by the charger device, wherein the second medical device is a replacement device for the first medical device.

In one example, the disclosure describes one or more non-transitory processor-readable storage media storing instructions which, when executed by one or more processors, cause performance of obtaining, from one or more server computing devices, user-specific configuration data stored on a first medical device that is configured to provide therapy to a patient in accordance with the user-specific configuration data, and causing configuration of a second medical device based on communicating the user-specific configuration data to the second medical device while the second medical device is being charged by the charger device, wherein the second medical device is a replacement device for the first medical device.

DETAILED DESCRIPTION

Devices, systems, and techniques for device autoconfiguration are described in this disclosure. Although the subject matter of this disclosure is explained using medical devices as examples, it should be appreciated that the subject matter of this disclosure is not limited to medical devices and is equally applicable to any other devices, including wearable devices and other consumer electronic devices. Furthermore, it should be appreciated that the techniques disclosed herein can be practiced with one or more types of insulin (e.g., fast-acting insulin, intermediate-acting insulin, and/or slow-acting insulin). Thus, terms such as “basal insulin” and “bolus insulin” do not necessarily denote different types of insulin. For example, fast-acting insulin may be used for both basal dosages and bolus dosages.

In some examples, a user (e.g., a patient) may employ medical devices (e.g., patch pumps and/or glucose monitoring devices) for glucose level management, and the medical devices may be configured with user-specific configuration data (e.g., configuration data that may be different for different users). Examples of user-specific configuration data include, without limitation, information indicative of any of the following: insulin-on-board, insulin type, a safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, and an insulin sensitivity factor. User-specific configuration data may be stored in volatile memory and/or non-volatile memory. Additionally, user-specific configuration data may be updated while the medical device is in use.

In some examples, the user may possess multiple medical devices of the same type (e.g., having the same manufacturer and model number but different serial numbers). Thus, the user may periodically replace (e.g., swap, cycle, or rotate out) an “in-use” medical device with a replacement medical device of the same type when the in-use medical device approaches an inoperable state (e.g., due to a low battery level, an occluded cannula, and/or an empty insulin reservoir). The term “in-use” should not be considered as limited to a device that is currently in use. For example, in some contexts, the term “in-use” may refer to the most recently used device.

When the user switches from the in-use medical device to the replacement medical device, the replacement medical device may not have the most up-to-date user-specific configuration data. Thus, when the replacement medical device is placed into service, the user typically configures it with the most up-to-date user-specific configuration data.

However, relying on the user to update user-specific configuration data can be burdensome. Furthermore, the user may incorrectly update user-specific configuration data (e.g., perform an incorrect update procedure), may update the user-specific configuration data with incorrect data, or may forget or fail to update user-specific configuration data on the replacement device.

This disclosure describes example techniques related to automatically configuring a replacement device with the most up-to-date user-specific configuration data. More specifically, when an in-use device is being replaced, the example techniques may be used to replace or update user-specific configuration data on the replacement device. For example, the in-use device may automatically transfer some or all of its user-specific configuration data to cause updating of outdated configuration data on the replacement device. Advantageously, automatically configuring a replacement device with the most up-to-date user-specific configuration data enables a substantially seamless handoff between devices.

Automatic configuration of a replacement device can be achieved in a variety of ways. The following describes examples in the context of medical devices. More specifically, one medical device corresponds to an in-use device, and another medical device corresponds to a replacement device.

In some examples, a replacement device (e.g., a first medical device) may be a wearable device configured to automatically detect whether it is being placed into service (e.g., deployed on the body of a user or otherwise prepared for use). Upon detecting that it is being placed into service, the replacement device may communicate with an in-use device (e.g., a second medical device) to obtain the most up-to-date configuration data. When the replacement device obtains the configuration data from the in-use device, the configuration data may be used to automatically configure the replacement device.

There are a variety of ways in which the replacement device can detect that it is being placed into service. For example, the replacement device may detect activation of its cannula insertion mechanism, process a sensor signal indicative of skin contact, detect actuation of a mechanical switch located on a surface of the replacement device, and/or determine that an integrated glucose sensor is in contact with interstitial fluid.

In some examples, an in-use device (e.g., a first medical device) may be a wearable device configured to automatically detect whether it is being taken out of service (e.g., removed from the body of a user or otherwise prepared for disuse). Upon detecting that it is being taken out of service, the in-use device may communicate with a replacement device (e.g., a second medical device) so that the replacement device obtains the most up-to-date configuration data. When the replacement device obtains the configuration data from the in-use device, the configuration data may be used to automatically configure the replacement device.

There are a variety of ways in which the in-use device can detect that it is being taken out of service. For example, the in-use device may determine that its cannula is no longer inserted in the body of the user, process a sensor signal indicative of an absence of skin contact, detect resetting of a mechanical switch located on a surface of the in-use device, and/or determine that an integrated glucose sensor is not in contact with interstitial fluid.

In some examples, a charger device (e.g., a docking station or a wireless charging mat) may be used to “trickle transfer” configuration data from an in-use device (e.g., a first medical device) to a replacement device (e.g., a second medical device). Thus, the charger device may be configured to communicate with one or more cloud-based servers to obtain configuration data as it is updated at the in-use device. In this way, the replacement device may be automatically configured with the most up-to-date configuration data whenever the in-use device updates its configuration data.

FIG.1is a block diagram illustrating an example glucose level management system comprising a tethered pump, in accordance with one or more examples described in this disclosure.FIG.1illustrates system10A that includes insulin pump14, tubing16, infusion set18, monitoring device20(e.g., a glucose level monitoring device comprising a glucose sensor), patient device24, and cloud26. Insulin pump14may be described as a tethered pump, because tubing16tethers insulin pump14to infusion set18. Cloud26represents a local, wide area or global computing network including one or more servers28A-28N (“one or more servers28”). Each of one or more servers28may include one or more processors and memory. In some examples, the various components may determine changes to therapy based on determination of glucose level for monitoring device20, and therefore system10A may be referred to as glucose level management system10A.

Patient12may be diabetic (e.g., Type 1 diabetic or Type 2 diabetic), and therefore, the glucose level in patient12may be controlled with delivery of supplemental insulin. For example, patient12may not produce sufficient insulin to control the glucose level or the amount of insulin that patient12produces may not be sufficient due to insulin resistance that patient12may have developed.

To receive the supplemental insulin, patient12may carry insulin pump14that couples to tubing16for delivery of insulin into patient12. Infusion set18may connect to the skin of patient12and include a cannula to deliver insulin into patient12. Monitoring device20may also be coupled to patient12to measure glucose level in patient12. Insulin pump14, tubing16, infusion set18, and monitoring device20may together form an insulin pump system. One example of the insulin pump system is the MINIMED™ 670G insulin pump system by MEDTRONIC MINIMED, INC. However, other examples of insulin pump systems may be used and the example techniques should not be considered limited to the MINIMED™ 670G insulin pump system. For example, the techniques described in this disclosure may be utilized in insulin pump systems that include wireless communication capabilities. However, the example techniques should not be considered limited to insulin pump systems with wireless communication capabilities, and other types of communication, such as wired communication, may be possible. In another example, insulin pump14, tubing16, infusion set18, and/or monitoring device20may be contained in the same housing.

As described in more detail below, in some examples, rather than utilizing a tethered pump system comprising insulin pump14, tubing16, infusion set18, and/or monitoring device20, patient12may utilize a patch pump, such as insulin pump30illustrated inFIG.2. Insulin pump30may be described as a patch pump, because it can be removably attached to patient12using a small piece of adhesive material worn on the skin. Instead of delivering insulin via tubing and an infusion set, insulin pump30may deliver insulin via a cannula extending directly from insulin pump30. In some examples, a glucose sensor may also be integrated into insulin pump30. In such examples, insulin pump30may be referred to as an all-in-one (AIO) insulin pump.

Referring back toFIG.1, insulin pump14may be a small device that patient12can place in different locations. For instance, patient12may clip insulin pump14to the waistband of pants worn by patient12. In some examples, to be discreet, patient12may place insulin pump14in a pocket. In general, insulin pump14can be worn in various places, and patient12may place insulin pump14in a location based on the particular clothes patient12is wearing.

To deliver insulin, insulin pump14may include one or more reservoirs (e.g., two reservoirs). In some examples, a reservoir may be included in a plastic cartridge that holds up to N units of insulin (e.g., up to 300 units of insulin) and that can be secured within insulin pump14. In some examples, a reservoir may be integrated into insulin pump14such that the reservoir can be filled using a syringe. Insulin pump14may be a battery-powered device that is powered by replaceable and/or rechargeable batteries.

Tubing16may connect at a first end to a reservoir in insulin pump14and may connect at a second end to infusion set18. Tubing16may carry the insulin from the reservoir of insulin pump14to patient12. Tubing16may be flexible, allowing for looping or bends to minimize concern of tubing16becoming detached from insulin pump14or infusion set18or concern from tubing16breaking.

Infusion set18may include a thin cannula that patient12inserts into a layer of fat under the skin (e.g., subcutaneous connection). Infusion set18may rest near the stomach of patient12. The insulin may travel from the reservoir of insulin pump14, through tubing16, through the cannula in infusion set18, and into patient12. In some examples, patient12may utilize an infusion set insertion device. Patient12may place infusion set18into the infusion set insertion device, and with a push of a button on the infusion set insertion device, the infusion set insertion device may insert the cannula of infusion set18into the layer of fat of patient12, and infusion set18may rest on top of the skin of the patient with the cannula inserted into the layer of fat of patient12.

Monitoring device20may include a sensor that is inserted under the skin of patient12, such as near the stomach of patient12or in the arm of patient12(e.g., subcutaneous connection). The sensor of monitoring device20may be configured to measure the interstitial glucose level, which is the glucose found in the fluid between the cells of patient12. Monitoring device20may be configured to continuously or periodically sample the glucose level and rate of change of the glucose level over time.

In one or more examples, insulin pump14, monitoring device20, and/or the various components illustrated inFIG.1, may together form a closed-loop therapy delivery system. For example, patient12may set a target glucose level, usually measured in units of milligrams per deciliter, on insulin pump14. Insulin pump14may receive the current glucose level from monitoring device20and, in response, may increase or decrease the amount of insulin delivered to patient12. For example, if the current glucose level is higher than the target glucose level, insulin pump14may increase the insulin. If the current glucose level is lower than the target glucose level, insulin pump14may temporarily cease delivery of the insulin. Insulin pump14may be considered as an example of an automated insulin delivery (AID) device. Other examples of AID devices may be possible, and the techniques described in this disclosure may be applicable to other AID devices. As described in more detail below, insulin pump14may be configured to operate in accordance with user-specific configuration data to delivery insulin to patient12.

Insulin pump14and monitoring device20may be configured to operate together to mimic some of the ways in which a healthy pancreas works. Insulin pump14may be configured to deliver basal dosages, which are small amounts of insulin released continuously throughout the day. There may be times when glucose levels increase, such as due to eating or some other activity that patient12undertakes. Insulin pump14may be configured to deliver bolus dosages on demand in association with food intake or to correct an undesirably high glucose level in the bloodstream. In one or more examples, if the glucose level rises above a target level, then insulin pump14may deliver a bolus dosage to address the increase in glucose level. Insulin pump14may be configured to compute basal and bolus dosages and deliver the basal and bolus dosages accordingly. For instance, insulin pump14may determine the amount of a basal dosage to deliver continuously and then determine the amount of a bolus dosage to deliver to reduce glucose level in response to an increase in glucose level due to eating or some other event.

Accordingly, in some examples, monitoring device20may sample glucose levels for determining rate of change in glucose level over time. Monitoring device20may output the glucose level to insulin pump14(e.g., through a wireless link connection like Bluetooth or BLE). Insulin pump14may compare the glucose level to a target glucose level (e.g., as set by patient12or a clinician) and adjust the insulin dosage based on the comparison. In some examples, insulin pump14may adjust insulin delivery based on a predicted glucose level (e.g., where glucose level is expected to be in the next 30 minutes).

As described above, patient12or a clinician may set one or more target glucose levels on insulin pump14. There may be various ways in which patient12or the clinician may set a target glucose level on insulin pump14. As one example, patient12or the clinician may utilize patient device24to communicate with insulin pump14. Examples of patient device24include mobile devices, such as smartphones, tablet computers, laptop computers, and the like. In some examples, patient device24may be a special programmer or controller (e.g., a dedicated remote control device) for insulin pump14. AlthoughFIG.1illustrates one patient device24, in some examples, there may be a plurality of patient devices. For instance, system10A may include a mobile device and a dedicated wireless controller, each of which is an example of patient device24. For ease of description only, the example techniques are described with respect to patient device24with the understanding that patient device24may be one or more patient devices.

Patient device24may also be configured to interface with monitoring device20. As one example, patient device24may receive information from monitoring device20through insulin pump14, where insulin pump14relays the information between patient device24and monitoring device20. As another example, patient device24may receive information (e.g., glucose level or rate of change of glucose level) directly from monitoring device20(e.g., through a wireless link).

In one or more examples, patient device24may comprise a user interface with which patient12or the clinician may control insulin pump14. For example, patient device24may comprise a touchscreen that allows patient12or the clinician to enter a target glucose level. Additionally or alternatively, patient device24may comprise a display device that outputs the current and/or past glucose level. In some examples, patient device24may output notifications to patient12, such as notifications if the glucose level is too high or too low, as well as notifications regarding any action that patient12needs to take. For example, if the batteries of insulin pump14are low on charge, then insulin pump14may output a low battery indication to patient device24, and patient device24may in turn output a notification to patient12to replace or recharge the batteries.

Controlling insulin pump14through a display device of patient device24is merely provided as an example and should not be considered limiting. For example, insulin pump14may include pushbuttons that allow patient12or the clinician to set the various glucose levels of insulin pump14. In some examples, insulin pump14itself, or in addition to patient device24, may be configured to output notifications to patient12. For instance, if the glucose level is too high or too low, insulin pump14may output an audible or haptic output. In some examples, if the battery is low, then insulin pump14may output a low battery indication on a display of insulin pump14.

In the example ofFIG.1, insulin pump14may be an in-use device or a replacement device. In some examples, the replacement insulin pump may be similar, including identical, to insulin pump14(e.g., same make and model with same capabilities). However, in some other examples, the replacement insulin pump may not be similar (e.g., have different capabilities) to insulin pump14.

As described above, during the operation of insulin pump14, user-specific configuration data may be updated. Examples of user-specific configuration data include one or more insulin delivery rate limits (e.g., a maximum basal rate and/or a maximum bolus rate), insulin-on-board (e.g., unmetabolized insulin from one or more previous bolus dosages), a history of insulin delivery, one or more glucose sensor calibration factors (e.g., a previous and/or current sensor sensitivity ratio for converting a sensor signal value into a blood glucose level), a safe basal rate (e.g., a basal rate that is fixed in that it does not adjust based on current sensor values), and an insulin sensitivity factor (e.g., a ratio that describes the effect of one unit of insulin on glucose levels). It should be appreciated that the above are non-limiting examples of user-specific configuration data stored on insulin pump14and that the particular configuration data used may vary from implementation to implementation.

When insulin pump14is replaced (e.g., rotated, swapped out), a replacement insulin pump may not have the updated user-specific configuration data. To address this problem, disclosed herein are example techniques for automating the transfer of user-specific configuration data from an in-use device (e.g., insulin pump14) to a replacement device (e.g., a replacement insulin pump). In some examples, user-specific configuration data may be transferred when the in-use device is being taken out of service and/or the replacement device is being placed into service. For instance, the in-use device may transfer the user-specific configuration data in response to a determination that the in-use device is being removed from service. Additionally or alternatively, the replacement device may request the user-specific configuration data in response to a determination that the replacement device is being placed into service.

Waiting to transfer user-specific configuration data when the in-use device is being taken out of service and/or is being placed into service increases the likelihood that the replacement device will receive the most up-to-date user-specific configuration data. Furthermore, when the transfer of the user-specific configuration data is automated, little to no patient interaction may be involved. Relying on patient12or some other user to configure the replacement device can introduce human error. By automating, such human error may be minimized or avoided altogether.

User-specific configuration data can be transferred between an in-use device and a replacement device in a variety of ways. As one example, the in-use device may directly communicate (e.g., via push or pull) the user-specific configuration data to the replacement device. As another example, the in-use device may indirectly communicate the user-specific configuration data to the replacement device via an intermediate device (e.g., patient device24or one or more servers28of cloud26). Furthermore, user-specific configuration data may be transferred via any number of various communication links (e.g., radio frequency (RF) communication, Bluetooth (BLE) communication, near-field communication (NFC), or optical communication).

As illustrated inFIG.1, system10A includes cloud26that includes one or more servers28. Cloud26may include a plurality of network devices (e.g., servers28), and each network device may include one or more processors. Cloud26represents a cloud infrastructure that supports one or more servers28which may execute applications or operations requested by one or more users. For example, one or more servers28may remotely store, manage, and/or process data that would otherwise be locally stored, managed, and/or processed by patient device24. One or more processors of one or more servers28may share data or resources for performing computations and may be part of computing servers, web servers, database servers, and the like. One or more servers28may be within a data center or may be distributed across multiple data centers. In some cases, the data centers may be in different geographical locations.

One or more processors of one or more servers28, as well as other processing circuitry described herein, can include one or more of any of the following: microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. The functions attributed to the one or more processors, as well as other processing circuitry described herein may be embodied as hardware, firmware, software or any combination thereof.

One or more processors of one or more servers28may be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Fixed-function circuits refer to circuits that provide particular functionality and are preset on the operations that can be performed. Programmable circuits refer to circuits that can be programmed to perform various tasks and provide flexible functionality in the operations that can be performed. For instance, programmable circuits may execute software or firmware that cause the programmable circuits to operate in the manner defined by instructions of the software or firmware. Fixed-function circuits may execute software instructions (e.g., to receive parameters or output parameters), but the types of operations that the fixed-function circuits perform are generally immutable. In some examples, the one or more of processors may include distinct circuit blocks (fixed-function or programmable), and in some examples, the one or more processors may include integrated circuits. The one or more processors may include arithmetic logic units (ALUs), elementary function units (EFUs), digital circuits, analog circuits, and/or programmable cores, formed from programmable circuits. In examples where the operations of one or more servers28are performed using software executed by the programmable circuits, memory accessible by one or more servers28may store the object code of the software that one or more processors of one or more servers28receive and execute.

FIG.2is a block diagram illustrating an example glucose level management system comprising a patch pump, in accordance with one or more examples described in this disclosure.FIG.2illustrates system10B that is similar to system10A ofFIG.1. However, in system10B, patient12may not have insulin pump14. Rather, patient12may utilize insulin pump30to deliver insulin.

Insulin pump30may be different than insulin pump14in that insulin pump30is an example of an on-body pump. Stated differently, insulin pump30is designed to be removably affixed to the skin of patient12.

In one or more examples, insulin pump30may include a glucose sensor similar to that of monitoring device20. Having the glucose sensor integrated into insulin pump30may be beneficial because of reduction in device on-body footprint, more reliable communication between the glucose sensor and components of insulin pump30(e.g., having a wired instead of wireless connection between the glucose sensor and the components of insulin pump30), and sharing of components such as the same processing circuitry for the pump and the glucose sensor, as a few examples. Insulin pump30may be referred to as an all-in-one (AIO) insulin pump. In some other examples, rather than the glucose sensor being integrated into insulin pump30, the glucose sensor may included in a device (e.g., monitoring device20) that is separate from insulin pump30.

Patient12may replace insulin pump30, for example, when the battery of insulin pump30is nearly depleted, when the insulin reservoir of insulin pump30is empty, or when the cannula of insulin pump30becomes occluded. In some examples, patient12may replace insulin pump30every few days (e.g., every 3 days).

In some examples, insulin pump30may be fully disposable in that patient12replaces insulin pump30in its entirety with a new insulin pump. However, in some other examples, insulin pump30may be semi-disposable in that it includes a durable/reusable portion and a consumable/disposable portion.

For example,FIGS.3A and3Bare different perspective views of a semi-disposable patch pump configured to provide therapy, in accordance with one or more examples described in this disclosure.FIG.3Aillustrates durable portion32and consumable portion34of insulin pump30. In some examples, durable portion32includes electronics (e.g., rechargeable batteries, processor, and memory), and consumable portion34includes insulin-contacting components, such as an insulin reservoir. As illustrated inFIG.3B, consumable portion34may also include patient-contacting components, such as cannula36and glucose sensor38. Glucose sensor38may be similar to the glucose sensor of monitoring device20.

There are a variety of ways in which durable portion32and consumable portion34may be operatively coupled. For example, there may be an electrical connection that facilitates communication between a processor of portion32and various components of portion34, a mechanical connection that enables a motor of portion32to exert a force on gears of portion34, and/or an electromagnetic connection that allows a motor stator in portion32to induce movement of a motor rotor in portion34.

Regardless of whether a patch pump is fully disposable or semi-disposable, it may be replaced periodically. For example, a semi-disposable patch pump may comprise a battery in a durable portion and a reservoir in a consumable portion. When the reservoir is empty, the patch pump may be removed from patient12, and the durable portion may be separated from the consumable portion. Upon separation, the durable portion may have its battery recharged (e.g., by connecting the durable portion to a charger device), and the consumable portion may simply be discarded. A replacement patch pump may be formed based on removably securing a replacement durable portion (e.g., a second durable portion that has recently been disconnected from the charger device) to a new consumable portion. Thus, patient12may have at least two durable portions—an in-use durable portion that is attached to patient12and a replacement durable portion that stands by waiting to replace the in-use durable portion.

However an in-use device and a replacement device may have different data stored in memory. For example, an in-use durable portion may have the most up-to-date configuration data, whereas a replacement durable portion may have default configuration data. A user may manually configure the replacement durable portion with the most up-to-date configuration data, but this approach tends to be error-prone. Furthermore, a manual configuration process may be so time-consuming that some data becomes outdated before the process can be completed. To address this problem, this disclosure describes example ways in which to automatically transfer user-specific configuration data between an in-use device and a replacement device.

Some example ways of automatically transferring user-specific configuration data involve a replacement device (e.g., a first medical device) that is configured to automatically determine whether it is being placed into service (e.g., placed in contact with the body of a user or otherwise prepared for use). The replacement device may be a replacement for an in-use device (e.g., a second medical device that was previously placed into service to provide medical therapy to patient12in accordance with user-specific configuration data stored on the second medical device). Upon determining that it is being placed into service, the replacement device may automatically communicate data indicative of the replacement device being placed into service (e.g., a request for the user-specific configuration data). Thereafter, the replacement device may obtain the user-specific configuration data, and the replacement device may be automatically configured to provide therapy in accordance with the user-specific configuration data.

There are a variety of ways in which the replacement device may determine that it is being placed into service. For example, in the context of a semi-disposable patch pump, durable portion32may determine that it has been removably attached to consumable portion34(e.g., based on a signal from a magnetoresistive (MR) sensor, a mechanical switch, a light sensor, and/or a Hall sensor configured to detect a motor rotor in consumable portion34) in preparation for deployment on the body of patient12. Provided below are some other examples that are not necessarily limited to the context of a semi-disposable patch pump.

In some examples, the replacement device may determine it is being placed into service based on determining activation of a cannula insertion mechanism associated with the replacement device. For example, the cannula insertion mechanism may comprise conductive elements configured to interface with conductive elements on the pump housing upon cannula insertion, thereby completing a circuit for conveying an electrical signal to a processor.

In some examples, the replacement device may determine it is being placed into service based on processing an electrical signal from a skin contact sensor (e.g., a temperature sensor, a sweat sensor, a bioimpedance sensor, a capacitance sensor, and/or an optical sensor) associated with the replacement device. For example, durable portion32may include a pulse oximeter configured to detect a heart rate that can be used to determine that durable portion32has been deployed on the body of patient12.

In some examples, the replacement device may determine it is being placed into service based on determining actuation of a mechanical switch (e.g., a snap action switch or a tactile switch). For example, durable portion32may include a mechanical switch configured to either complete or break a circuit upon actuation, which may result from contact with consumable portion34or the body of a user.

In some examples, the replacement device may determine it is being placed into service based on determining that a glucose sensor associated with the replacement device is in contact with interstitial fluid. For example, upon contact with interstitial fluid, a glucose sensor may generate an electrical signal that is communicated to a processor housed in durable portion32.

In some examples, the replacement device may determine it is being placed into service based on accelerometer data indicative of placement on the body of a user. For example, durable portion32may include an accelerometer configured to generate signals that can be processed to determine movement that is consistent with walking and/or to synthesize a biometric profile (e.g., based on a user's gait).

In some examples, the replacement device may determine it is being placed into service based on processing a signal indicative of a pull tab being removed from the replacement device. For example, a plastic pull tab may isolate a battery from a circuit such that removal of the pull tab may close the circuit, thereby enabling an electrical signal to be conveyed along the circuit to a processor.

In some examples, the replacement device may determine it is being placed into service based on determining that a charger device has been disconnected from the replacement device. For example, a replacement device may detect the absence of power being supplied to its battery.

In some examples, the replacement device may determine it is being placed into service based on receiving user input. For example, a replacement device may have one or more buttons which, when pressed by patient12, causes the replacement device to wake up, establish a communication link with another device (e.g., an in-use device or an intermediate device), and/or communicate directly/indirectly with an in-use device.

In some examples, the replacement device may determine it is being placed into service based on establishing a communication link with another device. For example, a replacement device may determine that it is being placed into service when a network connection is formed with an in-use device or patient device24.

Some example ways of automatically transferring user-specific configuration data involve an in-use device (e.g., a first medical device) that is configured to automatically determine whether it is being removed from service. The in-use device may have been previously placed into service to provide therapy in accordance with user-specific configuration data stored on the in-use device. Upon determining that the in-use device is being removed from service, a replacement device (e.g., a second medical device) may be configured to provide therapy in accordance with the user-specific configuration data. This may involve the in-use device communicating the user-specific configuration data toward the replacement device (e.g., directly or indirectly via one or more intermediate devices). For example, the in-use device may transmit the user-specific configuration data to the replacement device, thereby causing the replacement device to configure itself to provide therapy in accordance with the user-specific configuration data.

There are various ways in which the in-use device may determine it is being removed from service. For example, in the context of a semi-disposable patch pump, durable portion32may determine that it has been separated from consumable portion34(e.g., based on a signal/the absence of a signal from a MR sensor, a mechanical switch, a light sensor, and/or a Hall sensor configured to detect a motor rotor in consumable portion34) after removal from patient12. Provided below are some other examples that are not necessarily limited to the context of a semi-disposable patch pump.

In some examples, the in-use device may determine it is being removed from service based on determining removal of a cannula from the body of a user. For example, cannula removal may cause a decrease in pumping back-pressure, which may be detected by a force sensor configured to measure reaction force on a reservoir plunger.

In some examples, the in-use device may determine it is being removed from service based on processing a signal from a skin contact sensor associated with the in-use device. For example, durable portion32may include a light sensor that fails to detect light when placed against the body of a user and that detects light when no longer placed against the body of the user.

In some examples, the in-use device may determine it is being removed from service based on detecting a reset of a mechanical switch. For example, durable portion32may include a mechanical switch configured to automatically reset when no longer in contact with (e.g., separated from) consumable portion34or the body of a user.

In some examples, the in-use device may determine it is being removed from service based on determining that a glucose sensor associated with the in-use device is no longer in contact with interstitial fluid. For example, a glucose sensor may periodically (e.g., every five minutes) generate an electrical signal when it is in contact with interstitial fluid, so the in-use device may determine that the absence of an expected signal is indicative of removal.

In some examples, the in-use device may determine it is being removed from service based on processing a signal indicative of removal of a pull tab situated between the in-use device and a user. For example, a conductive/magnetic pull tab may be adhered to patient12such that when in-use device is removed from patient12, the pull tab breaks a circuit, thereby preventing an electrical signal from being conveyed along the circuit to a processor.

In some examples, the in-use device may determine it is being removed from service based on determining that a charger device has been connected to the in-use device. For example, the in-use device may detect power being supplied to its battery.

In some examples, the in-use device may determine it is being removed from service based on receiving user input. For example, an in-use device may have one or more buttons which, when pressed by patient12, causes the in-use device to wake up, establish a communication link with another device (e.g., a replacement device or an intermediate device), and/or communicate directly/indirectly with a replacement device.

In some examples, the in-use device may determine it is being removed from service based on detecting that a component has become inoperable. For example, the in-use device may determine that it has a low battery, that it has an empty insulin reservoir, and/or that a glucose sensor has reached the end of its life based on processing a signal from a battery monitor, processing a signal from a force sensor, and/or failing to process any signal from the glucose sensor.

In some examples, the in-use device may determine it is being removed from service based on discontinuing communications with another device. For example, an in-use device may determine it is being removed from service when it loses a network connection with a replacement device or patient device24.

For the avoidance of doubt, it is further emphasized that the example techniques disclosed herein are not limited to semi-disposable patch pumps but are equally applicable to various other devices, including medical devices (e.g., insulin pump14or monitoring device20) and non-medical devices (e.g., a smartwatch or computing eyewear). For example, tubing16may include a magnet where it is configured to connect with insulin pump14. Thus, insulin pump14may determine that it is being put into service when the magnet is detected, and insulin pump14may determine that it is being removed from service when the magnet is no longer detected.

Some example ways of automatically transferring user-specific configuration data involve an intermediate device (e.g., patient device24) that is configured to automatically determine whether a replacement device is being placed into service and/or an in-use device is being removed from service. For example, patient device24may determine received signal strength indication (RSSI) values for signals received from an in-use medical device and a replacement medical device that are each communicatively coupled to patient device24. Each RSSI value may be indicative of a distance between patient device24and a respective device. Typically, the in-use medical device and patient device24are located on or near patient12. Thus, patient device24may identify the in-use medical device based on associating it with a consistently high RSSI value. Furthermore, patient device24may use RSSI values to determine that the in-use medical device is being removed from service and that the replacement medical device is being placed into service and vice versa.

FIG.4is a block diagram illustrating an example communication system for transferring user-specific configuration data via an intermediate device, in accordance with one or more examples described in this disclosure.FIG.4illustrates in-use medical device40A and replacement medical device40B communicating with patient device24. Optionally, patient device24may be communicatively coupled to one or more servers28of cloud26.

When user-specific configuration data is updated, device40A may communicate the updated configuration data to patient device24. Communication of the updated configuration data may be achieved in a variety of ways. For example, device40A may transmit the updated configuration data to patient device24in response to determining that user-specific configuration data has been updated. As another example, patient device24may periodically poll device40A to determine whether it has any updated configuration data, and if so, patient device24may request the updated configuration data.

In some examples, patient device24may store the updated configuration data in its memory. For example, patient device24may cache the updated configuration data. In some examples, patient device24may communicate the updated configuration data to another device without keeping a copy on patient device24. For example, patient device24may stream the updated configuration data to cloud26. In some examples, patient device24may communicate the updated configuration data to cloud26, and one or more servers28of cloud26may store the updated configuration data. For example, the updated configuration data may be transferred (e.g., via push and/or pull) between patient device24and a database in cloud26that stores the updated configuration data.

When device40B is being placed into service and/or when device40A is being removed from service, patient device24may determine whether it has the most up-to-date configuration data. For example, when device40B is being placed into service, patient device24may request configuration data from device40A (e.g., in response to receiving a request for configuration data from device40B, upon establishing a communication link with device40B, or otherwise based on determining that device40B is being placed into service). Additionally or alternatively, in response to determining that device40A is being removed from service, device40A may transmit its configuration data to patient device24. Upon obtaining the configuration data from device40A, patient device24may determine whether the obtained configuration data is an updated version of configuration data stored on patient device24(e.g., by comparing the obtained configuration data to configuration data stored on patient device24and/or obtained from cloud26). When patient device24determines that the obtained configuration data is an updated version, patient device24may update its outdated configuration data.

Patient device24may communicate the most up-to-date configuration data to device40B for automatic configuration. In some examples, this may involve transfer of the configuration data over a previously established communication link between patient device24and device40B. In some other examples, this may involve establishing a communication link between patient device24and device40B.

In some examples, user-specific configuration data may be automatically transferred based on predicting when device replacement will occur. For example, a history of device replacement may be collected, and machine learning techniques may be applied to the history to determine one or more patterns, which can be used to predict when device replacement will occur. Based on such predictions, device40A, device40B, and/or patient device24may automatically initiate transfer of user-specific configuration data.

As mentioned above, transfer of user-specific configuration data may be automatically initiated by one or more devices (e.g., device24, device40A, and/or device40B). However, in some examples, transfer of user-specific configuration data may be initiated based on user input. For example, patient12may press one or more buttons (e.g., in a prescribed sequence of presses) on device40A, device40B, and/or device24to initiate transfer of user-specific configuration data between device40A and device40B. Pressing the one or more buttons may cause one or more devices to wake up, establish one or more communication links for transferring user-specific configuration data, and/or communicate over the one or more communication links.

In some examples, user-specific configuration data may be transferred based on user intervention. For example, user-specific configuration data may be stored on a memory card (e.g., subscriber identification module (SIM) card or micro secure digital (SD) card) or some other removable data storage medium. Thus, patient12may physically transfer the memory card from device40A to device40B (and vice versa) to facilitate automatic configuration based on the content of the memory card.

FIG.5is a block diagram illustrating an example communication system comprising a networked charger device, in accordance with one or more examples described in this disclosure. In some examples, rather than or in addition to transferring user-specific configuration data when an in-use device is being removed from service and/or a replacement device is being placed into service, user-specific configuration data may be “trickle” transferred between the in-use device and the replacement device. This may involve a network of one or more intermediate devices (e.g., patient device24, charger device42, and/or one or more servers28of cloud26). For instance, when user-specific configuration data is updated, the in-use device may communicate the updated user-specific configuration data to an intermediate device (e.g., patient device24which communicates the updated user-specific configuration data to one or more servers28of cloud26), and the replacement device may synchronize its version of user-specific configuration data with the version available on an intermediate device (e.g., charger device42which obtains the updated user-specific configuration data from one or more servers28of cloud26).

In some examples, when in-use device40A is in service, the batteries of replacement device40B may be charged. As illustrated inFIG.5, charger device42may be configured to charge the batteries of replacement device40B. Charger device42may be connected to a power source, such as AC power in a home via a wall socket.

Charger device42may be configured to utilize any of a variety of techniques to charge the batteries of replacement device40B. In some examples, charger device42may be configured to charge replacement device40B via an electrical connection (e.g., conductive contacts or a power cable that plugs into replacement device40B). In some other examples, charger device42may be configured to wirelessly charge the batteries of replacement device40B. For example, charger device42may include an induction coil to create an alternating electromagnetic field, and replacement device40B may include a receiver coil that converts the electromagnetic filed into electricity that is fed to the battery for charging.

In the example ofFIG.5, charger device42may be configured to communicate data to replacement device40B. Data may be communicated at any time relative to power transmission (e.g., prior to, concurrently with, and/or subsequent to). In examples where charger device42outputs power to replacement device40B through a power cable, the power cable may be a universal serial bus (USB) cable, such as a USB-C cable, that is also configured for data transfer. In examples where charger device42outputs power wirelessly, charger device42may utilize near field communication (NFC) techniques for communicating with replacement device40B.

Various communication protocols may be used to transfer data between charger device42and replacement device40B. In some examples, data transfer may occur upon determining that an updated version of configuration data is available. For example, charger device42may be configured to push configuration data to replacement device40B in response to determining that the configuration data is an updated version (e.g., based on comparing configuration data obtained from cloud26against configuration data stored on charger device42). As another example, replacement device40B may be configured to pull configuration data from charger device42(e.g., based on periodically polling charger device42for updated configuration data). In some other examples, data transfer may occur irrespective of whether an updated version of configuration data is available. For example, charger device42may periodically (e.g., at predetermined time intervals) or continuously push user-specific configuration information to replacement device40B. As another example, replacement device40B may periodically or continuously pull user-specific configuration data from charger device42. Regardless of the manner in which it is performed, the data transfer may cause automatic configuration of replacement device40B with updates.

As mentioned above, charger device42may obtain configuration data from cloud26. Data transfer between charger device42and cloud26may be performed using various communication protocols (e.g., push or pull) and with or without determining whether an updated version of configuration data is available. For example, charger device42may periodically poll one or more servers28of cloud26for any updated configuration data. In response to receiving a request for any updated configuration data, one or more servers28may determine whether it has an updated version of configuration data on charger device42(e.g., based on comparing a timestamp in the request to a timestamp for configuration data stored on one or more servers28). When one or more servers28determines that it has an updated version, it may communicate all or part of the updated version (e.g., based on comparing different versions to determine which portion of configuration data has changed) to charger device42.

In one or more examples, in-use device40A may communicate user-specific configuration data toward one or more servers28(e.g., directly to or indirectly via patient device24). Data transfer between in-use device40A and one or more servers28may be performed using various communication protocols (e.g., push or pull) and with or without determining whether an updated version of configuration data is available. For instance, whenever its user-specific configuration data is updated, in-use device40A may push the updated user-specific configuration data to patient device24or one or more servers28.

In examples involving patient device24as an intermediate device between in-use device40A and one or more servers28, data transfer between patient device24and one or more servers28may also be performed using various communication protocols (e.g., push or pull) and with or without determining whether an updated version of configuration data is available. For example, patient device24may periodically communicate configuration data to one or more servers28, which determines whether the configuration data obtained from patient device24is an updated version of configuration data stored on one or more servers28(e.g., based on comparing timestamps, checksums, or other metadata).

Using the example system ofFIG.5, in some instances, replacement device40B may already have the most up-to-date user-specific configuration data by the time it is to be placed into service. However, to help ensure that replacement device40B has the most up-to-date user-specific configuration data when it is being placed into service, one or more checks may be performed for any updated configuration data when device40A is being removed from service and/or device40B is being placed into service. For example, replacement device40B may perform a check based on requesting configuration data from charger device42when device40A is being removed from service and/or device40B is being placed into service. Additionally or alternatively, replacement device40B may perform a check based on requesting configuration data from patient device24when device40A is being removed from service and/or device40B is being placed into service. Performing multiple checks involving different devices may help account for network latency and/or connectivity issues that could hinder communication of updated configuration data to replacement device40B.

Although the previous example is provided in terms of replacement device40B requesting configuration data, it should be appreciated that the one or more checks may be performed with one or more other devices (alone or in combination with device40B) using various communication protocols (e.g., push or pull) and with or without determining whether an updated version of configuration data is available. For example, when device40A is being removed from service and/or device40B is being placed into service, patient device24may establish a communication link with device40B and push configuration data to it.

As mentioned above, one or more checks may be performed when device40A is being removed from service and/or device40B is being placed into service. In some examples, the one or more checks may be initiated upon detecting that device40A is being removed from service and/or that device40B is being placed into service. The detection may be performed using any number of the various techniques disclosed herein. For example, in-use device40A may detect that it is being removed from service and communicate data indicative of removal to patient device24, which may communicate the data to device40B, thereby causing one or more checks to be performed.

Although the example ofFIG.5involves a networked charger device42, user-specific configuration data may be transferred via a charger device that is not networked. For instance, such a charger device may include two charging ports—one for device40A and one for device40B. When devices40A and40B are both in the charger device, patient12may press a button to initiate transfer of user-specific configuration data between devices40A and40B.

FIG.6is a block diagram illustrating an example medical device, in accordance with one or more examples described in this disclosure.FIG.6illustrates medical device51, which may be an in-use device or a replacement device. Examples of medical device51include insulin pump14and insulin pump30.

As illustrated, medical device51includes processing circuitry50, memory52, telemetry circuitry54, power source56, insulin reservoir58, motor controller60, and one or more sensors62. Medical device51may include more or fewer components than those illustrated inFIG.6. Also, when medical device51is a semi-disposable patch pump, some components of medical device51may be located in durable portion32, and other components may be located in consumable portion34. For example, processing circuitry50, memory52, telemetry circuitry54, motor controller60, sensors62, and power source56may be part of durable portion32; and insulin reservoir58may be part of consumable portion34. However, the particular combination of components in durable portion32and consumable portion34may vary from implementation to implementation.

Memory52may store program instructions that, when executed by processing circuitry50, cause processing circuitry50to provide the functionality ascribed to insulin pump14, insulin pump30, device40A, and/or device40B throughout this disclosure. Memory52may also store user-specific configuration data.

Memory52may include any volatile, non-volatile, fixed, removable, magnetic, optical, or electrical media, such as RAM, ROM, hard disk, removable magnetic disk, memory cards or sticks, NVRAM, EEPROM, flash memory, and the like. Processing circuitry50can take the form one or more microprocessors, DSPs, ASICs, FPGAs, programmable logic circuitry, or the like, and the functions attributed to processing circuitry50herein may be embodied as hardware, firmware, software or any combination thereof.

In one or more examples, processing circuitry50may utilize the user-specific configuration data stored in memory52to output instructions to motor controller60for regulating insulin delivery. Motor controller60may be configured to control the timing and amount of insulin displacement from insulin reservoir58based on the instructions from processing circuitry50.

One or more sensors62may include a glucose sensor (e.g., glucose sensor38) and/or any number of sensors capable of generating signals indicative of medical device51being placed into service and/or removed from service. For instance, one or more sensors62may include temperature sensors, sweat sensors, resistance sensors, and the like that are configured to generate signals indicative of whether or not medical device51is attached to the body of patient12.

In accordance with one or more examples described in this disclosure, telemetry circuitry54may be configured to send and/or receive user-specific configuration data. Telemetry circuitry54may include any suitable hardware, firmware, software, or any combination thereof for enabling communication between medical device51and another device (e.g., one or more servers28of cloud26, patient device24, replacement device40B, and/or charger device42). Telemetry circuitry54may send and/or receive communications with the aid of an antenna, which may be internal and/or external to medical device51. Telemetry circuitry54may be configured to communicate via wired or wireless communication techniques. Examples of local wireless communication techniques that may be employed to facilitate communication include RF communication according to IEEE 802.11, Bluetooth, or BLE specification sets, infrared communication, e.g., according to an IrDA standard, near field communication (NFC), or other standard or proprietary telemetry protocols. Telemetry circuitry54may also provide connectivity with a carrier network for access to cloud26. In this manner, other devices may be capable of communicating with medical device51.

Power source56delivers operating power to the components of medical device51. In some examples, power source56may include a battery, such as a rechargeable or non-rechargeable battery. A non-rechargeable battery may last for several days or possibly longer, while a rechargeable battery may be periodically charged from an external device, e.g., on a daily or weekly basis, with charger device42. Recharging of a rechargeable battery may be accomplished by using an alternating current (AC) outlet or through proximal inductive interaction between charger device42and an inductive charging coil within medical device51. In some examples, the inductive charging coil may be the same as the coil used for communication by telemetry circuitry54. In some other examples, the inductive charging coil may be separate from the coil used for communication by telemetry circuitry54.

FIG.7is a block diagram illustrating an example of a patient device, in accordance with one or more examples described in this disclosure. While patient device24may generally be described as a hand-held computing device, in some examples, patient device24may be a notebook computer, a desktop computer, or a workstation, for example. In some examples, patient device24may be a mobile device, such as a smartphone or a tablet computer. Patient device24may execute an application that allows patient device24to perform example techniques described in this disclosure. In some examples, patient device24may be a specialized controller for communicating with medical device51.

As illustrated inFIG.7, patient device24may include processing circuitry70, memory72, user interface74, telemetry circuitry76, and power source78. Memory72may store program instructions that, when executed by processing circuitry70, cause processing circuitry70to provide the functionality ascribed to patient device24throughout this disclosure.

In some examples, memory72of patient device24may store user-specific configuration data. For example, in-use device40A may transmit the user-specific configuration data to patient device24, and memory72may store the user-specific configuration data for transmission to replacement device40B, charger device42, or one or more servers28.

Memory72may include any volatile, non-volatile, fixed, removable, magnetic, optical, or electrical media, such as RAM, ROM, hard disk, removable magnetic disk, memory cards or sticks, NVRAM, EEPROM, flash memory, and the like. Processing circuitry70can take the form one or more microprocessors, DSPs, ASICs, FPGAs, programmable logic circuitry, or the like, and the functions attributed to processing circuitry32herein may be embodied as hardware, firmware, software, or any combination thereof.

User interface74may include a button or keypad, lights, a microphone for voice commands, and/or a display device, such as a liquid crystal (LCD). In some examples the display may be a touchscreen. Processing circuitry70may present and receive information relating to therapy via user interface74. For example, processing circuitry70may receive user input via user interface74. The user input may be entered, for example, by pressing a button on a keypad, entering text, or selecting an icon from a touchscreen. For example, to enter initial configuration data for medical device51, patient12or a physician may utilize user interface74to enter the configuration data.

Telemetry circuitry76may include any suitable hardware, firmware, software, or any combination thereof for enabling communication between patient device24and another device, such as one or more servers28of cloud26, in-use device40A, replacement device40B, and charger device42. Telemetry circuitry76may send and/or receive communications with the aid of an antenna, which may be internal and/or external to patient device24. Telemetry circuitry76may be configured to communicate via wired or wireless communication techniques. Examples of local wireless communication techniques that may be employed to facilitate communication between patient device24and another computing device include RF communication according to IEEE 802.11, Bluetooth, or BLE specification sets, infrared communication, e.g., according to an IrDA standard, near field communication (NFC), or other standard or proprietary telemetry protocols. Telemetry circuitry76may also provide connectivity with a carrier network for access to cloud26. In this manner, other devices may be capable of communicating with patient device24.

In some examples, telemetry circuitry76may include analog or digital RSSI detector circuitry that provides information indicative of the strength of signals received from different devices (e.g., in-use device40A and replacement device40B). As mentioned above, processing circuitry70may determine which device is in service and which device is out of service based on the information. In some examples, the information may also be indicative of signal quality (e.g., for how long the signal strength is high, how often the signal strength is high, and so forth).

Power source78delivers operating power to the components of patient device24. In some examples, power source39may include a battery, such as a rechargeable or non-rechargeable battery. A non-rechargeable battery may last for several months or years, while a rechargeable battery may be periodically charged from an external device, e.g., on a daily or weekly basis. Recharging of a rechargeable battery may be accomplished by using an alternating current (AC) outlet or through proximal inductive interaction between an external charger and an inductive charging coil within patient device24.

FIG.8is a block diagram illustrating an example of a charger device, in accordance with one or more examples described in this disclosure. As illustrated, charger device42includes processing circuitry80, memory82, power circuitry84, telemetry circuitry86, and AC/DC converter88.

In some examples, memory82may store user-specific configuration data. Memory82may include any volatile, non-volatile, fixed, removable, magnetic, optical, or electrical media, such as RAM, ROM, hard disk, removable magnetic disk, memory cards or sticks, NVRAM, EEPROM, flash memory, and the like. Processing circuitry80can take the form one or more microprocessors, DSPs, ASICs, FPGAs, programmable logic circuitry, or the like, and the functions attributed to processing circuitry80herein may be embodied as hardware, firmware, software, or any combination thereof.

Telemetry circuitry86may include any suitable hardware, firmware, software or any combination thereof for enabling communication between charger device42and another device, such as one or more servers28of cloud26, in-use device40A, replacement device40B, and patient device24. Telemetry circuitry86may send and/or receive communication with the aid of an antenna, which may be internal and/or external to charger device42. Telemetry circuitry86may be configured to communicate via wired or wireless communication techniques. Examples of local wireless communication techniques that may be employed to facilitate communication between charger device42and another computing device include RF communication according to IEEE 802.11, Bluetooth, or BLE specification sets, infrared communication, e.g., according to an IrDA standard, near field communication (NFC), or other standard or proprietary telemetry protocols. Telemetry circuitry86may also provide connectivity with a carrier network for access to cloud26. In this manner, other devices may be capable of communicating with charger device42.

AC/DC converter88may be configured to receive AC voltage and current through a wall socket in the home of patient12and convert the AC voltage and current to DC voltage and current. AC/DC converter88may thus provide power to the components of charger device42.

Power circuitry84may be configured to provide power to medical device51. For example, power circuitry84may include an inductive coil that outputs power to medical device51for charging its battery. In some examples, power circuitry84and telemetry circuitry86may use the same coil for wireless communication and power delivery. In some examples, power circuitry84and telemetry circuitry86may share the same cable to deliver power and communicate.

FIG.9is a flowchart illustrating an example process for automatic configuration based on placement into service, in accordance with one or more examples described in this disclosure. As illustrated inFIG.9, a first medical device (e.g., replacement device40B) may determine that it is being placed into service to provide medical therapy to a patient (90). The first medical device may be a replacement device for a second medical device (e.g., in-use device40A) that was previously placed into service to provide medical therapy to a patient in accordance with user-specific configuration data stored on the second medical device.

In some examples, the first medical device and the second medical device may share a number of similarities. For example, they may serve the same purpose (e.g., physiological characteristic monitoring and/or therapeutic substance delivery), have the same model number (e.g., 670G), etc. In some examples, the first and second medical devices may each be an insulin delivery device (e.g., insulin pump14or30) or may each be a portion of an insulin delivery device (e.g., durable portion32of insulin pump30). In some other examples, the first and second medical device may each be a glucose level monitor (e.g., monitoring device20).

There are various ways in which the first medical device may determine that it is being placed into service. For example, the first medical device may make this determination based on one or more of the following: determining that a first portion of the first medical device (e.g., durable portion32) is removably attached to a second portion of the first medical device (e.g., consumable portion34), determining activation of a cannula insertion mechanism associated with the first medical device, processing a signal from a skin contact sensor associated with the first medical device, determining actuation of a mechanical switch between the first medical device and the patient, and determining that an integrated glucose sensor associated with the first medical device is in contact with interstitial fluid.

The user-specific configuration data may include parameters, settings, and/or other forms of data that vary from user to user. Examples of the user-specific configuration data include one or more of the following: information indicative of insulin-on-board, a safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, an insulin sensitivity factor, and a history of insulin delivery.

Upon determining that it is being placed into service, the first medical device may communicate data indicative of the first medical device being placed into service (92). For example, the data may include a request for the user-specific configuration data.

In some examples, the first medical device may communicate the data to the second medical device. In some other examples, the first medical device may communicate the data to one or more intermediate devices (e.g., patient device24, charger device42, and/or one or more servers28).

After communicating the data indicative of the first medical device being placed into service, the first medical device may obtain the user-specific configuration data stored on the second medical device (93). In some examples, the first medical device may obtain the user-specific configuration data directly from the second medical device. For example, the first medical device may request user-specific configuration data from the second medical device, which responds with its user-specific configuration data. In some other examples, the first medical device may obtain the user-specific configuration data through an intermediate device that obtains it from the second medical device. For example, after the first medical device communicates that its cannula insertion mechanism has been activated, patient device24may obtain the user-specific configuration data from the second medical device and communicate the configuration data to the first medical device.

At any time prior to obtaining the user-specific configuration data, the first medical device may establish a communication link through which the first medical device obtains the user-specific configuration data. For example, when the first medical device is being placed into service, the patient may provide user input to establish a network connection between the first medical device and the second medical device or an intermediate device.

The first medical device may configure itself to provide therapy in accordance with the user-specific configuration data (94). Thus, obtaining the user-specific configuration data may initiate a process for automatically configuring the first medical device.

FIG.10is a flowchart illustrating an example process for automatic configuration based on removal from service, in accordance with one or more examples described in this disclosure. As illustrated inFIG.10, a first medical device (e.g., in-use device40A) may determine that it is being removed from service (96). The first medical device may have been previously placed into service to provide therapy to a patient in accordance with user-specific configuration data stored on the first medical device. In some examples, the first medical device is to be replaced with a second medical device (e.g., replacement device40B) that is a replacement device for the first medical device.

In some examples, the first medical device and the second medical device may share a number of similarities. For example, they may serve the same purpose (e.g., physiological characteristic monitoring and/or therapeutic substance delivery), have the same model number (e.g., 670G), etc. In some examples, the first and second medical devices may each be an insulin delivery device (e.g., insulin pump14or30) or may each be a portion of an insulin delivery device (e.g., durable portion32of insulin pump30). In some other examples, the first and second medical device may each be a glucose level monitor (e.g., monitoring device20).

There are various ways in which the first medical device may determine that it is being removed from service. For example, the first medical device may make this determination based on one or more of the following: that a first portion of the first medical device (e.g., durable portion32) is separated from a second portion of the first medical device (e.g., consumable portion34), determining removal of a cannula associated with the first medical device, processing a signal from a skin contact sensor associated with the first medical device, detecting a reset of a mechanical switch between the first medical device and the patient, determining that an integrated glucose sensor associated with the first medical device is no longer in contact with interstitial fluid, and receiving user input.

The user-specific configuration data may include parameters, settings, and/or other forms of data that vary from user to user. Examples of the user-specific configuration data include one or more of the following: information indicative of insulin-on-board, a safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, an insulin sensitivity factor, and a history of insulin delivery.

In response to determining that it is being removed from service, the first medical device may cause configuration of the second medical device to provide therapy to the patient in accordance with the user-specific configuration data (98). Causing configuration of the second medical device may include the first medical device communicating the user-specific configuration data toward the second medical device. Thus, the second medical device obtaining the user-specific configuration data may initiate a process for automatically configuring the second medical device.

In some examples, the first medical device may communicate the user-specific configuration data directly to the second medical device. For example, the first medical device may transmit data indicative of removal from service, the second medical device may respond with a request for the user-specific configuration data, and the first medical device may communicate the requested data to the second medical device. In some other examples, the first medical device may communicate the user-specific configuration data to one or more intermediate devices (e.g., patient device24, charger device42, and/or one or more servers28) from which the second medical device obtains the user-specific configuration data. For example, the first medical device may communicate the user-specific configuration data to patient device24, which forwards it to the second medical device.

At any time prior to communicating the user-specific configuration data, the first medical device may establish a communication link through which the first medical device communicates the user-specific configuration data. For example, when the first medical device is being removed from service, the patient may provide user input to establish a network connection between the first medical device and the second medical device.

FIG.11is a flowchart illustrating an example process for automatic configuration involving a networked charger device, in accordance with one or more examples described in this disclosure.FIG.11illustrates an example of transferring user-specific configuration data via charger device42.

Charger device42may obtain, from one or more server computing devices, user-specific configuration data stored on a first medical device (e.g., in-use device40A) that is configured to provide therapy to a patient in accordance with the user-specific configuration data (120). Charger device42may obtain the user-specific configuration data using various communication protocols (e.g., push or pull) and with or without regard for whether an update to the user-specific configuration data is available. For example, the one or more server computing devices may be configured to automatically push any updates to charger device42. As another example, charger device42may periodically poll the one or more server computing devices to determine whether there is an update for charger device42to retrieve. As yet another example, the one or more server computing devices may continuously stream user-specific configuration data (updated or not) to charger device42. As still another example, charger device42may periodically retrieve any user-specific configuration data (updated or not) stored on the one or more server computing devices.

The user-specific configuration data may include parameters, settings, and/or other forms of data that vary from user to user. Examples of the user-specific configuration data include one or more of the following: information indicative of insulin-on-board, a safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, an insulin sensitivity factor, and a history of insulin delivery.

Charger device42may cause configuration of a second medical device (e.g., replacement device40B) based on communicating the user-specific configuration data to the second medical device while the second medical device is being charged by charger device42(122). The second medical device may be a replacement device for the first medical device.

In some examples, the example process ofFIG.11may comprise tasks to help ensure that the second medical device has the most up-to-date user-specific configuration data when the second medical device is being placed into service. For example, charger device42may determine that the second medical device is being placed into service (e.g., by detecting removal of the second medical device from charger device42, by obtaining data indicative of the first medical device being removed from service, or by any other technique disclosed herein). After determining that the second medical device is being placed into service, charger device42may obtain, from the one or more server computing devices, an update to the user-specific configuration data stored on the first medical device. Charger device42may cause configuration of the second medical device based on communicating the update to the second medical device.

In some examples, charger device42may be configured to charge the second medical device based on electromagnetic induction. In some other examples, charger device42may be configured to charge the second medical device based on an electrical connection.

In some examples, the first medical device and the second medical device may share a number of similarities. For example, they may serve the same purpose (e.g., physiological characteristic monitoring and/or therapeutic substance delivery), have the same model number (e.g., 670G), etc. In some examples, the first and second medical devices may each be an insulin delivery device (e.g., insulin pump14or30) or may each be a portion of an insulin delivery device (e.g., durable portion32of insulin pump30). In some other examples, the first and second medical device may each be a glucose level monitor (e.g., monitoring device20).

The following describes some example techniques that may be utilized separately or together in any combination.

Example 1. A method for automatically configuring a medical device with user-specific configuration data, the method comprising determining, by a first medical device, that the first medical device is being placed into service to provide medical therapy to a patient, wherein the first medical device is a replacement medical device for a second medical device that was previously placed into service to provide medical therapy to the patient in accordance with user-specific configuration data stored on the second medical device, communicating, by the first medical device, data indicative of the first medical device being placed into service, after communicating the data indicative of the first medical device being placed into service, obtaining, by the first medical device, the user-specific configuration data stored on the second medical device, and configuring, by the first medical device, the first medical device to provide therapy in accordance with the obtained user-specific configuration data.

Example 2. The method of example 1, further comprising: prior to obtaining the user-specific configuration data, establishing a communication link through which the first medical device obtains the user-specific configuration data.

Example 3. The method of any of examples 1 and 2, wherein the user-specific configuration data comprises at least one of a group including information indicative of insulin-on-board, a safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, an insulin sensitivity factor, and a history of insulin delivery.

Example 4. The method of any of examples 1-3, wherein the first medical device comprises a first portion and a second portion, and wherein determining that the first medical device is being placed into service comprises determining that the first portion is removably attached to the second portion.

Example 5. The method of any of examples 1-4, wherein determining that the first medical device is being placed into service comprises determining activation of a cannula insertion mechanism associated with the first medical device.

Example 6. The method of any of examples 1-5, wherein determining that the first medical device is being placed into service comprises processing a signal from a skin contact sensor associated with the first medical device.

Example 7. The method of any of examples 1-6, wherein determining that the first medical device is being placed into service comprises determining actuation of a mechanical switch between the first medical device and the patient.

Example 8. The method of any of examples 1-7, wherein determining that the first medical device is being placed into service comprises determining that a glucose sensor is in contact with interstitial fluid.

Example 9. The method of any of examples 1-8, wherein obtaining the user-specific configuration data comprises obtaining the user-specific configuration data through an intermediate device that obtains the user-specific configuration data from the second medical device.

Example 10. The method of any of examples 1-9, wherein the data indicative of the first medical device being placed into service comprises a request for the user-specific configuration data.

Example 11. A system for automatically configuring a medical device with user-specific configuration data, the system comprising one or more processors, and one or more processor-readable storage media storing instructions which, when executed by the one or more processors, cause performance of determining that a first medical device is being placed into service to provide medical therapy to a patient, wherein the first medical device is a replacement medical device for a second medical device that was previously placed into service to provide medical therapy to the patient in accordance with user-specific configuration data stored on the second medical device, communicating data indicative of the first medical device being placed into service, after communicating the data indicative of the first medical device being placed into service, obtaining the user-specific configuration data stored on the second medical device, and configuring the first medical device to provide therapy in accordance with the obtained user-specific configuration data.

Example 12. The system of example 11, wherein the user-specific configuration data comprises at least one of a group including information indicative of insulin-on-board, a safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, an insulin sensitivity factor, and a history of insulin delivery.

Example 13. The system of any of examples 11 and 12, wherein the first medical device comprises a first portion and a second portion, and wherein determining that the first medical device is being placed into service comprises determining that the first portion is removably attached to the second portion.

Example 14. The system of any of examples 11-13, wherein determining that the first medical device is being placed into service comprises determining activation of a cannula insertion mechanism associated with the first medical device.

Example 15. The system of any of examples 11-14, wherein determining that the first medical device is being placed into service comprises processing a signal from a skin contact sensor associated with the first medical device.

Example 16. The system of any of examples 11-15, wherein determining that the first medical device is being placed into service comprises determining actuation of a mechanical switch between the first medical device and the patient.

Example 17. The system of any of examples 11-16, wherein determining that the first medical device is being placed into service comprises determining that a glucose sensor is in contact with interstitial fluid.

Example 18. The system of any of examples 11-17, wherein obtaining the user-specific configuration data comprises obtaining the user-specific configuration data through an intermediate device that obtains the user-specific configuration data from the second medical device.

Example 19. The system of any of examples 11-18, wherein the data indicative of the first medical device being placed into service comprises a request for the user-specific configuration data.

Example 20. One or more non-transitory processor-readable storage media storing instructions which, when executed by one or more processors, cause performance of determining that a first medical device is being placed into service to provide medical therapy to a patient, wherein the first medical device is a replacement medical device for a second medical device that was previously placed into service to provide medical therapy to the patient in accordance with user-specific configuration data stored on the second medical device, communicating data indicative of the first medical device being placed into service, after communicating the data indicative of the first medical device being placed into service, obtaining the user-specific configuration data stored on the second medical device, and configuring the first medical device to provide therapy in accordance with the obtained user-specific configuration data.

Example 21. A method for automatically configuring a medical device with user-specific configuration data, the method comprising determining, by a first medical device, that the first medical device is being removed from service, wherein the first medical device was previously placed into service to provide therapy to a patient in accordance with user-specific configuration data stored on the first medical device, and wherein the first medical device is to be replaced with a second medical device that is a replacement medical device for the first medical device, and causing, by the first medical device in response to determining that the first medical device is being removed from service, configuration of the second medical device to provide therapy to the patient in accordance with the user-specific configuration data, wherein causing configuration of the second medical device comprises communicating the user-specific configuration data toward the second medical device.

Example 22. The method of example 21, further comprising prior to communicating the user-specific configuration data toward the second medical device, establishing a communication link through which the first medical device communicates the user-specific configuration.

Example 23. The method of any of examples 21 and 22, wherein the user-specific configuration data comprises at least one of a group including information indicative of insulin-on-board, a safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, an insulin sensitivity factor, and a history of insulin delivery.

Example 24. The method of any of examples 21-23, wherein the first medical device comprises a first portion and a second portion, and wherein determining that the first medical device is being removed from service comprises determining that the first portion is separated from the second portion.

Example 25. The method of any of examples 21-24, wherein determining that the first medical device is being removed from service comprises determining removal of a cannula associated with the first medical device.

Example 26. The method of any of examples 21-25, wherein determining that the first medical device is being removed from service comprises processing a signal from a skin contact sensor associated with the first medical device.

Example 27. The method of any of examples 21-26, wherein determining that the first medical device is being removed from service comprises detecting a reset of a mechanical switch between the first medical device and the patient.

Example 28. The method of any of examples 21-27, wherein determining that the first medical device is being removed from service comprises determining that a glucose sensor is no longer in contact with interstitial fluid.

Example 29. The method of any of examples 21-28, wherein determining that the first medical device is being removed from service comprises receiving user input.

Example 30. The method of any of examples 21-29, wherein communicating the user-specific configuration data toward the second medical device comprises communicating the user-specific configuration data to an intermediate device.

Example 31. A system for automatically configuring a medical device with user-specific configuration data, the system comprising one or more processors, and one or more processor-readable storage media storing instructions which, when executed by the one or more processors, cause performance of determining that a first medical device is being removed from service, wherein the first medical device was previously placed into service to provide therapy to a patient in accordance with user-specific configuration data stored on the first medical device, and wherein the first medical device is to be replaced with a second medical device that is a replacement medical device for the first medical device, and in response to determining that the first medical device is being removed from service, causing configuration of the second medical device to provide therapy to the patient in accordance with the user-specific configuration data, wherein causing configuration of the second medical device comprises communicating the user-specific configuration data toward the second medical device.

Example 32. The system of example 31, wherein the user-specific configuration data comprises at least one of a group including information indicative of insulin-on-board, a safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, an insulin sensitivity factor, and a history of insulin delivery.

Example 33. The system of any of examples 31 and 32, wherein the first medical device comprises a first portion and a second portion, and wherein determining that the first medical device is being removed from service comprises determining that the first portion is separated from the second portion.

Example 34. The system of any of examples 31-33, wherein determining that the first medical device is being removed from service comprises determining removal of a cannula associated with the first medical device.

Example 35. The system of any of examples 31-34, wherein determining that the first medical device is being removed from service comprises processing a signal from a skin contact sensor associated with the first medical device.

Example 36. The system of any of examples 31-35, wherein determining that the first medical device is being removed from service comprises detecting a reset of a mechanical switch between the first medical device and the patient.

Example 37. The system of any of examples 31-36, wherein determining that the first medical device is being removed from service comprises determining that a glucose sensor is no longer in contact with interstitial fluid.

Example 38. The system of any of examples 31-37, wherein determining that the first medical device is being removed from service comprises receiving user input.

Example 39. The system of any of examples 31-38, wherein communicating the user-specific configuration data toward the second medical device comprises communicating the user-specific configuration data to an intermediate device.

Example 40. One or more non-transitory processor-readable storage media storing instructions which, when executed by one or more processors, cause performance of determining that a first medical device is being removed from service, wherein the first medical device was previously placed into service to provide therapy to a patient in accordance with user-specific configuration data stored on the first medical device, and wherein the first medical device is to be replaced with a second medical device that is a replacement medical device for the first medical device, and in response to determining that the first medical device is being removed from service, causing configuration of the second medical device to provide therapy to the patient in accordance with the user-specific configuration data, wherein causing configuration of the second medical device comprises communicating the user-specific configuration data toward the second medical device.

Example 41. A method for automatically configuring a medical device with user-specific configuration data, the method comprising obtaining, by a charger device from one or more server computing devices, user-specific configuration data stored on a first medical device that is configured to provide therapy to a patient in accordance with the user-specific configuration data, and causing, by the charger device, configuration of a second medical device based on communicating the user-specific configuration data to the second medical device while the second medical device is being charged by the charger device, wherein the second medical device is a replacement device for the first medical device.

Example 42. The method of example 41, further comprising determining, by the charger device, that the second medical device is being placed into service, after determining that the second medical device is being placed into service, obtaining, by the charger device from the one or more server computing devices, an update to the user-specific configuration data stored on the first medical device, and causing, by the charger device, configuration of the second medical device based on communicating the update to the second medical device.

Example 43. The method of example 42, wherein determining that the second medical device is being placed into service comprises detecting removal of the second medical device from the charger device.

Example 44. The method of any of examples 42 and 43, wherein determining that the second medical device is being placed into service comprises obtaining data indicative of the first medical device being removed from service.

Example 45. The method of any of examples 41-44, wherein the charger device is configured to charge the second medical device based on electromagnetic induction.

Example 46. The method of any of examples 41-45, wherein the user-specific configuration data comprises at least one of a group including information indicative of insulin-on-board, a safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, an insulin sensitivity factor, and a history of insulin delivery.

Example 47. The method of any of examples 41-46, wherein each of the first medical device and the second medical device includes an insulin pump.

Example 48. A system for automatically configuring a medical device with user-specific configuration data, the system comprising one or more processors, and one or more processor-readable storage media storing instructions which, when executed by the one or more processors, cause performance of obtaining, from one or more server computing devices, user-specific configuration data stored on a first medical device that is configured to provide therapy to a patient in accordance with the user-specific configuration data, and causing configuration of a second medical device based on communicating the user-specific configuration data to the second medical device while the second medical device is being charged by the charger device, wherein the second medical device is a replacement device for the first medical device.

Example 49. The system of example 48, wherein the instructions comprise instructions which, when executed by the one or more processors, cause performance of determining that the second medical device is being placed into service, after determining that the second medical device is being placed into service, obtaining, from the one or more server computing devices, an update to the user-specific configuration data stored on the first medical device, and causing configuration of the second medical device based on communicating the update to the second medical device.

Example 50. The system of example 49, wherein determining that the second medical device is being placed into service comprises detecting removal of the second medical device from the charger device.

Example 51. The system of any of examples 49 and 50, wherein determining that the second medical device is being placed into service comprises obtaining data indicative of the first medical device being removed from service.

Example 52. The system of any of examples 48-51, wherein the charger device is configured to charge the second medical device based on electromagnetic induction.

Example 53. The system of any of examples 48-52, wherein the user-specific configuration data comprises at least one of a group including information indicative of insulin-on-board, a safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, an insulin sensitivity factor, and a history of insulin delivery.

Example 54. The system of any of examples 48-53, wherein each of the first medical device and the second medical device includes an insulin pump.

Example 55. One or more non-transitory processor-readable storage media storing instructions which, when executed by one or more processors, cause performance of obtaining, from one or more server computing devices, user-specific configuration data stored on a first medical device that is configured to provide therapy to a patient in accordance with the user-specific configuration data, and causing configuration of a second medical device based on communicating the user-specific configuration data to the second medical device while the second medical device is being charged by the charger device, wherein the second medical device is a replacement device for the first medical device.

Example 56. The one or more non-transitory processor-readable storage media of example 55, wherein the instructions comprise instructions which, when executed by the one or more processors, cause performance of determining that the second medical device is being placed into service, after determining that the second medical device is being placed into service, obtaining, from the one or more server computing devices, an update to the user-specific configuration data stored on the first medical device, and causing configuration of the second medical device based on communicating the update to the second medical device.

Example 57. The one or more non-transitory processor-readable storage media of example 56, wherein determining that the second medical device is being placed into service comprises detecting removal of the second medical device from the charger device.

Example 58. The one or more non-transitory processor-readable storage media of any of examples 56 and 57, wherein determining that the second medical device is being placed into service comprises obtaining data indicative of the first medical device being removed from service.

Example 59. The one or more non-transitory processor-readable storage media of any of examples 55-58, wherein the charger device is configured to charge the second medical device based on electromagnetic induction.

Example 60. The one or more non-transitory processor-readable storage media of any of examples 55-59, wherein the user-specific configuration data comprises at least one of a group including information indicative of insulin-on-board, a safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, an insulin sensitivity factor, and a history of insulin delivery.

In one or more examples, the functions described in this disclosure may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media forming a tangible, non-transitory medium. Instructions may be executed by one or more processors, such as one or more DSPs, ASICs, FPGAs, general purpose microprocessors, or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor,” as used herein may refer to one or more of any of the foregoing structure or any other structure suitable for implementation of the techniques described herein.

In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and/or software modules. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components, or integrated within common or separate hardware or software components. Also, the techniques could be fully implemented in one or more circuits or logic elements. The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including one or more processors28of cloud26, one or more processors of patient device24, one or more processors of insulin pump14, or some combination thereof. The one or more processors may be one or more integrated circuits (ICs), and/or discrete electrical circuitry, residing in various locations in the example systems described in this disclosure.

The one or more processors or processing circuitry utilized for example techniques described in this disclosure may be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Fixed-function circuits refer to circuits that provide particular functionality, and are preset on the operations that can be performed. Programmable circuits refer to circuits that can be programmed to perform various tasks, and provide flexible functionality in the operations that can be performed. For instance, programmable circuits may execute software or firmware that cause the programmable circuits to operate in the manner defined by instructions of the software or firmware. Fixed-function circuits may execute software instructions (e.g., to receive parameters or output parameters), but the types of operations that the fixed-function circuits perform are generally immutable. In some examples, the one or more of the units may be distinct circuit blocks (fixed-function or programmable), and in some examples, the one or more units may be integrated circuits. The processors or processing circuitry may include arithmetic logic units (ALUs), elementary function units (EFUs), digital circuits, analog circuits, and/or programmable cores, formed from programmable circuits. In examples where the operations of the processors or processing circuitry are performed using software executed by the programmable circuits, memory accessible by the processors or processing circuitry may store the object code of the software that the processors or processing circuitry receive and execute.