Device, method, and system for wirelessly controlling medical device

Abstract

To provide a device, a method, and a system suitable for wirelessly controlling a medical device.SOLUTION: There is provided a medical device system. The system includes a first medical device, a first remote interface, and a second remote interface for communicating with the first remote interface and the first medical device. The first medical device transmits a command to the first medical device through the second remote interface. When the command is received by the second remote interface, 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.SELECTED DRAWING: Figure 39

Description

[Technical Field]

[0001] (Technical field) FIELD OF THE DISCLOSURE The present disclosure relates to medical devices, and more particularly to a system for controlling at least one medical device. [Background technology]

[0002] (Background information) Many potentially valuable drugs or compounds, including biologics, are not orally effective due to poor absorption, 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 the desired schedule. In such cases, parenteral delivery is often employed or can be employed.

[0003] Effective parenteral routes of drug delivery and other fluids and compounds, such as subcutaneous injection, intramuscular injection, and intravenous (IV) administration, involve puncturing 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 could benefit from a wearable device that automatically delivers the required drug / compound over a period of time.

[0004] To this end, 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 suffer from numerous drawbacks, including a high rate of malfunction. Reducing the size, weight, and cost of these devices is also an ongoing challenge. In addition, these devices are often applied to the skin, posing the challenge of frequent repositioning for application.

[0005] For a single user, managing multiple medical devices simultaneously presents challenges. For one, the hardware, many of which include dedicated interfaces, presents logistical challenges for multiple "controllers" or "handhelds" for wirelessly controlled medical devices. First, the various interfaces can be difficult to direct attention from one interface to another and the master. Second, recharging multiple devices can present challenges, and third, transporting a medical device with multiple controllers presents challenges. Summary of the Invention [Means for solving the problem]

[0006] (summary) According to one aspect of the present invention, a medical device system is disclosed, which includes a first medical device, a first remote interface, and a second remote interface in communication with the first remote interface and the first medical device, wherein the first medical device sends a command to the first medical device through the second remote interface, and when the second remote interface receives the command, the command must be acknowledged by the second remote interface before the command is sent to the first medical device by the second remote interface.

[0007] Some embodiments of this aspect of the 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; and the second remote interface is not a medical device data system; the system further includes a blood glucose meter in communication with the second remote interface; and the system further includes a continuous glucose monitor transmitter in communication with the second remote interface. The first remote interface receives a command related to communication of safety-critical information to the first medical device, displays a message requesting confirmation that communication of the safety-critical information to the first medical device is using the second remote interface, and transmits a communication to the second remote interface, and once the 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 a bolus volume of infusible fluid by the infusion pump and displays a message requesting confirmation of the delivery of the bolus volume using the second remote interface, and once confirmation is received by the second remote interface, the second remote interface communicates to the infusion pump the information required for the delivery of the bolus volume of infusible fluid.

[0008] According to one aspect of the present invention, a medical device system is disclosed, which includes a first medical device, a first remote interface having a medical device data system, and a second remote interface in communication with the first remote interface and the first medical device, wherein the first medical device transmits safety-critical commands to the first medical device through the second remote interface, and when the second remote interface receives the safety-critical command, the command must be acknowledged by the second remote interface before the safety-critical command is transmitted to the first medical device by the second remote interface.

[0009] Some embodiments of this aspect of the 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 includes a blood glucose meter in communication with the second remote interface; the system further includes a continuous glucose monitor transmitter in communication with the second remote interface; the first remote interface receives input of information related to delivery of a bolus volume of infusible fluid by the infusion pump and displays a message requesting confirmation of delivery of the bolus volume using the second remote interface, and once confirmation is received by the second remote interface, the second remote interface communicates the information required for delivery of the bolus volume of infusible 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 including: a first remote interface receiving a command related to communication of safety-critical information to a first medical device; the first remote interface displaying a message requesting confirmation that the communication of the safety-critical information to the first medical device uses 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 invention may include one or more of the following: The first medical device is an infusion pump; The command is related to delivering a bolus of infusible fluid; The command is related to stopping delivery of a basal rate of infusible 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 including a touchscreen. The remote interface wirelessly communicates 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. Also included is a charging device. The charging device is configured to receive at least the first medical device and the remote interface, the charging device is configured to recharge a first medical device battery, and the charging device is configured to recharge an interface battery in the remote interface. The charging device is connected to a personal computer, and the personal computer provides information to the remote interface.

[0013] 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 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; the charging device is configured to receive at least one of the at least two reusable parts of the first medical device; the second medical device is a continuous glucose monitor system including 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 the 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; and the system further includes the wireless communication being radio frequency communication; the first medical device and the remote interface are paired using short-range communication; and / or the remote interface further includes 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 that wirelessly communicates with the first medical device. The system also includes a remote interface including a touchscreen. The remote interface wirelessly communicates with the first medical device, and 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. The system also includes a charging device configured to receive the first medical device and the remote interface. The charging device is configured to recharge the first medical device battery and the charging device is configured to recharge an interface battery within the remote interface. The charging device is connected to a personal computer, and the personal computer provides information to the remote interface.

[0015] Some embodiments of this aspect of the invention may include one or more of the following: The 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 the at least one disposable part. The charging device is configured to receive at least one of the at least two reusable parts of the first medical device. The second medical device includes a continuous glucose monitor system including at least one transmitter, the at least one transmitter wirelessly communicating with the first medical device. The second medical device includes a blood glucose meter wirelessly communicating with the first medical device. The first medical device and the remote interface are paired using short-range communication. The first medical device and the second medical device are paired using short-range communication.

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

[0017] Some embodiments of this aspect of the invention may include one or more of the following: The system further includes a continuous glucose monitor system including at least one transmitter, the at least one transmitter in wireless communication with the remote interface; The system further includes at least one blood glucose meter, the blood glucose meter in wireless communication with the remote interface; The 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] In accordance with one aspect of the present invention, an infusion pump system is disclosed that includes an infusion pump and a remote interface device in wireless communication with the infusion pump that includes instructions for controlling the infusion pump, the instructions optionally being synchronized with a secure web portal.

[0019] Some embodiments of this aspect of the invention may include one or more of the following: The system further includes a continuous glucose monitor system including a transmitter, the transmitter communicating wirelessly with the remote interface device; The system further includes a blood glucose meter, the blood glucose meter communicating wirelessly 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 that includes a first medical device and a second medical device in wireless communication with the first medical device, the second medical device including instructions for controlling the first medical device, the instructions optionally being synchronized with a secure web portal.

[0021] Some embodiments of this aspect of the 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 short-range 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 short-range 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 short-range communication.

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

[0023] Some embodiments of this aspect of the 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 sensor / transmitter; 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 review of the appended claims in conjunction with the accompanying drawings. The present specification also provides, for example, the following items: (Item 1) 1. A medical device system, comprising: a first medical device; a first remote interface; a second remote interface in communication with the first remote interface and the first medical device; Equipped with the first medical device transmitting a command to the first medical device through the second remote interface; A medical device system, wherein when the second remote interface receives the command, the command must be confirmed by the second remote interface before the command is sent by the second remote interface to the first medical device. (Item 2) Item 10. The medical device system of item 1, wherein the first medical device is an infusion pump. (Item 3) Item 10. The medical device system of item 1, wherein the first remote interface is a medical device data system. (Item 4) Item 10. The medical device system of item 1, wherein the second remote interface is not a medical device data system. (Item 5) Item 10. The medical device system of item 1, wherein the system further comprises a blood glucose meter in communication with the second remote interface. (Item 6) 2. The medical device system of claim 1, wherein the system further comprises a continuous glucose monitor transmitter in communication with the second remote interface. (Item 7) The first remote interface includes: receiving a command related to communication of safety-critical information to the first medical device; displaying a message requesting confirmation that communication of safety-critical information to the first medical device will use the second remote interface; transmitting the communication to the second remote interface; 2. The medical device system of claim 1, wherein once confirmation is received by the second remote interface, the second remote interface communicates the command to the first medical device. (Item 8) The first remote interface includes: receiving input of information related to delivery of a bolus volume of infusible fluid by said infusion pump; displaying a message requesting confirmation that the bolus volume will be delivered using the second remote interface; 3. The medical device system of claim 2, wherein once confirmation is received by the second remote interface, the second remote interface communicates to the infusion pump information required for delivery of a bolus volume of the infusible fluid. (Item 9) 1. A medical device system, comprising: a first medical device; a first remote interface comprising a medical device data system; a second remote interface in communication with the first remote interface and the first medical device; Equipped with the first medical device transmitting a safety-critical command to the first medical device through the second remote interface; A medical device system, wherein when the second remote interface receives the safety-critical command, the command must be confirmed by the second remote interface before the safety-critical command is sent by the second remote interface to the first medical device. (Item 10) Item 10. The medical device system of item 9, wherein the first medical device is an infusion pump. (Item 11) 10. The medical device system of claim 9, wherein the first remote interface is a medical device data system. (Item 12) 10. The medical device system of claim 9, wherein the second remote interface is not a medical device data system. (Item 13) Item 14. The medical device system of item 13, wherein the system further comprises a blood glucose meter in communication with the second remote interface. (Item 14) Item 15. The medical device system of item 14, wherein the system further comprises a continuous glucose monitor transmitter in communication with the second remote interface. (Item 15) The first remote interface includes: receiving input of information related to delivery of a bolus volume of infusible fluid by said infusion pump; displaying a message requesting confirmation that the bolus volume will be delivered using the second remote interface; Item 11. The medical device system of item 10, wherein once confirmation is received by the second remote interface, the second remote interface communicates to the infusion pump information required for delivery of a bolus volume of the infusible fluid. (Item 16) 1. A method of communication for a medical system, comprising: receiving, by a first remote interface, a command related to communication of safety-critical information to a first medical device; displaying a message on the first remote interface requesting confirmation that communication of the safety-critical information to the first medical device will use a second remote interface; and the first remote interface transmitting the communication to the second remote interface; the second remote interface receiving a confirmation; and the second remote interface communicating the command to the first medical device; A method comprising: (Item 17) Item 17. The method of item 16, wherein the first medical device is an infusion pump. (Item 18) 17. The method of claim 16, wherein the command relates to the delivery of a bolus of infusible fluid. (Item 19) 17. The method of claim 16, wherein the command relates to stopping delivery of a basal rate of infusible fluid. (Item 20) Item 17. The method of item 16, wherein the first remote interface is a medical device data system. (Item 21) 1. A medical device system, comprising: a first medical device; a second medical device; and a compact remote interface comprising a touchscreen, the compact remote interface wirelessly communicating with the first medical device and the second medical device, the compact remote interface configured to provide a user interface to the first medical device and the second medical device, and the compact remote interface configured to receive user input through the touchscreen; A medical device system comprising: (Item 22) 1. A method for establishing secure communications, said method comprising: Establishing a communication link between the medical sensor and the UI device; calculating a prime number (p) and a base number (g) between the medical sensor and the UI device using the communication link, the base number being a primitive root modulo the prime number; generating, by the UI device, a first random number (a) and a first value (u) derived by determining the base and raising it to the first random number (a), thereby defining a first exponent portion, and multiplying the first exponent portion modulo the prime number (p); communicating the first random number (a) and the first value (u) to the medical sensor from the UI device to the medical sensor; generating, by the medical sensor, a second random number (b) and a second value (v) derived by determining the base and raising it to the second random number, thereby defining a second exponent portion, and multiplying the second exponent portion by the modulus of the prime number; communicating the second random number (b) and the second value (v) from the medical sensor to the UI device; calculating, by the UI device, a shared key by determining a second value raised to the first random number, which is also a base raised to the second random number (both raised to the first random number and applied modulo the prime number); calculating, by the medical device, a shared key by determining a first value raised to the power of the second random number, which is also a 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); communicating between the medical sensor and the UI device using an encryption key based on the shared key; A method comprising: (Item 23) 37. The method of any one or more of items 22-36, wherein the calculating operation is performed using the communication link between the medical sensor and the UI device using public-private key cryptography. (Item 24) 37. The method of any one or more of items 22-36, wherein the act 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 having a symmetric key of the symmetric key, and the UI device having a second symmetric key of the symmetric key, the symmetric key being configured to provide encrypted communication between the medical sensor and the UI device. (Item 25) 37. The method of 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 a public key of the medical device prior to transmitting the first random number and the first value to the medical sensor. (Item 26) 37. The method of any one or more of items 22-36, wherein the medical sensor uses a private key to decrypt the first random number and the first value, both of which correspond to the public key. (Item 27) 37. 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 a second public key of the UI device prior to transmitting the second random number and the second value to the UI. (Item 28) 37. The method of any one or more of items 22-36, wherein the UI device decrypts the second random number and the second value, both corresponding to the UI device, using a secret key. (Item 29) 37. The method of any one or more of items 22-36, wherein the medical device and the UI device communicate at least one patient physiological data. (Item 30) 37. The method of any one or more of items 22-36, wherein the medical device is used as feedback for the UI device. (Item 31) The method of any one or more of items 22-36, wherein the first communication link may be an out-of-band pairing channel. (Item 32) 37. The method of any one or more of items 22-36, wherein the out-of-band pairing channel is at least one of a USB connection, an Ethernet connection, a zigbee connection, an Xbee connection, an ANT connection, a lightning connection, a SCSI connection, a serial port connection, a parallel port connection, an infrared connection, and a wireless USB connection. (Item 33) 37. The method of any one or more of items 22-36, wherein the encrypted communication uses a Bluetooth low energy communication link that is separate from the first communication link. (Item 34) 37. The method of any one or more of items 22-36, wherein the UI device and the medical device communicate using AES encryption using the key as an AES-key. (Item 35) 37. The method of any one or more of items 22-36, wherein 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 to seed the AES key. (Item 36) 37. The method of any one or more of items 22-36, wherein at least one fuse coupled to one or more data lines in the medical device is blown to prevent modification of the key. (Item 37) 1. A reliably communicable medical system, the system comprising: a medical sensor configured to establish a communication link for communicating over the communication link; a UI device configured to establish a communication link for communicating over said communication link; Equipped with the medical sensor and the UI device are configured to calculate an agreed upon prime number and base number using the communication link, the base number being 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 first random number, thereby defining a first exponent portion, and multiplying the first exponent portion by a modulus of the prime number; and 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 second random number, thereby defining a second exponent portion, and multiplying the second exponent portion by a modulus of the prime number; and the medical sensor is configured to communicate the second random number and the second value to the UI device 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 determining the second value raised to the first random number, which is also a base raised to the second random number (both raised to the first random number and applied modulo the prime number); the medical device is configured to calculate the shared key by determining the first value raised to the power of the second random number, which is also a base raised to the power of the first random number, both multiplied by the second random number and applied modulo the prime number; The system, wherein 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) Item 38. The system of 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) 52. The system of any one or more of items 37-51, wherein the medical sensor and the UI device are configured to use symmetric keys, the medical sensor having a symmetric key for the symmetric key, and the UI device having a second symmetric key for the symmetric key, and the symmetric key is configured to provide encrypted communication between the medical sensor and the UI device. (Item 40) 52. The system of 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 a public key of the medical device prior to transmitting the first random number and the first value to the medical sensor. (Item 41) 52. The system of any one or more of items 37-51, wherein the medical sensor is configured to decrypt the first random number and the first value, both of which correspond to the public key, using a private key. (Item 42) 52. The system of 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 a 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 of any one or more of items 37-51, wherein the UI device is configured to decrypt the second random number and the second value, both corresponding to the UI device, using a secret key. (Item 44) The system of any one or more of items 37-51, wherein the medical device and the UI device are configured to communicate at least one patient physiological data between each other using an encryption key generated using the shared key. (Item 45) 52. The system of any one or more of items 37-51, wherein the medical device is configured to be used as feedback for the UI device. (Item 46) The system of any one or more of items 37-51, wherein the first communication link is an out-of-band pairing channel. (Item 47) The system of any one or more of items 37-51, wherein the out-of-band pairing channel is at least one of a USB connection, an Ethernet connection, a zigbee connection, an Xbee connection, an ANT connection, a lightning connection, a SCSI connection, a serial port connection, a parallel port connection, an infrared connection, and a wireless USB connection. (Item 48) The system of any one or more of items 37-51, wherein the encrypted communication uses a Bluetooth® low energy communication link that is separate from the first communication link. (Item 49) 52. The system of any one or more of items 37-51, wherein the UI device and the medical device are configured to communicate using AES encryption using the key as an AES-key. (Item 50) 52. The system of any one or more of items 37-51, wherein 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 to seed the AES key. (Item 51) 52. The system of 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 to prevent modification of the key.

[0025] These and other features and advantages of the present invention will be better understood by reading the following detailed description taken in conjunction with the drawings. [Brief explanation of the drawings]

