Devices, methods, and systems for wireless control of medical devices

Abstract

To provide suitable devices, methods, and systems for wireless control of medical devices. [Solution] Medical device system. The system includes a first medical device, a first remote interface, and a second remote interface that communicates with the first remote interface and the first medical device, wherein the first medical device sends commands to the first medical device through the second remote interface, and when the second remote interface receives a command, the command must be confirmed by the second remote interface before the command is sent to the first medical device by the second remote interface.

Description

Technical Field

[0001] (Technical Field) The present disclosure relates to medical devices, and more particularly, to a system for controlling at least one medical device.

Background Art

[0002] (Background Information) Many potentially valuable drugs or compounds, including biological agents, are not orally effective due to poor absorption rates, hepatic metabolism, or other pharmacokinetic factors. In addition, some therapeutic compounds can be absorbed orally but may need to be administered frequently, making it difficult for patients to maintain a desired schedule. In such cases, parenteral delivery is often employed or can be employed.

[0003] Effective parenteral routes for drug delivery and other fluids and compounds, such as subcutaneous injection, intramuscular injection, and intravenous (IV) administration, involve piercing the skin with a needle or stylet. Insulin is an example of a therapeutic fluid that is self-injected by millions of diabetic patients. Users of parenterally delivered drugs can benefit from wearable devices that automatically deliver the required drug / compound over a period of time.

[0004] To achieve this objective, efforts have been made to design portable and wearable devices for the controlled release of therapeutic agents. Such devices are known to have a reservoir such as a cartridge, syringe, or bag, and to be electronically controlled. These devices have a number of drawbacks, including a malfunction rate. Reducing the size, weight, and cost of these devices is also an ongoing challenge. In addition, these devices often pose the problem of frequent repositioning for application to the skin.

[0005] For a single user, managing multiple medical devices simultaneously presents challenges. One such challenge lies in the hardware; for many medical devices, the presence of dedicated interfaces and multiple "controllers" or "handhelds" for wirelessly controlled medical devices presents logical challenges. Firstly, the various interfaces can make it difficult to direct attention from one interface to another and to the master. Secondly, recharging multiple devices can be challenging, and thirdly, transporting medical devices along with multiple controllers presents challenges. [Overview of the Initiative] [Means for solving the problem]

[0006] (summary) According to one aspect of the present invention, a medical device system is disclosed. The system includes a first medical device, a first remote interface, and a second remote interface that communicates with the first remote interface and the first medical device, wherein the first medical device transmits commands to the first medical device through the second remote interface, and when the second remote interface receives a command, the command must be confirmed by the second remote interface before the command is transmitted to the first medical device by the second remote interface.

[0007] Some embodiments of this aspect of the present invention may include one or more of the following: The first medical device is an infusion pump. The first remote interface is a medical device data system. The second remote interface is not a medical device data system. The system further comprises a blood glucose meter communicating with the second remote interface. The system further comprises a continuous glucose monitor transmitter communicating with the second remote interface. The first remote interface receives commands relating to the communication of safety-critical information to the first medical device, displays a message requesting confirmation that the communication of safety-critical information to the first medical device uses the second remote interface, transmits the communication to the second remote interface, and once confirmation is received by the second remote interface, the second remote interface communicates the command to the first medical device. The first remote interface receives input of information related to the delivery of the bolus volume of the injectable fluid by the injection pump, displays a message requesting confirmation that the delivery of the bolus volume will use the second remote interface, and once confirmation is received by the second remote interface, the second remote interface communicates the information required for the delivery of the bolus volume of the injectable fluid to the injection pump.

[0008] According to one aspect of the present invention, a medical device system is disclosed. The medical device system includes a first medical device, a first remote interface comprising a medical device data system, and a second remote interface communicating with the first remote interface and the first medical device, wherein the first medical device transmits safety-related important commands to the first medical device through the second remote interface, and when the second remote interface receives a safety-related important command, the command must be confirmed by the second remote interface before the safety-related important command is transmitted to the first medical device by the second remote interface.

[0009] Some embodiments of this aspect of the present invention may include one or more of the following: A first medical device is an infusion pump. A first remote interface is a medical device data system. A second remote interface is not a medical device data system. The system further comprises a blood glucose meter communicating with the second remote interface. The system further comprises a continuous glucose monitor transmitter communicating with the second remote interface. The first remote interface receives input of information relating to the delivery of a bolus volume of infusionable fluid by the infusion pump, displays a message requesting confirmation that the delivery of the bolus volume will use the second remote interface, and once confirmation is received by the second remote interface, the second remote interface communicates the information required for the delivery of the bolus volume of infusionable fluid to the infusion pump.

[0010] According to one aspect of the present invention, a method of communication for a medical system is disclosed. The method includes a first remote interface receiving a command relating to the communication of safety-critical information to a first medical device; the first remote interface displaying a message requesting confirmation that the communication of safety-critical information to the first medical device will use a second remote interface; the first remote interface transmitting the communication to the second remote interface; the second remote interface receiving the confirmation; and the second remote interface communicating the command to the first medical device.

[0011] Some embodiments of this aspect of the present invention may include one or more of the following: The first medical device is an infusion pump. A command relates to the delivery of a bolus of injectable fluid. A command relates to stopping the delivery of a base rate of injectable fluid. The first remote interface is a medical device data system.

[0012] According to one aspect of the present invention, a medical device system is disclosed. The medical device system includes a first medical device and a second medical device. The system also includes a remote interface, which includes a touchscreen. The remote interface communicates wirelessly with the first medical device and the second medical device. The remote interface is configured to provide a user interface to the first medical device and the second medical device. The remote interface is configured to receive user input through the touchscreen. A charging device is also included. The charging device is configured to receive at least the first medical device and the remote interface, and is configured to recharge the battery of the first medical device, and is configured to recharge the interface battery in the remote interface. The charging device is connected to a personal computer, which provides information to the remote interface.

[0013] Some embodiments of this aspect of the present invention may include one or more of the following: A first medical device is an infusion pump. The first medical device further includes at least one disposable part and at least two reusable parts, each of the two reusable parts configured to connect to at least one disposable part. A charging device is configured to receive at least one of the at least two reusable parts of the first medical device. A second medical device is a continuous glucose monitoring system comprising at least one transmitter, the at least one transmitter wirelessly communicating with a remote interface. The system further includes a third medical device wirelessly communicating with a remote interface. The remote interface is configured to provide a user interface to the third medical device. The third medical device is at least one blood glucose meter. In the system further, the wireless communication is radio frequency communication. The first medical device and the remote interface are paired using short-range communication. and / or the remote interface further comprises at least one camera.

[0014] According to one aspect of the present invention, a medical device system is disclosed. The medical device system includes a first medical device and a second medical device which communicates wirelessly with the first medical device. The system also includes a remote interface which includes a touchscreen. The remote interface communicates wirelessly with the first medical device and is configured to provide a user interface to the first medical device and the second medical device. The remote interface is configured to receive user input through the touchscreen. The system also includes a charging device which is configured to receive the first medical device and the remote interface. The charging device is configured to recharge the battery of the first medical device and is configured to recharge the interface battery in the remote interface. The charging device is connected to a personal computer which provides information to the remote interface.

[0015] Some embodiments of this aspect of the present invention may include one or more of the following: A first medical device is an infusion pump. The first medical device further includes at least one disposable portion and at least two reusable portions, each of which is configured to connect to at least one disposable portion. A charging device is configured to receive at least one of the at least two reusable portions of the first medical device. A second medical device includes a continuous glucose monitoring system, which includes at least one transmitter, the at least one transmitter communicating wirelessly with the first medical device. A second medical device includes a blood glucose meter communicating wirelessly with the first medical device. The first medical device and the remote interface are paired using near-field communication. The first medical device and the second medical device are paired using near-field communication.

[0016] According to one aspect of the present invention, an injection pump system is disclosed. The injection pump system includes at least one disposable part of an injection pump and at least two reusable parts of the injection pump, each of which is configured to connect to at least one disposable part. The system also includes a remote interface, including a touchscreen, which wirelessly communicates with at least one of the at least two reusable parts, which is configured to provide user instructions to at least one of the at least two reusable parts, and which is configured to receive user input through the touchscreen. The system also includes a charging device, which is configured to accept at least one of the at least two reusable parts and at least one of the remote interface. The charging device is configured to recharge the pump battery of at least one of the at least two reusable parts, and which is configured to recharge the interface battery in the remote interface. The charging device is connected to a personal computer, which provides information to the remote interface.

[0017] Some embodiments of this aspect of the present invention may include one or more of the following: The system further includes a continuous glucose monitoring system including at least one transmitter, the at least one transmitter communicating wirelessly with a remote interface. The system further includes at least one blood glucose meter, the blood glucose meter communicating wirelessly with a remote interface. At least one reusable part and the remote interface are paired using short-range communication. The remote interface further includes at least one accelerometer. The remote interface further includes at least one camera.

[0018] According to one aspect of the present invention, an injection pump system is disclosed. This injection pump system includes an injection pump and a remote interface device that wirelessly communicates with the injection pump, which includes instructions for controlling the injection pump, and the instructions may be synchronized with a secure web portal.

[0019] Some embodiments of this aspect of the present invention may include one or more of the following: The system further includes a continuous glucose monitoring system including a transmitter, the transmitter wirelessly communicating with a remote interface device. The system further includes a blood glucose meter, the blood glucose meter wirelessly communicating with the remote interface device. The wireless communication is radio frequency ("RF") communication. The infusion pump and the remote interface device are paired using short-range communication. The system further includes at least one accelerometer.

[0020] According to one aspect of the present invention, a medical device system is disclosed. This medical device system includes a first medical device and a second medical device which communicates wirelessly with the first medical device, the second medical device which includes instructions for controlling the first medical device, the instructions which may be synchronized with a secure web portal.

[0021] Some embodiments of this aspect of the present invention may include one or more of the following: The first medical device is an infusion pump, and the second medical device is a remote interface device. The infusion pump and the remote interface device are paired using near-field communication. The first medical device is a continuous glucose monitor sensor, and the second medical device is a remote interface device. The infusion pump and the remote interface device are paired using near-field communication. The first medical device is a blood glucose meter, and the second medical device is a remote interface device. The infusion pump and the remote interface device are paired using near-field communication.

[0022] According to one aspect of the present invention, a method for communication between two medical devices is disclosed. The method includes the first medical device transmitting an acoustic signal to the second medical device along with a wireless signal, using the acoustic signal to calculate the distance between the first medical device and the second medical device, determining whether the calculated distance exceeds a predefined threshold, and notifying the user if the calculated distance exceeds the predefined threshold.

[0023] Some embodiments of this aspect of the present invention may include one or more of the following. The first medical device is a remote interface, and the second medical device is an infusion pump. The first medical device is a remote interface, and the second medical device is a continuous glucose monitor / sender. The first medical device is a remote interface, and the second medical device is a blood glucose meter.

[0024] These aspects of the present invention are not meant to be exclusive, and other features, aspects, and advantages of the present invention will become readily apparent to those skilled in the art upon a review in conjunction with the appended claims and the accompanying drawings. This specification also provides, for example, the following items. (Item 1) A medical device system, comprising: a first medical device; a first remote interface; a second remote interface that communicates with the first remote interface and the first medical device; wherein the first medical device transmits a command to the first medical device through the second remote interface. The first medical device transmits a command to the first medical device through the second remote interface. When the second remote interface receives the command, the command must be confirmed by the second remote interface before the command is transmitted by the second remote interface to the first medical device, medical device system. (Item 2) The first medical device is an infusion pump, the medical device system according to item 1. (Item 3) The first remote interface is a medical device data system, the medical device system according to item 1. (Item 4) The second remote interface is not a medical device data system, the medical device system according to item 1. (Item 5) The system further comprises a blood glucose meter communicating with the second remote interface, the medical device system according to item 1. (Item 6) The system further comprises a continuous glucose monitor transmitter communicating with the second remote interface, the medical device system according to item 1. (Item 7) The first remote interface is Receiving a command related to the communication of important information regarding the safety to the first medical device, Displaying a message requesting confirmation that the communication of important information regarding the safety to the first medical device uses the second remote interface, Transmitting the communication to the second remote interface, Once confirmation is received by the second remote interface, the second remote interface communicates the command to the first medical device, the medical device system according to item 1. (Item 8) The first remote interface is Receiving an input of information related to the delivery of the bolus volume of the injectable fluid by the infusion pump, A message is displayed requesting confirmation that the delivery of the bolus volume will use the second remote interface. Once confirmation is received by the second remote interface, the second remote interface communicates information required for the delivery of the bolus volume of the injectable fluid to the infusion pump, as described in item 2 of the medical device system. (Item 9) A medical device system, The first medical device, A first remote interface equipped with a medical device data system, The first remote interface and the second remote interface that communicates with the first medical device Equipped with, The first medical device transmits important safety-related commands to the first medical device through the second remote interface. A medical device system in which, when the second remote interface receives the safety-related important command, the command must be verified by the second remote interface before the safety-related important command is transmitted to the first medical device by the second remote interface. (Item 10) The first medical device is an infusion pump, as described in item 9 of the medical device system. (Item 11) The first remote interface is a medical device data system, as described in item 9. (Item 12) The aforementioned second remote interface is not a medical device data system, but a medical device system as described in item 9. (Item 13) The medical device system according to item 13, further comprising a blood glucose meter communicating with the second remote interface. (Item 14) The medical device system according to item 14, further comprising a continuous glucose monitor transmitter communicating with the second remote interface. (Item 15) The first remote interface described above is The injection pump receives input of information related to the delivery of the bolus volume of the injectable fluid by the injection pump, A message is displayed requesting confirmation that the delivery of the bolus volume will use the second remote interface. Once confirmation is received by the second remote interface, the second remote interface communicates information required for the delivery of the bolus volume of the injectable fluid to the infusion pump, as described in item 10. (Item 16) A method of communication for a medical system, The first remote interface receives commands related to the communication of critical safety information to the first medical device, The first remote interface displays a message requesting confirmation that the communication of the safety-related important information to the first medical device will use the second remote interface, The first remote interface transmits the communication to the second remote interface, The second remote interface receives confirmation, The second remote interface communicates the command to the first medical device. Methods that include... (Item 17) The method according to item 16, wherein the first medical device is an infusion pump. (Item 18) The command is the method described in item 16 relating to the delivery of a bolus of an injectable fluid. (Item 19) The command relates to the method described in item 16, which involves stopping the delivery of the base rate of the injectable fluid. (Item 20) The first remote interface is a medical device data system, as described in item 16. (Item 21) A medical device system, The first medical device, A second medical device, A miniature remote interface having a touchscreen, wherein the miniature remote interface wirelessly communicates with the first medical device and the second medical device, the miniature remote interface is configured to provide a user interface to the first medical device and the second medical device, and the miniature remote interface is configured to receive user input through the touchscreen, and A medical device system equipped with the following features. (Item 22) A method for establishing secure communication, wherein the method is Establishing a communication link between medical sensors and UI devices, The process involves calculating a prime number (p) and a base (g) between the medical sensor and the UI device using the communication link, wherein the base is a primitive root modulo the prime number. The UI device generates a first random number (a), a base, which is raised to power by the first random number (a), thereby defining a first exponential part, and a first value (u) derived by multiplying the first exponential part modulo the prime number (p). The UI device communicates the first random number (a) and the first value (u) to the medical sensor, The medical sensor generates a second random number (b), a second value (v) derived by determining the base, raising it to the power of the second random number, thereby defining a second exponential part, and multiplying the second exponential part by the modulo of prime numbers, The medical sensor communicates the second random number (b) and the second value (v) to the UI device, The UI device calculates the shared key by obtaining a second value, which is also the base of the second random number, and which is raised to the power of the first random number (both raised to the power of the first random number and applied modulo the prime number), The medical device calculates a shared key by obtaining a first value raised to the power of the second random number, which is also the base raised to the power of the first random number (both raised to the power of the second random number and applied modulo the prime number), Communication between the medical sensor and the UI device using an encryption key based on the shared key. Methods that include... (Item 23) The calculation operation described above is performed using the communication link between the medical sensor and the UI device, utilizing public-private-key cryptography, in the manner of any one or more of items 22-36. (Item 24) The method of any one or more of items 22-36, wherein the operation of communicating between the medical sensor and the UI device using an encryption key based on the shared key utilizes a symmetric key, the medical sensor has a symmetric key of the symmetric key, the UI device has a second symmetric key of the symmetric key, and the symmetric key is configured to provide encrypted communication between the medical sensor and the UI device. (Item 25) The method according to any one or more of items 22-36, wherein the UI device communicates the first random number and the first value to the medical sensor by encrypting the first random number and the first value using the public key of the medical device prior to transmitting the first random number and the first value to the medical sensor. (Item 26) The method for any one or more items from items 22-36, wherein the medical sensor uses a secret key to decode the first random number and the first value, both of which correspond to the public key. (Item 27) The method of any one or more of items 22-36, wherein the medical device communicates the second random number and the second value to the UI device by encrypting the second random number and the second value using the second public key of the UI device prior to transmitting the second random number and the second value to the UI. (Item 28) The method for any one or more of items 22-36, wherein the UI device uses a secret key to decrypt the second random number and the second value, both corresponding to the UI device. (Item 29) The medical device and the UI device communicate at least one patient physiological data, according to one or more of the methods described in items 22-36. (Item 30) The medical device is used as feedback for the UI device, in the manner of any one or more of items 22-36. (Item 31) The first communication link may be an out-of-band pairing channel, as described in any one or more of items 22-36. (Item 32) The method according to any one or more items from items 22-36, wherein the out-of-band pairing channel is at least one of USB connection, Ethernet® connection, Zigbee® connection, Xbee connection, ANT connection, Lightning connection, SCSI connection, serial port connection, parallel port connection, infrared connection, and wireless USB connection. (Item 33) The encrypted communication uses a separate Bluetooth® low-energy communication link from the first communication link, as described in any one or more of items 22-36. (Item 34) The method according to any one or more of items 22-36, wherein the UI device and the medical device communicate using AES encryption with the key as the AES key. (Item 35) The method according to any one or more of items 22-36, based on the shared key, such that the encryption key is in an index to a random or pseudo-random number stream for identifying another key in order to seed the AES key. (Item 36) The method according to any one or more items from items 22-36, wherein at least one fuse coupled to one or more data lines in the medical device blows to prevent modification of the key. (Item 37) A medical system capable of reliable communication, wherein the system is A medical sensor configured to establish a communication link for communication through a communication link, A UI device configured to establish a communication link for communication through the aforementioned communication link and Equipped with, The medical sensor and the UI device are configured to use the communication link to calculate a predetermined prime number and base, wherein the base is a primitive root modulo the prime number. The UI device is configured to generate a first random number and a first value derived by determining the base, raising it to the power of the first random number, thereby defining a first exponential part, and multiplying the first exponential part by the modulo of prime numbers; the UI device is configured to communicate the first random number and the first value from the UI device to the medical sensor. The medical sensor is configured to generate a second random number and a second value derived by determining the base, raising it to the power of the second random number, thereby defining a second exponential part, and multiplying the second exponential part by the modulo of the prime numbers, and the medical sensor is configured to communicate the second random number and the second value from the medical device to the UI device. The medical sensor is configured to communicate the second random number and the second value to the UI device. The UI device is configured to calculate a shared key by obtaining the second value raised to power of the first random number (both raised to power of the first random number and applied modulo the prime number), which is also the base raised to power of the second random number. The medical device is configured to calculate the shared key by obtaining the first value raised to the power of the second random number, which is also the base raised to the power of the first random number (both multiplied by the second random number and applied modulo the prime number), A system in which the medical sensor and the UI device are configured to communicate with each other using messages encrypted using the encryption key based on the shared key. (Item 38) The system according to item 37, wherein the medical sensor and the UI device are configured to communicate over the communication link using public-private-key cryptography. (Item 39) The system according to any one or more of items 37-51, wherein the medical sensor and the UI device are configured to use a symmetric key, the medical sensor has a symmetric key of the symmetric key, the UI device has a second symmetric key of the symmetric key, and the symmetric key is configured to provide encrypted communication between the medical sensor and the UI device. (Item 40) The system according to any one or more of items 37-51, wherein the UI device is configured to communicate the first random number and the first value to the medical sensor by encrypting the first random number and the first value using the public key of the medical device prior to transmitting the first random number and the first value to the medical sensor. (Item 41) The medical sensor is configured to decode the first random number and the first value, both of which correspond to the public key, using a secret key, according to one or more of the items 37-51 of the system. (Item 42) The system according to any one or more of items 37-51, wherein the medical device is configured to communicate the second random number and the second value to the UI device by encrypting the second random number and the second value using the second public key of the UI device prior to transmitting the second random number and the second value to the UI. (Item 43) The system described in any one or more of items 37-51, wherein the UI device is configured to use a secret key to decrypt the second random number and the second value, both corresponding to the UI device. (Item 44) The system according to any one or more of the items from 37 to 51, wherein the medical device and the UI device are configured to communicate with each other using an encryption key generated using the shared key, wherein at least one patient physiological data is communicated between them. (Item 45) The medical device is a system described in any one or more of items 37-51, configured to be used as feedback for the UI device. (Item 46) The first communication link is an out-of-band pairing channel, as described in any one or more of the items 37-51. (Item 47) The out-of-band pairing channel is at least one of the following: USB connection, Ethernet® connection, Zigbee® connection, Xbee connection, ANT connection, Lightning connection, SCSI connection, serial port connection, parallel port connection, infrared connection, and wireless USB connection, as described in any one or more of the items 37-51. (Item 48) The encrypted communication uses a Bluetooth® Low Energy communication link separate from the first communication link, as described in any one or more of the items 37-51. (Item 49) The system described in any one or more of items 37-51, wherein the UI device and the medical device are configured to communicate using AES encryption with the key as the AES key. (Item 50) The encryption key is based on the shared key, such that the shared key is in an index into a random or pseudo-random number stream for identifying another key in order to seed the AES key, as described in any one or more of the items 37-51. (Item 51) A system as described in any one or more of items 37-51, wherein at least one fuse is coupled to one or more data lines in the medical device and configured to blow in order to prevent modification of the key.

[0025] These and other features and advantages of the present invention will be better understood by carefully reading the following embodiments for carrying out the invention, along with the drawings. [Brief explanation of the drawing]

[0026] [Figure 1A] Figure 1A is an exploded view of an embodiment of an injection pump. [Figure 1B] Figure 1B is an exploded view of an embodiment of an injection pump. [Figure 2] Figure 2 is an exploded view of an embodiment with an injection pump and a second reusable part. [Figure 3] Figure 3 is a perspective view of one embodiment of the disposable part of an injection pump, showing an external injection set. [Figure 4] Figures 4A and 4B illustrate an embodiment of the injection pump. [Figure 5A] Figures 5A-5C illustrate an embodiment of the injection pump. [Figure 5B] Figures 5A-5C illustrate an embodiment of the injection pump. [Figure 5C] Figures 5A-5C illustrate an embodiment of the injection pump. [Figure 5D] Figure 5D is an exploded view of an embodiment with reusable parts. [Figure 5E] Figure 5E is an exploded view of an embodiment with reusable parts. [Figure 5F] Figure 5F is an exploded view of an embodiment with reusable parts. [Figure 5G] Not specified [Figure 5H] Not specified [Figure 5I] Not specified [Figure 6] Figure 6 shows an embodiment with a remote interface. [Figure 7A] Figure 7 shows an embodiment with a remote interface. [Figure 7B] Figure 7 shows an embodiment with a remote interface. [Figure 8] Figure 8 is a diagram of one embodiment of the system. [Figure 8B] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8C] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8D]Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8E] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8F] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8G] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8H] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8I] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8J] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8K] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8L] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8M] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8N] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8O] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8P] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8Q] Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 8R]Figures 8B-8R depict various high-level schematic and flowcharts of one embodiment of the system. [Figure 9A] Figure 9A schematically depicts one embodiment of a multiprocessor-controlled configuration that may be included within one embodiment of this device. [Figure 9B] Figure 9B schematically depicts one embodiment of a multiprocessor control configuration that may be included within one embodiment of the device in several different configurations. [Figure 10A] Figures 10A and 10B schematically illustrate one embodiment of multiprocessor functionality. [Figure 10B] Figures 10A and 10B schematically illustrate one embodiment of multiprocessor functionality. [Figure 11] Figure 11 schematically illustrates one embodiment of multiprocessor functionality. [Figure 12] Figure 12 schematically illustrates one embodiment of multiprocessor functionality. [Figure 12A] Figures 12A-12E schematically illustrate various software layers according to one embodiment. [Figure 12B] Figures 12A-12E schematically illustrate various software layers according to one embodiment. [Figure 12C] Figures 12A-12E schematically illustrate various software layers according to one embodiment. [Figure 12D] Figures 12A-12E schematically illustrate various software layers according to one embodiment. [Figure 12E] Figures 12A-12E schematically illustrate various software layers according to one embodiment. [Figure 13] Figure 13 illustrates one embodiment of the system. [Figure 14] Figure 14 illustrates one embodiment of the system. [Figure 15] Figures 15A-15B illustrate one embodiment of a charging station in one embodiment of the system. [Figure 16A]Figures 16A-16F illustrate various diagrams of an embodiment of the system, specifically an embodiment of a battery charger / charging station. [Figure 16B] Figures 16A-16F illustrate various diagrams of an embodiment of the system, specifically an embodiment of a battery charger / charging station. [Figure 16C] Figures 16A-16F illustrate various diagrams of an embodiment of the system, specifically an embodiment of a battery charger / charging station. [Figure 16D] Figures 16A-16F illustrate various diagrams of an embodiment of the system, specifically an embodiment of a battery charger / charging station. [Figure 16E] Figures 16A-16F illustrate various diagrams of an embodiment of the system, specifically an embodiment of a battery charger / charging station. [Figure 16F] Figures 16A-16F illustrate various diagrams of an embodiment of the system, specifically an embodiment of a battery charger / charging station. [Figure 17] Figure 17 schematically illustrates one embodiment of the interconnection of various elements of the system. [Figure 18] Figure 18 illustrates one embodiment of the system. [Figure 19] Figure 19 illustrates one embodiment of the system. [Figure 20A] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20B] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20C] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20D] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20E]Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20F] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20G] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20H] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20I] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20J] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20K] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20L] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20M] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20N] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20O] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20P] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20Q]Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20R] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20S] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 20T] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 21A] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 21B] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 21C] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 21D] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 22A] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 22B] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 22C] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 22D] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 23A]Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 23B] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 23C] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 23D] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 24A] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 24B] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 25A] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 25B] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 25C] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26A] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26B] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26C] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26D]Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26E] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26F] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26G] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26H] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26I] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26J] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26K] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26L] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26M] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 26N] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 27A] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 27B]Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 27C] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 27E] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 27F] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 27G] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 27H] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 27I] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 28A] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 28B] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 28C] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 28D] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 28E] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 28F]Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 28G] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 28H] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 28I] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 29A] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 29B] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 29C] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 29D] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 29E] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 29F] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 30] Figure 20A-30 shows various screenshots of the remote interface according to one embodiment of the system. [Figure 31] Figure 31 shows an embodiment of a 2D barcode. [Figure 32]Figure 32 shows one embodiment of a system for programming a base profile using a remote interface and 2D barcodes. [Figure 33] Figure 33 shows information of one embodiment that may be embedded within a 2D barcode. [Figure 34] Figure 34 shows an embodiment with a basic profile that can be programmed to a remote interface using a camera. [Figure 35A] Figure 35A illustrates one embodiment of this system. [Figure 35B] Figure 35B illustrates one embodiment of this system. [Figure 35C] Figure 35C illustrates one embodiment of this system. [Figure 35D] Figure 35D illustrates one embodiment of this system. [Figure 35E] Figure 35E illustrates one embodiment of this system. [Figure 36] Figure 36 illustrates one embodiment of this system. [Figure 37] Figure 37 illustrates one embodiment of this system. [Figure 38] Figure 38 illustrates one embodiment of this system. [Figure 39] Figure 39 illustrates one embodiment of this system. [Figure 40] Figure 40 is a flowchart of one method of this system according to one embodiment. [Figure 41] Figure 41 is a flowchart of one method of the system according to one embodiment. [Figure 42] Figure 42 is a flowchart of one method of the system according to one embodiment. [Figure 43A] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43B] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43C] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43D] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43E] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43F] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43G] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43H] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43I] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43J] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43K] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43L] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43M] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43N]Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 43O] Figures 43A and 43O are various screenshots of a small remote interface according to one embodiment of this system. [Figure 44A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 44B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 45A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 45B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 45C] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 45D] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 45E] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 46A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 46B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 47A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 47B]Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 47C] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 48A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 48B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 48C] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 48D] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 49A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 49B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 50A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 50B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 51A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 51B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 52A]Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 52B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 52C] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 52D] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 53] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 54A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 54B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 54C] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 54D] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 55] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 56A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 56B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 56C]Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 57A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 57B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 57C] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58A] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58B] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58C] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58D] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58E] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58F] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58G] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58H] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58I]Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58J] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58K] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58L] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58M] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58N] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58O] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58P] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58Q] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58R] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58S] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Figure 58T] Figures 44A and 44T show various screenshots of the remote interface according to one embodiment of this system. [Modes for carrying out the invention]

