Method and system for verifying whether a non-medical client device is operating correctly with a medical device controlled by the non-medical client device and causing a notification to be generated

Abstract

This document provides a method and system for verifying whether a non-medical client device is operating correctly with a medical device controlled by the non-medical client device (NMCD) and causing a notification to be generated. According to the method, an application at the non-medical client device monitors for the occurrence of a trigger event, and when the trigger event is detected, the application may perform one or more diagnostic checks to verify whether the medical control application at the NMCD is operating correctly. When the application determines that the one or more diagnostic checks have failed, the medical control application may attempt to initiate one or more remedial corrective actions to restore the medical control application so that it operates correctly. When the one or more remedial corrective actions are unsuccessful, the application causes the notification to be generated through the user interface of the non-medical client device.

Description

Technical Field

[0001] Embodiments of the subject matter described herein relate generally to medical devices and medical device systems, and more particularly, to a method and medical device system for verifying that a non-medical client device is operating properly with a medical device controlled by the non-medical client device, such as an insulin infusion system. When one or more remedial corrective actions are unsuccessful in restoring the non-medical client device to proper operation, a notification may be generated. Background Art

[0002] Wireless devices such as cellular phones, mobile computers, personal digital assistants, digital media players, portable video game devices, etc. and related wireless communication technologies and protocols have become ubiquitous in modern society. Recently, portable medical devices with wireless data communication capabilities have become increasingly popular, especially for patients with conditions that must be monitored on a continuous or frequent basis. For example, diabetics usually need to change and monitor their daily lifestyle to maintain their body balance, particularly their blood sugar (" BG ") level. Individuals with type 1 diabetes and some individuals with type 2 diabetes use insulin to control their BG levels. For this reason, diabetics usually maintain a strict schedule, including timely intake of nutritious meals, participation in exercise, daily monitoring of BG levels, and corresponding regulation and administration of insulin dosages. Diabetics can utilize wireless medical devices deployed in a network environment in a manner that facilitates data communication between two or more separate devices.

[0003] In the past, a custom controller device (CCD) could be used to control medical devices on the body such as fluid infusion devices (or infusion pumps) and sensing devices (e.g., continuous glucose sensors). Today, there is a growing trend of using non-medical devices such as patients' smartphones, laptops, or tablets to control personal medical devices such as insulin infusion devices worn by patients. Non-medical smart devices (e.g., smartphones, tablets) can now be used to communicate and control medical devices on the body. One advantage of this method is that the need for patients to own and use another different control device can be eliminated. This can make the cost of ownership lower. In addition, patients can manage their diseases carefully and use familiar user interfaces and form factors that shorten the learning curve. This can also provide a connection to a back-end system (e.g., a cloud-based system) that is used to monitor patients and control drug delivery to patients. Non-medical smart devices can upload data for analysis by healthcare providers (HCPs) and AI-based systems. Non-medical smart devices can also receive regular updates to treatment management software. For example, these updates can update medical control application software (or its key parameters) to customize and improve treatment. Connectivity also provides a means to alert caregivers and HCPs in emergency situations when concerning trends emerge. Medical control applications can also use health-related data from non-medical smart devices and other applications / systems to improve treatment for patients.

[0004] Many insulin pump systems are designed to deliver accurate and measured insulin doses through an infusion set (an infusion set delivers insulin through a small diameter tube that terminates in a cannula inserted under the patient's skin). Instead of a syringe, the patient can simply activate an insulin pump to give an insulin bolus, for example, in response to the patient's current BG level, as needed. The patient can measure his BG level using a BG measuring device, such as a test strip meter, a continuous glucose measurement system, etc. The BG measuring device uses various methods to measure the patient's BG level, such as a blood sample of the patient, a sensor in contact with a body fluid, an optical sensor, an enzyme sensor, or a fluorescent sensor. When the BG measuring device has generated a BG measurement value, the measurement value will be displayed on the BG measuring device. The continuous glucose monitoring system can monitor the patient's sensor glucose (SG) level (e.g., subcutaneous tissue glucose level) in real time. This allows the delivery of insulin to be calculated in real time using a dose calculated by a software algorithm or a closed-loop algorithm based on the measured sensor glucose level.

[0005] Insulin pumps, continuous glucose monitoring (CGM) devices, and other devices such as smartphones and blood glucose monitors (BGM) can be different parts of an insulin infusion system. The various devices that are part of an insulin infusion system can form a wireless body area network that can be used, for example, to exchange monitoring and treatment (control) data between multiple medical devices worn on or near the patient's body. For example, treatment data such as measured glucose values ​​(SG values) and treatment settings (parameters for bolus delivery) can be transmitted wirelessly between devices within the body area network. Insulin pumps and CGM devices can also be configured to communicate with remote control devices, monitoring or display devices, BG meters, and other devices associated with such infusion systems. For example, a CGM sensor can include a wireless radio frequency ("RF") transmitter or cooperate with a wireless radio frequency ("RF") transmitter that communicates with other devices that are part of the infusion system, such as a handheld remote control (also called a command control device (CCD)) that uses a conventional (BT) or (BLE) technology to communicate with the infusion pump device.

[0006] Both the insulin infusion device and the smartphone may include a display and different types of alarms to alert the user when they are not operating correctly. For example, with respect to the insulin infusion device, if the microcontroller of the insulin infusion device fails, a notification (e.g., a message on a display, an audible or visual alarm, or other types of alarms such as vibration) may be activated to notify the user that their insulin infusion device is not operating correctly.

[0007] While such smartphones may offer many advantages over non-medical devices, one risk from the perspective of medical device manufacturers is that smartphones or other smart devices are relatively open platforms and are not as controllable as medical devices.

[0008] Therefore, it is desirable to provide a medical device system, such as an insulin infusion system, that can verify whether a non-medical client device (e.g., a smartphone or other smart device) is operating correctly with a wearable medical device (e.g., an insulin infusion device) controlled by the non-medical client device. It is also desirable to reduce the risks associated with using smartphones. In addition, other desired features and characteristics will become apparent from the subsequent detailed description and the appended claims in conjunction with the accompanying drawings and the aforementioned technical field and background technology. Summary of the invention

[0009] In one embodiment, a method for verifying whether a non-medical client device is operating correctly with a medical device controlled by the non-medical client device and causing a notification to be generated is provided. According to the method, an application at the non-medical client device monitors for the occurrence of a trigger event, and when the non-medical client device detects the occurrence of a trigger event, the application at the non-medical client device can perform one or more diagnostic checks to verify whether the medical control application at the non-medical client device is operating correctly. When the application at the non-medical client device determines that the one or more diagnostic checks have failed, the medical control application at the non-medical client device can attempt to initiate one or more remedial corrective measures to restore the medical control application so that it operates correctly, and when the one or more remedial corrective measures are unsuccessful, the application at the non-medical client device causes a notification to be generated through a user interface of the non-medical client device.

[0010] In one embodiment, the notification may be a first notification, and after causing the first notification to be generated through a user interface of the non-medical client device, a counter may be started at the non-medical client device. The application at the non-medical client device may then periodically determine whether a confirmation signal has been generated to confirm the first notification. When the count of the counter exceeds a threshold count and a confirmation signal has not been generated to confirm the first notification, a second notification is caused to be generated through a second user interface of the medical device. The second notification is used to alert the user that the first notification generated at the non-medical client device has not been confirmed, so that other remedial measures can be taken at the non-medical client device.

[0011] In one embodiment, when an application at a non-medical client device detects the occurrence of a triggering event, the application at the non-medical client device may perform a communication link verification process to determine whether the non-medical client device has an established communication link to the medical device. When the application at the non-medical client device determines that the non-medical client device does not have a communication link to the medical device, it may attempt to establish a communication link between the non-medical client device and the medical device. In one embodiment, when the attempt to establish a communication link between the non-medical client device and the medical device is unsuccessful, a first notification is caused to be generated through a user interface of the non-medical client device, and when the attempt to establish a communication link between the non-medical client device and the medical device is unsuccessful, a second notification is caused to be generated through a second user interface of the medical device.

[0012] In one embodiment, when the application at the non-medical client device detects the occurrence of a triggering event, the application at the non-medical client device may initiate a verification protocol. The verification protocol may include performing one or more diagnostic checks to verify that the medical control application is functioning properly and has access to sufficient computing resources. The computing resources may include processing resources, communication resources, user interface resources, and memory resources.

[0013] In one embodiment, the triggering event includes one or more of: receiving an indication that a notification needs to be confirmed; receiving an indication that a notification needs to be activated; receiving an indication that a notification has been issued; receiving an indication that a timer has expired; and receiving an indication that a counter has a count exceeding a threshold count.

[0014] In one embodiment, the one or more diagnostic checks used to verify whether the medical control application is running correctly include one or more of the following: determining whether the operating system version is up to date; determining whether the medical control application is up to date; determining whether the settings of the medical control application are correct; determining whether the medical control application is loaded normally; and determining whether the medical control application is running normally.

[0015] In one embodiment, the one or more remedial corrective actions attempt to correct the problem that caused the non-medical client device to operate improperly so that the medical control application will function correctly and can access required computing resources.

[0016] In one embodiment, one or more remedial corrective measures include one or more of the following: automatically closing and restarting the medical control application; when it is determined that the medical control application is not loaded or is not running normally, prompting the user to change and restart the medical control application of the non-medical client device; automatically closing the non-medical client device, automatically restarting the non-medical client device and reopening the medical control application; when it is determined that the existing version is incorrect, downloading and installing the latest version of the medical control application or the latest version of the operating system; when it is determined that one or more settings of the medical control application are incorrect, prompting the user to change one or more settings of the medical control application; and when it is determined that the medical control application cannot access sufficient computing resources, releasing additional computing resources of the non-medical client device for use by the medical control application.

[0017] In one embodiment, the non-medical client device comprises a smartphone, and the medical device comprises one of an insulin infusion device and a glucose sensor arrangement, the insulin infusion device being configured to be controlled by the medical control application executed at the smartphone.

[0018] In another embodiment, a non-medical client device is provided, which is configured to execute a medical control application that controls a medical device. The non-medical client device includes: at least one processor device; and a non-transitory processor-readable medium operably associated with the at least one processor device. The processor-readable medium includes executable instructions, which can be configured to cause the at least one processor device to perform a method for verifying whether the non-medical client device is operating correctly with the medical device and causing a notification to be generated. The method includes: monitoring the occurrence of a trigger event through an application at the non-medical client device; when the application at the non-medical client device detects the occurrence of the trigger event, performing one or more diagnostic checks through the application at the non-medical client device to verify whether the medical control application at the non-medical client device is operating correctly; attempting to initiate one or more remedial corrective measures through the application to restore the medical control application at the non-medical client device, so that when the application at the non-medical client device determines that the one or more diagnostic checks have failed, the medical control application is operating correctly; and when the one or more remedial corrective measures are unsuccessful, causing the notification to be generated through the user interface of the non-medical client device through the application.

[0019] In another embodiment, a wireless body area network for an insulin infusion system is provided. The wireless body area network includes a plurality of devices as part of the wireless body area network, the plurality of devices including: a non-medical client device and a medical device controlled by a medical control application configured to be executed by the non-medical client device. The non-medical client device includes: a processor device; and a non-transitory processor-readable medium operably associated with the processor device. The processor-readable medium includes executable instructions that can be configured to cause the processor device to perform a method for verifying whether the non-medical client device is operating correctly with the medical device and causing a notification to be generated. The method includes: monitoring the occurrence of a trigger event through an application at the non-medical client device; when the application at the non-medical client device detects the occurrence of the trigger event, performing one or more diagnostic checks through the application at the non-medical client device to verify whether the medical control application at the non-medical client device is operating correctly; attempting to initiate one or more remedial corrective measures through the application to restore the medical control application at the non-medical client device, so that when the application at the non-medical client device determines that the one or more diagnostic checks have failed, the medical control application operates correctly; and when the one or more remedial corrective measures are unsuccessful, causing the notification to be generated through the user interface of the non-medical client device through the application.

[0020] In one embodiment, the notification is a first notification, and the method further includes: after causing the first notification to be generated through the user interface of the non-medical client device, starting a counter at the non-medical client device; periodically determining, through the application at the non-medical client device, whether to generate a confirmation signal to confirm the first notification; and when the count of the counter exceeds a threshold count and a confirmation signal is not generated to confirm the first notification, causing the second notification to be generated through a second user interface of the medical device. The second notification is used to alert the user that the first notification generated at the non-medical client device has not been confirmed, so that other remedial measures can be taken at the non-medical client device.

[0021] In one embodiment, the triggering event includes one or more of: receiving an indication that a notification needs to be confirmed; receiving an indication that a notification needs to be activated; receiving an indication that a notification has been issued; receiving an indication that a timer has expired; and receiving an indication that a counter has a count exceeding a threshold count. The one or more diagnostic checks used to verify whether the medical control application is running correctly include one or more of: determining whether an operating system version is up to date; determining whether the medical control application is up to date; determining whether settings of the medical control application are correct; determining whether the medical control application is loaded normally; and determining whether the medical control application is running normally.

[0022] In one embodiment, when the application at the non-medical client device detects the occurrence of a triggering event, the application at the non-medical client device initiates a verification protocol. The verification protocol includes: performing one or more diagnostic checks to verify whether the medical control application is functioning properly and has access to sufficient computing resources, wherein the computing resources include processing resources, communication resources, user interface resources, and memory resources.

[0023] In one embodiment, the one or more remedial corrective measures attempt to correct the problem that caused the non-medical client device to operate abnormally so that the medical control application will function correctly and can access the required computing resources. The one or more remedial corrective measures include one or more of the following: automatically shutting down and restarting the medical control application; when it is determined that the medical control application is not loaded or is not operating normally, prompting the user to change and restart the medical control application of the non-medical client device; automatically shutting down the non-medical client device, automatically restarting the non-medical client device and reopening the medical control application; downloading and installing the latest version of the medical control application or the latest version of the operating system when it is determined that the existing version is incorrect; when it is determined that one or more settings of the medical control application are incorrect, prompting the user to change one or more settings of at least one of the medical control application, the non-medical client device or the operating system of the non-medical client device; and when it is determined that the medical control application cannot access sufficient computing resources, releasing additional computing resources of the non-medical client device for use by the medical control application.

[0024] This summary is provided to introduce a series of concepts further described in the detailed description below in a simplified form. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] A more complete understanding of the subject matter may be obtained by referring to the detailed description and claims when considered in conjunction with the following drawings, wherein like reference numerals refer to like elements throughout the drawings.