[0026] [Figure 1A] FIG. 1A is an exploded view of an embodiment of an infusion pump. [Figure 1B] FIG. 1B is an exploded view of an embodiment of an infusion pump. [Figure 2] FIG. 2 is an exploded view of an embodiment of the infusion pump and second reusable portion. [Figure 3] FIG. 3 is a perspective view of one embodiment of the infusion pump disposable portion showing the external infusion set. [Figure 4] 4A and 4B depict one embodiment of an infusion pump. [Figure 5A] 5A-5C depict one embodiment of an infusion pump. [Figure 5B] 5A-5C depict one embodiment of an infusion pump. [Figure 5C] 5A-5C depict one embodiment of an infusion pump. [Figure 5D] FIG. 5D is an exploded view of an embodiment of the reusable portion. [Figure 5E] FIG. 5E is an exploded view of an embodiment of the reusable portion. [Figure 5F] FIG. 5F is an exploded view of an embodiment of the reusable portion. [Figure 5G] Not specified [Figure 5H] Not specified [Figure 5I] Not specified [Figure 6] FIG. 6 is a diagram of an embodiment of a remote interface. [Figure 7A] FIG. 7 is a diagram of an embodiment of a remote interface. [Figure 7B] FIG. 7 is a diagram of an embodiment of a remote interface. [Figure 8] FIG. 8 is a diagram of an embodiment of the system. [Figure 8B] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8C] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8D] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8E] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8F] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8G] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8H] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8I] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8J] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8K] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8L] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8M] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8N] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8O] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8P] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8Q] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8R] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 9A]FIG. 9A diagrammatically depicts one embodiment of a multi-processor control configuration that may be included within one embodiment of the present device. [Figure 9B] FIG. 9B diagrammatically depicts an embodiment of a multi-processor control configuration that may be included within an embodiment of the present device in some embodiments. [Figure 10A] 10A and 10B diagrammatically depict one embodiment of multi-processor functionality. [Figure 10B] 10A and 10B diagrammatically depict one embodiment of multi-processor functionality. [Figure 11] FIG. 11 diagrammatically depicts one embodiment of multi-processor functionality. [Figure 12] FIG. 12 diagrammatically depicts one embodiment of multi-processor functionality. [Figure 12A] 12A-12E diagrammatically depict various software layers according to one embodiment. [Figure 12B] 12A-12E diagrammatically depict various software layers according to one embodiment. [Figure 12C] 12A-12E diagrammatically depict various software layers according to one embodiment. [Figure 12D] 12A-12E diagrammatically depict various software layers according to one embodiment. [Figure 12E] 12A-12E diagrammatically depict various software layers according to one embodiment. [Figure 13] FIG. 13 is an illustration of one embodiment of the system. [Figure 14] FIG. 14 is an illustration of one embodiment of the system. [Figure 15] 15A-15B are illustrations of one embodiment of a charging station in one embodiment of the system. [Figure 16A] 16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 16B]16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 16C] 16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 16D] 16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 16E] 16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 16F] 16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 17] FIG. 17 diagrammatically depicts one embodiment of the interconnection of the various elements of the system. [Figure 18] FIG. 18 is an illustration of one embodiment of the system. [Figure 19] FIG. 19 is an illustration of one embodiment of the system. [Figure 20A] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20B] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20C] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20D] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20E] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20F]20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20G] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20H] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20I] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20J] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20K] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20L] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20M] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20N] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20O] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20P] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20Q] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20R]20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20S] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 20T] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 21A] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 21B] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 21C] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 21D] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 22A] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 22B] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 22C] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 22D] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 23A] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 23B]20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 23C] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 23D] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 24A] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 24B] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 25A] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 25B] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 25C] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26A] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26B] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26C] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26D] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26E]20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26F] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26G] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26H] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26I] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26J] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26K] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26L] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26M] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 26N] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 27A] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 27B] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 27C]20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 27E] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 27F] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 27G] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 27H] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 27I] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 28A] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 28B] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 28C] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 28D] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 28E] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 28F] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 28G]20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 28H] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 28I] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 29A] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 29B] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 29C] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 29D] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 29E] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 29F] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 30] 20A-30 are various screenshots of an embodiment of a remote interface according to one embodiment of the system. [Figure 31] FIG. 31 is an embodiment of a 2D barcode. [Figure 32] FIG. 32 is an embodiment of a system for programming a basal profile using a remote interface and a 2D barcode. [Figure 33] FIG. 33 is an example of information that can be embedded within a 2D barcode. [Figure 34] FIG. 34 is an example of a basal profile that can be programmed into the remote interface using the camera. [Figure 35A] FIG. 35A is an illustration of one embodiment of the system. [Figure 35B] FIG. 35B is an illustration of one embodiment of this system. [Figure 35C] FIG. 35C is an illustration of one embodiment of this system. [Figure 35D] FIG. 35D is an illustration of one embodiment of this system. [Figure 35E] FIG. 35E is an illustration of one embodiment of this system. [Figure 36] FIG. 36 is an illustration of one embodiment of the system. [Figure 37] FIG. 37 is an illustration of one embodiment of the system. [Figure 38] FIG. 38 is an illustration of one embodiment of the system. [Figure 39] FIG. 39 is an illustration of one embodiment of the system. [Figure 40] FIG. 40 is a flow diagram of a method of the present system, according to one embodiment. [Figure 41] FIG. 41 is a flow diagram of a method of the present system, according to one embodiment. [Figure 42] FIG. 42 is a flow diagram of a method of the present system, according to one embodiment. [Figure 43A] 43A-43O are an embodiment of various screenshots of a miniature remote interface according to one embodiment of the present system. [Figure 43B] 43A-43O are an embodiment of various screenshots of a miniature remote interface according to one embodiment of the present system. [Figure 43C] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43D]43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43E] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43F] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43G] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43H] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43I] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43J] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43K] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43L] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43M] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43N] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 43O] 43A-43O are an embodiment of various screenshots of a small remote interface according to one embodiment of the present system. [Figure 44A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 44B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 45A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 45B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 45C] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 45D] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 45E] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 46A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 46B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 47A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 47B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 47C] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 48A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 48B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 48C] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 48D] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 49A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 49B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 50A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 50B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 51A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 51B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 52A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 52B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 52C] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 52D] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 53] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 54A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 54B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 54C] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 54D] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 55] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 56A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 56B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 56C] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 57A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 57B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 57C] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58A] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58B] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58C] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58D] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58E] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58F] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58G] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58H] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58I] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58J] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58K] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58L] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58M] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58N] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58O] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58P] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58Q] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58R] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58S] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. [Figure 58T] 44A-58T are various screenshots of an embodiment of a remote interface according to one embodiment of the present system. DETAILED DESCRIPTION OF THE INVENTION

[0027] DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS definition As used in this description and the accompanying claims, the following terms shall have the meanings indicated below, unless the context otherwise requires.

[0028] "Remote interface" shall mean a device for wireless communication with devices, which may include, but are not limited to, medical devices.

[0029] "Device" includes, but is not limited to, medical devices (including, but not limited to, infusion pumps and / or micro-infusion pumps, drug delivery pumps and / or devices, sensors, measurement devices and / or meters, blood pressure monitors, ECG monitors, pill dispensers, pulse oximetry monitors, CO 2 "medical device" shall mean any medical device, including capnometers, infusion bags, drip flow 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 device or devices configured to deliver, handle, and / or determine medical care.

[0030] An "input" of a device includes any mechanism by which a user of the device and / or remote interface and / or other operator / caregiver may control the function of the device and / or remote interface. User inputs may include mechanical arrangements (e.g., switches, push buttons, jog wheels), electrical arrangements (e.g., sliders, touch screens), 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 / lightwave images (including, but not limited to, camera inputs and / or images captured using a camera), sonic, and / or other types of interfaces.

[0031] A "button" in the context of inputs such as the so-called "bolus button" discussed below may be any type of user input capable of performing the desired function, including but not limited to push buttons, sliders, switches, touch screens, and / or jog wheels.

[0032] An "alarm" includes any mechanism by which a warning may be generated to a user and / or a third party / operator / caregiver. Alarms may include audio alarms (e.g., speaker, buzzer, sound generator), visual alarms (e.g., LED, LCD screen, image), tactile alarms (e.g., vibrating element), wireless signals (e.g., wireless transmission to a remote interface or caregiver), and / or other mechanisms. Alarms may be generated using multiple mechanisms simultaneously, in parallel, or as a sequence, including redundant mechanisms (e.g., two different audio alarms) or complementary mechanisms (e.g., audio, tactile, and wireless alarms), and / or mechanisms of increasing volume and / or intensity (e.g., an escalating alarm sequence).

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

[0034] "User" includes a person or animal receiving treatment from or connected to a device, whether as part of a medical treatment or otherwise, and / or a caregiver or third party, which may include, without limitation, a physician and / or healthcare provider and / or companion and / or parent and / or guardian, who is involved in programming the device or otherwise interacting with the device, administering treatment, and / or collecting information from the device.

[0035] "Cannula" is intended to mean a disposable device that can inject fluids into a user. Cannula, as used herein, may refer to a conventional cannula / flexible tube or a needle.

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

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

[0038] "Acoustic volume measurement" shall mean quantitative measurement of relative 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 Ser. No. 11 / 704,899, entitled "Fluid Delivery Systems and Methods," filed February 9, 2007 (now U.S. Patent Publication No. US-2007-0228071-A1), published October 4, 2007 (Attorney Docket No. E70), and U.S. patent application Ser. No. 12 / 347,985, entitled "Infusion Pump Assembly," filed December 31, 2008 (now U.S. Patent Publication No. US-2009-0299277), published December 3, 2009 (Attorney Docket No. G75), each of which is incorporated herein by reference in its entirety, as well as other techniques.

[0039] An exemplary use of various embodiments of the devices, methods, and systems described herein is for the delivery of insulin to people with diabetes, although other uses include the delivery of any fluid, the sensing of any disease state and / or condition, and / or the provision of medical treatment and / or 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. Therapeutic active molecules may be modified to improve device stability (e.g., by pegylation of peptides or proteins). While the illustrative embodiments herein describe drug delivery applications, the embodiments may be used in other applications, including lab-on-a-chip applications and the liquid dispensing of reagents for high-throughput analytical measurements such as capillary chromatography. For purposes of the following description, the terms "therapeutic agent," "insulin," or "fluid" are used interchangeably; however, in other embodiments, any fluid such as those described above may be used. Accordingly, the devices, systems, methods, and descriptions thereof included herein are not limited to use in conjunction with therapeutic agents.

[0040] Some embodiments of the device are adapted for use by people with diabetes and / or their caregivers. Thus, in these embodiments, the devices, methods, and systems cooperate to deliver insulin that supplements or replaces the function of pancreatic islet beta cells in people with diabetes (referred to as users). Embodiments adapted for insulin delivery seek to replace the function of pancreatic islet beta cells by providing both a basal level of fluid delivery and a bolus level of fluid delivery. The basal and bolus levels and timing may be set by the user through a remote interface user interface or directly through a user interface on the device. Additionally, the 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), which, in exemplary embodiments, may be integral with or wirelessly communicate with the remote interface. In other embodiments, the remote interface may include one or more analyte monitoring devices, which may include, but are not limited to, a blood glucose meter / device that receives a blood sample and / or a device configured to receive a blood sample, e.g., a blood glucose strip. 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 infusion pump and / or on the remote interface. In still other embodiments, the bolus or basal may be programmed or managed through a user interface located either on the device (e.g., on the infusion pump and / or on the remote interface).

[0041] With regard to the names given to screens and screen types herein and suitable names given to various features throughout various embodiments, these terms may vary and are for descriptive purposes; the present description is not limited to these names.

[0042] The devices, systems, and methods described herein may be used to control an infusion pump. For purposes of this description, various embodiments of the user interface and 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 it communicates may be any medical device, i.e., not limited to an infusion pump. Additionally, when the description refers to an infusion pump "screen," this "screen" may also appear on the remote interface, or may appear on the remote interface instead of the infusion pump.

[0043] Infusion pumps contemplated by the present description include pumps that can pump any fluid, including, but not limited to, therapeutic fluids (including, but not limited to, insulin). Thus, when the present description describes embodiments with respect to insulin, this is meant solely for illustrative purposes and is not intended to be limited to insulin. Other fluids are also contemplated. 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 devices described herein may be used for any one or more devices, and in some embodiments, the devices may include an infusion pump and / or an infusion pump system that may deliver fluid and / or may be configured to deliver fluid to a user through a cannula. For illustrative purposes only, an infusion pump system that may include at least one insulin pump is described herein. However, the systems are 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] 1A and 1B, one embodiment of device 100 is shown. Device 100 is an infusion pump, which in the illustrative embodiment may be any infusion pump, however, in some embodiments may be one of the infusion pump embodiments shown and described in U.S. Publication No. US-2007-0228071 (E70), published October 4, 2007, or U.S. Publication No. US-2009-0299277-A1 (Attorney Docket 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 a system.

[0046] Device 100 includes a reusable portion 102 and a disposable portion 104. In various embodiments, disposable portion 104 includes the reservoir and fluid lines, i.e., the "wet" components of the infusion pump. In some embodiments, disposable portion 104 includes tab 116.

[0047] The reusable part 102 includes mechanical and electrical components 108 configured to pump fluid in the reservoir from the reservoir to tubing 106, which may be connected to a cannula (not shown, but shown as 308 in FIG. 3 ). In some embodiments, the reusable part 102 may include a locking ring assembly 110 and a positioning protrusion 808 that may facilitate rotation of the locking ring assembly 110. The reusable part 102 may be removably engaged to the disposable part 104, which may be provided by, for example, but not limited to, a threaded, twist-lock, or compression fit configuration, or other configuration. In some embodiments, the reusable part 104 may be appropriately positioned relative to the disposable part 102, and the locking ring assembly 110 may be rotated to removably engage the reusable part 104 to the disposable part 102.

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

[0049] Referring now also to FIG. 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 portions 200, 202 and at least one disposable portion 204. The reusable portions 200, 202 and the disposable portion 204 may, in some embodiments, be embodiments of the device 100 described above. In some embodiments of the system, the system may include two reusable portions 200, 202, each of which may include a rechargeable power device, e.g., a rechargeable battery. Thus, in some embodiments, one reusable portion 200 is connected to the disposable portion 204 and is used by a user, while the other reusable portion 202 may be recharged. Thus, in some embodiments, the system may include a backup device that may be recharged or serviced while the other device is in use.

[0050] 3 , in some embodiments, the disposable portion 300 includes tubing 302, which may include a male connector 304 connected to the tubing 302. The male connector 304, in some embodiments, is configured to connect to a female connector 306. The envisioned connection of the male connector 304 and the female connector 306 provides a fluid path 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, the male connector 304, the female connector 306, the cannula 308, and the cannula adhesive pad 310 may collectively be referred to as an infusion 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 underside of the disposable portion 300, where the adhesive is exposed and can then be attached to the user) or a hook-and-loop patch. In embodiments where the disposable patch is a hook-and-loop patch (such as, for example, the hook-and-loop system offered by VELCRO USA Inc. (Manchester, NH)), the lower surface of the disposable portion 300 may include a complementary hook or loop surface.

[0051] 5A-5F, in some embodiments, reusable part 500 may include an input switch assembly configured to receive a user command (e.g., for bolus delivery, pairing with a remote interface or the like). The input switch assembly may include a button 824, which in some embodiments may be disposed within an opening 526 in body 520. As shown, for example, in FIG. 5B, locking ring assembly 506 may include a radial slot 528 that may be configured to allow locking ring assembly 506 to be rotated relative to body 520 while still providing easy access to button 524.

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

[0053] 5C, base plate 518 may provide access to electrical contacts 534, which may be electrically coupled to electrical control assembly 516, for example, for rechargeable battery 532. Base plate 518 may include one or more features (e.g., openings 536, 538) that may be configured to facilitate proper alignment with disposable housing assembly 504 via cooperating features (e.g., tabs) on disposable housing assembly 504. Additionally, base plate 518 may include various features for mounting valve assembly 514 and electrical control assembly 516, as well as for providing access to disposable portion 504 by valve assembly 514 (shown in FIGS. 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 may facilitate gripping and twisting of the locking ring assembly 506, for example, to engage / disengage the reusable part 500 and the disposable part 504. Additionally, the locking ring assembly 506 may include one or more sensing components, which in some embodiments may be a magnet 544, 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 part 500 (e.g., a Hall Effect sensor) and provide an indication, for example, of the nature of the mating components (which in some embodiments may include, but are not limited to, one or more of the disposable part 504, the charging station, or the filling station) and / or whether the reusable part 500 is properly engaged with the mating components. In some embodiments, the 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. Thus, in some embodiments, the Hall Effect sensor, in conjunction 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 portion component, i.e., in some embodiments, a Hall Effect sensor, to provide a determination of whether the reusable portion 500 is properly attached to its intended component or device. In some embodiments, the locking ring assembly 506 may not pivot when not attached to a component, which may include, but is not limited to, the disposable portion 504, a dust cover (not shown), or a battery charger (not shown). Thus, the sensing component 544, along with the reusable portion 500, may function to provide a number of advantageous safety features to the infusion pump system. These features may include, but are not limited to, one or more of the following: If the system does not detect attachment to the disposable portion 504, dust cover, or charger, the system may notify, warn, or alarm the user that the reusable portion 500, e.g., valve and pumping components, may be contaminated or damaged, compromising the integrity of the reusable assembly. Thus, the system may provide an integrity alarm to alert the user to a potential reusable integrity threat. Also, if the system senses that the reusable assembly is attached to the dust cover, the system may power off or reduce power to conserve power, which may provide more efficient use of power when the reusable parts are not connected to configurables that need to interact.

[0056] The reusable part 500 may attach to several different components, including, but not limited to, a disposable housing assembly, a dust cover, or a battery charger / charging station. In each case, a Hall effect sensor may detect that the locking ring assembly 506 is in the closed position, and thus the reusable part 500 is removably engaged with the disposable part 504, the dust cover, or the battery charger / charging station (or, in various embodiments, another component). The infusion pump system may determine the component attached thereto by using an AVS system, such as those described in the aforementioned referenced patent publications and patents, or by electronic contacts. Referring now also to FIGS. 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, and 547 such that the locking ring assembly 506 of the reusable part 500 can removably engage the dust cover 539. Additionally, the dust cover 539 may further include a recessed area 5849 to accommodate the valving and pumping features of the reusable part 500. For example, with respect to the dust cover, the AVS system may determine that the dust cover is connected to the reusable part, rather than the disposable part. The AVS system may use a lookup table or other comparison data to compare the measurement data with the characteristic dust cover or the empty disposable part to distinguish. With respect to the battery charger, the battery charger may, in some embodiments, include electrical contacts. When the reusable part is attached to the battery charger, the infusion pump assembly electronics system may sense that contact has been made, thus indicating that the reusable part is attached to the battery charger.

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

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

[0059] In some embodiments, the device includes hardware for wireless radio frequency ("RF") communication with a remote interface, which in some embodiments may be an infusion pump such as those described above. However, in various embodiments, the device may be any device and is not limited to an infusion pump. In some exemplary embodiments of the system, the device may include a display assembly, which may include one or more of at least one screen or other display, including a visual display to the user. However, in other embodiments, such as those shown in FIGS. 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 include a remote interface that also includes a display. Some embodiments of the remote interface are shown in FIGS. 6, 7, 7A, and 8.

[0060] 1A-5I, as well as other devices that may be used in conjunction with the infusion pump system, the device may include processing logic (not shown), which may be referred to as one or more processors, that execute 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] Where the system requires interaction between the user and the device, the interaction may be achieved using an input either on the remote interface or on the device; for example, in some embodiments, where the device is an infusion pump, the input on the device may be a switch assembly on the infusion pump.

[0062] The processing logic, in some embodiments, is used to receive input from a user. The user may use one or more input devices or assemblies, including, but not limited to, a button / switch assembly, a slider assembly, a capacitive slider (e.g., which may include, but is not limited to, any of the sliders described in U.S. Patent Application Serial No. 11 / 999,268, filed December 4, 2007, entitled "Medical Device Including a Slider Assembly," now U.S. Patent Publication No. US-2008-0177900, published July 24, 2008 (Attorney Docket No. F14) (incorporated herein by reference in its entirety)), a jog wheel, audio input, tactile input, and / or a touch screen. In some embodiments, the device may additionally receive input from an internal system. These internal systems may include, for example, in embodiments where the device is an infusion pump, one or more of, but are not limited to, an occlusion detection process, a confirmation process, and a volume measurement technique, such as acoustic volume sensing ("AVS"). Using these inputs, the device, which in some embodiments may be an infusion pump, may generate outputs, including, for example, but not limited to, infusion fluid delivery to a user, and / or these inputs may generate outputs, which may include, but are not limited to, one or more of a comment, a warning, an alarm, or an alert to the user. Inputs may thus be made either directly from a user to the device, directly from the device system to the processing logic, or from another device or remote interface to the device.The user interaction experience thus includes, but is not limited to, one or more of: interaction with a display (either on the device itself or a remote interface or both), including, but not limited to, reading / viewing text and / or graphics on the display, direct interaction with the display, e.g., through a touchscreen, interaction with one or more buttons, sliders, jog wheels, or other inputs, interaction with one or more glucose strip readers, and sensing either tactilely or audibly, one or more vibration motors, and / or an audio system. The term "user interface" is therefore used to encompass all of the systems, methods, and devices used by a user to interact with, control, and / or receive information from a device.

