Patent Description:
Demand for on-body or wearable medical devices and for body area network (BAN) medical devices (e.g., wireless controllers for on-body devices, and smartphones or smart watches with a medical condition management app and/or a health/fitness app) has been increasing, along with an increase in patients' and health care providers' desire for better and more convenient patient management of medical conditions such as diabetes. For example, one type of wearable medical device is a wearable medication delivery device that is worn against a patient's skin (e.g., a patch pump with cannula or needle inserted into the patient's skin), or a pump device that can be connected to a patient's belt, for example, and having an infusion set with tubing extending from the pump to an adhesive mount with a subcutaneous cannula.

A wearable medical device can communicate wirelessly with a separate dedicated controller or smartphone (e.g., a smartphone with app configured to wirelessly interface with the wearable medical device for various operations). Bluetooth® Low Energy (BLE), marketed as Bluetooth® Smart, is a wireless technology that provides an effective, low power protocol for wirelessly connecting devices, including devices that run on power sources such as coin cell batteries as can often be the case with wearable medical devices.

A concern with wirelessly controlling a wearable medical device, particularly a device that delivers medication to a patient's body, is security of the wireless control communication link against man-in-the-middle (MITM) and eavesdropping attacks. Of particular concern is security of a wearable medical device against nefarious attacks or unintentional attacks wherein control of the medical device is undesirably altered by another device.

Another concern with wearable medical devices is the ability of users to receive alerts from their device. For example, visual alerts generated on a display of a wearable medical device can be difficult for some users to see, particularly when the display is obscured by a user's clothes or the user is visually impaired. Reference is made to prior art documents <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, and <CIT>.

The invention is as set out in independent claims <NUM> and <NUM>, preferred forms being set out in the dependent claims <NUM> to <NUM> and <NUM> to <NUM>. The problems are overcome, and additional advantages are realized, by illustrative embodiments described below.

In accordance with illustrative embodiments, a wearable medical device (e.g., wearable drug delivery pump) sends a request to another device for generation of an audible or vibratory notification at the other device, which is helpful when the wearable medical device is obscured by a user's clothing or the user vision or hearing is impaired. The other device receiving the request to generate a notification can be a remote controller or smartphone paired with the wearable medical device, or a smart watch or a Bluetooth (BT)-enabled headset or other device paired with the remote controller. The wearable medical device is configured with a BT stack that allows the device to pair with its controller in a secure bonded relationship, but to send signals requiring less security (e.g., requests for generation of notifications) to other devices (e.g., a BT-enabled headset or smart watch) using a more ubiquitous wireless protocol such as a standard BT protocol with broadcast mode.

In accordance with the invention, a medical device is provided, comprising: a radio frequency (RF) circuit configured to exchange RF signals with a second device; a memory device; and a processing device connected to the RF circuit and the memory device, and configured to detect at least one designated notification condition in the medical device, generate a request for notification in response to detection of at least one designated notification condition, and transmit via the RF circuit the request wirelessly to the second device to prompt the second device to actuate an indicator that is remote from the medical device.

In accordance with aspects of illustrative embodiments, the medical device is a wearable device. The second device is at least one device chosen from a controller and a smartphone and is paired wirelessly with the medical device, the second device having at least one indicator chosen from an audible indicator and a tactile indicator.

In accordance with aspects of illustrative embodiments, the second device is paired with a third device, and the third device comprises at least one indicator chosen from an audible indicator and a tactile indicator. For example, the third device is selected from the group consisting of a smart watch, a Bluetooth®-enabled headset, a portable monitoring device, and a Bluetooth®-enabled wristband device.

In accordance with the invention, the processing device and RF circuit of the medical device are configured to employ a selected one of at least two wireless communication protocols to exchange, via the RF circuit, RF signals with at least one device chosen from the second device and the third device. The at least two wireless communication protocols comprise a first communication protocol that is employed by the processing device to pair the second device with the medical device to securely send secure information chosen from configuration data, medical device operation data, and control signals to operate the medical device, and a second communication protocol that is employed by the processing device to pair with at least one of the second device and the third device to send information chosen from medical device status data and notifications that requires less wireless security than the secure information.

In accordance with aspects of illustrative embodiments, the medical device further comprises a user interface. The processing device is configured to operate the user interface to generate user selection prompts that guide a user to configure notification preferences based on criteria chosen from paired device selection and corresponding notification mode, wherein the paired device selection prompts a user to indicate at least one device paired with the medical device, and wherein the notification mode prompts the user to select a mode chosen from an audible mode and a tactile mode to be employed by that paired device for the notification.

In accordance with illustrative embodiments, a device is provided for generating a notification from a medical device, comprising at least one indicator; a radio frequency (RF) circuit configured to exchange RF signals with the medical device; a memory device; and a processing device connected to the at least one indicator, the RF circuit and the memory device, and configured to wirelessly receive via the RF circuit a request for notification from the medical device, the medical device generating the request for notification in response to detection of at least one designated notification condition, and to perform a notification operation chosen from generating an audible signal via the at least one indicator, wirelessly transmitting via the RF circuit a request to a third device to generate an audible signal, generating a vibratory notification signal via the at least one indicator, and wirelessly transmitting via the RF circuit a request to the third device to generate a vibratory notification signal.

In accordance with aspects of illustrative embodiments, the device is at least one device chosen from a controller and a smartphone and is paired wirelessly with the medical device. The third device is selected from the group consisting of a smart watch, a Bluetooth®-enabled headset, a portable monitoring device, and a Bluetooth®-enabled wristband device.

In accordance with aspects of illustrative embodiments, the device further comprises a user interface. The processing device is configured to operate the user interface to generate user selection prompts that guide a user to configure notification preferences based on criteria chosen from paired device selection and corresponding notification mode, wherein the paired device selection prompts a user to indicate at least one device paired with the medical device, wherein the notification mode prompts the user to select a mode chosen from an audible mode and a tactile mode to be employed by that paired device for the notification, and wherein the paired device is chosen from the device, the third device and a fourth device.