[0027] (Detailed description of exemplary embodiments) definition As used in this description and the accompanying claims, the following terms shall have the meanings set forth below unless otherwise required by context.

[0028] "Remote interface" means a device for wireless communication with other devices, which may include, but is not limited to, medical devices.

[0029] "Devices" include, but are not limited to, medical devices (infusion pumps and / or microinfusion pumps, drug delivery pumps and / or devices, sensors, measuring devices and / or measuring instruments, blood pressure monitors, ECG monitors, pill dispensers, pulse oximetry monitors, CO2). 2 Any medical device includes, but is not limited to, capnometers, infusion bags, drip rate meters, temperature monitors, peritoneal dialysis machines (including, but not limited to, home peritoneal dialysis machines), hemodialysis machines (including, but not limited to, home hemodialysis machines), and any other medical devices or devices configured to deliver, handle, and / or determine medical care.

[0030] The "inputs" of the device include any mechanisms that allow the user of the device and / or remote interface and / or other operators / caregivers to control the functions of the device and / or remote interface. User inputs may include mechanical arrays (e.g., switches, push buttons, jog wheels), electrical arrays (e.g., sliders, touchscreens), wireless interfaces for communicating with the remote interface (e.g., radio frequency ("RF"), infrared ("IR"), Bluetooth®), acoustic interfaces (e.g., with voice recognition), computer network interfaces (e.g., USB ports), optical / optical imaging (including, but not limited to, camera inputs and / or images captured using a camera), sound waves, and / or other types of interfaces.

[0031] In the context of inputs such as so-called "bolus buttons" discussed below, "buttons" may be any type of user input capable of performing a desired function, and are not limited to push buttons, sliders, switches, touchscreens, and / or jog wheels.

[0032] "Alarm" includes any mechanism that may generate a warning to the user and / or a third party / operator / caregiver. An alarm may include an audio alarm (e.g., speaker, buzzer, voice generator), a visual alarm (e.g., LED, LCD screen, image), a tactile alarm (e.g., vibration element), a radio signal (e.g., remote interface or radio transmission to a caregiver), and / or other mechanisms. An alarm may be generated using multiple mechanisms simultaneously, in parallel, or in sequence, including redundant mechanisms (e.g., two different audio alarms) or complementary mechanisms (e.g., an audio alarm, a tactile alarm, and a radio alarm), and / or mechanisms that increase volume and / or intensity (e.g., a gradual increase alarm sequence).

[0033] "Fluid" shall mean a fluid line or a substance that can flow through a fluid line, such as a liquid.

[0034] "User" includes, but is not limited to, a person or animal who receives or connects to treatment from the device, whether as part of a medical treatment or otherwise, and / or a caregiver or third party who is involved in programming the device or otherwise interacting with the device, giving treatment, and / or collecting information from the device, and may include physicians and / or healthcare providers and / or companions and / or parents and / or guardians.

[0035] "Cannula" means a disposable device from which fluid can be injected into a user. As used herein, a cannula may refer to a conventional cannula / flexible tube or needle.

[0036] "Disposable" refers to a part, device, component, or other item that is intended to be used for a fixed duration and then discarded and replaced.

[0037] "Reusable" refers to a portion that is intended to have an unlimited duration of use.

[0038] "Acoustic volume measurement" means the quantitative measurement of the relevant volume using acoustic techniques, such as those described in U.S. Patent Nos. 5,349,852 and 5,641,892, and U.S. Patent Application No. 11 / 704,899, “Fluid Delivery Systems and Methods,” filed 9 February 2007 (currently U.S. Patent Publication No. US-2007-0228071-A1, published 4 October 2007) (Patent Attorney No. E70), and U.S. Patent Application No. 12 / 347,985, “Infusion Pump Assembly,” filed 31 December 2008 (currently U.S. Patent Publication No. US-2009-0299277, published 3 December 2009) (Patent Attorney No. G75) (each incorporated herein by reference as a whole), as well as other techniques.

[0039] Exemplary uses of various embodiments of the devices, methods, and systems described herein are for the delivery of insulin to people with diabetes, but other uses include the delivery of any fluid, the sensing of any medical condition and / or state, and / or the provision of medical treatment and / or medical care. Fluids may include, but are not limited to, analgesics for people suffering from pain, chemotherapy for cancer patients, and enzymes for patients suffering from metabolic disorders. Various therapeutic fluids may include, but are not limited to, small molecules, natural products, peptides, proteins, nucleic acids, carbohydrates, nanoparticle suspensions, and associated pharmaceutically acceptable carrier molecules. The therapeutically active molecule may be modified to improve device stability (e.g., by pegylation of a peptide or protein). While the illustrative embodiments herein describe drug delivery applications, these embodiments may also be used for other applications, including lab-on-a-chip applications and liquid dispensing of reagents for high-volume analytical measurements such as capillary chromatography. For the purposes of the following description, the terms “therapeutic agent,” “insulin,” and “fluid” are used synonymously, however, in other embodiments, any fluid as described above may be used. Thus, the devices, systems, methods, and their descriptions contained herein are not limited to their use in combination with therapeutic agents.

[0040] Several embodiments of the device are adapted for use by people with diabetes and / or their caregivers. Thus, in these embodiments, the device, method, and system work together to deliver insulin that complements or replaces the action of islet beta cells in people with diabetes (referred to as users). Embodiments adapted for insulin delivery seek to replace the action of islet beta cells by providing both basal and bolus levels of fluid delivery. Basal levels, bolus levels, and timing may be set by the user by using a remote interface user interface or directly by using a user interface on the device. In addition, basal and / or bolus levels may be triggered or adjusted in response to the output of one or more glucose meters and / or glucose monitors (i.e., devices) that are integrated with the remote interface or can be wirelessly transmitted, in exemplary embodiments. In other embodiments, the remote interface may include one or more sample monitoring devices, which may include a blood glucose meter / device that accepts a blood sample and / or is configured to accept a blood sample, e.g., blood glucose fragments. In some embodiments, the bolus may be triggered by the user using a designated button or other input means located on the device, i.e., on the injection pump and / or on the remote interface. In yet other embodiments, the bolus or foundation may be programmed or managed through a user interface located on either the device (e.g., on the injection pump and / or on the remote interface).

[0041] With respect to the names given to screens and screen types, as well as appropriate names given to various features, throughout the various embodiments, these terms may differ and are for illustrative purposes only. This description is not limited to these names.

[0042] Devices, systems, and methods described herein may be used to control an infusion pump. For the purposes of this description, various embodiments of the user interface and the infusion pump may be described with reference to an insulin pump, i.e., a pump that infuses insulin. However, it should be understood that the user interface may be on the infusion pump, and / or the remote interface and the medical device with which the remote interface communicates may be any medical device, i.e., not limited to an infusion pump. In addition, where the description relates to an infusion pump “screen”, this “screen” may also appear on the remote interface, or on the remote interface instead of the infusion pump.

[0043] The infusion pumps envisioned in this description include pumps capable of pumping any fluid, including, but not limited to, therapeutic fluids (including, but not limited to, insulin). Therefore, when this description describes embodiments relating to insulin, this is meant solely for illustrative purposes and is not intended to limit us to insulin. Other fluids are also envisioned. In some embodiments, the methods, systems, and devices described herein may be used in conjunction with other fluid delivery devices, such as pens and / or syringes known in the art.

[0044] The systems for controlling the devices described herein may be used for any one or more devices, and in some embodiments the device may include an infusion pump and / or infusion pump system capable of delivering fluid and / or configured to deliver fluid to a user through a cannula. For illustrative purposes only, an infusion pump system which may include at least one insulin pump is described herein. However, the system is not limited to use with one or more infusion pumps and / or insulin pump systems, but rather may be used with any device and / or any one or more devices.

[0045] Next, with reference to Figures 1A and 1B, one embodiment of device 100 is shown. In the illustrative embodiment, device 100 is an infusion pump, which may be any infusion pump; however, in some embodiments, it may be one of the embodiments of an infusion pump illustrated and described in U.S. Patent Publication No. US-2007-0228071 (E70), published October 4, 2007, or U.S. Patent Publication No. US-2009-0299277-A1 (Patent Attorney Reference No. G75), published December 3, 2009. However, as discussed above, in various other embodiments, the device may be any medical device, and in some embodiments, one or more devices are included in the system.

[0046] The device 100 includes a reusable portion 102 and a disposable portion 104. In various embodiments, the disposable portion 104 includes a reservoir and fluid lines, i.e., the “wet” components of the injection pump. In some embodiments, the disposable portion 104 includes a tab 116.

[0047] The reusable portion 102 includes mechanical and electrical components 108 configured to pump fluid from the reservoir out of the reservoir into tubing 106 which can be connected to a cannula (not shown, but indicated as 308 in Figure 3). In some embodiments, the reusable portion 102 may include a locking ring assembly 110 and a positioning projection 808 which can facilitate the rotation of the locking ring assembly 110. The reusable portion 102 may be removably engaged with the disposable portion 104, which may be achieved by, for example, a screw, twist lock, or compression fit configuration, or other configurations. In some embodiments, the reusable portion 104 may be appropriately positioned relative to the disposable portion 102, and the locking ring assembly 110 may rotate to removably engage the reusable portion 104 with the disposable portion 102.

[0048] In addition, for example, the position of the projection 112 relative to the tab 116 of the disposable housing assembly 104 may provide verification that the reusable portion 102 is fully engaged with the disposable portion 104. For example, as shown in Figure 4A, when the reusable portion 402 is properly aligned with the disposable portion 104, the projection 412 may be aligned to a first position relative to the tab 416. When the locking ring assembly 410 is rotated (in the direction of rotation indicated by the arrow in Figure 4A) to achieve a fully engaged state, the projection 412 may be aligned to a second position relative to the tab 416, as shown in Figure 4B.

[0049] Next, referring again to Figure 2, in some embodiments of the system the system may include one or more devices, and in some embodiments the system may include two devices 200, 202. In some embodiments of the system the system may include two reusable parts 200, 202 and at least one disposable part 204. In some embodiments the reusable parts 200, 202 and the disposable part 204 may be embodiments of the aforementioned device 100. In some embodiments of the system the system may include two reusable parts 200, 202, each of which may include a rechargeable power device, such as a rechargeable battery. Thus, in some embodiments one reusable part 200 is connected to the disposable part 204 and used by the user, while the other reusable part 202 may be rechargeable. Thus, in some embodiments the system may include a backup device that can be recharged or inspected while the other devices are in use.

[0050] Referring also to Figure 3, in some embodiments, the disposable portion 300 includes a tubing 302, which may include a male connector 304 connected to the tubing 302. In some embodiments, the male connector 304 is configured to connect to a female connector 306. The assumed connection between the male connector 304 and the female connector 306 provides a fluid pathway from the tubing 302 to the cannula 308, and thus from the reservoir to the cannula. The cannula 308 may be held in place on the user by a cannula adhesive pad 310. The tubing 302, male connector 304, female connector 306, cannula 308, and cannula adhesive pad 310 may collectively be referred to as the injection set 312. In some embodiments, the reusable portion 300 may be held on the user by a patch 314, which in some embodiments may be, for example, a disposable adhesive patch (connected to the lower surface of the disposable portion 300, where the adhesive is exposed and then attached to the user) or a hook-and-loop fastener patch. In embodiments where the disposable patch is a hook-and-loop fastener patch (e.g., a hook-and-loop fastener system provided by VELCRO USA Inc. (Manchester, NH)), the lower surface of the disposable portion 300 may include a complementary hook or loop surface.

[0051] Next, referring again to Figures 5A-5F, in some embodiments, the reusable portion 500 may include an input switch assembly configured to receive user commands (e.g., bolus delivery, pairing with a remote interface, or equivalent). In some embodiments, the input switch assembly may include a button 824 which may be located within an opening 526 of the body 520. As shown, for example in Figure 5B, the locking ring assembly 506 may include a radial slot 528 which may be configured to allow the locking ring assembly 506 to rotate relative to the body 520, while still providing easy access to the button 524.

[0052] Referring still to Figures 5A-5F, the electrical control assembly 516 may include a printed circuit board 530 and, in some embodiments, a battery 532, which may be a rechargeable battery. The printed circuit board 530 may include various control electronics for monitoring and controlling the amount of injectable fluid that has been pumped and / or is being pumped. For example, the electrical control assembly 516 may measure the amount of injectable fluid that has just been dispensed and determine whether a sufficient amount of injectable fluid has been dispensed based on the dose requested by the user. If sufficient injectable fluid has not been dispensed, the electrical control assembly 516 may determine that more injectable fluid should be pumped. The electrical control assembly 516 may provide an appropriate signal to the mechanical control assembly 512 so that any additional required dose may be pumped, or the electrical control assembly 516 may provide an appropriate signal to the mechanical control assembly 512 so that the additional dose may be dispensed together with the next dose. Alternatively, if too much injectable fluid has been dispensed, the electrical control assembly 516 may provide an appropriate signal to the mechanical control assembly 512 so that less injectable fluid may be dispensed in the next dose. The electrical control assembly 516 may include one or more microprocessors. In an exemplary embodiment, the electrical control assembly 516 may include three microprocessors. One processor (for example, but not limited to, a CC2510 microcontroller / radio frequency ("RF") transceiver available from Chipcon AS (Oslo, Norway)) may be dedicated to, for example, wireless communication for communicating with a remote interface. Two additional microprocessors (an example of which, but not limited to, the MSP430 micro-remote interface available from Texas Instruments Inc. (Dallas, Texas)) may be dedicated solely to issuing and executing commands (e.g., for dispensing a certain dose of injectable fluid, for processing feedback signals from a volumetric device, and equivalent).

[0053] As shown in Figure 5C, the base plate 518 may provide access to electrical contacts 534, which can be electrically connected, for example, to an electrical control assembly 516 for a rechargeable battery 532. The base plate 518 may include one or more features (e.g., openings 536, 538) that can be configured to facilitate proper alignment with the disposable housing assembly 504 via cooperating features (e.g., tabs) of the disposable housing assembly 504. In addition, the base plate 518 may include various features for mounting the valve assembly 514 and the electrical control assembly 516, and for providing access to the disposable portion 504 by the valve assembly 514 (shown in Figures 5D-5F).

[0054] The locking ring assembly 506 may include grip inserts 540, 542, which may include, for example, an elastomer or a textured material, that can facilitate gripping and twisting of the locking ring assembly 506 to engage / disengage the reusable portion 500 and the disposable portion 504. In addition, the locking ring assembly 506 may include one or more sensing components, which may be a magnet 544 in some embodiments, but in other embodiments may be electrical contacts or other sensing components. In various embodiments, the sensing components may interact with one or more components of the reusable portion 500 (e.g., a Hall effect sensor) to provide, for example, an indication of the nature of a meshing component (e.g., which may, in some embodiments, include, but not limited to, one or more of the disposable portion 504, a charging station, or a filling station) and / or whether the reusable portion 500 is properly engaged with the meshing component. In some embodiments, a Hall effect sensor (not shown) may be located on the pump printed circuit board 530. The Hall effect sensor may detect when the locking ring assembly 506 is rotated to the closed position. Therefore, in some embodiments, the Hall effect sensor, together with the magnet 544, may provide a system for determining whether the locking ring assembly 506 has been rotated to the closed position.

[0055] The sensing component (magnet) 544 may cooperate with a reusable component, i.e., a Hall effect sensor in some embodiments, to provide a determination of whether a reusable component 500 is properly attached to its intended component or device. In some embodiments, the locking ring assembly 506 may not have to swivel if not attached to a component, which may include, but are not limited to, a disposable component 504, a dust cover (not shown), or a battery charger (not shown). Thus, the sensing component 544, together with the reusable component 500, may function to provide the injection pump system with many advantageous safety features. These features may include, but are not limited to, one or more of the following: If the system does not detect that a disposable component 504, a dust cover, or a charger is attached, the system may notify, warn, or alarm the user that the reusable component 500, e.g., a valve and a pumping component, may be contaminated or damaged, thereby compromising the integrity of the reusable assembly. Thus, the system may provide the user with an integrity alarm to warn of a potential threat to reusable integrity. Furthermore, if the system detects that a reusable assembly is attached to a dust cover, the system may turn off the power or reduce the power to conserve energy. This can provide more efficient use of power if the reusable parts are not configurably connected to interact with each other.

[0056] The reusable portion 500 may be attached to several different components, including but not limited to a disposable housing assembly, a dust cover, or a battery charger / battery charging station. In any case, a Hall effect sensor may detect that the locking ring assembly 506 is in the closed position, and therefore the reusable portion 500 is detachably engaged with the disposable portion 504, the dust cover, or the battery charger / battery charging station (or, in various embodiments, another component). The injection pump system may determine the component to which it is attached by using an AVS system, such as those described in the aforementioned referenced patent publications and patents, or by electronic contacts. Next, referring again to Figure 5G-5I, one embodiment of a dust cover (e.g., dust cover 539) is shown. In an exemplary embodiment, the dust cover 539 may include features 541, 543, 545, 547 such that the locking ring assembly 506 of the reusable portion 500 can detachably engage with the dust cover 539. In addition, the dust cover 539 may further include a recessed area 5849 for accommodating the valve action and pumping features of the reusable portion 500. For example, with respect to the dust cover, the AVS system may determine that the dust cover is connected to the reusable portion and not to the disposable portion. The AVS system may use a lookup table or other comparison data to compare and distinguish between the measured data and the data of the characteristic dust cover or the empty disposable portion. With respect to the battery charger, the battery charger may include electrical contacts in some embodiments. When the reusable portion is attached to the battery charger, the injection pump assembly electronic system may sense that contact has been made and therefore indicate that the reusable portion is attached to the battery charger.

[0057] Various embodiments of the injection pump may include, or be similar to, a reservoir assembly configured to contain an injectable fluid. In some embodiments, the reservoir assembly is incorporated herein by reference to U.S. Patent No. 7,498,563, “Optical Displacement Sensor for Infusion Devices” (Patent Attorney No. D78), issued March 3, 2009 (incorporated herein as a whole by reference), and / or U.S. Patent No. 7,306,578, “Loading Mechanism for Infusion Pump” (Patent Attorney No. C54), issued December 11, 2007, PCT application PCT / US2009 / 060158, “Infusion Pump Assembly” filed October 9, 2009 (current publication WO2010 / 042814, published April 15, 2010) (Patent Attorney No. F51WO), and / or U.S. Patent Application No. 12 / 249,882, “Infusion Pump” filed October 10, 2008 The reservoir assembly may be similar to those described in "Assembly" (current U.S. Patent Publication No. US-2010-0094222, published April 15, 2010) (Patent Attorney No. F51), and / or U.S. Patent Application No. 13 / 076,067 "Infusion Pump Methods, Systems and Apparatus" filed March 30, 2011 (current U.S. Patent Publication No. US-2011-0230837, published September 22, 2011) (Patent Attorney No. I70), and / or U.S. Patent Application No. 13 / 121,822 "Infusion Pump Assembly" filed March 30, 2011 (current U.S. Patent Publication No. US-2011-0208123, published August 25, 2011) (Patent Attorney No. I73) (all incorporated herein by reference as a whole).

[0058] In some embodiments, various embodiments of the infusion pump may include, or be similar to, one or more described in U.S. Patent No. 7,306,578, “Loading Mechanism for Infusion Pump,” issued December 11, 2007 (Patent Attorney No. C54), U.S. Patent Application No. 12 / 249,882, “Infusion Pump Assembly,” filed October 10, 2008 (currently U.S. Patent Publication No. US-2010-0094222, published April 15, 2010) (Patent Attorney No. F51), and U.S. Patent Application No. 12 / 249,891, “Infusion Pump Assembly,” filed October 10, 2008 (currently U.S. Patent Publication No. US-2009-0099523, published April 16, 2009) (Patent Attorney No. G46) (all incorporated herein by reference as a whole).

[0059] In some embodiments, the device, which may be an injection pump such as those described above, includes hardware for radio frequency ("RF") communication with a remote interface. However, in various embodiments, the device may be any device and is not limited to an injection pump. In some exemplary embodiments of the system, the device may include a display assembly, which may include at least one screen or other display, including a visual display to a user, but is not limited to this. However, in other embodiments, such as those shown in Figures 1A-5F, the device may not include a display assembly. In these embodiments, the display assembly may be included on the remote interface. In some embodiments of the system, even if the device includes a display, the system may also include a remote interface, which also includes a display. Several embodiments of the remote interface are shown in Figures 6, 7, 7A, and 8.

[0060] Referring not only to the injection pump system shown in Figure 1A-5I, but also to other devices that may be used in conjunction with the system, the device may include processing logic (not shown), which may be called one or more processors, that perform one or more processes that may be required for the device to operate. The processing logic may include one or more microprocessors (not shown), one or more input / output remote interfaces (not shown), and a cache memory device (not shown). One or more data buses and / or memory buses may be used to interconnect the processing logic with one or more subsystems.

[0061] If the system requires interaction between a user and a device, the interaction may be achieved using inputs, either on a remote interface or on the device. For example, in some embodiments, if the device is an injection pump, the inputs on the device may be a switch assembly on the injection pump.

[0062] In some embodiments, the processing logic is used to receive input from the user. The user may use one or more input devices or assemblies, including, but not limited to, button / switch assemblies, slider assemblies, capacitive sliders (including, but not limited to, any sliders described in, for example, U.S. Patent Application No. 11 / 999,268, “Medical Device Including a Slider Assembly,” filed 4 December 2007 (current U.S. Patent Publication No. US-2008-0177900, published 24 July 2008) (Patent Attorney Reference No. F14) (incorporated herein by reference as a whole)), jog wheels, audio inputs, tactile inputs, and / or touchscreens. In some embodiments, the device may also receive input from internal systems. These internal systems may include, for example, in embodiments where the device is an injection pump, one or more of the following: occlusion detection processes, confirmation processes, and volume measurement techniques, such as acoustic volume sensing ("AVS"). Using these inputs, the device, which in some embodiments may be an injection pump, may generate outputs, e.g., including, but not limited to, delivery of injection fluid to the user, and / or these inputs may generate outputs, which may include, but not limited to, one or more of comments, warnings, alarms, or alerts to the user. Inputs are therefore made either directly from the user to the device, directly from the device system to processing logic, or from another device or remote interface to the device. User interaction experiences therefore include, but not limited to, interactions with a display (on the device itself or a remote interface or both), including reading / viewing text and / or graphics on the display, e.g., direct interaction with the display through a touchscreen, interaction with one or more buttons, sliders, jog wheels, or other inputs, interaction with one or more glucose flake readers, and sensing through either tactile or auditory, one or more vibration motors, and / or audio systems.Therefore, the term "user interface" is used to encompass all systems, methods, and devices that a user uses to interact with a device and to control and / or receive information from that device.

[0063] Next, referring to Figures 6 and 7A-7B, in some embodiments of the injection pump system, the injection pump may be remotely controlled using remote interfaces 600, 700. Two embodiments of the remote interface are shown, however, in various other embodiments, the remote interface may be any type of device capable of interacting with the device, including via radio and / or telecommunications. The remote interfaces 600, 700 may include all or part of the functionality of the device, which in some embodiments may include an injection pump similar to that illustrated and described herein with respect to Figure 1A-5I. As discussed above, for illustrative purposes, the device may be described as an injection pump, however, this disclosure is not limited to an injection pump. Furthermore, the systems, methods, and apparatus described herein may be used in conjunction with any device.