[0063] 6 and 7A-7B, in some embodiments of an infusion pump system, the infusion 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 wireless and / or remote communication. The remote interfaces 600, 700 may include all or a portion of the functionality of a device, which in some embodiments may include an infusion pump similar to those shown and described herein with respect to FIGS. 1A-5I. As discussed above, for purposes of explanation, the device may be described as an infusion pump; however, the present disclosure is not limited to infusion pumps. Additionally, the systems, methods, and apparatus described herein may be used in conjunction with any device.

[0064] In some embodiments of the aforementioned infusion pumps, the infusion pump may be configured using a remote interface 600, 700. In these embodiments, the infusion pump may include telemetry circuitry (not shown) that allows communication (e.g., wired or wireless) between the infusion pump and the remote interface 600, 700, thus allowing the remote interface 600, 700 to remotely control the infusion pump. The remote interface 600, 700 (which may also include telemetry circuitry (not shown) and be capable of communicating with the infusion pump) may include a display assembly 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 of the switch assemblies 604, 608, 704. 6, although some embodiments may include only one of either 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 the like, which may be coupled to a rotary encoder or other rotary transducer to provide a control signal based, at least in part, on movement of the wheel, ring, knob, or the like.

[0065] In some embodiments, the remote interface may include a touchscreen, and in such embodiments, as depicted in FIGS. 7A and 7B , the touchscreen may include one or more icons 706, 710 that indicate functionality of the remote interface 700. In some embodiments, the one or more icons 706, 710 may be associated with launching applications configured to communicate with devices. As shown in FIG. 7A , in some embodiments, the 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 or more icons 706 may be included on the remote interface 700. Also, as shown in FIG. 7A , in some embodiments, the remote interface 700 may include an icon 710 associated with a launching application associated with another functionality of the remote interface 700 (in addition to communicating with at least one device). In some embodiments, these may include, but are not limited to, launching a web browser, launching a cell phone or cell phone functionality, and / or launching an MP3 or other “audio” player functionality. In some embodiments, it may be desirable for a user to "launch" various features and / or applications of remote interface 700. In some embodiments, non-device-related functionality may be dormant and / or "sleep" until it is launched. This may be desirable for a number of reasons, including, but not limited to, extending battery life and / or preventing disruptions and / or slowing down operation with respect to using remote interface 700 to communicate with one or more devices. In some embodiments, applications may be launched automatically when a device is paired with remote interface 700 (as described in more detail below).In some embodiments, an icon 706 for a device on the remote interface 700 may indicate that the application is active, although the application is "minimized" on the display 702. Thus, in some embodiments, launching an 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 FIG. 7B , in some embodiments, the remote interface 700 may include various buttons on the display assembly that are links to adding notes and / or tags to a logbook. Thus, 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 basal rates, bolus alarms, delivery limits, user profiles, etc., and may allow the user to view history, logbooks, etc., establish user preferences, etc. In some embodiments, the remote interface may also include a glucose strip reader. However, in various embodiments, if the remote interface communicates with other devices rather than an infusion pump, the capabilities of the remote interface may differ.

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

[0068] In various embodiments of the user interface, the user interface may request user confirmation and / or user input. In some embodiments, the user interface focuses on ensuring that the effects of various interactions with the device are understood. Many examples will be presented throughout this description of devices that communicate the results of a user's actions to the user. These features ensure that the user understands their actions and therefore provide additional safety to the user. One such example is that if a user presses the back button on a screen after a value is changed, the user interface displays a "Cancel changes?" confirmation screen. 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 on which the user pressed the back button). When the action selection is "No" on the "Cancel 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 changes have been implemented when, in fact, they have not. Thus, this feature prevents such a situation and ensures that the user understands that changes have not been implemented. This is just one example of many user interfaces that require user confirmation and / or input.

[0069] Additionally, and referring also to FIG. 8 , in some embodiments of the device, the device 800 may be configured with a remote interface 802. In some embodiments, the device 800 may include telemetry circuitry (not shown) that enables communication (e.g., wired or wireless) between the device 800 and at least one remote interface 802, thus enabling the remote interface 802 to remotely communicate with the device 800. The remote interface 802 (which may also include telemetry circuitry (not shown) and be capable of communicating with the device 800) may, in various embodiments, include a display assembly 804 and at least one input assembly 806. The input assembly 806 may, in some embodiments, include at least one switch assembly, and in some embodiments, may include any of, without limitation, one or more of the aforementioned input assemblies. Thus, in some embodiments, the input assembly may include a jog wheel, multiple switch assemblies, a capacitive slider, or the like.

[0070] The remote interface 802 may include the ability to issue commands to 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 limits, e.g., delivery limits, and / or establish user preferences. In some embodiments, the remote interface 802 may allow a user to view the status of the device, which may include power status, delivery status, readings, alarm status, device progress, and / or any other data that may be communicated from the device to the remote interface 802. In some embodiments, the remote interface 802 may include a glucose strip reader and / or a temperature display device and / or other medical functionality that may be desired to perform therapy and / or diagnosis and / or provide 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 program / configure the device 800 using the remote interface 802. Some or all of the communications 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 utilizing a standard communication protocol. Furthermore, communication between various components contained within the device 800 may be achieved using the same protocol. One 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 infusion pump, may include an electrical control assembly 516, which may include one or more electrical components. For example, the electrical control assembly 516 may include multiple data processors (e.g., a supervisor processor and a command processor) and a wireless processor for enabling the device 800 to communicate with the remote interface 802. Thus, the remote interface 802 may include one or more electrical components, examples of which may include, but are not limited to, a command processor and a wireless processor for enabling the remote interface 802 to communicate with the device 800. A high-level diagram of one example of such a system is shown in FIG. 8B.

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

[0074] PCGP may be a flexible, extensible software module that may be used on 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 an adaptive interface to various drivers. For illustrative purposes only, PCGP may have the conceptual structure illustrated in FIG. 8C for a given processor.

[0075] PCGP may ensure data integrity by utilizing a cyclic redundancy check (CRC). PCGP may also provide guaranteed delivery status. As a non-limiting example, every new message should have a reply. If such a reply is not returned in time, the message may time out and PCGP may generate a negative acknowledgement 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 and may be coupled with rate control mechanisms at the driver level to provide a deterministic approach to message delivery without dropping packets, allowing individual nodes to have different amounts of buffers. When a node runs out of buffers, the driver may provide backpressure to other nodes, preventing them from sending new messages.

[0077] PCGP may use a shared buffer pool scheme to minimize data copies and avoid mutual exclusion, which may have a minor impact on the APIs used to send / receive messages to 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 subclassed from the bridge base class. In some embodiments, drivers may derive from the bridge class or communicate with or own a derived bridge class.

[0078] In some embodiments, PCGP may be designed to run in embedded environments, 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-limiting illustrative example of such an implementation is shown in FIG. 8D. PCGP may operate in the same way in both environments, but there may be versions of the calls for specific processor types (e.g., ARM9 / OS versions). 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, the ARM 9 Nucleus OS environment.

[0079] Referring also to FIG. 8E, the PCGP may: Allows multiple send / reply calls to occur have multiple drivers for RX and TX on different interfaces that operate asynchronously, and / or Provides packet ordering for sending / receiving and deterministic timeouts for sending messages

[0080] In some embodiments, each software object may ask the buffer manager for the next buffer it will use and then give that buffer to another object. Buffers may be passed automatically from one exclusive owner to another, and a queue may be generated automatically by ordering buffers by sequence number. In some embodiments, buffers may be recycled when they are no longer in use (e.g., an object may try 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; routing simply overwrites the buffer owner bytes.

[0081] Such an implementation of PCGP may provide a variety of benefits, examples of which may include, but are not limited to: · Once a message is in the buffer, it may not be possible to drop the message due to lack of buffer, as the message may remain there until it is forwarded or received by the application. Offsets are used to access the driver, PCGP, and payload sections of the buffer, so data does not have to be copied. A driver may swap ownership of message data by overwriting one byte (i.e., the buffer ownership byte). Mutual exclusion may only be needed when a single buffer owner may wish to use the buffer concurrently or obtain a new sequence number, so there may be no need for multiple exclusions except for reentrant calls. · There can be fewer rules for application writers to follow to implement reliable systems. · There is a set of calls provided to push / pull data from the driver out of the buffer management system, so drivers may use ISR / push / pull / and polled data models. The driver may not have to do any copying, CRC or any checking, but the destination byte and CRC and other checks can be done later from the ISR hotpath, so the driver may do very little other than TX and RX. · Queue ordering can occur automatically because the buffer manager can order accesses by sequence number. Small code / variable footprint may be utilized, i.e., hot path code may be small and overhead may be low.

[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 rules of the protocol and give the message to the driver / application.

[0083] To send a new message or send a reply, the PCGP may do one or more of the following: Check the calling arguments, for example to make sure the packet length is legal, the destination is correct, etc. Downlinks may allow PCGP to be used by the radio processor to establish links, pairs, etc., and may notify applications when PCGP is attempting to communicate over a link that is not functioning (instead of timing out), in some embodiments avoiding attempting to send messages over a link that is down unless it is a radio link node. Get a sequence number for a new message or use an existing sequence number for an existing message. Construct a packet, copy the payload data, write a CRC, and (from this point onwards) the integrity of the packet may be protected by the CRC; and / or Give a message to the buffer manager, either as a reply or a new message, and check whether putting this buffer in the buffer manager would exceed the maximum number of messages waiting to be sent.

[0084] Also, referring to Figures 8G-8H, in some embodiments, PCGP may run by doing all of the major work in one thread to avoid mutual exclusion and to avoid doing a lot of work on send / reply or driver calls. The "packetProcessor" call may need to apply protocol rules to replies, new sent messages, and received messages. Reply messages may simply be sent, but new and received messages may have rules for sending the messages. In each case, the software may loop while waiting for the correct type of message to apply the protocol rules until no more packets can be processed.

[0085] The sending of new messages may, in some embodiments, follow one or more of the following rules: Only two messages may be allowed "in flight" on the network; and / or Enough data about in-flight messages may be stored to match responses and handle timeouts.

[0086] Receiving a message may follow the following rules: A matching response may clear the "in-flight" information slot so a new packet can be sent. Non-matching responses may be dropped. The new message may be for a protocol (e.g., get / clear network statistics for this node). A buffer may be provided to the application to receive messages, or a callback may be used; and / or The buffer may be freed or remain owned by the application.

[0087] Thus, in some embodiments, PCGP may be configured as follows: The callback function may copy the payload data out or may use it entirely before returning. The callback function may copy any payload data it uses or do it entirely before returning. The callback function may own the buffer, reference the buffer and the buffer's payload by the payload address, and the message may be processed at a later time. The application may poll the PCGP system for received messages, and / or Applications may use callbacks to set events and then poll for incoming messages.

[0088] A communication system may have a limited number of buffers. If a PCGP runs out of buffers, the driver may stop receiving new packets and the application may be told that it cannot send new packets. To avoid this and maintain optimal performance, an application may attempt to take one or more steps, examples of which may include, but are not limited to, the following: a) Applications may keep PCGP up to date with radio conditions. Specifically, in some embodiments, if a link goes down and PCGP is unaware, PCGP may receive and queue new messages to send (or may not optimally time out messages), which may clog the send queue and delay applications from optimally using the link. b) The application may call "decrement timeout" periodically. Optimally, in some embodiments, the application may call "decrement timeout" every 20-100 milliseconds, unless the processor is sleeping. Generally, messages move fast (a few milliseconds), slow (a few seconds), or not at all. The timeout, in some embodiments, is an attempt to remove "in-flight" messages that should be dropped to free up buffers and bandwidth. Doing this infrequently may cause delays when new messages are sent or when the application queues new messages. c) Applications may ask PCGP if there is any pending work to do before going to sleep. Thus, in some embodiments, driver activity may wake up the system, and thus PCGP, if PCGP has no work to do, and thus PCGP does not require a call to "packetProcessor" or "decrement timeout" until a new packet enters the system. In some embodiments, failure to do this may cause a timeout condition to cause messages that would have been successfully sent / transmitted / received to be dropped. d) Applications should not hold on to received messages indefinitely. Message systems rely on quick replies. If applications share PCGP buffers, holding on to a message means holding on to the PCGP buffer. In some embodiments, the receiving node does not know whether the sending node has timeouts configured for slow or fast wireless communication. This means that the node should measure the network's fast timeout rate upon receiving a message. And / or e) Applications may call "packetProcessor" frequently. In some embodiments, the call may cause new messages queued by the application to be sent, or may handle the receipt of new messages. The call may also cause buffers to be reallocated, and infrequent calls may slow message traffic.

[0089] As shown in FIG. 8I, in some embodiments, at some point the RX driver may be asked 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 ask for a buffer pointer and may begin filling the buffer with the received data. Once the complete message is received, the RX driver may call a function to route the packet. The routing function may inspect 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 releasing the buffer.

[0090] The PCGP RX overhead may consist of asking for the next available buffer and calling the route function. A non-limiting example of code that performs such a function is as follows: [ka]

[0091] The driver may perform a TX by asking the buffer manager for a pointer to the next buffer to send. The TX driver may then ask the other side of the interface if it can accept the packet. If the other side rejects the packet, the TX driver may do nothing with the buffer since its state has not changed. Otherwise, the driver may send the packet and recycle / free the buffer. A non-limiting example of code that performs such a function is as follows: [ka]

[0092] To avoid transferring packets that exceed the maximum message system timeout period, some embodiments may call the BufferManager::first(uint8 owner) function, which may scan for buffers to free by asking for nextBuffer. Thus, a complete TX buffer with no chance of timing out may be freed on the thread that owns the buffer. In some embodiments, a bridge performing TX (i.e., searching for the next TX buffer) may free all TX buffers that 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 transferred to the driver to receive new packets or to PCGP to receive new payloads for TX. Allocation from "available" may be done by the "packetProcessor" function. The number of sends and receives 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 that handles addresses that are less than node addresses. GT_Driver may represent a driver that handles addresses that are more than node addresses.

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

[0095] After the router marks the buffer for TX, the driver may discover that the buffer is a TX and may send the message. After sending the message, if the driver is short of 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 acted upon. If the data is corrupted, a statistic 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 PCGP use or freed for reallocation by the buffer manager.

[0097] In some embodiments, when an application wants to send a new message, it may do so in a reentrant, transparent / mutually exclusive manner. When a buffer may be allocated, PCGP may mark the buffer as in use. Once marked in use, no other thread calling the send or reply function may grab this buffer because it is owned by the invocation of the function. The remainder of the process of performing error checking and creating the message may occur outside of the isolated race condition mutual exclusion protection code. The buffer may transition to a usable state, or it may become a valid filled, CRC-checked buffer and be passed to the router. In some embodiments, these buffers may not be sent immediately, but may be queued to allow the message to be sent later (assuming protocol rules allow). Reply messages may be marked differently from new send messages because they may be sent with a higher priority than normal send messages and there may be no rules limiting how many / when reply messages can be sent.

[0098] In some embodiments, PCGP may cooperate with flow control, which may negotiate the transfer of messages from one node to another so that buffers are never dropped due to a lack of buffers on the other side of the interface (which may cause backpressure on the sending node).

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

[0100] In some embodiments, when a packet is "in flight," it may be in the process of being sent by a driver en route to its destination, processed by a destination, or sent back as a response.

[0101] Typical delays are as follows: [Table 1]

[0102] Thus, in some embodiments, messages tend to complete the round trip quickly (eg, <50 ms), slowly (eg, 1 second or more), or not at all.

[0103] In various embodiments, PCGP may use two different times (set at initialization) for all timeouts: one for when the RF link is in fast heartbeat mode and one for when the RF link is in slow mode. However, in other embodiments, PCGP may use more or less than two different times. In some embodiments, when 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. Any additional transitions back and forth should not affect the expiration time for the message.

[0104] In some embodiments, there is a second timeout, which can be twice as long as the slow timeout, used to monitor buffer allocation within PCGP. Thus, if a message is "stranded" in the driver and not sent, for example due to flow control or hardware failure, the buffer may be freed by the buffer manager, causing it to be dropped. For a "new" message, this may mean that the packet has already timed out and a reply has already been given to the application that the message was not delivered, causing the buffer to be freed. Because the driver polls the buffer manager for buffers that need to be sent, the next time the blockage is removed, the buffer is freed so that a message that can be sent can be passed to the driver. For reply messages, the reply may simply be dropped or the sending node may time out.

[0105] In some embodiments, the PCGP messaging system may pass messages containing header information and a 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, inside PCGP there may be a consistent, driver-friendly byte layout. In some embodiments, a driver may insert bytes into or before a PCGP packet as follows: ·DE, CA: Synchronization bytes for use with RS232, nominal values ​​0xDE, 0xCA or 0x5A, 0xA5. · LD: Driver DMA length in bytes, equal to the amount the driver is pushing out in this DMA transfer, which is the total size not including the size byte or sync byte. · Cmd: Driver command and control byte used for flow control. LP: PCGP packet length, always 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 Tag is defined by the application and has no significance to PCGP. It allows the application to attach more information to the message, for example the thread from which the message originated. SeqNum: A 32-bit sequence number 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 of PCGP header and payload.

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

[0107] This methodology may have several advantages, examples of which may include, but are not limited to: In various embodiments, most hardware DMA engines may use the first byte to define how many additional bytes to move, so 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 "Cmd" bytes may be outside the CRC field, they may be modified by the driver and owned by the driver transport mechanism, and the driver may alert for invalid lengths. There may be a separate PGCP packet length byte that is CRC protected, so applications may trust that the payload length is correct. The endianness of the sequence number may be irrelevant, as it is just a byte pattern that can be matched, which also 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 sync byte so that the user may move the cable around while debugging the message stream and have both sides of the interface resynchronize. Applications, drivers, and PCGPs may share buffers and free them by pointer.

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

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

[0110] The following summarizes some exemplary events: [Table 2]

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

[0112] Below is an event-based pseudocode driver that illustrates how driver events work: The Driver subclasses Bridge, disables hasMessagesToSend and flowControlTumedOff, and schedules the TX and RX functions to be active if they are not already active. [ka] [ka]

[0113] Without limitation, 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 run-time configurable to facilitate testing and run-time fine-tuning of performance. Other parameters may be compile-time, e.g., anything that alters memory allocation that must be done statically at compile time, although other parameters may still be used in various embodiments.

[0115] The following may be definitions of a number of compile-time configurations that may vary where PCGP is implemented. Driver Bytes: Reserved for a common buffer scheme for drivers, may be 2 bytes, but in some embodiments this may be a compile time option to accommodate other drivers such as RF protocols. · Number of RX driver buffers: May be tuned to the number of buffers desired for that processor / traffic flow etc. · Number of PCGPRX buffers: May be tuned to the number of buffers desired for that processor / traffic flow etc. Total number of buffers: May be tuned to the number of buffers desired 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 be retried by the originator.

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