In accordance with the invention, a method of generating a notification from a medical device is provided that comprises: configuring the medical device to detect at least one designated notification condition; configuring the medical device to generate a request for notification in response to detection of at least one designated notification condition; transmitting the request wirelessly to a second device comprising an indicator, the second device actuating the indicator in response to the request; wherein the wireless transmission is employed by a selected one of at least two wireless communication protocols for the exchange, of radio frequency RF signals with the at least one other device chosen from a second device and a third device, wherein the at least two wireless communication protocols comprises a first communication protocol for pairing the second device with the medical device and securely receiving secure information chosen from configuration data, medical device operation data, and control signals to operate the medical device, and the at least two wireless communication protocols comprises a second communication protocol for pairing with at least one of the second device and the third device and sending information chosen from medical device status data and notifications that requires less wireless security than the secure information.

In accordance with aspects of illustrative embodiments, the indicator is an audio output device configured to output an audible output signal. The second device is selected from the group consisting of a cell phone, a Bluetooth-enabled ear piece, a smart watch, a portable communication device, a portable computing device, a portable wireless controller configured to control the medical device.

In accordance with aspects of illustrative embodiments, the notification condition is selected from the group consisting of an end of life state of the medical device, a corrupted memory in the medical device, near empty reservoir in the medical device, empty reservoir in the medical device, and low battery in the medical device.

In accordance with aspects of illustrative embodiments, the method of generating a notification from a medical device further comprises generating user selection prompts that guide a user to configure notification preferences based on criteria chosen from paired device selection and corresponding notification mode, wherein the paired device selection prompts a user to indicate at least one device paired with the medical device, and wherein the notification mode prompts the user to select a mode chosen from an audible mode and a tactile mode to be employed by that paired device for the notification.

In accordance with illustrative embodiments, a method of generating a notification from a medical device comprises wirelessly receiving a request for notification from the medical device at a second device, the medical device being configured to generate the request for notification in response to detection of at least one designated notification condition; and operating the second device to perform a notification operation chosen from generating an audible signal via at least one indicator, wirelessly transmitting a request to a third device to generate an audible signal, generating a vibratory notification signal via at least one indicator, and wirelessly transmitting a request to the third device to generate a vibratory notification signal.

In accordance with aspects of illustrative embodiments, the method further comprises the third device actuating an indicator in response to receiving the request transmitted from the second device.

In accordance with aspects of illustrative embodiments, the method further comprises generating, via a device chosen from the medical device, the second device and the third device, user selection prompts that guide a user to configure notification preferences based on criteria chosen from paired device selection and corresponding notification mode, wherein the paired device selection prompts a user to indicate at least one device paired with the medical device, wherein the notification mode prompts the user to select a mode chosen from an audible mode and a tactile mode to be employed by that paired device for the notification, and wherein the paired device is chosen from the second device, the third device and a fourth device.

Additional and/or other aspects and advantages of illustrative embodiments will be set forth in the description that follows, or will be apparent from the description, or may be learned by practice of the invention. The present invention may comprise one or more of the features and/or combinations of these aspects as recited in the attached claims.

The above and/or other aspects and advantages of example embodiments will be more readily appreciated from the following detailed description, taken in conjunction with the accompanying drawings, of which:.

Throughout the drawing figures, like reference numbers will be understood to refer to like elements, features and structures.

Reference will now be made in detail to example embodiments, which are illustrated in the accompanying drawings.

Problems are overcome and advantages are realized, by illustrative embodiments described below wherein a wearable medical device communicates a request for indication generation (e.g., alarms/notifications of certain wearable medical device conditions) by another wearable or portable, handheld device. The wearable medical device is configured with a Bluetooth®(BT) stack that allows the device to pair with its controller in a secure bonded relationship, but to send signals requiring less security (e.g., requests for generation of notifications) to other devices (e.g., a BT-enabled headset or smart watch) using a more ubiquitous standard BT protocol with broadcast mode. The wearable medical device communicates the request for indication generation using a standard BT protocol, which allows the wearable medical device to engage a greater variety of devices for alarm/notification generations than simply the controller to which it is paired using a proprietary BT protocol with additional security against unintended control operations of the wearable medical device by other devices.

With reference to <FIG>, an illustrative medication delivery system <NUM> is shown having a wearable medical device <NUM>, and a controller <NUM> with display <NUM> or other user interface. As will be described herein and in accordance with illustrative embodiments, the medical device <NUM> can be used with a dedicated controller <NUM> or with a smartphone with an app <NUM> configured to operate as a controller <NUM>, and the medical device <NUM> can also be connected directly, or indirectly, via its controller <NUM> to other devices <NUM> or smartphone apps <NUM> that provide additional functions. These other devices <NUM> or smartphone apps <NUM> can be related, for example, to one or more BAN devices such as a blood glucose meter, smart watch, exercise monitor, Bluetooth® headset and the like. The medical device <NUM>, the dedicated controller <NUM> or device control app <NUM> in a smartphone, and the other devices <NUM> or smartphone apps <NUM> that provide additional functions, are configured to have communication links with each other and optionally with additional devices in a LAN, WAN or internet cloud, while minimizing likelihood of MITM and eavesdropping attacks such as nefarious attacks wherein control of the medical device <NUM> is undesirably altered by another device. For example, as described below in connection with illustrative embodiments, the medical device <NUM> and the controller <NUM> can employ a secure, BLE-based intradevice communication protocol for secure control operations such as medication delivery, and a standard interdevice Bluetooth® protocol (e.g., legacy Classic Bluetooth®) can be used for pairing the medical device <NUM> with controller device <NUM> and/or devices <NUM> (e.g., Bluetooth® headsets or earpieces or smart watches) to merely generate notification or exchange information (e.g., status data or log data) but not control the medical device <NUM> configuration or dosing operations (e.g., not specifying or setting bolus amounts, initiating and terminating pump delivery operations, or providing sensitive device data such as delivered drug amounts).

The medical device <NUM> can be, for example, a disposable insulin delivery device (IDD) <NUM> for single patient use that is configured for continuous subcutaneous delivery of insulin at set and variable basal (<NUM>-hour period) rates and bolus (on-demand) doses for the management of patients with Type <NUM> Diabetes Mellitus (T2DM) requiring insulin therapy. It is to be understood, however, that the medical device <NUM> can be any on-body medical device (e.g., wearable infusion pump or continuous glucose meter) or BAN medical device (e.g., handheld blood glucose meter, smartphone with medical condition management apps, dedicated wireless controller for on-body device, smart watch, or wearable fitness and health monitor). It also is to be understood, however, that if the medical device <NUM> is a medication delivery device, it can be used to deliver any type of fluid and is not limited to insulin delivery.

