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

Abstract

We provide devices, methods, and systems for wireless control of medical devices. [Solution] The medical device system includes a first medical device 1802 and second medical devices 1804, 1806. A remote interface 1800, including a touchscreen, is also included. The remote interface communicates wirelessly with the first and second medical devices. The remote interface is configured to provide a user interface to the first and second medical devices. The remote interface is configured to receive user input through the touchscreen.

Description

Technical Field

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

Background Art

[0002] Many potentially valuable drugs or compounds, including biological agents, are not orally effective due to poor absorption rates, liver 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 for drug delivery and other fluids and compounds, such as subcutaneous injection, intramuscular injection, and intravenous (IV) administration, involve piercing the skin with a needle or stylet. Insulin is an example of a therapeutic fluid that is self-injected by millions of diabetic patients. Users of parenterally delivered drugs can benefit from wearable devices that automatically deliver the required drugs / compounds over a period of time.

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

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

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

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

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

[0009] 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 portion and at least two reusable portions, each of the two reusable portions configured to connect to at least one disposable portion. A charging device is configured to receive at least one of the at least two reusable portions of the first medical device. The second medical device includes a continuous glucose monitoring system, which includes 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, which wirelessly communicates with the first medical device. The first medical device and the remote interface are paired using near-field communication. The first medical device and the second medical device are paired using near-field communication.

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

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

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

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

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

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

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

[0017] Some embodiments of this aspect of the present invention may include one or more of the following: The first medical device is a remote interface and the second medical device is an infusion pump. The first medical device is a remote interface and the second medical device is a continuous glucose monitoring sensor / transmitter. The first medical device is a remote interface and the second medical device is a blood glucose meter.

[0018] These aspects of the present invention are not exclusive, and other features, aspects, and advantages of the present invention will be readily apparent to those skilled in the art upon careful reading in conjunction with the appended claims and accompanying drawings.

[0019] These and other features and advantages of the present invention will be better understood by carefully reading the following embodiments for carrying out the invention, along with the drawings. For example, this specification provides the following: (Item 1) A medical device system, The first medical device, A second medical device, A remote interface comprising a touch screen, wherein 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, and the remote interface is configured to receive user input through the touch screen, the remote interface and A charging device 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, 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, the charging device and A system comprising. (Item 2) The system according to item 1, wherein the first medical device is an infusion pump. (Item 3) The system according to item 2, wherein the first medical device further comprises at least one disposable part and at least two reusable parts, and each of the two reusable parts is configured to be connected to the at least one disposable part. (Item 4) The system according to item 3, wherein the charging device is configured to receive at least one of the at least two reusable parts of the first medical device. (Item 5) The system according to item 1, wherein the second medical device is a continuous glucose monitoring system comprising at least one transmitter, and the at least one transmitter wirelessly communicates with the remote interface. (Item 6) The system according to item 1, further comprising a third medical device that wirelessly communicates with the remote interface. (Item 7) The remote interface is configured to provide a user interface to the third medical device, the system according to item 6. (Item 8) The third medical device is at least one blood glucose meter, the system according to item 7. (Item 9) Furthermore, the system according to item 1, comprising that the wireless communication is radio frequency communication. (Item 10) The first medical device and the remote interface are paired using short-range communication, the system according to item 1. (Item 11) The remote interface further comprises at least one camera, the system according to item 1. (Item 12) A medical device system, A first medical device, A second medical device that wirelessly communicates with the first medical device, A remote interface comprising a touch screen, the remote interface wirelessly communicates with the first 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 touch screen, the remote interface, 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, the charging device is configured to recharge the 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, the charging device Comprising a system. (Item 13) The first medical device is an infusion pump, the system according to item 12. (Item 14) The system according to item 13, wherein the first medical device further comprises at least one disposable part and at least two reusable parts, each of the two reusable parts being configured to connect to the at least one disposable part. (Item 15) The system according to item 13, wherein the charging device is configured to receive at least one of the at least two reusable parts of the first medical device. (Item 16) The second medical device, as described above, comprises a continuous glucose monitoring system having at least one transmitter, the at least one transmitter wirelessly communicating with the first medical device, as described in item 12. (Item 17) The system according to item 12, wherein the second medical device comprises a blood glucose meter that communicates wirelessly with the first medical device. (Item 18) The infusion pump system described in item 12, wherein the first medical device and the remote interface described above are paired using short-range communication. (Item 19) The infusion pump system described in item 12, wherein the first medical device and the second medical device are paired using short-range communication. (Item 20) An injection pump system, At least one disposable part of the injection pump, At least two reusable parts of an injection pump, each of which is configured to connect to at least one disposable part, A remote interface having a touchscreen, wherein the remote interface wirelessly communicates with at least one of the at least two reusable parts, the remote interface is configured to provide user instructions to at least one of the at least two reusable parts, and the remote interface is configured to receive user input through the touchscreen; and a charging device configured to receive at least one of the at least two reusable parts and the remote interface, wherein the charging device is configured to recharge the pump battery of at least one of the at least two reusable parts, the charging device is configured to recharge the 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. An injection pump system equipped with an injection pump. (Item 21) The injection pump system according to item 20 further comprises a continuous glucose monitoring system having at least one transmitter, wherein the at least one transmitter communicates wirelessly with the remote interface. (Item 22) The infusion pump system according to item 20 further comprises at least one blood glucose meter, the blood glucose meter communicating wirelessly with the remote interface. (Item 23) The injection pump system described in item 20, wherein at least one of the reusable parts and the remote interface are paired using short-range communication. (Item 24) The above remote interface further comprises at least one accelerometer, as described in item 20, for the injection pump system. (Item 25) The above remote interface is further comprising at least one camera, as described in item 20 of the injection pump system. [Brief explanation of the drawing]

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

[0021] definition As used in this description and the accompanying claims, the following terms shall have the meanings set forth below unless otherwise required by context.

[0022] "Remote interface" is not a limitation, but it means a device for wireless communication with other devices, which may include medical devices.

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

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

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

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

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

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

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

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

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

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

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

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

[0035] Throughout the various embodiments, the names given to screens and screen types, as well as appropriate names given to various features, may vary and are for illustrative purposes only. This description is not limited to these names.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0062] In various embodiments of the user interface, the user interface may require user confirmation and / or user input. In some embodiments, the user interface focuses on ensuring that the user understands the effects of various interactions with the device. Many embodiments will be presented throughout this description of a device that communicates the results of user actions to the user. These features ensure that the user understands the action and therefore provide the user with greater security. One such embodiment is that if the user presses the back button on the screen after a value has changed, the user interface displays a confirmation screen asking, "Do you want to undo the changes?". If the user selects "Yes", in various embodiments, the user interface discards any pending changes, closes the confirmation screen, and returns to the previous screen (i.e., the screen before the screen from which the user pressed the back button). If the action selection on the "Do you want to undo the changes?" confirmation screen is "No", the user presses a newline button or otherwise, 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 a change has been implemented when it has not. Therefore, this feature prevents such a situation and ensures that the user understands that the change has not been implemented. This is just one of many examples of user interfaces that require user confirmation and / or input.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0078] Furthermore, referring to Figures 8G-8H, in some embodiments, PCGP may operate by having all the major work done in a single thread in order to avoid mutual exclusion and to avoid performing a lot of work on send / reply or driver calls. The "packetProcessor" call may require the application of protocol rules to replies, new outgoing messages, and incoming messages. Reply messages may simply be sent, while new and incoming messages may have rules for sending the message. In each case, the software may loop until it can no longer process packets, as long as the correct type of message is capable of having its protocol rules applied.

[0079] Sending a new message may, in some embodiments, follow one or more of the following rules: • Only two messages may be permitted “in-flight” on the network. and / or Sufficient data about the in-flight message may be stored to match the response and handle timeouts. Message reception may follow the rules below. • A matching response may clear the "in-flight" information slot, allowing a new packet to be sent. • Non-matching responses may be dropped. • New messages may be related to a protocol (for example, to get / clear network statistics for this node). • A buffer may be provided to the application to receive messages, and / or a callback may be used. The buffer may be released or it may remain owned by the application. Therefore, in some embodiments, the PCGP may be configured as follows: The callback function may copy the payload data out, or it may use it completely before returning. • The callback function may copy the payload data to be used or to complete the process before returning. The callback function may own the buffer, refer to the buffer's payload by the buffer and payload address, and the message may be processed later. The application may poll the PCGP system for received messages, and / or The application may use a callback to set an event and then poll for incoming messages.

[0080] The communication system may have a limited number of buffers. When the 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, the application may attempt one or more steps, including, but not limited to, the following: a) The application may keep the PCGP up-to-date in a wireless state. Specifically, in some embodiments, if the link is down and the PCGP is unaware, the PCGP may receive new messages to send and queue them (or not optimally time out the messages), which may disrupt the send queue and delay the application from optimal use of the link. b) The application may periodically call "decrement timeout". Optimally, in some embodiments, the application may call "decrement timeout" every 20 to 100 milliseconds, unless the processor is sleeping. Generally, messages travel fast (a few milliseconds), slow (a few seconds), or not at all. A timeout, in some embodiments, is an attempt to remove "in-flight" messages that should be dropped to free up buffers and bandwidth. Not doing this frequently can delay the sending of new messages or the application queuing new messages. c) The application may ask the PCGP if there is any pending work to do before going to sleep. Thus, in some embodiments, if there is no work for the PCGP to do, the driver activity may wake up the system, and therefore the PCGP, and thus the PCGP does not need to make a call to “packetProcessor” or “decrement timeout” until a new packet enters the system. In some embodiments, failure to do this may result in a timeout condition dropping a message that should have been successfully sent / forwarded / received. d) Applications should not hold onto received messages indefinitely. The messaging system relies on prompt replies. If an application shares a PCGP buffer, holding onto a message means holding onto the PCGP buffer. In some embodiments, a receiving node's reception is unaware that the sending node has timeouts configured for slow or fast wireless communication. This means that a node should measure the network's fast timeout rate in response to receiving a message, and / or e) The application may frequently call "packetProcessor". In some embodiments, the call may cause the application to send new messages that have been queued, or to handle the receipt of new messages. The call may also cause buffer reallocation, and if not called too frequently, it may delay message traffic.

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

[0082] The PCGP RX overhead may consist of requesting the next available buffer and calling the root function. An unrestricted implementation of code that performs such functions is as follows: @ Receive Request uint8 i = 0, *p; if (Bridge::canReceiveFlowControl() ) { p = Bridge::nextBufferRX(); while (not done) { p[i] = the next byte;} Bridge::route(p); }

[0083] The driver may perform a TX by requesting a pointer to the next buffer to send from the buffer manager. The TX driver may then ask the other side of the interface whether it can receive the packet. If the other side rejects the packet, the TX driver does nothing to the buffer because its state has not changed. Otherwise, the driver may send the packet and recycle / release the buffer. An unrestricted implementation of code that performs such a function is as follows: uint8 *p = Bridge::nextBufferTX(); if (p != (uint8 *)0) { Send the drug p; Bridge::recycle(p); }

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

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

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

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

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

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

[0090] In some embodiments, PCGP may work with a flow control system, which may negotiate the forwarding of messages from one node to another so that buffers are never dropped, as buffers are missing on the other side of the interface (which can cause back pressure on the transmitting node).

[0091] 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. The two bytes may be used such that one byte is the DMA length minus one and the second byte controls the flow of the message. These same two bytes may synchronize the bytes when the PCGP message is transmitted over RS232. Various other configurations and sizes may be used in various embodiments.

[0092] In some embodiments, when a packet is "in flight," it may be in a process of being sent by a driver, processed by a destination, or returned as a response en route to its destination. Typical delays are as follows: [Table 1]

[0093] Therefore, in some embodiments, messages tend to complete the round trip quickly (e.g., <50ms), slowly (e.g., more than 1 second), or not complete at all.

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

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

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

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

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

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

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