[0118] In some embodiments, the referenced method of interfacing PCGP to a Nucleus OS system on an ARM9 (as shown in FIG. 8O) may be used.

[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 may simplify the "C" code as the objects being acted upon are implicit.

[0120] In some embodiments, the following general rules may apply: PCGP may run on all nodes. Any driver may support the generic driver interface. Race conditions may not be tolerated. · Half-duplex may be supported on the SPI port between the slave and master processors. · It may succeed or return failure / false, so no data transfer may be attempted. · May require low overhead (wasted time, processing, bandwidth). May support CC2510 running at DMA (high speed) SPI clock ratio.

[0121] In some embodiments, SPI flow control may prevent data from being sent if the receiving side does not currently have an empty buffer in which to place the packet. In some embodiments, this may be accomplished by asking for permission to send and waiting for a response indicating that permission to do so has been granted. In some embodiments, another method may be used to indicate to the other side that there are currently no free buffers and that the transfer should be attempted later.

[0122] In some embodiments, all transmissions may begin with a length byte indicating the number of bytes being sent, not including the length byte itself. Following the length may be a single byte indicating the command being sent.

[0123] In some embodiments, the actual transmission of the packet may be the length of the packet plus one for the command byte, followed by the command byte for any attached messages, and finally the packet itself, however, in other embodiments the transmission of the packet may be different.

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

[0125] The following example 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 shown in Figure 8Q, when a slave processor has a packet to send to the master processor, the slave processor may notify the master processor (e.g., by asserting the flow control line) that there is a pending packet 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. Retrieval of the packet may be delayed at the discretion of the master processor, or the master processor may decide to attempt to send the packet to the slave processor before retrieving it from the slave processor.

[0127] In some embodiments, the master processor may initiate a withdrawal by sending the slave processor an M_CTS command, which in some embodiments is repeated 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 is sent. If an M_CTS command is received by the slave processor unexpectedly, the M_CTS command may be ignored.

[0128] As shown in FIG. 8R, in some embodiments, when a master processor has a packet to send to a slave processor, the master processor may initiate a transfer by sending an M_RTS command. Upon receiving the M_RTS command, in some embodiments, if the slave processor currently has a pending transmit packet, the slave processor lowers the FlowControl line so that it may be reused as a send authorization signal. The slave processor may then inform the master processor that it is in the process of preparing its SPIDMA to receive a packet, during which the master processor may stop timing bytes on the bus and allow the slave processor to finish preparing to receive.

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

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

[0131] 8, device 800 may include a switch assembly 810 coupled to electrical control assembly 510 (FIG. 5D), which may enable a user (not shown) to perform at least one task, and in some embodiments, multiple tasks. One illustrative example of such a task is administering a bolus dose of an infusible fluid (e.g., insulin) in embodiments where device 800 is an infusion pump or other drug delivery device and does not use a display assembly. Remote interface 802 may allow a user to enable / disable / configure device 800 to administer a bolus dose of insulin.

[0132] Display assembly 804 may be configured, at least in part, to allow a user to manipulate menu-based information rendered on display assembly 804. An example may be one in which display assembly 804 is a touchscreen. In some embodiments, touchscreen / display assembly 804 may be configured such that, for example, the rate at which a highlighted portion of a menu scrolls "up" or "down" varies depending on the displacement of a user's finger relative to an origin. Thus, in some embodiments, for example, if a user desires to rapidly scroll "up," the user may position their finger near the top of display assembly 804. Similarly, if a user desires to rapidly scroll "down," the user may position their finger near the bottom of display assembly 804. Additionally, if a user desires to scroll slowly "up," the user may position their finger slightly "up" relative to the origin. Additionally, if a user desires to scroll slowly "down," the user may position their finger slightly "down" relative to the origin. Once the appropriate menu item is highlighted, the user may select the highlighted menu item, for example, by either touching the screen a predefined number of times in any vicinity of the highlighted menu item and / or by using one or more switch assemblies 806, which in some embodiments may be included on the remote interface 802.

[0133] As discussed above, in one embodiment of the aforementioned infusion pump device, device 800 may be used to communicate with remote interface 802. When such a remote interface 802 is utilized, device 800 and 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" remote interface 802 to ensure that it is present and active. Furthermore, remote interface 802 may "ping" device 800 to ensure that it is still present and active. If one of device 800 and remote interface 802 cannot establish communication with the other, the one unable to establish communication (i.e., either device 800 or remote interface 802) may issue a "separation" alarm. For example, assume that remote interface 802 is left in the user's car while device 800 is in the user's pocket. Thus, after a defined period of time, device 800 may begin sounding a "separation" alarm, indicating an inability to establish communication with interface 802. In some embodiments, a user may acknowledge and / or silence the "separation" alarm by using switch assembly 810.

[0134] In various embodiments, a user may define and administer fluid delivery using switch assembly 810 of device 800 while remote interface 802 is not in communication with device 800, and device 800 may store information regarding 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) included within device 800. In response to communication established between device 800 and remote interface 802, device 800 may provide to remote interface 802 information regarding administered bolus insulin doses stored in the device 800's log file (not shown).

[0135] Additionally, in some embodiments, when a user anticipates separating remote interface 802 from device 800, the user may configure device 800 and remote interface 802 into "separate" mode, thus eliminating the generation of the aforementioned "separate" alarm. However, in some embodiments, 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 remote interface 802 may automatically be released from "separate" mode.

[0136] Further, in some embodiments, if a user anticipates traveling by airplane, the user may use remote interface 802 to configure device 800 and remote interface 802 into "airplane" mode, in which device 800 and remote interface 802 each suspend all data transmission. While in "airplane" 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, one or more of 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 infusible fluid.

[0138] 9A , as discussed above, in some embodiments, for example, to improve the safety of device 800, electrical control assembly 516 may include two separate and distinct microprocessors: supervisor processor 900 and command processor 902. Specifically, command processor 902 may perform functions such as, but not limited to, generating pump drive signals and may control, for example, a relay / switch assembly that controls the functionality of a shape-memory actuator. Command processor 902 may receive feedback from signal conditioner 908 regarding the state (e.g., voltage level) of a voltage signal applied to pump actuators 922, 924, which in some embodiments may be shape-memory actuators. Command processor 900 may control relay / switch assembly 910 independently of relay / switch assemblies 904, 906. Thus, for example, when an infusion event is desired, supervisor processor 900 and command processor 902 must both agree that an infusion event is appropriate (which may include whether the infusion event dose will not exceed any set limits of the system, whether inherent or user-selected / preprogrammed and / or planned), and both must activate their respective relays / switches. If either supervisor processor 900 or command processor 902 does not activate its respective relay / switch, the infusion event will not occur. Thus, through the use of supervisor processor 900 and command processor 902 and the cooperation and coincidence that must occur, the safety of device 800 is enhanced.

[0139] In some embodiments, supervisor processor 900 may prevent command processor 902 from delivering when inappropriate and / or may alarm if command processor 902 is not delivering when it should. Supervisor processor 900 may deactivate a relay / switch assembly, for example, if command processor 902 activates the wrong switch or if the command processor attempts to apply power for too long.

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

[0141] Supervisor processor 900 may redundantly keep profiles (e.g., delivery profiles and / or user preferences pre-programmed / pre-entered into the device) in RAM so that command processor 902 can make the correct calculations, but having bad RAM will cause commands to produce incorrect results. Therefore, supervisor processor 900 double-checks / verifies using a local copy of the profiles / user preferences, e.g., a base profile, etc.

[0142] Supervisor processor 900 may double-check one or more calculations, e.g., AVS measurements, performed by the device by reviewing the AVS calculations and applied safety checks. In some embodiments of the device, for example, supervisor processor 900 performs a double-check every time an AVS measurement is performed.

[0143] 9B, one or more of supervisor processor 900 and command processor 902 may perform diagnostics on various portions of infusion pump / device 800. For example, voltage dividers 912, 914 may be configured to monitor voltages (V1 and V2, respectively), such as those sensed at the distal end of shape-memory actuator 922. Knowing the signals applied to 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 FIG. 9B (in a manner similar to that shown in illustrative diagnostics table 916).

[0144] As discussed above and illustrated in FIGS. 9A-9B, to improve the safety of device 800, 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 effect an action (e.g., if device 800 effects the delivery of a drug, the action may be, for example, the delivery of a dose of infusible fluid). If microprocessors 900, 902 fail to interact / operate simultaneously, the delivery / action of the dose of infusible 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 utilized that tracks errors, e.g., volume error, over time, which may indicate that the volume of fluid delivered is less than or equal to what was requested. Thus, if the sum of errors becomes too large, a master alarm may be initiated, indicating that there may be an anomaly in the system. Thus, the master alarm may indicate the total volume comparison being made and the discrepancy found. A typical value of discrepancy required to initiate the master alarm may be 1.00 milliliters in an embodiment including the infusion pump described above. The master alarm may monitor the sum in a leak fashion (i.e., the inaccuracy has a time horizon).

[0146] 10A-10B, one such illustrative example of such interaction between multiple microprocessors during delivery of a dose of infusible fluid is shown. In this example, the interaction occurs during delivery of a dose of infusible fluid by an infusion pump. Specifically, command processor 902 may first determine 900 an initial volume of infusible fluid in the volume sensor chamber. Command processor 902 may then provide 1002 a "pump power request" message to supervisor processor 900. In response to receiving 1004 the "pump power request" message, supervisor processor 900 may, for example, activate relay / switch 910 1006 (thus activating shape memory actuator 922) and send 1008 a "pump power on" message to command processor 902. In response to receiving 1010 a "pump power on" message, the command processor 902 may, for example, activate 1012 the pump assembly (by energizing the relay / switch 904, thereby energizing the valve assembly 514), while the supervisor processor 900 may, for example, monitor 1014 the operation of the pump assembly.

[0147] Upon completion of pump assembly operation, command processor 902 may provide 1014 a “pump power off” message to supervisor processor 900. In response to receiving 1016 the “pump power off” message, supervisor processor 900 may de-energize 1018 relay / switch 910 and provide 1020 a “pump power off” message to command processor 902. In response to receiving 1022 the “pump power off” message, command processor 902 may measure 1024 the volume of infusible fluid pumped by the pump assembly (which in some embodiments may include valve assembly 514). This may be accomplished by measuring the current volume in the volume sensor chamber and comparing it to the volume determined above (in step 1000). Once determined 1024, command processor 902 may provide 1026 a “valve open power request” message to supervisor processor 900. In response to receiving 1028 the "valve open power request" message, supervisor processor 900 may energize 1030 relay / switch 910 (thus energizing shape memory actuator 924) and may send 1032 a "valve open power on" message to command processor 902. In response to receiving 1034 the "valve open power on" message, command processor 902 may, for example, actuate 1036 the measurement valve assembly (by energizing relay / switch 906), while supervisor processor 900 may, for example, monitor 1038 the actuation of the measurement valve assembly.

[0148] Upon completion of actuation of the measurement valve assembly, command processor 902 may provide 1040 a "valve power off" message to supervisor processor 900. In response to receiving 1042 the "valve power off" message, supervisor processor 900 may de-energize 1044 relay / switch 910 and provide 1046 a "valve power off" message to command processor 902.

[0149] In response to receiving 1048 the "valve power off" message, command processor 902 may provide 1050 a "valve close power request" message to supervisor processor 900. In response to receiving 1052 the "valve close power request" message, supervisor processor 900 may energize 1054 relay / switch 910 (thus energizing the shape-memory actuator) and may send 1056 a "power on" message to command processor 902. In response to receiving 1058 the "power on" message, command processor 902 may operate 1060 an excitation relay / switch (not shown) configured to energize the shape-memory actuator, while supervisor processor 900 may, for example, monitor 1062 the actuation of the shape-memory actuator.

[0150] In various embodiments, a shape memory actuator may be secured to a 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, the shape memory actuator may pull the bracket assembly forward and release the valve assembly. As such, the measurement valve assembly may be activated via the shape memory actuator. When the measurement valve assembly is activated, the bracket assembly may automatically latch the measurement valve assembly in the activated position. Activating the shape memory actuator may pull the bracket assembly forward and release the valve assembly. When the bracket assembly releases the measurement valve assembly, assuming the shape memory actuator is no longer activated, the measurement valve assembly may enter a deactivated state. Thus, activating the shape memory actuator may enter a deactivated state.

[0151] Upon completion of actuation of the shape memory actuator, command processor 902 may provide 1064 a "power off" message to supervisor processor 900. In response to receiving 1066 the "power off" message, supervisor processor 900 may de-energize 1068 relay / switch 910 and provide 1070 a "power off" message to command processor 902. In response to receiving 1072 the "power off" message, command processor 902 may determine 1074 the volume of infusible fluid in the volume sensor chamber, thus enabling command processor 902 to compare this measured volume with the volume determined above (in step 1024) to determine the volume of infusible fluid delivered to the user.

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

[0153] 11 , another illustrative example of the interaction between processors 900, 902 is shown, this time during the scheduling of a dose of infusible fluid. Command processor 902 may monitor 1100, 1102 for receipt of a basal scheduling message or a bolus request message (respectively). Upon receipt of either of these messages 1100, 1102, command processor 902 may set a desired delivery volume 1104 and may provide 1106 a “delivery request” message to supervisor processor 900. In response to receiving 1108 the “delivery request” message, supervisor processor 900 may verify 1110 the volume 1104 defined by command processor 902. Upon verification 1110, supervisor processor 900 may provide 1112 a “delivery accepted” message to command processor 902. In response to receiving 1114 a "delivery accepted" message, command processor 902 may update 1116 a remote interface (e.g., the remote interface discussed above and illustrated in FIGS. 6-8) and execute 1118 delivery of a basal / bolus dose of infusible fluid. Command processor 902 may monitor and update 1122 a total amount of infusible fluid delivered to the user (as discussed above and illustrated in FIGS. 10A-10B). Once the appropriate amount of infusible fluid has been delivered to the user, command processor 902 may provide 1124 a "delivery completed" message to supervisor processor 900. In response to receiving 1126 a "delivery completed" message, supervisor processor 900 may update 1128 the total amount of infusible fluid delivered to the user. If 1118 the total amount of infusible fluid delivered to the user is less than the amount defined above (in step 1104), the infusion process discussed above may be repeated (via loop 1130).

[0154] Referring also to FIG. 12, there is shown an example of how supervisor processor 900 and command processor 902 may interact while achieving volumetric measurements via a volume sensor assembly (as described above).

[0155] Specifically, command processor 902 may initialize 1250 the volume sensor assembly and begin collecting data from the volume sensor assembly 1252, a process that may be repeated for each frequency utilized in the sinusoidal sweep, as described, for example, in U.S. Publication No. US-2009-0299277-A1 (Attorney Docket No. G75), published December 3, 2009. Each time data is collected for a particular sweep frequency, a data point message may be provided 1254 from command processor 902, which may be received 1256 by supervisor processor 900.

[0156] Once data collection 1252 is complete for the entire sinusoidal sweep, command processor 902 may estimate 1258 the volume of infusible fluid delivered by the injection of device 800. Command processor 902 may provide 1260 a volume estimation message to supervisor processor 900. In response to receiving 1262 this volume estimation message, supervisor processor 900 may check (i.e., verify) 1264 the volume estimation message. Once checked (i.e., verified), supervisor processor 900 may provide 1266 a validation message to command processor 902. Once received 1268 from supervisor processor 900, command processor 902 may set a measurement state for the dose of infusible fluid delivered by the volume sensor assembly.

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

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

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

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

[0161] The OS may be a non-interrupt-type scheduling system in that all tasks, regardless of priority, run to completion before the next task can run. Additionally, no context switching may occur. When a task completes execution, the highest priority task currently scheduled for execution may run. If no tasks are scheduled for execution, the OS may place the processor (e.g., supervisor processor 900 and / or command processor 902) in a low-power sleep mode and may wake it when the next task is scheduled. The OS may be used only to manage main loop code, leaving interrupt-based functionality unaffected.

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