[0064] In some embodiments of the injection pump described above, the injection pump may be configured using remote interfaces 600, 700. In these embodiments, the injection pump may include telemetry circuitry (not shown) that enables communication (e.g., wired or wireless) between the injection pump and the remote interfaces 600, 700, and thus enables the remote interfaces 600, 700 to remotely control the injection pump. The remote interfaces 600, 700 (which may also include telemetry circuitry (not shown) and may be able to communicate with the injection pump) may include display assemblies 602, 702 and at least one input assembly which may include an input control device (such as a jog wheel 606, a slider assembly 610, or another conventional mode for input to the device) and / or one or more switch assemblies 604, 608, 704. Therefore, the remote interface 600 includes a jog wheel 606 and a slider assembly 610, as shown in Figure 6, although some embodiments may include only one of the jog wheel 606 or the slider assembly 610, or another conventional mode for input to the device. In embodiments having a jog wheel 606, the jog wheel 606 may include a wheel, ring, knob, or equivalent, which can be coupled to a rotary encoder or other rotary transducer to provide a control signal based on the movement of the wheel, ring, knob, or equivalent.

[0065] In some embodiments, the remote interface may include a touchscreen, in which case the touchscreen may include one or more icons 706, 710 indicating the functionality of the remote interface 700, as depicted in Figures 7A and 7B. In some embodiments, one or more icons 706, 710 may relate to a launch application configured to communicate with a device. As shown in Figure 7A, in some embodiments, one or more icons 706 may represent one or more devices, which in some embodiments may be medical device (e.g., medical device 1, medical device 2, medical device 3) applications. However, in various embodiments, fewer than three icons 706 may be included on the remote interface 700. Also, as shown in Figure 7A, in some embodiments, the remote interface 700 may include icons 710 related to launch applications related to another functionality of the remote interface 700 (in addition to communication with at least one device). In some embodiments, these may include, but are not limited to, launching a web browser, launching a mobile phone or mobile phone functionality, and / or launching MP3 or other "audio" player functionality. In some embodiments, it may be desirable for the user to "activate" various functions and / or applications of the remote interface 700. In some embodiments, non-device-related functionality may remain dormant and / or "sleep" until activated. This may be desirable for several reasons, including, but not limited to, extending battery life and / or preventing interference and / or slowing down operation with respect to the use of the remote interface 700 for communicating with one or more devices. In some embodiments, once a device is paired with the remote interface 700 (as described in more detail below), the application may be activated automatically.In some embodiments, an icon 706 relating to a device on the remote interface 700 may indicate that the "application" is "minimized" on the display 702, but that the application is active. Therefore, in some embodiments, launching the application associated with the device using the icon 706 may not be necessary and may be automated once the remote interface 700 is paired with the device. Referring to Figure 7B, in some embodiments, the remote interface 700 may include various buttons on the display assembly, which are links for adding notes and / or tags to a logbook. Therefore, in some embodiments, when a user taps one of the buttons, a note may be opened, and the user may add the note to the logbook. In some embodiments, tapping an icon may automatically register the event in the logbook.

[0066] Various embodiments of the remote interface may include the ability to pre-program base rates, bolus alarms, delivery restrictions, user profiles, etc., and may allow the user to view history, logbooks, etc., and establish user preferences. In some embodiments, the remote interface may also include a glucose flake reader. However, in various embodiments, the capabilities of the remote interface may differ when the remote interface communicates with a device other than the infusion pump.

[0067] In some embodiments, during use, the remote interfaces 600, 700 may communicate with the injection pump assembly using a wireless communication channel established between the remote interfaces 600, 700 and the injection pump. Thus, the user may program / configure the injection pump using the remote interfaces 600, 700. In some embodiments, some or all of the communication between the remote interfaces 600, 700 and the injection pump may be encrypted to provide an enhanced level of security.

[0068] In various embodiments of the user interface, the user interface may require user confirmation and / or user input. In some embodiments, the user interface focuses on ensuring that the user understands the effects of various interactions with the device. Many embodiments will be presented throughout this description of a device that communicates the results of the user's actions to the user. These features ensure that the user understands the actions and therefore provide the user with greater security. One such embodiment is that if the user presses the back button on the screen after a value has changed, the user interface displays a confirmation screen asking, "Do you want to undo the changes?" If the user selects "Yes," in various embodiments, the user interface discards any pending changes, closes the confirmation screen, and returns to the previous screen (i.e., the screen before the screen where the user pressed the back button). If the action selection is "No" on the "Do you want to cancel the changes?" confirmation screen, the user presses the return button or other, depending on the embodiment, and the user interface closes the confirmation screen and returns to the screen with the pending changes. This feature prevents the user from assuming that the changes have been implemented when they have not. Therefore, this feature prevents such a situation and ensures that the user understands that the changes have not been implemented. This is just one of many embodiments of a user interface that requires user confirmation and / or input.

[0069] In addition, referring to Figure 8, in some embodiments of the device, device 800 may be comprised of a remote interface 802. In some embodiments, device 800 may include telemetry circuitry (not shown) that enables communication (e.g., wired or wireless) between device 800 and at least one remote interface 802, and thus enables the remote interface 802 to communicate remotely with device 800. The remote interface 802 (which may also include telemetry circuitry (not shown) and be able to communicate with device 800) may, in various embodiments, include a display assembly 804 and at least one input assembly 806. In some embodiments, the input assembly 806 may include at least one switch assembly, and in some embodiments, it may include, but is not limited to, one or more of the aforementioned input assemblies. Thus, in some embodiments, the input assembly may include a jog wheel, a plurality of switch assemblies, a capacitive slider, or equivalent.

[0070] The remote interface 802 may include the ability to issue commands to the device and / or receive information from the device. In some embodiments, the remote interface 802 may include the ability to view history, receive and view alarms, program restrictions, such as delivery restrictions, and / or establish user preferences. In some embodiments, the remote interface 802 may allow the user to view the status of the device, which may include power status, delivery status, read values, alarm status, device progress, and / or any other data that can be communicated from the device to the remote interface 802. In some embodiments, the remote interface 802 may include a glucose flake reader and / or a temperature display device, and / or other medical functionalities that may be desired for performing treatment and / or diagnosis, and / or providing medical services to the user.

[0071] In some embodiments, the remote interface 802 may provide instructions to the device 800 via a wireless communication channel 808 established between the remote interface 802 and the device 800. Thus, a user may use the remote interface 802 to program / configure the device 800. Some or all of the communication between the remote interface 802 and the device may be encrypted to provide an enhanced level of security.

[0072] Communication between the remote interface 802 and the device 800 may be achieved using a standard communication protocol. Furthermore, communication between the various components contained within the device 800 may be achieved using the same protocol. An example of such a communication protocol is the Packet Communication Gateway Protocol (PCGP) developed by DEKA Research & Development (Manchester, NH). As discussed above, in some embodiments, the device 800, which may be an injection pump, may include an electrical control assembly 516 that may include one or more electrical components. For example, the electrical control assembly 516 may include a plurality of data processors (e.g., a supervisor processor and a command processor) and a wireless processor to enable the device 800 to communicate with the remote interface 802. Thus, the remote interface 802 may include one or more electrical components, and examples of such components include, but are not limited to, a command processor and a wireless processor to enable the remote interface 802 to communicate with the device 800. A high-level diagram of an example of such a system is shown in Figure 8B.

[0073] Each of these electrical components may be manufactured by a different component supplier and therefore may utilize its own (i.e., unique) communication commands. Thus, efficient communication between such heterogeneous components may be achieved through the use of standard communication protocols.

[0074] PCGP may be a flexible and extensible software module that may be used on the processors in device 800 and remote interface 802 to construct and route packets. PCGP may abstract various interfaces and provide a unified application programming interface (API) to various applications running on each processor. PCGP may also provide adaptive interfaces to various drivers. For illustrative purposes only, PCGP may have the conceptual structure shown in Figure 8C for a given processor.

[0075] PCGP may ensure data integrity by utilizing periodic redundancy checks (CRC). PCGP may also provide guaranteed delivery status. In a non-limiting embodiment, all new messages should have a reply. If such a reply is not sent back in a timely manner, the message may time out, and PCGP may generate a negative response reply message (i.e., NACK) to the application. Thus, the message reply protocol may inform the application whether it should retry sending the message.

[0076] In some embodiments, PCGP may also limit the number of in-flight messages from a given node, be coupled with a flow control mechanism at the driver level to provide a deterministic approach to message delivery, and provide individual nodes with different amounts of buffer without dropping packets. When a node runs out of buffer, the driver may provide back pressure to other nodes to prevent them from sending new messages.

[0077] PCGP may use a shared buffer pool scheme to minimize data copying and may avoid mutual exclusion, which may have a slight impact on the APIs used to send / receive messages to / from applications and a more significant impact on drivers. PCGP may use a “bridge” base class that provides routing and buffer ownership. Major PCGP classes may be subdivided from the bridge base class. In some embodiments, drivers may be derived from bridge classes, communicate with derived bridge classes, or own them.

[0078] In some embodiments, PCGP may be designed to operate in an embedded environment with or without an operating system by using semaphores to protect shared data, so that some calls are reentrant and can operate on multiple threads. One non-restrictive illustrative example of such an implementation is shown in Figure 8D. PCGP may operate in the same way in both environments, but there may be versions of calls for a particular processor type (e.g., ARM9 / OS version). Thus, in some embodiments, the functionality may be the same, but there may be an operating system abstraction layer with slightly different calls tailored to, for example, an ARM 9 Nucleus OS environment.

[0079] Referring also to Figure 8E, PCGP may do the following: • Enables multiple send / reply calls. • Has multiple drivers that operate asynchronously for RX and TX on different interfaces, and / or • Provides packet ordering for sending / receiving, and a deterministic timeout for message transmission.

[0080] In some embodiments, each software object may request the buffer manager for the next buffer to use and then give that buffer to another object. Buffers may pass automatically from one exclusive owner to another, and queues may arise automatically by ordering buffers by sequence number. In some embodiments, when a buffer is no longer in use, it may be recycled (for example, an object may attempt to give the buffer to itself or release it to the buffer manager for later reallocation). Thus, in some embodiments, data generally does not need to be copied, and routing simply overwrites the buffer owner bytes.

[0081] Such implementations of PCGP can offer various benefits, and examples of such implementations may include, but are not limited to, the following: • Once a message enters a buffer, it can persist there until it is forwarded or received by an application, making it impossible to drop a message due to buffer exhaustion. • Offsets are used to access the driver, PCGP, and buffer payload sections, so data does not need to be copied. The driver may change ownership of the message data by overwriting one byte (i.e., the buffer ownership byte). Mutual exclusion may only be necessary when a single buffer owner may want to use the buffer simultaneously or acquire a new sequence number; therefore, the need for multiple exclusions, except for reentrant calls, may not be necessary. There may be fewer rules for application writers to follow in order to implement a reliable system. Since there is a set of calls provided by the driver to push / pull data outside the buffer management system, the driver may use an ISR / push / pull / and polled data model. The driver does not need to perform copying, CRC, or any other checks, as destination bytes, CRC, and other checks can be performed later from the ISR hotpath, so the driver does not need to be very active except for TX and RX. • Because the buffer manager can order accesses by sequence number, queue ordering can occur automatically. • Smaller code / variable occupied area may be used, meaning the hot passcode may be smaller, potentially resulting in lower overhead.

[0082] As shown in Figure 8F, when a message needs to be sent, PCGP may quickly construct a packet and insert it into the buffer management system. Once inside the buffer management system, a call to "packetProcessor" may apply the protocol rules and deliver the message to the driver / application.

[0083] To send a new message or a reply, PCGP may do one or more of the following: For example, check the call arguments to ensure that the packet length is valid and the destination is correct. - Downlink may allow PCGP to be used by the radio processor to establish links, pairs, etc., and may notify the application when PCGP is attempting to communicate over a non-functional link (instead of timing out), in some embodiments, to avoid attempting to send messages over a down link unless it is a radio link node. - Obtain the sequence number of a new message, or use the existing sequence number of an existing message. • Construct the packet, copy the payload data, write it to the CRC, and (from this point onward) the packet's integrity may be protected by the CRC. and / or · As a reply or a new message, giving the message to the buffer manager and putting this buffer into the buffer manager checks whether it exceeds the maximum number of transmission messages in the standby state.

[0084] Also, referring to FIGS. 8G - 8H, in some embodiments, the PCGP may operate by performing all of the main operations in one thread so as to avoid mutual exclusion and to avoid performing a great deal of work in transmission / reply or driver calls. The "packetProcessor" call may need to apply protocol rules to replies, new transmission messages, and received messages. The reply message may simply be sent, but for new messages and received messages, there may be rules for sending the message. In each case, the software may loop while the correct type of message is able to apply the protocol rules until it becomes unable to process the packet.

[0085] The transmission of new messages may, in some embodiments, follow one or more of the following rules. · Only two messages may be the permitted "in - flight" on the network. And / or · Sufficient data regarding the in - flight message may be stored to match the response and handle the timeout.

[0086] The reception of messages may follow the following rules. · Since a matching response may clear the "in - flight" information slot, a new packet can be sent. · A non - matching response may be dropped. · The new message may be for the protocol (e.g., obtaining / clearing network statistics for this node). · A buffer may be given to the application to receive the message, and callbacks may also be used. And / or · The buffer may be released or remain owned by the application.

[0087] Thus, in some embodiments, the PCGP may be configured as follows. The callback function may copy the payload data out or may fully consume it before returning. · The callback function may copy the payload data that it fully processes or consumes before returning. · The callback function may own the buffer, may reference the buffer's payload by the buffer and payload address, and the message may be processed later. · The application may poll the PCGP system about received messages, and / or · The application may use a callback to set an event and then poll about received messages.

[0088] The communication system may have a limited number of buffers. When there are no buffers left for the PCGP, the driver may stop receiving new packets, and the application may be informed that the application cannot send new packets. To avoid this and maintain optimal performance, the application may attempt one or more procedures, examples of which may include, but are not limited to, the following. a) The application may keep the PCGP up-to-date in a wireless state. Specifically, in some embodiments, if the link goes down and the PCGP is not aware, the PCGP may receive new messages to send and put them in a queue (or may not optimally timeout the messages), which may interfere with the send queue and delay the application from optimally using the link. b) The application may periodically call “decrement timeout”. Optimally, in some embodiments, the application may call “decrement timeout” every 20 to 100 milliseconds, unless the processor is sleeping. Generally, messages travel quickly (a few milliseconds), slowly (a few seconds), or not at all. The timeout is, in some embodiments, an attempt to remove “in-flight” messages that should be dropped to free up buffers and bandwidth. Not doing this too often may delay when new messages are sent or when the application queues new messages. c) The application may ask the PCGP if there is any pending work to do before going to sleep. Thus, in some embodiments, if there is no work for the PCGP to do, the driver activity may wake up the system, and therefore the PCGP, and thus the PCGP does not need to make a call to “packetProcessor” or “decrement timeout” until a new packet enters the system. In some embodiments, failure to do this may result in a timeout condition dropping a message that should have been successfully sent / forwarded / received. d) Applications should not hold onto received messages indefinitely. The messaging system relies on prompt replies. If an application shares a PCGP buffer, holding onto a message means holding onto the PCGP buffer. In some embodiments, the receiving node is unaware of whether the transmitting node has timeouts configured for slow or fast wireless communication. This means that a node should measure the network's fast timeout rate in response to receiving a message, and / or e) The application may frequently call "packetProcessor". In some embodiments, the call may cause the application to send new messages that have been queued, or to handle the receipt of new messages. The call may also cause buffer reallocation, and if not called too frequently, it may delay message traffic.

[0089] As shown in Figure 8I, in some embodiments, at some point the RX driver may be prompted to receive a message from the other side of the interface. In some embodiments, to ensure that the message is not dropped, the RX driver may ask the buffer manager if there is a buffer available to store the new message. The driver may then request a buffer pointer and begin filling the buffer with the received data. Once the complete message is received, the RX driver may invoke a function to route the packet. The routing function may examine the destination byte in the packet header and, in some embodiments, do one or more of the following: change the owner to another driver and / or application, and / or detect that the packet is bad and drop the packet by freeing the buffer.

[0090] The PCGP RX overhead may consist of requesting the next available buffer and calling the route function. A non-exclusive example of code performing such functions is as follows: [ka]

[0091] The driver may perform a TX by requesting a pointer to the next buffer to send from the buffer manager. The TX driver may then ask the other side of the interface whether it can receive the packet. If the other side rejects the packet, the TX driver does nothing to the buffer because its state has not changed. Otherwise, the driver may send the packet and recycle / release the buffer. A non-restrictive implementation of code that performs such a function is as follows: [ka]

[0092] To avoid forwarding packets that exceed the maximum message system timeout period, in some embodiments, the BufferManager::first(uint8 owner) function may be called, which can scan for buffers to free by looking for nextBuffer. Thus, a complete TX buffer that has no possibility of timeout may be freed on the thread that owns the buffer. In some embodiments, a bridge performing a TX (i.e., while looking for the next TX buffer) may free all TX buffers that would expire before receiving the next TX buffer for processing.

[0093] As shown in Figures 8J-8L, in some embodiments, during the buffer allocation process, buffers marked as available may be forwarded to the driver to receive new packets or to the PCGP to receive new payloads for TX. Allocation from "available" may be performed by the "packetProcessor" function. The number of send and receive operations between "packetProcessor" calls may determine how many LT_Driver_RX, GT_Driver_RX, and PCGP_Free buffers need to be allocated. LT_Driver may represent a driver handling addresses less than the node address. GT_Driver may represent a driver handling addresses more than the node address.

[0094] When the driver receives a packet, it may place the data into the RX buffer, which is then passed to the router. The router may then reallocate the buffer to PCGP_Receive or another driver's TX (not shown). If the buffer contains obviously invalid data, the buffer may transition to an available state.

[0095] After the router marks a buffer for TX, the driver may discover that the buffer is TX and send a message. After sending the message, if the driver is short on RX buffers, the buffer may immediately become an RX buffer, or the buffer may be freed for reallocation.

[0096] During the "packetProcessor" call, PCGP may process all buffers that the router has marked as PCGP_Receive. At this point, the CRC and other data items may be checked as the data may be affected. If the data is corrupted, the statistics may be incremented and the buffer may be freed. Otherwise, the buffer may be marked as owned by the application. Buffers marked as owned by the application may be recycled for use by PCGP or freed for reallocation by the buffer manager.

[0097] In some embodiments, when an application wants to send a new message, it may be done in a reentrant, understandable / mutual exclusion manner. If a buffer may be allocated, PCGP may mark the buffer as in use. Once marked as in use, it is owned by the invocation of a send or reply function call, and therefore no other thread calling this function should capture this buffer. Error checking and the rest of the process of creating the message may be done outside of the isolated race condition mutual exclusion protection code. The buffer may transition to an available state, or become a valid, filled, CRC-checked buffer and be passed to the router. In some embodiments, these buffers may not be sent immediately and may be queued so that messages can be sent later (assuming protocol rules allow it). Reply messages may be sent with higher priority than regular outgoing messages, and there may be no rules limiting how many / when reply messages can be sent, so reply messages may be marked differently from new outgoing messages.

[0098] In some embodiments, the PCGP cooperates with flow control, and the flow control may negotiate for the transfer of messages from one node to another so that the buffer is never dropped because the opposite side of the interface lacks a buffer (which may cause backpressure on the transmitting node).

[0099] The flow control may be part of the shared buffer format. In some embodiments, the first two bytes may be reserved for the driver so that the driver never has to shift packet bytes. The two bytes may be used such that one byte is the DMA length - 1 and the second byte controls the flow of the message. These same two bytes may synchronize the bytes when the PCGP message is transmitted over RS232. Various other configurations and sizes may be used in various embodiments.

[0100] In some embodiments, when a packet is "in - flight", the packet may be in the process of being transmitted by the driver, processed by the destination, or returned as a response along its path to the destination.

[0101] Typical delays are as follows.

Table 1

[0102] Thus, in some embodiments, messages tend to complete a round - trip quickly (e.g., <50 ms), complete slowly (e.g., over 1 second), or not complete at all.

[0103] In various embodiments, PCGP may use two different timeouts (set during initialization) for all timeouts, one for when the RF link is in fast heartbeat mode and the other for when the RF link is in slow mode. However, in other embodiments, PCGP may use more or less different timeouts than the two. In some embodiments, if a message is in flight and the link state changes from fast to slow, the timeout may be adjusted, and the difference between fast and slow may be added to the expiration counter for the packet. No additional forward or backward transitions should affect the expiration for the message.

[0104] In some embodiments, there is a second timeout, which may be twice as long as the slow timeout, used to monitor buffer allocation within PCGP. Therefore, if a message is “stuck” within the driver and not sent, for example due to traffic control or hardware failure, the buffer may be released by the buffer manager, causing the buffer to drop. For “new” messages, this may also mean that the packet has already timed out and the application has already received a reply indicating that the message was not delivered, causing the buffer to be released. The buffer is released so that the driver has a message to send, which is passed to the driver when the next obstacle is removed, as the driver polls the buffer manager for buffers that need to be sent. For reply messages, the reply may simply be dropped, and the sending node may time out.

[0105] In some embodiments, the PCGP messaging system may pass messages containing header information and payload. However, in various embodiments, the PCGP messaging system may pass messages containing different information. Outside of PCGP, the header may be a set of data items in the call signature. In some embodiments, however, internally within PCGP, there may be a consistent driver-friendly byte layout. In some embodiments, the driver may insert bytes into or before the PCGP packet, as follows: • DE, CA: Synchronization bytes for use with RS232, nominal values ​​0xDE, 0xCA, or 0x5A, 0xA5. • LD: Driver DMA length bytes, the total size excluding size bytes or synchronization bytes, equal to the amount the driver is pushing in this DMA transfer. • Cmd: Driver commands and control bytes used for flow control. • LP: PCGP packet length, always equal to the total header + payload size in bytes + CRC size. LD = LP + 1. Dst: Destination address. • Src: Source address. • Cmd: Command byte. • Scd: Subcommand byte. • AT: Application tags are defined by the application and are not important to PCGP. This allows applications to attach further information to messages, such as the thread from which the message originated. • SeqNum: A 32-bit sequence number is incremented by PCGP for each new message sent, ensuring that the number is not rounded up, acts as a token, and is endianness-independent. • CRC16: 16-bit CRC for PCGP header and payload.

[0106] An example of a message with no payload and with cmd=1 and subcmd=2 is as follows: [ka]

[0107] This methodology may have several advantages, including, but are not limited to, the following: In various embodiments, the majority of the hardware DMA engine may use a first byte to define how many additional bytes to move, and therefore, in this methodology, the driver and PCGP may share a buffer. A byte may be provided immediately after the DMA length to pass flow control information between drivers. Because the driver length and the "Cmd" byte may be outside the CRC area, they may be modified by the driver, or owned by the driver transport mechanism, and the driver may be vigilant about invalid lengths. There may be a separate PGCP packet length byte protected by CRC. Therefore, the application may trust that its payload length is correct. The endianness of a sequence number may not be relevant, as it is merely a matching byte pattern that happens to be a 32-bit integer. The sequence number may be 4 bytes, aligned to the edge of the shared buffer pool length. There may be an optional RS232 synchronization byte to allow the user to move the cable around while debugging the message stream, and for both sides of the interface to resynchronize. Applications, drivers, and PCGP may share buffers and free them by pointers.

[0108] In some embodiments, PCGP may not be an event-driven type software design, but may be used in an event-driven type architecture depending on how the subclasses are written. Data may be exchanged conceptually between classes (as shown in Figures 8M-8N).

[0109] In some embodiments, some event models in the driver may wake the driver, receive messages, and pass messages through a bridge to a buffer manager that sends messages to the new owner of new messages (through the driver or a bridge to PCGP).

[0110] The following summarizes some illustrative events. [Table 2]

[0111] The following exemplary implementation demonstrates how a PCGP event model can work with Nucleus to wake up the PCGP task after a Dec timeout has occurred that has generated all sent messages, replies, or NACKs. [ka]

[0112] The following is an event-based pseudocode driver illustrating how driver events work. The driver subdivides the Bridge and disables hasMessagesToSend and flowControlTumedOff, planning to activate the TX and RX functions if they are not already operational. [ka] [ka]

[0113] While not limited to these, the following statistics may be supported by PCGP: • Number of packets sent · Number of packets received ·CRC error ·timeout • Unavailable buffer (buffer is gone)

[0114] In various embodiments, PCGP may be designed to operate in multiple processing environments. Most parameters may be runtime configured to facilitate testing and runtime fine-tuning of performance. Other parameters may be compile-time parameters, such as anything that modifies memory allocations that must be performed statically at compile time, but other parameters may still be used in various embodiments.

[0115] The following may be definitions of the number of compile-time configurations that can vary where PCGP is implemented. • Driver byte count: Reserved for a common buffer scheme for the driver, which may be 2 bytes, but in some embodiments, this may be a compilation time option adapted to other drivers such as RF protocols. • Number of RX driver buffers: May be synchronized with the number of buffers required by the processor / traffic flow, etc. • PCGPRX buffer count: May be synchronized with the number of buffers required by the processor / traffic flow, etc. • Total number of buffers: May be adjusted to match the number of buffers required for that processor.

[0116] In some embodiments, the CRC may be used to ensure data integrity. In some embodiments, if the CRC is invalid, it may not be delivered to the application, and the CRC error may be tracked. The message may eventually time out and may be retried by the sender.

[0117] Similarly, if the messaging system informs an application that a message has been delivered when it has not been delivered, this is undesirable for the system. A bolus stop command is an example of such a command. This can be mitigated by a message request / action sequence that may be required by the application to change the treatment method. In some embodiments, a remote interface 802 may receive a matching command from the device 800 application and consider the delivered message.

[0118] In some embodiments, a reference method may be used to interface the PCGP to a Nucleus OS system on ARM9 (as shown in Figure 8O).

[0119] As shown in Figure 8P, the pcgpOS.cpp file may create instances of PCGP node instances (Pcgp, Bridge, etc.) and may provide a set of C-linkable function calls through pcgpOS.h that provide a C language interface to C++ code. This simplifies the implicit nature of the C code as the object being acted upon.

[0120] In some embodiments, the following general rules may apply. PCGP may operate on all nodes. Any driver may support a general driver interface. • Race conditions do not need to be allowed. Half-duplex support may be provided on the SPI port between the slave processor and the master processor. Data transfer may not be attempted, as it will either succeed or fail / false. • Low overhead (wasted time, processing, bandwidth) may be required. • Support for the CC2510 operating at a DMA (high-speed) SPI clock ratio may be provided.