[0026] Figure 1 An exemplary embodiment of an infusion system is depicted;

[0027] Figure 2 is a simplified block diagram representation of an exemplary embodiment of a communication system;

[0028] Figure 3 is a simplified block diagram representation of an exemplary embodiment of a computer-based or processor-based device in accordance with the disclosed embodiments;

[0029] Figure 4 is a method for verifying whether a communication link between a non-medical client device and a medical device is established and for causing a notification to be issued at the non-medical client device and / or the medical device when the communication link is not established in accordance with the disclosed embodiments;

[0030] Figure 5 is a method for verifying the normal operation / functioning of a non-medical client device and a medical control application according to the disclosed embodiments; and

[0031] Figure 6 A method for generating a notification at a medical device when a notification generated at a non-medical client device is not acknowledged in accordance with the disclosed embodiments. DETAILED DESCRIPTION

[0032] The following specific embodiments are merely illustrative in nature and are not intended to limit the embodiments of the subject matter or the application or the application and use of such embodiments. As used herein, the word "exemplary" means "serving as an example, instance or illustration". Any embodiment described as exemplary herein is not necessarily to be construed as being superior to or superior to other embodiments. In addition, it is not intended to be bound by any express or implied theory presented in the aforementioned technical field, background technology, summary of the invention, or the following detailed description.

[0033] Technology and technology can be described herein according to functions and / or logic block components, and reference can be performed by various computing components or devices, symbolic representations of processing tasks and functions. Such operations, tasks and functions are sometimes referred to as computer-executed, computerized, software-implemented or computer-implemented. It should be understood that the various block components shown in the figure can be implemented by any number of hardware, software and / or firmware components configured to perform the specified functions. For example, embodiments of the system or component can use various integrated circuit components, such as memory elements, digital signal processing elements, logic elements and lookup tables, etc., which can perform various functions under the control of one or more microprocessors or other control devices.

[0034] When implemented in software, firmware, or processor-readable instructions, the various elements of the systems described herein are essentially code segments or instructions that perform various tasks. In some embodiments, the program or code segments are stored in a tangible processor-readable medium, which may include any medium capable of storing or transmitting information. Examples of non-transitory and processor-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, and hard disks, etc.

[0035] Exemplary embodiments of the subject matter described herein are implemented in conjunction with a medical device (e.g., a portable electronic medical device). Although many different applications are possible, the following description focuses on embodiments that incorporate an insulin infusion device (or insulin pump) as part of an infusion system deployment. For the sake of brevity, conventional techniques related to infusion system operation, insulin pump and / or infuser operation, and other functional aspects of the system (and the individual operating components of the system) may not be described in detail herein. Examples of infusion pumps may be of, but are not limited to, the types described in the following U.S. Patents: 4,562,751; 4,685,903; 5,080,653; 5,505,709; 5,097,122; 6,485,465; 6,554,798; 6,558,320; 6,558,351; 6,641,533; 6,659,980; 6,752,787; 6,817,990; 6,932,584; and 7,621,893; each of which is incorporated herein by reference.

[0036] Typically, the fluid infusion device includes a motor or other actuation arrangement that is operable to linearly move a plunger (or stopper) of a fluid reservoir disposed within the fluid infusion device to deliver a dose of fluid, such as insulin, to the user's body. The dose command governing the operation of the motor can be generated in an automatic manner according to a delivery control scheme associated with a particular operating mode, and the dose command can be generated in a manner affected by the current (or most recent) measurement of the physiological condition of the user's body. For example, in a closed-loop or automatic operating mode, a dose command can be generated based on the difference between the current (or most recent) measurement of the interstitial fluid glucose level in the user's body and the target (or reference) glucose set value. In this regard, the infusion rate can vary with the difference between the current measurement and the target measurement. For the purpose of explanation, the subject matter is described herein in the context of insulin used to regulate the glucose level of the user (or patient); however, it should be understood that many other fluids can be administered by infusion, and the subject matter described herein is not necessarily limited to use with insulin.

[0037] Smart devices (e.g., smartphones) are devices that are available to the general public and have other uses besides medical applications. Using such non-medical devices as part of a medical device system can provide many advantages. However, from the perspective of medical device manufacturers, one concern about using such non-medical devices to control medical devices is their openness, reliability, and security, because smart devices are relatively open platforms and are not as controllable as medical devices. In addition to writing the code for the medical control application implemented on the patient's smart device, the medical device manufacturer has little control over the patient's smart device and cannot ensure that it works correctly. For example, the medical device manufacturer does not write the operating system used by the smart device, cannot control the installation of the latest software (including medical control applications) on the smart device, cannot control the settings made by the user on the smart device, etc. For example, there is no way to ensure that the patient updates the operating system (OS) software and other applications, or ensures that the patient configures the settings of the non-medical smart device normally. In addition, the availability of required computing resources on the non-medical smart device can affect the functionality of the system. In contrast, since the medical device is designed by the device manufacturer, there is more control over its operation and settings, and it is therefore considered more reliable.