[0163] The base OS infrastructure may have the ability to track system time and control the ability to put the processor into low power mode (LPM, also known as hibernate 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 contain functionality to put a processor (e.g., supervisor processor 900 and / or command processor 902) into LPM to reduce energy consumption. While in LPM, a 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, placing the processor in LPM may always be done by the provided SysClocks. This function may contain all necessary power-down and power-up sequences that provide consistency whenever entering or leaving LPM. Wake-out from LPM may be initiated by any interrupt based on the slow clock.

[0166] The OS may track three aspects of time: seconds, milliseconds, and time of day. Regarding seconds, SysClocks may count seconds starting when the processor comes out of reset. The seconds counter may be based on a low-speed system clock and therefore may increment regardless of whether the processor is in LPM or full power. As a result, this is the boundary at which the processor wakes from sleep to execute a previously scheduled task. If a task is scheduled to run immediately after an interrupt service routine (ISR), the ISR may wake the processor from LPM upon completion, and the task may be executed immediately. Regarding milliseconds, in addition to counting seconds since power on, SysClocks may also count milliseconds while the processor is in full power mode. The millisecond counter may not increment because the high-speed clock is stopped during LPM. Therefore, the processor may not be in LPM whenever a task is scheduled to run based on milliseconds. With respect to time, the time may be represented within SysClocks as the number of seconds since a particular point in time (e.g., the number of seconds since 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 code base. Code delays may be necessary to allow hardware to stabilize or actions to complete. SysClocks may provide two forms of delay: a delay based on seconds, or a delay based on milliseconds. When a delay is used, the processor may simply wait until the desired time has elapsed before continuing the current code path. During this time, only the ISR may execute. SysClocks may provide all of the necessary functionality to set or retrieve the current time.

[0168] The term "task" may be associated with a more complex scheduling system, and therefore within the OS, tasks may be represented by and referred to as Managed Functions. The ManagedFunc class may be an abstract type base class that provides all of the controls and functionality necessary to manage and schedule the desired functionality.

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

[0170] In some embodiments, function IDs may be set at creation time and may never change. All function IDs may be defined in a single .h file, and the base ManagedFunc constructor may enforce that the same ID may not be used for more than one managed function. IDs may also define the priority of a function (relative to other functions) based on the assigned function ID, with higher priority functions being assigned lower function IDs. The highest priority task currently scheduled for execution 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 if (at runtime) the function should be rescheduled in a previously set amount of time. Manipulation of these controls and states may be possible, but only through well-known member functions (thus implementing safety controls in all settings).

[0172] Set start and set repeat functions may be used to control the scheduling of managed functions. Each of these member functions may be a simple interface that allows for the ability to configure or disable repeat settings, as well as control whether a managed function is scheduled by seconds, milliseconds, or time of day, or is inactive.

[0173] Through inheritance, creation of managed functions may be done by creating a derived class and defining a pure virtual "execute" function that contains the 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 starting and every 15 seconds thereafter, the desired code is placed in the virtual execute function, and a start time of 30 seconds, a function ID scheduled by seconds state, and a repeat setting of 15 seconds are provided to the constructor.

[0175] Below is an illustrative code example for 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 implemented by the SleepManager class. The SleepManager may contain the actual prioritized list of managed functions. This prioritized list of functions may be automatically populated by the managed function creation process, ensuring that each function is created properly and has a unique ID.

[0177] The primary role of the SleepManager class may be to have its "management" function called repeatedly from the processor's main loop and / or from a forever while loop. On each call to manage, SleepManager executes all functions scheduled to run until SleepManager exhausts all scheduled functions, at which point SleepManager may place the processor in LPM. When the processor wakes from LPM, the management function may be re-entered until the processor is ready to enter LPM again (this process may be repeated, for example, until stopped by the user or by the system).

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

[0179] The SleepManager may also provide an interface to manipulate the scheduling and iterate over the settings of any managed function through the use of the function's unique ID, 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] Radio circuitry contained within device 800 and remote interface 802 may provide wireless communication between remote interface 802 and device 800. In some embodiments, a 2.4 GHz wireless communication chip (e.g., a Texas Instruments CC2510 radio transceiver) with an internal 8051 micro remote interface may be used for wireless communication.

[0181] A wireless link may balance three objectives: link availability, latency, and energy.

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

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

[0184] Referring also to FIG. 12, one illustrative example of the various software layers of the wireless communication system discussed above is shown.

[0185] In some embodiments, the remote interface 802 and the radio processor included in the device 800 may transfer messaging packets between the SPI port and the 2.4 GHz radio link (or vice versa). In some embodiments, the radio may always be an SPI slave. On the device 800, the radio processor (PRP) 918 (see FIGS. 9A-9B) may, in some embodiments, service two additional nodes (the number of additional nodes may vary in various embodiments) that are 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 a continuous glucose monitor (CGM) and / or a blood glucose monitor (BGM) described above.

[0186] The messaging system may enable 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 configure and initiate part of mode switching on the two system radios. It may also be used by the radios to communicate radio and link status information to other nodes in the network.

[0187] In some embodiments, the radio of the remote interface 802 may use a system message when it wants to collect channel statistics from the device 800 or update the master channel list of the radio of the device 800. Synchronization for the new updated list to take effect may use a flag in the heartbeat message to remove timing uncertainty.

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

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

[0190] The Quiet_Radio signal may be used by the UI processor of the remote interface 802 to prevent noise interference on the remote interface 802 board by other systems on board. When Quiet_Radio is asserted, the radio application of the remote interface 802 may send a message to the radio of the device 800 to assert Radio Quiet mode for a predefined period of time. In some embodiments, the Quiet_Radio feature may not be needed based on noise interference levels measured on the PC board of the remote interface 802. During this period, the radio of the remote interface 802 may remain in Sleep Mode 2 for up to 100 ms. The radio of the remote interface 802 may exit Sleep Mode 2 when the Quiet_Radio signal is deasserted or the maximum period expires. The UI processor of the remote interface 802 may assert Quiet_Radio at least one radio communication interval before needing to assert the event. The radio of the remote interface 802 may notify the radio of the device 800 that communications will be shut down during this dormant period. The periodic radio link protocol may have a status bit / byte that accommodates the Quiet_Radio feature unless Quiet_Radio is required.

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

[0192] In some embodiments, the radio of remote interface 802 may be configured to consume only 32 mAh for 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 for three days (assuming 100 minutes of fast heartbeat mode communication per day). However, these configurations may vary throughout the embodiments and in some embodiments may be more or less than the stated examples.

[0193] The maximum time to reacquire communication includes connection request mode and acquisition mode; < The maximum time may be 6.1 seconds; however, in various other embodiments, the maximum time may be shorter or longer. In some embodiments, the radio of the remote interface 802 may advantageously use a fast heartbeat mode or a slow heartbeat mode setting to conserve power and minimize latency for the user. The difference between the device 800 and the remote interface 802 going into acquisition mode may be that the device 800 needs to go into acquisition mode frequently enough to ensure that communication can be restored within the maximum latency time. However, the remote interface 802 may vary the frequency of going into acquisition mode with the device 800 when it is in slow heartbeat mode and a heartbeat is lost. In some embodiments, the radio of the remote interface 802 may have knowledge of the user GUI interactions, while the 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 in each heartbeat from the radio of remote interface 802 to the radio of device 800. This may not exclusively establish the heartbeat rate for device 800, depending on other conditions that determine which mode is entered. When in fast heartbeat mode, the radio of remote interface 802 may set the heartbeat period to 20 ms if it is able to send or receive data packets, thus providing low-latency communication when data is being actively exchanged.

[0195] When in fast heartbeat mode, the radio of the remote interface 802 may set the heartbeat period to 60 ms, four heartbeats after the last time a data packet was exchanged bidirectionally over the air. Keeping the radio heartbeat period short after a data packet is sent or received ensures that any data response packets can also be provided using low link latency. When in slow heartbeat mode, the heartbeat rate may be 2.00 seconds or 6.00 seconds, depending on the online or offline state, respectively. However, in various embodiments, these values ​​may be different.

[0196] The device 800 may use a heartbeat rate set by the radio of the remote interface 802. The radio of the remote interface 802 may, in some embodiments, support the following mode requests via one or more messaging systems, including but not limited to: Pairing mode Connection Mode Acquisition mode (including the wireless serial number of the desired paired infusion pump assembly 100, 100', 400, 500) Synchronous mode - fast heartbeat Synchronous mode - slow heartbeat RF Off Mode The radio of infusion pump assembly 100, 100', 400, 500 may support the following mode requests via the messaging system: Pairing mode Acquisition mode RF Off Mode

[0197] In some embodiments, the radio may use a system message 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 a system message to store the paired radio serial number.

[0198] The remote interface 802 and the radio of the device 800 may, in some embodiments, use a messaging system to issue status messages to the UI processor of the remote interface 802 and the command processor 902 whenever one or more of the following conditions change, including but not limited to: Fast online: connection successful Fast Online: Change from Acquisition mode to Fast Heartbeat mode · Slow Online: Request to change from fast heartbeat to slow heartbeat successful Offline: Automatic change to search sync mode due to lack of heartbeat exchange · Fast Online: Successful request to change from slow heartbeat to fast heartbeat Offline: Bandwidth below 10% in synchronous mode Online: Bandwidth is greater than 10% in search synchronous mode Offline: Request to change to RF off mode successful

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

[0200] In some embodiments, there may be two parameters in the radio configuration message: the number of RF retries (e.g., the value may be 0 to 10) and a radio offline parameter (e.g., the value may be a percentage of bandwidth from 1 to 100). However, in various other embodiments, there may be more or less than two parameters.

[0201] The wireless application on 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, one or more of the following parameters may be recommended for radio hardware configuration, without limitation: Basic wireless specifications MSK Wireless communication ratio of 250 kbps or more Up to 84 channels 1000kHz channel spacing 812kHz filter bandwidth No Manchester encoding Data erasure 4-byte preamble 4-byte synchronization (word) CRC added to packets LQI (Link Quality Indicator) added to packets Automatic CRC filtering enabled

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

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

[0205] In some embodiments, AES encryption may be used for all packets, but may not be required, for example, in embodiments using a Texas Instruments CC2510 radio transceiver, as the transceiver includes this functionality. In embodiments in which AES encryption is used, a fixed key may be utilized, as this may be desirable for a number of reasons, including providing a fast method for enabling 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 with no other variables other than the fixed key data, thus allowing easier management of read access to the file.

[0206] In some embodiments, the radio software may support one or more of the following eight modes, without limitation: Pairing mode RF Off Mode Connection Mode Acquisition mode Fast heartbeat mode Slow Heartbeat Mode ·Search synchronous mode Synchronous acquisition mode All of this is depicted diagrammatically in Figures 12B-12C.

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

[0208] In some embodiments, pairing mode (one embodiment of which is depicted diagrammatically in FIG. 12D ) may require the following four messages to be exchanged over the RF link (however, various embodiments may require more, fewer, or no messages to be exchanged over the RF link): RF pairing request (broadcast from remote interface 802 to any device 800) RF pairing acknowledgement (device to remote interface 802) RF pairing confirmation request (remote interface 802 to device 800) RF Pairing Confirmation Acknowledgement (Device 800 to Remote Interface 802)

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

[0210] In some embodiments, the radio of device 800 may enter pairing mode in response to receiving a pairing mode request message. In some embodiments, if there is no disposable part attached to device 800 and the user presses switch assembly 810 of device 800 for a predefined amount of time, e.g., 6 seconds (which may vary throughout embodiments), indicating to the system that pairing mode is requested, it may be the responsibility of supervisor processor 900 on device 800 to request the radio to enter pairing mode. The radio of device 800 may set the appropriate transmit 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 remote interface 802 while the device is in pairing mode, which may trigger the pairing protocol, i.e., device 800 and remote interface 802 are identified as paired. In some embodiments, a camera located on remote interface 802 may be used to capture an image of a 2D barcode on device 800 and use this image and / or image identification to identify device 800. In some embodiments, device 800 may include an RFID transmitter, which may be used in an NFC protocol for recognition.

[0212] In some embodiments, while in pairing mode, in response to receiving the first valid RF pairing request message, the radio of device 800 may respond with an RF pairing acknowledgement message using the serial number of remote interface 802 and containing the radio serial number of device 800 for the duration of pairing mode.

[0213] In some embodiments, the radio of device 800 may automatically time out of pairing mode after a predefined amount of time, for example, 2.0±0.2 seconds, if an RF pairing request is not received. The radio of device 800 may automatically time out of pairing mode after, for example, 2.0±0.2 seconds, if an RF pairing request is not 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 acknowledgement. This message to supervisor processor 900 would enable feedback to the user during the pairing confirmation process. The radio of device 800 may automatically time out of pairing mode after transmitting an RF pairing acknowledgement, for example, 1.0±0.1 seconds, unless an RF pairing confirmation 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 store pairing radio serial number message if an RF pairing confirm request message is received after receiving the RF pairing request message. This action may store the radio serial number of remote interface 802 in non-volatile memory of device 800 and may overwrite existing pairing data in device 800.

[0214] The radio of device 800 may transmit an RF pairing confirmation acknowledgment and exit pairing mode after an acknowledgment from the stored pairing radio serial number message is received. In some embodiments, this may be the default exit from pairing mode on device 800, which may power down device 800 until placed into connected or pairing mode by the user.

[0215] In some embodiments, if the radio of device 800 exits pairing mode in response to successful receipt of a pairing confirmation request message, the radio of device 800 may return to the newly paired remote interface 802 and may send a pairing complete success message to command processor 902. In some embodiments, the radio of device 800 may exit pairing mode in response to receipt of an RF pairing abort message. The radio of device 800 may exit pairing mode in response to receipt of a pairing abort request message addressed to it. In some embodiments, this may allow command processor 902 or supervisor processor 900 to abort the pairing process locally on device 800.

[0216] In some embodiments, the radio of the remote interface 802 may enter pairing mode in response to receiving 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 the appropriate transmit power level for pairing mode. In some embodiments, the radio of the remote interface 802 may transmit RF pairing requests until an RF pairing acknowledgment is received or pairing is aborted.

[0217] In some embodiments, the radio of the remote interface 802 may automatically abort pairing mode if it does not receive an RF pairing acknowledgment message within a predefined time, e.g., 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 seconds. In some embodiments, upon receiving the first valid RF pairing acknowledgment message while in pairing mode, 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 the device 800, and may use that serial number for the duration of pairing mode. This message may provide a means for the UI processor of the remote interface 802 to prompt 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 (for a single pairing request) from the device 800, the first valid one may be used.

[0218] In some embodiments, the radio of the remote interface 802 may only accept an RF pairing confirm 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 confirm message in response to receiving a pairing confirm 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 the device 800 confirms pairing before adding the device 800 to the pairing list. In some embodiments, the radio of the remote interface 802 may issue a store paired radio serial number message if an RF pairing complete message is received. This action may enable the UI processor of the remote interface 802 to store the new serial number of the device 800 and provide user feedback of a successful pairing. Managing a list of paired infusion 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, and two or more devices may each be paired with the remote interface 802. However, in some embodiments, it may be desirable for only one of the paired devices to be used with the remote interface 802 at any given time. Thus, in these embodiments, once the initial pairing process is complete and the remote interface 802 includes a device on its list of paired devices, the user indicates on the remote interface 802 the device with which communication is desired for that duration (predefined amount of time) for use.

[0220] In some embodiments, the radio of the remote interface 802 may transmit an RF pairing abort request message and, in response to receiving the pairing abort request message, exit pairing mode, which may allow the UI processor of the remote interface 802 to abort 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 acquire each device 800 in its paired device list and attempt to restore its "ready to connect" state. The "connect" process, one embodiment of which is depicted diagrammatically in FIG. 12E, may, in some embodiments, allow the remote interface 802 to quickly identify one of its paired devices that may be ready for use. The radio of the remote interface 802 may be capable of connection request mode with multiple devices, for example, in some embodiments, up to six paired reusable parts of an infusion pump. Connection request mode may be supported only on the remote interface 802 and may be a specialized form of acquisition mode. In connection request mode, the remote interface 802 may connect and respond with the 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 obtain a list of serial numbers of the most recent paired devices when it enters connection mode. The radio of the remote interface 802 may enter connection mode in response to receiving 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 it desires to communicate with a paired device. The radio of the remote interface 802 may issue a connection assessment message to the UI processor of the remote interface 802, if applicable, containing the radio serial number of the first device that is “ready to connect.” The radio of the remote interface 802 may generate the connection assessment message within a predefined amount of time, e.g., 30 seconds, after entering connection request mode. However, the predefined amount of time may be less than or greater than 30 seconds in various embodiments. In some embodiments, the radio of the remote interface 802 may exit connection request mode and transition to fast heartbeat mode upon receiving a connection assessment acknowledgement. The radio of the remote interface 802 may exit connection request mode in response to receiving a connection request abort message from the UI processor of the remote interface 802.

[0223] Acquisition mode may be used on the remote interface 802 to find a particular 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 that the radio of the remote interface 802 will find a paired device.

[0224] The radio of the remote interface 802 may enter acquisition mode in response to receiving an acquisition mode request or a fast heartbeat mode request message while in RF off mode. The radio of the remote interface 802 may enter synchronized acquisition mode in response to receiving an acquisition mode request or a fast heartbeat mode request message while in search synchronization mode. 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 those in which the device is an infusion pump, the radio of the remote interface 802 may communicate (excluding pairing and connection modes) only with one paired infusion pump 800. In some embodiments, if communication is lost, the UI processor of the remote interface 802 may use acquisition mode (at some periodic 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, although in various other embodiments, additional conditions may trigger acquisition mode: When in wireless off mode and acquisition mode may be required When the search synchronization mode times out due to lack of heartbeat

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

[0228] In some embodiments, data packets may be transmitted between the pairing device 800 and the remote interface 802, for example, when the device 800 and the remote interface 802 are in synchronized 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 a heartbeat exchange. The device 800 may coordinate when to expect to receive 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 of the remote interface 802 may change to fast heartbeat mode if it is in slow heartbeat mode and a system request for fast heartbeat mode is received while the radio is online.

[0229] Upon transitioning from acquisition mode to fast heartbeat mode, the radio of the remote interface 802 may transmit a master channel list message. A master channel list may be constructed by the radio of the remote interface 802 and transmitted to the radio of the device 800 to enable frequency hopping channel selection based on past performance. When in fast heartbeat mode or slow heartbeat mode, periodic heartbeat messages may be exchanged between the radio of the remote interface 802 and the radio of the device 800. The periodicity of these messages may be at the heartbeat rate. The heartbeat messages may enable data packet transfers to occur and may also exchange status information. In some embodiments, the two radios may exchange status information such as dormant mode, data availability, buffer availability, heartbeat rate, and previous channel performance; however, in other embodiments, additional or less information may be exchanged. In some embodiments, keeping the packet size of the heartbeat messages small may be a goal to conserve power. In these embodiments, the radio may provide a maximum data packet size of 82 bytes when in synchronous mode. A messaging system may be designed to support, for example, a maximum packet payload size of 64 bytes. This maximum size may be selected as an optimal tradeoff between minimal message types and non-fragmented messages. In some embodiments, 82 bytes may be the maximum packet size for 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 allows the wireless protocol to send received wireless packets to it. The messaging system may also have an API that allows the wireless protocol to obtain packets for transmission over the wireless network. The messaging system may be responsible for packet routing between the wireless protocol and the SPI port. Data packets may be provided to the messaging system for processing. The messaging system may have an API that allows the wireless protocol to obtain a count of the number of data packets waiting to be transmitted over the wireless network. The wireless protocol may query the messaging system at each heartbeat to determine whether a data packet is available for transmission over the wireless network. It may be desirable for software to check message availability immediately before a heartbeat is transmitted to minimize round-trip message latency.

[0231] The wireless protocol may be capable of buffering one 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 receipt of the data packet. The messaging system may be responsible for sending the wireless data packet to the correct destination node. The wireless protocol may be capable of buffering one packet from the messaging system.

[0232] The radio protocol may involve acknowledging receipt of a valid data packet over 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, an RF ACK command identification, and the sequence number of the data packet being acknowledged.

[0233] In some embodiments, a radio transmitting a wireless data packet may retransmit that wireless data packet on the next heartbeat with the same sequence number if an RF ACK is not received and the retry count is within the maximum allowed RF retries. If interference prevents transmission on a particular frequency, in some embodiments, RF retries allow the same packet to be retransmitted at the next opportunity on a different frequency. The sequence number provides a means to uniquely identify a packet over a short time window. The number of wireless packet retries may be configurable using a radio configuration command. Allowing more retries may increase the probability of a packet being exchanged, but introduces additional latency for round-trip messages. The default number of wireless retries when powering up may be 10 (i.e., the maximum transmission attempts 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 all wireless data packets on the RF link. The sequence number may provide a way for two radios to know if a data packet is a duplicate, since the radios may engage in retrying the data packet transmission if not acknowledged. The transmitted sequence number may be incremented for each new wireless data packet and may be allowed to roll over. Upon successful reception of a data packet with the same sequence number (and in the same direction) as a previously successfully received data packet, the data packet may be acknowledged and the received data packet may be discarded. This may remove duplicate packets generated by the RF protocol before being introduced into the network. Note that under extreme circumstances, situations 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 remote interface 802 and the radio of device 800 may attempt to transmit and listen for subsequent heartbeats, respectively. The radio of remote interface 802 and the radio of device 800 may automatically change from fast heartbeat mode or slow heartbeat mode to search synchronization mode if a heartbeat is missed for two seconds. This may minimize power consumption when a link is lost by allowing the radios to continue using synchronization information, as two seconds allows enough time to cycle through all channels.

[0236] In some embodiments, a radio may be considered online when it is in the following modes: Fast 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 radio may be initialized to radio off mode at the start of code execution from reset. When code first runs on the radio processor, the initial state may be radio off mode to allow other processors to perform self-tests before requiring the radio to become operational. This requirement is not intended to define the mode when waking from hibernation mode. The radio may cease RF communications when set to radio off mode. On remote interface 802, this mode may be intended for use on an aircraft, i.e., in airplane mode, to suppress RF emissions. Radio off mode may only be used on device 800 when charging, since device 800 only responds to transmissions from remote interface 802 (which ceases transmissions in airplane mode).

[0239] In some embodiments, the command processor 902 may be notified that the RF has been intentionally turned off on the remote interface 802 to avoid generating airplane mode and therefore walkaway warnings. However, this may be completely hidden from the radios of the device 800.

[0240] In some embodiments, the radio of 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. The radio of remote interface 802 may transition to radio off mode after a predefined time period, e.g., 20 minutes in search synchronization mode, if the heartbeat exchange is unsuccessful.

[0241] In some embodiments, the device radio may transition to acquisition mode after a predefined amount of time, e.g., 20 minutes in search synchronization mode, without a successful heartbeat exchange. In some embodiments, listening during a pre-agreed time slot is the most efficient use of device 800 power to re-establish an RF link. After a loss of communication, crystal tolerances and temperature drift may require extending the device 800's receive time window over time. Remaining in search synchronization mode after a loss of communication for an extended period of time (e.g., 5-20 minutes) may cause the instantaneous power consumed to exceed the average power allocated to the device 800 radio. Because the remote interface 802 radio is not forced to extend its time window, remaining in search synchronization mode can be very power-efficient. Acquisition mode may consume more power in 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 radio and the device 800 radio; however, this time may vary depending on the embodiment.

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

[0243] Radio protocol performance statistics may be desired to facilitate radio troubleshooting and to evaluate radio performance. In some embodiments, the following radio performance statistics may be maintained in a data structure by the radio protocol. However, these are merely one embodiment and may vary across embodiments. Some embodiments may use no 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 Bad CCA count Average RSSI (accumulated for good RX packets only) Drops from frequency hop list count Acquisition mode count (pairs found on this channel)

[0245] In some embodiments, a debug option may be used to collect engineering-only statistics. If processor performance, power, and memory allow, it may be desirable to maintain this information at runtime. Radio 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 intended to provide a bar indicator of the wireless link quality, similar to a cell phone. The link quality may be available to both the remote interface 802 and the 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 frequency every heartbeat. An adaptive pseudorandom frequency hopping algorithm may be used for synchronization mode, and heartbeats are attempted in search synchronization mode. In some embodiments, the goal for frequency hopping may be to use, for example, 64 channels. However, in other embodiments using frequency hopping, more than 64 channels may be used. In some embodiments, an algorithm may be developed to adaptively generate a channel list on the remote interface 802 for 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 the device 800 by the radio of the remote interface 802 using a messaging system as needed to meet performance requirements. By creating channel lists from both the device 800 and the remote interface 802 perspectives, the radio interference environments of both units may be taken into account. The radio may adaptively select a hopping channel to meet round-trip message latency while operating in a desired RF environment.

[0248] 13 , in some embodiments, a system may include at least two reusable portions 1300, 1308 of an infusion pump and at least one disposable portion 1310 of the infusion pump. In some embodiments, the reusable portions 1300, 1308 include a rechargeable battery 532. In some embodiments, the two disposable portions may be paired to the same remote interface, which may include the embodiment shown as 1302 in FIG. 13 and / or any one or more of those shown as 600, 700, 802 in FIGS. 6-8. In some embodiments, a user may connect the reusable portion 1308 to the disposable portion 1310 by rotating the reusable portion 1308 in the direction of arrow 1316 while mating with the disposable portion 1310 to connect the reusable portion 1308 and disposable portion 1310, as described above. The second reusable part 1300 may be docked onto the recharging station 1304 by connecting to the recharging station 1304 through electrical contacts (not shown) in the recharging area 1306. While the user sleeps or otherwise remains in a single area for an extended period of time, e.g., three hours, the remote interface 1302 may be recharged by docking the remote interface 1302 onto 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 that may be configured to couple with the remote interface 1302 when the remote interface 1302 is placed in the slot 1318. The USB plug may allow for data transfer to / from the remote interface 1302 as well as charging of the remote interface 1302. In some embodiments, the user may use one reusable part 1308 while the second reusable part 1300 is recharging.

[0249] 14A-14E, another embodiment of an infusion pump system is shown. The system may include a remote interface 1402, one reusable part 1400, a second reusable part 1406, at least one disposable part 1408, and a charging station 1404 for charging the remote interface 1402 and / or filling the one or two disposable parts 1400, 1406. In some embodiments, the charging station may be similar to or any charging station shown in or described in one or more of U.S. Publication Nos. US-2007-0228071 (Attorney Docket No. E70), published October 4, 2007, and US-2009-0299277 (Attorney Docket No. G75), published December 3, 2009, and U.S. Patent Application No. 12 / 981,283, "Infusion Pump Assembly," filed December 29, 2010, (Attorney Docket No. I41), which are incorporated herein by reference in their entireties. As discussed above with respect to FIG. 13 , the charging station may include a USB plug that may be configured to couple with the remote interface 1402 when the remote interface 1402 is positioned within the slot 1414. The USB plug may enable data transfer to / from the remote interface 1402 as well as charging of the remote interface 1402.

[0250] 15A-15B, another embodiment of a 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, and in some embodiments, a mini-USB port, which may allow the charging station 1500 to receive power to charge the reusable part and / or the remote interface via USB 1506. Additionally and / or alternatively, the USB port 1508 may be configured for data transfer to / from the remote interface and / or the reusable part and / or by 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 web portal to check for updated software and, if updated software is available, download the software updates. These updates may then be transferred to the reusable part upon pairing.

[0251] 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 coupled to electrical contacts 1634 of the reusable housing assembly 1602. The electrical contacts 1606 may include, but are not limited to, electrical contact pads, spring-biased electrical contact members, or the like. Additionally, the top plate 1604 may include alignment tabs 1608, 1610 that may be configured to mate with openings 1636, 1638 in the base plate 1618 of the reusable housing assembly 1602 (e.g., as shown in FIG. 5C ). Cooperation of alignment tabs 1608, 1610 and openings 1636, 1638 may ensure that reusable housing assembly 1602 is aligned with battery charger 1600 such that electrical contacts 1606 of battery charger 1600 may electrically couple with electrical contacts 1634 of reusable housing assembly 1602.

[0252] The battery charger 1600 may be configured to removably engage the reusable part 1602. For example, in a manner similar to the disposable part, 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 part 1602 may be aligned (via alignment tabs 1608, 1610) with the battery charger 1600 with the locking ring 1606 in a first, unlocked position, as shown in FIG. 16C . The locking ring 1606 may be rotated relative to the battery charger 1600 in the direction of arrow 1616 to releasably engage tabs 1642, 1644, 1646, 1648 of the locking ring 1606 with locking tabs (e.g., locking tabs 1612, 1614) of the battery charger 1600, as shown in FIG. 16D.

[0253] In some embodiments, the battery charger 1600 may include a recessed area 1618, which may, for example, in some embodiments, provide clearance to accommodate pumping and valving components of the reusable part 1602. Also, with reference to FIGS. 16E-16F , the battery charger 1600 may provide electrical current to the electrical contacts 1606 (and thereby to the reusable part 1602 via electrical contacts 1634) for recharging the battery 1632 of the reusable part 1602. In some embodiments, no electrical current may be provided to the electrical contacts 1606 unless a signal indicating a fully engaged reusable part is provided. According to such embodiments, risks associated with short circuits (e.g., caused by a foreign object contacting the electrical contacts 1606) and damage to the reusable part 1602 (e.g., resulting from improper initial alignment between the electrical contacts 1606 and the electrical contacts 1634) may be reduced. Additionally, in some embodiments, the battery charger 1600 may not unnecessarily draw current when the battery charger is not charging the reusable portion 1602 .

[0254] 16E-16F, the battery charger 1600 may include a lower housing portion 1624 and a top plate 1604. A printed circuit board 1622 (which may include, for example, electrical contacts 1606) may be disposed within a cavity contained between the top plate 1604 and the lower housing portion 1624.

[0255] 16A-16F, in some embodiments, the battery charger 1600 may include a USB plug 1650 that may be configured to couple to a wall charger and / or a computer and / or a personal computer and / or a remote interface. The USB plug 1650 may enable data transfer to / from the computer / remote interface 1402 as well as providing power for charging the reusable portion 1602 using the battery charger 1600.

[0256] 17, one illustrative example of how the various components of the infusion pump system connect / communicate with each other is shown. For example, battery charger 1704 may be coupled to computing device 1700 (which in some embodiments may be a personal computer or any device that can be used in a manner similar to a personal computer, such as, but not limited to, a tablet) via bus conversion device 1702, which, in some embodiments, converts RS232 formatted data to, for example, I2C formatted data. Bus conversion device 1702 may execute a pass-through program that accomplishes the conversion. Battery charger 1704 may be coupled to radio processor 1718 via electrical contacts 1606 (described above). Radio processor 1718 may then be coupled to supervisor processor 900 and command processor 902, for example, via an RS232 bus. Radio processor 1718 may, in some embodiments, execute an update program that allows radio processor 1718 to control / orchestrate updates to flash memories accessible by supervisor processor 900 and command processor 902. Thus, through the use of the above linkages, software updates obtained by computing device 1700 may be uploaded to flash memory (not shown) accessible by supervisor processor 900 and command processor 902. The above software updates may, in some embodiments, be command line programs that may be automatically invoked by a script process.

[0257] 18 and 19, two embodiments of communication between a device, a remote interface, and a 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 FIG. 18, the remote interface 1800 communicates with an infusion pump 1802 and, in some embodiments, two other devices, which may include a blood glucose meter 1806 and a continuous glucose monitor 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., the remote interface 1800 uploading information to the personal computer 1808.

[0258] In FIG. 19 , the remote interface 1900 communicates with an infusion pump 1902. The infusion pump 1902 communicates with two other devices, which in some embodiments may include a blood glucose meter 1906 and / or a continuous glucose monitor sensor / transmitter 1904, and in some embodiments, may be two continuous glucose monitor sensors. In some embodiments, the communication is wireless and may use RF communication, e.g., RF communication protocols as 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 thus serves as a visual UI, as the remote interface 1900, in some embodiments, includes a display. In some embodiments, the remote interface 1900 communicates wirelessly with a personal computer 1908 (which in some embodiments has access to at least one web portal and / or 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] 18 and 19, three devices are shown communicating, either directly or indirectly, with the remote interface, but the system is not limited to three devices and may, in some embodiments, include four or more devices. Additionally, in some embodiments, the system may include one device in communication with the remote interface 1900. Also, while one personal computer is illustrated in FIGS. 18 and 19, in other embodiments, one or more personal computers may be used to receive information from the remote interface. Additionally, as discussed above with respect to the battery charger and charging station, in some embodiments, the infusion pump and / or the remote interface may be connected to the charging station and may upload and / or download and / or communicate with the personal computer via a USB connection.

[0260] 35A, in some embodiments, the remote interface 3500 communicates with an infusion 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), for example, or other similar type devices that may be referred to as a "mini remote interface." In some embodiments, the mini remote interface may include one or more user inputs, including any mechanism by which a user of the device and / or remote interface and / or other operator / caregiver may control the function of the device and / or remote interface. The user input may include one or more mechanical arrangements (e.g., switches, push buttons, jog wheels), electrical arrangements (e.g., sliders, touch screens), 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 / light wave images (including, but not limited to, camera input and / or image capture using a camera), sonic, and / or other types of interfaces.

[0261] In some embodiments, the compact remote interface may include all or a portion of the functionality described above with respect to the remote interface. In some embodiments, the compact remote interface may therefore provide all of the same functionality (and in some embodiments, additional functionality) as described above with respect to the remote interface, and, as described above, in some embodiments, may be paired with an infusion pump, etc.

[0262] Referring again to FIG. 35B , in some embodiments, the compact remote interface 3500 communicates with an infusion pump 3502 and, in some embodiments, may also communicate with additional devices, including medical devices, which in some embodiments may include one or more devices, which in some embodiments may include, but are not limited to, at least one blood glucose meter 3506 and / or at least one continuous glucose monitor sensor / transmitter 3504. In various other embodiments, other devices may also communicate with the compact remote interface 3500. In some embodiments, the communication is wireless and may use an RF communication protocol, such as an RF communication protocol, as described above, and / or BLUETOOTH® / BLUETOOTH® low energy or other non-proprietary protocol. 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 aforementioned communication protocols, one or more of the following communication protocols may be used, including, but 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 the same between each device, and in some embodiments, the communication may be different between each device. In some embodiments, the compact 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 compact remote interface 3500 and the personal computer 3508 may communicate via a web / internet connection 3510, and / or via the compact 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 which the compact remote interface 3500 uploads information to the personal computer 3508. In some embodiments, communication between the compact remote interface 3500 and the infusion pump 3502 is two-way communication. In some embodiments, communication between the compact remote interface 3500 and the personal computer 3508 is one-way, i.e., the compact remote interface 3500 may communicate with the personal computer 3508 (and / or the Internet); however, the personal computer 3508 (and / or the Internet) may not communicate with the compact remote interface. This may be beneficial for a number of reasons, including, but not limited to, control of information uploaded to the compact remote interface 3500, which may protect the compact remote interface 3500 from viruses and / or prevent undesirable and / or incorrect information from being uploaded onto the compact remote interface 3500. However, in various embodiments, communication between one or more of the various devices 3500, 3504, 3506, 3602, 3510, 3508 may be either unidirectional or bidirectional, and in some embodiments, communication may be unidirectional for some communication of predefined types or categories of information and bidirectional for other types or categories of information. This may be desirable for a number of reasons, including, but not limited to, for example, limiting communication of therapy-critical information to unidirectional communication between a dedicated and / or secure device and another device.

[0263] 35C , in some embodiments, the compact remote interface 3500 communicates with the infusion pump 3502 and, in some embodiments, may also communicate with additional devices, including medical devices, which in some embodiments may include one or more devices, which in some embodiments may include, but are not limited to, at least one blood glucose meter 3506 and / or at least one continuous glucose monitor sensor / transmitter 3504. In some embodiments, the compact remote interface 3500 may also communicate with a remote interface 3512, which may be any remote interface, including, but not limited to, a smartphone, e.g., an ADROID® smartphone. In some embodiments of this embodiment, the remote interface 3512 may include one-way communication between the compact remote interface 3500 and the remote interface 3512. Thus, in these embodiments, the remote interface 3512 may receive and display information related to one or more devices / medical devices 3502, 3504, 3506 that are in communication with the compact remote interface 3500; however, the remote interface 3512 may not control one or more of the devices 3502, 3504, 3506, may not control the compact remote interface 3500, and may not send information to the compact remote interface 3500. In some embodiments, the remote interface 3512 may therefore be used as an auxiliary user interface, including the ability to display information, e.g., 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 that can be used as a phone, but may also include applications that allow the compact remote interface 3500 to send information to the remote interface 3512 and present the information to the user in a graphically rich format.Thus, in this embodiment, the compact remote interface 3500 is the only device in the system that controls the infusion pump 3502 and may receive information from and send commands to and / or control the other devices 3504, 3506, including one or more of: programming / commanding bolus delivery, and / or programming and delivery of basal rates, and / or programming / commanding any therapy-related commands, including, but not limited to, commands for therapy changes or delivery. In some embodiments of this embodiment of the system, the compact remote interface 3500 may also communicate with and send information to a personal computer 3508 and / or the Internet. 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 compact 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 interval desired. In some embodiments, the compact remote interface 3500 may transmit data to the remote interface 3512 upon command by the user. In some embodiments, information programmed into the compact remote interface 3500 by the user / caregiver may be shared by the compact remote interface 3500 with other devices 3512, 3504, 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 compact remote interface 3500.

[0264] In various embodiments, the compact remote interface 3500 may pair with the infusion pump 3502 and / or various devices 3504, 3506 and / or remote interface 3512 using, for example, any one or more of the protocols described above. However, in various embodiments, one or more of the devices 3504, 3506, 3512 may pair with the compact remote interface 3500 using standard BLUETOOTH® pairing protocols, including the BLUETOOTH® low energy protocol. In some embodiments, one or more of the devices 3504, 3506, 3512 may pair with the compact 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, network range may be limited during pairing. In some embodiments, network range may be limited during pairing and one or more other types of transmissions (which may in some embodiments be pre-programmed, including but not limited to, changes in therapy and / or delivery commands and / or changes in delivery commands), or may resume regular transmissions. In some embodiments, network range may be limited during all transmissions, including but not limited to, pairing. Various other embodiments of pairing, which may be used between any two or more of the devices in various embodiments of the system, are described above and below.

[0265] In some embodiments, the communication is wireless and may be RF communication, e.g., using an RF communication protocol as described above, and / or may use BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or may include, but is 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 compact 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 compact remote interface 3500 and the personal computer 3508 may communicate via a web / internet connection 3510 and / or via the compact 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 which the compact remote interface 3500 uploads information to the personal computer 3508. In some embodiments, communication between the compact remote interface 3500 and the infusion pump 3502 is two-way. In some embodiments, communication between the compact remote interface 3500 and the personal computer 3508 is one-way, i.e., the compact remote interface 3500 may communicate with the personal computer 3508 (and / or the Internet); however, the personal computer 3508 (and / or the Internet) may not communicate with the compact remote interface.This may be beneficial for a number of reasons, including, but not limited to, controlling the information uploaded to the small remote interface 3500, which may protect the small remote interface 3500 from viruses and / or prevent unwanted and / or incorrect information from being uploaded onto the small remote interface 3500.

[0266] In any one or more of the foregoing embodiments, in some embodiments, the compact 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 compact remote interface 3500 may communicate with the infusion 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 of the devices in various embodiments of the system are described above and below.

[0267] Still referring to FIG. 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 through the compact remote interface 3500. The compact remote interface 3500 thus acts as a security “firewall,” i.e., a security barrier, and thus the compact remote interface 3500 may only communicate directly with the infusion pump 3502 and / or other devices / medical devices 3504, 3506. Also, the infusion pump 3502 and / or other devices / medical devices 3504, 3506, in some embodiments, only communicate directly with the compact remote interface 3500. In some embodiments of this embodiment, the compact remote interface 3500 may communicate information received from the infusion pump 3502 and / or other devices / medical devices 3504, 3506 to the internet and / or a personal computer 3508 using the connection 3510.

[0268] 35E, in some embodiments, the compact remote interface 3500 and the remote interface 3512 may each be used to control the infusion pump 3502 and / or one or more additional devices / medical devices 3504, 3506. In some embodiments of this embodiment of the system, the compact remote interface 3500 may be a "tramp," and thus, when the remote interface 3512 and the compact remote interface 3500 are both within communication distance of the infusion pump 3502 and / or one or more devices / medical devices 3504, 3506 at the same time, the compact remote interface 3500 will be a device that can communicate with the infusion pump 3502 and / or one or more devices / medical devices 3504, 3506. In some embodiments, the compact remote interface 3500 and the remote interface 3512 may communicate and synchronize information at pre-programmed intervals and / or when within a pre-programmed communication distance, for example, the compact remote interface 3500 and the remote interface 3512 may synchronize using a synchronization protocol, which may be any synchronization protocol, upon recognizing that the compact remote interface 3500 and the remote interface 3512 are within communication distance and / or that a certain time interval has passed since the last synchronization. The compact remote interface 3500 and the remote interface 3512 may also pair using various protocols described and discussed herein.

[0269] In some embodiments, the communication is wireless and may be RF communication, e.g., using an RF communication protocol as described above, and / or may use BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or may include, but is 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 compact 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 compact remote interface 3500 and the personal computer 3508 may communicate via a web / internet connection 3510 and / or via the compact 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 which the compact remote interface 3500 uploads information to the personal computer 3508. In some embodiments, communication between the compact remote interface 3500 and the infusion pump 3502 is two-way. In some embodiments, communication between the compact remote interface 3500 and the personal computer 3508 is one-way, i.e., the compact remote interface 3500 may communicate with the personal computer 3508 (and / or the Internet); however, the personal computer 3508 (and / or the Internet) may not communicate with the compact remote interface.This may be beneficial for a number of reasons, including, but not limited to, controlling the information uploaded to the small remote interface 3500, which may protect the small remote interface 3500 from viruses and / or prevent unwanted and / or incorrect information from being uploaded onto the small remote interface 3500.

[0270] In any one or more of the foregoing embodiments, in some embodiments, the compact 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 compact remote interface 3500 may communicate with the infusion 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 of the devices in various embodiments of the system are described above and below.

[0271] 36, one embodiment of various embodiments of the present 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. Also in this embodiment, infusion pump 3602 and remote interface 3604 communicate using bidirectional communication. In this embodiment, the remote interface 3604 may issue commands to the infusion pump 3602 related to, but not limited to, settings related to therapy, which may include, but are not limited to, insulin sensitivity factors, carbohydrate to insulin ratios, blood glucose correction factors, blood glucose targets; delivery commands, including bolus commands, including normal and dual wave or extended boluses or combination boluses; 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-up commands; setup / system editing; alarm and alert troubleshooting; reminders; reservoir replacement and cannula replacement, etc., all of which may be entered by the user or caregiver through the remote interface 3604, and these commands may be 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 not limited to, BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or may include, but 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, communication may be the same between each device, and in some embodiments, communication may be different between each device. Additionally, devices, in some embodiments, may communicate via wired and / or USB connections.In any one or more of the foregoing embodiments, 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 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] 37 , one embodiment of various embodiments of the present system is shown. In this embodiment, the system 3600 includes an infusion pump 3602, a compact remote interface 3610, a continuous glucose monitor / transmitter 3606, and a blood glucose meter 3608. In this embodiment, the various devices 3602, 3606, 3608, 3610 may communicate using the BLUETOOTH® Low Energy (BTLE) protocol. However, this embodiment of the system 3600 additionally includes a personal computer 3612, which may be connected to the compact remote interface 3610 via a USB / wired connection, if desired. Also, in this embodiment, the infusion pump 3602 and the compact remote interface 3610 communicate using bidirectional communication. In this embodiment, the miniature remote interface 3604 may issue commands to the infusion pump 3602, including all of the various commands that any embodiment of the remote interface 3604 (described above) may include, including, but not limited to, commands related to therapy-related settings, which may include, but are not limited to, insulin sensitivity factors, carbohydrate-to-insulin ratios, blood glucose correction factors, blood glucose targets; delivery commands, including bolus commands, including normal and dual-wave or extended boluses or combination boluses; 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-up commands; setup / system editing; alarm and alert troubleshooting; reminders; reservoir replacement and cannula replacement, etc., all of which may be entered by a user or caregiver through the miniature remote interface 3610 and these commands may be communicated to the infusion pump 3602. Additionally, 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 / preselected functions. For example, in some embodiments, the personal computer 3612 may be used to modify or establish a basal profile and / or view logs / history.This may be desirable for many reasons, including, but not limited to, the ability to attach the compact remote interface 3610 to any desired personal computer 3612 and enter logs, modify one or more of the basal profiles, and / or view the log / history, for example, to a website, which in some embodiments may be secure / password protected (which may be desirable for many reasons, including, but not limited to, a physician or healthcare provider viewing and modifying the log / history and basal profile). In some embodiments, additional functions may be viewed and / or modified using the personal computer 3612. In some embodiments, the functions that may be viewed and / or modified may vary and / or be pre-set 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, any one or more of the settings and / or setup, food library, and alert preferences, including, but not limited to, reminders.

[0273] While this embodiment is shown using the BTLE protocol and a USB connection, in various other embodiments, any one or more wireless communication protocols may be used, including, but not limited to, BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or may include, but 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, communication may be the same between each device, and in some embodiments, communication may be different between each device. Additionally, two or more of the devices may, in some embodiments, communicate via wired and / or USB connections, and / or may communicate with certain devices via wired and / or USB connections, but with other devices via wireless communication. In any one or more of the foregoing embodiments, 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 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] 38 , one embodiment of various embodiments of the present 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, 3610 may communicate using the BLUETOOTH® Low Energy (BTLE) protocol. However, this embodiment of system 3600 additionally includes a personal computer 3612, which may be connected to miniature remote interface 3610 via a USB / wired connection, if desired. Also, in this embodiment, infusion pump 3602 and miniature remote interface 3610 communicate using bidirectional communication. In this embodiment, the compact remote interface 3604 may issue commands to the infusion pump 3602, including all of the various commands that any embodiment of the remote interface 3604 and / or compact remote interface 3610 (described above) may include, which may include, but are not limited to, settings related to therapy, which may include insulin sensitivity factors, carbohydrate-to-insulin ratios, blood glucose correction factors, blood glucose targets; delivery commands, including bolus commands, including normal and dual-wave or extended boluses or combination boluses; 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-up commands; setup / system editing; alarm and alert troubleshooting; reminders; reservoir replacement and cannula replacement, etc., all of which may be entered by a user or caregiver through the compact remote interface 3610, and these commands may be communicated to the infusion pump 3602. Additionally, 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 / preselected functions.For example, in some embodiments, the personal computer 3612 may be used to modify or establish the basal profile and / or view the log / history. This may be desirable for a number of reasons, including, but not limited to, the ability to attach the small remote interface 3610 to any desired personal computer 3612 and enter logs, modify one or more of the basal profiles, and / or view the log / history, for example, on a website, which in some embodiments may be secure / password protected (which may be desirable for a number of reasons, including, but not limited to, a physician or healthcare provider viewing and modifying the log / history as well as the basal profile). In some embodiments, additional functions may be viewed and / or modified using the personal computer 3612. In some embodiments, the functions that may be viewed and / or modified may vary and / or be preset and / or predefined 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, and any one or more of the food library and alert preferences, including, but not limited to, reminders.

[0275] In some embodiments of this embodiment of the system 3600, the remote interface 3604 may serve as a larger display for the miniature remote interface 3610, however, it may not 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 portable larger display) to display data and other information to the user / caregiver on a larger and / or clearer scale. 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 secure protocols.

[0276] While this embodiment is shown using the BTLE protocol and a USB connection, in various other embodiments, any one or more wireless communication protocols may be used, including, but not limited to, BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or may include, but 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, communication may be the same between each device, and in some embodiments, communication may be different between each device. Additionally, two or more of the devices may, in some embodiments, communicate via wired and / or USB connections, and / or may communicate with certain devices via wired and / or USB connections, but with other devices via wireless communication. In any one or more of the foregoing embodiments, 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 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] 39 , one embodiment of various embodiments of a system 3600 is shown. In this embodiment, the 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, 3610 may communicate using the BLUETOOTH® Low Energy (BTLE) protocol. However, this embodiment of the system 3600 additionally includes a personal computer 3612, which may be connected to the miniature remote interface 3610 via a USB / wired connection, if desired. Also, in this embodiment, the infusion pump 3602 and the miniature remote interface 3610 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 compact remote interface 3610 or the remote interface 3604 may issue commands to the infusion pump 3602, including all of the various commands that any embodiment of the remote interface 3604 or the compact remote interface 3610 (described above) may include, which may include, but are not limited to, commands related to, but not limited to, insulin sensitivity factors, carbohydrate-to-insulin ratios, blood glucose correction factors, blood glucose targets; delivery commands, including bolus commands, including normal and dual-wave or extended boluses or combination boluses; and therapy-related settings, which may include basal rate settings and basal rate changes and temporary basal rate commands; alarms and alerts; logs / history; start-up commands; setup / system editing; alarm and alert troubleshooting; reminders; reservoir replacement and cannula replacement, etc., all of which may be entered by a user or caregiver through the compact remote interface 3610, and these commands may be communicated to the infusion pump 3602. Additionally, 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 / preselected functions. For example, in some embodiments, the personal computer 3612 may be used to modify or establish basal profiles 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, enter logs, modify one or more of the basal profiles, and / or view the logs / history, which in some embodiments may be secure / password protected, on a website (which may be desirable for many reasons, including, but not limited to, a physician or healthcare provider viewing and modifying the logs / history as well as the basal profiles). In some embodiments, additional functions may be viewed and / or modified using the personal computer 3612.In some embodiments, the features that can be viewed and / or modified may vary and / or be pre-set 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 features, including, but not limited to, any one or more of the settings and / or setup, and food library, and alert preferences, including, but not limited to, 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 portable larger display) to display data and other information to the user / caregiver on a larger and / or clearer basis. 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 secure protocols.