[0101] The following exemplary implementation demonstrates how a PCGP event model can work with Nucleus to wake up the PCGP task after a Dec timeout has occurred that has generated all sent messages, replies, or NACKs. class PcgpOS : public Pcgp { virtual void schedulePacketProcessor(void) { OS_EventGrp_Set(g_RCVEvGrps[EVG_RF_TASK].pEvgHandle, RfRadioTxEvent, OS_EV_OR_NO_CLEAR); } }

[0102] The following is an event-based pseudocode driver illustrating how driver events work. The driver subdivides the Bridge and disables hasMessagesToSend and flowControlTumedOff, planning to activate the TX and RX functions if they are not already operational. class SPI_Driver : public Bridge { virtual void hasMessagesToSend() { Trigger_ISR(TX_ISR, this); } virtualvoidflowControlTurnedOff() { Trigger_ISR(RX_ISR, this); } static void TX_RetryTimer() { Trigger_ISR(TX_ISR, this); } static voidTX_ISR(Bridge* b) { DisableISRs(); do { uint8 * p = b->nextBufferTX(); if (p == null) break; if (b->_bufferManager->bufferTimedOut(p)==false) { if (OtherSideSPI_FlowControl() == false) { Trigger TX_RetryTimer in 20 msec. break; } send(p); } free(p); }while (true); ESIRs(); } static void RX_ISR(Bridge * b) { DisableISRs(); do { uint8 * p = b->nextBufferRX(); if (p == null) break; uint i; while (not done receiving) p[i++] = getChar(); b->route(p); } while (true); ESIRs(); } }

[0103] There are no restrictions, but one or more statistics may be supported by PCGP. • Number of packets sent · Number of packets received ·CRC error ·timeout • Unavailable buffer (buffer is gone)

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

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

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

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

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

[0109] As shown in Figure 8P, the pcgpOS.cpp file may create instances of PCGP node instances (Pcgp, Bridge, etc.) and may provide a set of C-linkable function calls through pcgpOS.h that provide a C language interface to C++ code. This simplifies the implicit nature of the C code as the object being acted upon. In some embodiments, the following general rules may apply. PCGP may operate on all nodes. Any driver may support a general driver interface. • Race conditions do not need to be allowed. Half-duplex support may be provided on the SPI port between the slave processor and the master processor. Data transfer may not be attempted, as it will either succeed or fail / false. • Low overhead (wasted time, processing, bandwidth) may be required. • Support for the CC2510 operating at a DMA (high-speed) SPI clock ratio may be provided.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0124] Furthermore, in some embodiments, if the user anticipates separating the remote interface 802 from the device 800, the user may configure the device 800 and the remote interface 802 into a "separated" mode, thus eliminating the occurrence of the aforementioned "separation" alarm. However, in some embodiments, when the remote interface 802 and the device 800 return to a state of communicating with each other, they may continue to send "ping" messages to each other so that the device 800 and the remote interface 802 can be automatically released from the "separated" mode.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0146] As discussed above (and referring temporarily to FIGS. 1A-5I), various embodiments and components of the infusion pump system may be configured using the remote interface 802 (see FIGS. 6-8). When configurable via the remote interface 802, the infusion pump 800 enables communication (e.g., wired or wireless) between the infusion pump and, for example, the remote interface 802, and thus, the remote interface 802 may include a telemetry circuit (not shown) that enables it to communicate remotely with the infusion pump 800. Various embodiments of the remote interface 802 (which may similarly include a telemetry circuit (not shown) and may be communicable 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.

[0147] As used herein, the term "remote interface" refers to any embodiment of a remote interface. However, the embodiment shown in FIG. 8 is used hereinafter for illustrative purposes only, and the description is not limited to that embodiment of the remote interface shown in FIG. 8.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0164] The following 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. #include “ManagedFunc.h” / / The SendGoodFunc is a “heartbeat” status message class SendGoodFunc : public ManagedFunc { public: / / Initialize the managed func to run 2 seconds after start up / / and repeat every second. SendGoodFunc(): ManagedFunc(IPC_SEND_GOOD,SCHEDULED_SEC, 1, true, 10) {}; ~SendGoodFunc() {}; protected: void execute(void); }; void SendGoodFunc::execute(void) { / / << code to send the heartbeat >> } SendGoodFunc g _sendGoodFunc; / / to manipulate the heartbeat timing simply call: / / g_sendGoodFunc.setFuncStart(…) or g_sendGoodFunc.setRepeat(… )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0181] The maximum time to reacquire communication, including the connection request mode and the acquisition mode, 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 favorably use a fast heartbeat mode or a slow heartbeat mode setting to conserve power and minimize latency for the user. The difference between device 800 and the remote interface 802 in entering acquisition mode may be that device 800 needs to enter acquisition mode frequently enough to ensure that communication can be restored within the maximum latency. However, the remote interface 802 may be in slow heartbeat mode and vary the frequency with device 800 entering acquisition mode when a heartbeat is lost. In some embodiments, the radio of the remote interface 802 may have knowledge of user GUI interaction, but device 800 may not.

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

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

[0184] Device 800 may use a heartbeat ratio 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, though not limited to: Pairing mode • Connection mode • Acquisition mode (including the wireless serial number of the desired paired injection pump assembly 100, 100', 400, 500) • Synchronization Mode - High-Speed ​​Heartbeat • Synchronization mode - slow heartbeat • RF off mode The radios of injection pump assemblies 100, 100', 400, and 500 may support the following mode requests via a messaging system: Pairing mode Acquisition mode • RF off mode

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

[0186] 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 the remote interface 802 sends this command to both the radio of the remote interface 802 and the radio of device 800 to configure these radio settings.

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

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

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

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

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

[0192] In some embodiments, AES encryption may be used for all packets, but in embodiments using, for example, a Texas Instruments CC2510 wireless transceiver, this transceiver may not be necessary as it includes this functionality. In embodiments where AES encryption is used, a fixed key may be utilized, as a fixed key may be desirable for several reasons, including providing a quick way to enable encryption without passing the key. However, in some embodiments, key exchange may be provided within device 800. In some embodiments, the fixed key may be contained in a separate header source without any other variables besides the fixed key data, thus enabling easier management of file read access. In some embodiments, the wireless software may support one or more of the following eight modes, but is not limited to them. Pairing mode • RF off mode • Connection mode Acquisition mode • High-speed heartbeat mode • Low-speed heartbeat mode • Search and sync mode Synchronization mode All of these are schematically depicted in Figures 12B-12C.

[0193] Pairing may be a process of exchanging wireless serial numbers between the remote interface 802 and the device 800. The remote interface 802 may "pair" with the device 800 when the device 800 knows its serial number. In some embodiments, the pairing mode (one embodiment of which is schematically depicted in Figure 12D) may require that the following four messages be exchanged over the RF link (however, various embodiments may require that more, fewer, or no messages be exchanged over the RF link than those specified). • RF pairing request (broadcast from remote interface 802 to any device 800) • RF pairing acknowledgment (remote interface 802 from the device) • RF pairing confirmation request (from remote interface 802 to device 800) • RF pairing confirmation acknowledgment (from device 800 to remote interface 802)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0210] In some embodiments, particularly in those embodiments where the device is an injection pump, the radio of the remote interface 802 may communicate with only one paired injection pump 800 (except in pairing and connection modes). In some embodiments, if communication is lost, the UI processor of the remote interface 802 may use an acquisition mode (at some periodic rate limited by the power budget) to attempt to restore communication. In some embodiments, device 800 may enter acquisition mode under one or more of the following conditions, but in various other embodiments, additional conditions may trigger acquisition mode. • When wireless is off mode and acquisition mode may be requested. • When the search sync mode times out due to insufficient heartbeats.

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

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

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

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

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

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

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

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

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

[0220] In some embodiments, the wireless may be considered online when it is in the following modes: • High-speed heartbeat mode • Low-speed heartbeat mode In some embodiments, these may be the only states in which messaging system traffic may be exchanged. All other states may be considered offline.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0240] Next, referring to Figures 18 and 19, two embodiments of communication between the device, the remote interface, and the personal computer (which, in some embodiments, has access to one or more web portals and / or one or more secure web portals) are shown. In Figure 18, the remote interface 1800 communicates with the infusion pump 1802 and two other devices, which, in some embodiments, may include a blood glucose meter 1806 and a sustained glucose monitor sensor / transmitter 1804. In some embodiments, the communication is wireless and may use RF communication, for example, the RF communication protocol described above, and / or BLUETOOTH® 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 and / or by the remote interface 1800 uploading information to the internet and the personal computer 1808 downloading information from the internet.

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

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

[0243] 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, as described above, the therapeutic agent may be administered by the supervisor processor and the command processor. The actions of the reusable part are communicated to the remote interface. In order to "switch" the reusable parts (so that the reusable part on the charger becomes the reusable part in use, or vice versa), the controller, which has uploaded information from the first reusable part while it is in use, downloads various logs to 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. In one step of the process, after pump activation, in some embodiments, this is done by the user pressing a switch assembly on the reusable part while the remote interface is in connected mode. During this step, the profile and user therapeutic configuration are transferred to the second reusable pump and / or synchronized with the reusable part non-volatile memory.

[0244] Once this step is complete, in some embodiments, the second reusable part, after internalization, sends the base profile back to the remote interface so that the remote interface can verify that the base profile is correct. This step can confirm that the second reusable part has provided the correct information. In some embodiments, a display may show the base profile to the user, which the user may confirm.

[0245] Therefore, as described above regarding therapeutic administration, the infusion pump completes all decisions and controls the delivery of the infusionable fluid. The remote interface is an interface to the infusion pump and, in some embodiments, provides an improved user interface (e.g., a display screen) with various opportunities to interact with the device (e.g., the infusion pump) and / or the user.

[0246] Therapy-related information is therefore stored both on the controller and in the reusable part / infusion pump non-volatile memory. Thus, during the connection process between the reusable part and the remote interface, the remote interface may verify that the reusable part contains the updated information. If the remote interface determines that the reusable part does not contain the updated information, the remote interface updates the information and / or synchronizes the reusable part's non-volatile memory with the updated information. Therefore, in various embodiments, all therapy information and / or profiles may be stored both on the reusable part of the infusion pump and on the remote interface.

[0247] As discussed above, the device 800 (which in some embodiments is an injection pump) may be configured to deliver an injectable fluid to the user. Furthermore, the injection pump 800 may deliver the injectable fluid via injection events, which may include continuous and / or multiple injection events, and / or discrete injection events and / or single injection events. Some of the injection events may, but are not limited, include one or more of a bolus, an extended bolus, a base quantity, a transient base quantity, and a combined bolus. As is known in the art, a base injection event refers to the repeated injection of small amounts of the injectable fluid at predetermined intervals (e.g., every 3 minutes), which may be repeated, for example, by the user or by the system, until stopped. Furthermore, the basal injection ratio may be pre-programmed and may include specified ratios to pre-programmed timeframes, for example, a ratio of 0.50 units per hour from 6 a.m. to 3 p.m., a ratio of 0.40 units per hour from 3 p.m. to 10 p.m., and a ratio of 1.0 unit per hour from 10 p.m. to 6 a.m., and / or may include pre-programmed timeframes such as 0.50 units per hour, then 1.0 unit per two hours, then 0.05 units per 30 minutes. In some embodiments, the basal ratio may be pre-programmed to remain constant, for example, 1.0 unit per hour, and may not change throughout the timeframe. The basal ratio may be repeated regularly / daily and / or on specific days, unless otherwise modified. These pre-programmed basal ratios may be referred to as basal profiles.

[0248] A temporary base ratio refers to a modification of the existing base profile / base ratio during a given time frame. For example, if the existing base profile includes a ratio of 2.0 units from 6:00 AM to 10:00 AM, the temporary base ratio may be required to modify the ratio by either increasing or decreasing the ratio by 2.0 units per percentage, for example, by decreasing the ratio by 20% over a given time period, e.g., 30 minutes. In some cases, the temporary base may include a 100% modification that is either higher or lower than the base profile ratio, and therefore, in some cases, the temporary base ratio may be 0.00 units per hour during a given time period.