[0038] In addition, users can control the operation of their smart devices and change settings (e.g., volume settings, wireless communication interface settings), etc. For example, users are responsible for controlling the settings of their smart devices, other devices they are connected to, the use of computing resources, updates to the operating system or other application software (including what applications are installed and may conflict with the medical control application), etc. It may be necessary to notify or alert the user (e.g., when a patient's blood sugar level becomes low), but certain settings on the smart device can be set in a way to prevent this from happening. For example, Bluetooth can be used for phone calls, the speaker can be used to listen to music, or the volume of the device can be turned off. In short, this openness of smart devices creates a potential risk that the medical control application executed at the smart device may not operate as expected.

[0039] To address these issues, a medical device system, such as an insulin infusion system, is provided that can verify whether a non-medical client device (e.g., a smartphone or other smart device) is operating correctly with a wearable medical device (e.g., an insulin infusion device) controlled by the non-medical client device. This system can reduce the risks associated with using smart devices such as smartphones and increase the likelihood that patients can continue to be notified in the event of a malfunction in their smartphones or the medical control application executed on their smartphones. For example, the system can allow patients to continue to receive warnings, alarms, and other alerts about their medical devices when needed, even if their smart devices (or non-medical devices) may not communicate with them, or even if the medical control application running on their smart devices is not operating as expected. For example, when the battery on the patient's smartphone runs out, or when the user switches the communication interface (e.g., Bluetooth interface) to link it to another device, or when the user turns off the volume on the smartphone so that the patient cannot hear the alarm generated by the application, or when the medical control application fails to operate as expected for any reason, the system can allow the patient to continue to receive warnings, alarms, and other alerts.

[0040] In one embodiment, methods, systems, and apparatus are provided for verifying that a non-medical client device is operating correctly with a medical device controlled by the non-medical client device and causing a notification to be generated. The medical device and the non-medical client device may be part of a wireless body area network for a medical device system (i.e., an insulin infusion system). According to certain embodiments, the insulin infusion system includes an insulin infusion device configured to deliver insulin to a user, a glucose sensor arrangement, a mobile non-medical client device such as a smartphone, and the like. For example, the non-medical client device may be a smartphone, and the medical device may be an insulin infusion device configured to be controlled by a medical control application executed at the smartphone.

[0041] In one embodiment, an application at a non-medical client device may monitor for the occurrence of a triggering event, and when the application at the non-medical client device detects the occurrence of a triggering event, the application at the non-medical client device may perform one or more diagnostic checks to verify whether the medical control application at the non-medical client device is operating correctly. For example, in one embodiment, the triggering event may be one or more of: receiving an indication that a notification needs to be confirmed; receiving an indication that a notification needs to be activated; receiving an indication that a notification has been issued; receiving an indication that a timer has expired; and receiving an indication that a counter has a count that exceeds a threshold count. In addition, in one embodiment, the one or more diagnostic checks may include one or more of: determining whether an operating system version is up to date; determining whether the medical control application is up to date; determining whether the settings of the medical control application are correct; determining whether the medical control application is loaded normally; and determining whether the medical control application is operating normally.

[0042] When the application at the non-medical client device determines that one or more diagnostic checks have failed (e.g., this may mean that the medical control application is not operating correctly), the application may attempt to initiate one or more remedial corrective measures to restore the medical control application so that it operates correctly. The one or more remedial corrective measures attempt to correct the problem that caused the non-medical client device to operate abnormally so that the medical control application will function correctly and can access the required computing resources (e.g., memory, processing, user interface, communication interface, power / supply, etc.). For example, in one embodiment, the remedial corrective measures may include one or more of the following: automatically shutting down and restarting the medical control application; when it is determined that the medical control application is not loaded or is not operating normally, prompting the user to change the medical control application of the non-medical client device to restart; automatically shutting down the non-medical client device, automatically restarting the non-medical client device and reopening the medical control application; downloading and installing the latest version of the medical control application or the latest version of the operating system when it is determined that the existing version is incorrect; when it is determined that one or more settings of the medical control application are incorrect, prompting the user to change one or more settings of the medical control application; and when it is determined that the medical control application cannot access sufficient computing resources, releasing additional computing resources of the non-medical client device for use by the medical control application.

[0043] When the one or more remedial corrective measures are unsuccessful, the application causes a first notification to be generated through the user interface of the non-medical client device, and a counter may be started after causing the notification to be generated. Thereafter, the application at the non-medical client device may periodically determine whether a confirmation signal has been generated to confirm the notification. When the count of the counter exceeds a threshold count and a confirmation signal is not generated to confirm the first notification, the application may cause a second notification to be generated through a second user interface of the medical device. The second notification is used to alert the user that the first notification generated at the non-medical client device has not been confirmed, so that other remedial measures can be taken at the non-medical client device.

[0044] For example, in one embodiment, an application at a non-medical client device may initiate a verification protocol when it detects the occurrence of a triggering event. The verification protocol may include performing diagnostic checks to verify that the medical control application is functioning properly and has access to sufficient computing resources (e.g., processing resources, communication resources, user interface resources, memory resources).

[0045] In another embodiment, when an application at a non-medical client device detects the occurrence of a triggering event, the application may perform a communication link verification process to determine whether the non-medical client device has an established communication link to the wearable medical device. When the application at the non-medical client device determines that the non-medical client device does not have a communication link to the wearable medical device, the application may attempt to establish a communication link between the non-medical client device and the medical device, and if the attempt to establish a communication link is unsuccessful, the application may cause a first notification to be generated through a user interface of the non-medical client device, and / or cause a second notification to be generated through a second user interface of the medical device.

[0046] In yet another embodiment, a method is provided for an application on a non-medical device (e.g., a smartphone, tablet, or laptop computer) to control an insulin pump to issue a notification or warning (e.g., activating an audio or visual alarm, activating a tactile signal). This provides a way for patients to know that their non-medical devices may not be operating as expected to warn them that they need to take certain actions. In one embodiment, the smartphone can periodically check to ensure that the application and / or the smartphone running the application are working as required. For example, whenever the information indicates that an alarm needs to be issued, a check can be performed to ensure that the application and / or the smartphone running the application are operating correctly. In this way, the system can determine whether everything is connected and working properly, so that the user knows whether the medical control application is working correctly or as expected. If everything is not connected or working properly, the backup warning system or alarm on the wearable medical device (e.g., CGM, insulin pump, or both) can be used as a backup to notify the user that the non-medical device or application it is executing is not operating normally or optimally as recommended (e.g., warning the user that the application and / or the smartphone running the application is not working as required, and / or warning the user that certain actions need to be taken).

[0047] Now go to Figure 1 , an exemplary embodiment of the infusion system 100 includes, but is not limited to, a fluid infusion device (or infusion pump) 102, a sensing arrangement 104, a command control device (CCD) 106, and a computer 108. The components of the infusion system 100 may be implemented using different platforms, designs, and configurations, and Figure 1 The embodiments shown in are not exhaustive or limiting. In practice, Figure 1 As shown in FIG. 1 , the infusion device 102 and the sensing arrangement 104 are fixed at a desired location on the body of the user (or patient). In this regard, Figure 1 The locations where the infusion device 102 and the sensing arrangement 104 are fixed to the user's body are provided only as representative, non-limiting examples. The elements of the infusion system 100 may be similar to those described in U.S. Pat. No. 8,674,288, the subject matter of which is incorporated herein by reference in its entirety.

[0048] exist Figure 1 In the illustrated embodiment, the infusion device 102 is designed as a portable medical device suitable for infusing a fluid, liquid, gel or other medication into the body of a user. In the exemplary embodiment, the infused fluid is insulin, although many other fluids can be administered by infusion, such as but not limited to HIV medications, medications for treating pulmonary hypertension, iron chelation medications, pain medications, anti-cancer treatments, drugs, vitamins, hormones, etc. In some embodiments, the fluid may include nutritional supplements, dyes, tracking media, saline media, hydration media, etc.

[0049] The sensing arrangement 104 generally represents a component of the infusion system 100 configured to sense, detect, measure, or otherwise quantify a condition of a user, and may include sensors, monitors, and the like for providing data indicative of a condition sensed, detected, measured, or otherwise monitored by the sensing arrangement. In this regard, the sensing arrangement 104 may include electronics and enzymes responsive to a biological condition of the user, such as blood glucose level, and provide data indicative of the blood glucose level to the infusion device 102, CCD 106, and / or computer 108. For example, the infusion device 102, CCD 106, and / or computer 108 may include a display for presenting information or data to the user based on sensor data received from the sensing arrangement 104 (e.g., a user's current glucose level, a plot or graph of the user's glucose level over time, a device status indicator, an alarm message, and the like). In other embodiments, the infusion device 102, the CCD 106, and / or the computer 108 may include electronics and software configured to analyze the sensor data and operate the infusion device 102 based on the sensor data and / or a preprogrammed delivery routine to deliver the fluid to the user's body. Thus, in an exemplary embodiment, one or more of the infusion device 102, the sensing arrangement 104, the CCD 106, and / or the computer 108 include a transmitter, a receiver, and / or other transceiver electronics that allow communication with other components of the infusion system 100, such that the sensing arrangement 104 can transmit sensor data or monitor data to one or more of the infusion device 102, the CCD 106, and / or the computer 108.

[0050] Still reference Figure 1 In various embodiments, the sensing arrangement 104 may be affixed to the user's body or embedded in the user's body at a location remote from where the infusion device 102 is affixed to the user's body. In various other embodiments, the sensing arrangement 104 may be incorporated into the infusion device 102. In other embodiments, the sensing arrangement 104 may be separate and isolated from the infusion device 102 and may be, for example, part of the CCD 106. In such embodiments, the sensing arrangement 104 may be configured to receive a biological sample, an analyte, etc. to measure a condition of the user.

[0051] In some embodiments, the CCD 106 and / or the computer 108 may include electronics and other components configured to perform processing, deliver routine storage, and control the infusion device 102 in a manner affected by sensor data measured by and / or received from the sensing arrangement 104. By including the control functions in the CCD 106 and / or the computer 108, the infusion device 102 can be made with more simplified electronics. However, in other embodiments, the infusion device 102 may include all control functions and may operate without the CCD 106 and / or the computer 108. In various embodiments, the CCD 106 may be a portable electronic device. In addition, in various embodiments, the infusion device 102 and / or the sensing arrangement 104 may be configured to transmit data to the CCD 106 and / or the computer 108 for display or processing of the data by the CCD 106 and / or the computer 108.

[0052] In some embodiments, the CCD 106 and / or computer 108 can provide information to the user that facilitates the user's subsequent use of the infusion device 102. For example, the CCD 106 can provide information to the user to allow the user to determine the rate or dosage of the drug to be applied to the user's body. In other embodiments, the CCD 106 can provide information to the infusion device 102 to autonomously control the rate or dosage of the drug applied to the user's body. In some embodiments, the sensing arrangement 104 can be integrated into the CCD 106. Such embodiments can allow the user to monitor the condition by providing a sample of, for example, his or her blood to the sensing arrangement 104 to assess his or her condition. In some embodiments, the sensing arrangement 104 and the CCD 106 can be used to determine the glucose level in the user's blood and / or body fluids without using or requiring a wire or cable connection between the infusion device 102 and the sensing arrangement 104 and / or the CCD 106.

[0053] In some embodiments, the sensing arrangement 104 and / or the infusion device 102 are cooperatively configured to utilize a closed loop system to deliver fluid to a user. Examples of sensing devices and / or infusion pumps utilizing a closed loop system can be found in, but are not limited to, U.S. Patent Nos. 6,088,608, 6,119,028, 6,589,229, 6,740,072, 6,827,702, 7,323,142, and 7,402,153 or U.S. Patent Application Publication No. 2014 / 0066889, all of which are incorporated herein by reference in their entirety. In such embodiments, the sensing arrangement 104 is configured to sense or measure a condition of the user, such as a blood sugar level, etc. The infusion device 102 is configured to deliver fluid in response to a condition sensed by the sensing arrangement 104. In turn, the sensing arrangement 104 continues to sense or otherwise quantify the user's current condition, thereby allowing the infusion device 102 to continue to deliver fluid indefinitely in response to the condition currently (or most recently) sensed by the sensing arrangement 104. In some embodiments, the sensing arrangement 104 and / or infusion device 102 may be configured to utilize the closed-loop system only during a portion of the day (e.g., only when the user is asleep or awake).

[0054] Figure 2 2 is a simplified block diagram representation of an exemplary embodiment of a communication system 200 that is appropriately configured to support the techniques and methods described in more detail below. The system 200 supports users of insulin infusion devices and implements various techniques and methods to help users (patients, caregivers, healthcare providers, parents, etc.) manage the use of insulin infusion devices. It should be understood that Figure 2 One possible implementation of the communication system is depicted, and other arrangements, architectures, and deployments may be provided if desired. The system 200 (which has been simplified for purposes of illustration) generally includes, but is not limited to, or cooperates with the following components: a mobile device 204; an insulin infusion device 206; a blood glucose meter 208; a continuous glucose sensor 210; and an optional data uploader 212. The mobile device 204 is a client device owned or operated by a user (i.e., a diabetic patient). The insulin infusion device 206, the blood glucose meter 208, and the glucose sensor 210 are components of an insulin infusion system used by a patient to treat diabetes. The system 200 may also include or cooperate with an optional data uploader component 212.

[0055] The various components of the system 200 can be used to collect and analyze the patient's input data from various sources, including an insulin infusion device, a glucose sensor or a blood glucose meter, a mobile device operated by a user of the insulin infusion device, or other components or computing devices compatible with the system, such as a data uploader. The present disclosure contemplates these and other alternative arrangements. To this end, some embodiments of the system may include additional devices and components that act as data sources, data processing units, etc. For example, the system may include, but is not limited to, any one or all of the following elements: a computer device or system; a patient monitor; a healthcare provider system; a data communication device; and the like. It should be understood that in some applications (e.g., for patients with type 2 diabetes), the insulin infusion device 206 may be an optional component. For such applications, another diabetes management device and / or mobile device 204 may operate in an equivalent manner to support the system 200.

[0056] At least, the mobile device 204 is communicatively coupled to the network 214. In certain embodiments, the insulin infusion device 206, the blood glucose meter 208, and / or the continuous glucose sensor 210 are also communicatively coupled to the network 214 to facilitate uploading relevant data to a remote server system (not shown). Alternatively or additionally, the insulin infusion device 206, the blood glucose meter 208, and the continuous glucose sensor 210 provide relevant data to the data uploader component 212, which in turn uploads the data to other systems (not shown) via the network 214.

[0057] Figure 2 The network 214 is depicted in a simplified manner. In practice, the system 200 may cooperate with and utilize any number of wireless data communication networks and any number of wired data communication networks maintained or operated by various entities and providers. Thus, communications between the various components of the system 200 may involve multiple network links and different data communication protocols. In this regard, the network 214 may include, but is not limited to, or cooperate with any of the following: a local area network; a wide area network; the Internet; a personal area network; a cellular communication network; a satellite communication network; a video service or television broadcast network; an in-vehicle network; and the like. In addition, the various components may also communicate directly with each other using NFMI radio communications; NFeMI radio communications, Communications, Traditional (BT) communication, WLAN (or "Wi-Fi") communication, or indirectly communicate with each other using WLAN or cellular communication, as will be described below. The components of the system can be appropriately configured to support various wireless data communication protocols and wired data communication protocols, technologies and technologies required for compatibility with network 214.

[0058] The mobile device 204 may be implemented using a variety of different device platforms. For example, the mobile device 204 may be implemented as, but not limited to, any of the following: a cellular phone or smartphone; a portable computer (e.g., a laptop, tablet, or netbook computer); a portable media player; a portable video game device; a portable medical device; a navigation device, such as a global positioning system (GPS) device; a wearable computing device; an electronic toy or game; etc. According to certain exemplary embodiments, the mobile device 204 supported by the system 200 is implemented as a computer-based or processor-based component. For simplicity and ease of description, Figure 2 Only one mobile device 204 is depicted. However, in practice, the system 200 is suitably configured to support multiple mobile devices 204, wherein the patient or user owns or operates at least one of the supported mobile devices 204. Figure 3 Exemplary embodiments of devices suitable for implementing mobile device 204 are described.

[0059] The remainder of this specification assumes that the mobile device 204 is a smartphone used by a particular patient. To this end, the configuration and general functionality of the mobile device 204 can be substantially consistent with a conventional smartphone design. In this regard, a properly designed mobile application is installed on the mobile device 204 to allow the patient to receive, view and interact with messages and notifications provided by the system. The mobile application installed on the mobile device 204 can also be used to provide relevant data to other systems (not shown) for storage and analysis. For example, the mobile application can be, but is not limited to, managing and uploading the following information: calendar data (time, day of the week, month, quarter, etc.); user profile data; GPS data indicating the geographic location of the mobile device 204; map or navigation data associated with the operation of the mobile device 204; dietary consumption, food content and / or food ingredient data entered by the user; carbohydrate data entered by the user; exercise-related data entered by the user; medication-related data entered by the user; user response data associated with the reception of blood glucose insight messages; user feedback related to blood glucose insight messages; accelerometer data; contact list information; web browser data; consumer purchase data; and the like.

[0060] In some embodiments, the insulin infusion device 206 is a portable patient-worn or patient-carried component that is operated to deliver insulin to the patient through, for example, an infusion set. According to some exemplary embodiments, each insulin infusion device 206 supported by the system 200 is implemented as a computer-based or processor-based component. For simplicity and ease of description, Figure 2Only one insulin infusion device 206 is depicted. However, in practice, the system 200 is suitably configured to support multiple insulin infusion devices 206, with each patient or user owning or operating at least one of the insulin infusion devices 206. Figure 3 An exemplary embodiment of a device suitable for implementing the insulin infusion device 206 is described.

[0061] The system 200 obtains input data from one or more sources, which may include various diabetes management devices (insulin infusion devices, continuous glucose monitoring devices, glucose sensors, monitoring devices, etc.). In this regard, the insulin infusion device 206 represents an input data source for the system 200. In certain embodiments, the insulin infusion device 206 provides data associated with its operation, status, insulin delivery events, etc. As previously described, depending on the specific embodiment of the system 200, the relevant data generated or collected by the insulin infusion device 206 can be transmitted directly or indirectly to other components of the system, including the data uploader component 212. The specific types of data provided by the insulin infusion device 206 are described in more detail below.

[0062] The patient or user may own or operate a blood glucose meter 208. The blood glucose meter 208 is configured to measure the user's blood glucose level by analyzing a blood sample. For example, the blood glucose meter 208 may include a container for receiving a blood sample test strip. In this regard, the user inserts the test strip into the blood glucose meter 208, which analyzes the sample and displays the blood glucose level corresponding to the test strip sample. The blood glucose meter 208 may be configured to transmit the measured blood glucose level to the insulin infusion device 206 for storage and processing, to the mobile device 204, or to a data uploader component 212. In some cases, the patient is responsible for inputting each blood glucose measurement result into the insulin infusion device 206. Finally, the measured blood glucose data may be provided to any component of the system for analysis.

[0063] The glucose sensor 210 may be owned or operated by a patient or user. The glucose sensor 210 is appropriately configured to measure the patient's glucose level (interstitial) in real time. The glucose sensor 210 may include a wireless transmitter that facilitates transmission of the sensor glucose data to other devices, such as the insulin infusion device 206 or the data uploader component 212 or other components of the system, where the sensor glucose data may be received for further processing.

[0064] Depending on the particular embodiment and application, the system 200 may include or cooperate with other devices, systems, and input data sources. The devices within the system 200 may be configured to support the transmission of data to various external devices, such as, but not limited to: a fixed monitoring device, such as a bedside monitor or hospital monitoring equipment; a portable computer, such as a laptop PC, a palmtop PC, or a tablet PC; a fixed computer, such as a desktop PC; a personal digital assistant, which may also be a portable email device; one or more additional computing devices or databases; and the like. The above list of possible external devices is not exhaustive, and embodiments of the system 200 may be designed to accommodate communication with other systems, devices, computing devices, components, and elements external to the system 200. For example, in some embodiments, the system 200 includes one or more sources of contextual information or data, which may include, but are not limited to: an activity tracker device; a meal logging device or application; a mood tracking device or application; and the like.

[0065] System 200 includes a local infusion system having one or more local devices configured to communicate wirelessly with each other. The local infusion system may be referred to herein as a "personal area network" or "body area network" of its component devices. These local devices may be configured to transmit and receive local communications within the local infusion system, wherein such local communications are transmitted and received according to one or more specified local data communication protocols. For example, local communications may be exchanged between local devices using one or more wireless data communication protocols (which may utilize RF, infrared, magnetic induction, or other wireless technologies) and / or using one or more wired data communication protocols. Therefore, in the context of the present specification, one or more local devices may be considered to be wireless medical devices. The local infusion system may be flexibly configured such that any given local device may communicate with any other local device, and the communication link or path between two local devices may be unidirectional or bidirectional. Figure 2 An exemplary embodiment is depicted in which each communication link or path is bi-directional (indicated by double-headed arrows).

[0066] In addition, a local device in a local infusion system can communicate (unidirectionally or bidirectionally) with one or more "external" devices that are not considered part of the local infusion system. The manner in which a given local device within a local infusion system communicates with a given external device may vary depending on the particular configuration of the system 200, the characteristics of the local device, and the characteristics of the external device. For example, data may be routed between the local infusion system and the external device using one data communications network, using multiple data communications networks, using direct wireless or wired connections, etc.

[0067] As described above, the system 200 includes or cooperates with computer-based and / or processor-based components having appropriately configured hardware and software that are written to perform the functions and methods required to support the features described herein. For example, the mobile device 204, the insulin infusion device 206, the blood glucose meter 208, and the data uploader component 212 can be implemented as processor-based electronic components. Figure 3 Describes exemplary embodiments of apparatus suitable for implementing the various components of the system. In this regard, Figure 3 Suitable for deployment in Figure 2 A simplified block diagram representation of an exemplary embodiment of a computer-based or processor-based device 300 in the system is shown.

[0068] The illustrated embodiment of the device 300 is intended as a high-level and general representation of a suitable platform. In this regard, any computer-based or processor-based component of the system 200 can utilize the architecture of the device 300. The illustrated embodiment of the device 300 generally includes, but is not limited to: at least one processor 302; an appropriate amount of memory 304; device-specific hardware, software, firmware and / or features 306; a user interface 308; a communication module 310; and a display element 311. Of course, embodiments of the device 300 may include additional elements, components, modules, and functions that are configured to support various features unrelated to the subject matter described herein. For example, the device 300 may include certain features and elements to support conventional functions that may be related to a specific embodiment and deployment of the device 300. In practice, the elements of the device 300 may be coupled together via a bus or any suitable interconnect architecture 301.

[0069] The processor 302 may be implemented or executed using a general purpose processor, a content addressable memory, a digital signal processor, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. In addition, the processor 302 may be implemented as a combination of computing devices, for example, a combination of a digital signal processor and a microprocessor, a combination of multiple microprocessors, a combination of one or more microprocessors and a digital signal processor core, or any other such configuration.

[0070] Memory 304 can be implemented as RAM memory, flash memory, EPROM memory, EEPROM memory, register, hard disk, removable disk, CD-ROM or any other form of storage medium known in the art. In this regard, memory 304 can be coupled to processor 302 so that processor 302 can read information from memory 304 and write information to the memory. In an alternative, memory 304 can be integrated with processor 302. As an example, processor 302 and memory 304 can reside in an ASIC. At least a portion of memory 304 can be implemented as a computer storage medium, such as a tangible computer-readable medium having computer executable instructions stored thereon. When read and executed by processor 302, the computer executable instructions cause device 300 to perform certain tasks, operations, functions and processes that are specific to a particular embodiment. In this regard, memory 304 can represent a suitable embodiment of such a computer-readable medium. Alternatively or additionally, the apparatus 300 may receive and cooperate with a computer-readable medium (not separately shown) implemented as a portable or mobile component or platform, such as a portable hard drive, USB flash drive, optical disk, or the like.

[0071] The device-specific hardware, software, firmware, and features 306 may vary from one embodiment of the device 300 to another. For example, the device-specific hardware, software, firmware, and features 306 will support: smartphone functions and features when the device 300 is implemented as a mobile phone; traditional personal computer functions and features when the device 300 is implemented as a laptop or tablet computer; insulin pump operation when the device 300 is implemented as an insulin infusion device; etc. In practice, certain portions or aspects of the device-specific hardware, software, firmware, and features 306 may be implemented in a variety of different embodiments. Figure 3 and Figure 4 The invention may be implemented in one or more other blocks as shown.

[0072] The user interface 308 may include or cooperate with various features to allow a user to interact with the device 300. Thus, the user interface 308 may include various human-machine interfaces, such as keypads, keys, keyboards, buttons, switches, knobs, touch pads, joysticks, pointing devices, virtual tablets, touch screens, microphones, or any device, component, or function that enables a user to select options, input information, or otherwise control the operation of the device 300. The user interface 308 may include one or more graphical user interface (GUI) control elements that enable a user to manipulate or otherwise interact with an application through the display element 311.

[0073] The communication module 310 facilitates data communication between the device 300 and other components as needed during operation of the device 300. In the context of the present specification, the communication module 310 may be used to transmit or stream control data related to the device, data related to the patient, status or operational data related to the device, blood glucose insight messages and notifications, etc. It should be understood that the specific configuration and functionality of the communication module 310 may vary depending on the hardware platform and specific implementation of the device 300. Thus, the communication module 310 is used to obtain input data from various sources and send output data to the above referenced Figure 1 and 2 Other components or devices described. In practice, embodiments of the apparatus 300 may use various data communication protocols to support wireless data communication and / or wired data communication. For example, the communication module 310 may support one or more wireless data communication protocols, technologies, or methods, including but not limited to: RF; IrDA (infrared); (and other variations of the IEEE 802.15 protocol); IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or any other variation); direct sequence spread spectrum; frequency hopping spread spectrum; cellular / wireless / cordless telecommunication protocols; wireless home network communication protocols; paging network protocols; magnetic induction; satellite data communication protocols; wireless hospital or healthcare facility network protocols, such as those operating in the WMTS band; GPRS; and proprietary wireless data communication protocols, such as variations of wireless USB. In addition, the communication module 310 can support one or more wired / cable data communication protocols, including but not limited to: Ethernet; power line; home network communication protocols; USB; IEEE 2394 (Firewire); hospital network communication protocols; and proprietary data communication protocols. In a specific embodiment, the communication module 310 includes a far-field communication module and a body area network communication module, as well as a controller (not shown).