The IDD <NUM> addresses an unmet need for many Type <NUM> patients on multiple daily injections (MDI) requiring a discreet, simple and cost effective insulin delivery alternative to the traditional complex insulin pump. With continued reference to <FIG>, <FIG> and <FIG>, the IDD <NUM> is part of a system <NUM> that is an advanced insulin delivery system for use by patients with T2DM. The IDD <NUM> is configured for <NUM>-hour-a-day use in all environments typically inhabited by the target users. The IDD <NUM> is configured to allow the patient user to wear the IDD for a period of three days (up to <NUM> hours). The IDD <NUM> has four (<NUM>) main functions: delivering user-set daily basal insulin rate; delivering user-set bolus insulin amount; delivering manual bolus insulin dose(s); and generating system status and notifications.

As described below, the IDD <NUM> communicates wirelessly with its controller (i.e., hereinafter referred to as the wireless controller (WC <NUM>)) through a Bluetooth® Low Energy (BLE) interface. In addition to IDD operational data, the IDD <NUM> sends feedback to the WC <NUM> if it detects issues with the IDD (e.g., memory corruption, low or empty reservoir, low battery). The WC <NUM> is configured to program the IDD <NUM> to deliver a daily basal insulin rate and bolus or food dose insulin amount to the patient. The WC <NUM> is configured to also provide status information about the system <NUM>. The WC <NUM> also enables connectivity to a BLE Wireless Connected Device Interface (BWCDI) of an external device <NUM> for data exchange. As such, WC <NUM> can send a request for generation of a notification, or optionally IDD <NUM> data, to an external device <NUM> via a BWCDI.

An important function supported by communication software in the system <NUM> is the wireless communication between the WC <NUM> and IDD <NUM>, which enables the IDD <NUM> to provide the feedback to the WC <NUM> and for the user to control their insulin delivery by the IDD <NUM> wirelessly via the WC <NUM> in a simple and discreet way. Sometimes, when the IDD <NUM> feedback to the WC <NUM> indicates an issue with the IDD (e.g., a malfunction or problem with the IDD), a notification needs to be generated and provided to the user. A notification can be, for example, a visual alert such as a display on a graphical user interface screen, or activation of a light-emitting diode (LED), provided on the IDD <NUM> or the WC <NUM>. Visual alerts, however, can be difficult for some users to see, particularly when an alert is generated at the IDD <NUM> and the IDD <NUM> is obscured by a user's clothes or the user is visually impaired.

A need therefore exists for providing enhanced notifications to a user of a wearable medical device. A number of example, enhanced notification methods and related devices are described below in accordance with illustrative embodiments. An example IDD <NUM> and example WC <NUM> are described below with reference to <FIG> for illustrative purposes. It is to be understood that the enhanced notification methods in the illustrative embodiments can be used with different medical devices <NUM> (e.g., IDDs) and controllers or WCs <NUM> having different configurations, functions and operations than those shown and described with reference to <FIG>. As described herein, the example IDD <NUM> is disposable. Accordingly, a need also exists for enhanced notifications operations of an IDD <NUM> that does not add to the complexity and cost of the IDD.

In the illustrated embodiment shown in <FIG>, the IDD <NUM> has a microcontroller <NUM> configured to control a pumping mechanism <NUM>, wireless communication with the WC (e.g., via an RF circuit <NUM> having a match circuit and antenna), and pump operations. The IDD has a bolus button(s) <NUM> for manual delivery of medication in addition to programmed delivery of medication. The pumping mechanism <NUM> comprises a reservoir <NUM> for storing a fluid medication (e.g., insulin) to be delivered via a cannula <NUM> to the patient wearing the IDD, and a pump <NUM> for controllably delivering designated amounts of medication from the reservoir through the cannula. The reservoir <NUM> can be filled via a septum <NUM> using a syringe. The IDD has a manual insertion mechanism <NUM> for inserting the cannula <NUM> into a patient; however, the processor <NUM> can be configured to operate an optional drive circuit to automate operation of the insertion mechanism <NUM> to deploy the cannula <NUM> into the patient. Further, the IDD <NUM> can be optionally provided with a fluid sensor <NUM> or a pressure sensor <NUM> for occlusion detection, for example. An LED <NUM> can be operated by the microcontroller <NUM> to be on or flash during one or more pump operations such as during reservoir priming, for example. As stated above, the LED can be obscured by the user's clothes or otherwise disposed on the IDD to not be in view once the IDD is adhered to the user's skin. The IDD <NUM> is powered by a battery and regulator as indicated at <NUM>. When initializing the IDD <NUM> (e.g., powering on to begin pairing with the WC <NUM>), the bolus button(s) <NUM> can be configured as wake-up button(s) that, when activated by the user, causes the IDD <NUM> to wake from a power conserving shelf mode. In the illustrated embodiment, the IDD <NUM> is not provided with a user interface other than wake-up button(s) since such an addition of a touch screen or other display screen to the IDD <NUM> would disadvantageously increase its cost and possibly its form factor size.

In the illustrated embodiment shown in <FIG>, the WC <NUM> can be implemented as a dual microprocessor component having: <NUM>) a WC Main Processor (WCMP) <NUM>, and a WC Communications Processor (WCCP) <NUM>. It is to be understood, however, that the WC <NUM> can be configured as a single processor device. The two processors <NUM>, <NUM> communicate with each other through a serial peripheral interface (SPI). The two processors <NUM>, <NUM> can also interrupt each other through two interrupt pins, M_REQ_INT and S_REQ_INT.

With reference to <FIG>, the WCMP <NUM> is connected to the user interface (UI) components such as the LCD display with touch screen <NUM>, one or more buttons <NUM>, optional indicator <NUM> (e.g., speaker, vibration circuit, LED, buzzer), and the like. The WCCP <NUM> is connected to radio frequency (RF) components <NUM> (e.g., an antenna and a match circuit) and is mainly responsible for the WC <NUM>'s wireless communication with the IDD <NUM>. It is to be understood, however, that the RF components <NUM> can comprise one or more antennas and related circuitry to communicate with other devices <NUM> via different communication protocols. The WC <NUM> is designed to be non-field serviceable (i.e. no parts to be inspected, adjusted, replaced or maintained by the user), except for replaceable alkaline batteries <NUM> for power. A non-volatile memory (e.g., FLASH memory) <NUM> is provided in the WC to store delivery and status data received from the IDD <NUM> such as delivery dates and times and amounts.