[0249] As is well known in the art, a bolus is a predetermined volume of fluid, typically delivered at a rate at which the device can deliver the fluid, when delivered as a bolus. In some embodiments, a predetermined volume, for example, a bolus volume of 20 units or more, may be delivered more slowly than the “normal bolus” rate, which may be desired by the user, for example, for the purpose of absorption into tissue. However, in any case, typically, the bolus event is delivered over a short time period, for example, in some embodiments, within 10 minutes or less.

[0250] Furthermore, as is known in the art, an extended bolus injection event may refer to a predetermined fluid volume delivered in repeated injections of small amounts of injectable fluid at predetermined intervals (e.g., every 3 minutes) over a predetermined time period (e.g., 3 hours). Some extended bolus injection events may include a predetermined volume of injectable fluid delivered as a bolus (i.e., a certain percentage of the total extended bolus volumes delivered as a bolus), followed by the remaining volume of the predetermined volume delivered as an extended bolus injection event (i.e., over a predetermined time period).

[0251] The extended bolus injection event may occur simultaneously with the basal injection event. In various embodiments, the simultaneous control of the delivery of various types of injection events may be as described in U.S. Patent Application No. 12 / 837,19, filed July 15, 2010, “Apparatus, Systems and Methods for An Infusion Pump Assembly” (currently U.S. Patent Publication No. US-2011-0144574, published June 16, 2011) (Patent Attorney Reference No. I23) (which is incorporated herein by reference as a whole).

[0252] Various embodiments of the infusion pump illustrated and described herein, as well as various embodiments of the infusion pump, are not limited to, but include, U.S. Patent No. 7,498,563, "Optical Displacement Sensor for Infusion Devices" issued March 3, 2009 (Patent Attorney No. D78); U.S. Patent No. 7,306,578, "Loading Mechanism for Infusion Pump" issued December 11, 2007 (Patent Attorney No. C54); PCT Application No. PCT / US2009 / 060158, "Infusion Pump Assembly" filed October 9, 2009 (current publication No. WO2010 / 042814, published April 15, 2010) (Patent Attorney No. F51WO); and U.S. Patent Application No. 13 / 076,067, "Infusion Pump Methods, Systems and Apparatus (current US Patent Publication No. US-2011-0230837, published September 22, 2011) (Patent Attorney ID I70); US Patent Application No. 13 / 121,822 "Infusion Pump Assembly" filed March 30, 2011 (current US Patent Publication No. US-2011-0208123, published August 25, 2011) (Patent Attorney ID I73); US Patent Application No. 11 / 704,899 "Fluid Delivery Systems and Methods" filed February 9, 2007 (current US Patent Publication No. US-2007-0228071-A1, published October 4, 2007) (Patent Attorney ID E70); US Patent Application No. 12 / 347,985 "Infusion Pump" filed December 31, 2008 "Assembly" (current U.S. Patent Publication No. US-2009-0299277-A1, published December 3, 2009) (Patent Attorney Reference Number G75); U.S. Patent Application No. 12 / 560,106 "Systems and Methods for Fluid Delivery" (current U.S. Patent Publication No. US-2010-0185142-A1, published July 22, 2010) (Patent Attorney Reference Number G47);This may include apparatus, methods, devices, and systems similar to or described herein, one or more of the following: U.S. Patent Application No. 12 / 837,193, “Apparatus, Systems and Methods for An Infusion Pump Assembly,” filed July 15, 2010 (currently U.S. Patent Publication No. US-2011-0144574, published June 16, 2011) (Patent Attorney Reference No. I23); and U.S. Patent Application No. 13 / 011,384, “Method and System for Shape-Memory Alloy Wire Control,” filed January 21, 2011 (currently U.S. Patent Publication No. US-2011-0300001, published December 8, 2011) (Patent Attorney Reference No. I48) (all incorporated herein by reference as a whole); and in various embodiments of various devices, remote interfaces may be used. In some embodiments, the remote interface may be a dedicated or non-dedicated device, and may include those described above with respect to Figure 6-8. However, in some embodiments, the remote interface may be, but is not limited to, the DROID RAZER by Motorola, Inc. (Schaumburg, Illinois, USA); the HTC GOOGLE Nexus One by HTC (Taoyuan 330, Taiwan); or the SAMSUNG Nexus S by SAMSUNG Corporation.The remote interface may be a multi-functional web-connected / web-enabled device, such as a GOOGLE ANDROID® type device or any other device, which may run using an open-source operating system, such as the ANDROID® operating system, and may include CASIO G'zOne Commando by CASIO COMPUTER CO., LTD. (Tokyo, Japan). In some embodiments, the remote interface may be a tablet or other personal computing device, and / or in some embodiments, the remote interface may be any so-called “smartphone” type device. Thus, in various embodiments, the remote interface may include, but is not limited to, peripheral devices such as GPS, accelerometer, telephone, web connectivity, camera, email, etc.

[0253] Next, referring again to Figures 18 and 19, in some embodiments, the remote interfaces 1800, 1900 may be, or have, the capability of a web-connected remote interface, which may include, but is not limited to, the ability to download applications, download software updates, upload information, and / or transmit information to various machines, including, but is not limited to, a web-based secure portal and / or email and / or wireless communication protocols. Thus, in various embodiments, the remote interface application may run on any corresponding device and is not limited to so-called dedicated devices. Furthermore, in some embodiments, the remote interface may be Bluetooth®-enabled or otherwise compatible to communicate with one or more devices, for example, using radio frequency ("RF") communication, which may include, but are not limited to, infusion pumps 1802, 1902 and / or continuous glucose monitor transmitters / sensors 1804, 1904 ("CGM") and / or BLUETOOTH® or other communication protocol-enabled blood glucose meters 1806, 1906 and / or any other medical devices and / or patient care devices or any other devices.

[0254] Figures 18-19 illustrate remote interfaces 1800, 1900 that communicate with personal computers 1808, 1908, infusion pumps 1802, 1902, blood glucose meters 1806, 1906 and / or CGM 1804, 1904, but in various embodiments, the remote interfaces 1800, 1900 may communicate with one or more of any one or more of any other devices, including but not limited to medical devices, personal computers 1808, 1908 (which may be a web portal in some embodiments), infusion pumps 1802, 1902, blood glucose meters 1806, 1906 and / or CGM 1804, 1904 and / or medical devices. Furthermore, in some embodiments, one or more of the personal computers 1808, 1908 (which may be a web portal in some embodiments), infusion pumps 1802, 1902, blood glucose meters 1806, 1906 and / or CGMs 1804, 1904 may also communicate with one or more of the personal computers 1808, 1908 (which may be a web portal in some embodiments), infusion pumps 1802, 1902, blood glucose meters 1806, 1906 and / or CGMs 1804, 1904, in addition to communicating with the remote interfaces 1800, 1900. In some embodiments, the remote interfaces 1800, 1900 may communicate with one or more devices not described herein, however, it should be understood that the remote interfaces 1800, 1900 may communicate with any device. Furthermore, communication may be defined as one-way and / or two-way communication. In some embodiments, the web portal may be a secure web portal.

[0255] In some embodiments, remote interface devices 1800, 1900 may share data with secure web pages / web portals / personal computers 1808, 1909. This shared data may, in some embodiments, be automatically transferred (i.e., synchronized) at predetermined and / or pre-programmed intervals. In some embodiments, data from remote interfaces 1800, 1900 is uploaded to secure web pages / web portals / personal computers 1808, 1908 by a password-protected application that ensures the information is not shared. In some embodiments, information from remote interfaces 1800, 1900 may be stored on the secure web page, and therefore the information may be downloaded to a substitute remote interface and / or a second remote interface and / or other device upon request. Thus, in some embodiments, the system allows remote interfaces 1808, 1908 to be easily replaced in the event of failure and / or loss. As discussed above, in some embodiments, the transfer of secure web pages and / or data is secured by passwords or other types of security.

[0256] Furthermore, the secure web portal / personal computer 1808, 1908 may be used by the user to review infusion pump therapy, CGM data and / or glucose meter data (and, in some embodiments, additional devices connected to either the remote interface 1800, 1900 and / or the secure web page / personal computer 1808, 1908 in the same location). Furthermore, the secure web page / personal computer 1808, 1908 may include a food library and / or user-customizable therapies customized by the user, for example on a personal computer, and then, in some embodiments, automatically synchronized with the remote interface 1800, 1900. In some embodiments, the user may edit and / or tag CGM and / or infusion pump and / or other data with events. These edits may be entered in real time, i.e., while the event is occurring or afterward. These events may then be "named" by the user in some embodiments, and in some embodiments, a therapy plan may be pre-programmed by the user for each of these events. For example, if a user is eating pizza, the user may associate a given therapy with the food being consumed, and may, though not limited, include the number of slices and the ingredients of each slice, e.g., "Sal's Pizza, cheese, 2 slices." The user may then input this into the remote interfaces 1800, 1900, and in some embodiments, the user may later design a therapy to be used when eating "Sal's Pizza, cheese, 2 slices," while reviewing CGM and / or pump and / or glucose meter data. The user may name this event, and a therapy may be associated with this name. The user may then select the "Sal's Pizza, cheese, 2 slices" event at any time, and the remote interfaces 1800, 1900 may authorize the administration of a saved therapy associated with pizza.In some embodiments, events may be linked to a food library, and so the remote interfaces 1800, 1900 may "link" food items with therapy and / or CGM and / or blood glucose meter data as the user includes items from the food library. As discussed above, changes to the software and / or profile may be made by the user using a personal computer (and / or secure web page) 1808, 1908, and these changes may be uploaded onto the remote interfaces 1800, 1900. Once these changes are uploaded from the personal computer (and / or secure web page) 1808, 1908 to the remote interfaces 1800, 1900, they may then be downloaded onto other devices connected to the remote interfaces 1800, 1900, including, but not limited to, infusion pumps 1802, 1902.

[0257] In some embodiments, rather than a web page, there may be a dedicated application on the remote interfaces 1800, 1900 that includes similar functionality to that discussed above, such as a food library and / or user-customizable therapy recommendations, which may be performed directly on the remote interface device. In some of these embodiments, the dedicated application may be updated on the remote interfaces 1800, 1900 by downloading information from a web database, which in some embodiments may be a secure web database.

[0258] Therefore, the user may perform post-event analysis and design, and / or make changes to the therapy based on the analysis. In some embodiments, the user may use this information to examine trends and modify the baseline and / or bolus profiles. In some embodiments, the analysis may be completed by a physician and / or caregiver using or through secure web pages 1808, 1908. In some embodiments, the user may “filter” the database for specific events and / or ingested foods, analyze them together with or alone with their caregiver, determine the baseline and / or bolus profiles, and link them to the specific events and / or food items. Therefore, in some embodiments, the user may use remote interfaces 1800, 1900 (or secure web pages 1808, 1908) to filter all events, for example, “Sal’s Pizza, cheese, 2 slices,” and analyze both the therapy, the time of the event, and the CGM profile and / or blood meter readings for that event.

[0259] In some embodiments, the remote interfaces 1800, 1900 may learn user habits from both the collected CGM and / or pump and / or glucose meter data and the information entered by the user. The application and / or software may recommend therapy changes, which the user may accept or reject.

[0260] In some embodiments, CGM and / or infusion pump and / or blood glucose meter data and / or event data may be delivered to a secure web portal 1808, 1908 established between the user and the user's physician and / or healthcare provider. In some embodiments, the secure web portal used by the user's physician and / or healthcare provider may be separate from the user's secure web portal. Thus, in some embodiments, the portal may require the user to accept or reject recommended changes, etc., prior to being downloaded from the secure web portal 1808, 1908 accessed by the user's physician and / or healthcare provider and / or synchronized with the remote interface 1800, 1900.