[0121] In some embodiments, if the receiving end does not currently have an empty buffer to place the packet, SPI traffic control may prevent the data from being transmitted. In some embodiments, this may be achieved by requesting permission to transmit and waiting for a response indicating that permission has been granted. In some embodiments, another method may be used to indicate to the other party that there is no empty buffer at the moment and that the transmission should be attempted at a later date.

[0122] In some embodiments, all transmissions may begin with a length byte indicating the number of bytes to be transmitted, which does not include the length byte itself. The length may be followed by a single byte indicating the command being transmitted.

[0123] In some embodiments, the actual transmission of the packet may consist of the command byte being the packet length plus one, followed by the command byte for the attached message, and finally the packet itself. However, in other embodiments, the transmission of the packet may differ.

[0124] In addition to the command bytes to be transmitted, an additional hardware line called a flow control line may be added to the four conventional SPI signals. This line may be used to allow the protocol to operate as quickly as possible without a pre-configured delay. It also allows the slave processor to inform the master processor that there are packets waiting to be transmitted, thus eliminating the need for the master processor to poll the slave processor for status.

[0125] The following exemplary command values ​​may be used in some embodiments. Commands sent by the master processor: [Table 3] Commands sent by the slave processor [Table 4-1] [Table 4-2]

[0126] As illustrated in Figure 8Q, when a slave processor has packets to send to the master processor, the slave processor may notify the master processor (for example, by asserting a flow control line) that there are pending packets waiting to be sent. Doing so may result in an IRQ on the master processor, at which point the master processor may decide when to retrieve the message from the slave processor. Packet retrieval may be delayed at the discretion of the master processor, and the master processor may decide to attempt to send the packets to the slave processor before retrieving them from the slave processor.

[0127] In some embodiments, the master processor may initiate retrieval by sending the slave processor an M_CTS command. This is repeated in some embodiments until the slave processor responds by sending an S_MSG_APPENDED command along with the packet itself. The flow control line may be released after the packet has been sent. If the M_CTS command is received by the slave processor unexpectedly, the M_CTS command may be ignored.

[0128] As illustrated in Figure 8R, in some embodiments, when a master processor has a packet to send to a slave processor, the master processor may initiate the transfer by sending an M_RTS command. Upon receiving the M_RTS command, in some embodiments, if the slave processor has any currently pending transmit packets, the slave processor lowers the flow control line so that it may be reused as a transmit enable signal. The slave processor may then inform the master processor that it is in the process of preparing SPIDMA to receive the packet, while the master processor may stop measuring byte time on the bus, allowing the slave processor to finish preparing to receive.

[0129] In some embodiments, the slave processor may then indicate that it is ready to receive the entire packet by raising the flow control line (used as the CTS signal). Upon receiving the CTS signal, the master processor may then send the M_MSG_APPENDED command along with the packet itself.

[0130] After the transfer is complete, the slave processor may lower the flow control line. If the packet was pending at the start of the transfer, or if transmission occurred on the slave processor while the packet was being received, the slave processor may reassert the flow control line indicating that there is a pending packet.

[0131] Referring again to Figure 8, the device 800 may include a switch assembly 810 connected to an electrical control assembly 510 (Figure 5D), which may allow a user (not shown) to perform at least one task, and in some embodiments, multiple tasks. One illustrative embodiment of such a task is the administration of a bolus dose of an injectable fluid (e.g., insulin), in an embodiment where device 800 is an infusion pump or other drug delivery device, without using a display assembly. A remote interface 802 may allow a user to enable / disable / configure device 800 to administer a bolus dose of insulin.

[0132] The display assembly 804 may be configured, at least in part, to allow the user to interact with menu-based information rendered on the display assembly 804. In some embodiments, the display assembly 804 may be a touchscreen. In some embodiments, the touchscreen / display assembly 804 may be configured such that, for example, the ratio at which a highlighted portion of a menu scrolls "upward" or "downward" varies depending on the displacement of the user's finger relative to the starting point. Thus, in some embodiments, for example, if the user desires to scroll quickly "upward," the user may position their finger near the top of the display assembly 804. Similarly, if the user desires to scroll quickly "downward," the user may position their finger near the bottom of the display assembly 804. In addition, if the user desires to scroll slowly "upward," the user may position their finger slightly "upward" relative to the starting point. Furthermore, if the user desires to scroll slowly "downward," the user may position their finger slightly "downward" relative to the starting point. When an appropriate menu item is highlighted, the user may select the highlighted menu item, for example, by touching the screen a predefined number of times in any of the vicinity of the highlighted menu item, and / or, in some embodiments, by using one or more switch assemblies 806, which may be included on the remote interface 802.

[0133] As discussed above, in one embodiment of the injection pump device described above, device 800 may be used to communicate with a remote interface 802. When such a remote interface 802 is used, device 800 and the remote interface 802 may periodically contact each other to ensure that the two devices are still communicating with each other. For example, device 800 may "ping" the remote interface 802 to ensure that the remote interface 802 is present and active. Furthermore, the remote interface 802 may "ping" device 800 to ensure that device 800 is still present and active. If one of device 800 and the remote interface 802 is unable to establish communication with the other, the one that is unable to establish communication (i.e., either device 800 or the remote interface 802) may trigger an "isolation" alarm. For example, suppose the remote interface 802 is left in the user's vehicle, while device 800 is in the user's pocket. Therefore, after a defined period, device 800 may begin emitting a “separation” alarm, indicating that it cannot establish communication with interface 802. In some embodiments, the user may use switch assembly 810 to acknowledge and / or silence the “separation” alarm.

[0134] In various embodiments, the user may use the switch assembly 810 of device 800 to define and administer fluid delivery while the remote interface 802 is not communicating with device 800, and device 800 may store information about administered bolus insulin doses in a log file (not shown) stored within device 800. This log file (not shown) may be stored in non-volatile memory (not shown) contained within device 800. Depending on the communication established between device 800 and the remote interface 802, device 800 may provide the remote interface 802 with information about administered bolus insulin doses stored in the log file (not shown) of device 800.

[0135] Furthermore, in some embodiments, if the user anticipates that the remote interface 802 will be isolated from device 800, the user may configure device 800 and the remote interface 802 in "isolated" mode, thereby eliminating the occurrence of the aforementioned "isolated" alarm. However, in some embodiments, the remote interface 802 and device 800 may continue to "ping" each other so that when they return to communicating with each other, device 800 and the remote interface 802 can be automatically released from "isolated" mode.

[0136] Furthermore, in some embodiments, if the user anticipates traveling by aircraft, the user may use the remote interface 802 to configure device 800 and remote interface 802 into “aircraft” mode, causing device 800 and remote interface 802 to suspend all data transmission, respectively. While in “aircraft” mode, device 800 and remote interface 802 may or may not continue to receive data.

[0137] In some embodiments, the switch assembly 810 may be used to perform additional functions, which may include, but are not limited to, checking the battery life of the reusable portion 502, pairing the reusable portion 502 with the remote interface 802, and / or interrupting the administration of a bolus dose of the injectable fluid.

[0138] Referring to Figure 9A, as discussed above, in some embodiments, for example, to improve the safety of device 800, the electrical control assembly 516 may include two separate and individual microprocessors, namely a supervisor processor 900 and a command processor 902. Specifically, the command processor 902 may perform functions such as generating pump drive signals, or control relay / switch assemblies that control the functionality of shape memory actuators, for example. In some embodiments, the command processor 902 may receive feedback from the signal regulator 908 regarding the state (e.g., voltage level) of the voltage signals applied to pump actuators 922, 924, which may be shape memory actuators. The command processor 900 may control relay / switch assembly 910 independently of relay / switch assemblies 904, 906. Therefore, for example, when an injection event is desired, both the supervisor processor 900 and the command processor 902 must agree that the injection event is appropriate (which may include whether the injection event dose does not exceed any configurable limits of the system, when it is unique or user-selected / pre-programmed and / or planned), and both must activate their respective relays / switches. If either the supervisor processor 900 or the command processor 902 fails to activate its respective relay / switch, the injection event will not occur. Thus, the safety of device 800 is improved through the use of the supervisor processor 900 and the command processor 902 and the cooperation and simultaneous occurrence that must occur.

[0139] In some embodiments, the supervisor processor 900 may prevent the command processor 902 from making deliveries when inappropriate, and / or may alarm if the command processor 902 fails to make deliveries when it should. The supervisor processor 900 may deactivate a relay / switch assembly, for example, if the command processor 902 activates the wrong switch or if the command processor attempts to apply power for an excessively long time.

[0140] The supervisor processor 900 may redundantly calculate the amount of fluid to be delivered (i.e., double-check the calculations of the command processor 902). In some embodiments, the command processor 902 may determine the delivery schedule, and the supervisor processor 900 may redundantly check / verify those calculations.

[0141] The supervisor processor 900 may redundantly maintain profiles (e.g., pre-programmed / pre-entered delivery profiles and / or user preferences) in RAM so that the command processor 902 can perform the correct calculations, but if it has bad RAM, it will produce incorrect results for the commands. Therefore, the supervisor processor 900 double-checks / verifies the profiles / user preferences using local copies, such as the base profile.

[0142] The supervisor processor 900 may double-check one or more calculations performed by the device, such as AVS measurement, by reviewing the AVS calculation and the safety checks applied. In some embodiments of the device, for example, the supervisor processor 900 performs a double-check each time an AVS measurement is performed.

[0143] See also Figure 9B, one or more of the supervisor processor 900 and command processor 902 may perform diagnostics on various parts of the injection pump / device 800. For example, voltage dividers 912, 914 may be configured to monitor voltages (V1 and V2, respectively) sensed, for example, at the distal end of the shape memory actuator 922. Knowing the signals applied to the relay / switch assemblies 904, 910, the values ​​of voltages V1 and V2 allow diagnostics to be performed on various components of the circuit shown in Figure 9B (in a similar manner to that shown in illustrative diagnostic table 916).

[0144] As discussed above and illustrated in Figures 9A-9B, in order to improve the safety of device 800, the electrical control assembly 910 may include multiple microprocessors (e.g., supervisor processor 900 and command processor 902), each of which may be required to interact and operate simultaneously to produce an action (e.g., if device 800 produces drug delivery, the action may be, for example, delivery of a certain dose of injectable fluid). If the microprocessors 900, 902 fail to interact / operate simultaneously, the delivery / action of the dose of injectable fluid may fail, and one or more alarms may be triggered, thus improving the safety and reliability of device 800.

[0145] A master alarm may be used to track errors, such as volume errors, where the volume of fluid delivered over time is less than or equal to the required volume. Therefore, if the sum of the errors becomes too large, a master alarm may be triggered, indicating that there may be a problem with the system. Thus, the master alarm may indicate the total volume comparison being performed and the discovered discrepancies. A typical value of the discrepancy required to trigger a master alarm may be 1.00 milliliter in embodiments including the aforementioned injection pump. The master alarm may monitor the total in a leak-like manner (i.e., the inaccuracy has a temporal horizontal).

[0146] See also Figures 10A-10B, which illustrate one such exemplary embodiment of such interaction between multiple microprocessors during the delivery of a dose of injectable fluid. In this embodiment, the interaction occurs during the delivery of a certain dose of injectable fluid by an injection pump. Specifically, the command processor 902 may first determine the initial volume of the injectable fluid in the volume sensor chamber 900. The command processor 902 may then provide the supervisor processor 900 with a "pump power request" message 1002. Upon receiving the "pump power request" message 1004, the supervisor processor 900 may, for example, excite a relay / switch 910 1006 (thus exciting the shape memory actuator 922) and send a "pump power on" message to the command processor 902 1008. Upon receiving the "pump power on" message 1010, the command processor 902 may, for example, actuate the pump assembly 1012 (by exciting a relay / switch 904, thereby exciting the valve assembly 514), while the supervisor processor 900 may, for example, monitor the operation of the pump assembly 1014.

[0147] Once the pump assembly has finished operating, the command processor 902 may provide the supervisor processor 900 with a “pump power off” message 1014. In response to receiving the “pump power off” message 1016, the supervisor processor 900 may de-excite the relay / switch 910 1018 and provide the command processor 902 with a “pump power off” message 1020. In response to receiving the “pump power off” message 1022, the command processor 902 may measure the volume of injectable fluid pumped by the pump assembly (which in some embodiments may include a valve assembly 514) 1024. This may be achieved by measuring the current volume in the volume sensor chamber and comparing it to the volume determined above (in step 1000). Once determined 1024, the command processor 902 may provide the supervisor processor 900 with a “valve open power request” message 1026. In response to receiving the “Valve Open Power Request” message 1028, the supervisor processor 900 may excite the relay / switch 910 1030 (and thus the shape memory actuator 924) and send the “Valve Open Power On” message to the command processor 902 1032. In response to receiving the “Valve Open Power On” message 1034, the command processor 902 may actuate the measuring valve assembly, for example (by exciting the relay / switch 906) 1036, while the supervisor processor 900 may monitor the actuatement of the measuring valve assembly, for example 1038.

[0148] Once the operation of the measuring valve assembly is complete, the command processor 902 may provide the supervisor processor 900 with a “valve power off” message 1040. Upon receiving the “valve power off” message 1042, the supervisor processor 900 may de-excite the relay / switch 910 1044 and provide the command processor 902 with a “valve power off” message 1046.

[0149] Upon receiving the “Valve Power Off” message 1048, the command processor 902 may provide the supervisor processor 900 with a “Valve Closed Power Request” message 1050. Upon receiving the “Valve Closed Power Request” message 1052, the supervisor processor 900 may excite a relay / switch 910 1054 (and thus excite a shape memory actuator) and send a “Power On” message to the command processor 902 1056. Upon receiving the “Power On” message 1058, the command processor 902 may activate an excitation relay / switch (not shown) configured to excite a shape memory actuator 1060, during which time the supervisor processor 900 may monitor the operation of the shape memory actuator, for example 1062.

[0150] In various embodiments, the shape memory actuator may be fixed to the first end using electrical contacts. The other end of the shape memory actuator may be connected to a bracket assembly. When the shape memory actuator is activated, it may pull the bracket assembly forward and release the valve assembly. As such, the measuring valve assembly may be activated via the shape memory actuator. When the measuring valve assembly is activated, the bracket assembly may automatically latch onto the measuring valve assembly in the activated position. By acting the shape memory actuator, the bracket assembly may be pulled forward and the valve assembly may be released. Assuming the shape memory actuator is no longer activated, the measuring valve assembly may become deactivated when the bracket assembly releases it. Therefore, the measuring valve assembly may become deactivated by activating the shape memory actuator.

[0151] Once the operation of the shape memory actuator is complete, the command processor 902 may provide a “power off” message to the supervisor processor 900 1064. Upon receiving the “power off” message 1066, the supervisor processor 900 may de-excite the relay / switch 910 1068 and provide a “power off” message to the command processor 902 1070. Upon receiving the “power off” message 1072, the command processor 902 may determine the amount of injectable fluid in the volume sensor chamber, so that the command processor 902 can determine the amount of injectable fluid delivered to the user by comparing this measured amount with the amount determined above (in step 1024) 1074.

[0152] If the amount of injectable fluid 1074 delivered to the user is less than the amount of injectable fluid specified for the base / bolus injection event, the above procedure may be repeated (via loop 1076).

[0153] Referring to Figure 11, another illustrative embodiment of the interaction between processors 900 and 902 during scheduling of the injection fluid dose is shown. Command processor 902 may monitor for the reception of a basic scheduling message or a bolus request message (each, 1100, 1102). Upon receiving either of these messages 1100, 1102, command processor 902 may set a desired delivery volume 1104, or provide a “delivery request” message to supervisor processor 900 1106. Upon receiving the “delivery request” message 1108, supervisor processor 900 may verify the volume 1104 defined by command processor 902 1110. Once verified 1110, supervisor processor 900 may provide a “delivery acceptance” message to command processor 902 1112. Upon receiving the “Delivery Accepted” message 1114, the command processor 902 may update the remote interface (e.g., the remote interface discussed above and illustrated in Figure 6-8) 1116 and perform the delivery of the base / bolus dose of the injectable fluid 1118. The command processor 902 may monitor and update the total amount of injectable fluid delivered to the user (as discussed above and illustrated in Figures 10A-10B) 1122. When an appropriate amount of injectable fluid has been delivered to the user, the command processor 902 may provide the supervisor processor 900 with a “delivery complete” message 1124. Upon receiving the “delivery complete” message 1126, the supervisor processor 900 may update the total amount of injectable fluid delivered to the user 1128. If the total amount of injectable fluid delivered to the user 1118 is less than the amount defined above (in step 1104), the injection process discussed above may be repeated (via loop 1130).

[0154] Referring also to Figure 12, an embodiment is shown in which the supervisor processor 900 and the command processor 902 can interact while achieving volume measurement via a volume sensor assembly (as described above).

[0155] Specifically, the command processor 902 may initialize the volume sensor assembly 1250 and begin collecting data from the volume sensor assembly 1252, and this process may be repeated for each frequency used in the sinusoidal sweep described above, for example, in U.S. Patent Publication No. US-2009-0299277-A1 (Patent Attorney Reference No. G75), published on December 3, 2009. Whenever data has been collected for a particular sweep frequency, a data point message may be provided from the command processor 902 1254, which may be received by the supervisor processor 900 1256.

[0156] Once data acquisition 1252 is complete for the entire sinusoidal sweep, the command processor 902 may estimate the volume of injectable fluid delivered by the injection of device 800 1258. The command processor 902 may provide a volume estimation message to the supervisor processor 900 1260. Upon receiving this volume estimation message 1262, the supervisor processor 900 may check (i.e., confirm) the volume estimation message 1264. Once checked (i.e., confirmed), the supervisor processor 900 may provide a verification message to the command processor 902 1266. Upon receiving from the supervisor processor 900 1268, the command processor 902 may set a measurement state for the amount of injectable fluid delivered by the volume sensor assembly.

[0157] As discussed above (and temporarily referring to Figure 1A-5I), various embodiments and components of the injection pump system may be configured using a remote interface 802 (see Figure 6-8). When configurable via the remote interface 802, the injection pump 800 may include telemetry circuitry (not shown) that enables communication (e.g., wired or wireless) between the injection pump and, for example, the remote interface 802, and thus enables the remote interface 802 to communicate remotely with the injection pump 800. Various embodiments of the remote interface 802 (which may also include telemetry circuitry (not shown) and be able to communicate with the injection pump 800) may include display assemblies (602, 702, 804) and at least one input assembly (608, 604, 610, 606, 704, 702, 804, 806), however, in various embodiments, the display assemblies may also serve as input assemblies.

[0158] As used herein, the term “remote interface” refers to any embodiment of a remote interface. However, the embodiment shown in Figure 8 is used below for illustrative purposes only, and the description is not limited to that embodiment of the remote interface shown in Figure 8.

[0159] In some embodiments, the remote interface 802 may include two processors, one of which may be dedicated to wireless communication, for example, wireless communication for communicating with device 800, including, but not limited to, the CC2510 microcontroller interface / RF transceiver available from Chipcon AS (Oslo, Norway). The second processor included in the remote interface 802, which may be the ARM920T and ARM922T manufactured by ARM Holdings PLC (United Kingdom), may be a command processor and may perform, for example, data processing tasks associated with configuring device 800. However, in various other embodiments, as described below, the remote interface 802 may include various processors and / or communication protocols and / or various antennas for communication.

[0160] Furthermore, as discussed above, one embodiment of the electrical control assembly 516 may include three microprocessors. One processor (which may include, but is not limited to, the CC2510 micro remote interface / RF transceiver available from Chipcon AS (Oslo, Norway)) may be dedicated to wireless communication, for example, to communicate with the remote interface 802. Two additional microprocessors (which may include, but is not limited to, the supervisor processor 1800 and the command processor 1802) may achieve the delivery of injectable fluid (as discussed above). An example of the supervisor processor 1800 and the command processor 1802 may include, but is not limited to, the MSP430 micro remote interface available from Texas Instruments Inc. (Dallas, Texas).

[0161] The OS may be a non-interrupt scheduling system in that it executes all tasks until they are completed, regardless of priority, before the next task can be executed. In addition, context switching may not occur. When a task completes execution, the highest-priority task currently scheduled to be executed may be executed. If no tasks are scheduled to be executed, the OS may put the processor (e.g., supervisor processor 900 and / or command processor 902) into a low-power hibernation mode and wake it up when the next task is scheduled. The OS may be used only to manage the main loop code and may leave interrupt-based functionality unaffected.

[0162] In some embodiments, the OS may be written to utilize the C++ language. Inheritance and virtual functions may be important design elements that enable the easy creation, scheduling, and management of tasks.

[0163] The OS infrastructure may include the ability to track system time and control the ability to put the processor into a low-power mode (LPM, also known as hibernation mode). This functionality, along with the control and configuration of all system clocks, may be encapsulated by the SysClocks class.

[0164] The SysClocks class may include functionality to reduce energy consumption by putting a processor (e.g., supervisor processor 900 and / or command processor 902) into LPM mode. While in LPM mode, the slow real-time clock may continue to run, while the fast system clock that runs the CPU core and most peripherals may be disabled.

[0165] In some embodiments, the processor may always be made to LPM by provided SysClocks. This function may include all necessary power-down and power-up sequences that provide consistency whenever the processor becomes LPM or ceases to be LPM. The wake from LPM may be initiated by an arbitrary interrupt based on a slow clock.

[0166] The OS may track three time phases: seconds, milliseconds, and time. Regarding seconds, SysClocks may begin counting seconds when the processor emerges from reset. The seconds counter may be based on the slow system clock and therefore may increment regardless of whether the processor is in LPM or full power. This, in turn, is the boundary at which the processor wakes from hibernation to perform a previously scheduled task. If a task is scheduled to run immediately after an interrupt handling routine (ISR), the ISR may wake the processor from LPM upon completion, allowing the task to run immediately. Regarding milliseconds, in addition to counting seconds since power-on, SysClocks may also count milliseconds while the processor is in full power mode. Since the fast clock is paused during LPM, the millisecond counter does not need to increment. Therefore, the processor does not need to be in LPM whenever a task is scheduled to run based on milliseconds. With respect to time, the time may be expressed in SysClocks as the number of seconds since a specific point in time (for example, January 1, 2008, and / or in some embodiments, the number of seconds since January 1, 1971, POSIX standard time).

[0167] The SysClocks class may provide useful functionality used throughout the command and supervisor project codebase. Code delays may be necessary to allow hardware to stabilize or for an action to complete. SysClocks may provide two forms of delay: delays based on seconds or delays based on milliseconds. When a delay is used, the processor may simply wait until a desired amount of time has elapsed before continuing the current code path. During this time, only the ISR may be executed. SysClocks may set or retrieve the current time, providing all the necessary functionality.

[0168] The term "task" may be associated with more complex scheduling systems, and therefore, within an OS, a task may be represented by and referred to as a managed function. The ManagedFunc class may be an abstract type-based class that provides all the control elements and functionality necessary to manage and schedule a desired functionality.

[0169] The ManagedFunc base class may have five control elements, two of which are scheduling operation element functions, and one which may contain managed functionality and is a pure virtual execution function. All ManagedFunc control elements may be hidden from the derived class, or they may only be set directly by the derived class during creation, thus simplifying use and improving the safety of the injection pump 800.

[0170] In some embodiments, the function ID may be set at creation time and may never be changed. All function IDs may be defined within a single .h file, and the base ManagedFunc constructor may enforce that the same ID cannot be used for more than one managed function. The ID may also define the priority of a function (relative to other functions) based on the assigned function ID, with higher-priority functions having lower assigned function IDs. The highest-priority task, which is currently scheduled to run, may run before lower-priority tasks.

[0171] All other control elements may be used to represent the current scheduled state of the function when it should be executed and when the function should be scheduled again for a previously set amount of time (at runtime). Manipulation of these controls and states may be possible, but only through well-known member functions (thus ensuring safety controls in all settings).

[0172] To control the scheduling of managed functions, start and iterate configuration functions may be used. Each of these member functions may be a simple interface that allows for the ability to configure or disable iterate configurations, as well as control whether a managed function is in an inactive state, scheduled by seconds, milliseconds, or time.

[0173] Managed functions may be created through inheritance by creating a derived class and defining a pure virtual "executable" function containing code that needs to be subject to scheduling control. The ManagedFunc base class constructor may be based on the function's unique ID, but may also be used to set default control values ​​at startup.

[0174] For example, to create a function that runs 30 seconds after startup and then every 15 seconds thereafter, the desired code is placed in a virtual execution function, and the constructor is provided with a function ID scheduled by a seconds state, which is the start time of 30 seconds, and an iteration setting of 15 seconds.

[0175] The following is an illustrative code example of creating a managed function. In this particular example, a "heartbeat" function is created that is scheduled to run for the first time 1 second after device 800 starts up, and then every 10 seconds thereafter. [ka]

[0176] The actual execution of managed functions may be controlled and performed by the SleepManager class. The SleepManager may contain an actual priority list of managed functions. This priority list of functions may be automatically populated by the managed function creation process to ensure that each function is properly created and has a unique ID.

[0177] The primary role of the SleepManager class may be to have its "management" function repeatedly called from the processor's main loop and / or an infinite while loop. With each call to management, SleepManager executes all functions that are scheduled to run until SleepManager has used up all scheduled functions, at which point SleepManager may put the processor into LPM. When the processor wakes from LPM, the management function may be re-entered until the processor is ready to become LPM again (this process may be repeated, for example, until stopped by the user or the system).

[0178] If the processor must remain in full power mode for an extended period (for example, while analog / digital conversion is being sampled), SleepManager may provide functionality to disable LPM. While LPM is disabled, management functions may continue to search for scheduled tasks.

[0179] SleepManager may also provide an interface for manipulating scheduling and iterating over the configuration of arbitrary managed functions through the use of a unique ID for the function, which may allow any section of code to perform any necessary scheduling without direct access to or unnecessary knowledge of the desired ManagedFunc object.

[0180] The wireless circuitry contained within device 800 and remote interface 802 may provide wireless communication between the remote interface 802 and device 800. In some embodiments, a 2.4 GHz wireless communication chip (e.g., Texas Instruments CC2510 wireless transceiver) with an internal 8051 microremote interface may be used for wireless communication.

[0181] A wireless link may strike a balance between three factors: link availability, latency, and energy consumption.