[0280] While this embodiment is shown using the BTLE protocol and a USB connection, in various other embodiments, any one or more wireless communication protocols may be used, including, but not limited to, BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or may include, but 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, communication may be the same between each device, and in some embodiments, communication may be different between each device. Additionally, two or more of the devices may, in some embodiments, communicate via wired and / or USB connections, and / or may communicate with certain devices via wired and / or USB connections, but with other devices via wireless communication. In any one or more of the foregoing embodiments, 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 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] 39 , in this embodiment, the system 3600 includes an infusion pump 3602, a remote interface 3604, a compact 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, 3610 may communicate using the BLUETOOTH® Low Energy (BTLE) protocol. However, this embodiment of the system 3600 additionally includes a personal computer 3612, which may be connected to the compact remote interface 3610 via a USB / wired connection, if desired. Also, in this embodiment, the infusion pump 3602 and the compact remote interface 3610 may communicate using bidirectional communication, and the compact remote interface 3610 and the remote interface 3604 may communicate using bidirectional communication.

[0282] 39 , in another embodiment, the compact remote interface 3610 and the remote interface 3604 collectively function as a single remote interface or a compact remote user interface, as previously described. In some embodiments, the remote interface 3604 may perform non-safety-critical steps / functions and may be any device, including a smartphone, and may include downloadable applications. Thus, in some embodiments, the remote interface 3604 may be an MDDS or medical device data system. In these embodiments, the compact remote interface 3610 may be a dedicated device that includes secure protocols and may perform safety-critical steps / functions.

