US20210060244A1 - 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 - Google Patents

Abstract

A method and system are provided 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. In accordance with the method, an application at the non-medical client device monitors for occurrence of a trigger event and when a trigger event is detected, the application can perform one or more diagnostic checks to verify whether a 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 can attempt to initiate one or more remedial correction measures to restore the medical control application so that it is operating correctly. When the one or more remedial correction measures were unsuccessful, the application causes the notification to be generated via a user interface of the non-medical client device.

Description

TECHNICAL FIELD
• Embodiments of the subject matter described herein relate generally to medical devices and medical device systems and, more specifically, to a method and medical device system, such as an insulin infusion system, for verifying whether a non-medical client device is operating correctly with a medical device controlled by the non-medical client device. A notification can be generated when one or more remedial correction measures are unsuccessful to restore the non-medical client device so that it is operating correctly.
BACKGROUND
• Wireless devices, such as cellular telephones, mobile computers, personal digital assistants, digital media players, portable video game devices, and the like, and related wireless communication techniques and protocols have become ubiquitous in modern society. More recently, portable medical devices having wireless data communication capabilities are becoming increasingly popular, especially for patients that have conditions that must be monitored on a continuous or frequent basis. For example, diabetics are usually required to modify and monitor their daily lifestyle to keep their body in balance, in particular, their blood glucose (“BG”) levels. Individuals with Type1 diabetes and some individuals with Type2 diabetes use insulin to control their BG levels. To do so, diabetics routinely keep strict schedules, including ingesting timely nutritious meals, partaking in exercise, monitoring BG levels daily, and adjusting and administering insulin dosages accordingly. Diabetics may utilize wireless medical devices that are deployed in a network environment in a manner that facilitates data communication between two or more separate devices.
• In the past, on-body medical devices, such as fluid infusion device (or infusion pump) and sensing arrangement (e.g., continuous glucose sensors), could be controlled using a custom controller device (CCD). Today, there is a growing trend towards controlling personal medical devices, such as insulin infusion devices that are worn by a patient, using a non-medical device such as a patient's smart phone, laptop or tablet. On-body medical devices can now be communicated with and controlled using a non-medical smart device (e.g., smartphone, tablet). One advantage of this approach is that is can eliminate the need for a patient to possess and use another distinct control device. This can make the cost of ownership lower. In addition, patients can be discreet in managing their disease, and use a familiar user interface and form-factor which shortens the learning curve. This can also provide connectivity to back end systems (e.g., cloud-based systems) that are used to monitor patients and control delivery of medication to a patient. Non-medical smart devices can upload data for analysis by health care providers (HCPs) and AI-based systems. Non-medical smart devices can also receive regular updates to therapy management software. For instance, these updates can update medical control application software (or key parameters thereof) to customize and improve therapy. Connectivity also provides the means to alert caregivers and HCPs in emergency situations when concerning trends are present. A medical control application can also use health related data from the non-medical smart device and other apps/systems to improve therapy for the patient.
• A number of insulin pump systems are designed to deliver accurate and measured doses of insulin via infusion sets (an infusion set delivers the insulin through a small diameter tube that terminates at a cannula inserted under the patient's skin). In lieu of a syringe, the patient can simply activate the insulin pump to administer an insulin bolus as needed, for example, in response to the patient's current BG level. A patient can measure his BG level using a BG measurement device, such as a test strip meter, a continuous glucose measurement system, or the like. BG measurement devices use various methods to measure the BG level of a patient, such as a sample of the patient's blood, a sensor in contact with a bodily fluid, an optical sensor, an enzymatic sensor, or a fluorescent sensor. When the BG measurement device has generated a BG measurement, the measurement is displayed on the BG measurement device. A continuous glucose monitoring system can monitor the patient's sensor glucose (SG) level (e.g., subcutaneous tissue glucose level) in real-time. This allows delivery of insulin to be calculated in real-time with dosage calculated in a software algorithm based on measured sensor glucose level, or a closed-loop algorithm.
• The insulin pump, continuous glucose monitoring (CGM) device, and other devices, such as a smartphone and a Blood Glucose Monitor (BGM), can be different parts of an insulin infusion system. The various devices that are part of the insulin infusion system can form a wireless body area network that can be used, for example, to exchange monitor and therapy (control) data among multiple medical devices that are either worn on or near a patient's body. For instance, therapy data such as measured glucose values (SG values) and therapy settings (parameters for bolus delivery) can be transferred wirelessly among devices within the body area network. Insulin pumps and CGM devices may also be configured to communicate with remote control devices, monitoring or display devices, BG meters, and other devices associated with such an infusion system. For example, a CGM sensor may include or cooperate with a wireless radio frequency (“RF”) transmitter that communicates with other devices that are part of an infusion system such as a handheld remote control (also called a command control device (CCD)) that communicates with the infusion pump device using wireless communication technologies such as classical Bluetooth® (BT) or Bluetooth Low Energy® (BLE) technologies.
• The insulin infusion device and the smartphone can both include displays and different types of alarms to alert a user when they are not operating correctly. For instance, with respect to the insulin infusion device, if a microcontroller of the insulin infusion device fails, a notification (e.g., a message on a display, an audible or visual alarm or other type of alert such as a vibration) can be activated to inform the user that their insulin infusion device is not operating correctly.
• While using non-medical devices such smartphones can provide a number of advantages, one risk from the perspective of medical device manufacturers is that a smartphone or other smart devices are a relatively open platform and not as controllable as a medical device.
• Accordingly, 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., smartphone or other smart device) is operating correctly with a wearable medical device (e.g., insulin infusion device) that is controlled by the non-medical client device. It would also be desirable to reduce risk associated with using a smartphone. Furthermore, other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background.
BRIEF SUMMARY
• In one embodiment, a method is provided 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. In accordance with the method, an application at the non-medical client device monitors for occurrence of a trigger event and when the non-medical client device detects occurrence of the trigger event, the application at the non-medical client device can perform one or more diagnostic checks to verify whether a 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 correction measures to restore the medical control application so that it is operating correctly, and when the one or more remedial correction measures were unsuccessful, the application at the non-medical client device causes the notification to be generated via a user interface of the non-medical client device.
• In one embodiment, the notification can be a first notification, and after causing the first notification to be generated via the user interface of the non-medical client device, a counter can be started at the non-medical client device. The application at the non-medical client device can then regularly determine whether an acknowledgement signal was generated to acknowledge the first notification. When a count of the counter exceeds a threshold count and no acknowledgement signal was generated to acknowledge the first notification, a second notification is caused to be generated via a second user interface of the medical device. The second notification is used to alert a user that the first notification generated at the non-medical client device has not been acknowledged so that other remedial measures can be taken at the non-medical client device.
• In one embodiment, the application at the non-medical client device can perform a communication link verification process, when the application at the non-medical client device detects occurrence of the trigger event, 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 haves a communication link to the medical device, it can attempt attempting to establish a communication link between the non-medical client device and the medical device. In one embodiment, a first notification is caused to be generated via the user interface of the non-medical client device when the attempt to establish the communication link between the non-medical client device and the medical device is unsuccessful, and when the attempt to establish the communication link between the non-medical client device and the medical device is unsuccessful, a second notification is caused to be generated via a second user interface of the medical device.
• In one embodiment, the application at the non-medical client device can initiate a verification protocol when the application at the non-medical client device detects occurrence of the trigger event. The verification protocol can include executing one or more diagnostic checks to verify whether the medical control application is functioning properly and has access to adequate computing resources. The computing resources may include processing resources, communication resources, user interface resources, and memory resources.
• In one embodiment, the trigger event comprises one or more of: receiving an indication that a notification needs to be acknowledged; 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 one embodiment, the one or more diagnostic checks to verify whether the medical control application is operating correctly comprise 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 loading properly; and determining whether the medical control application is running properly.
• In one embodiment, the one or more remedial correction measures attempt to correct issues that are causing the non-medical client device to run improperly so that the medical control application will function correctly and have access to required computing resources.
• In one embodiment, the one or more remedial correction measures comprise one or more of: automatically closing and restarting the medical control application; prompting the user to change restart the medical control application of the non-medical client device when it is determined that the medical control application is not loading or is not running properly; automatically powering the non-medical client device off, automatically restarting non-medical client device and reopening the medical control application; downloading and installing an up-to-date version of the medical control application or an up-to-date version of an operating system when it is determined that the existing versions were not correct; prompting the user to change one or more settings of the medical control application when it is determined that one or more settings of the medical control application are incorrect; and freeing up additional computing resources of the non-medical client device for use by the medical control application when it is determined that the medical control application does not have access to adequate computing resources.
• In one embodiment, the non-medical client device comprises: a smartphone, and the medical device comprises one of an insulin infusion device that is configured to be controlled via the medical control application executed at the smartphone, and a glucose sensor arrangement.
• In another embodiment, a non-medical client device is provided that is configured to execute a medical control application that controls a medical device. The non-medical client device comprises: at least one processor device; and a non-transitory processor-readable medium operatively associated with the at least one processor device. The processor-readable medium comprises executable instructions configurable 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 comprises: monitoring for occurrence of a trigger event via an application at the non-medical client device; performing, via the application at the non-medical client device when the application at the non-medical client device detects occurrence of the trigger event, one or more diagnostic checks to verify whether a medical control application at the non-medical client device is operating correctly; attempting to initiate one or more remedial correction measures via the application to restore the medical control application at the non-medical client device so that it is operating correctly when the application at the non-medical client device determines that the one or more diagnostic checks have failed; and causing, via the application, the notification to be generated via a user interface of the non-medical client device when the one or more remedial correction measures were unsuccessful.
• 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 that are part of the wireless body area network, the plurality of devices comprising: a non-medical client device and a medical device configured to be controlled by a medical control application executed by the non-medical client device. The non-medical client device comprises: a processor device; and a non-transitory processor-readable medium operatively associated with the processor device. The processor-readable medium comprises executable instructions configurable 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 comprises: monitoring for occurrence of a trigger event via an application at the non-medical client device; performing, via the application at the non-medical client device when the application at the non-medical client device detects occurrence of the trigger event, one or more diagnostic checks to verify whether a medical control application at the non-medical client device is operating correctly; attempting to initiate one or more remedial correction measures via the application to restore the medical control application at the non-medical client device so that it is operating correctly when the application at the non-medical client device determines that the one or more diagnostic checks have failed; and causing, via the application, the notification to be generated via a user interface of the non-medical client device when the one or more remedial correction measures were unsuccessful.
• In one embodiment, the notification is a first notification, and the method further comprises: starting a counter at the non-medical client device after causing the first notification to be generated via the user interface of the non-medical client device; regularly determining, via the application at the non-medical client device, whether an acknowledgement signal was generated to acknowledge the first notification; and causing a second notification to be generated via a second user interface of the medical device when a count of the counter exceeds a threshold count and no acknowledgement signal was generated to acknowledge the first notification. The second notification is used to alert a user that the first notification generated at the non-medical client device has not been acknowledged so that other remedial measures can be taken at the non-medical client device.
• In one embodiment, the trigger event comprises one or more of: receiving an indication that a notification needs to be acknowledged; 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. The one or more diagnostic checks to verify whether the medical control application is operating correctly comprise 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 loading properly; and determining whether the medical control application is running properly.
• In one embodiment, the application at the non-medical client device initiates a verification protocol when the application at the non-medical client device detects occurrence of the trigger event. The verification protocol comprises: executing one or more diagnostic checks to verify whether the medical control application is functioning properly and has access to adequate computing resources, wherein the computing resources include processing resources, communication resources, user interface resources, and memory resources.
• In one embodiment, the one or more remedial correction measures attempt to correct issues that are causing the non-medical client device to run improperly so that the medical control application will function correctly and have access to required computing resources. The one or more remedial correction measures comprise one or more of: automatically closing and restarting the medical control application; prompting the user to change restart the medical control application of the non-medical client device when it is determined that the medical control application is not loading or is not running properly; automatically powering the non-medical client device off, automatically restarting non-medical client device, and reopening the medical control application; downloading and installing an up-to-date version of the medical control application or an up-to-date version of an operating system when it is determined that the existing versions were not correct; prompting the user to change one or more settings of at least one of the medical control application, the non-medical client device or an operating system of the non-medical client device when it is determined that one or more settings of the medical control application are incorrect; and freeing up additional computing resources of the non-medical client device for use by the medical control application when it is determined that the medical control application does not have access to adequate computing resources.
• This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. 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
• A more complete understanding of the subject matter may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures.
• FIG. 1 depicts an exemplary embodiment of an infusion system;
• FIG. 2 is a simplified block diagram representation of an exemplary embodiment of a communication system;
• FIG. 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.
• FIG. 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 a non-medical client device and/or a medical device when the communication link is not established in accordance with the disclosed embodiments;
• FIG. 5 is a method for verifying that a non-medical client device and a medical control application are operating/functioning properly in accordance with the disclosed embodiments; and
• FIG. 6 is 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
• The following detailed description is merely illustrative in nature and is not intended to limit the embodiments of the subject matter or the application and uses of such embodiments. As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any implementation described herein as exemplary is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary or the following detailed description.
• Techniques and technologies may be described herein in terms of functional and/or logical block components, and with reference to symbolic representations of operations, processing tasks, and functions that may be performed by various computing components or devices. Such operations, tasks, and functions are sometimes referred to as being computer-executed, computerized, software-implemented, or computer-implemented. It should be appreciated that the various block components shown in the figures may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. For example, an embodiment of a system or a component may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, look-up tables, or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices.
• When implemented in software, firmware, or processor-readable instructions, various elements of the systems described herein are essentially the code segments or instructions that perform the various tasks. In certain embodiments, the program or code segments are stored in a tangible processor-readable medium, which may include any medium that can store or transfer information. Examples of a non-transitory and processor-readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable ROM (EROM), a floppy diskette, a CD-ROM, an optical disk, a hard disk, or the like.
• Exemplary embodiments of the subject matter described herein are implemented in conjunction with medical devices, such as portable electronic medical devices. 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 infusion set operation, and other functional aspects of the systems (and the individual operating components of the systems) may not be described in detail here. Examples of infusion pumps may be of the type described in, but not limited to, U.S. Pat. Nos. 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 are herein incorporated by reference.
• Generally, a fluid infusion device includes a motor or other actuation arrangement that is operable to linearly displace a plunger (or stopper) of a fluid reservoir provided within the fluid infusion device to deliver a dosage of fluid, such as insulin, to the body of a user. Dosage commands that govern operation of the motor may be generated in an automated manner in accordance with the delivery control scheme associated with a particular operating mode, and the dosage commands may be generated in a manner that is influenced by a current (or most recent) measurement of a physiological condition in the body of the user. For example, in a closed-loop or automatic operating mode, dosage commands may be generated based on a difference between a current (or most recent) measurement of the interstitial fluid glucose level in the body of the user and a target (or reference) glucose setpoint value. In this regard, the rate of infusion may vary as the difference between a current measurement value and the target measurement value fluctuates. For purposes of explanation, the subject matter is described herein in the context of the infused fluid being insulin for regulating a glucose level of a user (or patient); however, it should be appreciated that many other fluids may be administered through infusion, and the subject matter described herein is not necessarily limited to use with insulin.
• Smart devices (e.g., smartphones) are devices that are available to the general public and have other uses beyond medical applications. Using such non-medical devices as part of a medical device system can provide a number of advantages. However, from the perspective of medical device manufacturers, one concern with using such non-medical devices to control medical devices is their open nature, reliability and security because smart devices are relatively open platforms and not as controllable as a medical device. Other than writing the code for a medical control application that is implemented on a patient's smart device, medical device manufacturers have little control of the patient's smart device to ensure that it is working correctly. For example, the medical device manufacturer does not write the operating system used by the smart device, has no control over installation of the most up-to-date software on the smart device (including the medical control application), cannot control what the user does to settings on the smart device, etc. For example, there is no way to ensure that a patient updates operating system (OS) software and other apps, or that a patient properly configures settings of the non-medical smart device. In addition, the availability of required computing resources on the non-medical smart device can affect functionality of the system. By contrast, because medical devices are is designed by device manufacturers there is more control over their operations and settings they are thus considered more reliable.
• In addition, users can control operation of their smart device and change settings (e.g., volume settings, wireless communication interface settings), etc. For example, users are responsible for controlling settings of their smart device, what other devices they are connected to, usage of computing resources, updates to the operating system or other application software (including what applications are installed and potentially conflict with a medical control application), etc. A need may arise to notify or alert the user (e.g., when the patient's blood glucose level goes low), but certain settings on the smart device may be set in a way that prevents this from happening. As an example, Bluetooth maybe in use for a phone call, speakers may be in use for listening to music, or the device's volume might be turned off. In short, this open nature of smart devices creates a potential risk that a medical control application executed at the smart device may not operate as intended.
• 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., smartphone or other smart device) is operating correctly with a wearable medical device (e.g., insulin infusion device) that is controlled by the non-medical client device. This system can reduce risk associated with using a smart device such as a smartphone, and increase the likelihood that a patient can continue to get notifications in the event that their smartphone, or the medical control application executed on their smartphone, fails. For instance, the system can allow patients to continue to receive alerts, alarms, and other warnings concerning their medical devices when needed even though their smart device (or non-medical device) may not be communicating them, or even though a medical control application that runs on their smart device is not operating as intended. For example, the system can allow patients to continue to receive alerts, alarms, and other warnings when a battery dies on the patient's smartphone, or when the user switches a communication interface (like a Bluetooth interface) so that it is linked to another device, or when the user turns the volume on smartphone off so that alarms generated by the application are not audible to the patient, or when the medical control application fails to operate as intended for any reason.
• In one embodiment, methods, systems and apparatus are provided 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. The medical device and the non-medical client device can be part of a wireless body area network for a medical device system, namely, an insulin infusion system. In accordance with 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, etc. For example, the non-medical client device can be smartphone, and the medical device can be an insulin infusion device that is configured to be controlled via the medical control application executed at the smartphone.
• In one embodiment, an application at the non-medical client device can monitor for occurrence of a trigger event, and when the application at the non-medical client device detects occurrence of the trigger event, the application at the non-medical client device can perform one or more diagnostic checks to verify whether a medical control application at the non-medical client device is operating correctly. For example, in one implementation, the trigger event can be one or more of: receiving an indication that a notification needs to be acknowledged; 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. Further, in one implementation, the one or more diagnostic checks can 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 loading properly; and determining whether the medical control application is running properly.
• When the application at the non-medical client device determines that the one or more diagnostic checks have failed (e.g., this can mean that the medical control application is not operating correctly), the application can attempt to initiate one or more remedial correction measures to restore the medical control application so that it is operating correctly. The one or more remedial correction measures attempt to correct issues that are causing the non-medical client device to run improperly so that the medical control application will function correctly and have access to required computing resources (e.g., memory, processing, user interfaces, communication interfaces, power sources/supplies, etc.). For example, in one implementation, the remedial correction measures can include one or more of: automatically closing and restarting the medical control application; prompting the user to change restart the medical control application of the non-medical client device when it is determined that the medical control application is not loading or is not running properly; automatically powering the non-medical client device off, automatically restarting non-medical client device and reopening the medical control application; downloading and installing an up-to-date version of the medical control application or an up-to-date version of an operating system when it is determined that the existing versions were not correct; prompting the user to change one or more settings of the medical control application when it is determined that one or more settings of the medical control application are incorrect; and freeing up additional computing resources of the non-medical client device for use by the medical control application when it is determined that the medical control application does not have access to adequate computing resources.
• When the one or more remedial correction measures are unsuccessful, the application causes a first notification to be generated via a user interface of the non-medical client device, and can start a counter after causing the notification to be generated. Thereafter, the application at the non-medical client device can regularly determine whether an acknowledgement signal was generated to acknowledge the notification. When a count of the counter exceeds a threshold count and no acknowledgement signal was generated to acknowledge the first notification, the application can cause a second notification to be generated via a second user interface of the medical device. The second notification is used to alert a user that thee first notification generated at the non-medical client device has not been acknowledged so that other remedial measures can be taken at the non-medical client device.
• For instance, in one implementation, the application at the non-medical client device can initiate a verification protocol when it detects the occurrence of the trigger event. The verification protocol can include executing diagnostic checks to verify whether the medical control application is functioning properly and has access to adequate computing resources (e.g., processing resources, communication resources, user interface resources, memory resources).
• In another embodiment, the application at the non-medical client device can perform a communication link verification process, when the application detects occurrence of the trigger event, 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 haves a communication link to the wearable medical device, the application can attempt to establish a communication link between the non-medical client device and the medical device, and if the attempt to establish the communication link is unsuccessful, the application can cause a first notification to be generated via the user interface of the non-medical client device, and/or cause a second notification to be generated via a second user interface of the medical device.
• In yet another embodiment, a method is provided for an application on the non-medical device (e.g., smartphone, tablet or laptop) to take control of the insulin pump to issue a notification or an alert (e.g., activate an audio or visual alarm, activate a haptic signal). This provides a way to let a patient know that their non-medical device may not be operating as intended to alert them that some action needs to be taken. In one implementation, a smartphone can periodically check to make sure that an application and/or the smartphone that runs the application are working as required. For example, whenever information indicates that an alarm needs to be issued, a check can be performed to make sure that the application and/or smartphone that runs the application are operating correctly. This way, the system can determine whether everything is connected and working properly so that the user knows if the medical control application is working correctly or as intended. If everything is not connected or working properly, then backup alert system or alarm on the body-worn 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 properly or optimally as recommended (e.g., alert the user that the application and/or smartphone that runs the application are not working as required, and/or to alert the user that some action needs to be taken).
• Turning now toFIG. 1, one exemplary embodiment of aninfusion system100 includes, without limitation, a fluid infusion device (or infusion pump)102, asensing arrangement104, a command control device (CCD)106, and acomputer108. The components of aninfusion system100 may be realized using different platforms, designs, and configurations, and the embodiment shown inFIG. 1 is not exhaustive or limiting. In practice, theinfusion device102 and thesensing arrangement104 are secured at desired locations on the body of a user (or patient), as illustrated inFIG. 1. In this regard, the locations at which theinfusion device102 and thesensing arrangement104 are secured to the body of the user inFIG. 1 are provided only as a representative, non-limiting, example. The elements of theinfusion system100 may be similar to those described in U.S. Pat. No. 8,674,288, the subject matter of which is hereby incorporated by reference in its entirety.
• In the illustrated embodiment ofFIG. 1, theinfusion device102 is designed as a portable medical device suitable for infusing a fluid, a liquid, a gel, or other medicament into the body of a user. In exemplary embodiments, the infused fluid is insulin, although many other fluids may be administered through infusion such as, but not limited to, HIV drugs, drugs to treat pulmonary hypertension, iron chelation drugs, pain medications, anti-cancer treatments, medications, vitamins, hormones, or the like. In some embodiments, the fluid may include a nutritional supplement, a dye, a tracing medium, a saline medium, a hydration medium, or the like.
• Thesensing arrangement104 generally represents the components of theinfusion system100 configured to sense, detect, measure or otherwise quantify a condition of the user, and may include a sensor, a monitor, or the like, for providing data indicative of the condition that is sensed, detected, measured or otherwise monitored by the sensing arrangement. In this regard, thesensing arrangement104 may include electronics and enzymes reactive to a biological condition, such as a blood glucose level, or the like, of the user, and provide data indicative of the blood glucose level to theinfusion device102, theCCD106 and/or thecomputer108. For example, theinfusion device102, theCCD106 and/or thecomputer108 may include a display for presenting information or data to the user based on the sensor data received from thesensing arrangement104, such as, for example, a current glucose level of the user, a graph or chart of the user's glucose level versus time, device status indicators, alert messages, or the like. In other embodiments, theinfusion device102, theCCD106 and/or thecomputer108 may include electronics and software that are configured to analyze sensor data and operate theinfusion device102 to deliver fluid to the body of the user based on the sensor data and/or preprogrammed delivery routines. Thus, in exemplary embodiments, one or more of theinfusion device102, thesensing arrangement104, theCCD106, and/or thecomputer108 includes a transmitter, a receiver, and/or other transceiver electronics that allow for communication with other components of theinfusion system100, so that thesensing arrangement104 may transmit sensor data or monitor data to one or more of theinfusion device102, theCCD106 and/or thecomputer108.
• Still referring toFIG. 1, in various embodiments, thesensing arrangement104 may be secured to the body of the user or embedded in the body of the user at a location that is remote from the location at which theinfusion device102 is secured to the body of the user. In various other embodiments, thesensing arrangement104 may be incorporated within theinfusion device102. In other embodiments, thesensing arrangement104 may be separate and apart from theinfusion device102, and may be, for example, part of theCCD106. In such embodiments, thesensing arrangement104 may be configured to receive a biological sample, analyte, or the like, to measure a condition of the user.
• In some embodiments, theCCD106 and/or thecomputer108 may include electronics and other components configured to perform processing, delivery routine storage, and to control theinfusion device102 in a manner that is influenced by sensor data measured by and/or received from thesensing arrangement104. By including control functions in theCCD106 and/or thecomputer108, theinfusion device102 may be made with more simplified electronics. However, in other embodiments, theinfusion device102 may include all control functions, and may operate without theCCD106 and/or thecomputer108. In various embodiments, theCCD106 may be a portable electronic device. In addition, in various embodiments, theinfusion device102 and/or thesensing arrangement104 may be configured to transmit data to theCCD106 and/or thecomputer108 for display or processing of the data by theCCD106 and/or thecomputer108.
• In some embodiments, theCCD106 and/or thecomputer108 may provide information to the user that facilitates the user's subsequent use of theinfusion device102. For example, theCCD106 may provide information to the user to allow the user to determine the rate or dose of medication to be administered into the user's body. In other embodiments, theCCD106 may provide information to theinfusion device102 to autonomously control the rate or dose of medication administered into the body of the user. In some embodiments, thesensing arrangement104 may be integrated into theCCD106. Such embodiments may allow the user to monitor a condition by providing, for example, a sample of his or her blood to thesensing arrangement104 to assess his or her condition. In some embodiments, thesensing arrangement104 and theCCD106 may be used for determining glucose levels in the blood and/or body fluids of the user without the use of, or necessity of, a wire or cable connection between theinfusion device102 and thesensing arrangement104 and/or theCCD106.
• In some embodiments, thesensing arrangement104 and/or theinfusion device102 are cooperatively configured to utilize a closed-loop system for delivering fluid to the user. Examples of sensing devices and/or infusion pumps utilizing closed-loop systems may be found at, but are not limited to, the following U.S. Pat. Nos. 6,088,608, 6,119,028, 6,589,229, 6,740,072, 6,827,702, 7,323,142, and 7,402,153 or United States Patent Application Publication No. 2014/0066889, all of which are incorporated herein by reference in their entirety. In such embodiments, thesensing arrangement104 is configured to sense or measure a condition of the user, such as, blood glucose level or the like. Theinfusion device102 is configured to deliver fluid in response to the condition sensed by thesensing arrangement104. In turn, thesensing arrangement104 continues to sense or otherwise quantify a current condition of the user, thereby allowing theinfusion device102 to deliver fluid continuously in response to the condition currently (or most recently) sensed by thesensing arrangement104 indefinitely. In some embodiments, thesensing arrangement104 and/or theinfusion device102 may be configured to utilize the closed-loop system only for a portion of the day, for example only when the user is asleep or awake.
• FIG. 2 is a simplified block diagram representation of an exemplary embodiment of acommunication system200 that is suitably configured to support the techniques and methodologies described in more detail below. Thesystem200 supports users of insulin infusion devices, and performs various techniques and methods to help users (patients, caregivers, healthcare providers, parents, etc.) manage the use of insulin infusion devices. It should be appreciated thatFIG. 2 depicts one possible implementation of a communication system, and that other arrangements, architectures, and deployments can be provided if so desired. The system200 (which has been simplified for purposes of illustration) generally includes or cooperates with the following components, without limitation: amobile device204; aninsulin infusion device206; ablood glucose meter208; acontinuous glucose sensor210; and anoptional data uploader212. Themobile device204 is a client device that is owned or operated by the user, i.e., a diabetic patient. Theinsulin infusion device206, theblood glucose meter208, and theglucose sensor210 are components of an insulin infusion system that is used by the patient to treat diabetes. Thesystem200 may also include or cooperate with the optionaldata uploader component212.
• The various components of thesystem200 can be used to collect and analyze input data for the patient that can originate from various sources, including an insulin infusion device, a glucose sensor or meter, a mobile device operated by a user of the insulin infusion device, or other components or computing devices that are compatible with the system, such as a data uploader. These and other alternative arrangements are contemplated by this disclosure. To this end, some embodiments of the system may include additional devices and components that serve as data sources, data processing units, etc. For example, the system may include any or all of the following elements, without limitation: computer devices or systems; patient monitors; healthcare provider systems; data communication devices; and the like. It should be appreciated that theinsulin infusion device206 can be an optional component in some applications (for example, for Type2 diabetes patients). For such applications, another diabetes management device and/or themobile device204 can function in an equivalent manner to support thesystem200.
• At a minimum, themobile device204 is communicatively coupled to anetwork214. In certain embodiments, theinsulin infusion device206, theblood glucose meter208, and/or thecontinuous glucose sensor210 are also communicatively coupled to thenetwork214 to facilitate the uploading of relevant data to a remote server system (not illustrated). Alternatively, or additionally, theinsulin infusion device206, theblood glucose meter208, and thecontinuous glucose sensor210 provide relevant data to thedata uploader component212, which in turn uploads the data to other systems (not illustrated) via thenetwork214.
• FIG. 2 depicts thenetwork214 in a simplified manner. In practice, thesystem200 may cooperate with and leverage any number of wireless and any number of wired data communication networks maintained or operated by various entities and providers. Accordingly, communication between the various components of thesystem200 may involve multiple network links and different data communication protocols. In this regard, thenetwork214 can include or cooperate with any of the following, without limitation: a local area network; a wide area network; the Internet; a personal area network; a cellular communication network; a satellite communication network; a video services or television broadcasting network; a network onboard a vehicle; or the like. In addition, the various components can also communicate directly with each other using NFMI radio communications; NFeMI radio communications, BLE® communications, classical Bluetooth® (BT) communications, WLAN (or “Wi-Fi”) communications, or indirectly with each other using WLAN or cellular communications, as will be described below. The components of the system may be suitably configured to support a variety of wireless and wired data communication protocols, technologies, and techniques as needed for compatibility with thenetwork214.
• Themobile device204 can be realized using a variety of different device platforms. For example, themobile device204 can be implemented as any of the following, without limitation: a cellular telephone or smartphone; a portable computer (e.g., a laptop, a tablet, or a 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. In accordance with certain exemplary embodiments, themobile device204 supported by thesystem200 is implemented as a computer-based or processor-based component. For simplicity and ease of illustration,FIG. 2 depicts only onemobile device204. In practice, however, thesystem200 is suitably configured to support a plurality ofmobile devices204, where the patient or user owns or operates at least one of the supportedmobile devices204. An exemplary embodiment of a device suitable for implementing themobile device204 is described below with reference toFIG. 3.
• The remainder of this description assumes that themobile device204 is a smartphone used by the particular patient. To this end, the configuration and general functionality of themobile device204 can be substantially consistent with conventional smartphone design. In this regard, a suitably designed mobile app is installed on themobile device204 to allow the patient to receive, view, and interact with messages and notifications provided by the system. The mobile app installed on themobile device204 can also be utilized to provide relevant data to other systems (not illustrated) for storage and analysis. For example, the mobile app can manage and upload the following information, without limitation: calendar data (time of day, day of the week, month, season, etc.); user profile data; GPS data that indicates the geographic position of themobile device204; map or navigation data associated with operation of themobile device204; user-entered meal consumption, food content, and/or food ingredient data; user-entered carbohydrate data; user-entered exercise related data; user-entered medication related data; user response data associated with the receipt of glycemic insight messages; user feedback related to glycemic insight messages; accelerometer data; contacts list information; web browser data; consumer purchasing data; and the like.
• In certain embodiments, theinsulin infusion device206 is a portable patient-worn or patient-carried component that is operated to deliver insulin into the body of the patient via, for example, an infusion set. In accordance with certain exemplary embodiments, eachinsulin infusion device206 supported by thesystem200 is implemented as a computer-based or processor-based component. For simplicity and ease of illustration,FIG. 2 depicts only oneinsulin infusion device206. In practice, however, thesystem200 is suitably configured to support a plurality ofinsulin infusion device206, wherein each patient or user owns or operates at least one of theinsulin infusion devices206. An exemplary embodiment of a device suitable for implementing theinsulin infusion device206 is described below with reference toFIG. 3.
• Thesystem200 obtains input data from one or more sources, which may include various diabetes management devices (an insulin infusion device, a continuous glucose monitoring device, a glucose sensor, a monitor device, or the like). In this regard, theinsulin infusion device206 represents a source of input data for thesystem200. In certain embodiments, theinsulin infusion device206 provides data that is associated with its operation, status, insulin delivery events, and the like. As mentioned previously, relevant data generated or collected by theinsulin infusion device206 can be transmitted directly or indirectly to other components of the system including thedata uploader component212, depending on the particular implementation of thesystem200. The particular type of data provided by theinsulin infusion device206 is described in more detail below.
• The patient or user can own or operate theblood glucose meter208. Theblood glucose meter208 is configured to measure the blood glucose level of a user by analyzing a blood sample. For example, theblood glucose meter208 may include a receptacle for receiving a blood sample test strip. In this regard, the user inserts a test strip into theblood glucose meter208, which analyzes the sample and displays a blood glucose level corresponding to the test strip sample. Theblood glucose meter208 may be configured to communicate the measured blood glucose level to theinsulin infusion device206 for storage and processing, to themobile device204, or to thedata uploader component212. In some scenarios, the patient is responsible for entering each blood glucose measurement into theinsulin infusion device206. Ultimately, the measured blood glucose data can be provided to any components of the system for analysis.
• Theglucose sensor210 can be owned or operated by the patient or user. Theglucose sensor210 is suitably configured to measure a glucose level (interstitial) of the patient in real time. Theglucose sensor210 may include a wireless transmitter that facilitates transmission of the sensor glucose data to other devices, such as theinsulin infusion device206 or thedata uploader component212 or other components of the system, where the sensor glucose data can be received for further processing.
• Depending on the particular embodiment and application, thesystem200 can include or cooperate with other devices, systems, and sources of input data. Devices within thesystem200 may be configured to support the transmission of data to various external devices, such as, without limitation: a stationary monitor device, such as a bedside monitor or a piece of hospital monitoring equipment; a portable computer, such as a laptop PC, a palmtop PC, or a tablet PC; a stationary 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; or the like. The above list of possible external devices is not exhaustive, and an implementation of thesystem200 can be designed to accommodate communication with other systems, equipment, computing devices, components, and elements that are external to thesystem200. For example, in certain embodiments thesystem200 includes one or more sources of contextual information or data, which may include, without limitation: activity tracker devices; meal logging devices or apps; mood tracking devices or apps; and the like.
• Thesystem200 includes a local infusion system having one or more local devices configured to wirelessly communicate with each other. This description may refer to the local infusion system as a “personal area network” or a “body area network” of its constituent devices. These local devices may be configured to transmit and receive local communications within the local infusion system, where such local communications are transmitted and received in accordance with 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 leverage RF, infrared, magnetic induction, or other wireless techniques) and/or using one or more wired data communication protocols. Thus, one or more of the local devices can be considered to be a wireless medical device in the context of this description. The local infusion system may be flexibly configured such that any given local device can communicate with any other local device, and a communication link or path between two local devices may be unidirectional or bidirectional.FIG. 2 depicts an exemplary embodiment where each communication link or path is bidirectional (represented by double headed arrows).
• Moreover, the local devices in the local infusion system may be capable of communication (unidirectional or bidirectional) with one or more “external” devices that are not considered to be part of the local infusion system. The manner in which a given local device within the local infusion system communicates with a given external device may vary depending upon the particular configuration of thesystem200, 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 an external device using one data communication network, using a plurality of data communication networks, using a direct wireless or wired connection, or the like
• As mentioned above, thesystem200 includes or cooperates with computer-based and/or processor-based components having suitably configured hardware and software written to perform the functions and methods needed to support the features described herein. For example, themobile device204, theinsulin infusion device206, theblood glucose meter208 and thedata uploader component212 can be realized as an electronic processor-based component. An exemplary embodiment of a device suitable for implementing the various components of the system will described below with reference toFIG. 3. In this regard,FIG. 3 is a simplified block diagram representation of an exemplary embodiment of a computer-based or processor-baseddevice300 that is suitable for deployment in the system shown inFIG. 2.
• The illustrated embodiment of thedevice300 is intended to be a high-level and generic representation of one suitable platform. In this regard, any of the computer-based or processor-based components of thesystem200 can utilize the architecture of thedevice300. The illustrated embodiment of thedevice300 generally includes, without limitation: at least oneprocessor302; a suitable amount ofmemory304; device-specific hardware, software, firmware, and/or features306; auser interface308; acommunication module310; and a display element311. Of course, an implementation of thedevice300 may include additional elements, components, modules, and functionality configured to support various features that are unrelated to the subject matter described here. For example, thedevice300 may include certain features and elements to support conventional functions that might be related to the particular implementation and deployment of thedevice300. In practice, the elements of thedevice300 may be coupled together via a bus or any suitable interconnection architecture301.
• Theprocessor302 may be implemented or performed with 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 designed to perform the functions described here. Moreover, theprocessor302 may be implemented as a combination of computing devices, e.g., a combination of a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other such configuration.
• Thememory304 may be realized as RAM memory, flash memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. In this regard, thememory304 can be coupled to theprocessor302 such that theprocessor302 can read information from, and write information to, thememory304. In the alternative, thememory304 may be integral to theprocessor302. As an example, theprocessor302 and thememory304 may reside in an ASIC. At least a portion of thememory304 can be realized as a computer storage medium, e.g., a tangible computer-readable medium having computer-executable instructions stored thereon. The computer-executable instructions, when read and executed by theprocessor302, cause thedevice300 to perform certain tasks, operations, functions, and processes that are specific to the particular embodiment. In this regard, thememory304 may represent one suitable implementation of such computer-readable media. Alternatively, or additionally, thedevice300 could receive and cooperate with computer-readable media (not separately shown) that is realized as a portable or mobile component or platform, e.g., a portable hard drive, a USB flash drive, an optical disc, or the like.
• The device-specific hardware, software, firmware, and features306 may vary from one embodiment of thedevice300 to another. For example, the device-specific hardware, software, firmware, and features306 will support: smartphone functions and features when thedevice300 is realized as a mobile telephone; conventional personal computer functions and features if thedevice300 is realized as a laptop or tablet computer; insulin pump operations when thedevice300 is realized as an insulin infusion device; etc. In practice, certain portions or aspects of the device-specific hardware, software, firmware, and features306 may be implemented in one or more of the other blocks depicted inFIGS. 3 and 4.
• Theuser interface308 may include or cooperate with various features to allow a user to interact with thedevice300. Accordingly, theuser interface308 may include various human-to-machine interfaces, e.g., a keypad, keys, a keyboard, buttons, switches, knobs, a touchpad, a joystick, a pointing device, a virtual writing tablet, a touch screen, a microphone, or any device, component, or function that enables the user to select options, input information, or otherwise control the operation of thedevice300. Theuser interface308 may include one or more graphical user interface (GUI) control elements that enable a user to manipulate or otherwise interact with an application via the display element311.
• Thecommunication module310 facilitates data communication between thedevice300 and other components as needed during the operation of thedevice300. In the context of this description, thecommunication module310 can be employed to transmit or stream device-related control data, patient-related data, device-related status or operational data, glycemic insight messages and notifications, and the like. It should be appreciated that the particular configuration and functionality of thecommunication module310 can vary depending on the hardware platform and specific implementation of thedevice300. Accordingly, thecommunication module310 is utilized to obtain input data from various sources, and to send output data to other components or devices that are described above with reference toFIGS. 1 and 2. In practice, an embodiment of thedevice300 may support wireless data communication and/or wired data communication, using various data communication protocols. For example, thecommunication module310 could support one or more wireless data communication protocols, techniques, or methodologies, including, without limitation: RF; IrDA (infrared); Bluetooth®; ZigBee® (and other variants 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 health care facility network protocols such as those operating in the WMTS bands; GPRS; and proprietary wireless data communication protocols such as variants of Wireless USB. Moreover, thecommunication module310 could support one or more wired/cabled data communication protocols, including, without limitation: Ethernet; powerline; home network communication protocols; USB; IEEE 2394 (Firewire); hospital network communication protocols; and proprietary data communication protocols. In one particular implementation, thecommunication module310 includes a far-field communication module and a body area network communication module, and a controller (not illustrated).
• The far-field communication module includes various far-field communication interfaces that can be used to communicate electromagnetic signals to other devices that are part of a body area network. In this non-limiting example, various far-field communication interfaces can include, but are not limited to, a Bluetooth low energy (BLE®) communication interface, a classical Bluetooth® (BT) communication interface, a wireless local area network (WLAN) communication interface (e.g., a Wi-Fi interface), and a cellular communication interface. The above-mentioned communication interfaces can comply with any known standards. For example, the BLE® communication interface can communicate in compliance with any Bluetooth® release (e.g., versions 1.0 through 5.1), and any physical (PHY) layer specifications defined therein. For instance, Bluetooth® 5.0 includes three PHY layer variations called LE 1M, LE 2M and LE Coded. Each PHY variant has its own particular characteristics and was designed with specific aims in mind. As another non-limiting example, the BLE® communication interface can communicate in compliance with a Bluetooth® mesh networking protocol (defined in Mesh Profile Specification and Mesh Model Specification which was adopted on Jul. 13, 2017). The Bluetooth® mesh networking protocol is a protocol based upon Bluetooth Low Energy® that allows for many-to-many communication over Bluetooth® radio.
• When a signal from a far-field communication interface is transmitted by an antenna, it is attenuated over distance to the point that the signal cannot be effectively detected. This is called far-field transmission, and works well if the signal needs to be transmitted over a long distance. However, far-field communication interfaces can have problems if the wireless communication needs to be very low power and confines to a fairly short distance near body areas. Improper placement of devices close to a human body may result in a detuned antenna input impedance, reduced antenna efficiency, and distorted antenna radiation pattern. Penetration of electromagnetic signals generated by far-field communication interfaces into the human body is another problem because electromagnetic signals can be quickly absorbed and greatly attenuated due to the very conductive body tissues. In addition, interference can be very high due to coexistence of multiple far-field communication interfaces (e.g., BT, BLE®, Wi-Fi, and ZigBee®) that operate in the same frequency band. Power consumption can also limit continuous operation. Lastly, far-field communication interface can present potential security problems because electromagnetic signals can be intercepted and decrypted after propagating into free space.
• On the other hand, the body area network communication module includes various near-field communication interfaces that can be used to communicate magnetic signals to other devices that are part of a body area network. In this non-limiting example, various near-field communication interfaces can include, but are not limited to, a near field magnetic inductive (NFMI) radio communication interface, a near-field electromagnetic induction (NFeMI) radio communication interface (not illustrated), 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. A near-field communication interface can provide a more reliable, a more secure, and a much lower power radio link within, on, and in the immediate proximity of a human body.
• For example, NFMI is a short-range wireless technology that communicates using a tightly coupled magnetic field among devices. NFMI enables human body friendly, reliable, secure, and power efficient wireless communication. As used herein, the term “Near-Field Magnetic Induction (NFMI) radio communication system” can refer to a short range wireless physical layer that communicates by coupling a tight, low-power, non-propagating magnetic field between devices. A transmitter coil in one device can modulate a magnetic field which is measured by a receiver coil in another device. To explain further, in NFMI-based communication systems, a modulated signal that is sent out from a transmitter coil is in the form of a magnetic field. This magnetic field induces voltage on the receiving coil, which in turn will be measured by an NFMI receiver. NFMI radio communication systems differ from other wireless communications in that most conventional wireless RF systems use an antenna to generate, transmit, and propagate an electromagnetic wave, where all of the transmission energy is designed to radiate into free space. This type of transmission is referred to as “far-field.” NFMI systems are designed to contain transmission energy within the localized magnetic field. This magnetic field energy resonates around the communication system, but does not radiate into free space. To explain further, the power density of NFMI signals attenuate at a rate inversely proportional to the distance to the sixth power compared to the second power for Bluetooth® signals. This means for the same distance, the power density of NFMI signals is 10000 times weaker than Bluetooth® signals provided that both transmitting power are equal. This type of wireless transmission is referred to as “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 system.
• As used herein, the term “near-field electromagnetic induction (NFeMI) radio communication interface” can refer to a communication interface that can operate near a human body by means of a combination of a magnetic field and electric field without the use of transversal radiating waves. Such NFEMI systems improve a wearable device's signal link budget and extend their range to a complete human body. Whereas RF wireless communication may be accomplished by propagating an RF plane wave through free space, NFEMI communication utilizes non-propagating quasi-static fields.
• As used herein, the term “Near-field communication (NFC)” can refer to a set of communication protocols and data exchange formats that enable two or more electronic devices (e.g., a medical device such as an insulin pump and a portable device such as a smartphone) to establish communication with each other by bringing them within a short separation range of each other (e.g., 2 meters or less). NFC allows one- and two-way communication between endpoints, suitable for many applications. NFC uses electromagnetic induction between two loop antennas (located within each other's near-field) to effectively form an air-core transformer that allows them to exchange information. The NFC interface operates based on similar principles as the NFMI interface322 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 around 13 MHz, NFMI provides a data rate of over 400 Kbps per frequency channel, up to 10 separate frequency channels and 10 sub-channels per frequency channel using time division (e.g., a hundred separate wireless links inside a single WBAN). In one non-limiting implementation, NFC-enabled devices that are described herein can exchange information in accordance with any NFC standards that cover communications protocols and data exchange formats. NFC standards cover communications protocols and data exchange formats and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443. The standards include ISO/IEC 18092 and those defined by the NFC Forum. In addition to the NFC Forum, the GSM Association (GSMA) group defined a platform for the deployment of GSMA NFC Standards within mobile handsets.
• RFID systems can operate in low frequency (LF), high frequency (HF), and ultra-high frequency (UHF) bands, and thus can be categorized by the frequency band within which they operate: low frequency, high frequency, and ultra-high frequency. In addition, there are also two broad categories of systems—passive and active RFID. The LF band covers frequencies from 30 KHz to 300 KHz (e.g., some LF RFID systems operate at 125 KHz, while others operate at 134 KHz). The RFID HF communication interface326 can operate in a HF band that ranges from 3 to 30 MHz, with communications ranges between 10 cm and 1 m. There are several HF RFID standards, such as the ISO 15693 standard for tracking items, and the ECMA-340 and ISO/IEC 18092 standards for Near Field Communication (NFC), the ISO/IEC 14443 A and ISO/IEC 14443 standards. The UHF frequency band covers the range from 300 MHz to 3 GHz, and the range of some UHF systems can be as long as 12 m with faster data transfer rates than LF or HF. The UHF frequency band is regulated by a single global standard called the ECPglobal Gen2 (ISO 18000-63) UHF standard.
• The low power wide area network (LPWAN) communication interfaces can include interfaces such as a Long Term Evolution for Machines (LTE-M) communication interface (LTE-Cat M1) and/or a narrowband-IoT (NB-IoT) communication interface (not illustrated). NB-IOT and LTE-M are two newer low power wide area (LPWA) technologies that were developed for IOT applications. Both are protocols for low bandwidth cellular communications that connect to the internet devices that need to transmit small amounts of data, with the lower costs (both hardware and subscription) and the higher battery life.
• The various communication interfaces mentioned above are non-limiting, and can be implemented in accordance with any known standards including those mentioned above. However, it should be appreciated that the number of communication interfaces that are included as part of thecommunication module310 can vary depending on the implementation.
• A controller (not illustrated) can be configured to control which ones of the communication interfaces are selected and used by a device or component of the wireless body area network 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 one of the communication interfaces is to be used at any particular time and switch between which one of the communication interfaces is enabled and used by a device or component of the wireless body area network to communicate data with other devices or components that are part of the wireless body area network.
• As will be described in greater detail below, depending on a device's proximity to the body area network, the controller can select any of the various communication interfaces to use for communications 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 quality of service of the communication link with another device, the security type of the data that is being communicated to the other device, etc. In this regard quality of service can be measured using any standard quality of service performance metrics (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. Quality of service metrics can also include metrics such as service response time, loss, signal-to-noise ratio, crosstalk, echo, interrupts, frequency response, and so on. Quality of service (QoS) is the description or measurement of the overall performance of a service, particularly the performance seen by the users of the network.
• When the quality of service is greater than or equal to the threshold, the device can utilize a particular communication interface. When the quality of services is less than the threshold, the controller can then determine an appropriate communication interface to switch to that will achieve the desired quality of service that is greater than or equal to the threshold. In addition, in some embodiments, once the controller determines that the quality of service over one of the communication interfaces is greater than or equal to the threshold, the controller can also determine the type of data that is being communicated by the device, and if it is a high security datatype, the controller can also restrict communication to one of the body area network communication interfaces such that communications can only take place within traceable security boundary, as defined by the body area network, where the wireless energy has not degraded to a negligible level. In other words, when the type of data being communicated is a high security datatype, the controller will only utilize one of the body area network communication interfaces to help ensure security of the data that's being communicated.
• Referring again toFIG. 3, the display element311 is suitably configured to enable thedevice300 to render and display various screens, insight messages, notifications, GUIs, GUI control elements, drop down menus, auto-fill fields, text entry fields, message fields, or the like. Of course, the display element311 may also be utilized for the display of other information during the operation of thedevice300, as is well understood. Notably, the specific configuration, operating characteristics, size, resolution, and functionality of thedisplay element310 can vary depending upon the practical implementation of thedevice300. For example, if thedevice300 is a laptop computer, then the display element311 may be a relatively large monitor. Alternatively, if thedevice300 is a cellular telephone device (e.g., smartphone), then the display element311 may be a relatively small integrated display screen, such as a touch-sensitive screen.
• FIG. 4 is amethod400 for verifying whether a communication link between anon-medical client device108 and amedical device102,104 is established and for causing a notification to be issued at thenon-medical client device108 and/or themedical device102,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 themethod400 are not necessarily limiting. With reference tomethod400, steps can be added, omitted, and/or performed simultaneously without departing from the scope of the appended claims. It should be appreciated that themethod400 may include any number of additional or alternative tasks, that the tasks shown inFIG. 4 need not be performed in the illustrated order, and that themethod400 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the tasks shown inFIG. 4 could potentially be omitted from an embodiment of themethod400 as long as the intended overall functionality remains intact. It should also be understood that the illustratedmethod400 can be stopped at any time. Themethod400 is computer-implemented in that various tasks or steps that are performed in connection with themethod400 may be performed by software, hardware, firmware, or any combination thereof. For illustrative purposes, the following description of themethod400 may refer to elements mentioned above in connection withFIGS. 1-3.
• In certain embodiments, some or all steps of this process, and/or substantially equivalent steps, are performed by execution of processor-readable instructions stored or included on a processor-readable medium. For instance, in the description ofFIG. 4 that follows, thenon-medical client device108 and themedical device102,104 will be described as performing various acts, tasks or steps, but it should be appreciated that this refers to processing system(s) of these entities executing instructions to perform those various acts, tasks or steps. Depending on the implementation, themethod400 can be performed by an application at thenon-medical client device108 and/or an application at themedical device102,104 to regularly check the status of the communication link between thenon-medical client device108 and themedical device102,104 to make sure that the respective medical control applications at each are able to communicate. Therapy related notifications can be generated from themedical device102,104. Both themedical device102,104 and thenon-medical client device108 are capable of confirming communication link between them and notifying the user if the communication link is not there. If the communication link between thenon-medical client device108 and themedical device102,104 is not adequate (e.g., not established), one or more notifications, warnings, alerts or alarms on themedical device102,104 can be activated to alert the user that the communication link between thenon-medical client device108 and themedical device102,104 is inadequate. As described above, the notifications, warnings, alerts or alarms on themedical device102,104 can be, for example, visual, haptic and/or audio alarms. In some embodiments, the visual, haptic and/or audio alarms can be implemented in specific sequences of visual, audio and haptics for different messages. For example, three flashes or vibration followed by a pause to indicate loss of communication withnon-medical client device108. Furthermore, in the description ofFIG. 4, a particular example is described in which thenon-medical client device108 and/or themedical device102,104 perform certain actions by interacting with other elements of the system described above with reference toFIGS. 1-3.
• The communicationlink verification method400 begins at402, where the link verification process starts and themethod400 proceeds to404. At404, an application determines whether a trigger event has occurred. The trigger event could be, for example, receiving an indication that an alert has been issued or needs to be acknowledged; receiving an indication that a notification, alarm, alert, or warning 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 that a regularly scheduled data transfer (e.g., blood glucose or confirmation of last insulin delivery) did not occur, etc. Themethod400 loops at404 until a trigger event occurs and then proceeds to406.
• At406, the application determines whether the communication link between thenon-medical client device108 and themedical device102,104 is established or adequate (e.g., whether themedical control application107 that is running on thenon-medical client device108 is able to communicate with themedical control application105 that is running at themedical device102,104). When the application determines (at406) that an adequate communication link is established between communication interfaces of thenon-medical client device108 and themedical device102,104, themethod400 loops back to402. In one embodiment, a timer or counter can be reset when it is determined (at406) that thenon-medical client device108 and themedical device102,104 have an adequate communication link.
• When the application determines (at406) that the that the communication link is inadequate, themethod400 proceeds to408 where the application at either thenon-medical client device108 or themedical device102,104 attempts to establish (or reestablish) a communication link between communication interfaces of themedical device102,104 and thenon-medical client device108. Themethod400 then proceeds to410, where the application determines whether the communication link was successfully established. When the application determines (at410) that the communication link was successfully established, themethod400 loops back to402.
• When the application determines (at410) that the communication link was not successfully established, themethod400 proceeds to412, where the application at thenon-medical client device108, and/or the application at themedical device102,104, causes one or more notifications, warnings, alarms or alerts to be activated at thenon-medical client device108, and/or themedical device102,104 causes one or more notifications, warnings, alarms or alerts to be activated at themedical device102,104. Since thenon-medical client device108 may be separated from the patient, themedical device102,104 should be able perform the check and if needed issue a notification. Having thenon-medical client device108 in the system may be critical in situations where the system is programmed to also notify the caregivers or health care providers thru the cloud.
• FIG. 5 is amethod500 for verifying that a non-medical client device and a medical control application are operating/functioning properly in accordance with the disclosed embodiments. As a preliminary matter, it should be understood that the steps of themethod500 are not necessarily limiting. With reference tomethod500, steps can be added, omitted, and/or performed simultaneously without departing from the scope of the appended claims. It should be appreciated that themethod500 may include any number of additional or alternative tasks, that the tasks shown inFIG. 5 need not be performed in the illustrated order, and that themethod500 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the tasks shown inFIG. 5 could potentially be omitted from an embodiment of themethod500 as long as the intended overall functionality remains intact. It should also be understood that the illustratedmethod500 can be stopped at any time. Themethod500 is computer-implemented in that various tasks or steps that are performed in connection with themethod500 may be performed by software, hardware, firmware, or any combination thereof. For illustrative purposes, the following description of themethod500 may refer to elements mentioned above in connection withFIGS. 1-3.
• In certain embodiments, some or all steps of this process, and/or substantially equivalent steps, are performed by execution of processor-readable instructions stored or included on a processor-readable medium. For instance, in the description ofFIG. 5 that follows, thenon-medical client device108 and themedical device102,104 will be described as performing various acts, tasks or steps, but it should be appreciated that this refers to processing system(s) of these entities executing instructions to perform those various acts, tasks or steps. Depending on the implementation, themethod500 can be performed by an application at thenon-medical client device108 and/or at themedical device102,104. In one embodiment, themethod500 can be initiated by thenon-medical client device108 to execute one or more diagnostic checks to ensure the medical control application at thenon-medical client device108 is running properly and has access to required resources for its proper function. Themethod500 can be used to generate a notification at thenon-medical client device108 to alert the user whenmedical control application107 of thenon-medical client device108 is not operating/functioning properly (e.g., not running properly or does not have access to required resources for it to function properly). Furthermore, in the description ofFIG. 5, a particular example is described in which thenon-medical client device108 and/or themedical device102,104 perform certain actions by interacting with other elements of the system described above with reference toFIGS. 1-3.
• Themethod500 starts at502, the application starts an application verification process. At504, the application monitors for a trigger event by determining whether a trigger event has occurred. The trigger event could be, for example, receiving an indication that an alert has been issued or needs to be acknowledged; receiving an indication that a notification, alarm, alert, or warning 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 discovering that a communication link between the medical device and non-medical device is not operating or communicating as intended, etc. Themethod500 loops at504 until a trigger event occurs and then proceeds to506.
• When a trigger event has been determined to have occurred (at504), the application initiates an application verification protocol at506 to verify whether the application is operating/functioning properly and/or has access to required computing resources. The application verification protocol can include running one or more diagnostic checks. The diagnostic checks can be used to verify that the application is operating/functioning properly and/or has access to required computing resources.
• The diagnostic checks that are performed or executed at506 can include: verifying whether a communication link between anon-medical client device108 and amedical device102,104 is established (as described above with reference toFIG. 4); determining whether the application and/or the operating system version is up-to-date and/or authentic; determining whether the settings of the application are correct; determining whether the application is loading properly; determining whether the application is running properly; determining whether the application has access to adequate computing resources (e.g., processing resources, communication resources, user interface resources, and/or memory resources) of the device; determining whether the application has access to adequate computing resources of the non-medical client device108 (e.g., processing resources, communication resources, user interface resources, and/or memory resources) of the device, etc. For instance, themedical device102,104 should be satisfied that the application is working properly and has access to resources such as processor, memory, speakers, camera flash, display, haptic or other vibrators, or other means for generating notifications, etc. If themedical device102,104 does have confirmation of this is should notify the user thru its own notification means. The number of diagnostic checks that are performed, and the order in which they are performed, can vary depending on the implementation.
• In one embodiment, the diagnostic checks can be performed in parallel or simultaneously or nearly simultaneously. In another embodiment, the diagnostic checks can be performed sequentially (in a predetermined order). For instance, after initiation of the application verification protocol at506,steps506 through512 are iteratively performed to run a series of diagnostic checks that are used to determine whether the application is running or operating/functioning properly and/or has access to required computing resources. On the first iteration of506, the first diagnostic check is executed. At508, the application determines whether the application passed the first diagnostic check, and if so, themethod500 proceeds to512, where the application determines whether there are any additional diagnostic checks to be executed. If it is determined (at512) that there are no additional diagnostic checks to be executed, themethod500 proceeds to514. When it is determined (at512) that there are additional diagnostic checks to be executed, themethod500 loops back to506, where the application executes the next diagnostic check to determine whether the application is operating/functioning properly and/or has access to required computing resources. In one embodiment, steps506 through512 loop until all the diagnostic checks have been executed.
• Whenever the application determines at508 that the application did not pass a particular diagnostic check that was executed (at506), themethod500 can proceed to510 where a problem corresponding to that particular diagnostic check is logged to create a record that explains why the application is not operating/functioning properly and/or does not have access to required computing resources, and the method then proceeds to512. When it is determined (at512) that there are no additional diagnostic checks to be executed, themethod500 proceeds to514.
• At514, the application attempts to initiate one or more remedial correction measures in an attempt to correct issues that are causing it to run improperly so that the application will function correctly and/or have access to required computing resources. The remedial correction measures that are taken (at514) can vary depending on the implementation and which diagnostic checks were performed or executed at506, and which ones of those were determined to have not passed (NO at508). The remedial correction measures that are taken (at514) can include, for example: automatically closing and restarting the application; prompting the user to change restart the application of the non-medical client device when it is determined that the application is not loading or is not running properly; automatically powering the device off, restarting it and reopening the application; downloading and installing an up-to-date version of the application or the operating system when it is determined that the existing versions were not correct (e.g., no up-to-date and/or authentic); 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; freeing up additional computing resources for use by the application when it is determined that the application does not have access to adequate computing resources; changing a setting at the non-medical client device108 (e.g., changing a setting via the operating system of the non-medical client device108), etc.
• Each time one of the remedial correction measures is initiated (at514), themethod500 determines at516 whether that correction measure was successful. Whenever any one of the remedial correction measures is determined (at516) to have not been successful, this means that the application is not running properly and/or does not have access to required computing resources, and themethod500 can proceed to518 where the application causes a notification (e.g., an alert, alarm or other warning signal) to be generated at the non-medical client device and/or at themedical device102,104. For example, an alert or notification could be issued at theinfusion device102. Alerts or notifications can be issued until themedical device102,104 is satisfied that thenon-medical client device108 and its corresponding application are working properly (e.g., able to communicate with themedical device102,104, issue notifications, etc.) In addition, in some embodiments, at520, thenon-medical client device108 can present (e.g., via a display) suggestions to the user to suggest changes to settings on thenon-medical client device108 to correct the problem. For instance, thenon-medical client device108 can display suggested changes to notification settings, allow access to location data, activity data, a microphone of thenon-medical client device108, or provide shortcuts or links to settings that need to be changed. If themedical device102,104 fails, thenon-medical client device108 may suggest actions based last uploaded data such as insulin on board, last bolus, BG, etc. The suggestions may include instructions on how to use an insulin pen or syringe until the pump can be replaced. Thenon-medical client device108 can also send notifications to care giver or health care provided (HCP).
• When it is determined that each of the correction measures that were executed (at514) were successful, this means that the application is running properly and/or has access to required computing resources, and themethod500 loops back to504.
• FIG. 6 is amethod600 for generating a notification (alarms, alert or other warning signal) at amedical device102,104 when a notification generated at anon-medical client device108 is not acknowledged in accordance with the disclosed embodiments. As a preliminary matter, it should be understood that the steps of themethod600 are not necessarily limiting. With reference tomethod600, steps can be added, omitted, and/or performed simultaneously without departing from the scope of the appended claims. It should be appreciated that themethod600 may include any number of additional or alternative tasks, that the tasks shown inFIG. 6 need not be performed in the illustrated order, and that themethod600 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the tasks shown inFIG. 6 could potentially be omitted from an embodiment of themethod600 as long as the intended overall functionality remains intact. It should also be understood that the illustratedmethod600 can be stopped at any time. Themethod600 is computer-implemented in that various tasks or steps that are performed in connection with themethod600 may be performed by software, hardware, firmware, or any combination thereof. For illustrative purposes, the following description of themethod600 may refer to elements mentioned above in connection withFIGS. 1-3.
• In certain embodiments, some or all steps of this process, and/or substantially equivalent steps, are performed by execution of processor-readable instructions stored or included on a processor-readable medium. For instance, in the description ofFIG. 6 that follows, thenon-medical client device108 and themedical device102,104 will be described as performing various acts, tasks or steps, but it should be appreciated that this refers to processing system(s) of these entities executing instructions to perform those various acts, tasks or steps. Themethod600 can be performed by applications at thenon-medical client device108 and at themedical device102,104. Themethod600 can be used to generate a therapy-related notifications (e.g., a haptic signal, a visual signal and/or the audio signal) at themedical device102,104 to alert the user when alarms or alerts generated at thenon-medical client device108 are not acknowledged within a predetermined time threshold. Furthermore, in the description ofFIG. 6, a particular example is described in which thenon-medical client device108 and/or themedical device102,104 perform certain actions by interacting with other elements of the system described above with reference toFIGS. 1-3.
• To explain further, themethod600 begins at602 (which can be step518 ofFIG. 5) when a notification (alarm, alert, or other warning signal) is generated at the user's non-medical client device. Themethod600 then proceeds to604, where an application at thenon-medical client device108 starts a counter for an alert escalation process, and the method then proceeds to606. At606, an application at thenon-medical client device108 determines whether the notification (generated at602) at thenon-medical client device108 was acknowledged within a certain time frame. When it is determined that the notification (generated at602) at thenon-medical client device108 was acknowledged within a certain time frame, themethod600 proceeds to608 where themethod600 ends. When it is determined that the notification (generated at602) at thenon-medical client device108 was not acknowledged within a certain time frame, themethod600 proceeds to610.
• At610, the application at thenon-medical client device108 determines whether counter for the alert escalation process it greater than or equal to a threshold count. The process at610 loops back to606 until the counter for the alert escalation process is determined (at610) to be equal to the threshold count. In other words, when the application determines (at610) that the counter has not yet reached the threshold (e.g., count of the counter is less than the threshold), themethod600 loops back to606.
• When the counter for the alert escalation process is determined (at610) to be equal to the threshold count, themethod600 proceeds to612, where the application causes a notification (e.g., an alarm or alert) to be generated at themedical device102,104. In one embodiment, themedical control application105 at themedical device102,104 causes a notification (e.g., an alert or alarm such as a haptic signal, visual signal and/or audio signal) to be generated at themedical device102,104. In one embodiment, the application can also activate haptics, camera flash, override silent mode, and increase speaker or alarm volume at thenon-medical client device108 if user does not acknowledge a notification. Themethod600 proceeds to614, where themethod600 ends. The notification is used to alert the user that notifications generated at thenon-medical client device108 have not been acknowledged so that the user can then take remedial measures at thenon-medical client device108 so that the application of thenon-medical client device108 is operating/functioning properly.
• Thus, themedical device102,104 should initiate system checks for thenon-medical client device108. If thenon-medical client device108 is not functioning properly and cannot be fixed automatically or by the patient, notifications thrunon-medical client device108 should be generated. If notification is not acknowledged by patient onnon-medical client device108 thenmedical device102,104 should notify the patient. When notifications generated bymedical device102,104 are not generated at the non-medical client device108 (due to issues at the non-medical client device108), theapplication107 at thenon-medical client device108 can confirm whether the notifications have been acknowledged and send a confirmation tomedical device102,104. If thenon-medical client device108 cannot confirm that a notification was issued, it should try to correct by checking settings to see if it has access to resources (speakers, haptics, etc.), and if not suggest corrective action. If corrective action is not successful, then a notification at can be generated at one or more of themedical devices102,104. Themedical device102,104 can notify the user if acknowledgement from thenon-medical client device108 is not received within a reasonable time that can vary depending on criticality of notification. For example, an alert time to do a blood glucose check issued frommedical device102,104 may allow more time for thenon-medical client device108 to come back with an acknowledgment or correct an issue. For critical alarms such as an occlusion in line, the allowed time can be shorter.
• While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope defined by the claims, which includes known equivalents and foreseeable equivalents at the time of filing this patent application.

Claims (20)

What is claimed is:

1. 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, the method comprising:

monitoring for occurrence of a trigger event via an application at the non-medical client device;

performing, via the application at the non-medical client device when the application at the non-medical client device detects occurrence of the trigger event, one or more diagnostic checks to verify whether a medical control application at the non-medical client device is operating correctly;

attempting to initiate one or more remedial correction measures to restore the medical control application at the non-medical client device so that it is operating correctly when the application at the non-medical client device determines that the one or more diagnostic checks have failed; and

causing, via the application at the non-medical client device, the notification to be generated via a user interface of the non-medical client device when the one or more remedial correction measures were unsuccessful.

2. The method ofclaim 1, wherein the notification is a first notification, and further comprising:

starting a counter at the non-medical client device after causing the first notification to be generated via the user interface of the non-medical client device;

regularly determining, via the application at the non-medical client device, whether an acknowledgement signal was generated to acknowledge the first notification; and

causing a second notification to be generated via a second user interface of the medical device when a count of the counter exceeds a threshold count and no acknowledgement signal was generated to acknowledge the first notification, wherein the second notification is used to alert a user that the first notification generated at the non-medical client device has not been acknowledged so that other remedial measures can be taken at the non-medical client device.

3. The method ofclaim 1, wherein performing comprises:

performing a communication link verification process, via the application at the non-medical client device when the application at the non-medical client device detects occurrence of the trigger event, to determine whether the non-medical client device has an established communication link to the medical device.

4. The method ofclaim 3, wherein attempting comprises:

attempting to establish a communication link between the non-medical client device and the medical device when the application at the non-medical client device determines that the non-medical client device does not haves a communication link to the medical device.

5. The method ofclaim 4, wherein causing comprises:

causing a first notification to be generated via the user interface of the non-medical client device when the attempt to establish the communication link between the non-medical client device and the medical device is unsuccessful; and

causing a second notification to be generated via a second user interface of the medical device when the attempt to establish the communication link between the non-medical client device and the medical device is unsuccessful.

6. The method ofclaim 1, wherein performing comprises:

initiating a verification protocol, via the application at the non-medical client device when the application at the non-medical client device detects occurrence of the trigger event, wherein the verification protocol comprises: executing one or more diagnostic checks to verify whether the medical control application is functioning properly and has access to adequate computing resources, wherein the computing resources include processing resources, communication resources, user interface resources, and memory resources.

7. The method ofclaim 1, wherein the trigger event comprises one or more of:

receiving an indication that a notification needs to be acknowledged;

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.

8. The method ofclaim 1, wherein the one or more diagnostic checks to verify whether the medical control application is operating correctly comprise 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 loading properly; and

determining whether the medical control application is running properly.

9. The method ofclaim 1, wherein the one or more remedial correction measures attempt to correct issues that are causing the non-medical client device to run improperly so that the medical control application will function correctly and have access to required computing resources.

10. The method ofclaim 1, wherein the one or more remedial correction measures comprise one or more of:

automatically closing and restarting the medical control application;

prompting the user to change restart the medical control application of the non-medical client device when it is determined that the medical control application is not loading or is not running properly;

automatically powering the non-medical client device off, automatically restarting non-medical client device and reopening the medical control application;

downloading and installing an up-to-date version of the medical control application or an up-to-date version of an operating system when it is determined that the existing versions were not correct;

prompting the user to change one or more settings of the medical control application when it is determined that one or more settings of the medical control application are incorrect; and

freeing up additional computing resources of the non-medical client device for use by the medical control application when it is determined that the medical control application does not have access to adequate computing resources.

11. The method ofclaim 1, wherein the non-medical client device comprises: a smartphone, and wherein the medical device comprises one of an insulin infusion device that is configured to be controlled via the medical control application executed at the smartphone, and a glucose sensor arrangement.

12. A non-medical client device that is configured to execute a medical control application that controls a medical device, the non-medical client device comprising:

at least one processor device; and

a non-transitory processor-readable medium operatively associated with the at least one processor device, the processor-readable medium comprising executable instructions configurable 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 comprising:

monitoring for occurrence of a trigger event via an application at the non-medical client device;

performing, via the application at the non-medical client device when the application at the non-medical client device detects occurrence of the trigger event, one or more diagnostic checks to verify whether a medical control application at the non-medical client device is operating correctly;

attempting to initiate one or more remedial correction measures via the application to restore the medical control application at the non-medical client device so that it is operating correctly when the application at the non-medical client device determines that the one or more diagnostic checks have failed; and

causing, via the application at the non-medical client device, the notification to be generated via a user interface of the non-medical client device when the one or more remedial correction measures were unsuccessful.

13. The non-medical client device ofclaim 12, wherein the notification is a first notification, and the method further comprising:

starting a counter at the non-medical client device after causing the first notification to be generated via the user interface of the non-medical client device;

regularly determining, via the application at the non-medical client device, whether an acknowledgement signal was generated to acknowledge the first notification; and

causing a second notification to be generated via a second user interface of the medical device when a count of the counter exceeds a threshold count and no acknowledgement signal was generated to acknowledge the first notification, wherein the second notification is used to alert a user that the first notification generated at the non-medical client device has not been acknowledged so that other remedial measures can be taken at the non-medical client device.

14. The non-medical client device ofclaim 12, wherein performing comprises:

initiating a verification protocol, via the application at the non-medical client device when the application at the non-medical client device detects occurrence of the trigger event, wherein the verification protocol comprises: executing one or more diagnostic checks to verify whether the medical control application is functioning properly and has access to adequate computing resources, wherein the computing resources include processing resources, communication resources, user interface resources, and memory resources.

15. The non-medical client device ofclaim 12, wherein the one or more remedial correction measures attempt to correct issues that are causing the non-medical client device to run improperly so that the medical control application will function correctly and have access to required computing resources, and wherein the one or more remedial correction measures comprise one or more of:

automatically closing and restarting the medical control application;

prompting the user to change restart at least one of the medical control application, the non-medical client device and an operating system of the non-medical client device when it is determined that the medical control application is not loading or is not running properly;

automatically powering the non-medical client device off, automatically restarting non-medical client device and reopening the medical control application;

downloading and installing an up-to-date version of the medical control application or an up-to-date version of an operating system when it is determined that the existing versions were not correct;

prompting the user to change one or more settings of the medical control application when it is determined that one or more settings of the medical control application are incorrect; and

freeing up additional computing resources of the non-medical client device for use by the medical control application when it is determined that the medical control application does not have access to adequate computing resources.

16. A wireless body area network for an insulin infusion system, comprising:

a plurality of devices that are part of the wireless body area network, the plurality of devices comprising: a non-medical client device and a medical device configured to be controlled by a medical control application executed by the non-medical client device, the non-medical client device comprising:

a processor device; and

a non-transitory processor-readable medium operatively associated with the processor device, the processor-readable medium comprising executable instructions configurable 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 comprising:

monitoring for occurrence of a trigger event via an application at the non-medical client device;

performing, via the application at the non-medical client device when the application at the non-medical client device detects occurrence of the trigger event, one or more diagnostic checks to verify whether a medical control application at the non-medical client device is operating correctly;

attempting to initiate one or more remedial correction measures via the application to restore the medical control application at the non-medical client device so that it is operating correctly when the application at the non-medical client device determines that the one or more diagnostic checks have failed; and

causing, via the application at the non-medical client device, the notification to be generated via a user interface of the non-medical client device when the one or more remedial correction measures were unsuccessful.

17. The wireless body area network ofclaim 16, wherein the notification is a first notification, and the method further comprising:

starting a counter at the non-medical client device after causing the first notification to be generated via the user interface of the non-medical client device;

regularly determining, via the application at the non-medical client device, whether an acknowledgement signal was generated to acknowledge the first notification; and

causing a second notification to be generated via a second user interface of the medical device when a count of the counter exceeds a threshold count and no acknowledgement signal was generated to acknowledge the first notification, wherein the second notification is used to alert a user that the first notification generated at the non-medical client device has not been acknowledged so that other remedial measures can be taken at the non-medical client device.

18. The wireless body area network ofclaim 16, wherein the trigger event comprises one or more of: receiving an indication that a notification needs to be acknowledged; 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, and

wherein the one or more diagnostic checks to verify whether the medical control application is operating correctly comprise 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 loading properly; and determining whether the medical control application is running properly.

19. The wireless body area network ofclaim 16, wherein performing comprises:

initiating a verification protocol, via the application at the non-medical client device when the application at the non-medical client device detects occurrence of the trigger event, wherein the verification protocol comprises: executing one or more diagnostic checks to verify whether the medical control application is functioning properly and has access to adequate computing resources, wherein the computing resources include processing resources, communication resources, user interface resources, and memory resources.

20. The wireless body area network ofclaim 16, wherein the one or more remedial correction measures attempt to correct issues that are causing the non-medical client device to run improperly so that the medical control application will function correctly and have access to required computing resources, and wherein the one or more remedial correction measures comprise one or more of:

automatically closing and restarting the medical control application;

prompting the user to change restart the medical control application of the non-medical client device when it is determined that the medical control application is not loading or is not running properly;

automatically powering the non-medical client device off, automatically restarting non-medical client device, and reopening the medical control application;

downloading and installing an up-to-date version of the medical control application or an up-to-date version of an operating system when it is determined that the existing versions were not correct;

prompting the user to change one or more settings of at least one of the medical control application, the non-medical client device or an operating system of the non-medical client device when it is determined that one or more settings of the medical control application are incorrect; and

freeing up additional computing resources of the non-medical client device for use by the medical control application when it is determined that the medical control application does not have access to adequate computing resources.

Images