[0182] Regarding link availability, the remote interface 802 may provide a primary means for issuing commands to device 800 and may provide detailed feedback to the user via the graphical user interface (GUI) (display assembly 804) of the remote interface 802. Regarding latency, the communication system may be designed to provide low latency for delivering data from the remote interface 802 to device 800 (and vice versa). Regarding energy, both the remote interface 802 and device 800 may have maximum energy consumption for wireless communication.

[0183] The radio link may support half-duplex communication. In some embodiments, the remote interface 802 may be the master of the radio link, initiating all communications. In these embodiments, device 800 may only respond to communications and may never initiate any communications. The use of such a radio communication system may offer various advantages, including improved security, simplified design (e.g., for aircraft use), and coordinated control of the radio link. In other embodiments, device 800 may initiate certain actions, but communications may be initiated by the remote interface 802.

[0184] See also Figure 12, which shows an illustrative example of one of the various software layers of the wireless communication system discussed above.

[0185] In some embodiments, the remote interface 802 and the radio processor included in device 800 may forward messaging packets between the SPI port and the 2.4GHz radio link (and vice versa). In some embodiments, the radio may always be an SPI slave. On device 800, the radio processor (PRP) 918 (see Figures 9A-9B) may, in some embodiments, service two additional nodes (the number of additional nodes may vary in various embodiments) located upstream (i.e., the command processor 900 and the supervisor processor 902) via the SPI port. In some embodiments, on the remote interface 802, the radio processor 918 (CRP) may enable two additional nodes on the SPI port, which may be either upstream or downstream, for example, in some embodiments, the remote control processor (UI) and the continuous glucose monitor (CGM) and / or blood glucose monitor (BGM).

[0186] The messaging system may enable the communication of messages between various nodes in the network. The UI processor of the remote interface 802, and, for example, the supervisor processor 900, may use the messaging system to constitute and initiate part of mode switching on two system radios. It may also be used by radio to transmit radio and link status information to other nodes in the network.

[0187] In some embodiments, if the radio of the remote interface 802 wishes to collect channel statistics from device 800 or update the master channel list of the radio of device 800, the radio of the remote interface 802 may use a system message. Synchronization to make the new updated list effective may use a flag in the heartbeat message to eliminate timing uncertainty.

[0188] The wireless communication system may be written in C++ to be compatible with messaging software. In some embodiments, a 4-byte wireless serial number may be used to address each wireless node. A hash table may be used to provide a one-to-one translation between a device-readable serial number sequence and the wireless serial number. The hash table may provide more randomized, e.g., 8-bit logical addresses, so that devices or remote interfaces with similar-readable serial numbers are more likely to have unique logical addresses. In some embodiments, the wireless serial numbers between device 800 and remote interface 802 do not need to be unique due to the unique role each has in the wireless protocol.

[0189] The radio serial numbers of the remote interface 802 and the device 800 may be included in all radio packets, except for the RF pairing request message, which in some embodiments may only include the radio serial number of the remote interface 802, thus ensuring that it only occurs with the remote control assembly / injection pump assembly being paired. The CC2510 may support a one-byte logical node address, and it may be advantageous to use one byte of the radio serial number as the logical node address to provide a level of filtering for incoming packets.

[0190] To prevent noise interference on the remote interface 802 board by other systems on the board, the Quiet_Radio signal may be used by the UI processor of the remote interface 802. When Quiet_Radio is asserted, the radio application of the remote interface 802 may send a message to the radio of device 800 to assert Radio Quiet mode for a predefined period. In some embodiments, the Quiet_Radio feature may not be required, based on the noise interference level measured on the PC board of the remote interface 802. During this period, the radio of the remote interface 802 may remain in hibernation mode 2 for up to 100 ms. The radio of the remote interface 802 may exit hibernation mode 2 when the Quiet_Radio signal is stopped being asserted or when the maximum period has expired. The UI processor of the remote interface 802 may assert Quiet_Radio at intervals of at least one radio communication before it is necessary to assert the event. The radio of remote interface 802 may notify the radio of device 800 that communication will be shut down during this sleep period. The periodic radio link protocol may have state bits / bytes that accommodate the Quiet_Radio feature unless Quiet_Radio is required.

[0191] The wireless software may be integrated with the messaging system and wireless bootloader on the same processor and may be validated using throughput testing. The wireless software may be integrated with the messaging system, SPI driver using DMA, and wireless bootloader, all on the same processor (e.g., TI CC2510).

[0192] In some embodiments, the radio of the remote interface 802 may be configured to consume only 32 mAh over three days (assuming 100 minutes of fast heartbeat mode communication per day). In some embodiments, the radio of device 800 may be configured to consume only 25 mAh over three days (assuming 100 minutes of fast heartbeat mode communication per day). However, these configurations may vary throughout embodiments, and in some embodiments they may exceed or fall below the embodiments described.

[0193] The maximum time to reacquire communication includes connection request mode and acquisition mode. < 6.1 seconds is possible, however, in various other embodiments, the maximum time may be shorter or longer. In some embodiments, the radio of the remote interface 802 may favorably use a fast heartbeat mode or a slow heartbeat mode setting to conserve power and minimize latency for the user. The difference between device 800 and the remote interface 802 in entering acquisition mode may be that device 800 needs to enter acquisition mode frequently enough to ensure that communication can be restored within the maximum latency. However, the remote interface 802 may be in slow heartbeat mode and vary the frequency with device 800 entering acquisition mode when a heartbeat is lost. In some embodiments, the radio of the remote interface 802 may have knowledge of user GUI interaction, but device 800 may not.

[0194] The radio of remote interface 802 may set a heartbeat period for both radios. In some embodiments, the period may be selectable to optimize power and link latency depending on activity. The desired heartbeat period may be communicated from the radio of remote interface 802 to the radio of device 800 with each heartbeat. This may not exclusively establish the heartbeat ratio of device 800, depending on other conditions that determine which mode is being used. When in fast heartbeat mode, the radio of remote interface 802 may set the heartbeat period to 20ms, provided it is capable of transmitting or receiving data packets, thus providing low-latency communication when data is being actively exchanged.

[0195] In high-speed heartbeat mode, the radio of the remote interface 802 may set the heartbeat period to 60 ms after four heartbeats have passed since the last bidirectional exchange of data packets over the radio. Keeping the radio heartbeat period short after data packets are transmitted or received ensures that any data response packets can also be delivered with less link latency. In low-speed heartbeat mode, the heartbeat ratio may be 2.00 seconds or 6.00 seconds, depending on whether the device is online or offline, respectively. However, in various embodiments, these values ​​may differ.