[0261] In some embodiments, CGM sensors 1804, 1904 may communicate directly with injection pumps 1802, 1902 and / or remote interfaces 1800, 1900 (see Figures 18 and 19). In some embodiments, CGM sensors 1804, 1904 may communicate with one or the other, and in some embodiments, CGM sensors 1804, 1904 may communicate with both injection pumps 1802, 1902 and remote interfaces 1800, 1900. In some embodiments, safety criticality information, such as alarms, may be communicated directly to injection pumps 1802, 1902, and the remote interfaces 1800, 1900 may simply be used as displays.

[0262] Next, also referring to Figure 7, in some embodiments, the remote interfaces 1800, 1900 may include at least one screen containing at least one accelerometer and a plurality of buttons 706, 710, which may be customizable by the user. In some embodiments, the buttons 706, 710 may be used, for example, to input information about an event and / or simply to indicate to the remote interface 524 that an event is occurring, or to directly navigate to a specific screen. In some embodiments, this information may be stored and transmitted to a secure webpage and / or other, which may include the ability to synchronize with therapy / infusion pump information and / or CGM and / or blood glucose meter information.

[0263] In some embodiments, information may be transmitted to remote interfaces 1800, 1900 for safety monitoring services. The service may perform monitoring and, when data indicates that a problem may exist, e.g., low blood glucose, and / or infusion pump warnings / alarms and / or CGM warnings / alarms have not been acknowledged, e.g., alarms / alarms but not acknowledged by the user, which may include pressing a button and / or touching a screen to acknowledge receipt of the alarm / alarm, although this is not limited to acknowledging receipt of the alarm / alarm, it may make a phone call and / or send a text (e.g., "Are you okay?") to the remote interfaces 1800, 1900. For example, in some embodiments, if the user does not respond to the service call and / or text, the service may then call emergency services and / or parents or guardians and / or emergency contacts. In some embodiments, GPS within the remote interfaces 1800, 1900 may be used to position the user and thus delegate emergency personnel to be dispatched to the user's location. In some embodiments, if the service is able to contact the parents, paramedics, or emergency contacts, the service may also transmit the current CGM and / or pump data for review.

[0264] As discussed above, in some embodiments, the remote interfaces 1800, 1900 may be web-enabled (and / or have access to a database which may be downloaded onto or accessed by the remote interfaces 1800, 1900), and in some embodiments, the user may use the remote interfaces 1800, 1900 to easily access menus and / or nutritional information. In some embodiments, this information may be "automatically entered" into a bolus calculator and / or other device to calculate carbohydrates, fat content, etc., and assist in determining appropriate therapy. In some embodiments, the actual calculations may be performed on a device (which may be an infusion pump 1802, 1902 in some embodiments), but the remote interfaces 1800, 1900 may be a user interface for the user to input information.

[0265] In some embodiments, the remote interfaces 1800, 1900, the secure web pages 1808, 1908, and the injection pumps 1802, 1902 may be encrypted using 128-bit encryption. However, in other embodiments, the encryption may differ.

[0266] In some embodiments, the remote interfaces 1800, 1900 may pair with a device, which may include an infusion pump 1802, 1902 and / or a CGM sensor 1802, 1902 532 and / or a blood glucose meter 1806, 1906, through a series of voice indications, i.e., sounds. The sounds may be individualized and / or unique for each remote interface 1800, 1900, which may increase the security when pairing the remote interfaces 1800, 1900 with the user's device. In some embodiments, pairing may be achieved using NFC (Near Field Communication), i.e., by holding the device and the remote interfaces 1800, 1900 in close proximity within a short distance, so that the two can communicate and pair, i.e., become communicative.

[0267] In some embodiments, a remote interface display / screen may show the user the actual volume delivered, along with the planned delivery trajectory. This may increase the user's awareness of the amount of fluid delivered by the infusion pump and thus enable the user to make more informed therapeutic decisions. Furthermore, the actual volume delivered may be useful for healthcare providers to fine-tune or perform adjustments to baseline levels, insulin-to-carbohydrate ratios, etc.

[0268] In some embodiments, the remote interface may appear as a normal device rather than a medical device, and therefore may include password protection required to change the therapy. For example, to open a “therapy screen” (this term may be used to refer to any screen from which any changes to the therapy can be made, including, but not limited to, insulin / drug sensitivity, carbohydrate-to-drug ratio, drug duration, baseline profile, bolus request, food library information, blood glucose screen, etc.), the user may be required in some embodiments to enter a password. In some embodiments, a fingerprint or the like may be used. In some embodiments, a “tap code,” i.e., force applied to the remote interface at intervals, may be used (for example, in embodiments where remote interfaces 1800, 1900 may include at least one accelerometer, taps of the device on a specific code may transmit information. In some embodiments, in addition to or instead of remote interfaces 1800, 1900 having at least one accelerometer, the infusion pumps 1802, 19002 may include at least one accelerometer).

[0269] In some embodiments where the remote interface is web-enabled and / or Bluetooth®-enabled, if one or more devices (e.g., CGM sensor / transmitter 1804, 1904, infusion pump 1802, 1902, blood glucose meter 1806, 1906) experience a problem, the user may directly send an engineering log for that particular device to the manufacturer. This may be desirable as it may eliminate the need for the user to mail the problematic device to the manufacturer. Upon receipt, the manufacturer may, once it has determined the cause of the problem, recommend a code or other to the user to stop an alarm or other. In some embodiments, the remote interface may include a protocol pre-programmed to send only engineering logs, and not medical information, to the manufacturer. This may ensure that the user does not unintentionally send its secure medical information to the manufacturer. Thus, in some embodiments, the remote interfaces 1800, 1900 include logs and / or information for all devices connected to the remote interfaces 1800, 1900. Therefore, device replacement may be achieved by downloading logs, user profiles, user preferences, etc., from remote interfaces 1800, 1900, so that the device can be used by the user with a minimum "setup" time, and the replacement device can function / configure in the same way as the old device that was replaced.

[0270] In some embodiments, it may be desirable to transmit a screen, for example, a "screenshot," from the remote interface 1800, 1900 to a service representative and / or manufacturer, i.e., the service representative may be able to view the screen while discussing any issues with the device, for example, via web chat and / or telephone.

[0271] In some embodiments, the manufacturer may transmit to the remote interfaces 1800, 1900 a “video” or a link to a website for instructions on device calibration. In some embodiments, the “video” or other video may also be available on the remote interfaces 1800, 1900 themselves, which, though not limited, may include videos or videos for showing / explaining and / or “step-by-step” to users and / or caregivers responding to alarms and / or other actions relating to devices 1802, 1902, 1804, 1904, 1806, 1906 and / or the remote interfaces 1800, 1900 (see, for example, Figures 29A–29F of some embodiments).

[0272] Furthermore, in some embodiments, the remote interfaces 1800, 1900 may include, but are not limited to, the ability to compile a list of authorized addresses for transmitting secure information, which may include medical information. Therefore, if a user unintentionally enters an incorrect email address or web address, etc., the remote interfaces 1800, 1900 may prevent the user from transmitting secure information without further steps, which may include, for example, entering a new address from the authorized address list. In some embodiments, modification of the list may be protected by a password or other means (e.g., tap, fingerprint).

[0273] In some embodiments, but not limited to, one or more states of the devices (i.e., CGM sensors / transmitters 1804, 1904 and / or infusion pumps 1802, 1902 and / or blood glucose meters 1806, 1906), which may include the current glucose reading, may be indicated by an earphone connected to the remote interface 1800, 1900 and / or an audio signal through a speaker on the remote interface 1800, 1900.