With continued reference to <FIG>, the LCD with capacitive touch screen <NUM> serves as the visual interface for the user by rendering visual and graphical outputs to the user (e.g., system information, instructions, visual notices, user configurations, data outputs, etc.), and by providing a visual interface for the user to enter inputs (e.g., device operation inputs such as IDD pairing and set up and dosing, and configuration parameters, and so on). The WC display with capacitive touch screen <NUM> detects at least single-touch gestures over its display area. For example, the touch screen is configured for recognizing user tactile inputs (tap, swipe, and button press), allowing for navigation within UI screens and applications. The touch screen <NUM> aids in executing specific system functionalities (i.e. IDD <NUM> setup and pairing with the WC <NUM>, insulin dosing, providing user with dosing history, and IDD deactivation and replacement with another IDD, and so on) through specific user interactions. The WC <NUM> can also include a button <NUM> such as a device wake-up button that, when activated by the user, causes the WC <NUM> to wake from a power conserving sleep mode. The WC <NUM> can also have an LED <NUM> to indicate low battery status (e.g., indicate low battery state when there is <NUM> hours or less of usage remaining).

The WC <NUM> radio frequency (RF) interface with the IDD <NUM> is, for example, based on a Bluetooth® Low Energy or BLE-based communication protocol, although other wireless communication protocols can be used. In the example medication delivery system <NUM>, the WC <NUM> and IDD <NUM> communicate wirelessly within a distance of up to <NUM> feet or approximately <NUM> meters, utilizing the ISM band from <NUM> to <NUM> spectrum. The WC <NUM> communicates with the IDD <NUM> while the IDD is adhered to the body in open air. The WC <NUM> is the central device or master, and the IDD <NUM> is the peripheral device or slave. Whenever the WCMP <NUM> wants to send information to the IDD <NUM> or retrieve information from the IDD <NUM>, it does so by interacting with the WCCP <NUM>, which in turn, communicates with the IDD <NUM> across the BLE link via the respective RF circuits <NUM> and <NUM>, as shown in <FIG> and <FIG> respectively.

<FIG> is a block diagram depicting an example device <NUM>. The device <NUM> can be a smartphone, smart watch, Bluetooth®-enabled health and/or fitness monitoring device, Bluetooth®-enabled headset or earpiece, among other Bluetooth®-enabled wireless devices <NUM>, for example. The device <NUM> comprises a processor and memory <NUM> that can be integrated or separate components. The device <NUM> can have a Bluetooth®-enabled wireless communications interface <NUM> and an optional cellular communications interface <NUM>, for example. The device <NUM> can also have different user interfaces such as one or more of a microphone <NUM>, touchscreen <NUM> or keypad or other user input device, an audio signal output device (e.g., speaker or buzzer) <NUM>, and/or another indicator such as a vibration circuit <NUM>. The WC <NUM> communicates with the device <NUM> across a BLE link, for example, via respective RF circuits and BLE wireless interfaces.

In accordance with an aspect of illustrative embodiments, the WC <NUM> (e.g., its WCCP <NUM>) and the IDD <NUM> can communicate in accordance with a specific intradevice pairing protocol and various operations to mitigate risk that the WC <NUM> pairs with an unintended IDD <NUM>' or, vice versa, that an intended IDD <NUM> pairs with an unintended WC <NUM>' as described, for example, in commonly owned PCT published applications. <CIT> and <CIT>, which are incorporated herein by reference. As defined herein, "intradevice" refers to the WC <NUM> being paired with and bonded with one particular medical device <NUM> (e.g., IDD <NUM>). Either unintended pairing scenario could cause unintended operation or control of the pumping mechanism <NUM>, potentially resulting in insulin over-infusion that can be injurious to the patient. In accordance with another aspect of illustrative embodiments, the WC <NUM> can also communicate with another device(s) <NUM> in accordance with a more ubiquitous interdevice communication protocol (e.g., a protocol that is more commonly used by different commercially available devices <NUM>), to enable the WC <NUM> to send less sensitive data than medical device control commands to various devices <NUM>. As defined herein, "interdevice" refers to the WC <NUM> being able to send selected IDD <NUM> information with one or more other devices <NUM>.

For example, Bluetooth® Low Energy (BLE), marketed as Bluetooth® Smart, is a wireless technology for establishing packet-based wireless networks among wireless devices operating in the <NUM> to <NUM> frequency range with significantly reduced power consumption compared to legacy Bluetooth® devices, which are sometimes referred to as Classic Bluetooth® devices. Low power wireless devices compliant with the Bluetooth® Smart specification are advantageous for healthcare applications because they are expected to run for long periods of time on a button or coin battery. Bluetooth® Smart Ready devices are wireless devices with dual protocol stacks capable of communicating with legacy Classic Bluetooth® devices, as well as Bluetooth® Smart devices. For example, a smartphone with IDD control app <NUM> can have Bluetooth® Smart Ready operation so that it can communicate with a legacy Classic Bluetooth® device <NUM> such as an activity monitor or continuous glucose monitor (CGM), as well as a personal device such as an IDD <NUM> having Bluetooth® Smart operation to allow for pairing using, for example, the specific intradevice pairing protocol to restrict which device <NUM> the IDD <NUM> can exchange pump operation data with and receive control commands from.

An illustrative example of a specific intradevice pairing protocol for pairing the IDD <NUM> with the WC <NUM> will now be described with reference to <FIG>, <FIG> and <FIG>. In accordance with an illustrative embodiment and as described below, the intradevice pairing protocol has particular advertising and scanning window durations, and corresponding intradevice pairing software is provided to the IDD <NUM> and WC <NUM> for a secure, bonded relationship. It is to be understood that the timing described with reference to <FIG>, <FIG> and <FIG> is for illustrative purposes and that timing specifications can be different depending on the design and inputs used for a particular device pairing application. As will also be discussed below, an interdevice, legacy Classic Bluetooth® pairing protocol available to, and commonly used among, various devices <NUM> can be also used instead for communications requiring less security than, for example, control communications for a delivery device and therefore no bonded relationship as between the IDD <NUM> and WC <NUM>.