[0074] The far field communication module includes various far field communication interfaces that can be used to transmit electromagnetic signals to other devices that are part of the body area network. In this non-limiting example, the various far field communication interfaces may include but are not limited to Bluetooth Low Energy. Communication interface, classic (BT) communication interface, wireless local area network (WLAN) communication interface (e.g., Wi-Fi interface) and cellular communication interface. The above communication interfaces may comply with any known standards. For example, The communication interface can comply with any versions (e.g., versions 1.0 through 5.1) and any physical (PHY) layer specifications defined therein. 5.0 contains three PHY layer variations called LE 1M, LE 2M, and LE Coded. Each PHY variant has its own specific characteristics and is designed for a specific purpose. As another non-limiting example, The communication interface can follow The mesh networking protocol (defined in the Mesh Profile Specification and Mesh Model Specification adopted on July 13, 2017) is used for communication. Mesh network protocols are based on The protocol allows Radios conduct many-to-many communications.

[0075] When the signal from the far-field communication interface is transmitted by the antenna, it is attenuated over distance to the point where the signal cannot be effectively detected. This is called far-field transmission, and works well if the signal needs to be transmitted over long distances. However, far-field communication interfaces can be problematic if the wireless communication requires very low power and is limited to fairly short distances near body areas. Improper placement of the device close to the human body can result in detuned antenna input impedance, reduced antenna efficiency, and distorted antenna radiation patterns. Penetration of the electromagnetic signals generated by the far-field communication interface into the human body is another problem, as the electromagnetic signals can be rapidly absorbed and greatly attenuated due to the strong conductivity of human tissue. In addition, due to the presence of multiple far-field communication interfaces operating in the same frequency band (e.g., BT, Wi-Fi and ) coexistence, interference can be very large. Power consumption can also limit continuous operation. Finally, far-field communication interfaces can have potential security issues because electromagnetic signals can be intercepted and decrypted after propagating into free space.