[0283] Thus, in these embodiments, the compact remote interface 3610 may issue commands to the infusion pump 3602 and the remote interface 3604, and the compact remote interface 3610 may communicate with each other. However, in some embodiments, important steps / commands / confirmations are entered only through the compact remote interface 3610. Referring again now to FIG. 40 , an example of a method for commanding the delivery of a bolus 4000 is shown. This method is one embodiment and shows the steps for commanding a regular bolus; however, similar steps may be used to command any type of bolus. The user / caregiver first enters the number of units desired for the bolus using the remote interface (3604) 4002 (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 (thus, 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 indicating to the user the number of units the bolus will deliver, e.g., 4.0 units, and may include a run, start, or confirm icon, as well as a cancel icon; in some embodiments, the cancel icon may be highlighted as the default. In some embodiments, using the remote interface 3604, the user may modify the number of units in either the regular bolus or the number resulting from the calculation in the bolus calculator function.However, the user / caregiver then confirms the amount on the miniature remote interface (3610) 4006, which commands the infusion pump to deliver the bolus 4008. The infusion pump 3602 then delivers the bolus 4010. In various embodiments, the user may select to cancel the bolus using the miniature remote interface in step 4006 rather than confirming the amount. Also, in various embodiments, the bolus delivery 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 sent 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 a number of reasons, including, but not limited to, the ability to present large amounts 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 various menu items. On the other hand, the small remote interface 3610, in some embodiments, includes a limited screen and therefore may make it more difficult for the user / caregiver to view large amounts of information on a single screen. Thus, the above-described embodiments present an MDDS for displaying non-safety-critical information and a dedicated, secure, smaller device for presenting safety-critical information and issuing safety-critical information commands. In various embodiments of this embodiment, all safety-critical inputs must be confirmed on the small remote interface 3610 before the commands are sent to the infusion pump 3602.For example, again referring to FIG. 41 , a user / caregiver uses the remote interface 3604 to input or change a safety-critical setting and / or enter a command 4100, the remote interface displays instructions for the user / caregiver to confirm the input / change to the safety-critical setting and / or command on the miniature remote interface 4102. A confirmation screen on the miniature remote interface 3610 then requests the user to confirm or cancel the setting or command 4104. If the user confirms the setting or command on the miniature remote interface (3610) 4106, the setting / command is communicated to the infusion pump 3602 and / or implemented within the system 4108.

[0284] In various embodiments, safety-critical commands and / or settings may include, but are not limited to, any setting or command that results in either a calculation of an amount of infusible fluid (e.g., insulin) to deliver to a user, an amount of infusible fluid (e.g., insulin) to deliver to a user, a time for delivering infusible fluid to a user, and / or a command for delivery of infusible fluid to a user, and / or a cancellation of delivery of infusible fluid. In some embodiments, therefore, the remote interface 3604 may be used to input and view non-safety-critical commands, such as initiating commands (but not confirming them), entering information for a bolus calculator / wizard, and viewing calculations and recommended volumes of infusible fluid to be delivered using the remote interface 3604, but not confirming the information / volumes or commanding the infusion pump 3602 to deliver. The remote interface 3604 may also be used to view alarms and alerts, troubleshoot alarms and alerts, view the logbook / log and history, and set up and edit basal profiles. However, in some embodiments, basal profile setup and editing may be completed using the remote interface 3604 (or personal computer 3612), but they must be confirmed using the miniature remote interface 3610. In some embodiments, basal profile setup and editing may be completed and confirmed using the remote interface 3604 (or personal computer 3612). Additionally, 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, settings such as the time may require confirmation using the miniature 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 changes and / or commands may be classified as safety-critical and require confirmation using the miniature remote interface 3610; however, in some embodiments, various changes and / or commands may be classified as non-safety-critical and may be implemented through the remote interface 3604 and / or the personal computer 3612. However, regardless of whether changes / commands are classified as safety-critical in any given embodiment, they must be confirmed using the miniature remote interface 3610 or may not be implemented / commanded to the infusion pump 3602. Thus, in these embodiments, information sent 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. Thus, in these embodiments, the remote interface 3604 cannot issue commands directly to the infusion pump 3610.

[0286] 39-41 , in various embodiments, commands / settings that may be considered safety-critical may include, but are not limited to, one or more of: insulin sensitivity factor, carbohydrate-to-insulin ratio, blood glucose correction factor, blood glucose target; delivery commands, including bolus commands, including normal and dual-wave or extended bolus or combination bolus; and commands related to changing therapy and various therapy commands, including therapy-related settings, which may include basal rate settings and basal rate changes and temporary basal rate commands; acknowledging and / or silencing one or more alarms and alerts; start commands; setup / system editing; alarm and alert troubleshooting, all of which may be entered by the user or caregiver through the remote interface 3604, although final confirmation must be completed on the miniature remote interface 3610 or the changes / commands will not be communicated to the infusion pump 3602. Additionally, 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 / preselected functions. For example, in some embodiments, the personal computer 3612 may be used to modify or establish the basal profile and / or view the log / history. This may be desirable for a number of reasons, including, but not limited to, the ability to attach the small remote interface 3610 to any desired personal computer 3612 and enter logs, modify one or more of the basal profiles, and / or view the log / history, for example, on a website, which in some embodiments may be secure / password protected (which may be desirable for a number of reasons, including, but not limited to, a physician or healthcare provider viewing and modifying the log / history as well as the basal profile). In some embodiments, additional functions may be viewed and / or modified using the personal computer 3612.However, in some embodiments, various features may be viewed or modified using the personal computer 3612, but if the feature is safety-critical, the user / caregiver must confirm any changes using the small remote interface 3610. In some embodiments, the features that may be viewed and / or modified using the personal computer 3612 may vary and / or be pre-set and / or pre-defined and / or hard-wired into the system. In some embodiments, the personal computer 3612 may be used to view / modify more or fewer features, including, but not limited to, settings and / or setup, and any one or more of the food library and alert preferences, including, but not limited to, reminders.

[0287] In various embodiments, viewing and / or modifying logs / history, alarm and alert troubleshooting, reminders including reservoir and cannula changes, etc. may all be classified as non-safety critical, in some embodiments, one or more of these may be classified as safety critical.

[0288] In some embodiments of the present embodiments, the remote interface 3604 may serve as a larger display for the miniature remote interface 3610, however, it may not 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 portable larger display) to display data and other information to the user / caregiver on a larger and / or clearer scale. In various embodiments of the present embodiments, 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 secure protocols.

[0289] While this embodiment is shown using the BTLE protocol and a USB connection, in various other embodiments, any one or more wireless communication protocols may be used, including, but not limited to, BLUETOOTH® / BLUETOOTH® Low Energy or other non-proprietary protocols, and / or may include, but 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, communication may be the same between each device, and in some embodiments, communication may be different between each device. Additionally, two or more of the devices may, in some embodiments, communicate via wired and / or USB connections, and / or may communicate with certain devices via wired and / or USB connections, but with other devices via wireless communication. In any one or more of the foregoing embodiments, 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 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 the miniature remote interface, the user may be required to swipe the screen either 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 pre-determined period of time, e.g., three seconds. However, in various embodiments, the amount of time may vary. In some embodiments, the user may be required to place the miniature remote interface in close proximity to the remote interface for confirmation. In some embodiments, confirmation may be achieved by pressing a switch assembly on the infusion pump.

[0291] In some embodiments where the miniature remote interface is required to confirm a command, if the user / caregiver loses access to the miniature remote interface, the user may use a predefined encrypted signal, e.g., a dial tone, voice recognition, that is played / spoken to the infusion pump to confirm the command. In some embodiments, there may be a secure call center where the user / caregiver may call in and, after identifying themselves using either a passcode, patient confidentiality 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 the various devices may be accomplished using any of the methods described above or known in the art, such as BLUETOOTH® pairing. However, in some embodiments, the various devices may be paired using near-field 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 an infusion pump with a miniature remote interface and / or any one or more of the various devices in a system involving the remote interface and / or any one or more devices may include performing the pairing in an area where the devices remain paired in close proximity to each other and where additional devices are unlikely to interfere, such as the user's / caregiver's home / office.

[0293] Referring again now to FIG. 42 , a flow diagram is shown illustrating a methodology 4200 for securely communicating between one or more devices, such as between a medical device and a user interface / remote interface / mini-user interface device, according to an embodiment of the present disclosure. Method 4200 includes acts 4204-4220. In act 4204, the master device and the slave device establish communication over a communication link. The communication link may be unsecured. In some embodiments, the communication link may use public-private key cryptography. In act 4206, the master device (e.g., medical UI / remote interface / mini-remote interface device) and the slave device (e.g., blood glucose meter, continuous glucose monitor transmitter, etc.) negotiate a prime number p and a base number g using the communication link. The negotiation may occur using an encrypted communication link, via a wired link, or using public-private key-pairing cryptography. The base number g is a primitive root modulo p. P and g may be publicly known. In act 4208, the master device generates a random number a and calculates u = g^a(mod p). In act 4210, the master device sends a and u to the slave device. In act 4212, the slave device generates a random number b, calculates v = g^b(mod p), and communicates b and vg^b(mod p) to the master device.

[0294] In act 4216, the master device calculates key k, where k = v^a = (g^b)^a(mod p). In act 4218, the slave device calculates 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 act 4220, the master and slave devices use the shared secret key k as a seed to the symmetric encryption key. The secret key may be used as an index to a pseudo-random index, in which case the pseudo-random index is the key for the symmetric key.

[0295] 43A-43J, several embodiments of screenshots on the compact remote interface 3610 are shown. In various embodiments, the compact 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 touch screen. In some embodiments, the display may include a touch screen, where the user / caregiver first scrolls and selects the particular command (which may be done using any of the user inputs), and then confirms or selects the particular command by touching the screen in another particular location and swiping the screen either left to right or right to left. In some embodiments, for example, as shown in FIG. 43A, to unlock the screen, the user / caregiver may be required to swipe the screen from left to right, while in some embodiments, for example, as shown in FIG. 43J, to select or confirm, the user / caregiver may be required to swipe the screen from right to left. This may be desirable / beneficial for many reasons, including, but not limited to, preventing unintentional confirmation by requiring the user to confirm by swiping in a direction different from the unlocking direction. In various embodiments, the direction for each action may be different. In some embodiments, the direction to unlock may be right to left, and the direction for confirmation / selection may be left to right. In some embodiments, swiping in the confirmation direction 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. Again, referring to FIGS. 43C-43D, in some embodiments, the small remote interface 3610 may include a display that includes menu selections. The menu selections may be scrolled by swiping the screen or by another user input. The menu selection may then be selected by the user / caregiver.43E-43G, in various embodiments, once the user / caregiver navigates to the Bolus Home screen, the user / caregiver may select the type of bolus to deliver, for example, using a wizard / calculator, manually, or by another type (represented by a preset). In some embodiments, scrolling through menu items may be accomplished using a touchscreen by touching a particular location and then swiping up or down from that location 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 another user input, for example, one or more buttons and / or a scroll wheel. Again, referring to FIG. 43G, once a desired option is selected, for example, using a wizard, the user may swipe the screen. In some embodiments, the user may touch the screen to select.

[0296] 43K-43N, in various embodiments, once a bolus type, e.g., a wizard, is selected, the next screen requests that the user enter blood glucose and carbohydrate values. In various embodiments, a screen / scroll function may be present to enter these values, and screen scrolling movement may be effected by swiping the screen up or down to effect scrolling. In some embodiments, other user inputs may be used. In some embodiments, once the desired values ​​are entered, the user may swipe the screen, e.g., from right to left, to select the value and proceed to the next screen.

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

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

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

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

[0301] 44A-44B, in various embodiments, the screen may be locked, which may be beneficial for a number of reasons, including, but not limited to, preventing unintentional changes to settings and / or commands sent to the infusion pump. In some embodiments, a locked screen may require a passcode to unlock the screen. In various embodiments, unless the passcode unlocks the screen, the screen remains locked and settings cannot be changed or commands sent.

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

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

[0304] 46A-46B, in various embodiments, a basal pattern may be programmed by entering a start and end time and the rate for that time frame. In various embodiments, the basal pattern may be displayed as a graph representing the basal pattern delivery rate throughout a 24-hour period. In various embodiments, as shown in FIG. 46B, once a basal pattern is programmed, the user / caregiver may review the entire pattern, including the graphical representation and time frame, on a single screen. Additionally, the basal pattern may be switched by selecting "Switch Basal Pattern" and then selecting another basal pattern. A graphical representation may be beneficial / desirable for many reasons, including, but not limited to, presenting the basal pattern / profile in a manner that easily identifies when rates are higher or lower and provides an overall picture throughout the day.

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

[0306] 48A-48D, in various embodiments, to adjust any rate in a basal pattern, the user / caregiver may navigate to Adjust Basal Pattern and then select the rate they wish to adjust. Once selected, an indication of the current rate 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] 49A-49B, in various embodiments, a temporary basal rate may be set. In some embodiments, this may be done by navigating to a "Set Temporary Rate" screen, where the new rate may, in some embodiments, be entered using a keypad (see FIG. 49B), and the duration of the new rate may, in some embodiments, be entered using a scroll wheel function (see FIG. 49A). A graphical depiction of the basal pattern may also assist the user / caregiver in programming the temporary rate, as it may visualize the difference between the rates before and after the temporary rate and aid in programming an adequate rate.