Example IDD <NUM> advertising and WC <NUM> scanning before intradevice pairing are illustrated <FIG>. Upon waking up and before pairing, every <NUM> (+/- <NUM>%) as indicated at <NUM>, the IDD <NUM> advertises with IDD Startup Advertising Data packets <NUM>, and waits for <NUM> (+/- <NUM>%) for the possible reply from a WC <NUM>. At the WCMP <NUM>'s request, the WCCP <NUM> initiates the communication by starting scanning the IDD advertisement every <NUM> (+/- <NUM>%)<NUM> for about a <NUM> (+/- <NUM>%) scanning window <NUM>. At the end of the scanning time period <NUM>, if the WCCP <NUM> does not detect any advertising packet <NUM> within a transport layer timeout period, the WCCP stops scanning and sends a Nack response with a Transmission Timeout error code. The WCCP <NUM> goes to sleep if no advertising is detected.

The WC <NUM> can determine if a particular type of device <NUM> is in its vicinity. For example, the IDD <NUM> Startup Advertising Data can comprise IDD identifying information (e.g., selected dynamic and/or static parameters or values that identify a type of device such as manufacturer and/or model or other characteristic) such that the WC <NUM> can be configured to only pair with devices or IDDs having designated IDD identifying information and not with other devices that do have the designated IDD identifying information. Thus, if the WCCP determines that the IDD <NUM> Startup Advertising Data has IDD identifying information relating, for example, to its particular manufacturer, the WC <NUM> can pair with the advertising IDD <NUM>. If not, the WCCP <NUM> continues scanning.

Example IDD <NUM> advertising and WC <NUM> scanning after pairing are illustrated <FIG>. After intradevice pairing, and optionally when the IDD <NUM> is not actively pumping, the IDD advertises with a IDD Periodic Data Packet <NUM> at a selected interval <NUM> (e.g., every <NUM> second (+/- <NUM>%)). The IDD Periodic Data Packet can be provided with an alert code or other data indicating a condition requiring generation of a notification to the user(s) or otherwise indicating a request for notification. After each advertisement <NUM>, the IDD <NUM> waits for <NUM> (+/- <NUM>%) for the possible reply from the WC <NUM>. After pairing, at the WCMP <NUM>'s request, the WCCP <NUM> initiates the communication by starting scanning the IDD advertisement every <NUM> (+/- <NUM>%) <NUM> for a <NUM> (+/- <NUM>%) scanning window <NUM>.

Example IDD <NUM> advertising and WC <NUM> scanning during pumping are illustrated in <FIG>. If the IDD <NUM> is delivering a medication such as insulin, it can optionally advertise every <NUM> for <NUM> seconds at the end of a dispense stroke <NUM>. Even though it is not indicated in <FIG>, during the break time between IDD aspirate periods <NUM> and dispense periods <NUM>, the IDD <NUM> still tries advertising if possible. When the IDD <NUM> is pumping, at the WCMP <NUM>'s request, the WCCP initiates the communication by starting scanning the IDD advertisement every <NUM> (+/- <NUM>%) <NUM> for <NUM> (+/- <NUM>%) scanning windows <NUM>.

In the illustrated example of <FIG>, <FIG> and <FIG>, the intradevice wireless protocol implemented by the WC <NUM> and its paired IDD <NUM> configures the IDD <NUM> to only accept a control command from the paired WC <NUM> such as a wireless command to deliver insulin or to configure dosage amounts and to only send sensitive device data or information (e.g., delivered drug amounts) to the paired WC <NUM>. This bonded, specific intradevice communication relationship between the WC <NUM> and IDD <NUM> ensures that no other device can control operation of the IDD <NUM> for safety and security reasons or receive sensitive data or information, and this bonded, specific intradevice communication relationship remains until the IDD is deactivated. After IDD deactivation, the WC <NUM> is free to pair with a new IDD <NUM>; however, at any given time, the WC <NUM> is preferably only allowed to pair with one IDD <NUM>. If the WC <NUM> is a smartphone, as opposed to a dedicated wireless controller, then the smartphone can be configured with a medical device control app <NUM> that controls the smartphone's pairing and resulting bonded relationship with only one IDD <NUM> at a time.

It is to be understood, however, that a standard or legacy Classic Bluetooth® protocol can be used by the IDD <NUM> to pair with the WC or smartphone <NUM> and optionally pair with another device <NUM> (e.g., a smart watch or Bluetooth®-enabled headset or earpiece), or can be used by the WC <NUM> to pair with another device <NUM>, to merely exchange medical device data that does not require the same bonding relationship limitation of intradevice pairing protocol described above in connection with <FIG>, <FIG> and <FIG>. For example, if the IDD <NUM> is merely using the Bluetooth® link to request that a notification be generated at the WC <NUM> or other device <NUM>, and therefore the IDD <NUM> is not sending sensitive IDD operational status data or receiving commands, then a common interdevice protocol (e.g., legacy Classic Bluetooth®) can be used for pairing with and requesting notification by another device <NUM>,<NUM> that also supports the same protocol. To send less sensitive information, such legacy Classic Bluetooth®-enabled connectivity need not limit the device(s) <NUM> to which the IDD <NUM> is paired, or require specific, non-standard intervals and therefore does not require software in the IDD <NUM> and the WC <NUM> and/or other device <NUM> that supports a specific intradevice protocol for wireless connectivity having a level of security needed for safe medical device operation. In other words, the IDD <NUM> and the WC <NUM> can employ a secure, intradevice BLE-based communication protocol for secure drug delivery control operations, and a common interdevice and standard Bluetooth® protocol (e.g., legacy Classic Bluetooth) can be used for pairing the IDD <NUM> with devices <NUM> and/or devices <NUM> (e.g., Bluetooth® earpieces or smart watches) that are merely receiving requests for notifications about IDD operational problems, or collecting status or log data from the IDD <NUM>.