[0076] On the other hand, the body area network communication module includes various near field communication interfaces, which can be used to transmit magnetic signals to other devices that are part of the body area network. In this non-limiting example, the various near field communication interfaces may include but are not limited to a near field magnetic induction (NFMI) radio communication interface, a near field electromagnetic induction (NFeMI) radio communication interface (not shown), a near field communication (NFC) interface, an RFID high frequency (HF) communication interface, and one or more low power wide area network (LPWAN) communication interfaces. The near field communication interface can provide a more reliable, safer and much lower power radio link in, on and near the human body.

[0077] For example, NFMI is a short-range wireless technology that uses tightly coupled magnetic fields to communicate between devices. NFMI enables human-friendly, reliable, secure and power-efficient wireless communications. As used herein, the term "near field magnetic induction (NFMI) radio communication system" may refer to a short-range wireless physical layer that communicates by coupling tightly, low-power, non-propagating magnetic fields between devices. A transmitter coil in one device can modulate a magnetic field measured by a receiver coil in another device. To explain further, in a NFMI-based communication system, the modulated signal emitted from the transmitter coil is in the form of a magnetic field. This magnetic field induces a voltage on the receiving coil, which in turn will be measured by the NFMI receiver. The NFMI radio communication system differs from other wireless communications in that most conventional wireless RF systems use antennas to generate, transmit and propagate electromagnetic waves, where all transmitted energy is designed to be radiated into free space. This type of transmission is called "far field". The NFMI system is designed to contain the transmitted energy within a local magnetic field. This magnetic field energy resonates around the communication system but is not radiated into free space. To explain further, with The power density of the NFMI signal decays at a rate inversely proportional to the distance to the sixth power compared to the second power of the signal. This means that for the same distance, if the two transmit powers are equal, the power density of the NFMI signal is The signal is 10,000 times weaker. This type of wireless transmission is called "near field." Various modulation schemes used in typical RF communications (e.g., amplitude modulation, phase modulation, and frequency modulation) can also be used in near-field magnetic induction communication systems.