[0308] 50A-50B, in various embodiments, basal patterns / profiles may be managed using a basal profile management screen. For example, as shown in FIG. 50A, in some embodiments, basal patterns may be viewed collectively on a single screen showing 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 manage basal patterns screen, a graphical depiction of the pattern may be shown along with options to adjust the rate, set as the current pattern, delete the pattern, or copy the pattern (to create another pattern with a new name but having the same pattern) (see FIG. 50B).

[0309] 51A-51B, in various embodiments, the user interface may include a "Preset Bolus" option, where the user / caregiver may pre-set bolus amounts and / or bolus types, for example, for breakfast, lunch, and dinner. To request 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 FIG. 51B) showing the bolus type and amount, e.g., regular 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 FIG. 51A (see FIG. 51B).

[0310] 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 enter carbohydrate and blood glucose amounts using a keypad (a carbohydrate screenshot is shown in FIG. 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 a blood glucose reading. The next screen, an embodiment of which is shown in FIG. 52B, shows the calculation of the user's correction bolus based on blood glucose (which in this example is 125 mg / dL), insulin correction (based on active insulin, which in this example is 2.45 units), and meal bolus (based on carbohydrate). The total bolus amount is also shown (which in this example is 7.50). 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 "dual wave" bolus. Referring now to FIG. 52C , in various embodiments, to deliver part of the bolus as a regular 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 regular, expressed as both units and a percentage of the total, is represented on one side of a line, and the amount to be delivered as a square wave, expressed as both units and a percentage of the total, is represented on the other side. The user / caregiver may adjust the percentage of the amount to be delivered as regular and square wave by moving the rectangular icon toward the square wave or regular side. While moving the rectangular icon, the sum of both sides is 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 use the on-screen scroll wheel to program the duration of the square wave (see Figure 52D).

[0312]

[00103] 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 proportions 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 1 hour for a total of 2.50 units.

[0313] In various embodiments, the user may enter a normal bolus amount and then select to deliver some or all of the total bolus as an extended bolus or a "square wave" or "dual wave" bolus. Referring now to FIG. 52C , in various embodiments, to deliver some of the bolus as a normal bolus and some 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, expressed as both units and a percentage of the total, is represented on one side of a line, and the amount to be delivered as square wave, expressed as both units and a percentage of the total, is represented on the other side. The user / caregiver may adjust the percentage of the amount to be delivered as normal and square wave by moving the rectangular icon toward the square wave or normal side. While moving the rectangular icon, the totals on both sides are adjusted so that the user / caregiver can see the percentage and total unit changes in real time.

[0314] Referring again to FIGS. 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 FIG. 54A). With regard to the blood glucose check reminder, the user / caregiver may program the duration between the bolus and the reminder by using the scroll wheel to program the hours and minutes until the reminder. Additionally, the user / caregiver may turn the reminder on and off. Additional reminders may include, but are not limited to, a cannula fill blood glucose reminder, which may be programmed to remind the user / caregiver to check their blood glucose a certain (programmed) duration after filling the cannula. Infusion site reminders may also be programmed. As shown in FIG. 54D, in some embodiments, once the infusion site is changed, a 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., two days, which may be modified by the user / caregiver to any number of days desired, e.g., three days. Like other reminders, in this embodiment, this reminder may be turned on or off by user / caregiver preference. In some embodiments, a reminder to check blood glucose may be set by the user / caregiver, which may be set for any number of hours / minutes from the time of reminder creation. In some embodiments, this type of reminder is triggered by user / caregiver preference; for example, in some embodiments, the user / caregiver may have recently been treated for low blood glucose with carbohydrates and may want a 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 in some embodiments using the screen scroll wheel, as shown in FIG. 54C.

[0315] Other reminders may also be user-programmed, including, but not limited to, missed meal reminders. In some embodiments, the user / caregiver may program a reminder for the time a meal is expected. In some embodiments, if a bolus is not requested within 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 not delivered a bolus for the meal. In various embodiments, these reminders may be programmed to alert the user daily as recurring reminders, or may be single reminders.

[0316] 55A, in some embodiments, a walkaway alert may be included within the remote interface / infusion pump / and / or miniature remote interface system. The user may either turn the walkaway alert on or off, or 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 the screen scroll wheel.

[0317] Referring again to FIGS. 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 a 24-hour period. In various embodiments, the blood glucose targets may be represented to the user / caregiver in graphical form. The blood glucose targets may, in various embodiments, include a low target and a high target for each time frame / interval. This may be desirable for many reasons, including, but not limited to, the ability for the user / caregiver to visualize the various time frames / intervals and the targets for those time frames / intervals in a single graphical representation. This may be beneficial / desirable for many reasons, including, but not limited to, selecting the correct target during programming, which in some embodiments may prevent errors during programming. In addition to the graphical representation, each time frame / interval is written in and includes a high and low target (see FIG. 56A). To change a particular interval, the user may use the touchscreen to tap the particular interval, or in some embodiments, tap either the written interval section or the 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 FIG. 56B). In some embodiments, by selecting an interval, the user may "delete target" by selecting an option on the screen (see FIG. 56C).

[0318] 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 correction bolus calculations. In various embodiments, the user interface includes the ability to set carbohydrate ratios for various time frames / intervals throughout a 24-hour period. In various embodiments, the carbohydrate ratios may be represented to the user / caregiver in graphical form. The carbohydrate ratios, in various embodiments, include values ​​representing grams of carbohydrate per unit of infusible fluid, e.g., insulin. This may be desirable for many reasons, including, but not limited to, the ability for the user / caregiver to visualize various time frames / intervals and the ratios between those time frames / intervals in a single graphical representation. This may be beneficial / desirable for many reasons, including, but not limited to, selecting the correct ratio during programming, which in some embodiments may prevent errors during programming. In addition to the graphical representation, each time frame / interval is filled in and includes the carbohydrate ratio for that time frame / interval (see FIG. 57B). To change a particular interval, the user may use the touchscreen to tap the particular interval, or in some embodiments, tap either the written interval section or the graphical representation of that interval. A new screen appears, including a screen scroll wheel for changing the interval and / or changing the ratio (see FIG. 57C). In some embodiments, by selecting an interval, the user may "delete target" by selecting an option on the screen (see FIG. 57A).

[0319] 58A-58T, in various embodiments, the user interface includes a logbook. In various embodiments, the logbook includes functionality for both receiving information from the user / caregiver and processing that information (referred to as "events"), as well as displaying historical data for the system. Referring now to FIG. 58A, in some embodiments, the logbook home page may include the last blood glucose entered into the system (or, in some embodiments, collected directly by the system), the duration since the last blood glucose, the volume of the last bolus delivered, and the duration since the last bolus. The logbook home page, in some embodiments, also includes menu options for the user / caregiver to navigate to various sections of the logbook. In some embodiments, the various sections include, but are not limited to, "Last Glucose Entry," "Event Entry," "View Daily Totals," and "View Event History." In various embodiments, the logbook home page additionally includes menu icons for navigating to other sections of the user interface.

[0320] Referring again to FIGS. 58B-58G, in some embodiments, the logbook includes the ability for the user / caregiver to enter an "event," which may include the number of grams of carbohydrates ingested by the user, an exercise event, and / or an insulin injection / medication event. The user / caregiver may then be navigated to enter the appropriate event. In some embodiments, the user / caregiver may enter a "carbohydrate event" by navigating to the appropriate screen and entering the number of grams of carbohydrates consumed (see FIG. 58B). In some embodiments, the user interface may also include the type of carbohydrate / food consumed, e.g., pizza, cupcake, sushi, lasagna, brown rice, Mom's Chicken Soup, etc. Once the user / caregiver presses "Next," a review screen appears showing the number of grams of carbohydrates as well as the date and time of the event (see FIG. 58C). In some embodiments, the user / caregiver may enter an "exercise event" by navigating to the appropriate screen and entering the intensity of the exercise (low, medium, or high) (see FIG. 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," the user / caregiver may enter the duration of the exercise (see FIG. 58E). Finally, the details of the exercise event may be reviewed by the user / caregiver (see FIG. 58F). Once the user / caregiver confirms that the information is correct, the event is saved in a logbook for future reference by the user / caregiver (see FIG. 58G). A similar event entry method may be followed for entering insulin injections or other medication events. The type and dosage of medication may be entered, which will then be saved in the logbook and show the time and type and dosage of the medication for later review.

[0321] The ability to enter a specific event can be beneficial / desirable for many reasons, including, but not limited to, the ability for a user / caregiver to review previous events and track the results of that event, for example, reviewing blood glucose readings after an exercise, medication, or carbohydrate event, to either make decisions regarding future dosages of insulin or other medications, and / or determine changes in eating patterns based on the results from the exercise or ingestion of a specific food. The ease of entering these events can make it easier for those with diabetes and other diseases to enter events, which can lead to improved health.

[0322] Referring again to FIGS. 58H-58L, in various embodiments, the logbook additionally includes historical data that is presented to the user / caregiver upon request by navigating the user interface to the Daily Totals (FIG. 58I), Daily Dose (FIG. 58J), Total Carbohydrates (FIG. 58K), and Average Blood Glucose (FIG. 58L) sections of the logbook. Also referring to FIG. 58H, the user / caregiver may select to view the "Daily Totals" from a specific date, e.g., December 4, 2013. However, in various embodiments, another date may be selected. The daily totals, total carbohydrates, and average BG are then displayed for that particular date (FIG. 58I). The user / caregiver may then select to view any one of those menu items in detail. If the user / caregiver selects the "Total Daily Dose" menu item, a Daily Dose screen appears (FIG. 58J), which in some embodiments includes the total insulin given, the percentage of basal and bolus to the total, and different types of bolus delivery, e.g., carbohydrate (meal) bolus, BG (correction) bolus, manual (regular) bolus, etc. If the user / caregiver selects the "Total Carbohydrate" menu item, a Total Carbohydrate screen appears (FIG. 58K), which in some embodiments includes total carbohydrates (e.g., in some embodiments, entered into the system through carbohydrate / meal bolus, carbohydrate events where carbohydrates were entered, and / or through the bolus calculator), Bolus Wizard carbohydrates (including carbohydrates entered only through the Bolus Wizard / Bolus Calculator where carbohydrates were entered), the time carbohydrates were entered through the Bolus Wizard / Bolus Calculator, and total logbook carbohydrates (carbohydrates entered as events), as well as the time of carbohydrate events. In various embodiments, the type of information displayed on the various screens may vary.

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

[0324] Referring again to FIGS. 58M-58T, in various embodiments, a user / caregiver may view events in the logbook, for example, by specifying a date, e.g., December 5, 2013 (see FIG. 58M). The event history screen will present various events from the specified date, which in FIG. 58N is December 4, 2013 (see FIG. 58N). For each event, the user / caregiver may select the event, for example, by tapping a section using the touchscreen, and the event itself will be displayed. For example, if the first event shown in FIG. 58N, "Normal Bolus Stop," is selected, the screen shown in FIG. 58O will be displayed containing specific information about the event. Similarly, if a setting change event is listed in the event history, the user / caregiver may select the event, for example, by tapping a section using the touchscreen, and the event itself will be displayed (see FIG. 58P). Thus, the user / caregiver can review exactly which settings were changed and when. If a dual wave bolus event is listed in the event history, the user / caregiver may select the event, for example, by tapping a section using the touchscreen, and the event itself will be displayed (see Figure 58Q). The bolus event includes the type of bolus (dual wave), the time of the event (7:14:22 pm), and details, such as the units delivered as a regular bolus and the units delivered as a square wave bolus. If a basal rate change event is listed in the event history, the user / caregiver may select the event, for example, by tapping a section using the touchscreen, and the event itself will be displayed (see Figure 58R). The basal rate change event includes the changed pattern and the units of the pattern. If a temporary basal event is listed in the event history, the user / caregiver may select the event, for example, by tapping a section using the touchscreen, and the event itself will be displayed (see Figure 58S). The temporary basal event includes the basal rate change, the time of the event, and the duration. Referring again to FIG. 58T, the logbook additionally contains a list of all alarms and alerts.The user / caregiver may select an event, for example, by tapping a section using the touchscreen, and the event itself will be shown. Various alarms and alerts include, but are not limited to, low insulin alert, inactivity alarm, walkaway alert, insulin temperature alert, pump audio, and occlusion detection. However, more or fewer alarms and alerts may be included in various embodiments. When viewing alarms and alerts, the screen displays the alarm or alert type, time, and, in some embodiments, whether it was silenced.

[0325] As discussed above, in various embodiments of the infusion pump embodiment, the system may include two or more reusable parts. In these cases, in some embodiments, one reusable part may be in use while the other is on a recharger. While the first reusable part is in use, therapeutic agent may be administered by the supervisor processor and command processor, as described above. Actions by the reusable part are communicated to the remote interface. To "switch" the reusable part (so that the reusable part on the charger becomes the reusable part in use, or vice versa), the controller that uploaded information from the first reusable part during use downloads various logs onto the second reusable part so that the memory on the second reusable part contains all of the same memory as the first reusable part. This is done during the pairing process. One step in the process, after pump activation, in some embodiments, is performed by the user pressing a switch assembly on the reusable part while the remote interface is in connection mode. During this step, profiles and user therapy configurations are transferred to the second reusable pump and / or synchronized with the reusable part non-volatile memory.

[0326] Once this step is complete, in some embodiments, the second reusable portion, after internalization, transmits the basal profile back to the remote interface so that the remote interface can verify that the basal profile is correct. This step may confirm that the second reusable portion has received the correct information. In some embodiments, a display may show the basal profile to the user, and the user may confirm.

[0327] Thus, as previously described with respect to therapy administration, the infusion pump completes all decisions and controls the delivery of the infusible fluid. The remote interface is an interface to the infusion pump and, in some embodiments, provides an enhanced user interface (e.g., a ...

Claims

[Claim 1] A system that complies with patent requirements.

Images