The medical device <NUM>, dedicated controller <NUM> and smartphone with medical device controller app <NUM> are configured to each implement at least two different wireless communication protocols for exchanging, respectively, data or signals characterized as having at least two different levels of security requirements. For example, with reference to <FIG>, <FIG> and <FIG>, the RF components <NUM> in the medical device <NUM>, the RF components <NUM> in the dedicated controller <NUM> or similar RF components in the smartphone can comprise antenna(s) and matching circuit(s) as needed to accommodate at least the two different wireless communication protocols. For example, the wearable medical device <NUM> is configured with a BT stack that allows the device <NUM> to pair with its controller <NUM> in a secure bonded relationship, but to send signals requiring less security (e.g., requests for generation of notifications) to other devices (e.g., a BT-enabled headset or smart watch) <NUM> using a more ubiquitous standard BT protocol with broadcast mode. The medical device <NUM>, controller <NUM> or medical device control app <NUM> for a smartphone are programmed or otherwise configured to determine when to use the two different wireless communication protocols, depending on the type of operation and/or the type of information to be exchanged. For example, the medical device <NUM> and controller or control app <NUM> are programmed or otherwise configured to constrain medical device configuration and control operations and related data and signals (e.g., set dose amounts, commands to initiate and terminate delivery operation, delivered drug amounts) to communication via the more secure of the two different wireless communication protocols (e.g., a specific intradevice protocol). For example, the data related to configuration and control operations that require more secure communication can be provided with metadata or stored in a designated memory location that signifies that the more secure of the two communication protocols is needed to exchange it between the medical device <NUM> and the controller or control app <NUM> and to preclude its communication to a device <NUM> that does not also employ the same secure wireless protocol such as the specific intradevice protocol. Similarly, device <NUM> requests for generation of notifications, or log or history data, that are designated to be less sensitive than device <NUM> configuration and control data can be provided with metadata or stored in a designated memory location that signifies that the less secure of the two communication protocols can be used to communicate the requests for generation of notifications or transmit the log data from the medical device <NUM> to the controller or control app <NUM> and/or device(s) <NUM> and/or from the controller or control app <NUM> to the device(s) <NUM>.

As stated above, the LED <NUM> can be used for notification. For example, the LED <NUM> can blink at critical notification(s) of the IDD <NUM>. Critical notifications can include, but are not limited to, memory corruption in the IDD <NUM>, a reservoir empty or near empty condition, a pump malfunction such as the IDD <NUM> pumping mechanism not running during an intended insulin delivery, low IDD battery, or other condition that leads to the IDD's end of life, etc. Wearable medical devices such as a patch pump <NUM> are often worn under a patient's clothing. Accordingly, if a wearable medical device has an indicator (e.g., an LED <NUM>), a patient's view of the indicator is often obscured by the patient's clothing. In addition, even if the visual indicator <NUM> is not obscured by clothing, LED notifications on a wearable medical device <NUM> may not be perceived by a vision impaired patient, or elderly or mentally impaired patient. Accordingly, a tactile and/or auditory indicator <NUM> can be helpful to these types of patients, particularly tactile indicators for deaf or hearing impaired patients.

With reference to <FIG>, apparatuses and methods are provided in accordance with three illustrative embodiments for informing a patient wearing a medical device when a critical notification occurs. As described below, the medical device <NUM> (e.g., an IDD) can be configured to: (<NUM>) generate a request for an audio signal to be generated at the WC <NUM> or another device <NUM> such as smartphone or BT-enabled headset using a BLE communication from the IDD <NUM>; and/or (<NUM>) generate a request for a vibration notification to be generated at the WC <NUM> or another device <NUM> such as a smartphone, swart watch or BT-enabled wristband (e.g., fitness monitor) using BLE communication from the IDD <NUM>; and/or (<NUM>) transmit a BLE signal from the IDD <NUM> to the WC <NUM> or another device <NUM> such as a smartphone, swart watch to request that the device <NUM> or <NUM> send a message(s) to another person (e.g., a caregiver) via the other person's smartphone, for example. One or a combination of these three notification methods can be implemented using the BT stacks of the IDD <NUM> and WC <NUM> described above. Further, if the IDD <NUM>'s request for notification generation is fulfilled by the WC <NUM> or a smartphone <NUM> configured to control IDD operation, the request can be sent using either one of the intradevice or interdevice BT protocols described above. If the IDD <NUM>'s request for notification generation is fulfilled by a device <NUM> that is not configured to control IDD operation, the request can be sent using a wireless communication protocol compatible with the device <NUM> and that may have less security associated with it such as the interdevice BT protocol described above.

The illustrative embodiments realize a number of advantages over existing wearable medical devices including, but not limited to, ensuring patients of different sensory and cognitive abilities are able to receive notifications regarding their medical device <NUM>, particularly notifications regarding critical conditions occurring in their devices <NUM>. Patients, for example, can hear an audio signal requested by their medical device <NUM>. (e.g., IDD) and generated by a BT-enabled headset <NUM> or smartphone <NUM>,<NUM> or WC <NUM>. Patients can feel a vibration requested by their medical device <NUM> and generated by their BT-enabled wristband <NUM> or at their smart phone <NUM>, <NUM> or WC <NUM>. A patient's caregiver can receive a message generated at their device (e.g., a smartphone) in response to a request for generation of message by the IDD <NUM>. It would be great to take proper action at right time. In any event, the illustrative embodiments facilitate a patient or caregiver being able to take proper action regarding the patient's medical device <NUM> condition (e.g., replace the IDD <NUM>, reset or power it one, replace battery, etc.) upon a timely notification. Further, by having the medical device <NUM> merely generate a request for a notification that is fulfilled at different device <NUM> or <NUM>, there is no need to change the existing medical device <NUM> hardware or increase medical device <NUM> complexity or cost because the request for notification can be generated and transmitted from the medical device <NUM> using a wireless communication interface already existing in the medical device <NUM>. In addition, a patient can use the enhanced notifications provided by the illustrative embodiments without hesitation in public areas because the requested notification can be a discreet vibratory notification from a smartphone or smart wristband, or an audible signal in a BT-enabled headset, for example. Security of the medical device <NUM> (e.g., IDD) and the controller <NUM> (e.g., WC) control operations is maintained because the enhanced notifications provided by the illustrative embodiments limit operations with a third device <NUM> to notifications only and not medical device <NUM> control.

