Automatic network configuration based on biometric authentication
The automatic configuration of network connections through biometric certification solves the problem of cumbersome manual configuration when changing medical devices, and realizes automatic data transmission and the effectiveness of treatment when changing devices.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- MEDTRONIC MINIMED INC
- Filing Date
- 2021-06-15
- Publication Date
- 2026-07-31
AI Technical Summary
Manually configuring network connections when replacing medical devices is cumbersome and error-prone, resulting in a lack of up-to-date user-specific configuration data and affecting the effectiveness of treatment.
The network connection is automatically configured through biometric authentication. By comparing the biometric data generated by the in-use and replacement devices, a communication link is automatically established after confirming that the device is associated with the same patient, so as to realize the transmission of configuration data.
The network configuration process for replacement devices has been simplified, ensuring that the replacement devices have the latest user-specific configuration data, thereby improving the effectiveness and reliability of the therapy.
Smart Images

Figure HDA0004007856120000011 
Figure HDA0004007856120000021 
Figure HDA0004007856120000031
Abstract
Description
[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 044,993, filed June 26, 2020, the entire contents of which are incorporated herein by reference.
[0002] This application discloses subject matter relating to U.S. Patent Application No. 17 / 212,956, filed March 25, 2021; U.S. Patent Application No. 17 / 212,982, filed March 25, 2021; and U.S. Patent Application No. 17 / 213,003, filed March 25, 2021, the full text of each of which is incorporated herein by reference. Technical Field
[0003] This disclosure relates to automatic network configuration, and more particularly, to automatic network configuration based on biometric authentication. Background Technology
[0004] While many devices are in service, they update the information they store about their users. For example, in the field of medical devices, treatments are often tailored to the specific needs of each patient. Therefore, when a device ceases service, the replacement device may not be configured with the updated information.
[0005] To address this issue, the replacement device can be manually configured with updated information. However, the tedious task of manually configuring the replacement device can lead to user frustration and incorrect configuration. Summary of the Invention
[0006] Apparatus, systems, and techniques for automatic network configuration are described. More specifically, apparatus, systems, and techniques for automatic network configuration based on biometric authentication are disclosed herein.
[0007] In one example, this disclosure describes a method for automated network configuration based on biometric authentication, the method comprising: obtaining first biometric data derived by one or more processors from one or more sensor signals generated by one or more sensors of a first device coupled to a user; obtaining second biometric data derived by the one or more processors from one or more sensor signals generated by one or more sensors of a second device; comparing the first biometric data and the second biometric data by the one or more processors; determining, based on the comparison, that the second device is coupled to the user; and establishing a communication link with the second device by the one or more processors based on the determination that the second device is coupled to the user.
[0008] In another example, this disclosure describes a system for automated network configuration based on biometric authentication, the system comprising: one or more processors; and one or more processor-readable storage media storing instructions that, when executed by the one or more processors, cause to: obtain first biometric data derived from one or more sensor signals generated by one or more sensors of a first device coupled to a user; obtain second biometric data derived from one or more sensor signals generated by one or more sensors of a second device; compare the first biometric data and the second biometric data; determine, based on the comparison, that the second device is coupled to the user; and establish a communication link with the second device based on the determination that the second device is coupled to the user.
[0009] In yet another example, this disclosure describes one or more non-transitory processor-readable storage media storing instructions that, when executed by one or more processors, cause to: obtain first biometric data derived from one or more sensor signals generated by one or more sensors of a first device coupled to a user; obtain second biometric data derived from one or more sensor signals generated by one or more sensors of a second device; compare the first biometric data and the second biometric data; determine, based on the comparison, that the second device is coupled to the user; and establish a communication link with the second device based on the determination that the second device is coupled to the user.
[0010] Details of one or more aspects of this disclosure are set forth in the following drawings and description. Other features, objects, and advantages of this disclosure will become apparent from the description, drawings, and claims. Attached Figure Description
[0011] Figure 1 This is a block diagram illustrating an exemplary glucose level management system including a tethered pump according to one or more examples described in this disclosure.
[0012] Figure 2 This is a block diagram illustrating an exemplary glucose level management system including a patch pump according to one or more examples described in this disclosure.
[0013] Figure 3A and Figure 3B These are different perspective views of a semi-disposable patch pump configured to provide therapy, based on one or more examples described in this disclosure.
[0014] Figure 4 This is a block diagram illustrating an exemplary communication system for transmitting user-specific configuration data via an intermediate device, according to one or more examples described in this disclosure.
[0015] Figure 5 This is a block diagram illustrating an exemplary medical device according to one or more examples described in this disclosure.
[0016] Figure 6 This is a block diagram illustrating an example of a patient device according to one or more examples described in this disclosure.
[0017] Figure 7 This is a flowchart illustrating an exemplary process for automated network configuration based on biometric authentication according to one or more examples described in this disclosure. Detailed Implementation
[0018] This disclosure describes apparatus, systems, and techniques for network configuration. Although medical devices are used as examples to illustrate the subject matter of this disclosure, it should be understood that the subject matter is not limited to medical devices and is equally applicable to any other device, including wearable devices and other consumer electronics devices. Furthermore, it should be understood that the techniques disclosed herein can be practiced with one or more types of insulin (e.g., rapid-acting insulin, intermediate-acting insulin, and / or slow-acting insulin). Therefore, terms such as “basal insulin” and “bulk insulin” do not necessarily indicate different types of insulin. For example, rapid-acting insulin can be used for both basal and bulk doses.
[0019] In some examples, a user (e.g., a patient) may use a medical device (e.g., a patch pump and / or glucose monitoring device) for glucose level management, and the medical device may be configured with user-specific configuration data (e.g., different configuration data for different users). Examples of user-specific configuration data include, but are not limited to, information indicating any of the following: active insulin (insulin-on-board), insulin type, safe basal rate, one or more insulin delivery rate limits, one or more glucose sensor calibration factors, and insulin sensitivity factors. User-specific configuration data may be stored in volatile and / or non-volatile memory. Additionally, user-specific configuration data may be updated as the medical device is used.
[0020] In some examples, a user may own multiple medical devices of the same type (e.g., with the same manufacturer and model but different serial numbers). Therefore, when the in-use medical device approaches inoperability (e.g., due to low battery, blocked cannulas, and / or an empty insulin reservoir), the user can periodically replace (e.g., replace, cycle, or swap out) the "in-use" medical device with a replacement medical device of the same type. The term "in-use" should not be considered limited to the currently used device. For example, in some contexts, the term "in-use" may refer to a device that has been in use until a replacement device is put into service.
[0021] When a user switches from an existing medical device to a replacement medical device, the replacement device may not have the latest user-specific configuration data. Therefore, when the replacement medical device is put into service, the user typically configures it with the latest user-specific configuration data. This usually involves manually configuring the network connection between the medical devices to facilitate the transfer of configuration data.
[0022] However, relying on users to establish communication links for updating user-specific configuration data can be cumbersome and error-prone. Therefore, it may be necessary to not establish such links, and replacing medical devices without up-to-date configuration data may not provide adequate treatment.
[0023] To avoid the aforementioned drawbacks, this disclosure describes exemplary techniques related to automated network configuration. This can be achieved based on biometric authentication. For example, when being put into service, a replacement medical device (e.g., an insulin delivery device or a continuous glucose monitoring device) can generate biometric data. Examples of biometric data include motion data (e.g., from inertial measurement sensors such as accelerometers or gyroscopes), glucose level readings (e.g., from a glucose sensor), skin temperature data (e.g., from a skin temperature sensor), and / or other measurement data obtained from one or more sensors. The replacement medical device can (e.g., based on short-range wireless transmissions that can be received by any nearby device) announce the biometric data, which can be compared with biometric data generated by the in-use medical device to determine whether the in-use medical device and the replacement medical device are associated with the same patient (e.g., attached to the same patient or otherwise worn by the same patient). If so, a wireless network connection can be automatically established, for example, to transmit patient-specific configuration data from the in-use medical device to the replacement medical device.
[0024] Figure 1 This is a block diagram illustrating an exemplary glucose level management system including a tethered pump according to one or more examples described in this disclosure. Figure 1 System 10A is illustrated, comprising an insulin pump 14, tubing 16, infusion unit 18, monitoring device 20 (e.g., a glucose level monitoring device including a glucose sensor), patient device 24, and cloud 26. The insulin pump 14 can be described as a tethered pump because tubing 16 tethers the insulin pump 14 to the infusion unit 18. Cloud 26 represents a local wide area or global computing network comprising one or more servers 28A to 28N (“one or more servers 28”). Each of the one or more servers 28 may include one or more processors and memory. In some examples, the various components may determine changes in therapy based on the determination of glucose levels on monitoring device 20, and therefore system 10A may be referred to as a glucose level management system 10A.
[0025] Patient 12 may have diabetes (e.g., type 1 or type 2 diabetes), and therefore, glucose levels in Patient 12 can be controlled by delivering supplemental insulin. For example, Patient 12 may not be able to produce enough insulin to control glucose levels, or the amount of insulin produced by Patient 12 may be insufficient due to insulin resistance that Patient 12 may have developed.
[0026] To receive supplemental insulin, patient 12 may carry an insulin pump 14 coupled to a tubing 16 for delivering insulin to patient 12. An infusion set 18 may be attached to the skin of patient 12 and includes a cannula for delivering insulin to patient 12. A monitoring device 20 may also be coupled to patient 12 to measure patient 12's glucose levels. The insulin pump 14, tubing 16, infusion set 18, and monitoring device 20 together form an insulin pump system. An example of an insulin pump system is the MINIMED from Medtronic Minimed, Inc. TM 670G insulin pump system. However, other examples of insulin pump systems may be used, and the exemplary technology should not be considered limited to MINIMED. TM 670G insulin pump system. For example, the techniques described in this disclosure can be used in insulin pump systems including 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, are also possible. In another example, the insulin pump 14, tubing 16, infusion set 18, and / or monitoring device 20 may be contained in the same housing.
[0027] As described in more detail below, in some examples, patient 12 may utilize a patch pump, such as Figure 2 The insulin pump 30 shown is not a tethered pump system comprising an insulin pump 14, tubing 16, infusion setter 18, and / or monitoring device 20. The insulin pump 30 can be described as a patch pump because it can be removably attached to the patient 12 using a small piece of adhesive material worn on the skin. Instead of delivering insulin via tubing and infusion setter, the insulin pump 30 delivers insulin via a cannula extending directly from the insulin pump 30. In some examples, a glucose sensor may also be integrated into the insulin pump 30. In such examples, the insulin pump 30 may be referred to as an autosomal (AIO) insulin pump.
[0028] Return to reference Figure 1The insulin pump 14 can be a small device that the patient 12 can place in different locations. For example, the patient 12 can clip the insulin pump 14 to the waistband of the pants the patient 12 is wearing. In some examples, as a precaution, the patient 12 can place the insulin pump 14 in a pocket. Typically, the insulin pump 14 can be worn in different places, and the patient 12 can place the insulin pump 14 in a certain location based on the specific clothing the patient 12 is wearing.
[0029] For insulin delivery, the insulin pump 14 may include one or more reservoirs (e.g., two reservoirs). In some examples, the reservoir may be included in a plastic cylinder holding up to N units of insulin (e.g., up to 300 units of insulin) and may be securely held within the insulin pump 14. In some examples, the reservoir may be integrated into the insulin pump 14 such that it can be filled using a syringe. The insulin pump 14 may be a battery-powered device powered by replaceable and / or rechargeable batteries.
[0030] The tubing 16 may be connected at a first end to a reservoir in the insulin pump 14 and at a second end to an infusion set 18. The tubing 16 carries insulin from the reservoir of the insulin pump 14 to the patient 12. The tubing 16 may be flexible, allowing it to loop or bend to minimize concerns about the tubing 16 becoming detached from the insulin pump 14 or the infusion set 18, or about the tubing 16 breaking.
[0031] The infusion set 18 may include a thin cannula that the patient 12 inserts into the subcutaneous fat layer (e.g., subcutaneous connection). The infusion set 18 may be placed near the patient 12's stomach. Insulin travels from the reservoir of the insulin pump 14 through tubing 16, through the cannula in the infusion set 18, and into the patient 12's body. In some examples, the patient 12 may use an infusion set insertion device. The patient 12 may place the infusion set 18 into the infusion set insertion device, and upon pressing a button on the infusion set insertion device, the infusion set insertion device may insert the cannula of the infusion set 18 into the patient 12's fat layer, and with the cannula inserted into the patient 12's fat layer, the infusion set 18 may be placed on top of the patient's skin.
[0032] The monitoring device 20 may include a sensor inserted under the skin of the patient 12, such as near the stomach of the patient 12, or in the arm of the patient 12 (e.g., subcutaneous connection). The sensor of the monitoring device 20 may be configured to measure interstitial glucose levels, which are glucose present in the fluid between the cells of the patient 12. The monitoring device 20 may be configured to continuously or periodically sample glucose levels and the rate of change of glucose levels over time.
[0033] In one or more examples, insulin pump 14 and monitoring device 20 and / or Figure 1The various components described herein can together form a closed-loop therapy delivery system. For example, patient 12 can set a target glucose level on insulin pump 14, typically measured in milligrams per deciliter. Insulin pump 14 can receive the current glucose level from monitoring device 20 and, in response, can increase or decrease the amount of insulin delivered to patient 12. For example, if the current glucose level is higher than the target glucose level, insulin pump 14 can increase insulin. If the current glucose level is lower than the target glucose level, insulin pump 14 can temporarily stop insulin delivery. Insulin pump 14 can be considered an example of an automated insulin delivery (AID) device. Other examples of AID devices are also possible, and the technology described in this disclosure can be applied to other AID devices. As described in more detail below, insulin pump 14 can be configured to operate according to user-specific configuration data to deliver insulin to patient 12.
[0034] Insulin pump 14 and monitoring device 20 may be configured to operate together to mimic some of the ways in which a healthy pancreas functions. Insulin pump 14 may be configured to deliver a basal dose, which is a small amount of insulin released throughout the day. There may be times when glucose levels rise, such as due to eating by patient 12 or some other activity. Insulin pump 14 may be configured to deliver a bolus dose as needed in association with food intake or to correct for undesirable high glucose levels in the bloodstream. In one or more examples, if glucose levels rise above a target level, insulin pump 14 may deliver a bolus dose to address the rise in glucose levels. Insulin pump 14 may be configured to calculate the basal dose / bolus dose and deliver the basal dose / bolus dose accordingly. For example, insulin pump 14 may determine the amount of basal dose to be delivered and then, in response to a rise in glucose levels due to eating or some other event, determine the amount of bolus dose to be delivered to lower the glucose levels.
[0035] Therefore, in some examples, monitoring device 20 may sample glucose levels to determine the rate of change of glucose levels over time. Monitoring device 20 may output glucose levels to insulin pump 14 (e.g., via a wireless link such as Bluetooth or BLE connection). Insulin pump 14 may compare glucose levels to target glucose levels (e.g., as set by patient 12 or clinician) and adjust insulin doses based on the comparison. In some examples, insulin pump 14 may adjust insulin delivery based on predicted glucose levels (e.g., where glucose levels are expected to be what they will be over the next 30 minutes).
[0036] As described above, the patient 12 or clinician can set one or more target glucose levels on the insulin pump 14. Various methods may exist in which the patient 12 or clinician can set target glucose levels on the insulin pump 14. For example, the patient 12 or clinician can communicate with the insulin pump 14 using a patient device 24. Examples of patient devices 24 include mobile devices such as smartphones, tablets, laptops, etc. In some examples, the patient device 24 may be a special programmer or controller for the insulin pump 14 (e.g., a dedicated remote control device). Although... Figure 1 A patient device 24 is shown, but in some examples, multiple patient devices may be present. For example, system 10A may include a mobile device and a dedicated wireless controller, each of which is an example of patient device 24. For ease of description only, the exemplary technology is described with respect to patient device 24, and it should be understood that patient device 24 may be one or more patient devices.
[0037] The patient device 24 may also be configured to interface with the monitoring device 20. For example, the patient device 24 may receive information from the monitoring device 20 via the insulin pump 14, wherein the insulin pump 14 relays information between the patient device 24 and the monitoring device 20. As another example, the patient device 24 may receive information (e.g., glucose levels or rates of change in glucose levels) directly from the monitoring device 20 (e.g., via a wireless link).
[0038] In one or more examples, patient device 24 may include a user interface that patient 12 or clinician can use to control insulin pump 14. For example, patient device 24 may include a touchscreen that allows patient 12 or clinician to input a target glucose level and output current and / or past glucose levels. In some examples, patient device 24 may output notifications to patient 12, such as notifications of excessively high or low glucose levels, and notifications regarding any actions patient 12 needs to take. For example, if the battery of insulin pump 14 is low, insulin pump 14 may output a low battery indication to patient device 24, and patient device 24 may then output a notification to patient 12 to replace the battery or recharge the battery.
[0039] Controlling the insulin pump 14 via a touchscreen display of the patient device 24 is provided as an example only and should not be considered limiting. For example, the insulin pump 14 may include buttons that allow the patient 12 or a clinician to set various glucose levels. In some examples, the insulin pump 14, either alone or as a supplement to the patient device 24, may be configured to output notifications to the patient 12. For example, if glucose levels are too high or too low, the insulin pump 14 may output an audible or tactile output. In some examples, if the battery is low, the insulin pump 14 may output a low battery indication on its display.
[0040] exist Figure 1 In some examples, the insulin pump 14 and / or monitoring device 20 may each correspond to an in-use device or a replacement device. In some examples, the replacement device may be similar to the in-use device, including being identical to the in-use device (e.g., having the same construction and model with the same capabilities). However, in some other examples, the replacement device may not be similar to the in-use device (e.g., having different capabilities).
[0041] As described above, user-specific configuration data can be updated during operation of the insulin pump 14 and / or monitoring device 20. Examples of user-specific configuration data include one or more insulin delivery rate limits (e.g., maximum basal rate and / or maximum bolus rate), active insulin (e.g., unmetabolized insulin from one or more previous bolus doses), insulin delivery history, one or more glucose sensor calibration factors (e.g., previous and / or current sensor sensitivity ratios used to convert sensor signal values into blood glucose levels), safe basal rate (e.g., a relatively low basal rate that is fixed because it is not adjusted based on current sensor values), and insulin sensitivity factors (e.g., a ratio describing the effect of one unit of insulin on glucose levels). It should be understood that the above are non-limiting examples of user-specific configuration data stored on the insulin pump 14, and the specific configuration data used may vary between specific implementations.
[0042] When replacing (e.g., swapping out) an existing device, the replacement device may not have updated user-specific configuration data. However, solutions to this problem typically rely on some degree of human intervention, such as manually configuring a network connection to facilitate the transmission of configuration data to the replacement device. To eliminate or reduce human intervention, this document discloses exemplary techniques for automatically configuring a network connection to provide the replacement device with updated user-specific configuration data. More specifically, the network connection can be automatically configured upon successful biometric authentication.
[0043] Biometric authentication can be performed in a variety of ways. For example, biometric authentication may involve the notification of biometric data by an in-use device, a replacement device, and / or an intermediate device (e.g., patient device 24). The biometric data may be generated at substantially the same time (e.g., when the user is wearing both the in-use device and the replacement device) or at different times (e.g., the in-use device may generate biometric data before the replacement device is put into service, and the replacement device may generate biometric data while it is being put into service). At least one of the devices may compare the biometric data to confirm that the in-use device and the replacement device are associated with the same patient (e.g., worn by the same patient).
[0044] For example, insulin pump 14 may be an in-use device including an accelerometer that generates first biometric data related to the gait of patient 12. Even after insulin pump 14 is removed from patient 12, insulin pump 14 may store the first biometric data in non-volatile memory for use. Replacing insulin pump may include an accelerometer that generates second biometric data related to the gait of patient 12. When it is determined that it is in service, replacement insulin pump may notify nearby devices (including insulin pump 14) of all or part of the second biometric data. Insulin pump 14 may perform a comparison between the notified biometric data and at least a portion of the first biometric data. When matching biometric data is determined (e.g., based on determining that the compared biometric data are substantially the same), a network connection may be established (e.g., insulin pump 14 may automatically initiate the establishment of a network connection with replacement insulin pump). Examples of network connections include radio frequency (RF) communication links, Bluetooth Low Energy (BLE) communication links, near field communication (NFC) links, and optical communication links.
[0045] In some implementations, when it is determined that insulin pump 14 is being taken out of service, insulin pump 14 may also notify nearby devices of all or part of the first biometric data. Therefore, replacing the insulin pump can perform a comparison between the biometric data notified by insulin pump 14 and at least a portion of the second biometric data. Based on this comparison, the replacement insulin pump can confirm (e.g., when the compared biometric data are substantially the same) or reject (e.g., when the compared biometric data are significantly different) the establishment of a network connection with insulin pump 14. For added security, the biometric data notified by insulin pump 14 may differ from the biometric data notified by the replacement insulin pump.
[0046] In the foregoing example, a network connection is automatically established between the in-use device and the replacement device. Therefore, the in-use device can directly transmit configuration data to the replacement device via the network connection (e.g., via push or pull). However, the techniques disclosed herein are not limited to establishing a network connection between the in-use device and the replacement device. As will be described in more detail below, in some other examples, a network connection can be automatically established between the replacement device and an intermediate device, allowing the in-use device to indirectly transmit configuration data to the replacement device via the intermediate device.
[0047] like Figure 1 As shown, system 10A includes a cloud 26, which includes one or more servers 28. Cloud 26 may include multiple network devices (e.g., servers 28), and each network device may include one or more processors. Cloud 26 represents a cloud infrastructure supporting one or more servers 28 capable of executing one or more user-requested applications or operations. For example, one or more servers 28 may remotely store, manage, and / or process data that would otherwise be stored, managed, and / or processed locally by patient device 24. One or more processors of one or more servers 28 may share data or resources used to perform computations and may be part of a computing server, network server, database server, etc. One or more servers 28 may be located within a data center or distributed across multiple data centers. In some cases, data centers may be located in different geographical locations.
[0048] One or more processors of server 28, and other processing circuitry described herein, may include any one or more 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, and any combination of such components. The functionality attributable to one or more processors and other processing circuitry described herein may be embodied in hardware, firmware, software, or any combination thereof.
[0049] One or more processors of one or more servers 28 may be implemented as fixed-function circuits, programmable circuits, or combinations thereof. A fixed-function circuit is a circuit that provides a specific function and is pre-configured for executable operations. A programmable circuit is a circuit that can be programmed to perform various tasks and provide flexible functionality in executable operations. For example, a programmable circuit may execute software or firmware that causes the programmable circuit to operate in a manner defined by the instructions of the software or firmware. A fixed-function circuit may execute software instructions (e.g., receive or output parameters), but the type of operation performed by a fixed-function circuit is generally immutable. In some examples, one or more processors in the processor may include different circuit blocks (fixed-function or programmable), and in some examples, the one or more processors may include integrated circuits. One or more processors may include arithmetic logic units (ALUs), basic function units (EFUs), digital circuits, analog circuits, and / or programmable cores formed by programmable circuits. In examples where software executed by programmable circuits is used to perform operations of one or more servers 28, memory accessible to one or more servers 28 may store object code of the software received and executed by one or more processors of one or more servers 28.
[0050] Figure 2 This is a block diagram illustrating an exemplary glucose level management system including a patch pump according to one or more examples described in this disclosure. Figure 2 Similar to Figure 1 System 10A is equivalent to system 10B. However, in system 10B, patient 12 may not need insulin pump 14. Instead, patient 12 may use insulin pump 30 to deliver insulin.
[0051] Insulin pump 30 may differ from insulin pump 14 in that insulin pump 30 is an example of an on-the-skin pump. In other words, insulin pump 30 is designed to be removably attached to the skin of patient 12.
[0052] In one or more examples, insulin pump 30 may include a glucose sensor similar to the glucose sensor of monitoring device 20. Integrating the glucose sensor into insulin pump 30 may be advantageous due to the reduced footprint of the device on the body, more reliable communication between the glucose sensor and components of insulin pump 30 (e.g., a wired connection rather than a wireless connection between the glucose sensor and components of insulin pump 30), and the sharing of the same processing circuitry, such as that used for the pump and the glucose sensor, to name just a few examples. Insulin pump 30 may be referred to as an autosomal (AIO) insulin pump. In some other examples, the glucose sensor may be included in a separate device (e.g., monitoring device 20) from insulin pump 30, rather than being integrated into insulin pump 30.
[0053] For example, when the battery of insulin pump 30 is nearly depleted, when the insulin reservoir of insulin pump 30 is empty, or when the cannula of insulin pump 30 becomes blocked, patient 12 may replace insulin pump 30. In some examples, patient 12 may replace insulin pump 30 every few days (e.g., every 3 days).
[0054] In some examples, insulin pump 30 can be entirely disposable, as patient 12 replaces the entire insulin pump 30 with a new one. However, in some other examples, insulin pump 30 can be semi-disposable, as it comprises a durable / reusable portion and a consumable / disposable portion.
[0055] For example, Figure 3A and Figure 3B These are different perspective views of a semi-disposable patch pump configured to provide therapy, based on one or more examples described in this disclosure. Figure 3A The durable portion 32 and the consumable portion 34 of the insulin pump 30 are shown. In some examples, the durable portion 32 includes electronics (e.g., a rechargeable battery, processor, and memory), and the consumable portion 34 includes insulin contact components, such as an insulin reservoir. Figure 3B As shown, the consumable portion 34 may also include patient contact components, such as a cannula 36 and a glucose sensor 38. The glucose sensor 38 may be similar to the glucose sensor of the monitoring device 20.
[0056] There are various ways in which the durable part 32 and the consumable part 34 can be operatively coupled. For example, there may be electrical connections that facilitate communication between the processor in part 32 and various components in part 34, mechanical connections that enable the motor in part 32 to apply force to the gears in part 34, and / or electromagnetic connections that allow the motor stator in part 32 to cause movement of the motor rotor in part 34.
[0057] Regardless of whether the patch pump is fully disposable or semi-disposable, it can be replaced periodically. For example, a semi-disposable patch pump may include a battery in a durable part and a reservoir in a consumable part. When the reservoir is empty, the patch pump can be removed from the patient 12, and the durable part can be separated from the consumable part. After separation, the durable part can recharge its battery (e.g., by connecting the durable part to a charger device), and the consumable part can be simply discarded. Replacing the patch pump may be based on removably securing a replacement durable part (e.g., a second durable part that has recently been disconnected from the charger device) to a new consumable part. Thus, the patient 12 may have at least two durable parts: an in-use durable part attached to the patient 12 and a replacement durable part prepared for replacement of the in-use durable part.
[0058] However, the in-use device and the replacement device may have different data stored in memory. For example, the in-use durable part may have the latest configuration data, while the replacement durable part may have the default configuration data. To address this issue, this disclosure describes an exemplary method for automatically establishing a network connection for transmitting user-specific configuration data to the replacement device.
[0059] Some exemplary ways of automatically establishing a network connection involve a replacement device (e.g., a first medical device) configured to automatically determine whether it is in service (e.g., placed in physical contact with a user). The replacement device may be a replacement of an in-service device (e.g., a second medical device previously in service to provide medical treatment to patient 12 based on user-specific configuration data stored on a second medical device). Upon determining that it is in service (e.g., based on biometric data obtained from one or more sensor components), the replacement device may automatically notify nearby devices (e.g., including the in-service device and / or patient device 24) of biometric data (e.g., previously and / or currently obtained biometric data) and / or listen for biometric data notified by another device (e.g., the in-service device and / or patient device 24).
[0060] There are multiple ways to determine if a replacement device is in service. A non-exhaustive list of examples, not limited to the context of semi-disposable patch pumps, is provided below.
[0061] In some implementations, the replacement device may determine that it is being put into service based on processing electrical signals from skin contact sensors associated with the replacement device. For example, the durable part 32 may include a temperature sensor configured to detect the skin temperature indicating that the durable part 32 is to be deployed on the body of the patient 12.
[0062] In some implementations, the replacement device may determine that it is in service based on the determination that the glucose sensor associated with the replacement device is in contact with interstitial fluid. For example, upon contact with interstitial fluid, the glucose sensor may generate an electrical signal that is transmitted to a processor housed in the durable portion 32.
[0063] In some implementations, the replacement device may determine that it is being put into service based on accelerometer data placed on the user's body. For example, the durable part 32 may include an accelerometer configured to generate signals that can be processed to determine a movement and / or synthetic biometric profile consistent with walking (e.g., based on the user's gait).
[0064] For example, insulin pump 30 may be an in-use device including one or more sensors that generate first biometric data (e.g., an accelerometer that generates first motion data, a glucose sensor that generates first glucose measurement data, and / or a temperature sensor that generates first skin temperature data). A replacement insulin pump may be attached to patient 12 before removing insulin pump 30 from patient 12. The replacement insulin pump may include one or more sensors that generate second biometric data at approximately the same time as one or more sensors of insulin pump 30 generate the first biometric data (e.g., an accelerometer that generates second motion data, a glucose sensor that generates second glucose measurement data, and / or a temperature sensor that generates second skin temperature data). When it is determined (e.g., based on the generation of second biometric data) that it is in service, the replacement insulin pump may notify nearby devices (including insulin pump 30) of the second biometric data. When insulin pump 30 receives the second biometric data, it may compare the first and second biometric data. When it is determined (e.g., based on the determination that the first biometric data and the second biometric data are substantially the same in whole or in part) that both the first biometric data and the second biometric data correspond to patient 12, a network connection can be established (e.g., insulin pump 30 can automatically initiate the establishment of a network connection with the replacement insulin pump).
[0065] Some exemplary methods of automatically establishing network connectivity involve an in-use device (e.g., a second medical device) configured to automatically determine whether it is exiting service (e.g., it has been separated from the user's body or is otherwise approaching inoperability). The in-use device may have previously been put into service to provide medical treatment to patient 12 based on user-specific configuration data stored on the in-use device. When it is determined that it is exiting service (e.g., based on the failure to obtain further biometric data from one or more sensor components or processing signals indicating that the in-use device is approaching inoperability), the in-use device may automatically notify nearby devices (e.g., including replacement devices and / or patient device 24) of biometric data (e.g., previously and / or currently obtained biometric data) and / or listen to biometric data notified by the replacement device.
[0066] There are various ways in which an in-use device can determine that it is being taken out of service. For example, in the context of a semi-disposable patch pump, the durable part 32 can determine that it has separated from the consumable part 34 (e.g., based on signals from MR sensors, mechanical switches, optical sensors, and / or Hall sensors configured to detect the motor rotor in the consumable part 34 / the absence of such signals). Some other examples are provided below that are not limited to the context of semi-disposable patch pumps.
[0067] In some implementations, the device in use can determine that it is being decommissioned based on the removal of the cannula from the user's body. For example, cannula removal can result in a decrease in pump back pressure, which can be detected by a force sensor configured to measure the reaction force acting on the reservoir plunger.
[0068] In some implementations, the device in use may determine that it is leaving service based on the absence of signals from skin contact sensors associated with the device in use. For example, the durable part 32 may include a temperature sensor that can no longer detect skin temperature when it is no longer placed against the user's body.
[0069] In some implementations, the device in use may determine that it is exiting service based on the absence of signals from motion sensors associated with the device in use. For example, the durable part 32 may include an accelerometer that can no longer detect movement when it is no longer worn by the user.
[0070] In some implementations, the device in use may determine that it is being taken out of service based on the detection of a reset of a mechanical switch. For example, the durable part 32 may include a mechanical switch configured to automatically reset when it is no longer in physical contact with the user (e.g., separated).
[0071] In some implementations, the device in use can determine that it is being decommissioned based on the determination that the glucose sensor associated with the device is no longer in contact with the interstitial fluid. For example, when the glucose sensor is in contact with the interstitial fluid, it may periodically (e.g., every five minutes) generate an electrical signal, so the device in use can determine that the absence of the expected signal indicates decommissioning.
[0072] In some implementations, the device in use can determine that it is exiting service based on a signal indicating the removal of a pull tab located between the device in use and the user. For example, a conductive / magnetic pull tab can be attached to the patient 12 such that when the device in use is removed from the patient 12, the pull tab disconnects the circuit, thereby preventing electrical signals from being transmitted along the circuit to the processor.
[0073] In some implementations, the device in use can determine that it is being taken out of service based on the fact that a charger has been connected to it. For example, the device in use can detect that power is being supplied to its battery.
[0074] In some implementations, the device in use may determine that it is exiting service based on received user input. For example, the device in use may have one or more buttons that, when pressed by the patient 12, cause the device in use to announce its biometric data and / or monitor the biometric data of the replacement device.
[0075] In some implementations, the device in use can determine that it is being decommissioned or is likely to be decommissioned based on the detection that a component has become inoperable. For example, the device in use can determine that it has low battery power, that it has an empty insulin reservoir, and / or that the glucose sensor has reached the end of its life based on processing signals from a battery monitor, processing signals from a force sensor, and / or failing to process any signals from a glucose sensor.
[0076] In some implementations, the device in use can determine that it is out of service or is likely to be out of service based on the interruption of communication with another device. For example, the device in use can determine that it is out of service when it loses network connection with the patient device 24.
[0077] For example, insulin pump 30 may be an in-use device including one or more sensors that generate first biometric data (e.g., an accelerometer that generates first motion data, a glucose sensor that generates first glucose measurement data, and / or a temperature sensor that generates first skin temperature data). When insulin pump 30 determines that it is being taken out of service, it may notify nearby devices of all or part of the first biometric data. At any time related to the notification made by insulin pump 30 (e.g., before, during, and / or after it), a replacement insulin pump may be put into service. Replacement insulin pump may include one or more sensors that generate second biometric data (e.g., an accelerometer that generates second motion data, a glucose sensor that generates second glucose measurement data, and / or a temperature sensor that generates second skin temperature data). When it is determined that it is being put into service, replacement insulin pump may notify nearby devices (including insulin pump 30) of all or part of the second biometric data. To enhance safety, insulin pump 30 and the replacement insulin pump can communicate different biometric data (e.g., insulin pump 30 can communicate movement data, while the replacement insulin pump can communicate skin temperature data, or insulin pump 30 can communicate glucose measurement data at time T1, while the replacement insulin pump can communicate glucose measurement data at time T2).
[0078] To perform biometric authentication, insulin pump 30 and the replacement insulin pump can each perform a comparison between biometric data stored in their memory and biometric data reported by the other device. When both insulin pump 30 and the replacement insulin pump determine that the compared biometric data matches (e.g., are substantially identical), a network connection can be established between the devices. For example, either insulin pump 30 or the replacement insulin pump (e.g., whichever device determines the matching biometric data earlier) can automatically initiate the establishment of the network connection, and the other device can confirm or reject the establishment of the network connection based on whether it determines that the matching biometric data is present.
[0079] Some exemplary methods for automatically establishing a network connection involve an intermediate device (e.g., patient device 24) configured to store first biometric data obtained from the device in use. Thus, instead of interacting with the device in use, the replacement device can interact with the intermediate device to perform biometric authentication.
[0080] For example, Figure 4 This is a block diagram illustrating an exemplary communication system for transmitting user-specific configuration data via an intermediate device, according to one or more examples described in this disclosure. Figure 4 The in-use medical device 40A and the replacement medical device 40B, which communicate with the patient device 24 via links 42A and 42B respectively, are shown. For ease of explanation, Figure 4 Patient device 24 is depicted as being coupled to both devices 40A and 40B. However, in some embodiments, when patient device 24 is coupled to device 40B, patient device 24 may not be coupled to device 40A, and vice versa. Optionally, patient device 24 may be communicatively coupled to one or more servers 28 of cloud 26.
[0081] To establish link 42B, patient device 24 and replacement medical device 40B can be used to perform biometric authentication. Patient device 24 can obtain biometric data generated by the in-use device 40A. This can be obtained in various ways. For example, device 40A can transmit biometric data to patient device 24 in response to determining that device 40A is out of service and / or whenever biometric data is generated by device 40A. Additionally or alternatively, patient device 24 can periodically poll device 40A to determine whether it has any biometric data to provide, and if so, patient device 24 can request the biometric data.
[0082] In some examples, patient device 24 may store biometric data in its memory. For example, patient device 24 may cache biometric data.
[0083] When it is determined that device 40A is exiting service, patient device 24 may monitor biometric data announced by device 40B. For example, patient device 24 may determine that device 40A is exiting service based on biometric data obtained from device 40A, determination that it has lost network connectivity with device 40A, and / or receipt of user input indicating that device 40A is exiting service. In some embodiments, patient device 24 may announce all or part of the biometric data obtained from device 40A when it is determined that device 40A is exiting service.
[0084] Patient device 24 may otherwise perform operations similar to those described herein as being applicable to devices in use. For example, patient device 24 may perform a comparison between biometric data notified by device 40B and biometric data obtained from device 40A, and after determining that matching biometric data is found, may establish link 42B (e.g., patient device 24 may automatically initiate or confirm the establishment of link 42B).
[0085] Figure 5 This is a block diagram illustrating an exemplary medical device according to one or more examples described in this disclosure. Figure 5 A medical device 51 is shown, which may be an in-use device or a replacement device. Examples of medical devices 51 include insulin pump 14 and insulin pump 30.
[0086] As shown in the figure, medical device 51 includes processing circuitry 50, memory 52, telemetry circuitry 54, power supply 56, insulin reservoir 58, motor controller 60, and one or more sensors 62. Medical device 51 may include... Figure 5 The components shown may have more or fewer parts. Furthermore, when the medical device 51 is a semi-disposable patch pump, some components of the medical device 51 may be located in the durable portion 32, and others may be located in the consumable portion 34. For example, the processing circuitry 50, memory 52, telemetry circuitry 54, motor controller 60, sensor 62, and power supply 56 may be part of the durable portion 32; while the insulin reservoir 58 may be part of the consumable portion 34. However, the specific combination of components in the durable portion 32 and the consumable portion 34 may vary between specific implementations.
[0087] The memory 52 may store program instructions that, when executed by the processing circuit 50, cause the processing circuit 50 to provide the functions pertaining to insulin pump 14, insulin pump 30, device 40A, and / or device 40B throughout this disclosure. The memory 52 may also store biometric data and user-specific configuration data.
[0088] The memory 52 may include any volatile, non-volatile, fixed, removable, magnetic, optical, or electrical medium, such as RAM, ROM, hard disk, removable disk, memory card or stick, NVRAM, EEPROM, flash memory, etc. The processing circuitry 50 may take the form of one or more microprocessors, DSPs, ASICs, FPGAs, programmable logic circuits, etc., and the functions attributed herein to the processing circuitry 50 may be embodied in hardware, firmware, software, or any combination thereof.
[0089] In one or more examples, processing circuitry 50 may use user-specific configuration data stored in memory 52 to output instructions to motor controller 60 to regulate insulin delivery. Motor controller 60 may be configured to control the timing and amount of insulin dispensed from insulin reservoir 58 based on instructions from processing circuitry 50.
[0090] One or more sensors 62 may include a glucose sensor (e.g., glucose sensor 38), an inertial measurement sensor, a skin temperature sensor, and / or any other sensor capable of generating a signal indicating that the medical device 51 is in service and / or out of service. For example, one or more sensors 62 may include a temperature sensor, a sweat sensor, a resistance sensor, etc., configured to generate a signal indicating whether the medical device 51 is attached to the body of the patient 12.
[0091] According to one or more examples described in this disclosure, telemetry circuitry 54 may be configured to transmit and / or receive biometric data and / or user-specific configuration data. Telemetry circuitry 54 may include any suitable hardware, firmware, software, or any combination thereof for enabling communication between medical device 51 and another device (e.g., patient device 24, replacement device 40B, and / or device in use 40A). Telemetry circuitry 54 may transmit and / or receive communication with the aid of an antenna, which may be internal to and / or external to medical device 51. Telemetry circuitry 54 may be configured to communicate via wired or wireless communication technologies. Examples of local wireless communication technologies that may be used to facilitate communication include RF communication according to IEEE 802.11, Bluetooth, or BLE specification sets, infrared communication such as according to the IrDA standard, near field communication (NFC), or other standard or proprietary telemetry protocols. Telemetry circuitry 54 may also provide connectivity to an operator network to access cloud 26. In this way, other devices may be able to communicate with medical device 51.
[0092] Power source 56 delivers operating power to components of medical device 51. In some examples, power source 56 may include a battery, such as a rechargeable or non-rechargeable battery. A non-rechargeable battery can last for several days or possibly longer, while a rechargeable battery can be periodically charged from an external device, for example, on a daily or weekly basis. Recharging of a rechargeable battery can be accomplished by using an alternating current (AC) outlet or by proximal inductive interaction between a charger device 42 and an inductive charging coil within medical device 51. In some examples, the inductive charging coil may be the same as the coil used for communication by telemetry circuitry 54. In some other examples, the inductive charging coil may be separate from the coil used for communication by telemetry circuitry 54.
[0093] Figure 6This is a block diagram illustrating an example of a patient device according to one or more examples described in this disclosure. While patient device 24 may generally be described as a handheld computing device, in some examples, patient device 24 may be, for example, a laptop computer, a desktop computer, or a workstation. In some examples, patient device 24 may be a mobile device such as a smartphone or tablet computer. Patient device 24 may execute applications that allow patient device 24 to perform the example technologies described in this disclosure. In some examples, patient device 24 may be a dedicated controller for communicating with medical device 51.
[0094] like Figure 6 As shown, the patient device 24 may include processing circuitry 70, memory 72, user interface 74, telemetry circuitry 76, and power supply 78. Memory 72 may store program instructions that, when executed by processing circuitry 70, cause processing circuitry 70 to provide the functions pertaining to the patient device 24 throughout this disclosure.
[0095] In some examples, the memory 72 of the patient device 24 may store biometric data and / or user-specific configuration data. For example, the in-use device 40A may transfer user-specific configuration data to the patient device 24, and the memory 72 may store user-specific configuration data for transfer to a replacement device 40B or one or more servers 28.
[0096] The memory 72 may include any volatile, non-volatile, fixed, removable, magnetic, optical, or electrical medium, such as RAM, ROM, hard disk, removable disk, memory card or stick, NVRAM, EEPROM, flash memory, etc. The processing circuitry 70 may take the form of one or more microprocessors, DSPs, ASICs, FPGAs, programmable logic circuits, etc., and the functions attributed herein to the processing circuitry 70 may be embodied in hardware, firmware, software, or any combination thereof.
[0097] User interface 74 may include buttons or a keyboard, lights, a microphone for voice commands, and / or a display device such as a liquid crystal display (LCD). In some examples, the display may be a touchscreen. Processing circuitry 70 may present and receive therapy-related information via user interface 74. For example, processing circuitry 70 may receive user input via user interface 74. User input may be entered, for example, by pressing buttons on a keyboard, typing text, or selecting icons from a touchscreen. For example, to input initial configuration data for medical device 51, patient 12 or physician may use user interface 74 to input configuration data.
[0098] Telemetry circuitry 76 may include any suitable hardware, firmware, software, or any combination thereof for enabling communication between patient device 24 and another device, such as one or more servers 28 of cloud 26, in-use device 40A, and replacement device 40B. Telemetry circuitry 76 may receive communication with the aid of an antenna, which may be internal to and / or external to patient device 24. Telemetry circuitry 76 may be configured to communicate via wired or wireless communication technologies. Examples of local wireless communication technologies that may be used to facilitate communication between patient device 24 and another computing device include RF communication according to IEEE 802.11, Bluetooth, or BLE specification sets; infrared communication, such as according to the IrDA standard; near field communication (NFC); or other standard or proprietary telemetry protocols. Telemetry circuitry 76 may also provide connectivity to a carrier network to access cloud 26. In this way, other devices may be able to communicate with patient device 24.
[0099] In some examples, telemetry circuitry 76 may include analog or digital RSSI detector circuitry that provides information indicating the strength of signals received from different devices (e.g., in-service device 40A and replacement device 40B). Processing circuitry 70 may use this information to determine which device is put into service and which is taken out of service. In some examples, this information may also indicate signal quality (e.g., how long the signal strength is high, how often the signal strength is high, etc.).
[0100] Power source 78 delivers operating power to components of patient device 24. In some examples, power source 78 may include a battery, such as a rechargeable or non-rechargeable battery. Non-rechargeable batteries can last for months or years, while rechargeable batteries can be periodically charged from an external device, for example, on a daily or weekly basis. Recharging of a rechargeable battery can be accomplished by using an alternating current (AC) outlet or by proximal inductive interaction between an external charger and an inductive charging coil within patient device 24.
[0101] Figure 7 This is a flowchart illustrating an exemplary process for automated network configuration based on biometric authentication according to one or more examples described in this disclosure. The exemplary process can automatically establish a communication link between the replacement device and the device in use or an intermediate device logically located between the replacement device and the device in use (e.g., patient device 24).
[0102] like Figure 7As shown, one or more processors (e.g., in-use devices or intermediate devices) can acquire first biometric data derived from one or more sensor signals generated by one or more sensors of a first device coupled to the user (90) (e.g., attached to the user or otherwise worn by the user). The first device may be an in-use medical device (e.g., insulin pump 14, monitoring device 20, or insulin pump 30) previously put into service to provide medical therapies to a user based on user-specific configuration data stored on the in-use medical device. One or more sensors of the first device may include temperature sensors, glucose sensors, and / or inertial measurement sensors (e.g., accelerometers or gyroscopes). Thus, examples of the first biometric data may include all or part of each of the following (e.g., one or more features): skin temperature data, glucose measurement data, and motion data (e.g., acceleration data). For example, the first biometric data may include all skin temperature data within a predetermined time period; all glucose measurements within a predetermined time period; all acceleration data within a predetermined time period; absolute or relative timing of a predetermined number of changes in skin temperature; absolute or relative timing of multiple glucose level inflection points (e.g., local maximums and / or minimums); and / or absolute or relative timing of multiple accelerations exceeding a predetermined threshold. In another example, the first biometric data may include each rate of change of skin temperature data within a predetermined time period; each rate of change of glucose measurements within a predetermined time period; each rate of change of acceleration data within a predetermined time period; absolute or relative timing of each predetermined rate of change of skin temperature; absolute or relative timing of each predetermined rate of change of glucose level; and absolute or relative timing of each acceleration exceeding a predetermined threshold.
[0103] It should be understood that although one or more sensor signals may be generated when the first device is coupled to a user, the first biometric data may be obtained when the first device is coupled to or disconnected from the user. For example, after the first device is removed from the user, the first biometric data may be derived based on the processing of one or more sensor signals.
[0104] At any time related to the acquisition of the first biometric data (e.g., before, simultaneously, and / or after), one or more processors may acquire second biometric data derived from one or more sensor signals generated by one or more sensors of the second device (92). The second device may be a replacement medical device for the first device (e.g., a replacement insulin pump or a replacement monitoring device). The one or more sensors of the second device may include a temperature sensor, a glucose sensor, and / or an inertial measurement sensor (e.g., an accelerometer or a gyroscope). Thus, examples of the second biometric data may include all or part of each of the following (e.g., one or more features): skin temperature data, glucose measurement data, and motion data (e.g., acceleration data). For example, the second biometric data may include all skin temperature data within a predetermined time period (e.g., the same time period corresponding to the skin temperature data of the first biometric data); all glucose measurement data within a predetermined time period (e.g., the same time period corresponding to the glucose measurement data of the first biometric data); all acceleration data within a predetermined time period (e.g., the same time period corresponding to the acceleration data of the first biometric data); absolute or relative timing of a predetermined number of changes in skin temperature; absolute or relative timing of multiple glucose level inflection points (e.g., local maximum and / or minimum values); and / or absolute or relative timing of multiple accelerations exceeding a predetermined threshold. In another example, the second biometric data may include each rate of change of skin temperature data within a predetermined time period; each rate of change of glucose measurement data within a predetermined time period; each rate of change of acceleration data within a predetermined time period; absolute or relative timing of each predetermined rate of change of skin temperature; absolute or relative timing of each predetermined rate of change of glucose level; and absolute or relative timing of each acceleration exceeding a predetermined threshold. When the second device determines (e.g., automatically) that it is being put into service, the second biometric data may have already been notified by the second device to any nearby devices (e.g., any device in a predetermined area in the local area of the second device).
[0105] One or more processors can compare the first biometric data and the second biometric data (94). In some respects, the biometric data is similar to a pass key exchanged during the Bluetooth pairing process.
[0106] Based on the comparison, one or more processors may determine whether the second device is coupled to a user. More specifically, if the first biometric data and the second biometric data match, the one or more processors may determine that the second device is coupled to a user (95). If the first device remains coupled during the biometric certification of the second device, the one or more processors may generate output data instructing the user to remove the first device. However, if the first biometric data and the second biometric data do not match, the one or more processors may determine that the second device is not coupled to a user (e.g., coupled to a different user).
[0107] Based on the determination that the second device is coupled to the user, one or more processors may establish a communication link with the second device (96). Establishing a communication link may include initiating the establishment of the communication link (e.g., transmitting a connection request to the second device). Alternatively, establishing a communication link may include confirming the establishment of the communication link (e.g., responding positively to a connection request from the second device). Through the above communication link, user-specific configuration data may be transmitted to the second device.
[0108] It should be understood that Figure 7 The described process is provided as an example only and may be modified without departing from the scope of this disclosure. More specifically, the exemplary process may be practiced in a different order or with more / fewer tasks. For example, prior to establishing a communication link (e.g., simultaneously with task 92, task 94, or task 95), one or more processors may obtain third biometric data derived from one or more sensor signals generated by one or more sensors of the first device. For added security, the third biometric data may differ from the first biometric data (e.g., the first and third biometric data may correspond entirely to different time periods, different characteristics of one or more sensor signals, and / or different sensors). Furthermore, upon determining (e.g., automatically) that the first device is out of service, one or more processors may notify any nearby devices (e.g., any device within a predetermined area local to one or more processors).
[0109] The following describes some exemplary techniques that can be used separately or in any combination.
[0110] Example 1: A method for automated network configuration based on biometric authentication, the method comprising: obtaining first biometric data derived from one or more sensor signals generated by one or more sensors of a first device coupled to a user by one or more processors; obtaining second biometric data derived from one or more sensor signals generated by one or more sensors of a second device by the one or more processors; comparing the first biometric data and the second biometric data by the one or more processors; determining, based on the comparison, that the second device is coupled to the user; and establishing a communication link with the second device by the one or more processors based on the determination that the second device is coupled to the user.
[0111] Example 2: According to the method of Example 1, the method further includes: obtaining third biometric data derived from the one or more sensor signals generated by the one or more sensors of the first device before establishing the communication link; and notifying the third biometric data to any device in a predetermined area local to the one or more processors.
[0112] Example 3: The method according to any one of Examples 1 and 2, wherein the third biometric data is different from the first biometric data.
[0113] Example 4: The method according to any one of Examples 1 to 3, wherein when it is determined that the first device is out of service, the notification of the third biometric data is performed.
[0114] Example 5: The method according to any one of Examples 1 to 4, wherein when the second device determines that it is in service, the second biometric data is communicated to any device in a predetermined area in the locality of the second device.
[0115] Example 6: The method according to any one of Examples 1 to 5, wherein establishing the communication link with the second device includes initiating the establishment of the communication link.
[0116] Example 7: The method according to any one of Examples 1 to 6, wherein establishing the communication link with the second device includes confirming the establishment of the communication link.
[0117] Example 8: The method according to any one of Examples 1 to 7 further includes transmitting user-specific configuration data to the second device via the communication link.
[0118] Example 9: The method according to any one of Examples 1 to 8, wherein the first device includes the one or more processors.
[0119] Example 10: The method according to any one of Examples 1 to 9, wherein an intermediate device is logically located between the first device and the second device, and wherein the intermediate device includes the one or more processors.
[0120] Example 11: The method according to any one of Examples 1 to 10, wherein the first biometric data and the second biometric data correspond to the same time period.
[0121] Example 12: The method according to any one of Examples 1 to 11, wherein the one or more sensors of the first device and the one or more sensors of the second device include temperature sensors.
[0122] Example 13: The method according to any one of Examples 1 to 12, wherein the one or more sensors of the first device and the one or more sensors of the second device include glucose sensors.
[0123] Example 14: The method according to any one of Examples 1 to 13, wherein the first biometric data and the second biometric data include absolute or relative timing of multiple glucose level inflection points.
[0124] Example 15: The method according to any one of Examples 1 to 14, wherein the one or more sensors of the first device and the one or more sensors of the second device include inertial measurement sensors.
[0125] Example 16: The method according to any one of Examples 1 to 15, wherein the first biometric data and the second biometric data include absolute or relative timing of multiple accelerations exceeding a predetermined threshold.
[0126] Example 17: The method according to any one of Examples 1 to 16, wherein each of the first device and the second device includes an insulin pump.
[0127] Example 18: A system for automated network configuration based on biometric authentication, the system comprising: one or more processors; and one or more processor-readable storage media storing instructions that, when executed by the one or more processors, cause to perform: obtaining first biometric data derived from one or more sensor signals generated by one or more sensors of a first device coupled to a user; obtaining second biometric data derived from one or more sensor signals generated by one or more sensors of a second device; comparing the first biometric data and the second biometric data; determining, based on the comparison, that the second device is coupled to the user; and establishing a communication link with the second device based on the determination that the second device is coupled to the user.
[0128] Example 19: The system of claim 18, wherein the one or more processor-readable storage medium further stores instructions that, when executed by the one or more processors, cause to perform: obtaining third biometric data derived from the one or more sensor signals generated by the one or more sensors of the first device before establishing the communication link; and notifying the third biometric data to any device in a predetermined area local to the one or more processors.
[0129] Example 20: One or more non-transitory processor-readable storage media storing instructions that, when executed by one or more processors, cause the following to be performed: obtaining first biometric data derived from one or more sensor signals generated by one or more sensors of a first device coupled to a user; obtaining second biometric data derived from one or more sensor signals generated by one or more sensors of a second device; comparing the first biometric data and the second biometric data; determining, based on the comparison, that the second device is coupled to the user; and establishing a communication link with the second device based on the determination that the second device is coupled to the user.
[0130] Various aspects of these technologies may be implemented within one or more processors (including one or more microprocessors, DSPs, ASICs, FPGAs, or any other equivalent integrated or discrete logic circuits), and any combination of such components, embodied in programmers such as physician or patient programmers, electrical stimulators, or other devices. The terms “processor” or “processing circuit” may generally refer to any of the aforementioned logic circuits, alone or in combination with other logic circuits, or any other equivalent circuit.
[0131] In one or more examples, the functionality described in this disclosure may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. The computer-readable medium may include a computer-readable storage medium forming a tangible, non-transitory medium. The 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 circuits. Therefore, as used herein, the term "processor" may refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein.
[0132] Additionally, in some aspects, the functions described herein can be housed within dedicated hardware and / or software modules. Describing 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 implemented by separate hardware or software components. Rather, the functions 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. Furthermore, the technology can be fully implemented in one or more circuit or logic elements. The technology of this disclosure can be implemented in a wide variety of devices or apparatuses, including one or more processors of cloud 26, one or more processors of patient device 24, one or more processors of insulin pump 14, or some combination thereof. One or more processors can be one or more integrated circuits (ICs) and / or discrete circuits residing in various locations within the exemplary systems described in this disclosure.
[0133] One or more processors or processing circuits used in, for example, the example techniques described in this disclosure, can be implemented as fixed-function circuits, programmable circuits, or combinations thereof. A fixed-function circuit is a circuit that provides a specific function and is pre-configured for executable operations. A programmable circuit is a circuit that can be programmed to perform a variety of tasks and provides flexible functionality in its executable operations. For example, a programmable circuit can execute software or firmware that causes the programmable circuit to operate in a manner defined by the instructions of the software or firmware. A fixed-function circuit can execute software instructions (e.g., receive or output parameters), but the type of operation performed by a fixed-function circuit is generally immutable. In some examples, one or more units in the unit may be different circuit blocks (fixed-function or programmable), and in some examples, the one or more units may be integrated circuits. The processor or processing circuit may include an arithmetic logic unit (ALU), an essential function unit (EFU), digital circuitry, analog circuitry, and / or a programmable core formed by the programmable circuit. In examples where the operation of the processor or processing circuit is performed using software executed by the programmable circuit, memory accessible to the processor or processing circuit may store object code of the software received and executed by the processor or processing circuit.
[0134] Various aspects of this disclosure have been described. These and other aspects are within the scope of the following claims.
Claims
1. A method for automated network configuration based on biometric authentication, the method comprising: First biometric data derived by one or more processors from one or more sensor signals generated by one or more sensors of a first device attached to the user's body; The processor obtains second biometric data derived from one or more sensor signals generated by one or more sensors of a second device attached to the user's body; The first biometric data and the second biometric data are compared by the one or more processors; The one or more processors determine, based on the comparison, that the second device is attached to the same user as the user to whom the first device is attached; The one or more processors establish a communication link with the second device based on determining that the second device is attached to the same user; as well as The one or more processors generate output data instructing the user to remove the first device from their body so that the first device is out of service.
2. The method according to claim 1, further comprising: Before establishing the communication link, third biometric data derived from the one or more sensor signals generated by the one or more sensors of the first device are obtained; as well as The third biometric data is communicated to any device in a predetermined area local to the one or more processors.
3. The method according to claim 2, wherein the third biometric data is different from the first biometric data.
4. The method of claim 2, wherein when it is determined that the first device is out of service, the notification of the third biometric data is performed.
5. The method of claim 1, wherein when the second device determines that it is in service, the second biometric data is communicated to any device in a predetermined area local to the second device.
6. The method of claim 1, wherein establishing the communication link with the second device includes initiating the establishment of the communication link.
7. The method of claim 1, wherein establishing the communication link with the second device includes confirming the establishment of the communication link.
8. The method of claim 1, further comprising transmitting user-specific configuration data to the second device via the communication link.
9. The method of claim 1, wherein the first device comprises the one or more processors.
10. The method of claim 1, wherein the intermediate device is logically located between the first device and the second device, and wherein the intermediate device includes the one or more processors.
11. The method according to claim 1, wherein the first biometric data and the second biometric data correspond to the same time period.
12. The method of claim 1, wherein the one or more sensors of the first device and the one or more sensors of the second device comprise a temperature sensor.
13. The method of claim 1, wherein the one or more sensors of the first device and the one or more sensors of the second device comprise a glucose sensor.
14. The method according to claim 1, wherein the first biometric data and the second biometric data include absolute or relative timing of multiple glucose level inflection points.
15. The method of claim 1, wherein the one or more sensors of the first device and the one or more sensors of the second device comprise inertial measurement sensors.
16. The method of claim 1, wherein the first biometric data and the second biometric data include absolute or relative timing of a plurality of accelerations exceeding a predetermined threshold.
17. The method of claim 1, wherein each of the first device and the second device comprises an insulin pump.
18. A system for automated network configuration based on biometric authentication, the system comprising: One or more processors; and One or more processor-readable storage media storing instructions that, when executed by the one or more processors, cause the following to be performed: Obtain first biometric data derived from one or more sensor signals generated by one or more sensors of a first device attached to the user's body; Obtain second biometric data derived from one or more sensor signals generated by one or more sensors of a second device attached to the user's body; Compare the first biometric data and the second biometric data; Based on the comparison, it is determined that the second device is attached to the same user as the user to whom the first device is attached; A communication link with the second device is established based on the determination that the second device is attached to the same user. as well as The one or more processors generate output data instructing the user to remove the first device from their body so that the first device is out of service.
19. The system of claim 18, wherein the one or more processor-readable storage media further stores instructions that, when executed by the one or more processors, cause the following to be performed: Prior to establishing the communication link, third biometric data derived from the one or more sensor signals generated by the one or more sensors of the first device are obtained; and The third biometric data is communicated to any device in a predetermined area local to the one or more processors.
20. A non-transitory processor-readable storage medium storing instructions that, when executed by one or more processors, cause the following to be performed: Obtain first biometric data derived from one or more sensor signals generated by one or more sensors of a first device attached to the user's body; Obtain second biometric data derived from one or more sensor signals generated by one or more sensors of a second device attached to the user's body; Compare the first biometric data and the second biometric data; Based on the comparison, it is determined that the second device is attached to the same user as the user to whom the first device is attached; as well as A communication link with the second device is established based on the determination that the second device is attached to the same user. as well as The one or more processors generate output data instructing the user to remove the first device from their body so that the first device is out of service.