[0078] As used herein, the term "near field electromagnetic induction (NFeMI) radio communication interface" may refer to a communication interface that can operate in the vicinity of the human body through a combination of magnetic and electric fields without using lateral radiated waves. Such NFeMI systems improve the signal link budget of wearable devices and extend their range to the entire human body. While RF wireless communication can be achieved by propagating RF plane waves in free space, NFeMI communications utilize non-propagating quasi-static fields.

[0079] As used herein, the term "near field communication (NFC)" may refer to a set of communication protocols and data exchange formats that enable two or more electronic devices (e.g., medical devices such as insulin pumps and portable devices such as smartphones) to establish communication with each other by placing them within a short separation range (e.g., 2 meters or less) of each other. NFC allows one-way and two-way communication between endpoints and is suitable for many applications. NFC uses electromagnetic induction between two loop antennas (located in the near field of each other) to effectively form an air-core transformer that allows them to exchange information. The NFC interface operates based on principles similar to the NFMI interface 322 and uses the same high frequency (HF) band. However, NFMI extends the range of NFC (e.g., from a distance of 1-4 inches for NFC to up to 9 feet for NFMI). At approximately 13MHz, NFMI uses time division to provide data rates of more than 400Kbps per channel, with up to 10 separate channels and 10 sub-channels per channel (e.g., 100 separate wireless links within a single WBAN). In one non-limiting embodiment, the NFC-enabled devices described herein can exchange information according to any NFC standard covering communication protocols and data exchange formats. NFC standards cover communication protocols and data exchange formats and are based on existing radio frequency identification (RFID) standards including ISO / IEC 14443. Standards include ISO / IEC 18092 and standards defined by the NFC Forum. In addition to the NFC Forum, the GSM Association (GSMA) group defines a platform for deploying the GSMA NFC standard in mobile phones.

[0080] RFID systems can operate in low frequency (LF), high frequency (HF) and ultra high frequency (UHF) bands, and can therefore be classified by the frequency band in which they operate: low frequency, high frequency and ultra high frequency. In addition, there are two broad systems - passive and active RFID. The LF band covers frequencies from 30KHz to 300KHz (for example, some LF RFID systems operate at 125KHz, while others operate at 134KHz). The RFID HF communication interface 326 can operate in the HF band ranging from 3 to 30MHz, with a communication range between 10cm and 1m. There are several HF RFID standards, such as the ISO 15693 standard for tracking items, and the ECMA-340 and ISO / IEC 18092 standards, ISO / IEC 14443A and ISO / IEC14443 standards for near field communication (NFC). The UHF band covers a range from 300 MHz to 3 GHz, and some UHF systems can have a range of up to 12 m, with faster data transfer rates than LF or HF. The UHF band is regulated by a single global standard called the ECPglobal Gen2 (ISO 18000-63) UHF standard.

[0081] The low power wide area network (LPWAN) communication interface may include an interface such as a long term evolution (LTE-M) communication interface for machines (LTE-Cat M1) and / or a narrowband-IoT (NB-IoT) communication interface (not shown). NB-IoT and LTE-M are two newer low power wide area (LPWA) technologies developed for IoT applications. Both protocols are protocols for low bandwidth cellular communications connected to Internet devices that need to transmit small amounts of data, with lower costs (hardware and subscriptions) and higher battery life.

[0082] The various communication interfaces described above are non-limiting and may be implemented in accordance with any known standard including those described above. However, it should be understood that the number of communication interfaces included as part of the communication module 310 may vary depending on the implementation.

[0083] A controller (not shown) may be configured to control which communication interfaces a device or component of the wireless body area network selects and uses to communicate data with other devices or components that are part of the wireless body area network. For example, the controller is configured to select which of the communication interfaces to use at any particular time, and to switch between enabling and using which of the communication interfaces a device or component of the wireless body area network enables and uses to communicate data with other devices or components that are part of the wireless body area network.

[0084] As will be described in more detail below, depending on the proximity of the device to the body area network, the controller can select any of a variety of communication interfaces for communicating with other devices that are part of the body area network. The controller can seamlessly switch between the various communication interfaces based on factors such as the quality of service of the communication link with the other device, the security type of data being transmitted to the other device, etc. In this regard, the quality of service can be measured using any standard quality of service performance metric (e.g., RSSI, packet loss, packet error rate (PER), bit rate, bit error rate, latency, throughput, transmission delay, availability, jitter, etc.) and compared to a threshold. The quality of service metric can also include metrics such as service response time, loss, signal-to-noise ratio, crosstalk, echo, interruptions, frequency response, etc. Quality of service (QoS) is a description or measurement of the overall performance of a service, particularly the performance seen by network users.

[0085] When the quality of service is greater than or equal to a threshold, the device may utilize a particular communication interface. When the quality of service is less than the threshold, the controller may then determine an appropriate communication interface to switch to that will achieve a desired quality of service greater than or equal to the threshold. Additionally, in some embodiments, once the controller determines that the quality of service on one of the communication interfaces is greater than or equal to the threshold, the controller may also determine the type of data being transmitted by the device, and if it is a high security data type, the controller may also limit the communication to one of the body area network communication interfaces such that the communication may only occur within a traceable security boundary defined by the body area network where the wireless energy is not degraded to a negligible level. In other words, when the type of data being transmitted is a high security data type, the controller will only utilize one of the body area network communication interfaces to help ensure the security of the data being transmitted.

[0086] Reference again Figure 3 , the display element 311 is appropriately configured to enable the device 300 to present and display various screens, insight messages, notifications, GUIs, GUI control elements, drop-down menus, auto-fill fields, text input fields, message fields, etc. Of course, the display element 311 can also be used to display other information during the operation of the device 300, as is well understood. It is worth noting that the specific configuration, operating characteristics, size, resolution, and functionality of the display element 310 can vary depending on the actual implementation of the device 300. For example, if the device 300 is a laptop computer, the display element 311 can be a relatively large monitor. Alternatively, if the device 300 is a cellular telephone device (e.g., a smart phone), the display element 311 can be a relatively small integrated display screen, such as a touch-sensitive screen.

[0087] Figure 4104 and / or the like. The present invention relates to a method 400 for verifying whether a communication link between a non-medical client device 108 and a medical device 102, 104 is established and for causing a notification to be issued at the non-medical client device 108 and / or the medical device 102, 104 when the communication link is not established in accordance with the disclosed embodiments. As a preliminary matter, it should be understood that the steps of the method 400 are not necessarily limiting. With reference to the method 400, steps may be added, omitted, and / or performed simultaneously without departing from the scope of the appended claims. It should be understood that the method 400 may include any number of additional or alternative tasks, Figure 4 The tasks shown in the method 400 need not be performed in the order shown, and the method 400 may be incorporated into a more comprehensive program or process having additional functionality not described in detail here. Furthermore, as long as the intended overall functionality remains intact, Figure 4 One or more of the tasks shown may potentially be omitted from an embodiment of method 400. It should also be understood that the method 400 shown may be stopped at any time. Method 400 is computer-implemented in that the various tasks or steps performed in conjunction with method 400 may be performed by software, hardware, firmware, or any combination thereof. For illustrative purposes, the following description of method 400 may refer to the above description of method 400 in conjunction with Figures 1 to 3 The components mentioned.

[0088] In some embodiments, some or all of the steps of the process and / or substantially equivalent steps are performed by executing processor-readable instructions stored or contained on a processor-readable medium. For example, in the following Figure 4In the description of the present invention, the non-medical client device 108 and the medical devices 102, 104 are described as performing various actions, tasks or steps, but it should be understood that this refers to the processing systems of these entities executing instructions to perform these various actions, tasks or steps. Depending on the implementation, the method 400 can be performed by an application at the non-medical client device 108 and / or an application at the medical devices 102, 104 to periodically check the status of the communication link between the non-medical client device 108 and the medical devices 102, 104 to ensure that the corresponding medical control application at each can communicate. Notifications related to treatment can be generated from the medical devices 102, 104. Both the medical devices 102, 104 and the non-medical client device 108 can confirm the communication link between them and notify the user if there is no communication link. If the communication link between the non-medical client device 108 and the medical device 102, 104 is insufficient (e.g., not established), one or more notifications, alerts, warnings, or alarms on the medical device 102, 104 may be activated to alert the user that the communication link between the non-medical client device 108 and the medical device 102, 104 is insufficient. As described above, the notifications, alerts, warnings, or alarms on the medical devices 102, 104 may be, for example, visual, tactile, and / or audio alarms. In some embodiments, the visual, tactile, and / or audio alarms may be implemented in a specific sequence of visual, audio, and tactile for different messages. For example, a pause after three flashes or vibrations to indicate that communication with the non-medical client device 108 is lost. In addition, in Figure 4 In the description of FIG. 1 , a specific example is described in which the non-medical client device 108 and / or the medical device 102, 104 are connected to the medical device 102 through the above reference Figures 1 to 3 Other elements of the described system interact to perform certain actions.