<FIG> depicts generally an example medical device <NUM> (e.g., IDD) that generates a request for an audible notification. With reference to <FIG>, the request for an audible notification can be transmitted wirelessly by the IDD <NUM> to a dedicated WC <NUM>, or directly to a smartphone <NUM> operating as the IDD controller, wherein the WC or smartphone <NUM> is configured to generate an audible notification via its speaker and/or buzzer or other sound generating device. As stated above, the wireless protocol for transmitting the request for notification from the IDD <NUM> to the controller <NUM> can be either the intradevice protocol or an interdevice protocol. <FIG> depicts an illustrative embodiment wherein a patient does not have a smartphone but rather uses a dedicated wireless controller <NUM> with the IDD <NUM>. As shown in <FIG>, the IDD <NUM> can transmit a request for notification to the WC <NUM> (e.g., using either the intradevice protocol or a interdevice protocol). The WC <NUM>, in turn, is configured to transmit an audible signal to a device <NUM> such as a BT-enabled headset for playback to its user (e.g., a diabetic patient using a BT-enabled device for audio signals).

<FIG> depicts generally an example medical device <NUM> (e.g., IDD) that generates a request for a vibratory or tactile notification. With reference to <FIG>, the request for a vibratory or tactile notification can be transmitted wirelessly by the IDD <NUM> to a dedicated WC <NUM>, or directly to a smartphone <NUM> operating as the IDD controller, wherein the WC or smartphone <NUM> is configured to generate a vibratory or tactile notification via its vibratory device or other tactile indicator. Alternatively, the reusable, dedicated WC <NUM> can be configured without a tactile indicator to minimize its complexity and cost, in which case the WC <NUM> or IDD <NUM> is configured to send a request for tactile notification to a device <NUM> comprising a tactile indicator. As stated above, the wireless protocol for transmitting the request for notification from the IDD <NUM> to the controller <NUM> can be either the intradevice protocol or an interdevice protocol. To maintain security of IDD control operations, the wireless protocol for transmitting the request for notification from the IDD <NUM> or the controller <NUM> to a device <NUM> is via an interdevice protocol that is not configured to send or receive IDD control commands or sensitive device data. <FIG> depicts an illustrative embodiment wherein a patient does not have a smartphone but rather uses a dedicated wireless controller <NUM> with the IDD <NUM>. As shown in <FIG>, the IDD <NUM> can transmit a request for notification to the WC <NUM> (e.g., using either the intradevice protocol or a interdevice protocol). The WC <NUM>, in turn, is configured to transmit a request for generation of a vibratory or other tactile indication to a device <NUM> such as a smart watch or other smart wristband device that is BT-enabled or configured to communicate with the WC <NUM> via near field communication (NFC) or other wireless protocol, which can be an interdevice protocol that is not configured to send or receive IDD control commands or sensitive data. For example, the patient can use a wristband or wearable patch device <NUM> comprising a BLE interface, vibration motor and battery. Operating vibration motor or other tactile indicator electronic circuit in a remote device <NUM> to indicate a notification helps hearing impaired patients, caregivers, and patients who wear the IDD <NUM> in loud environments such as a place of employment characterized by noise from industrial plant operations or other sources (motors of equipment or airplanes) to be ensured access to notifications to timely address a critical condition detected or occurring at the IDD <NUM>.

<FIG> depicts generally an example medical device <NUM> (e.g., IDD) that (<NUM>) generates a request for an audible and/or tactile notification and transmits it to a controller <NUM> or other device that fulfills the request by outputting the requested notification(s) to the patient as described above in connection with <FIG>, and also (<NUM>) generates a request that a message be transmitted to a caregiver regarding the IDD critical condition. For example, the IDD <NUM> can pair with a WC <NUM> or smart watch or smartphone <NUM><NUM> that stores a caregiver cell number(s). The IDD <NUM> and WC <NUM> can use, for example, BLE to communicate the request for notification from the IDD <NUM> to the WC <NUM> or smartphone <NUM> operating as an IDD controller. The WC or other IDD controller <NUM> in turn can use cellular communication to complete a call to a device <NUM><NUM> used by the family member(s) or physician or school nurse or other caregiver. The device <NUM><NUM> in turn receives the message or request for a notification and generates the notification, as illustrated in <FIG>. This illustrative embodiment is advantageous because the message to the caregiver(s) is sent through a smartphone interface with wireless controller <NUM> using BLE or other interdevice protocol that need not be configured to send and receive IDD control commands. The IDD and WC do not require additional hardware for this function, thereby avoiding increased complexity and cost.

In addition, the IDD <NUM> and/or WC or other IDD controller <NUM> can be configured to allow the patient to select among different modes of enhanced, remote notifications such as vibration or tactile notification and/or audible notification, depending on the controller <NUM> and the devices <NUM> paired with the controller <NUM> and/or IDD <NUM>. For example, the controller <NUM> can be programmed to generate display screens during a set-up mode with user prompts that allow the IDD user <NUM> to indicate criteria such as paired device selection (e.g., indicating selected the device(s) <NUM> to which it is paired) and corresponding notification mode (e.g., audible mode and/or tactile mode to be employed by that paired device for the notification). For example, any of the medical device <NUM>, controller <NUM> or other device <NUM> can be configured to generate user prompts that allow a user, depending on the notification circuity and functionality at the controller <NUM> (i.e., WC or smartphone) and the paired devices (<NUM>), to select preferred type(s) of notifications to be generated at the controller <NUM> and/or device(s) <NUM>.