[0274] In some embodiments, devices 1802, 1902, 1804, 1904, 1806, and 1906 may communicate with remote interfaces 1800, 1900 using acoustic signals coupled with radio signals, so-called "thunder and flashes," to indicate the proximity of one or more of the devices. In some embodiments, a message may be transmitted by the first device to the second device using radio signals. These radio signals may also be coupled with ultrasonic "chirps," which may be used to determine and / or calculate the distance between the devices. This method may be used, for example, to ensure that messages transmitted by and / or requests made by remote interfaces 1800, 1900 are at an appropriate distance from the devices, which may indicate whether a user of the remote interfaces 1800, 1900 of the devices is sending the message, or whether another (i.e., non-user) remote interface and / or device is sending the message. This may be used by the remote interfaces 1800, 1900 to ensure the security of communication and control of one or more of the devices. For example, if a user is sending a signal / communication from its remote interface 1800, 1900 to its injection pump 1802, 1902, this can ensure that the user is wearing the injection pump 1802, 1902, since the remote interface 1800, 1900 cannot exceed a certain distance from the injection pump 1802, 1902, e.g., 4 feet. Thus, if the system determines and / or calculates that the remote interface 1800, 1900 exceeds a threshold distance from the injection pump 1802, 1902 (which in some embodiments may be predetermined and / or pre-set by either the manufacturer and / or the user, and which in some embodiments may be based, for example, on the user's own measurements and / or the length of the tubing) using the method described above, the remote interface 1800, 1900 may warn / alarm and / or notify the user.In some embodiments, the alarm / warning may also include a message indicating that an unidentified device is attempting to communicate with the injection pumps 1802, 1902. Thus, this may be one way for the remote interfaces 1800, 1900 to determine whether the communications being received and / or transmitted to devices in the system are from an "authorized device," i.e., a device that the user has incorporated into the system, i.e., a device paired with the remote interfaces 1800, 1900, and / or a device paired with another device that can be paired with the remote interfaces 1800, 1900.

[0275] In some embodiments, the method for managing communication between an unauthorized device and an authorized device may be as follows: When remote interfaces 1800, 1900 transmit a message, there is a known radio and response delay between the device and the remote interfaces 1800, 1900. For example, the delay between the time when devices 1802, 1902, 1804, 1904, 1806, 1906 receive a message and the time when they transmit a message can be measured to determine the round-trip time. This may be used to determine the distance between the remote interfaces 1800, 1900 and devices 1802, 1902, 1804, 1904, 1806, 1906. If the measured distance indicates that the distance exceeds a pre-programmed threshold, the remote interfaces 1800, 1900 may, in some embodiments, warn and / or alarm the user, for example.

[0276] In some embodiments, information uploaded from remote interfaces 1800, 1900 to the web portal / personal computer 1808, 1909 may also be synchronized with an electronic calendar, for example, Outlook Calendar or others, but not limited to these. Thus, events in the user's life may be linked to data on devices 1802, 1902, 1804, 1904, 1806, 1906 connected to the system. This may be desirable to show events that have occurred and to bring relevance and breadth to the data for analysis. Furthermore, even if the user has not entered events into remote interfaces 1800, 1900, if the events are on the electronic calendar, the events may be automatically entered along with the data for consideration and analysis. For example, if a user's calendar shows "soccer practice," but the user did not display the event on the remote interfaces 1800, 1900 during soccer practice, then, in response to data uploads from the remote interfaces 1800, 1900 to the web portal / personal computer 1808, 1908, the event "soccer practice" may be incorporated into a software program designed to facilitate viewing of information and data from the devices, for example, above an area representing data from the remote interfaces 1800, 1900, such as the amount of fluid delivered (which may be a baseline ratio) and blood glucose data, for example, data from the CGM sensor / transmitter 1804, 1904 and / or data from the blood glucose meter 1806, 1906. Thus, the user may view a representative graph showing what the user was doing at that time, along with, for example, drug delivery data, CGM, and blood glucose data.

[0277] Therefore, the user may connect the remote interfaces 1800, 1900 to the personal computers 1808, 1908 and / or, in some embodiments, upload data from the remote interfaces 1800, 1900 to a web portal or elsewhere. In some embodiments, this may be achieved during "recharging" of the remote interfaces 1800, 1900, which in some embodiments may be done using a USB connection to the personal computers 1808, 1908. In addition to charging / recharging, the remote interfaces 1800, 1900 may synchronize and / or upload / download data from the personal computers 1808, 1908 and / or the web portal. At this point, the system may determine that a software update is available for one or more of the devices and / or for the remote interfaces 1800, 1900. The user may select "Download updates," which may again be downloaded to the remote interfaces 1800, 1900 when charging, and / or at any time when the remote interfaces 1800, 1900 are connected, either directly or indirectly, to the personal computer 1808, 1908 and / or to a web portal designed specifically for the system. As discussed above, the remote interfaces 1800, 1900 are capable of communicating with various devices. Therefore, software updates may be communicated by the remote interfaces 1800, 1900 to any one or more devices. This has many advantages, including, but is not limited, the only need to connect the remote interfaces 1800, 1900 to the personal computer / web portal 1808, 1908 for both uploading data / information from all devices and / or downloading updates and / or applications from the personal computer and / or the internet / web portal to any device.This may be desirable for many reasons, including, but not limited to, the ability to efficiently and easily update all devices from a single connection, and / or the ability to view all data from all devices in one location, and / or the ability to download information and / or settings from a personal computer / web portal to any of the devices via a remote interface.

[0278] Therefore, in some embodiments, a new “remote interface” may be introduced into the system, since the personal computer / web portal may, from time to time, contain all information from all devices, including, but not limited to, remote interfaces. This may be achieved by connecting the new remote interface to the personal computer / web portal and downloading all information about the system to the remote interface. In some embodiments, this may require that the old remote interface be removed from the “authorized device” first, however, in other embodiments, the system may “allow” additional remote interfaces with permission from the user. Thus, the system includes the ability to download all information and applications to any Internet-connected and / or remote interface that is communicable to devices and connectable to the personal computer and / or web portal.

[0279] This also allows the remote interface to download any application from the internet to any device in the system. Thus, in various embodiments of the system, the user can make any device (including several parameters such as the ability to wirelessly communicate and connect to a personal computer and / or a web portal) a device that can control various devices, for example, an infusion pump and / or receive and / or control data from a CGM sensor / transmitter and / or other sample sensors and / or other devices. In some embodiments, the remote interface and / or one or more applications on the remote interface may be password protected or otherwise and paired with one or more devices, for example, an infusion pump and / or a CGM sensor and / or one or more other devices.

[0280] In some embodiments, information on a remote interface may be uploaded and / or synchronized with another device and / or computer and / or machine, including uploading data to an internet site (web portal), which may be password protected, but is not restricted. Thus, a user may access information from any device and / or download information to any device, including any device-specific application, and therefore, user information, including history, preferred settings, etc., may be downloaded to any device, but is not restricted.

[0281] In some embodiments of the system, blood glucose meters 1806, 1906 may be included, which may consist only of a fragment reader and minimal components for function, and not a user interface. In some embodiments, the blood glucose meters 1806, 1906 communicate with remote interfaces 1800, 1900, the remote interfaces 1800, 1900 displays the readings, and / or in some embodiments, the remote interfaces 1800, 1900 may include, but are not limited to, a graphical representation of the blood glucose meter 1806, 1906 readings and / or historical data, as well as user preferences, etc., and include a wider range of functions than the blood glucose meters 1806, 1906.

[0282] The system takes an exemplary form of an infusion pump system, as discussed above, but in various embodiments, the devices may be any devices, including any medical devices, and / or may be more or less than the number of devices shown in the figures.

[0283] As discussed above, in various embodiments, the remote interfaces 1800, 1900 may include a tablet computer or a multifunction web-connected / web-enabled device, for example, in some embodiments the remote interface may be a DROID RAZER. In some embodiments, one or more peripherals may be turned off and / or put to "sleep" while the remote interface is communicating with one or more devices in the system, for example, a medical device. In some embodiments, the antenna and / or wireless communication software may be modified to a dedicated version, for example, in any of the information described above or incorporated by reference. In some embodiments, the wireless communication may be one located within the remote interface device itself, for example, the BLUETOOTH® low-energy wireless communication protocol. In some embodiments, along with this communication protocol, a converter may be included to convert to a dedicated protocol on one or more devices in the system. In some embodiments, messaging may be achieved through the protocols discussed herein or similar protocols and / or using protocols from the remote interface device.

[0284] The remote interface therefore includes a display assembly, which may, in various embodiments, include a color touchscreen. In some embodiments, the remote interface also includes at least one switch assembly. In some embodiments, the remote interface includes animated “setup” instructions for one or more devices. In addition, in some embodiments, the remote interface may include alarm restore and / or alarm videos, which may include instructions to the user to check and / or confirm and / or restore from an alarm state. These videos may also include document / text instructions and / or voice instructions, which are not limited. In some embodiments, the graphical user interface may present different color backgrounds to represent different states, e.g., “red” for alarms, “blue” for idle states, “green” for delivery / action, etc. In some embodiments, one or more of the functions described above may also include sound / voice, which may also include voice instructions, beeps, etc., which are not limited.

[0285] Next, referring to Figures 20A-30, various "screenshots" are depicted, which serve as several embodiments of a graphical user interface for a remote interface for an infusion pump, for example, one of the embodiments of the infusion pump described herein. In some embodiments, a screenshot for a remote interface for a blood glucose meter is shown. In some embodiments, the screen may be used as an instruction interface.

[0286] Next, referring to Figures 20A-22H, in some embodiments, the remote interface may include video and / or photographic / graphical instructions to demonstrate to the user how to perform a certain action on the device. In some embodiments, these video and / or photographic / graphical instructions may include narration and / or audio, and / or text and documentary instructions. Figures 20A-22H include several embodiments and / or examples of embodiments of a graphical user interface (GUI) for configuring an injection pump. These embodiments are shown as illustrative screenshots, and the various embodiments are not limited to the text and / or photographs shown. Also, the order of the screenshots may differ throughout the embodiments. In addition, in some embodiments, the various screenshots may include one or more of the following buttons: “back”, “cancel”, and / or “next”. In these embodiments, on any screen, the user may choose to go back, cancel the screen, and / or proceed to the next screen. In some embodiments that include video, the video may play indefinitely until the user selects a button, such as back, stop, and / or next. In some embodiments, the buttons may be highlighted and / or unhighlighted (which may be represented as dotted lines in the figures).

[0287] Next, referring to Figures 20A-20M, graphical instructions are shown for filling the disposable portion (which may also be called a reservoir) and priming the disposable portion. Referring to Figure 20A, some embodiments include at least one screen that instructs the user to wash their hands. Some embodiments include at least one screen showing the user washing their hands and instructing the user to wash their hands with soap and water. Some embodiments may include a video showing the user washing their hands with soap and water. Referring to Figure 20B, some embodiments include at least one screen that instructs the user to remove the cover and lid of the disposable portion. In some embodiments, the screen may show a disposable portion. In this embodiment, the screen shows an embodiment of the disposable portion in the packaging and instructs the user to remove the cover and lid from the package. In some embodiments, this embodiment is a video, and in some embodiments, a graphical video shows the cover and lid being removed from the package. Next, referring to Figure 20C, some embodiments include at least one screenshot showing the base of the package being attached to the lid. In some embodiments, this embodiment is a video, and in some embodiments, a graphical video shows the base of the package being attached to the lid. Next, referring to Figure 20D, some embodiments include at least one screen showing a vial (of injectable fluid) being cleaned. In this embodiment, the screen shows an embodiment of the vial and an alcohol swab and instructs the user to clean the top of the insulin vial with the alcohol swab. In some embodiments, this embodiment is a video of the vial being cleaned with the alcohol swab. Next, referring to Figure 20E, some embodiments include at least one screen showing a syringe in the package. In this embodiment, the screen shows an embodiment of a syringe in a package and instructs the user to remove the syringe from the package and attach the needle. In some embodiments, this embodiment is a video of the syringe being removed from the package and the needle being attached. Next, referring to Figure 20F, some embodiments include at least one screen showing a syringe and a vial. In this embodiment, the screen shows an embodiment of a vial and a syringe and instructs the user to fill the syringe with an insulin supply for up to 3 days. The reservoir can hold up to 3 mL. Remove any air bubbles in the syringe. In some embodiments, this embodiment is a video of the syringe being filled with insulin from the vial.

[0288] Next, referring to Figure 30, in some embodiments, the configuration may include a syringe filled with fluid ("filled" does not necessarily mean volume, and "filled" can be used to refer to any volume of fluid loaded into the syringe and / or reservoir) and at least one screen that can show an embodiment of a remote interface placed near the syringe, held by the user and taking a photograph of the syringe. In some embodiments, the configuration is a video of the remote interface and the syringe, where the remote interface takes a photograph of the syringe. In some embodiments, at least one screen may instruct the user to take a photograph of the syringe. In some embodiments, when the user reaches this screen, the remote interface may automatically enter camera mode so that the user can then check the finder in the display assembly and take a photograph of the filled syringe. In some embodiments, the remote interface may check whether the photograph is acceptable. In some embodiments, when the remote interface enters camera mode from the “Take a picture of the filled syringe” screen, the camera mode may be “autofocus” mode, and / or in some embodiments, a dedicated camera mode designed specifically for this task, which takes a picture at a resolution such that pattern recognition software can determine the fluid level in the syringe. In some embodiments, this recognition software may be similar to software used to read 2D barcodes. In some embodiments, the camera on the remote interface may be used for other purposes, for example, to scan 2D barcodes on disposable and / or reusable portions (for example, in some embodiments, this may be used for a device paired with the remote interface), and / or to scan 2D barcodes on other peripherals that may be used in various embodiments of insulin and / or injectable fluid vials and / or systems, whether the system includes an infusion pump.

[0289] Next, referring again to Figures 31-34, in some embodiments, the base profile may be entered into the remote interface 3004 using a camera in the remote interface 3004 and a barcode 3000, which includes, but is not limited to, a 2D barcode (see item 3000 in Figure 31 and item 3002 in Figure 32 for examples thereof). In various embodiments, the 2D barcode may be generated by a prescription from the user's physician. In some embodiments, the 2D barcode may be communicated to the user, and the communication mechanism may include, but is not limited to, providing a hard copy of the 2D barcode and / or providing the 2D barcode, for example, in an email and / or on a secure web portal. In various embodiments, the camera in the remote interface 3004 reads the 2D barcodes 3000, 3002. The 2D barcode includes an embedded prescription base profile embedded within the 2D barcode, which, once read by barcode reading software, provides the information required by the remote interface and programs the base profile. Examples of information that may be included within a 2D barcode are shown as 3006 in Figure 33. The information may include, but is not limited to, one or more of the user's name, date of birth, profile type, profile expiration date, and hourly rates given by time frame. In some embodiments, if the 2D barcode includes an expiration date, the remote interface may warn / alarm the user as the expiration date approaches, so that the user may prompt their physician to enter an updated base profile 2D barcode, as discussed above. In various embodiments, once the profile expires, the remote interface may stop pumping until an updated profile prescription is entered. In various embodiments, the user may receive multiple 2D barcodes, each containing a different base profile, which may include, for example, weekdays, weekends, exercise, sick days, etc. In some embodiments, a single 2D barcode may encode two or more base profiles.In various embodiments, the aforementioned system may use 3D barcodes, and in other embodiments, the system may use QR codes®, i.e., “Quick Response Codes.” The system may be beneficial for many reasons, including, but not limited to, preventing or reducing instances of manual programming errors (e.g., copying errors may occur when a user manually enters a prescription). However, by using 2D barcodes, programming errors are eliminated, and therefore the system may be more secure than manual entry. In addition, the system may be beneficial for prescriptions that can be sent by email and / or made available to the user electronically, for example, on a secure web portal. In some embodiments, the system may require the user to enter a passcode / password before the system reads the 2D barcode. This may be beneficial to prevent the prescription barcode from being read and programmed by the wrong remote interface. In some embodiments, when the remote interface 3004 reads the 2D barcodes 3000, 3002, the remote interface 3004 may display a basic profile in graphical form for the user to review.

[0290] Next, referring again to Figure 34, in some embodiments, the remote interface 3004 may use a camera to take a graphical photograph of the base profile 3008, whether presented, for example, on paper or in electronic format. In some embodiments, the remote interface 3004 may include recognition software that can recognize the parameters of the base profile 3008 and program the base profile 3008 into the remote interface 3004 so that the intended base profile 3008 is automatically entered into the remote interface 3004. This system may be beneficial for many reasons, including, but not limited to, preventing or reducing instances of manual programming errors (for example, when a user manually enters a prescription, there may be copying errors). However, using the base profile 3008 read by the remote interface 3004 eliminates programming errors, and therefore the system may be safer than manual entry. In some embodiments, once the remote interface 3004 has read the base profile 3004, the remote interface 3004 may display the base profile 3008 in a graphical form for the user to review. In some embodiments, the system may require the user to enter a passcode / password before the system reads the base profile 3008. This may be useful in preventing the prescription base profile from being read and programmed into the remote interface without the user's consent.

[0291] Next, referring to Figure 20G, some embodiments include at least one screen that instructs the user to fill the base reservoir. In some embodiments, the screen may show an embodiment of a syringe in a filling aid within the reservoir package, and the user may be instructed to insert the syringe into the filling aid and transfer insulin to the base reservoir (the syringe is not yet removed). In some embodiments, this embodiment is a video of the syringe being inserted into the filling aid and the plunger being moved toward the base to transfer insulin to the base reservoir.

[0292] Next, referring to Figure 20H, some embodiments include at least one screen showing a syringe for removing foam from a filled reservoir. In this embodiment, the screen shows an embodiment of a syringe in a filling aid within a reservoir package, instructing the user to check the foam in the reservoir and draw any bubbles back into the syringe. In some embodiments, this embodiment is a video of the user checking the reservoir foam and drawing the bubbles back into the syringe.

[0293] Next, referring to Figure 20I, some embodiments include at least one screen showing a syringe and a “sharp object” container. In this embodiment, the screen shows an embodiment in which the user holds the syringe adjacent to the sharp object container and instructs the user to remove the syringe and discard the needle into the sharp object container. In some embodiments, this embodiment is a video of the user removing the syringe and discarding the needle into the sharp object container.

[0294] Referring to Figure 20J, in some embodiments, a screen may be included that prompts the user to enter the reservoir volume. In some embodiments, a keypad may be included, as shown in Figure 20J, and the user may touch the appropriate number buttons so that the display reflects, in some embodiments, the volume of fluid transferred to the reservoir as a unit. In some embodiments, the system may compare the entered volume with a volume determined from an image of a filled syringe. In some embodiments, if the two volumes are within an error threshold, e.g., + or -0.5 units, the system may rely on either one or the other, and in some embodiments, on user input (e.g., unit input on the keypad in Figure 20J). In some embodiments, if the difference between the two numbers exceeds a threshold, the remote interface may prompt the user to re-enter or ask "Are you sure?". This may be desirable for confirmation of the volume of fluid transferred to the reservoir.

[0295] Next, referring to Figure 20K, in some embodiments the user interface may include at least one confirmation screen along with the reservoir volume, and in some embodiments it may include a button for "Modify Reservoir Volume," which in some embodiments may lead the user to a screen for entering a different volume value, for example, the screen shown in Figure 20J.

[0296] Next, referring to Figure 20L, some embodiments include at least one screen that instructs the user to priming the disposable portion. In this embodiment, the screen shows a thumb / hand pressing down on the filling aid on the disposable portion / reservoir and a caption for the infusion set connector, instructing the user to press and hold the priming button on the filling aid until a droplet of insulin becomes visible from the infusion set connector. In some embodiments, this embodiment is a video of the thumb / hand pressing and holding the priming button on the filling aid until a droplet of insulin becomes visible from the infusion set connector.

[0297] Next, referring to Figure 20M, some embodiments include at least one screen that instructs the user to remove the filling aid. In this embodiment, the screen shows a hand rotating the filling aid on a disposable part / reservoir and instructs the user to remove the filling aid from its base and discard it by rotating the filling aid counterclockwise. In some embodiments, this embodiment is a video of a hand removing the filling aid from its base and discarding it by rotating the filling aid counterclockwise.

[0298] Next, referring to Figure 20N, some embodiments include at least one screen that instructs the user to attach the pump to the base. In this embodiment, the screen includes an illustration / caption showing the user attaching the pump to the base, which may be a close-up of "lock" and "unlock" position icons, and instructs the user to first remove the protective dust cover or charger, and then attach the pump to the base and rotate it to the locked position. The pump will play a confirmation tone once it detects that the base is in the correct position. In some embodiments, this embodiment is a video showing the first removal of the protective dust cover or charger, and then the installation of the pump onto the base and rotation to the locked position.

[0299] Next, referring to Figure 20O, some embodiments include at least one screen that instructs the user to press a pump button. In this embodiment, the screen shows the user pressing a pump button on a reusable portion and instructs the user to activate the pump by pressing and holding the pump button. The pump button will play a sound when activated. In some embodiments, this embodiment is a video of a hand activating the pump by pressing and holding the pump button.

[0300] Next, referring to Figure 20P, some embodiments include at least one screen that indicates to the user that the pump has been activated. In this embodiment, the screen displays pump vibration or sound playback to indicate to the user that the pump has been activated and instructs them to press the next button to proceed to the settings.

[0301] Next, referring to Figure 20Q, several embodiments include at least one screen that prompts the user to initiate a pump test. In this embodiment, the screen displays a warning sign instructing the user to ensure that the cannula is not connected to the tube set (the pump test will deliver a small amount of insulin). A button on the screen indicates that the user should press to initiate the pump test after following the warning.

[0302] Next, referring to Figure 20R, some embodiments include at least one screen indicating that the pump is performing a pump self-test. In this embodiment, the screen displays a warning sign instructing the user to ensure that the cannula is not connected to the tubing set (the pump test will deliver a small amount of insulin), and also indicates that the pump is performing a pump self-test. The test will generally take about one minute.

[0303] Next, referring to Figure 20S, some embodiments include at least one screen indicating that the pump test is complete. In this embodiment, the screen displays a “check mark” indicating that the test has passed (the pump and base are functioning properly) and instructs the user to press the “next” button to proceed. In some embodiments, the “back” button may be unhighlighted, and in some embodiments, this may indicate that the system suggests proceeding or pausing. Referring to Figure 20T, some embodiments include at least one screen instructing the user to insert the injection set according to the manufacturer’s instructions.

[0304] Next, referring to Figure 21A, some embodiments include at least one screen that instructs the user to attach VELCRO® to the pump. As previously stated, in some embodiments (for example, as described and illustrated with respect to Figure 3), the disposable portion may include an adhesive patch, which in some embodiments may include a VELCRO fastener system. In this embodiment, the screen shows the user touching the backing of the patch on the back of the disposable portion and instructs the user to remove the backing and attach the smaller VELCRO patch to the back of the base. In some embodiments, this embodiment is a video of the hand removing the backing and attaching the smaller VELCRO patch to the back of the base.

[0305] Next, referring to Figure 21A, some embodiments include at least one screen instructing the user to attach the VELCRO to the pump. As previously stated, in some embodiments (for example, as described and illustrated with respect to Figure 3), the disposable portion may include an adhesive patch, which in some embodiments may include a VELCRO fastener system. In this embodiment, the screen shows the user touching the backing of the patch on the back of the disposable portion and instructs the user to remove the backing and attach the smaller VELCRO patch to the back of the base. In some embodiments, this embodiment includes a video of the hand removing the backing and attaching the smaller VELCRO patch to the back of the base.

[0306] Next, referring to Figure 21B, some embodiments include at least one screen that instructs the user to attach the patch to the user's body. As previously stated, in some embodiments (for example, as described and illustrated with respect to Figure 3), the disposable portion may include an adhesive patch, which in some embodiments may include a VELCRO fastener system for attachment to the body. In this embodiment, the screen shows the backing of the larger patch and a user touching the larger patch, instructing the user to remove the backing, attach the larger VELCRO patch to their body, and then attach the pump to the VELCRO. In some embodiments, this embodiment is a video of the hands removing the backing, attaching the larger VELCRO patch to the body, and attaching the pump to the patch.

[0307] Next, referring to Figure 21C, some embodiments include at least one screen that instructs the user to remove the injection set cap. In this embodiment, the screen shows the user removing the injection set cap and instructs the user to squeeze the two tabs on the injection set and remove the protective cap. In some embodiments, this embodiment is a video of the hands squeezing the two tabs on the injection set and removing the protective cap.

[0308] Next, referring to Figure 21D, some embodiments include at least one screen that instructs the user to connect the infusion set. In this embodiment, the screen shows the user connecting the infusion set to the cannula and instructs the user to connect the infusion set to the cannula. In some embodiments, this embodiment is a video of the hand connecting the infusion set to the cannula.

[0309] Next, referring to Figure 22A, some embodiments include at least one screen for priming the cannula. In this embodiment, the screen displays the priming volume and includes a button for initiating cannula priming, verifies that the cannula priming volume is correct, and then instructs the user to press the cannula priming start button. The button on the screen indicates which button the user should press to initiate cannula priming.

[0310] Next, referring to Figure 22A, some embodiments include at least one screen for indicating ongoing cannula priming. In this embodiment, the screen displays the volume of priming delivered and the total priming volume, and includes a button for stopping priming. The screen also includes a status bar representing the volume delivered out of the total priming volume requested.

[0311] Next, referring to Figure 22B, some embodiments include at least one screen for confirming that cannula priming is complete. Referring to Figure 22D, some embodiments include at least one screen for confirming that the setup is complete and include a button for starting the basal volume. In some embodiments, this screen appears automatically after the setup is complete, which may be beneficial for several reasons, including, but not limited to, reminding the user to start the basal volume based on the injection pump.

[0312] Next, referring to Figure 23A, some embodiments include at least one screen for programming a base profile. In the embodiments shown, to program a base profile, the user inputs a ratio, which may be volume (in units of hours) in some embodiments, and a start and end time. In various embodiments, the user may create base profiles for different days of the week (e.g., a profile for Monday), and / or for weekdays, and / or for weekends, and / or for events (e.g., skiing).

[0313] Next, referring to Figure 23B, some embodiments include at least one screen for visually examining the daily baseline profile, which may include both a graphical representation of a 24-hour cycle and a display of the ratio at the time of review.

[0314] Next, referring to Figures 23C and 23D, some embodiments include at least one base profile screen, which includes buttons containing each ratio within a time range, for example, a 24-hour cycle. In some embodiments, the user may select a button that represents one of the time ranges and leads the user to a screen for editing that particular time frame. In some embodiments, the screen may also include a graphical representation of both the current base profile and the current time frame at the top.

[0315] Next, referring to Figures 24A and 24B, in some embodiments, the remote interface may be wirelessly connected to a blood glucose meter and / or include a blood glucose meter. When the user takes a blood glucose reading, in some embodiments, the screen shown in Figure 24A becomes visible automatically. In some embodiments, the screen may include buttons that automatically represent possible “tags” (the screen button shows “Lunch”) based on the time, for example, as shown in Figure 24A. However, the user may edit these tags. For example, the user may select the “Add / Edit” button, and the user may be led to a screen similar to that shown in Figure 24B. The memo and tag editing screen may include an area for custom editing (i.e., an edit box), and the user may type a comment into the edit box. The tag list may include custom tags that can be pre-programmed into user settings by the user either by using a personal computer / web portal or by using the remote interface. In some embodiments, the settings for the GUI may include a default list that can be edited.

[0316] Next, referring to Figures 25A and 25B, some embodiments may include a screen in which the user manually enters blood glucose readings, as shown in Figure 25A. In some embodiments, after entering the values ​​and selecting "Next," a label screen may be presented, for example, as shown in Figure 25B, allowing the user to select labels. The label list may include custom tags that can be pre-programmed into user settings by the user either using a personal computer / web portal or using a remote interface. In some embodiments, the settings for the GUI may include default labels that can be edited.

[0317] In some embodiments, the user interface may indicate the amount of carbohydrates the user should consume in response to the manual input of blood glucose values ​​using a screen, for example, one shown in Figure 25A. For example, if the user inputs "40 mg / dL", the system may calculate the amount of carbohydrates to treat hypoglycemia by using correction information entered in relation to the user profile (i.e., the amount of carbohydrates to be used to treat low blood glucose levels / hypoglycemia, which may be determined by the user together with their healthcare provider). In some embodiments, the remote interface may be pre-programmed to treat hypoglycemia with specific instructions, such as 15 skittles (e.g., or any other candy, i.e., glucose item) and 4 ounces of apple juice (however, in some embodiments, these may differ) (all of which may be entered into the user profile by the user through either the remote interface or a personal computer / web portal), and the user interface may show the user pictures of the foods, e.g., 15 skittles and / or 4 ounces of apple juice, in response to the input of a hypoglycemic glucose value (the value may be pre-programmed into the system). In some embodiments, the user may request additional suggestions, which may also be presented to the user on the GUI in the form of text and / or pictures. This may be desirable for many reasons, including, but not limited to, the rapid and easy treatment of hypoglycemic events (the user may quickly find out what foods to eat to treat a hypoglycemic event, and / or the user may show a picture to a friend or another person and ask them to provide the food). In some embodiments, this may be particularly beneficial in countries where the user does not speak the local language.

[0318] Next, referring to Figure 25C, some embodiments may include at least one glucose history screen, which in some embodiments may include a list of time and glucose readings. In some embodiments, additional information may be readily available on such a screen, or if the user selects a reading, another screen may be included with more details, such as the foods consumed and / or activities and / or labels and / or tags, or any other indications that the user has tagged or labeled with the reading. In some embodiments, a "Graph" tab may be accessible from the glucose screen to view a graph of blood glucose levels. In some embodiments, the graph may be bidirectional, and the user may touch a point or location on the graph that leads the user to a screen containing further details and / or time periods for input, etc. In some embodiments, the GUI may display a continuous glucose monitor (CGM), a blood glucose meter (BGM), and an infusion pump volume on the same graph.

[0319] In some embodiments, the graphical user interface may include one or more screens for programming boluses. Referring now to Figures 26A–26D, in some embodiments, the user may input and select items from the food library, which may include custom input by the user (either using a remote interface and / or downloading the food library from the web and / or completing the custom input on a personal computer and / or a web portal and downloading / synchronizing it with the remote interface) and / or default input, as discussed above. In some embodiments, the user may navigate to a food library screen (for example, in some embodiments, the screen may be similar to the screens shown in Figures 26K and 26L), select a food, and / or select a “keypad” and type the food into a search screen, which may then prompt the user to input a quantity of the food. In some embodiments, the screen may also include a display of the nutritional value of the food, which may include, for example, one or more of carbohydrates, fats, and / or calories, but not limitations. In some embodiments, if no food is selected from the food library, a confirmation screen will be shown to the user, which in some embodiments may be similar to the embodiment of the screen shown in Figure 26M.

[0320] In some embodiments, the user may input the carbohydrate amount using a keypad, which may be similar to that shown in Figure 26D. In some embodiments, once the user has entered a food item, the user may return to adding additional items using buttons similar to those shown on the screen, for example, Figure 26J, where the user may select the "Add Food / Carbohydrate" button. Once the user has added the total carbohydrates, including the food item, for the bolus, the user may select "OK," and a screen, which may be similar to that shown in Figure 26B, may indicate to the user that the remote interface has established wireless communication with the injection pump.

[0321] In some embodiments, the user may choose to enter the units of insulin required for a bolus, rather than entering carbohydrates or food items and quantities. In some embodiments, this may be achieved using a keypad screen, which may be similar to the screen shown in Figure 26N, for example. Once the user enters the required volume, the user may select "OK," and a screen, which may be similar to the one shown in Figure 26B, may indicate to the user that the remote interface has established wireless communication with the injection pump.

[0322] In some embodiments, during the bolus process, the remote interface may display a screen containing the most recent blood glucose meter results, and in some embodiments, it may also show the user the time the test was performed and the elapsed time since the test. In some embodiments, the screen may be similar to the screen in Figure 26H. In some embodiments, the screen may prompt the user to confirm whether the bolus calculator wants to use this latest glucose test for the correction portion of the bolus. In some embodiments, the user may select "No, retest," in which case the user interface may open the blood glucose meter screen. In some embodiments, the user may select "No, skip correction bolus," in which case the bolus calculator will not use the value and will not automatically redirect the user to the blood glucose meter screen. In some embodiments, the user may select "OK," and the bolus process may continue.

[0323] In any case, once the user has entered all the information they wish to input regarding the bolus, which may include, but are not limitations, one or more of the following units of carbohydrate value, food item, blood glucose value, and / or the required insulin volume, the user interface presents the user with an overview screen, which may be similar to the embodiment shown in Figure 26I, showing, in some embodiments, recommendations for each bolus category, e.g., dietary bolus (for food), corrected bolus (for glucose), the residual bolus amount (which may also be referred to as residual insulin amount or IOB in some embodiments), and the recommended total bolus. The user may adjust the total bolus to be delivered by navigating from this window, for example, by touching the "Total Bolus" area of ​​the screen and adjusting the value per unit. In some embodiments, this may be done using a keypad. In some embodiments, this may be done using a slide adjustment GUI, which may be similar to the one shown in Figure 26G. In this embodiment, the recommended total amount, e.g., 3.51 units, is shown in the "Bolus Amount Adjustment" box 2600. The user may adjust the total volume by moving slider 2602. For example, as the user slides slider 2602 to the left, the total volume in bolus volume adjustment box 2600 decreases, and the percentage of decrease is shown in bolus volume adjustment box 2600. For example, as the user slides slider 2602 to the right, the total volume in bolus volume adjustment box 2600 increases, and the percentage of increase is shown in bolus volume adjustment box 2600. This is not limited to cases where the user desires to increase or decrease the recommended bolus volume by a given percentage, for example, decreasing it by 20% before exercise and / or increasing it by 40% during illness, in which case bolus volume adjustment box 2600 may be desirable for many reasons, including making this calculation easier for the user. Once the volume to be delivered is determined, in some embodiments the user interface presents a screen that allows the user to determine ~.

[0324] However, if the user wishes to proceed from the recommendation review screen, the user may navigate using the “Next” button in some embodiments. If the user navigates from the bolus volume modification screen, the user may use the “OK” button in some embodiments. In some embodiments, the user will be led to a screen that allows the user to determine how the bolus will be delivered, i.e., normally, expanded, or combined. Next, referring to Figures 26E and 26F, the total volume of insulin to be delivered may, by default, be delivered as a normally bolus unless the user modifies it to add at least a percentage to be delivered as an expanded bolus. In some embodiments, depending on the input on the screen shown in Figure 26E, normally 2604 may include the recommended total amount, and expanded 2608 may include 0.00 units. The total units to be delivered 2606 may be shown below slider 2610. In some embodiments, both the standard 2604 and the extended 2608 may also include a percentage representing the total percentage that will be delivered in that manner, i.e., either standard or extended.

[0325] The user may adjust the total volume that can be delivered as normal 2604 and extended 2608 by moving the slider 2610. For example, as the user slides the slider 2610 to the left, the percentage of the total volume and the total volume in normal 2604 increases, and the percentage of the total volume and the total volume in extended 2608 decreases. However, as the user slides the slider 2610 to the right, for example, the percentage of the total volume and the total volume in extended 2608 increases, and the percentage of the total volume and the total volume in normal 2604 decreases. This is desirable for many reasons, but is not limited to cases where the user desires to deliver a particular percentage as extended, for example, if the user desires to deliver 80% as extended, the user may slide the slider 2610 to the right until the percentage in extended 2608 shows "80%". Furthermore, if the user desires to deliver a specific volume, for example, 1.0 unit as normal (this may be desired in many situations, but is not limited to cases where the user desires to deliver the total volume resulting from the correction bolus as normal), the user may slide the slider 2610 to the right until the volume in normal 2604 becomes 1.00 unit. In some embodiments, the direction of the slider 2610 with respect to the increase or decrease in normal 2604 and / or extension 2608 may differ.

[0326] Next, referring to Figure 26F, if any percentage or volume of the bolus is selected to be delivered as an extension, in some embodiments, a screen similar to that shown in Figure 26F may be presented to the user after selecting "Next" from the normal and extension bolus quantity screens. The user may input the amount of time for which the extension volume (from Figure 26E) should be delivered as an extension bolus. In some embodiments, as the user slides slider 2612 to the right, the time for the extension bolus increases, and as the user slides slider 2612 to the left, the time for the extension bolus decreases. In some embodiments, the direction of slider 2612 with respect to increasing or decreasing time may differ. In some embodiments, a duration screen, such as the one shown in Figure 26F, may open with a default duration, for example, one hour, and allow the user to modify it. In some embodiments, the default may be the latest programmed extended bolus.

[0327] Once the user programs a method for delivering a bolus volume, the user may, in some embodiments, select "OK," and a bolus setting review screen, similar to that illustrated in Figure 26C, may become visible. In some embodiments, the bolus setting review screen may provide the total bolus amount to be delivered, the delivery method, the total volume to be delivered normally, and the total volume to be delivered as an extension, and if there is a volume to be delivered as an extension, the duration of the extension bolus may also be indicated. The user thus has the opportunity to clearly review the bolus volume and delivery method. In some embodiments, to initiate bolus delivery, the user must "slide" the "Confirm" button. This may be desirable for many reasons, including, but not limited to, reducing the occurrence of accidental or unintentional taps of the "Confirm" button. Therefore, using the Cancel button, the action of "cancel," i.e., tapping, is a completely different action from "Confirm," i.e., sliding. Also, the location of the "Confirm" button and slide, which are in a location very different from the "Cancel" button, may prevent unintentional cancellations. Therefore, this method can reduce unintentional discontinuation and unintentional delivery when discontinuation is desired. Also, in some embodiments, the location of the "Next" or "OK" button is similar on many screens. Therefore, to prevent unintentional confirmation when a therapy change is made, in some embodiments, the system requires a different action, for example, a slide instead of a touch / tap, and in addition, in some embodiments, the start of the slide is on the opposite side from the "Next" or "OK" button.

[0328] While not limited, this method of programming bolus volume has many advantages, including the following: The user may first determine the volume of the bolus, and then subsequently determine the method of delivery. Thus, in some situations, the user may wish to deliver the food bolus portion of the total bolus as an expanded bolus and the correction portion of the total bolus as a regular bolus, as described above, it is not necessary to decide whether the bolus is "expanded" before entering, for example, carbohydrate / food and / or blood glucose values. Furthermore, the slider embodiments shown in Figures 26G, 26E, and 26F allow the user to change the percentage and view the total volume at any given time. This method, therefore, can prevent miscalculations and allow for more precise fine-tuning and customization of insulin therapy. Furthermore, regarding the user programming the duration of the extended bolus after inputting the portion of the bolus volume to be delivered as an extended bolus, the user may be less likely to "confirm" delivery before modifying the duration.

[0329] Next, referring to Figures 27A, 27B, 27C, and 27E, in various embodiments the user interface includes various opportunities for the user to discontinue an action. In some embodiments, when the "Cancel" button is pressed, another screen appears confirming that the user wishes to cancel. This may be desirable, for example, if the user unintentionally taps the cancel button, as it gives the user the opportunity to continue rather than cancel.

[0330] Next, referring to Figures 27F and 27G, in some embodiments, while a bolus is active, for example, in the above embodiments, part of the bolus may be delivered normally and part may be delivered as an extension, the user interface may include a “Delivering” screen that indicates the active delivery status. For example, in some embodiments, as shown in Figure 27F, the delivered volume and the total volume to be delivered 2716 may be shown, and the status bar 2714 represents the delivered volume as a function of the total volume to be delivered. In addition, in some embodiments, the delivery screen may also include the current base profile 2718, which may display both the profile name, e.g., "Weekdays," and a pre-programmed base rate, e.g., 0.82 units / hour.

[0331] In some embodiments, while a bolus is active, the home screen for the user interface may change to a bolus delivery status screen or a delivery screen, which in some embodiments may be similar to the delivery screen shown in Figure 27F. In some embodiments, the home screen (which in some embodiments may be similar to the delivery screen as described above) freezes and does not time out whenever an active bolus is being delivered.

[0332] In some embodiments, while the infusion pump is in delivery, the delivery screen and / or various screens of the user interface may include different splash screens and / or background screens to visually indicate to the user that delivery is taking place. In some embodiments, the background may be "green" to indicate delivery. However, this is only one embodiment, and other embodiments may be used to indicate and / or distinguish the status of the infusion pump.

[0333] Still referring to Figure 27F, in some embodiments, a “Bolus Stop” button 2720 may be included on the delivery screen while the injection pump is delivering the bolus. In some embodiments, the bolus stop button 2720 may be a different color from the rest of the screen; for example, in some embodiments, the bolus stop button 2720 may be red.

[0334] Next, referring to Figure 27G, in some embodiments, if the user selects “Stop Basal” while an active bolus is being delivered, a Stop Basal pop-up screen 2722 may appear to confirm to the user that they wish to stop the delivery of basal insulin and to remind the user that this will also stop the current bolus delivery. In some embodiments, the infusion pump may not allow the user to stop the basal unless the bolus is also stopped, which may be desirable as it may indicate that if the user wishes to stop the delivery of basal insulin, all insulin delivery should be stopped. The Stop Basal pop-up screen 2722 reminds the user that bolus delivery is in progress if they are unaware that they are selecting to initiate the process for “Stop Basal”.

[0335] Next, referring to Figures 27H and 27I, in some embodiments, if the user selects “Stop Bolus” while an active bolus is being delivered, a basal stop pop-up screen 2724 may appear to confirm to the user that they wish to stop the delivery of basal insulin. In some embodiments, the infusion pump may not allow the user to stop the bolus unless the basal is also stopped, which may be desirable as it may indicate that if the user wishes to stop the delivery of bolus insulin, all insulin delivery should be stopped. Referring to Figure 27H, in some embodiments, if the user selects to discontinue the bolus, a discontinuation confirmation screen may appear showing the delivered units 2726 of the programmed total volume.

[0336] Next, referring to Figure 28A, an embodiment of the home screen is shown. In the embodiments shown, the home screen displays several different pieces of information, and in some embodiments, the amount of information on the home screen may vary. However, in some embodiments, the home screen may include, for example, an infusion pump status display 2800 indicating that the infusion pump is delivering; an active basal profile display 2802; a remaining bolus volume display 2804; a last glucose result display 2806, including in some embodiments the time of the last result; the volume of insulin remaining in the reservoir 2808; a percentage of the remaining life of the pump battery 2810; a battery value 2814 (which may include a battery level display); the current time 2818; connection status 2816; and information of the section 2812 of the user interface in which the page exists. However, in various other embodiments, one or more of this information and / or additional information may be included.

[0337] In some embodiments, as discussed above, while the infusion pump is delivering, the screen may include a backsplash, icon, or other indicator to easily show its status, for example, the backsplash of the page may be a different color depending on the status. In some embodiments, the delivering state may be green, the glucose state may be orange, the alarm state may be red, and the idle state may be blue. In these embodiments, regardless of the screen, the status of the infusion pump may be learned by the user. Embodiments of the alarm state screen may be found in Figures 29A-29F, and embodiments of the idle screen may be found in Figure 28C. In some embodiments, when the infusion pump is idle, this indicates that there is no delivery, which in many situations may be undesirable if it is for a long time. Therefore, in some embodiments, when the infusion pump is idle, the home screen indicates the idle state 2828, and the idle state home screen includes a large button for "Start Basic" 2830.

[0338] In some embodiments, one or more screens may include icon buttons for navigating to specific screens, such as Home 2812, Glucose 2820, Bolus or Basis 2822, Logbook 2824, and / or Settings 2826. An example of one embodiment of these screens is shown as Home (Figure 29A), Glucose (Figure 28B), Insulin (e.g., Bolus or Basis) (Figures 28D-28G), Logbook (Figure 28H), and / or Settings (Figure 28I).

[0339] Next, referring to embodiments of the insulin screen, Figures 28D-28G, in some embodiments the insulin screen includes, but is not limited to, one or more buttons for a bolus calculator 2830, a bolus program 2832, a basal program 2834, and a basal stop 2836. In some embodiments the insulin screen may also include a display of the last bolus 2838, which may include volume and time, as well as a display of the currently active basal profile 2840, which may include ratio and profile name.

[0340] Next, referring to Figures 29A-29F, embodiments of an occlusion detection alarm are shown. In some embodiments, as discussed above, the alarm state may be converted to a different backsplash / background or color, i.e., the backsplash on the screen may be red to indicate the alarm state. In some embodiments, once an alarm state is detected by the system, the system may provide a series of GUI screens to help the user recover and / or confirm the alarm state. For example, in Figure 29A, in some embodiments, the screen may indicate that insulin flow is blocked and therefore an occlusion state exists. In some embodiments, the user may select “Next,” and the GUI may step-by-step explain the recommended actions to the user. For example, in some embodiments, for example, in Figure 29B, the screen may remind the user to check their blood glucose. Referring to Figures 29C and 29D, the screen may instruct the user to start a pump test (e.g., to determine whether the occlusion is in the disposable part or cannula). In some embodiments, the pump test may determine whether the disposable part has an occlusion. Before starting the pump test, in some embodiments, a screen reminds the user to disconnect from the tubing set. Next, referring to Figures 29E and 29F, in some embodiments, the system may determine that the blockage is not in the disposable section and remind the user to replace the cannula. In some embodiments, the system may automatically start a series of screens, including, in some embodiments, the aforementioned, and in some embodiments, remind the user to connect to a new cannula (and prim the new cannula, etc.). In some embodiments, if the system determines that the blockage is in the disposable section, the system may instruct the user to replace the disposable section.

[0341] Various embodiments of the system therefore include one or more devices and remote interfaces. In some embodiments, the remote interface may be configured to connect to and communicate with a web portal and / or a personal computer. In some embodiments, the remote interface may be a personal computer.

[0342] In some embodiments, the system includes a recharger and / or a device for recharging a remote interface and / or for recharging one or more devices. In some embodiments, during recharging, the device and / or remote interface may receive software updates / software downloads and / or synchronize with a database. In some embodiments, the recharger and / or charger includes a USB connection to a personal computer, and the connection may be used as a data port and / or a charging device.

[0343] In some embodiments, the system includes at least two reusable parts of an injection pump and / or other device, both of which are configured to receive information and / or communicate with a remote interface. In some embodiments, the second of the two reusable parts may be in use while the first is being recharged. The exchange from the first to the second reusable part may involve the remote interface synchronizing data with the second reusable part so that the second reusable part contains updated information when it is in use. In some embodiments, each reusable part may include non-volatile memory and full control and instruction capabilities relating to one or more processors that instruct the device. Thus, in some embodiments, the remote interface may be used as a user interface, and commands, instructions, and profiles may be entered by the user using the remote interface; however, those commands are sent to the device, and in some embodiments, after the remote interface confirms that the device has correctly received the information, the device instructs a full operation, for example, an injection pump instructs the delivery of injectable fluid.

[0344] In some embodiments, in order for the user to change use from a first reusable portion to a second reusable portion, the user may indicate to the remote interface that they wish to change the reusable portion. While in use, the first reusable portion transmits current remaining insulin amount and / or remaining bolus amount (may also be referred to as IOB) information to the remote interface. The remote interface receives this information and begins measuring time with respect to the IOB information. When the second reusable portion is connected to the remote interface, the remote interface transmits the IOB information, along with a timestamp, to the second reusable portion. The second reusable part checks the time related to the IOB information. If the reusable part finds that the timestamps do not match (which in some embodiments may indicate that the battery of the first reusable part is not functioning properly and / or was depleted when placed on the charger), a message is sent to the remote interface to inform the user that the times do not match. The user may enter the correct time and enter this time for both the remote interface and the reusable part. However, if the timestamps match, the second reusable part may rely on the IOB information, and therefore the IOB calculation can continue even while the first reusable part is being replaced with the second reusable part. In cases where the timestamps do not match, in some embodiments, the IOB information may be deleted, and the calculation starts from 0 at the new set time, and the user is notified of this using the remote interface.

[0345] A remote interface may be used to communicate with at least one device. In some embodiments, the remote interface may be used to communicate with various devices. This may be desirable for many reasons, including user-friendliness, though not limited to these. A single remote interface may be used to design its software platform, which in many embodiments is designed to be similar in nature so that a single user can learn various software / applications for various devices without significant learning time. In addition, the remote interface may download all software updates for all devices it can communicate with, either while connected to a personal computer via USB and / or while connected to a web portal, and then transfer these updates to the devices themselves. This may be beneficial for many reasons, including maintaining devices in an efficient process and updating devices in an efficient manner, though not limited to these.

[0346] In addition, in some embodiments, the user may configure various profiles and / or view various data about the device in one place using various software applications that are loaded onto a personal computer and / or can be accessed through a web portal. Changes made to the information and / or profiles may be downloaded onto a remote interface. Any relevant changes are then communicated wirelessly to the device. In some embodiments, the device itself may receive the information via a USB connection to a personal computer.

[0347] In some embodiments, the remote interface may be used to capture images to assist in controlling the device. For example, in some embodiments, the user may be instructed to use a camera on the remote interface to take a photograph of the filled syringe so that the remote interface (and the user interface) can either verify user-entered information regarding the volume of fluid in the filled syringe and / or determine the volume of fluid in the filled syringe. This can be beneficial for several reasons, including, but is not limited to, an approximately correct volume of fluid loaded into the reservoir (which in some embodiments may lead to greater user safety). In some embodiments, the infusion pump determines the volume of fluid remaining in the reservoir and alarms the user if the volume is below a specific, in some embodiments, pre-programmed volume. In these embodiments, the user may change the reservoir (i.e., replace it with a filled reservoir) before the volume is completely depleted. This thus prevents the user from suffering an event where there is no medication at all. Therefore, if the user inputs an incorrect fluid volume to be transferred to the reservoir, the calculation of the fluid volume in the reservoir may be inaccurate. This is not limited to, but if the volume of fluid transferred to the reservoir is miscalculated to be higher, the reservoir may be depleted faster than calculated, and thus undesirable for many reasons, including the user running out of medication in an unexpected manner. However, if the volume of fluid transferred to the reservoir is miscalculated to be lower, the reservoir may be depleted more slowly than calculated, and thus the user may replace the reservoir prematurely and thus discard the unused fluid.

[0348] In some embodiments, the camera may be used as described above, but the camera may also be part of the peripheral devices of the remote interface. In some embodiments, the peripheral devices may transfer images to the remote interface, and the remote interface may process the images as if they were provided by a camera on the remote interface.

[0349] While the principles of the present invention have been described herein, it will be understood by those skilled in the art that this description is merely an example and not a limitation on the scope of the invention. In addition to the exemplary embodiments illustrated and described herein, other embodiments are also conceivable within the scope of the invention. Modifications and substitutions by those skilled in the art are also considered to be within the scope of the invention.

Claims

[Claim 1] The invention described in the drawings of this application.

Images