[0089] The communication link verification method 400 begins at 402, where the link verification process begins and the method 400 proceeds to 404. At 404, the application determines whether a triggering event has occurred. The triggering event can be, for example, receiving an indication that an alarm has been issued or needs to be acknowledged; receiving an indication that a notification, alarm, warning, or alert needs to be activated; receiving an indication that a link verification timer has expired; receiving an indication that a link verification counter has a count greater than or equal to a threshold count; receiving an indication that a regularly scheduled data transmission (e.g., blood glucose or confirmation of the last insulin delivery) has not occurred, etc. At 404, the method 400 loops until the triggering event occurs, and then proceeds to 406.

[0090] At 406, the application determines whether a communication link between the non-medical client device 108 and the medical device 102, 104 is established or sufficient (e.g., whether the medical control application 107 running on the non-medical client device 108 is able to communicate with the medical control application 105 running on the medical device 102, 104). When the application determines (at 406) that a sufficient communication link is established between the non-medical client device 108 and the communication interface of the medical device 102, 104, the method 400 loops back to 402. In one embodiment, when it is determined (at 406) that the non-medical client device 108 and the medical device 102, 104 have a sufficient communication link, a timer or counter may be reset.

[0091] When the application determines (at 406) that the communication link is insufficient, the method 400 proceeds to 408, where the application at the non-medical client device 108 or medical device 102, 104 attempts to establish (or reestablish) a communication link between the communication interface of the medical device 102, 104 and the non-medical client device 108. The method 400 then proceeds to 410, where the application determines whether the communication link is successfully established. When the application determines (at 410) that the communication link is successfully established, the method 400 loops back to 402.

[0092] When the application determines (at 410) that the communication link was not successfully established, the method 400 proceeds to 412, where the application at the non-medical client device 108 and / or the application at the medical device 102, 104 causes one or more notifications, alerts, alarms, or warnings to be activated at the non-medical client device 108, and / or the medical device 102, 104 causes one or more notifications, alerts, alarms, or warnings to be activated at the medical device 102, 104. Since the non-medical client device 108 can be separated from the patient, the medical device 102, 104 should be able to perform an examination and issue a notification if necessary. In the case where the system is programmed to also notify the caregiver or healthcare provider through the cloud, having a non-medical client device 108 in the system may be critical.

[0093] Figure 5 The present invention is a method 500 for verifying the normal operation / functioning of a non-medical client device and a medical control application according to the disclosed embodiments. As a preliminary matter, it should be understood that the steps of the method 500 are not necessarily limiting. With reference to the method 500, steps may be added, omitted, and / or performed simultaneously without departing from the scope of the appended claims. It should be understood that the method 500 may include any number of additional or alternative tasks, Figure 5The tasks shown in the method 500 need not be performed in the order shown, and the method 500 may be incorporated into a more comprehensive program or process having additional functionality not described in detail here. Furthermore, as long as the intended overall functionality remains intact, Figure 5 One or more of the tasks shown may potentially be omitted from an embodiment of method 500. It should also be understood that the method 500 shown may be stopped at any time. Method 500 is computer-implemented in that the various tasks or steps performed in conjunction with method 500 may be performed by software, hardware, firmware, or any combination thereof. For illustrative purposes, the following description of method 500 may refer to the above description of method 500 in conjunction with the present invention. Figures 1 to 3 The components mentioned.

[0094] In some embodiments, some or all of the steps of the process and / or substantially equivalent steps are performed by executing processor-readable instructions stored or contained on a processor-readable medium. For example, in the following Figure 5 In the description of , the non-medical client device 108 and the medical devices 102, 104 are described as performing various actions, tasks, or steps, but it should be understood that this refers to the processing systems of these entities executing instructions to perform these various actions, tasks, or steps. Depending on the implementation scheme, the method 500 can be performed by the non-medical client device 108 and / or the application at the medical devices 102, 104. In one embodiment, the method 500 can be initiated by the non-medical client device 108 to perform one or more diagnostic checks to ensure that the medical control application at the non-medical client device 108 is operating properly and accessing the required resources for its normal function. The method 500 can be used to generate a notification at the non-medical client device 108 to alert the user when the medical control application 107 of the non-medical client device 108 is not operating / functioning properly (for example, is not operating properly or cannot access the resources required for its normal function). In addition, in Figure 5 In the description of FIG. 1 , a specific example is described in which the non-medical client device 108 and / or the medical device 102, 104 are connected to the medical device 102 through the above reference Figures 1 to 3 Other elements of the described system interact to perform certain actions.

[0095] The method 500 begins at 502, where the application begins an application verification process. At 504, the application monitors for a triggering event by determining whether a triggering event has occurred. The triggering event can be, for example, receiving an indication that an alarm has been issued or needs to be acknowledged; receiving an indication that a notification, alarm, warning, or alert needs to be activated; receiving an indication that an application verification timer has expired; receiving an indication that an application verification counter has a count greater than or equal to a threshold count; receiving an indication or finding that a communication link between a medical device and a non-medical device is not operating or transmitting as expected, etc. The method 500 loops at 504 until a triggering event occurs, and then proceeds to 506.

[0096] When it has been determined that a triggering event has occurred (at 504), the application initiates an application verification protocol at 506 to verify that the application is operating / functioning properly and / or accessing required computing resources. The application verification protocol may include running one or more diagnostic checks. The diagnostic checks may be used to verify that the application is operating / functioning properly and / or accessing required computing resources.