<FIG> is a flow chart depicting operations of an example medical device <NUM> (e.g., IDD <NUM>) to request a notification generated at another device <NUM>, <NUM> in accordance with illustrative embodiments. The IDD <NUM> can be programmed or otherwise configured to perform the operations, for example, and the operations may incorporate all or only a subset of the steps depicted in <FIG>. The IDD <NUM> is paired with a dedicated WC <NUM> or smartphone <NUM> configured to control the IDD <NUM> (block <NUM>). The IDD <NUM> is configured to monitor for conditions occurring within the IDD that require the user to be notified such as the aforementioned critical conditions, for example (block <NUM>). If a condition is detected requiring user notification (block <NUM>), the IDD <NUM> is configured to generate a request for notification (blocks <NUM> and <NUM>) for transmission to the controller <NUM> (block <NUM>) and/or another device <NUM> (block <NUM>). As stated above, if the WC <NUM> has the requisite indicator for the desired notification mode (e.g., auditory or tactile), the IDD <NUM> can transmit the request for notification using the secure BLE intradevice protocol. Alternatively, the IDD <NUM> can send the request for notification directly to a device <NUM> or via the controller <NUM> via a less secure BT interdevice protocol, for example. Upon receiving a notification (e.g., via the LED <NUM>, or via an enhanced notification generated at a device <NUM>, <NUM> remote from the IDD <NUM>, the IDD user or a caregiver can attempt to resolve the issue with the IDD that resulted in detection of a condition warranting notifying the user (block <NUM>). If the condition cannot be resolved, then the IDD <NUM> can be disabled manually by the user or caregiver, or automatically via its processor <NUM>.

<FIG> is a flow chart depicting operations of at least one other device <NUM>, <NUM> to generate the notification(s) requested by a wearable medical device (e.g., IDD <NUM>) in accordance with illustrative embodiments. With reference to block <NUM>, the device <NUM>, <NUM> is programmed or otherwise configured determine if a request for notification has been received (e.g., directly from the IDD <NUM> or from the WC <NUM> or smartphone <NUM> being used to control the IDD <NUM>). As stated above, the IDD can request remote generation of notifications at a device <NUM> and/or <NUM> using one or more modes such as an auditory mode (block <NUM>), a tactile mode (<NUM>) and a messenger mode (block <NUM>). For example, it is to be understood that the device <NUM>,<NUM> only operates in an auditory mode or a tactile mode for notification, or in different combinations of subsets of all of the modes, or in any of all of the available modes, depending on how the IDD <NUM>, WC <NUM> and/or device <NUM> are configured.

With reference to blocks <NUM> and <NUM> in <FIG>, if the medical device <NUM> (e.g., IDD) is controlled by a smartphone <NUM> (e.g., as opposed to a dedicated WC without cellular operation or limited indicators such as only an LCD display), the smartphone <NUM> can fulfill the IDD <NUM>'s request for notification by generating, respectively, an audible notification (block <NUM>) and/or tactile notification (block <NUM>). On the other hand, with reference to blocks <NUM> and <NUM> in <FIG>, if the IDD <NUM> is controlled by a dedicated WC <NUM>, for example, the WC <NUM> can fulfill the IDD <NUM>'s request for notification by generating, respectively, an audible notification (block <NUM>) and/or tactile notification (block <NUM>), depending on its hardware and software configuration for generating indications. Alternatively, with reference to blocks <NUM> and <NUM> in <FIG>, the IDD <NUM> or WC <NUM> can pair with another device <NUM> using, for example, an interdevice wireless protocol and request generation of a notification at that device <NUM>. For example, the IDD <NUM> or WC <NUM> can command a BT-enabled headset to generate an audible notification (block <NUM>). The IDD <NUM> or WC <NUM> can command a BT-enabled smart watch or other BT-wristband to generate a tactile notification (block <NUM>). Thus, the device <NUM>, <NUM> (e.g., a smartphone, WC, BT-headset, smart watch, BT-enabled wristband, or other device <NUM> with an indicator) can receive a request for notification from the IDD <NUM> directly or from an IDD controller <NUM> and generate the requested notification using its indicator hardware and/or software, depending on how the IDD <NUM> and/or controller <NUM> are configured to generate notifications or indications.

With reference to block <NUM> in <FIG>, the WC or smartphone <NUM> controlling the IDD <NUM> can store number(s) of caregiver(s) and, operating in the messenger mode, send notification (e.g., via cellular communication) to the caregiver(s) in response to receiving a request for notification from the IDD <NUM>. If the IDD <NUM> and/or WC <NUM> indicates an end of life status for the IDD <NUM>, the request fulfillment process illustrated in <FIG> can be terminated or suspended until the WC <NUM> and/or the device <NUM> pairs with a new IDD <NUM>, for example.

It will be understood by one skilled in the art that this disclosure is not limited in its application to the details of construction and the arrangement of components set forth in the description or illustrated in the drawings. The embodiments herein are capable of other embodiment: within the scope of the appended claims, and capable of being practiced or carried out in various ways. Also, it will be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. Unless limited otherwise, the terms "connected," "coupled," and "mounted," and variations thereof herein are used broadly and encompass direct and indirect connections, couplings, and mountings. In addition, the terms "connected" and "coupled" and variations thereof are not restricted to physical or mechanical connections or couplings. Further, terms such as up, down, bottom, and top are relative, and are employed to aid illustration, but are not limiting.

The components of the illustrative devices, systems and methods employed in accordance with the illustrated embodiments can be implemented, at least in part, in digital electronic circuitry, analog electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. These components can be implemented, for example, as a computer program product such as a computer program, program code or computer instructions tangibly embodied in an information carrier, or in a machine-readable storage device, for execution by, or to control the operation of, data processing apparatus such as a programmable processor, a computer, or multiple computers.

Also, functional programs, codes, and code segments for accomplishing the illustrative embodiments can be easily construed as within the scope of the invention by programmers skilled in the art to which the illustrative embodiments pertain. Method steps associated with the illustrative embodiments can be performed by one or more programmable processors executing a computer program, code or instructions to perform functions (e.g., by operating on input data and/or generating an output). Method steps can also be performed by, and apparatus of the illustrative embodiments can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit), for example.

The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an ASIC, a FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein.

Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example, semiconductor memory devices, e.g., electrically programmable read-only memory or ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory devices, and data storage disks (e.g., magnetic disks, internal hard disks, or removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks). The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.

Claim 1:
A system (<NUM>) for generating a notification from a medical device by at least one other device, the medical device (<NUM>), comprising:
a radio frequency RF circuit (<NUM>) configured to exchange RF signals with a second device;
a memory device; and
a processing device (<NUM>) connected to the RF circuit and the memory device, and configured to detect at least one designated notification condition in the medical device, generate a request for notification in response to detection of at least one designated notification condition, and transmit via the RF circuit the request wirelessly to the second device to prompt the second device to actuate an indicator (<NUM>) that is remote from the medical device;
wherein the processing device and RF circuit are configured to employ a selected one of at least two wireless communication protocols for the exchange, via the RF circuit, of RF signals with the at least one other device chosen from a second device (<NUM>) and a third device (<NUM>),
characterized in that the at least two wireless communication protocols comprises a first communication protocol employed by the processing device for pairing the second device with the medical device and for securely receiving secure information chosen from configuration data, medical device operation data, and control signals to operate the medical device, and the at least two wireless communication protocols comprises a second communication protocol employed by the processing device for pairing with at least one of the second device and the third device and for sending information chosen from medical device status data and notifications that requires less wireless security than the secure information.