[0196] Device 800 may use a heartbeat ratio set by the radio of the remote interface 802. In some embodiments, the radio of the remote interface 802 may support the following mode requests via one or more messaging systems, though not limited to: Pairing mode • Connection mode • Acquisition mode (including the wireless serial number of the desired paired injection pump assembly 100, 100', 400, 500) • Synchronization Mode - High-Speed ​​Heartbeat • Synchronization mode - slow heartbeat • RF off mode The radios of injection pump assemblies 100, 100', 400, and 500 may support the following mode requests via a messaging system: Pairing mode Acquisition mode • RF off mode

[0197] In some embodiments, the radio may use system messages to obtain the local radio serial number. On the remote interface 802, the radio may obtain the serial number from the UI processor of the remote interface 802. The radio may use system messages to store the paired radio serial number.

[0198] In some embodiments, the radio of the remote interface 802 and device 800 may, at any time, use a messaging system to issue status messages to the UI processor of the remote interface 802 and command processor 902 when one or more of the following states change: • High-speed online: Connection successful • High-speed online: Change from acquisition mode to high-speed heartbeat mode • Slow Online: Successful request to change from fast heartbeat to slow heartbeat • Offline: Automatic switch to search sync mode due to insufficient heartbeat exchange. • High-speed online: Successful request to change from slow heartbeat to fast heartbeat. • Offline: Bandwidth falls below 10% in sync mode • Online: Bandwidth exceeds 10% in search sync mode • Offline: Successful request to change to RF off mode

[0199] In some embodiments, a wireless configuration message may be used to configure the number of wireless retries. This message may be sent over a messaging system. In some embodiments, the UI processor of the remote control assembly 802 configures these wireless settings by sending this command to both the wireless of the remote interface 802 and the wireless of device 800.

[0200] In some embodiments, the radio configuration message may include two parameters: the number of RF retries (for example, the value may be between 0 and 10) and a radio offline parameter (for example, the value may be between 1 and 100 as a percentage of the bandwidth). However, in various other embodiments, there may be more or fewer than two parameters.

[0201] The wireless applications of both the remote interface 802 and the device 800 may have an API that allows the messaging system to configure the number of RF retries and wireless offline parameters.

[0202] In some embodiments, but not limited to, one or more of the following parameters may be recommended for the wireless hardware configuration. Basic wireless specifications ·MSK • Wireless communication rate of 250kbps or higher • Up to 84 channels • 1000kHz channel spacing • 812kHz filter bandwidth • Manchester coding scheme is not available. • Data erasure • 4-byte preamble • 4-byte synchronous (word) • CRC attached to the packet • LQI (Link Quality Indicator) attached to the packet • Activated automatic CRC filtering

[0203] In some embodiments, forward error correction (FEC) may or may not be used. Forward error correction (FEC) is used to increase the effective signal dynamic range by about 3 dB, but FEC requires a fixed packet size and doubles the number of wireless bits for the same fixed-size message, which may be undesirable in some embodiments.

[0204] In some embodiments, the radio may operate within a distance of 1.83 meters under nominal operating conditions (except in pairing mode). In some embodiments, the radio may operate within a distance of 7.32 meters under nominal operating conditions. In some embodiments, the transmission power level may be 0 dBm (except in pairing mode), and the transmission power level in pairing mode may be -22 dBm. Since the desired radio node address of device 800 may not be known by the remote interface 802 in pairing mode, both device 800 and the remote interface 802 may, in some embodiments, use lower transmission power to reduce the possibility of accidental pairing with another injection pump assembly. However, in various other embodiments, either device 800 or the remote interface 802 may use lower transmission power.

[0205] In some embodiments, AES encryption may be used for all packets, but in embodiments using, for example, a Texas Instruments CC2510 wireless transceiver, this transceiver may not be necessary as it includes this functionality. In embodiments where AES encryption is used, a fixed key may be utilized, as a fixed key may be desirable for several reasons, including providing a quick way to enable encryption without passing the key. However, in some embodiments, key exchange may be provided within device 800. In some embodiments, the fixed key may be contained in a separate header source file without any other variables besides the fixed key data, thus allowing for easier management of read access to the file.

[0206] In some embodiments, the wireless software may support one or more of the following eight modes, but is not limited to: Pairing mode • RF off mode • Connection mode Acquisition mode • High-speed heartbeat mode • Slow heartbeat mode • Search and sync mode • Synchronization mode All of these are schematically depicted in Figures 12B-12C.

[0207] Pairing may be a process of exchanging wireless serial numbers between the remote interface 802 and the device 800. The remote interface 802 may "pair" with the device 800 when the device 800 knows its serial number.

[0208] In some embodiments, the pairing mode (one embodiment of which is schematically depicted in Figure 12D) may require that the following four messages be exchanged over the RF link (however, various embodiments may require that more, fewer, or no messages be exchanged over the RF link than those specified). • RF pairing request (broadcast from remote interface 802 to any device 800) • RF pairing acknowledgment (remote interface 802 from the device) • RF pairing confirmation request (from remote interface 802 to device 800) • RF pairing confirmation acknowledgment (from device 800 to remote interface 802)

[0209] In addition, the remote interface 802 may interrupt the pairing process at any time using an RF pairing interruption message (from the remote interface 802 to device 800). In some embodiments, the pairing mode does not need to support messaging system data transfer.

[0210] In some embodiments, the radio of device 800 may enter pairing mode in response to the reception of a pairing mode request message. In some embodiments, there are no disposable parts attached to device 800, and it may be the responsibility of the supervisor processor 900 on device 800 to request the radio to enter pairing mode when the user presses the switch assembly 810 of device 800 for a predefined amount of time, e.g., 6 seconds (which may vary throughout the embodiments), indicating to the system that pairing mode has been requested. The radio of device 800 may set an appropriate transmission power level for pairing mode. In some embodiments, device 800 may be paired with only one remote interface 802 at a time.

[0211] In some embodiments, a Near Field Communication ("NFC") protocol may be used to identify that device 800 and remote interface 802 are paired. For example, using NFC, a user may touch a disposable portion of the remote interface 802 while the device is in pairing mode, which may trigger the pairing protocol, i.e., it is identified that device 800 and remote interface 802 are paired. In some embodiments, a camera located on the remote interface 802 may be used to capture an image of a 2D barcode on device 800, and this image and / or image recognition may be used to identify device 800. In some embodiments, device 800 may include an RFID transmitter, which may be used in the NPC protocol for recognition.

[0212] In some embodiments, while in pairing mode, in response to the reception of a first valid RF pairing request message, the radio of device 800 may respond for the duration of pairing mode with an RF pairing acknowledgment message that uses the serial number of the remote interface 802 and includes the radio serial number of device 800.

[0213] In some embodiments, the radio of device 800 may automatically time out of pairing mode after a predefined time period, for example, 2.0 ± 0.2 seconds, if no RF pairing request is received. The radio of device 800 may automatically time out of pairing mode after, for example, 2.0 ± 0.2 seconds, if no RF pairing request is received. In some embodiments, this time may be less than or greater than 2.0 ± 0.2 seconds. In some embodiments, the radio of device 800 may issue a pairing request received message after transmitting an RF pairing acknowledgment. This message to the supervisor processor 900 will allow feedback to the user during the pairing acknowledgment process. The radio of device 800 may automatically time out of pairing mode after, for example, 1.0 ± 0.1 seconds, after transmitting an RF pairing acknowledgment, unless an RF pairing acknowledgment request is received. In some embodiments, this time may be less than or greater than 1.0 ± 0.1 seconds. In some embodiments, the radio of device 800 may issue a message to store the pairing radio serial number if an RF pairing confirmation request message is received after an RF pairing request message has been received. This action may involve storing the radio serial number of the remote interface 802 in the non-volatile memory of device 800, which may overwrite existing pairing data of device 800.

[0214] The radio of device 800 may transmit an RF pairing acknowledgment acknowledgment after receiving an acknowledgment from a stored message of the pairing radio serial number, and exit pairing mode. In some embodiments, this may be a default exit from pairing mode on device 800, and the power of device 800 may be reduced until the user enters connected mode or pairing mode.

[0215] In some embodiments, when the radio of device 800 terminates pairing mode in response to successful reception of a pairing confirmation request message, the radio of device 800 may return to the newly paired remote interface 802 and send a pairing completion success message to the command processor 902. In some embodiments, the radio of device 800 may terminate pairing mode in response to reception of an RF pairing interruption message. The radio of device 800 may terminate pairing mode in response to reception of a pairing interruption request message addressed to it. In some embodiments, this may allow the command processor 902 or supervisor processor 900 to locally interrupt the pairing process on device 800.

[0216] In some embodiments, the radio of the remote interface 802 may enter pairing mode in response to the receipt of a pairing mode request message. In some embodiments, it may be the responsibility of the UI processor of the remote interface 802 to request that the radio enter pairing mode under appropriate conditions. The radio of the remote interface 802 may set an appropriate transmission power level for pairing mode. In some embodiments, the radio of the remote interface 802 may transmit an RF pairing request until an RF pairing acknowledgment is received or pairing is interrupted.

[0217] In some embodiments, the radio of the remote interface 802 may automatically interrupt the pairing mode if an RF pairing acknowledgment message is not received within a predefined time, for example, 30.0 ± 1.0 seconds, after entering pairing mode. However, in various embodiments, the predefined time may be greater than or less than 30.0 ± 1.0. In some embodiments, while in pairing mode, upon receiving the first valid RF pairing acknowledgment message, the radio of the remote interface 802 may send a pairing success message to the UI processor of the remote interface 802, including the serial number of device 800, and may use that serial number for the duration of pairing mode. This message may provide the UI processor of the remote interface 802 with a means for the user to confirm the serial number of the desired device 800. In some embodiments, if the radio of the remote interface 802 receives multiple responses from device 800 (with respect to a single pairing request), the first valid one may be used.

[0218] In some embodiments, the radio of the remote interface 802 may only accept an RF pairing acknowledgment acknowledgment message after an RF pairing acknowledgment has been received while in pairing mode. The radio of the remote interface 802 may transmit an RF pairing acknowledgment message in response to receiving a pairing acknowledgment request message from the UI processor of the remote interface 802.

[0219] In some embodiments, the radio of the remote interface 802 may check that device 800 confirms pairing before adding device 800 to the pairing list. In some embodiments, the radio of the remote interface 802 may issue a message to store the paired radio serial number when an RF pairing complete message is received. This action may allow the UI processor of the remote interface 802 to store the new serial number of device 800 and provide user feedback of successful pairing. Managing the list of paired injection pump assemblies may be the responsibility of the UI processor of the remote interface 802. Thus, in some embodiments of the system, the system may include two or more devices, each of which may be paired with the remote interface 802. However, in some embodiments, it may be desirable that one of the paired devices be used in conjunction with the remote interface 802 at any given time. Therefore, in these embodiments, once the initial pairing process is complete and the remote interface 802 includes the devices on its list of paired devices, the user indicates to the remote interface 802 the device with which communication is desired for a duration of use (a predefined time amount).

[0220] In some embodiments, the radio of the remote interface 802 may send an RF pairing interruption request message and terminate the pairing mode upon receipt of the pairing interruption request message. This may allow the UI processor of the remote interface 802 to interrupt the pairing process on both the remote interface 802 and the acknowledged device 800.

[0221] In connection request mode, the radio of the remote interface 802 may attempt to retrieve each device 800 in its paired device list and restore its “ready to connect” state. One embodiment of this “connection” process, schematically depicted in Figure 12E, may, in some embodiments, allow the remote interface 802 to quickly identify one of its paired devices that is ready for use. The radio of the remote interface 802 may be able to perform connection request mode with multiple devices, for example, in some embodiments, up to six paired reusable parts of an injection pump. The connection request mode may be supported only on the remote interface 802, or it may be a special form of retrieval mode. In connection request mode, the remote interface 802 may connect with and respond to a first device. However, each message may be directed to a specific device serial number.

[0222] In some embodiments, the radio of the remote interface 802 may, upon entering connection mode, obtain a list of the serial numbers of the most recently paired device. The radio of the remote interface 802 may enter connection mode in response to the receipt of a connection mode request message. It may be the responsibility of the UI processor of the remote interface 802 to request that the radio enter connection mode when communication with a paired device is desired. The radio of the remote interface 802 may, where applicable, issue a connection evaluation message to the UI processor of the remote interface 802 containing the radio serial number of the first device, indicating "Ready to connect". The radio of the remote interface 802 may generate the connection evaluation message within a predefined time period, for example, 30 seconds, after entering connection request mode. However, the predefined time period may be less than or greater than 30 seconds in various embodiments. In some embodiments, the radio of the remote interface 802 may terminate connection request mode upon receiving a connection evaluation acknowledgment and transition to fast heartbeat mode. The radio of the remote interface 802 may terminate connection request mode in response to the receipt of a connection request interruption message from the UI processor of the remote interface 802.

[0223] On the remote interface 802, acquisition mode may be used to find a specific paired device. In some embodiments, the radio of the remote interface 802 may send an RF RUT (aRe yoU There) packet to the desired paired device. If the device receives the RF RUT message, it may respond to the radio of the remote interface 802. In some embodiments, multiple channels may be used in the acquisition mode algorithm to improve the chances of the radio of the remote interface 802 finding a paired device.

[0224] The radio of the remote interface 802 may enter acquisition mode while in RF off mode in response to the reception of an acquisition mode request or a fast heartbeat mode request message. The radio of the remote interface 802 may enter synchronized acquisition mode while in search synchronization mode in response to the reception of an acquisition mode request or a fast heartbeat mode request message. It may be the responsibility of the UI processor of the remote interface 802 to request that the radio enter acquisition mode when the RF link is offline and the remote interface 802 desires to communicate with a device.

[0225] In some embodiments, particularly in those embodiments where the device is an injection pump, the radio of the remote interface 802 may communicate with only one paired injection pump 800 (except in pairing and connection modes). In some embodiments, if communication is lost, the UI processor of the remote interface 802 may use an acquisition mode (at some periodicity rate limited by the power budget) to attempt to restore communication.

[0226] In some embodiments, device 800 may enter acquisition mode under one or more of the following conditions, but in various other embodiments, additional conditions may trigger acquisition mode. • When wireless is off mode and acquisition mode may be requested. • When the search sync mode times out due to insufficient heartbeats.

[0227] When in acquisition mode, the radio of device 800 may obtain the serial number of the last stored paired remote interface 802. The radio of device 800 may only communicate with the remote interface 802 to which it is "paired" (except while in "pairing request" mode). Once the acquisition of synchronization with the remote interface 802 is successful, the radio of device 800 may transition from acquisition mode to fast heartbeat mode. In some embodiments, the acquisition mode of device 800 may be capable of acquiring synchronization within 6.1 seconds, which may indicate that when in acquisition mode, device 800 may always be listening at least every approximately 6 seconds. However, in various embodiments, listening may be for shorter or longer durations.

[0228] In some embodiments, data packets may be transmitted, for example, between the pairing device 800 and the remote interface 802, when the device 800 and the remote interface 802 are in synchronous mode and online. The two devices may synchronize via heartbeat packets before data packets are exchanged. Each radio may transmit data packets at known time intervals after the heartbeat exchange. Device 800 may adjust the timing to anticipate receiving packets. In some embodiments, the radio may support one data packet in each direction on each heartbeat. The radio may provide a negative response to a fast heartbeat mode request if the radio is offline. The radio on the remote interface 802 is in slow heartbeat mode and may switch to fast heartbeat mode if a system request for fast heartbeat mode is received while the radio is online.

[0229] When transitioning from acquisition mode to fast heartbeat mode, the radio of remote interface 802 may transmit a master channel list message. The master channel list may be constructed by the radio of remote interface 802 and transmitted to the radio of device 800 to enable the selection of frequency-hopping channels based on past performance. When in high-speed or low-speed heartbeat mode, periodic heartbeat messages may be exchanged between the radio of remote interface 802 and the radio of device 800. The periodicity of these messages may be in terms of the heartbeat ratio. Heartbeat messages may enable data packet transfer and may also exchange state information. In some embodiments, the two radios may exchange state information such as sleep mode, data availability, buffer availability, heartbeat ratio, and previous channel performance; however, in other embodiments, additional or less information may be exchanged. In some embodiments, the goal may be to keep the packet size of heartbeat messages small in order to conserve power. In these embodiments, the radios may provide a maximum data packet size of 82 bytes when in synchronous mode. The messaging system may be designed to support a packet payload size of, for example, up to 64 bytes. This maximum size may be chosen as the optimal trade-off between the smallest message type and unfragmented messages. In some embodiments, 82 bytes may be the maximum packet size of the messaging system, including packet overhead; however, in various embodiments, this maximum packet size may be larger or smaller.

[0230] In some embodiments, the messaging system has an API that enables a radio protocol to send received radio packets to it. The messaging system may also have an API that enables the radio protocol to obtain packets for transmission over the radio network. The messaging system may be involved in packet routing between the radio protocol and the SPI port. Data packets may be given to the messaging system for processing. The messaging system may have an API that enables the radio protocol to obtain a count of the number of data packets waiting to be transmitted over the radio network. The radio protocol may query the messaging system with each heartbeat to determine whether a data packet is available to be transmitted over the radio network. To minimize round-trip message latency, it may be desirable for the software to check message availability immediately before the heartbeat is sent.

[0231] The wireless protocol may be capable of buffering a single received wireless data packet and passing the packet to a messaging system. In some embodiments, the wireless protocol may transmit the data packet to the messaging system upon receiving it. The messaging system may be involved in sending the wireless data packet to the appropriate destination node. The wireless protocol may be capable of buffering a single packet from the messaging system.

[0232] The radio protocol may be involved in acknowledging the receipt of a valid data packet on the RF link via an RFACK reply packet to the transmitting radio. The RF ACK packet may contain the source and destination radio serial numbers, the RF ACK command identifier, and the sequence number of the data packet being acknowledged.

[0233] In some embodiments, a radio transmitting a wireless data packet may retransmit the wireless data packet on the next heartbeat with the same sequence number, provided that an RF ACK is not received and the retry count is within the maximum allowed RF retries. If interference disrupts transmission on a particular frequency, in some embodiments, RF retries allow the same packet to be retransmitted on a different frequency on a subsequent occasion. The sequence number provides a means of uniquely identifying the packet within a short time frame. The number of wireless packet retries may be configurable using a wireless configuration command. Allowing more retries may increase the probability of packets being exchanged, but introduces further latency for round-trip messages. The default number of wireless retries during power increases may be 10 (i.e., the maximum transmission attempt before dropping a message). However, this maximum number may vary in various embodiments.

[0234] In some embodiments, a one-byte (modulo 256) radio sequence number may be included in every radio data packet on the RF link. Since radios may be involved in retrying data packet transmission if not acknowledged, the sequence number may provide a way for two radios to determine if data packets are duplicates. The transmitted sequence number may be incremented for each new radio data packet and may be rollover-enabled. If a data packet is successfully received with the same sequence number (and in the same direction) as a previously received data packet, the data packet may be acknowledged, or the received data packet may be discarded. This may remove duplicate packets generated by the RF protocol before they are introduced into the network. It should be noted that under extreme circumstances, conditions may arise where multiple consecutive data packets with the same sequence number may need to be dropped.

[0235] In some embodiments, if a heartbeat is missed, the radio of the remote interface 802 and the radio of device 800 may attempt to transmit and listen for a subsequent heartbeat, respectively. If a heartbeat is missed for two seconds, the radio of the remote interface 802 and the radio of device 800 may automatically switch from fast heartbeat mode or slow heartbeat mode to search synchronization mode. Since two seconds allows enough time to switch all channels sequentially, this may minimize power consumption when the link is lost by allowing the radio to continue using synchronization information.

[0236] In some embodiments, the wireless may be considered online when it is in the following modes: • High-speed heartbeat mode • Slow heartbeat mode

[0237] In some embodiments, these may be the only states in which messaging system traffic may be exchanged. All other states may be considered offline.

[0238] The wireless function may be initialized to wireless-off mode when code execution begins after a reset. When the code is first executed on the radio processor, the initial state may be radio-off mode, allowing other processors to perform self-tests before requesting the radio to be operational. This requirement is not intended to define a mode when waking from hibernation mode. When the radio is set to radio-off mode, it may cease RF communication. On remote interface 802, this mode may be intended for use on an aircraft, i.e., in aircraft mode, to suppress RF emissions. Since device 800 only responds to transmissions from remote interface 802 (which ceases transmission in aircraft mode), radio-off mode may only be used on device 800 when charging.

[0239] In some embodiments, the command processor 902 may be notified that the RF has been intentionally turned off on the remote interface 802 so as not to generate an aircraft mode, and therefore a walkaway warning. However, this may be completely hidden from the radio of device 800.

[0240] In some embodiments, the radio of the remote interface 802 and the radio of device 800 may periodically attempt to exchange heartbeats to re-establish data bandwidth while in search synchronization mode. If the exchange of heartbeats is unsuccessful, the radio of the remote interface 802 may transition to radio off mode after a predefined time period, for example, 20 minutes in search synchronization mode.

[0241] In some embodiments, the device's radio may transition to acquisition mode after a predefined time period, e.g., 20 minutes in search-synchronization mode, if heartbeat exchange is unsuccessful. In some embodiments, listening during a pre-agreed time slot is the most efficient use of power of device 800 for re-establishing the RF link. After loss of communication, crystal resistance and temperature drift may require device 800 to extend its listening time frame over time. Remaining in search-synchronization mode after loss of communication for an extended period (e.g., 5-20 minutes) may cause the instantaneous power consumed to exceed the average power allocated to device 800's radio. Remaining in search-synchronization mode can be very power-efficient for the remote interface 802's radio, as it may not be compelled to extend its time frame. Acquisition mode may consume more power for the remote interface 802. In some embodiments, 20 minutes may be used as a compromise to balance power consumption in both the remote interface 802's radio and device 800's radio; however, this time may vary depending on the embodiment.

[0242] The radio of the remote interface 802 and the radio of device 800 may transition to a slow heartbeat mode if a predefined percentage of a certain group of heartbeats, for example, if three of the last five heartbeats are successfully exchanged. Then, at predefined intervals, for example, about every six seconds, a burst of five heartbeats (or, depending on the embodiment, more or less) may be attempted. If these predefined percentages, for example, three of them are successful, it may be assumed that the bandwidth is sufficient to transition to a slow heartbeat mode. The radio of device 800 may be available while in search-synchronous mode with a latency of, for example, 6.1 seconds, however, this latency may vary depending on the embodiment. In this embodiment, this may indicate that device 800 may always be listening at least every about six seconds when in search-synchronous mode.

[0243] Wireless protocol performance statistics may be desired to facilitate wireless troubleshooting and to evaluate wireless performance. In some embodiments, the following wireless performance statistics may be maintained within a data structure by the wireless protocol. However, these are merely examples of one embodiment, and they may differ from embodiment to embodiment. Some embodiments may not use statistics, or may use more, fewer, or different statistics. [Table 5-1] [Table 5-2]

[0244] In some embodiments, the #define DEBUG option (compiler option) may be used to collect one or more of the following additional radio performance statistics per channel (16-bit number), however, in various other embodiments, additional information may also be collected. • Number of missing hops • Good CCA count • Defective CCA count • Average RSSI (accumulated only for good RX packets) • Drop from frequency hop list count • Acquisition mode count (the pair found on this channel)

[0245] In some embodiments, debugging options may be used to collect engineering-specific statistics. It may be desirable to retain this information at runtime, where processor performance, power, and memory allow. Wireless statistics may be made available to the messaging system.

[0246] In some embodiments, the link quality may be available / viewable on the remote interface 802 and may be intended to provide a bar indicator of wireless link quality, similar to a mobile phone. The link quality may be available to both the remote interface 802 and device 800. In some embodiments, the link quality status may consist of a one-byte indicator of the quality of the wireless link.

[0247] In some embodiments, the radio may change its frequency with each heartbeat. An adaptive pseudo-random frequency hopping algorithm may be used for the synchronization mode, and the heartbeats may be tried in the search synchronization mode. In some embodiments, the goal may be to use, for example, 64 channels for frequency hopping. However, in other embodiments using frequency hopping, more than 64 channels may be used. In some embodiments, the algorithm may be developed to adaptively generate a channel list on the remote interface 802 with respect to frequency hopping. The radio of the remote interface 802 may build, maintain, and distribute a master channel list. In some embodiments, previous channel statistics and historical performance information may be obtained from the radio of device 800 by the radio of the remote interface 802, using a messaging system as needed, to meet performance requirements. The radio interference environment of both units may be taken into consideration by creating channel lists from the perspective of both device 800 and the remote interface 802. The radio may adaptively select hopping channels and meet round-trip message latency while operating in a desired RF environment.

[0248] Next, also referring to Figure 13, in some embodiments the system may include at least two reusable parts 1300, 1308 of the injection pump and at least one disposable part 1310 of the injection pump. In some embodiments the reusable parts 1300, 1308 include a rechargeable battery 532. In some embodiments the two disposable parts may be paired to the same remote interface, which may include the embodiment shown as 1302 in Figure 13 and / or any one or more shown as 600, 700, 802 in Figures 6-8. In some embodiments the user may connect the reusable part 1308 to the disposable part 1310 by rotating the reusable part 1308 in the direction of arrow 1316 while aligning it with the disposable part 1310 to connect the reusable part 1308 and the disposable part 1310, as described above. The second reusable portion 1300 may be docked on the recharging station 1304 by connecting to the recharging station 1304 through electrical contacts (not shown) in the recharging area 1306. While the user is sleeping or otherwise remaining in a single area for an extended period, for example, 3 hours, the remote interface 1302 may be recharged by docking the remote interface 1302 on the recharging station 1304 by connecting to the recharging station 1304 through electrical contacts (not shown) in the slot 1318. In some embodiments, the electrical contacts may be a USB plug, which may be configured to connect to the remote interface 1302 when the remote interface 1302 is placed in the slot 1318. The USB plug may enable data transfer to and from the remote interface 1302 as well as charging the remote interface 1302. In some embodiments, the user may use one of the reusable portions 1308 while the second reusable portion 1300 is being recharged.

[0249] Next, referring to Figures 14A-14E, another embodiment of the injection pump system is shown. The system may include a remote interface 1402, one reusable portion 1400, a second reusable portion 1406, at least one disposable portion 1408, and a charging station 1404 for charging the remote interface 1402 and / or filling one or two disposable portions 1400, 1406. In some embodiments, the charging station may be any charging station, or similar to any charging station, as illustrated and / or described in one or more of the following: U.S. Patent Publication No. US-2007-0228071 (Patent Attorney No. E70), published on 4 October 2007; U.S. Patent Publication No. US-2009-0299277 (Patent Attorney No. G75), published on 3 December 2009; and U.S. Patent Application No. 12 / 981,283, “Infusion Pump Assembly” (Patent Attorney No. I41), filed on 29 December 2010 (which is incorporated herein by reference as a whole). As discussed above with respect to Figure 13, the charging station may include a USB plug that can be configured to connect to the remote interface 1402 when the remote interface 1402 is placed in slot 1414. The USB plug may enable data transfer to and from the remote interface 1402 as well as charging of the remote interface 1402.

[0250] Next, referring to Figures 15A-15B, another embodiment of the charging station 1500 is shown. As shown, in some embodiments, the charging station 1500 may include a charging area 1504 for the reusable part and a charging area 1502 for the remote interface, which may include a USB plug. In some embodiments, the charging station 1500 may include a USB port 1508, in some embodiments a mini USB port, and in some embodiments a USB 1506, which may allow the charging station 1500 to receive power to charge the reusable part and / or the remote interface. In addition and / or alternatively, the USB port 1508 may be configured for data transfer to and from the remote interface and / or the reusable part, and / or connection to a computer or other device and / or other computer-type equipment. In embodiments including a USB port, while the remote interface is charging, the system may call a personal computer and / or a web portal to check for updated software and download software updates if available. These updates may then be transferred to the reusable part, depending on the pairing.

[0251] Next, referring again to Figures 16A-16F, as discussed above, the reusable portion 1602 may include a battery 1632, which may include, for example, a rechargeable battery. The battery charger 1600 may be configured to recharge the battery 1632. The battery charger 1600 may include a housing 1602 having a top plate 1604. The top plate 1604 may include one or more electrical contacts 1606, generally configured to be electrically connected to the electrical contacts 1634 of the reusable housing assembly 1602. The electrical contacts 1606 may include, but are not limited to, electrical contact pads, spring-deflected electrical contact members, or equivalents. In addition, the top plate 1604 may include matching tabs 1608, 1610, which may be configured to mesh with openings 1636, 1638 in the base plate 1618 of the reusable housing assembly 1602 (for example, as shown in Figure 5C). The cooperation of the alignment tabs 1608, 1610 and the openings 1636, 1638 ensures that the reusable housing assembly 1602 is aligned with the battery charger 1600 so that the electrical contact 1606 of the battery charger 1600 can be electrically connected to the electrical contact 1634 of the reusable housing assembly 1602.

[0252] The battery charger 1600 may be configured to removably engage with the reusable portion 1602. For example, in a manner similar to that of the disposable portion, the battery charger 1600 may include one or more locking tabs (e.g., locking tabs 1612, 1614). The locking tabs (e.g., locking tabs 1612, 1614) may be engaged by tabs 1642, 1644, 1646, 1648 of the locking ring assembly 1606. Thus, the reusable portion 1602 may be aligned with the battery charger 1600 with the locking ring 1606 in a first unlocked position (via alignment tabs 1608, 1610), as shown in Figure 16C. The locking ring 1606 may be rotated relative to the battery charger 1600 in the direction of arrow 1616, and the tabs 1642, 1644, 1646, and 1648 of the locking ring 1606 may be removably engaged with the locking tabs of the battery charger 1600 (e.g., locking tabs 1612, 1614), as shown in Figure 16D.

[0253] In some embodiments, the battery charger 1600 may include a recessed area 1618 that can provide space for accommodating the pressurizing and valve-operating components of the reusable portion 1602, for example, in some embodiments. Also, referring to Figures 16E-16F, the battery charger 1600 may supply current to the electrical contact 1606 (and thereby to the reusable portion 1602 via the electrical contact 1634) for recharging the battery 1632 of the reusable portion 1602. In some embodiments, current may not be supplied to the electrical contact 1606 unless a signal indicating a fully engaged reusable portion is provided. According to such embodiments, risks associated with short circuits (e.g., caused by foreign matter coming into contact with the electrical contact 1606) and damage to the reusable portion 1602 (e.g., caused by improper initial alignment between the electrical contact 1606 and the electrical contact 1634) can be reduced. In addition, in some embodiments, the battery charger 1600 does not need to unnecessarily draw current when the battery charger is not charging the reusable portion 1602.

[0254] Referring still to Figures 16E-16F, the battery charger 1600 may include a lower housing portion 1624 and an upper plate 1604. The printed circuit board 1622 (which may include, for example, electrical contacts 1606) may be located in a cavity between the upper plate 1604 and the lower housing portion 1624.

[0255] Still referring to Figures 16A-16F, in some embodiments, the battery charger 1600 may include a USB plug 1650, which may be configured to connect to a wall charger and / or a computer and / or a personal computer and / or a remote interface. The USB plug 1650 may enable the battery charger 1600 to provide power for data transfer to and from the computer / remote interface 1402 and for charging the reusable portion 1602.

[0256] Referring to Figure 17, an exemplary embodiment of how various components of the injection pump system are connected / communicate with each other is shown. For example, the battery charger 1704 may be connected to a computing device 1700 (in some embodiments, a personal computer, or any device that can be used in a manner similar to a personal computer, such as a tablet, for example) via a bus converter 1702 that converts RS232 format data to, for example, I2C format data. The bus converter 1702 may run a pass-through program to achieve the above conversion. The battery charger 1704 may be connected to a wireless processor 1718 via an electrical contact 1606 (described above). The wireless processor 1718 may then be connected to a supervisor processor 900 and a command processor 902 via, for example, an RS232 bus. In some embodiments, the wireless processor 1718 may run an update program that allows the wireless processor 1718 to control / organize updates to flash memory accessible by the supervisor processor 900 and the command processor 902. Therefore, through the use of the above linkage, software updates obtained by the computing device 1700 may be uploaded to flash memory (not shown) accessible by the supervisor processor 900 and the command processor 902. In some embodiments, the above software updates may be command-line programs that are automatically invoked by a script process.

[0257] Next, referring to Figures 18 and 19, two embodiments of communication between the device, the remote interface, and the personal computer (which, in some embodiments, has access to one or more web portals and / or one or more secure web portals) are shown. In Figure 18, the remote interface 1800 communicates with the infusion pump 1802 and two other devices, which, in some embodiments, may include a blood glucose meter 1806 and a sustained glucose monitoring sensor / transmitter 1804. In some embodiments, the communication is wireless and may use RF communication, e.g., RF communication protocols as described above, and / or BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols. In some embodiments, the remote interface 1800 communicates wirelessly with the personal computer 1808; however, in some embodiments, the remote interface 1800 may be connected to the personal computer 1808 via a USB connection and / or other wired connection. In some embodiments, the remote interface 1800 and the personal computer 1808 may communicate via a web / internet connection 1810, with the remote interface 1800 uploading information to the internet and the personal computer 1808 downloading information from the internet. In some embodiments, the remote interface 1800 and the personal computer 1808 may communicate via a wired and / or infrared ("IR") connection 1810, i.e., with the remote interface 1800 uploading information to the personal computer 1808.

[0258] In Figure 19, the remote interface 1900 communicates with the infusion pump 1902. The infusion pump 1902 may, in some embodiments, include a blood glucose meter 1906 and / or a sustained glucose monitoring sensor / transmitter 1904, and in some embodiments, communicates with two other devices, which may be two sustained glucose monitoring sensors. In some embodiments, the communication is wireless communication and may use RF communication, for example, the RF communication protocols described above, and / or other non-proprietary protocols, including but not limited to BLUETOOTH® or Low Energy BLUETOOTH® / BLUETOOTH® Low Energy. In some embodiments, the infusion pump 1902, which wirelessly communicates with the remote interface 1900, may communicate information received from the two devices 1904, 1906 to the remote interface 1900. The remote interface 1900 therefore serves as a visual UI, as the remote interface 1900 includes a display in some embodiments. In some embodiments, the remote interface 1900 communicates wirelessly with the personal computer 1908 (which, in some embodiments, has access to at least one web portal and / or a secure web portal); however, in some embodiments, the remote interface 1900 may be connected to the personal computer 1908 via a USB connection and / or other wired connection. In some embodiments, the remote interface 1900 and the personal computer 1908 may communicate via a web / internet connection 1910 and / or via the remote interface 1900 uploading information to the internet and the personal computer 1908 downloading information from the internet.

[0259] In both Figures 18 and 19, three devices are shown communicating with the remote interface, either directly or indirectly; however, the system is not limited to three devices and may include four or more devices in some embodiments. In addition, in some embodiments, the system may include one device that communicates with the remote interface 1900. Also, one personal computer is illustrated in Figures 18 and 19; however, in other embodiments, one or more personal computers may be used to receive information from the remote interface. Furthermore, as discussed above with respect to the battery charger and charging station, in some embodiments, the injection pump and / or remote interface may be connected to the charging station and may upload and / or download and / or communicate with a personal computer via a USB connection.

[0260] Referring again to Figure 35A, in some embodiments, the remote interface 3500 communicates with the injection pump 3502. In some embodiments, the remote interface 3500 may be any device, including, but not limited to, a SMARTWATCH manufactured by SONY Corporation (Tokyo, Japan), or other similar type devices which may be referred to as "miniature remote interfaces." In some embodiments, the miniature remote interface may include one or more user inputs, including any mechanism which allows a user of the device and / or remote interface and / or other operator / caregiver to control the functions of the device and / or remote interface. User input may include one or more mechanical arrays (e.g., switches, push buttons, jog wheels), electrical arrays (e.g., sliders, touchscreens), wireless interfaces for communicating with remote interfaces (e.g., radio frequency ("RF"), infrared ("IR"), Bluetooth®, Bluetooth® Low Energy, WiFi, ZIGBEE®, XB, WiFi Ad Hoc, White Space, Ultra Wideband, Ant, and / or wireless USB), acoustic interfaces (e.g., with voice recognition), computer network interfaces (e.g., USB ports), optical / optical imaging (including, but not limited to, camera input and / or image acquisition using a camera), sound waves, and / or other types of interfaces.

[0261] In some embodiments, the miniature remote interface may include all or some of the aforementioned functionalities with respect to the remote interface. In some embodiments, the miniature remote interface may therefore provide all of the same functionalities as those described above with respect to the remote interface (and, in some embodiments, additional functionalities), and, as described above, in some embodiments, it may be paired with an injection pump, etc.

[0262] Referring again to Figure 35B, in some embodiments, the miniature remote interface 3500 communicates with the infusion pump 3502, and in some embodiments, it may also communicate with additional devices, including medical devices, which may include at least one blood glucose meter 3506 and / or at least one continuous glucose monitor sensor / transmitter 3504, and in some embodiments, one or more devices. In various other embodiments, other devices may also communicate with the miniature remote interface 3500. In some embodiments, the communication is wireless communication and may use an RF communication protocol, e.g., an RF communication protocol, and / or a BLUETOOTH® / BLUETOOTH® low energy or other non-proprietary protocol, as described above. In some embodiments, the communication may be the same between each device, and in some embodiments, the communication may be different between each device. In some embodiments, in addition to the communication protocols described above, one or more of the following communication protocols may be used, but are not limited to: WiFi, ZIGBEE®, XB, WiFi Ad Hoc, White Space, Ultra Wideband, Ant, and / or Wireless USB. In some embodiments, the communication may be identical between each device, and in some embodiments, the communication may be different between each device. In some embodiments, the miniature remote interface 3500 communicates wirelessly with the personal computer 3508; however, in some embodiments, the remote interface 3500 may be connected to the personal computer 3508 via a USB connection and / or other wired connection. In some embodiments, the miniature remote interface 3500 and the personal computer 3508 may communicate via a web / internet connection 3510 and / or via the miniature remote interface 3500 uploading information to the internet and the personal computer 3508 downloading information from the internet.In some embodiments, the remote interface 3500 and the personal computer 3508 may communicate via a wired and / or infrared ("IR") connection 3510, i.e., via the uploading of information from the miniature remote interface 3500 to the personal computer 3508. In some embodiments, communication between the miniature remote interface 3500 and the injection pump 3502 is bidirectional. In some embodiments, communication between the miniature remote interface 3500 and the personal computer 3508 is unidirectional, i.e., the miniature remote interface 3500 may communicate with the personal computer 3508 (and / or the Internet), but the personal computer 3508 (and / or the Internet) may not communicate with the miniature remote interface. This can be beneficial for many reasons, including, but is not limited to, controlling the information uploaded to the miniature remote interface 3500, which can protect the miniature remote interface 3500 from viruses and / or prevent unwanted and / or incorrect information from being uploaded onto the miniature remote interface 3500. However, in various embodiments, communication between one or more of the various devices 3500, 3504, 3506, 3602, 3510, and 3508 may be either unidirectional or bidirectional, and in some embodiments, communication may be unidirectional for information of a predefined type or category, and bidirectional for information of other types or categories. This may be desirable for many reasons, but is not limited to, limiting the communication of therapeutically important information to unidirectional communication between a dedicated and / or secure device and another device, for example.

[0263] Referring again to Figure 35C, in some embodiments, the miniature remote interface 3500 communicates with the infusion pump 3502, and in some embodiments, it may also communicate with additional devices, including medical devices, which may include at least one blood glucose meter 3506 and / or at least one continuous glucose monitor sensor / transmitter 3504, and in some embodiments, one or more devices. In some embodiments, the miniature remote interface 3500 may also communicate with a remote interface 3512, which may be any remote interface, including a smartphone, e.g., an ADROID® smartphone. In some embodiments of this embodiment, the remote interface 3512 may include one-way communication between the miniature remote interface 3500 and the remote interface 3512. Therefore, in these embodiments, the remote interface 3512 may receive and display information relating to one or more devices / medical devices 3502, 3504, 3506 that communicate with the miniature remote interface 3500, however, the remote interface 3512 does not have to control one or more devices 3502, 3504, 3506, nor does it have to control the miniature remote interface 3500, nor does it have to transmit information to the miniature remote interface 3500. In some embodiments, therefore, the remote interface 3512 may be used as an auxiliary user interface, including the ability to display information, such as graphs and logbook information, in a larger format for easier viewing by the user. In some embodiments, the remote interface 3512 may be a smartphone, which can be used as a telephone, however, it may also include an application that enables the miniature remote interface 3500 to transmit information to the remote interface 3512 and present the information to the user in a graphic-rich format.Accordingly, in this embodiment, the miniature remote interface 3500 is the only device in the system capable of controlling the infusion pump 3502, receiving information from other devices 3504, 3506, sending commands to the infusion pump 3502, and / or controlling it, the control of which includes, but is not limited to, programming / commanding bolus delivery, and / or programming and delivery of basal amounts, and / or programming / commanding any therapy-related commands, including, but not limited to, commands for therapy modification or therapy delivery. In some embodiments of this embodiment of the system, the miniature remote interface 3500 may also communicate with a personal computer 3508 and / or the Internet to transmit information. In some embodiments of this embodiment of the system, the remote interface 3512 may also display alarms, alerts, etc., and indicate the status of the infusion pump 3502 and / or other devices 3504, 3506. In some embodiments, the miniature remote interface 3500 may transmit data to the remote interface 3512 at regular / programmable intervals, for example, every two minutes; however, the interval may be any desired interval. In some embodiments, the miniature remote interface 3500 may transmit data to the remote interface 3512 when a command is issued by the user. In some embodiments, information programmed into the miniature remote interface 3500 by the user / caregiver may be shared by the miniature remote interface 3500 with other devices 3512, 3504, and 3506 in the system. This information may include, but is not limited to, blood glucose readings, for example, readings from a blood glucose meter that does not otherwise communicate wirelessly with the miniature remote interface 3500.

[0264] In various embodiments, the miniature remote interface 3500 may pair with the injection pump 3502 and / or various devices 3504, 3506 and / or the remote interface 3512 using, for example, any one or more of the protocols described above. However, in various embodiments, one or more devices 3504, 3506, 3512 may pair with the miniature remote interface 3500 using a standard BLUETOOTH® pairing protocol, including the BLUETOOTH® Low Energy protocol. In some embodiments, one or more devices 3504, 3506, 3512 may pair with the miniature remote interface 3500 using a Near Field Communication ("NFC") protocol, for example, the devices would share a secret key and receive a real-time key using NFC. In some embodiments, the network range may be limited during pairing. In some embodiments, the network range may be limited during pairing and one or more other types of transmission (in some embodiments, this may be pre-programmed, but not limited to, therapy and / or delivery commands and / or command changes for changes to delivery commands), otherwise, regular transmission may be resumed. In some embodiments, the network range may be limited during all transmissions, including pairing, but not limited to. Various other embodiments of pairing, which may be used between any two or more devices in various embodiments of the system, are described above and below.

[0265] In some embodiments, the communication is wireless communication and may use RF communication, for example, RF communication protocols as described above, and / or BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or may include, but are not limited to, one or more of the following protocols: WiFi, ZIGBEE®, XB, WiFi Ad Hoc, White Space, Ultra Wideband, Ant, and / or Wireless USB. In some embodiments, the communication may be the same between each device, and in some embodiments, the communication may be different between each device. In some embodiments, the miniature remote interface 3500 communicates wirelessly with the personal computer 3508, however, in some embodiments, the remote interface 3500 may be connected to the personal computer 3508 via a USB connection and / or other wired connection. In some embodiments, the miniature remote interface 3500 and the personal computer 3508 may communicate via a web / internet connection 3510 and / or via the miniature remote interface 3500 uploading information to the internet and the personal computer 3508 downloading information from the internet. In some embodiments, the remote interface 3500 and the personal computer 3508 may communicate via a wired and / or infrared ("IR") connection 3510, i.e., via the miniature remote interface 3500 uploading information to the personal computer 3508. In some embodiments, communication between the miniature remote interface 3500 and the injection pump 3502 is bidirectional. In some embodiments, communication between the miniature remote interface 3500 and the personal computer 3508 is unidirectional, i.e., the miniature remote interface 3500 may communicate with the personal computer 3508 (and / or the internet), but the personal computer 3508 (and / or the internet) may not communicate with the miniature remote interface.This could be beneficial for several reasons, including, but not limited to, controlling the information uploaded to the small remote interface 3500, which could protect the small remote interface 3500 from viruses and / or prevent unwanted and / or incorrect information from being uploaded to the small remote interface 3500.

[0266] In any one or more of the embodiments described above, in some embodiments, the miniature remote interface 3500 may include two or more radios with the ability to communicate via BLUETOOTH® low energy and / or BLUETOOTH® high energy, and / or via low energy protocols and high energy protocols. For example, in some embodiments, the miniature remote interface 3500 may communicate with the injection pump 3502 using a low-power protocol radio and with the remote interface 3512 using a high-energy BLUETOOTH® radio or a high-power protocol radio. Various other embodiments of pairing that may be used between any two or more devices in various embodiments of the system are described above and below.

[0267] Referring still to Figure 35D, in some embodiments, the remote interface 3512 may be used to control one or more devices / medical devices 3502, 3504, 3506; however, in some embodiments, the remote interface 3512 must communicate via the miniature remote interface 3500. Thus, the miniature remote interface 3500 acts as a security "firewall," i.e., a security barrier, and therefore, only the miniature remote interface 3500 may communicate directly with the infusion pump 3502 and / or other devices / medical devices 3504, 3506. Also, in some embodiments, the infusion pump 3502 and / or other devices / medical devices 3504, 3506 communicate directly only with the miniature remote interface 3500. In some embodiments of this embodiment, the miniature remote interface 3500 may use connection 3510 to communicate information received from the infusion pump 3502 and / or other devices / medical devices 3504, 3506 to the Internet and / or personal computer 3508.

[0268] Referring again to Figure 35E, in some embodiments, the miniature remote interface 3500 and the remote interface 3512 may be used to control the infusion pump 3502 and / or one or more additional devices / medical devices 3504, 3506, respectively. In some embodiments of this system, the miniature remote interface 3500 may also be a "tramp," and therefore, if both the remote interface 3512 and the miniature remote interface 3500 are simultaneously within communication range of the infusion pump 3502 and / or one or more devices / medical devices 3504, 3506, the miniature remote interface 3500 will be a device capable of communicating with the infusion pump 3502 and / or one or more devices / medical devices 3504, 3506. In some embodiments, the miniature remote interface 3500 and remote interface 3512 may communicate and synchronize information at pre-programmed intervals and / or when within a pre-programmed communication distance. For example, when the miniature remote interface 3500 and remote interface 3512 recognize that they are within communication distance and / or that a certain time interval has elapsed since the last synchronization, they may synchronize using a synchronization protocol which may be any synchronization protocol. The miniature remote interface 3500 and remote interface 3512 may also pair using various protocols described and discussed herein.

[0269] In some embodiments, the communication is wireless communication and may use RF communication, for example, RF communication protocols as described above, and / or BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or may include, but are not limited to, one or more of the following protocols: WiFi, ZIGBEE®, XB, WiFi Ad Hoc, White Space, Ultra Wideband, Ant, and / or Wireless USB. In some embodiments, the communication may be the same between each device, and in some embodiments, the communication may be different between each device. In some embodiments, the miniature remote interface 3500 communicates wirelessly with the personal computer 3508, however, in some embodiments, the remote interface 3500 may be connected to the personal computer 3508 via a USB connection and / or other wired connection. In some embodiments, the miniature remote interface 3500 and the personal computer 3508 may communicate via a web / internet connection 3510 and / or via the miniature remote interface 3500 uploading information to the internet and the personal computer 3508 downloading information from the internet. In some embodiments, the remote interface 3500 and the personal computer 3508 may communicate via a wired and / or infrared ("IR") connection 3510, i.e., via the miniature remote interface 3500 uploading information to the personal computer 3508. In some embodiments, communication between the miniature remote interface 3500 and the injection pump 3502 is bidirectional. In some embodiments, communication between the miniature remote interface 3500 and the personal computer 3508 is unidirectional, i.e., the miniature remote interface 3500 may communicate with the personal computer 3508 (and / or the internet), but the personal computer 3508 (and / or the internet) may not communicate with the miniature remote interface.This could be beneficial for several reasons, including, but not limited to, controlling the information uploaded to the small remote interface 3500, which could protect the small remote interface 3500 from viruses and / or prevent unwanted and / or incorrect information from being uploaded to the small remote interface 3500.

[0270] In any one or more of the embodiments described above, in some embodiments, the miniature remote interface 3500 may include two or more radios with the ability to communicate via BLUETOOTH® Low Energy and / or BLUETOOTH® High Energy, and / or via Low Energy and High Energy protocols. For example, in some embodiments, the miniature remote interface 3500 may communicate with the injection pump 3502 using a Low Power Protocol radio and with the remote interface 3512 using a High Energy BLUETOOTH® radio or a High Power Protocol radio. Various other embodiments of pairing that may be used between any two or more devices in various embodiments of the system are described above and below.

[0271] Referring now to Figure 36, one embodiment of various configurations of this system is shown. In this embodiment, system 3600 includes an infusion pump 3602, a remote interface 3604, a continuous glucose monitor / transmitter 3606, and a blood glucose meter 3608. In this embodiment, the various devices communicate using the Bluetooth® Low Energy (BTLE) protocol. In this embodiment, the infusion pump 3602 and the remote interface 3604 communicate using bidirectional communication. In this embodiment, the remote interface 3604 may issue commands to the infusion pump 3602, including, but not limited to, the following: therapy-related settings, which may include insulin sensitivity coefficients, carbohydrate-to-insulin ratios, blood glucose correction coefficients, and blood glucose targets; delivery commands, including bolus commands, which include normal and dual-wave or extended bolus or combined bolus; and changes to therapy and various therapy commands, including basal rate settings and basal rate changes and temporary basal rate commands; alarms and alerts; logs / history; start commands; setup / system editing; alarm and alert troubleshooting; reminders; reservoir replacement and cannula replacement, etc. All of these commands may be entered by the user or caregiver through the remote interface 3604 and communicated to the infusion pump 3602. While this embodiment is shown using the BTLE protocol, in various other embodiments, any one or more wireless communication protocols may be used, including, but are not limited to, BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or, but are not limited to, one or more of the following protocols: WiFi, ZIGBEE®, XB, WiFi Ad Hoc, White Space, Ultra Wideband, Ant, and / or Wireless USB. In some embodiments, the communication may be identical between devices, and in some embodiments, the communication may differ between devices. In addition, the devices may communicate via wired and / or USB connections, in some embodiments.In any one or more of the embodiments described above, in some embodiments, one or more devices may include two or more radios with the ability to communicate via BLUETOOTH® low energy and / or BLUETOOTH® high energy, and / or via low energy protocols and high energy protocols. For example, in some embodiments, the remote interface 3604 may communicate with the infusion pump 3602 using a low-power protocol radio and with the blood glucose meter 3608 using a high-energy BLUETOOTH® radio or a high-power protocol radio.

[0272] Referring again to Figure 37, one embodiment of various embodiments of the system is shown. In this embodiment, system 3600 includes an infusion pump 3602, a miniature remote interface 3610, a continuous glucose monitor / transmitter 3606, and a blood glucose meter 3608. In this embodiment, the various devices 3602, 3606, 3608, and 3610 may communicate using the BLUETOOTH® Low Energy (BTLE) protocol. However, this embodiment of system 3600 also includes, optionally, a personal computer 3612 which can be connected to the miniature remote interface 3610 via a USB / wired connection. In this embodiment, the infusion pump 3602 and the miniature remote interface 3610 communicate using bidirectional communication. In this embodiment, the miniature remote interface 3604 may issue commands to the infusion pump 3602, including, but not limited to, commands related to therapy, such as insulin sensitivity coefficients, carbohydrate-to-insulin ratios, blood glucose correction coefficients, and blood glucose targets; delivery commands, including bolus commands, including normal and dual-wave or extended bolus or combined bolus; and changes to therapy and various therapy commands, including basal rate settings and basal rate changes and temporary basal rate commands; alarms and alerts; logs / history; start commands; setup / system editing; alarm and alert troubleshooting; reminders; reservoir and cannula changes, etc., all of which may be entered by the user or caregiver through the miniature remote interface 3610, and these commands may be communicated to the infusion pump 3602. In addition, the personal computer 3612 may communicate with the miniature remote interface 3610 via USB, and in some embodiments, this communication may be limited to various predefined / pre-selected functions. For example, in some embodiments, a personal computer 3612 may be used to modify or establish a base profile and / or to view logs / history.This may be desirable for many reasons, including, but not limited to, the ability to attach a small remote interface 3610 to any desired personal computer 3612 and, for example, in some embodiments, log into websites, modify one or more of the underlying profiles, and / or view logs / history (which may be desirable for many reasons, including, but not limited to, a physician or healthcare provider viewing and modifying logs / history and underlying profiles). In some embodiments, additional functions may be viewed and / or modified using the personal computer 3612. In some embodiments, functions that can be viewed and / or modified may be variable, and / or pre-configured and / or pre-defined, and / or hardwired into the system. In some embodiments, the personal computer 3612 may be used to view / modify more or fewer functions, including, but not limited to, settings and / or setup, as well as any one or more of the food library and alert preferences, and, but not limited to, reminders.

[0273] While this embodiment is shown using the BTLE protocol and USB connection, in various other embodiments, any one or more wireless communication protocols may be used, including, but are not limited to, BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or, but are not limited to, one or more of the following protocols: WiFi, ZIGBEE®, XB, WiFi Ad Hoc, White Space, Ultra Wideband, Ant, and / or Wireless USB. In some embodiments, the communication may be identical between each device, and in some embodiments, the communication may be different between each device. In addition, in some embodiments, two or more devices may communicate via wired and / or USB connection, and / or communicate with a specific device via wired and / or USB connection, but may also communicate with other devices via wireless communication. In any one or more of the embodiments described above, in some embodiments, one or more devices may include two or more radios with the ability to communicate via BLUETOOTH® low energy and / or BLUETOOTH® high energy, and / or via low energy protocols and high energy protocols. For example, in some embodiments, the remote interface 3604 may communicate with the infusion pump 3602 using a low-power protocol radio and with the blood glucose meter 3608 using a high-energy BLUETOOTH® radio or a high-power protocol radio.

[0274] Referring again to Figure 38, one embodiment of various embodiments of the system is shown. In this embodiment, system 3600 includes an infusion pump 3602, a remote interface 3604, a miniature remote interface 3610, a continuous glucose monitor / transmitter 3606, and a blood glucose meter 3608. In this embodiment, the various devices 3602, 3604, 3606, 3608, and 3610 may communicate using the BLUETOOTH® Low Energy (BTLE) protocol. However, this embodiment of system 3600 also includes, optionally, a personal computer 3612 which can be connected to the miniature remote interface 3610 via a USB / wired connection. In this embodiment, the infusion pump 3602 and the miniature remote interface 3610 communicate using bidirectional communication. In this embodiment, the miniature remote interface 3604 may issue commands to the infusion pump 3602, including, but not limited to, commands related to therapy, such as insulin sensitivity coefficients, carbohydrate-to-insulin ratios, blood glucose correction coefficients, and blood glucose targets; delivery commands, including bolus commands, including normal and dual-wave or extended bolus or combined bolus; and changes to therapy and various therapy commands, including basal rate settings and basal rate changes and temporary basal rate commands; alarms and alerts; logs / history; start commands; setup / system editing; alarms and alert troubleshooting; reminders; reservoir and cannula changes, etc., including, but not limited to, commands related to these, and any embodiment of the miniature remote interface 3604 and / or miniature remote interface 3610 (as described above), all of which may be entered by the user or caregiver through the miniature remote interface 3610, and these commands may be communicated to the infusion pump 3602. In addition, the personal computer 3612 may communicate with the small remote interface 3610 via USB, and in some embodiments, this communication may be limited to various predefined / pre-selected functions.For example, in some embodiments, the personal computer 3612 may be used to modify or establish the base profile and / or view the logs / history. This may be desirable for many reasons, including, but not limited to, the ability to attach a small remote interface 3610 to any desired personal computer 3612 and, for example, in some embodiments, log into a website which may be secure / password protected, modify one or more of the base profiles, and / or view the logs / history (for many reasons, but not limited to, a physician or healthcare provider viewing and modifying the logs / history as well as the base profile). In some embodiments, additional functions may be viewed and / or modified using the personal computer 3612. In some embodiments, the functions that can be viewed and / or modified may be variable, and / or pre-configured, and / or pre-defined, and / or hardwired into the system. In some embodiments, the personal computer 3612 may be used to view / modify more or fewer functions, including, but not limited to, settings and / or setup, as well as any one or more of the food library and alert preferences, including, but not limited to, reminders.

[0275] In some embodiments of this system 3600, the remote interface 3604 may serve as a larger display for the miniature remote interface 3610, but it does not have to be used to issue commands to the infusion pump 3602 or to the miniature user interface 3610. For example, in some embodiments, the remote interface 3604 may be used to display data, including logs and / or history and / or CGM and / or BG meter trends and / or graphs and / or history. Thus, in some embodiments, the remote interface 3604 may be desirable as a larger display (and a larger portable display) to display data and other information larger and / or more clearly to the user / caregiver. In various embodiments of this embodiment, the remote interface 3604 may be any type of interface, including, but not limited to, a smartphone, and may include a downloadable application. Thus, in some embodiments, the remote interface 3604 may be an MDDS or medical device data system, and the miniature remote interface 3610 may be a dedicated device including a secure protocol.

[0276] While this embodiment is shown using the BTLE protocol and USB connection, in various other embodiments, any one or more wireless communication protocols may be used, including, but are not limited to, BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or, but are not limited to, one or more of the following protocols: WiFi, ZIGBEE®, XB, WiFi Ad Hoc, White Space, Ultra Wideband, Ant, and / or Wireless USB. In some embodiments, the communication may be identical between each device, and in some embodiments, the communication may be different between each device. In addition, in some embodiments, two or more devices may communicate via wired and / or USB connection, and / or communicate with a specific device via wired and / or USB connection, but may also communicate with other devices via wireless communication. In any one or more of the embodiments described above, in some embodiments, one or more devices may include two or more radios with the ability to communicate via BLUETOOTH® low energy and / or BLUETOOTH® high energy, and / or via low energy protocols and high energy protocols. For example, in some embodiments, the remote interface 3604 may communicate with the infusion pump 3602 using a low-power protocol radio and with the blood glucose meter 3608 using a high-energy BLUETOOTH® radio or a high-power protocol radio.

[0277] Referring again to Figure 39, one embodiment of various embodiments of system 3600 is shown. In this embodiment, system 3600 includes an infusion pump 3602, a remote interface 3604, a miniature remote interface 3610, a continuous glucose monitor / transmitter 3606, and a blood glucose meter 3608. In this embodiment, the various devices 3602, 3604, 3606, 3608, and 3610 may communicate using the BLUETOOTH® Low Energy (BTLE) protocol. However, this embodiment of system 3600 also includes, optionally, a personal computer 3612 which can be connected to the miniature remote interface 3610 via a USB / wired connection. In this embodiment, the infusion pump 3602 and the miniature remote interface 3610 may communicate using bidirectional communication, and the miniature remote interface 3610 and the remote interface 3604 may communicate using bidirectional communication.

[0278] In one embodiment of this embodiment, the miniature remote interface 3610 or remote interface 3604 may issue commands to the infusion pump 3602, including, but not limited to, commands related to, insulin sensitivity coefficients, carbohydrate-to-insulin ratios, blood glucose correction coefficients, blood glucose targets; delivery commands, including bolus commands, including normal and dual-wave or extended bolus or combined bolus; and therapy-related settings, including basal rate settings and basal rate changes and temporary basal rate commands; alarms and alerts; logs / history; start commands; setup / system editing; alarms and alert troubleshooting; reminders; reservoir and cannula changes, etc., including, but not limited to, commands related to, reservoir and cannula changes, etc., and any embodiment of the remote interface 3604 or miniature remote interface 3610 (as described above), all of which may be entered by the user or caregiver through the miniature remote interface 3610, and these commands may be communicated to the infusion pump 3602. In addition, the personal computer 3612 may communicate with the miniature remote interface 3610 via USB, and in some embodiments, this communication may be limited to various predefined / pre-selected functions. For example, in some embodiments, the personal computer 3612 may be used to modify or establish a base profile and / or view logs / history. This may be desirable for many reasons, including, but not limited to, the ability to attach the miniature remote interface 3610 to any desired personal computer 3612 and, for example, in some embodiments, log into a website that may be secure / password protected, modify one or more of the base profiles, and / or view logs / history (for many reasons, but not limited to, a physician or healthcare provider viewing and modifying logs / history and base profiles). In some embodiments, additional functions may be viewed and / or modified using the personal computer 3612.In some embodiments, the functions that can be viewed and / or modified may be variable, and / or pre-configured and / or pre-defined, and / or hardwired within the system. In some embodiments, a personal computer 3612 may be used to view / modify more or fewer functions, including, but not limited to, settings and / or setup, as well as any one or more of the food library and, but not limited to, alert preferences, including reminders.

[0279] In some embodiments of this embodiment, the remote interface 3604 may serve as a larger display version of the miniature remote interface 3610 and may not be used to issue commands to the infusion pump 3602 or to issue commands to the miniature user interface 3610. Thus, in some embodiments, the remote interface 3604 may be desirable as a larger display (and a larger portable display) to display data and other information larger and / or more clearly to the user / caregiver. In various embodiments of this embodiment, the remote interface 3604 and the miniature remote interface 3610 may each be any type of dedicated device including a secure protocol.

[0280] While this embodiment is shown using the BTLE protocol and USB connection, in various other embodiments, any one or more wireless communication protocols may be used, including, but are not limited to, BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or, but are not limited to, one or more of the following protocols: WiFi, ZIGBEE®, XB, WiFi Ad Hoc, White Space, Ultra Wideband, Ant, and / or Wireless USB. In some embodiments, the communication may be identical between each device, and in some embodiments, the communication may be different between each device. In addition, in some embodiments, two or more devices may communicate via wired and / or USB connection, and / or communicate with a specific device via wired and / or USB connection, but may also communicate with other devices via wireless communication. In any one or more of the embodiments described above, in some embodiments, one or more devices may include two or more radios with the ability to communicate via BLUETOOTH® low energy and / or BLUETOOTH® high energy, and / or via low energy protocols and high energy protocols. For example, in some embodiments, the remote interface 3604 may communicate with the infusion pump 3602 using a low-power protocol radio and with the blood glucose meter 3608 using a high-energy BLUETOOTH® radio or a high-power protocol radio.

[0281] Referring still to Figure 39, in this embodiment, system 3600 includes an infusion pump 3602, a remote interface 3604, a miniature remote interface 3610, a continuous glucose monitor / transmitter 3606, and a blood glucose meter 3608. In this embodiment, the various devices 3602, 3604, 3606, 3608, and 3610 may communicate using the BLUETOOTH® Low Energy (BTLE) protocol. However, this embodiment of system 3600 also includes, optionally, a personal computer 3612 which can be connected to the miniature remote interface 3610 via a USB / wired connection. Furthermore, in this embodiment, the infusion pump 3602 and the miniature remote interface 3610 may communicate using bidirectional communication, and the miniature remote interface 3610 and the remote interface 3604 may communicate using bidirectional communication.

[0282] In the embodiments shown in Figure 39, both the miniature remote interface 3610 and the remote interface 3604 function collectively as a single remote interface or a miniature remote user interface, as described above. In some embodiments, the remote interface 3604 may perform steps / functions that are not critical to security, and may be any device, including a smartphone, and may include a downloadable application. Thus, in some embodiments, the remote interface 3604 may be an MDDS or a medical device data system. In these embodiments, the miniature remote interface 3610 may be a dedicated device, including a secure protocol, and may perform critical steps / functions related to security.

[0283] Therefore, in these embodiments, the miniature remote interface 3610 may issue commands to the infusion pump 3602 and the remote interface 3604, and the miniature remote interfaces 3610 may communicate with each other. However, in some embodiments, important steps / commands / confirmations are entered only through the miniature remote interface 3610. Referring again here to Figure 40, an embodiment of a method for issuing a command for the delivery of a bolus 4000 is shown. This method is one embodiment and shows the steps of issuing a command for a typical bolus, however, similar steps may be used to issue a command for any type of bolus. The user / caregiver first uses the remote interface (3604) 4002 to input the number of units required for the bolus (and, in some embodiments, blood glucose and carbohydrates may also be entered into the remote interface 3604 using a bolus calculator). The remote interface 3604 displays instructions to the user / caregiver to confirm the bolus amount using the miniature remote interface (3610) 4004 (therefore, in various embodiments, the remote interface 3604 either displays the number of units entered by the user / caregiver or, in the bolus calculator function, indicates a recommended number of units based on the entered blood glucose value and carbohydrates). The user / caregiver must then confirm the displayed bolus amount using the miniature remote interface (3610) 4006. In various embodiments, the miniature remote interface may include a message informing the user of the number of units the bolus will deliver, e.g., 4.0 units, and may include an execute, start, or confirm icon, as well as a cancel icon, and in some embodiments, the cancel icon may be highlighted by default. In some embodiments, the user may use the remote interface 3604 to modify the number of units, either in the usual bolus or in the number resulting from a calculation in the bolus calculator function.However, the user / caregiver then confirms the volume on the miniature remote interface (3610) 4006, and the miniature remote interface (3610) commands the infusion pump to deliver bolus 4008. The infusion pump 3602 then delivers bolus 4010. In various embodiments, the user may choose to cancel the bolus using the miniature remote interface instead of confirming the volume in step 4006. Also in various embodiments, the delivery of the bolus in step 4010 may be canceled by the user / caregiver canceling the bolus delivery using the miniature remote interface 3610. Thus, in these embodiments, safety-critical commands are transmitted only from the miniature user interface 3610. The remote interface 3604 is used to input and view information, and therefore presents the user / caregiver with a larger, and in some embodiments, clearer display, which can be beneficial for many reasons, including, but not limited to, the ability to present a large amount of information on the display at any given time, the ability to present information in a larger format, and the ability to easily and quickly navigate through various menu items. On the other hand, the small remote interface 3610 includes a limited screen in some embodiments, and therefore it may be more difficult for the user / caregiver to view a large amount of information on a single screen. Therefore, the embodiments described above present an MDDS for displaying non-critical safety information and a dedicated, secure, smaller device for displaying critical safety information and issuing commands for critical safety information. In various embodiments of this embodiment, all critical safety inputs must be confirmed on the small remote interface 3610 before commands are sent to the injection pump 3602.For example, here again, referring to Figure 41, if a user / caregiver uses remote interface 3604 to enter or change a critical safety setting and / or enter a command 4100, the remote interface displays instructions on miniature remote interface 4102 for the user / caregiver to confirm the entry / change to the critical safety setting and / or command. The confirmation screen on miniature remote interface 3610 then prompts the user to confirm or cancel the setting or command 4104. If the user confirms the setting or command on miniature remote interface 3610 4106, the setting / command is communicated to the infusion pump 3602 and / or implemented in system 4108.

[0284] In various embodiments, safety-critical commands and / or settings may include, but are not limited to, one or more of any settings or commands that result in either calculating the amount of injectable fluid (e.g., insulin) to be delivered to the user, the amount of injectable fluid (e.g., insulin) to be delivered to the user, the time to deliver the injectable fluid to the user, and / or a command to deliver the injectable fluid to the user, and / or cancellation of the delivery of the injectable fluid. In some embodiments, the remote interface 3604 may therefore be used for non-safety-critical inputs and browsing, e.g., initiating commands (but not confirming them), entering information for the bolus calculator / wizard, and browsing the calculation of the injectable fluid to be delivered and the recommended volume using the remote interface 3604, but without confirming the information / volume or commanding the infusion pump 3602 to deliver. The remote interface 3604 may also be used to browse alarms and alerts, troubleshoot alarms and alerts, browse logbooks / logs and history, and set up and edit base profiles. However, in some embodiments, the setup and editing of the base profiles may be completed using the remote interface 3604 (or personal computer 3612), but they must be confirmed using the miniature remote interface 3610. In addition, in various embodiments, reminders may be entered using the remote interface 3604, and in some embodiments, reminders do not require confirmation from the miniature remote interface 3610, however, in some embodiments, reminders do require confirmation from the miniature remote interface 3610.In some embodiments, the time and other settings may be requested for confirmation using the small remote interface 3610; however, in other embodiments, changes to the time may be made through the remote interface 3604.

[0285] In various embodiments, depending on the embodiment, various modifications and / or commands may be classified as safety-critical and require confirmation using the miniature remote interface 3610; however, in some embodiments, various modifications and / or commands may be classified as non-safety-critical and may be implemented through the remote interface 3604 and / or personal computer 3612. However, regardless of whether the modifications / commands are classified as safety-critical in any given embodiment, they must be confirmed using the miniature remote interface 3610, or they may not be implemented / commands issued to the infusion pump 3602. Therefore, in these embodiments, information transmitted from the remote interface 3604 to the miniature remote interface 3610 is treated as data and not as commands, and none of this data is communicated to the infusion pump 3602 unless the user / caregiver confirms the information on the miniature remote interface 3610. Therefore, in these embodiments, the remote interface 3604 cannot directly issue commands to the infusion pump 3610.

[0286] Referring still to Figures 39-41, in various embodiments, commands / settings that may be considered important for safety include, but are not limited to, insulin sensitivity coefficients, carbohydrate-to-insulin ratios, blood glucose correction coefficients, blood glucose targets; delivery commands, including bolus commands, including normal and dual-wave or extended bolus or combined bolus; and therapy-related settings, including basal rate settings and basal rate changes and temporary basal rate commands; confirmation and / or muting of one or more alarms and alerts; start commands; setup / system editing; and one or more alarm and alert troubleshooting. All of these may be entered by the user or caregiver through the remote interface 3604, but final confirmation must be completed on the miniature remote interface 3610, or the changes / commands will not be communicated to the infusion pump 3602. In addition, in some embodiments, a personal computer 3612 may communicate with the miniature remote interface 3610 via USB, and in some embodiments, this communication may be limited to various predefined / pre-selected functions. For example, in some embodiments, the personal computer 3612 may be used to modify or establish the base profile and / or view the logs / history. This may be desirable for many reasons, including, but not limited to, the ability to attach a small remote interface 3610 to any desired personal computer 3612 and, for example, in some embodiments, log into a website which may be secure / password protected, modify one or more of the base profiles, and / or view the logs / history (for many reasons, but not limited to, a physician or healthcare provider viewing and modifying the logs / history as well as the base profile). In some embodiments, additional functions may be viewed and / or modified using the personal computer 3612.However, in some embodiments, various functions may be viewed or modified using the personal computer 3612, but if the function is critically related to safety, the user / caregiver must confirm any changes using the small remote interface 3610. In some embodiments, functions that can be viewed and / or modified using the personal computer 3612 may be variable, and / or pre-configured and / or pre-defined, and / or hardwired within the system. In some embodiments, the personal computer 3612 may be used to view / modify more or fewer functions, including, but not limited to, settings and / or setup, as well as any one or more of alert preferences, including, but not limited to, a food library and reminders.

[0287] In various embodiments, features such as viewing and / or modifying logs / history, troubleshooting alarms and alerts, and reminders including reservoir and cannula replacements may not be classified as non-critical safety features. In some embodiments, one or more of these may be classified as critical safety features.

[0288] In some embodiments of this embodiment, the remote interface 3604 may serve as a larger display for the miniature remote interface 3610, but it does not have to be used to issue commands to the infusion pump 3602 or to issue commands to the miniature user interface 3610. For example, in some embodiments, the remote interface 3604 may be used to display data, including logs and / or history and / or CGM and / or BG meter trends and / or graphs and / or history. Thus, in some embodiments, the remote interface 3604 may be desirable as a larger display (and a larger portable display) to display data and other information larger and / or more clearly to the user / caregiver. In various embodiments of this embodiment, the remote interface 3604 may be any type of interface, including, but not limited to, a smartphone, and may include a downloadable application. Thus, in some embodiments, the remote interface 3604 may be an MDDS or medical device data system, and the miniature remote interface 3610 may be a dedicated device including a secure protocol.

[0289] While this embodiment is shown using the BTLE protocol and USB connection, in various other embodiments, any one or more wireless communication protocols may be used, including, but are not limited to, BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or, but are not limited to, one or more of the following protocols: WiFi, ZIGBEE®, XB, WiFi Ad Hoc, White Space, Ultra Wideband, Ant, and / or Wireless USB. In some embodiments, the communication may be identical between each device, and in some embodiments, the communication may be different between each device. In addition, in some embodiments, two or more devices may communicate via wired and / or USB connection, and / or communicate with a specific device via wired and / or USB connection, but may also communicate with other devices via wireless communication. In any one or more of the embodiments described above, in some embodiments, one or more devices may include two or more radios with the ability to communicate via BLUETOOTH® low energy and / or BLUETOOTH® high energy, and / or via low energy protocols and high energy protocols. For example, in some embodiments, the remote interface 3604 may communicate with the infusion pump 3602 using a low-power protocol radio and with the blood glucose meter 3608 using a high-energy BLUETOOTH® radio or a high-power protocol radio.

[0290] In some embodiments, to confirm a command on a small remote interface, the user may be required to swipe the screen from left to right, right to left, top to bottom, bottom to top, and / or diagonally. In some embodiments, one or more buttons may be required to be pressed for a predetermined time period, for example, 3 seconds. However, the amount of time may vary in various embodiments. In some embodiments, the user may be required to bring the small remote interface close to the remote interface for confirmation. In some embodiments, confirmation may be achieved by pressing a switch assembly on the injection pump.

[0291] In some embodiments where a small remote interface is required to confirm commands, if the user / caregiver loses access to the small remote interface, the user may use a predefined encrypted signal, such as a dial tone or voice recognition, which is played / spoken to the infusion pump to confirm the command. In some embodiments, a secure call center may exist, and the user / caregiver may make a call and, after identifying themselves using either a passcode, patient confidential information, etc., receive a confirmation tone that can be received by the infusion pump to complete the command from the remote interface.

[0292] Pairing of various devices may be achieved using any of the methods described above or using methods known in the art, such as BLUETOOTH® pairing. However, in some embodiments, the various devices may be paired using short-range communication. In some embodiments, the devices may be paired using a wired connection, including, but not limited to, a USB connection. In some embodiments, a method for pairing any one or more of the various devices of a system with an infusion pump and a small remote interface and / or a remote interface and / or any one or more devices may include the step of performing the pairing in an area where the devices are in close proximity to each other and where the likelihood of interference from additional devices is low, for example, at the user's / caregiver's home / office.

[0293] Referring again to Figure 42, a flowchart illustrating a methodology 4200 for securely communicating between one or more devices, such as between a medical device and a user interface / remote interface / miniature user interface device, according to one embodiment of the present disclosure. Method 4200 includes operations 4204-4220. Operation 4204 involves a master device and a slave device establishing communication over a communication link. The communication link may not be secure. In some embodiments, the communication link may use public-private-key cryptography. Operation 4206 involves a master device (e.g., a medical UI / remote interface / miniature remote interface device) and a slave device (e.g., a blood glucose meter, a continuous glucose monitor transmitter, etc.) arranging a prime number p and a radix g using the communication link. The arrangement may occur over a wired link using an encrypted communication link, or using public-private-key pairing cryptography. Radix g is a primitive root modulo p. P and g may be publicly known. In action 4208, the master device generates a random number a and calculates u = g^a (mod p). In action 4210, the master device transmits a and u to the slave device. In action 4212, the slave device generates a random number b, calculates the computer v = g^b (mod p), and communicates b and vg^b (mod p) to the master device.

[0294] In action 4216, the master device calculates a key k, where k = v^a = (g^b)^a (mod p). In action 4218, the slave device calculates a key k, where k = u^b = (g^a)^b (mod p). The symmetric keys were never communicated; that is, they were generated internally by the individual devices. In action 4220, the master and slave devices use the shared secret key k as a seed for the symmetric encryption key. The secret key may also be used as an index for a pseudorandom index, in which case the pseudorandom index is the key for the symmetric key.

[0295] Referring again to Figures 43A-43J, several embodiments of screenshots on the miniature remote interface 3610 are shown. In various embodiments, the miniature remote interface 3610 may include one or more user inputs, which may include, but are not limited to, one or more buttons, a scroll wheel, or a touchscreen. In some embodiments, the display may include a touchscreen, where the user / caregiver first scrolls and selects a particular command (which may be done using one of the user inputs), then touches the screen at another specific location, and swipes the screen either from left to right or right to left to confirm or select a particular command. In some embodiments, for example, as shown in Figure 43A, the user / caregiver may be required to swipe the screen from left to right to unlock the screen, while in some embodiments, for example, as shown in Figure 43J, the user / caregiver may be required to swipe the screen from right to left to select or confirm. This may be desirable / beneficial for several reasons, including, but not limited to, preventing unintentional confirmation by requiring the user to confirm by swiping in a direction different from the direction of unlocking. In various embodiments, the directions for each action may differ. In some embodiments, the direction for unlocking may be right to left, and the direction for confirmation / selection may be left to right. In some embodiments, a confirmation swipe on a screen that does not have any selection will advance the screen to another screen, which may be the next screen in the user interface. Referring again here to Figures 43C-43D, in some embodiments the miniature remote interface 3610 may include a display that includes a menu selection. Menu selection may be scrolled by swiping the screen or by other user input. Menu selection may then be selected by the user / caregiver. Referring again to Figures 43E-43G, in various embodiments, once the user / caregiver is navigated to the Bolus home screen, the user / caregiver may select the type of Bolus to deliver manually or by another type (represented by a preset), for example, using a wizard / calculator. In some embodiments, scrolling through menu items may be achieved by using a touchscreen, touching a specific position, and then swiping up or down from that position as various options are highlighted. Once a desired option is highlighted, the user / caregiver may select that option by swiping from right to left, for example, or by using other user input, for example, one or more buttons and / or a scroll wheel. Referring again to Figure 43G, once a desired option is selected, for example, by a wizard, the user may swipe the screen. In some embodiments, the user may select by touching the screen.

[0296] Referring again to Figures 43K-43N, in various embodiments, once a bolus type, such as a wizard, is selected, the next screen prompts the user to enter blood glucose and carbohydrate values. In various embodiments, there may be a screen / scroll function for entering these values, and the screen scrolling may be achieved by swiping the screen up or down to scroll. In some embodiments, other user inputs may be used. In some embodiments, once the desired values ​​are entered, the user may swipe the screen, for example, from right to left, to select a value and proceed to the next screen.

[0297] Referring also to Figures 43M and 43N, in various embodiments, the miniature remote interface may include a timeout feature, which may include a predefined amount of time, for example, after 3 seconds, the display turning off or locking. In some embodiments, the miniature remote interface may also provide a warning to the user / caregiver that the timeout is approaching, for example, by graying out or fading out part of the screen, as shown in Figures 43M-43N. Other methods of warning about a timeout may also be used.

[0298] Referring again to Figure 43O, in various embodiments, information may be displayed to the user / caregiver on the display of a small remote interface, and may include symbols or words indicating either approval or cancellation. In various embodiments, the user / caregiver may select either the approve or cancel icon by scrolling and swiping in the appropriate direction, or by selecting using any one or more of various user inputs.

[0299] In some embodiments, confirmation / selection may be completed, for example, by simultaneously pressing one or more button user inputs or a combination thereof.

[0300] Various embodiments of screenshots and methods that may be used by remote interfaces have been described above. However, additional screenshots and methods for user interfaces, one or more of which may be used by miniature remote interfaces and / or remote interfaces in various embodiments of the systems described herein, are shown in Figure 44A-58T.

[0301] Referring again to Figures 44A-44B, in various embodiments the screen may be locked, which can be beneficial for several reasons, including, but not limited to, preventing unintentional changes to settings and / or commands sent to the injection pump. In some embodiments, a locked screen may require a passcode to unlock it. In various embodiments, the screen remains locked, and settings cannot be changed and commands cannot be sent unless a passcode is entered to unlock it.

[0302] Referring here to Figure 45A, in various embodiments the home screen may include icons for selection to navigate to specific function menus. Referring here again to Figure 45B, the icons may be located at the bottom of the home screen. In various embodiments the home screen may include information showing the amount of insulin (or other injectable fluid) remaining in the reservoir, the percentage of remaining battery life, and the basal amount, and, if applicable, the current delivery rate for a bolus. For example, in Figure 45B, the home screen shows that basal pattern A is currently being delivered, and its rate, e.g., 5.50 units / hour, is also shown. The home screen also shows that a square wave bolus is being saved, with 1.02 of 1.88 units delivered and 6 minutes remaining for the square wave bolus.

[0303] Referring again to Figure 45C, the home screen shown normally includes an indication that a bolus has been delivered and that 10.04 out of 14.00 units have been delivered. During a bolus event, the user / caregiver may stop the bolus by pressing the “Stop Bolus” button on the home screen. Referring again to Figures 45D and 45E, another embodiment of the home screen is shown. In Figure 45D, a “Basal Override” event lasting 1 hour and 50 minutes is also shown. In this embodiment, the rate is shown as 6.50 units / hour. Referring again to Figure 45E, in this embodiment of the home screen, a “Temporary Basal Rate” event is shown, which includes a 50% increase in the basal rate for 1 hour and 30 minutes. The rate is 6.25 units / hour. In both Figures 45D and 45E, the active insulin is shown as, for example, 0.21 units. Thus, in all of the embodiments shown, the home screen represents the current delivery status and the active insulin / injectable fluid.

[0304] Referring again to Figures 46A-46B, in various embodiments, the base pattern may be programmed by inputting start and end times and rates between those time frames. In various embodiments, the base pattern may be displayed as a graph representing the base pattern delivery rate throughout the entire 24-hour cycle. In various embodiments, as shown in Figure 46B, once the base pattern is programmed, the user / caregiver may review the entire pattern, including the graphical representation and time frames, on a single screen. In addition, the base pattern may be switched by selecting “Base Pattern Switching” and then selecting a different base pattern. Graphical representations may be beneficial / desirable for many reasons, including, but are not limited to, presenting the base pattern / profile in a way that clearly indicates when the rate is higher or lower and presents an overall picture throughout the day.

[0305] Referring again to Figures 47A-47C, in some embodiments, the base pattern / profile may be programmed by the user / caregiver tracing a rate using the touchscreen functionality of the interface and their finger or stylus, etc. Once the base pattern / profile is drawn, the system renders a graphical representation, and the user may view and / or edit the pattern / profile.

[0306] Referring again to Figures 48A-48D, in various embodiments, in order to adjust an arbitrary rate in the base pattern, the user / caregiver may navigate to adjust the base pattern and then select the rate they wish to adjust. Once selected, the current rate indication is presented to the user / caregiver, along with scrolling as it functions. The user / caregiver may then adjust the rate by using the arrows on the scroll wheel and then select "OK" to save the new rate.

[0307] Referring again to Figures 49A-49B, in various embodiments, a temporary base rate may be set. In some embodiments, this may be done by navigating to a "Temporary Rate Setting" screen, where the new rate may be entered using a keypad in some embodiments (see Figure 49B), and the duration of the new rate may be entered using a scroll wheel function in some embodiments (see Figure 49A). A graphical representation of the base pattern can also be used to visualize the difference between the rates before and after the temporary rate, which can help in programming a sufficient rate, thus assisting the user / caregiver in programming the temporary rate.

[0308] Referring again to Figures 50A-50B, in various embodiments, the base patterns / profiles may be managed using a base profile management screen. For example, as shown in Figure 50A, in some embodiments, the base patterns may be viewed on a single screen that collectively shows the number of units per day. This screen also includes the current pattern. This screen may also include a button for creating a new pattern. In some embodiments, once a pattern is selected from the managed base pattern screen, a graphical representation of the pattern may be displayed with options to adjust the rate, set it as the current pattern, delete the pattern, or copy the pattern (to create another pattern with the same pattern but a new name) (see Figure 50B).

[0309] Referring here to Figures 51A-51B, in various embodiments the user interface may include a “preset bolus” option, allowing the user / caregiver to pre-set bolus amounts and / or bolus types for, for example, breakfast, lunch, and dinner. To request the delivery of a preset bolus, in some embodiments the user selects a preset bolus, e.g., breakfast. The user interface then navigates to another screen (see Figure 51B) showing the bolus type and amount, e.g., a normal bolus and 2.50 units. The user / caregiver may select “Deliver,” and the preset bolus may be delivered. In various embodiments, preset boluses may be added and / or adjusted, deleted, or copied using the screen shown in Figure 51A (see Figure 51B).

[0310] Referring here to Figures 52A-52D, in various embodiments the user interface may include a “bolus wizard” or bolus calculator. In various embodiments the bolus wizard or bolus calculator may require the user to input the amounts of carbohydrates and blood glucose using a keypad (a screenshot of carbohydrates is shown in Figure 52A; the blood glucose keypad is similar in various embodiments). However, in some embodiments the last blood glucose reading may be used if the user chooses to use it, or the user may choose to calculate the bolus without using the blood glucose reading. An embodiment of this is shown in Figure 52B, the following screen showing the calculation of the user’s corrected bolus, insulin corrected (based on active insulin, 2.45 units in this embodiment), and dietary bolus (based on carbohydrates), based on blood glucose (125 mg / dl in this embodiment). The total bolus amount is also shown (7.50 in this embodiment). The user may then adjust the calculated “total bolus” amount and / or choose to deliver part or all of the total bolus as an extended bolus or a “square wave” or “double wave” bolus. Referring here to Figure 52C, in various embodiments, to deliver part of the bolus as a normal bolus and part of the bolus as a square wave bolus (or extended bolus), the user interface presents the user / caregiver with a sliding scale where the amount to be delivered as normal, represented as both units and a percentage of the total, is shown on one side of the line, and the amount to be delivered as a square wave, represented as both units and a percentage of the total, is shown on the other side. The user / caregiver may adjust the percentages of the amount to be delivered as normal and square wave by moving a rectangular icon toward the square wave side or the normal side. While moving the rectangular icon, the sums on both sides are adjusted so that the user / caregiver can see the percentage and total unit changes in real time.

[0311] Once the total amount to be delivered as normal and square waves has been selected, the user / caregiver may program the duration of the square wave using the on-screen scroll wheel (see Figure 52D).

[0312] Referring again to Figure 53, in various embodiments, the preset bolus may also be adjusted to include normal and square wave portions. In various embodiments, the normal and square wave ratios are pre-programmed into the preset bolus. For example, in Figure 53, the “lunch” preset bolus includes 1.25 units delivered as a normal bolus and 1.25 units delivered as a square wave bolus over one hour for a total of 2.50 units.

[0313] In various embodiments, the user may input a normal bolus quantity and then choose to deliver part or all of the total bolus as an extended bolus or a "square wave" or "double wave" bolus. Referring here to Figure 52C, in various embodiments, to deliver part of the bolus as a normal bolus and part of the bolus as a square wave bolus (or extended bolus), the user interface presents the user / caregiver with a sliding scale where the quantity to be delivered as normal, expressed as both units and a total percentage, is shown on one side of the line, and the quantity to be delivered as a square wave, expressed as both units and a total percentage, is shown on the other side. The user / caregiver may adjust the percentages of the quantities to be delivered as normal and square wave by moving a rectangular icon toward the square wave side or the normal side. While moving the rectangular icon, the totals on both sides are adjusted so that the user / caregiver can see the change in percentage and total units in real time.

[0314] Referring again to Figures 54A-54D, in various embodiments, various reminders may be entered / programmed by the user / caregiver. These include, but are not limited to, a reminder for the user / caregiver to check blood glucose after a bolus (see Figure 54A). With regard to checking the blood glucose reminder, the user / caregiver may program the duration between the bolus and the reminder by using a scroll wheel to program the time and minutes until the reminder. In addition, the user / caregiver may turn the reminder on and off. Additional reminders include, but are not limited to, a cannula-filling blood glucose reminder, which can be programmed to remind the user / caregiver to check the blood glucose after a certain (programmed) duration after filling the cannula. Infusion site reminders may also be programmed. As shown in Figure 54D, in some embodiments, once the infusion site is changed, the reminder may be set to remind the user / caregiver to change the infusion set again after a programmed number of days. The programmed number of days may be selected by the user / caregiver using the screen scroll wheel. In some embodiments, the system may include a default number of days, e.g., 2 days, which may be modified by the user / caregiver to any desired number of days, e.g., 3 days. As with other reminders, in this embodiment, this reminder may be turned on or off according to the user / caregiver's preference. In some embodiments, a reminder to check blood glucose may be set by the user / caregiver, and this may be set for any number of hours / minutes from the time the reminder is created. In some embodiments, this type of reminder is triggered at the user / caregiver's request. For example, in some embodiments, the user / caregiver may have recently been treated for hypoglycemia with glucose and may want the reminder to remind them to recheck their blood glucose after a certain duration, e.g., 15 minutes. However, any duration may be programmed by the user using the screen scroll wheel, as shown in Figure 54C, in some embodiments.

[0315] Other reminders may also be programmed by the user, and include, but are not limited to, meal reminders. In some embodiments, the user / caregiver may program a reminder for the time when a meal is expected. In some embodiments, if a bolus is not requested during a pre-programmed / user-programmed duration before or after that time, the reminder may alert the user that they may have either forgotten to eat or have not delivered a bolus for a meal. In various embodiments, these reminders may be programmed to alert the user daily as recurring reminders, or they may be single reminders.

[0316] Referring again to Figure 55A, in some embodiments, the walkaway alert may be included within the remote interface / injection pump / and / or miniature remote interface system. The user may either turn the walkaway alert on or off, and the system may be programmed to alert for a certain duration after determining that the controller and pump are out of range. In some embodiments, the duration may be pre-programmed or adjustable by the user. In some embodiments, the user may adjust the duration using a screen scroll wheel.

[0317] Referring again to Figures 56A-56C, in some embodiments, the user interface may include blood glucose targets that can be programmed by the user / caregiver and used in various calculations by the system, including, but not limited to, blood glucose correction bolus calculations. In various embodiments, the user interface includes the ability to set various blood glucose targets for various time frames / intervals throughout the entire 24-hour cycle. In various embodiments, the blood glucose targets may be represented to the user / caregiver in graphical form. In various embodiments, the blood glucose targets may include low and high targets for each time frame / interval. This may be desirable for several reasons, including, but not limited to, the ability for the user / caregiver to visualize the various time frames / intervals and the targets between them in a single graphical representation. This may be beneficial / desirable for several reasons, including, but not limited to, the ability to select the correct targets during programming, and in some embodiments, this may prevent errors during programming. In addition to the graphical representation, each time frame / interval is written and includes high and low targets (see Figure 56A). To change a specific interval, the user may use the touchscreen to tap the specific interval, or in some embodiments, tap either a written interval section or a graphical representation of that interval. A new screen appears, including a screen scroll wheel for changing the interval and / or changing the target (low and / or high) (see Figure 56B). In some embodiments, by selecting an interval, the user may “remove the target” by selecting an option on the screen (see Figure 56C).

[0318] Referring here to Figures 57A-57C, in some embodiments, the user interface may include carbohydrate ratios that can be programmed by the user / caregiver and used in various calculations by the system, including, but not limited to, meal bolus calculations and / or meal and corrected bolus calculations. In various embodiments, the user interface includes the ability to set carbohydrate ratios between various time frames / intervals throughout a 24-hour cycle. In various embodiments, the carbohydrate ratios may be represented to the user / caregiver in graphical form. In various embodiments, the carbohydrate ratios include values ​​representing grams of carbohydrates per unit of an injectable fluid, e.g., insulin. This may be desirable for several reasons, including, but not limited to, the ability for the user / caregiver to visualize various time frames / intervals and the ratios between them in a single graphical representation. This may be beneficial / desirable for several reasons, including, but not limited to, the ability to select the correct ratios during programming and, in some embodiments, the ability to prevent errors during programming. In addition to graphical representation, each time frame / interval is written and includes the carbohydrate ratios between that time frame / interval (see Figure 57B). To change a specific interval, the user may use the touchscreen to tap the specific interval, or in some embodiments, tap either a written interval section or a graphical representation of that interval. A new screen appears, including a screen scroll wheel for changing the interval and / or the ratio (see Figure 57C). In some embodiments, the user may “delete the target” by selecting an interval, or by selecting an option on the screen (see Figure 57A).

[0319] Referring here to Figures 58A-58T, in various embodiments, the user interface includes a logbook. In various embodiments, the logbook includes both the functionality to receive information from the user / caregiver and process that information (referred to as “events”), and the functionality to display the system’s historical data. Referring here to Figure 58A, in some embodiments, the logbook homepage may include the last blood glucose entered into the system (or, in some embodiments, directly collected by the system), the duration since the last blood glucose, the volume of the last bolus delivery, and the duration since the last bolus. In some embodiments, the logbook homepage also includes menu options for the user / caregiver to navigate to various sections of the logbook. In some embodiments, various sections may include, but are not limited to, “Last Glucose Input,” “Event Input,” “View Daily Totals,” and “View Event History.” In various embodiments, the logbook homepage also includes menu icons for navigating to other sections of the user interface.

[0320] Referring again to Figures 58B-58G, in some embodiments, the logbook includes the ability for the user / caregiver to input “events,” which may include the number of grams of carbohydrates ingested by the user, exercise events, and / or insulin injection / medication events. The user / caregiver may then be navigated to input the appropriate events. In some embodiments, the user / caregiver may input a “carbohydrate event” by navigating to the appropriate screen and inputting the number of grams of carbohydrates consumed (see Figure 58B). In some embodiments, the user interface may also include the type of carbohydrate / food consumed, such as pizza, cupcakes, sushi, lasagna, brown rice, Mom's Chicken Soup, etc. Once the user / caregiver presses "Next," a review screen appears showing the grams of carbohydrates consumed and the date and time of the event (see Figure 58C). In some embodiments, the user / caregiver may input the "exercise event" by navigating to the appropriate screen and entering the exercise intensity (low, medium, or high) (see Figure 58D). In some embodiments, the user interface may also include the type of exercise (skiing, hiking, walking, weightlifting, mountain biking, swimming, paddleboarding, kayaking, etc.). Once the user / caregiver presses "Next," they may enter the duration of the exercise (see Figure 58E). Finally, the details of the exercise event may be reviewed by the user / caregiver (see Figure 58F). Once the user / caregiver confirms that the information is correct, the event is saved in the logbook for future reference by the user / caregiver (see Figure 58G). A similar event input method may be followed to input insulin injections or other medication events. The type and amount of medication may be entered, which will then be saved in the logbook to indicate the time, type, and amount of medication for later review.

[0321] The ability to input specific events, while not limiting, can be beneficial / desirable for many reasons, including the ability to track the consequences of an event for either reviewing previous events and making decisions regarding future dosages of insulin or other medications, and / or deciding on changes to eating patterns based on the results from exercise or specific food intake, such as reviewing blood glucose readings after exercise, medication, or carbohydrate events. The ease of inputting these events may make it easier for individuals with diabetes and other diseases to input events, which may lead to improved health.

[0322] Referring again to Figures 58H-58L, in various embodiments, the logbook also includes historical data, which is presented to the user / caregiver upon request by navigating the user interface to the daily total (Figure 58I), daily dose (Figure 58J), total carbohydrates (Figure 58K), and average blood glucose (Figure 58L) sections of the logbook. Referring again to Figure 58H, the user / caregiver may choose to view the "daily total" from a specific date, for example, December 4, 2013. However, in various embodiments, a different date may be selected. The daily total dose, total carbohydrates, and average BG are then displayed for that particular date (Figure 58I). The user / caregiver may then choose to view any one of those menu items in detail. When the user / caregiver selects the "Total Daily Dose" menu item, the Daily Dose screen appears (Figure 58J), which in some embodiments includes the total insulin given, the percentage of basal and bolus deliveries to the total, and different types of bolus deliveries, e.g., carbohydrate (diet) bolus, BG (corrected) bolus, manual (normal) bolus, etc. When the user / caregiver selects the "Total Carbohydrate" menu item, the Total Carbohydrate screen appears (Figure 58K), which in some embodiments includes total carbohydrates (e.g., entered into the system through a carbohydrate / diet bolus, a carbohydrate event and / or a bolus calculator), bolus wizard carbohydrates (including carbohydrates entered only through the bolus wizard / bolus calculator), the time the carbohydrates were entered through the bolus wizard / bolus calculator, and total logbook carbohydrates (carbohydrates entered as events), as well as the time of the carbohydrate events. In various embodiments, the type of information displayed on various screens may vary.

[0323] Referring again to Figure 58L, in various embodiments, the logbook includes an "Average Book Glucose" screen that presents information about blood glucose readings for a specific day (selected by the user / caregiver, which in this embodiment is December 3, 2013). The Average Glucose screen includes the average blood glucose for all blood glucose readings for the day, and lists the number of readings per hour and any other findings / indications (i.e., through findings or pre-programmed target values) that the system, or in some embodiments, the user / caregiver, believes to be attributable to that reading. In some embodiments, the system may assign a "Low" descriptor to any blood glucose reading below the low blood glucose target during that time frame / interval, and a "High" descriptor to any blood glucose reading above the low blood glucose target during that time frame / interval.

[0324] Referring again to Figures 58M-58T, in various embodiments, the user / caregiver may view events in the logbook by specifying, for example, a date, such as December 5, 2013 (see Figure 58M). The event history screen would then display various events from the specified date, which in Figure 58N is December 4, 2013 (Figure 58N). For each event, the user / caregiver may select the event by, for example, tapping a section using a touchscreen, and the event itself will be displayed. For example, if the first event, "Normal Bolus Stop" event shown in Figure 58N, is selected, the screen shown in Figure 58O will be displayed to include specific information about the event. Similarly, if setting change events are listed in the event history, the user / caregiver may select the event by, for example, tapping a section using a touchscreen, and the event itself will be displayed (see Figure 58P). Thus, the user / caregiver can accurately review which settings were changed and when. If a double-wave bolus event is listed in the event history, the user / caregiver may select the event by, for example, tapping a section using a touchscreen, and the event itself will be displayed (see Figure 58Q). A bolus event includes the bolus type (double-wave), the time of the event (7:14:22 pm), and details, such as units delivered as a normal bolus and units delivered as a square-wave bolus. If base rate change events are listed in the e...

Claims

[Claim 1] A system that meets patent requirements.

Images