[0097] The diagnostic check performed or executed at 506 may include: verifying that a communication link between the non-medical client device 108 and the medical devices 102, 104 is established (as described above with reference to Figure 4 Determine whether the application and / or the operating system version is up to date and / or authentic; determine whether the application is set up correctly; determine whether the application is loaded normally; determine whether the application is running normally; determine whether the application has access to sufficient computing resources (e.g., processing resources, communication resources, user interface resources, and / or memory resources) of the device; determine whether the application has access to sufficient computing resources (e.g., processing resources, communication resources, user interface resources, and / or memory resources) of the non-medical client device 108, etc. For example, the medical device 102, 104 should satisfy the normal operation of the application and access resources such as a processor, memory, speaker, camera flash, display, tactile or other vibrator, or other means for generating notifications. If the medical device 102, 104 does confirm this, it should notify the user through its own notification means. The number of diagnostic checks performed and the order in which they are performed can vary depending on the implementation.

[0098] In one embodiment, the diagnostic checks may be performed in parallel or simultaneously or nearly simultaneously. In another embodiment, the diagnostic checks may be performed sequentially (in a predetermined order). For example, after initiating the application verification protocol at 506, steps 506 to 512 are iteratively performed to run a series of diagnostic checks, which are used to determine whether the application is running or operating / functioning normally and / or accessing the required computing resources. In the first iteration of 506, the first diagnostic check is performed. At 508, the application determines whether the application has passed the first diagnostic check, and if so, the method 500 proceeds to 512, where the application determines whether there are any additional diagnostic checks to be performed. If it is determined (at 512) that there are no additional diagnostic checks to be performed, the method 500 proceeds to 514. When it is determined (at 512) that there are additional diagnostic checks to be performed, the method 500 loops back to 506, where the application performs the next diagnostic check to determine whether the application is operating / functioning normally and / or accessing the required computing resources. In one embodiment, steps 506 to 512 loop until all diagnostic checks have been performed.

[0099] Whenever the application determines at 508 that the application failed a particular diagnostic check performed (at 506), method 500 may proceed to 510, where the problem corresponding to the particular diagnostic check is logged to create a record explaining why the application did not operate / function properly and / or was unable to access required computing resources, and the method then proceeds to 512. When it is determined (at 512) that there are no additional diagnostic checks to perform, method 500 proceeds to 514.

[0100] At 514, the application attempts to initiate one or more remedial corrective actions to attempt to correct the problem that caused it to operate abnormally so that the application will function correctly and / or access the required computing resources. The remedial corrective actions taken (at 514) may vary depending on the implementation, and which diagnostic checks are performed or executed at 506, and which of those checks are determined to have failed (no at 508). The remedial corrective actions taken (at 514) may include, for example: automatically closing and restarting the application; prompting the user to change the application to restart the non-medical client device when it is determined that the application is not loaded or is not operating properly; automatically shutting down the device power, restarting the device and reopening the application; downloading and installing the latest version of the application or operating system when it is determined that the existing version is incorrect (e.g., not up to date and / or trusted); prompting the user to change one or more settings of the application when it is determined that one or more settings of the application are incorrect; releasing additional computing resources used by the application when it is determined that the application cannot access sufficient computing resources; changing settings at the non-medical client device 108 (e.g., changing settings through the operating system of the non-medical client device 108), etc.

[0101] Whenever one of the remedial corrective actions is initiated (at 514), the method 500 determines whether the corrective action was successful at 516. Whenever any of the remedial corrective actions is determined (at 516) to be unsuccessful, this means that the application is not functioning properly and / or cannot access required computing resources, and the method 500 may proceed to 518, where the application causes a notification (e.g., a warning, alarm, or other alert signal) to be generated at the non-medical client device and / or at the medical device 102, 104. For example, a warning or notification may be issued at the infusion device 102. The warning or notification may be issued until the medical device 102, 104 is satisfied that the non-medical client device 108 and its corresponding application are functioning properly (e.g., able to communicate with the medical device 102, 104, issue notifications, etc.). In addition, in some embodiments, at 520, the non-medical client device 108 may present (e.g., via a display) a suggestion to the user to suggest changing a setting on the non-medical client device 108 to correct the problem. For example, the non-medical client device 108 may display suggested changes to notification settings, allow access to location data, activity data, the microphone of the non-medical client device 108, or provide a shortcut or link to the settings that need to be changed. If a medical device 102, 104 fails, the non-medical client device 108 may suggest actions based on the last uploaded data such as insulin on board, last bolus, BG, etc. The suggestion may include instructions on how to use an insulin pen or syringe until the pump can be replaced. The non-medical client device 108 may also send a notification to a caregiver or healthcare provider (HCP).

[0102] When it is determined (at 514 ) that each of the corrective actions performed were successful, meaning that the application is operating normally and / or accessing required computing resources, the method 500 loops back to 504 .

[0103] Figure 6 600 is a method 600 for generating a notification (alarm, warning or other alert signal) at a medical device 102, 104 when a notification generated at a non-medical client device 108 is not acknowledged in accordance with the disclosed embodiments. As a preliminary matter, it should be understood that the steps of method 600 are not necessarily limiting. With reference to method 600, steps may be added, omitted, and / or performed simultaneously without departing from the scope of the appended claims. It should be understood that method 600 may include any number of additional or alternative tasks, Figure 6 The tasks shown in the method 600 need not be performed in the order shown, and the method 600 may be incorporated into a more comprehensive program or process having additional functionality not described in detail herein. Furthermore, as long as the intended overall functionality remains intact, Figure 6One or more of the tasks shown may potentially be omitted from an embodiment of method 600. It should also be understood that the method 600 shown may be stopped at any time. Method 600 is computer-implemented in that the various tasks or steps performed in conjunction with method 600 may be performed by software, hardware, firmware, or any combination thereof. For illustrative purposes, the following description of method 600 may refer to the above description of method 600 in conjunction with Figures 1 to 3 The components mentioned.

[0104] In some embodiments, some or all of the steps of the process and / or substantially equivalent steps are performed by executing processor-readable instructions stored or contained on a processor-readable medium. For example, in the following Figure 6 In the description of , the non-medical client device 108 and the medical devices 102, 104 are described as performing various actions, tasks, or steps, but it should be understood that this refers to the processing systems of these entities executing instructions to perform these various actions, tasks, or steps. The method 600 can be performed by the non-medical client device 108 and the application at the medical devices 102, 104. The method 600 can be used to generate a notification (e.g., a tactile signal, a visual signal, and / or an audio signal) related to treatment at the medical device 102, 104 to alert the user when an alarm or warning generated at the non-medical client device 108 is not acknowledged within a predetermined time threshold. In addition, in Figure 6 In the description of FIG. 1 , a specific example is described in which the non-medical client device 108 and / or the medical device 102, 104 are connected to the medical device 102 through the above reference Figures 1 to 3 Other elements of the described system interact to perform certain actions.

[0105] To further explain, when a notification (alarm, warning or other alert signal) is generated at a non-medical client device of a user, method 600 begins at 602 (which may be Figure 5 518 of step 518). The method 600 then proceeds to 604, where the application at the non-medical client device 108 starts a counter for the warning escalation process, and the method then proceeds to 606. At 606, the application at the non-medical client device 108 determines whether the notification at the non-medical client device 108 (generated at 602) is confirmed within a certain time frame. When it is determined that the notification at the non-medical client device 108 (generated at 602) is confirmed within the certain time frame, the method 600 proceeds to 608, where the method 600 ends. When it is determined that the notification at the non-medical client device 108 (generated at 602) is not confirmed within the certain time frame, the method 600 proceeds to 610.

[0106] At 610, the application at the non-medical client device 108 determines whether the counter for the warning escalation process is greater than or equal to the threshold count. The process at 610 loops back to 606 until the counter for the warning escalation process is determined (at 610) to be equal to the threshold count. In other words, when the application determines (at 610) that the counter has not reached the threshold (e.g., the count of the counter is less than the threshold), the method 600 loops back to 606.

[0107] When the counter for the alarm escalation process is determined (at 610) to be equal to the threshold count, the method 600 proceeds to 612, where the application causes a notification (e.g., an alarm or warning) to be generated at the medical device 102, 104. In one embodiment, the medical control application 105 at the medical device 102, 104 causes a notification (e.g., a warning or alarm, such as a tactile signal, a visual signal, and / or an audio signal) to be generated at the medical device 102, 104. In one embodiment, if the user does not confirm the notification, the application may also activate haptics, a camera flash, an override silent mode, and increase the speaker or alarm volume at the non-medical client device 108. The method 600 proceeds to 614, where the method 600 ends. The notification is used to alert the user that the notification generated at the non-medical client device 108 has not been confirmed, so that the user can then take remedial action at the non-medical client device 108 so that the application of the non-medical client device 108 operates / functions normally.

[0108] Therefore, the medical device 102, 104 should initiate a system check of the non-medical client device 108. If the non-medical client device 108 is not functioning properly and cannot be secured automatically or by the patient, a notification through the non-medical client device 108 should be generated. If the patient does not confirm the notification on the non-medical client device 108, the medical device 102, 104 should notify the patient. When the notification generated by the medical device 102, 104 is not generated at the non-medical client device 108 (due to a problem at the non-medical client device 108), the application 107 at the non-medical client device 108 can confirm whether the notification has been confirmed and send a confirmation to the medical device 102, 104. If the non-medical client device 108 cannot confirm that the notification was issued, it should attempt to correct it by checking the settings to see if it has access to the resource (speaker, haptics, etc.), and if not, suggesting a corrective action. If the corrective action is unsuccessful, a notification can be generated at one or more of the medical devices 102, 104. If an acknowledgment is not received from the non-medical client device 108 within a reasonable time that may vary depending on the criticality of the notification, the medical device 102, 104 may notify the user. For example, a warning time from the medical device 102, 104 to perform a blood glucose check may allow the non-medical client device 108 more time to return to confirm or correct the problem. For critical alerts such as an in-line blockage, the time allowed may be shorter.

[0109] Although at least one exemplary embodiment has been presented in the foregoing detailed description, it should be understood that there are a large number of variations. It should also be understood that one or more exemplary embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. More precisely, the foregoing detailed description will provide a convenient guide for implementing one or more of the described embodiments to those skilled in the art. It should be understood that various changes may be made to the function and arrangement of the elements without departing from the scope defined by the claims, which are included in known equivalents and foreseeable equivalents at the time of filing this patent application.

Claims

1. A system, include: one or more processors; as well as One or more processor-readable media storing instructions that, when executed by the one or more processors, cause the following operations to be performed: generating a first notification via a medical application executed on a non-medical device; determining that the first notification has not been acknowledged within a predetermined time threshold; and A second notification is caused to be generated at a medical device controlled by the non-medical device and connected to the user's body to notify the user that the first notification has not been confirmed.

2. The system according to claim 1, in, The one or more processor-readable media further store instructions that, when executed by the one or more processors, cause the following operations to be performed: Based on determining that the first notification is not acknowledged within a predetermined time frame, verifying whether the medical application has access to a user interface resource of the non-medical device.

3. The system according to claim 2, in, The one or more processor-readable media further store instructions that, when executed by the one or more processors, cause the following operations to be performed: Based on verifying that the medical application does not have access to the user interface resource of the non-medical device, a speaker volume of the non-medical device is increased.

4. The system according to claim 2, in, The one or more processor-readable media further store instructions that, when executed by the one or more processors, cause the following operations to be performed: Based on verifying that the medical application does not have access to the user interface resource of the non-medical device, a silent mode of the non-medical device is overridden.

5. The system according to claim 2, in, The one or more processor-readable media further store instructions that, when executed by the one or more processors, cause the following operations to be performed: Based on verifying that the medical application does not have access to the user interface resource of the non-medical device, activating a haptic sensation at the non-medical device.

6. The system of claim 2, in, The one or more processor-readable media further store instructions that, when executed by the one or more processors, cause the following operations to be performed: Based on verifying that the medical application does not have access to the user interface resource of the non-medical device, a camera flash is activated at the non-medical device.

7. The system of claim 1, in, Determining that the first notification is not confirmed within the predetermined time threshold includes: Determines that a counter has reached a threshold count.

8. The system of claim 1, in, The second notification includes a tactile signal.

9. The system of claim 1, in, The second notification includes a visual signal.

10. The system of claim 1, in, The second notification includes an audio signal.

11. The system of claim 1, in, The medical device is an insulin delivery device.

12. The system of claim 1, in, The medical device is a glucose sensor arrangement.

13. A processor-implemented method, include: generating a first notification via a medical application executed on a non-medical device; determining that the first notification has not been acknowledged within a predetermined time threshold; A second notification is caused to be generated at a medical device controlled by the non-medical device and connected to the user's body to notify the user that the first notification has not been confirmed.

14. The method of claim 13, further comprising: include: Based on determining that the first notification is not acknowledged within a predetermined time frame, verifying whether the medical application has access to a user interface resource of the non-medical device.

15. The method of claim 14, further comprising: include: Based on verifying that the medical application does not have access to the user interface resource of the non-medical device, a speaker volume of the non-medical device is increased.

16. The method of claim 14, further comprising: include: Based on verifying that the medical application does not have access to the user interface resource of the non-medical device, a silent mode of the non-medical device is overridden.

17. The method of claim 14, further comprising: include: Based on verifying that the medical application does not have access to the user interface resource of the non-medical device, activating a haptic sensation at the non-medical device.

18. The method of claim 14, further comprising: include: Based on verifying that the medical application does not have access to the user interface resource of the non-medical device, a camera flash is activated at the non-medical device.

19. One or more processor-readable media storing instructions that, when executed by one or more processors, cause the following operations to be performed: generating a first notification via a medical application executed on a non-medical device; determining that the first notification has not been acknowledged within a predetermined time threshold; A second notification is caused to be generated at a medical device controlled by the non-medical device and connected to the user's body to notify the user that the first notification has not been confirmed.

Images