Device, method, and system for wirelessly controlling medical device

Abstract

To provide a device, a method, and a system for wirelessly controlling a medical device.SOLUTION: There is provided a medical device system. The medical device system includes a first medical device and a second medical device. It also includes a remote interface including a touch screen. The remote interface performs wireless communication 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 touch screen.SELECTED DRAWING: None

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 technology]

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

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

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

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

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

[0007] Some embodiments of this aspect of the invention may include one or more of the following: The first medical device is an infusion pump. The first medical device further includes at least one disposable part and at least two reusable parts, each of the two reusable parts configured to connect to the at least one disposable part. The charging device is configured to receive at least one of the at least two reusable parts of the first medical device. The second medical device is a continuous glucose monitor system including at least one transmitter, the at least one transmitter in wireless communication with the remote interface. The system further includes a third medical device in wireless communication with the remote interface. The remote interface is configured to provide a user interface to the third medical device. The third medical device is at least one blood glucose meter. In the system further, the wireless communication is radio frequency communication. The first medical device and the remote interface are paired using short-range communication. And / or the remote interface further includes 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 that wirelessly communicates with the first medical device. The system also includes a remote interface including a touch screen. The remote interface wirelessly communicates with the first medical device, and the remote interface is configured to provide a user interface to the first medical device and the second medical device. The remote interface is configured to receive user input through the touch screen. The system also includes a charging device configured to receive the first medical device and the remote interface. The charging device is configured to recharge the first medical device battery, and the charging device is configured to recharge an interface battery in the remote interface. The charging device is connected to a personal computer, and the personal computer provides information to the remote interface.

[0009] Some embodiments of this aspect of the invention may include one or more of the following: The first medical device is an infusion pump. The first medical device further includes at least one disposable part and at least two reusable parts, each of the two reusable parts configured to connect to the at least one disposable part. The charging device is configured to receive at least one of the at least two reusable parts of the first medical device. The second medical device includes a continuous glucose monitor system including at least one transmitter, the at least one transmitter wirelessly communicating with the first medical device. The second medical device includes a blood glucose meter wirelessly communicating with the first medical device. The first medical device and the remote interface are paired using short-range communication. The first medical device and the second medical device are paired using short-range communication.

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

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

[0012] According to one aspect of the present invention, an infusion pump system is disclosed that includes an infusion pump and a remote interface device in wireless communication with the infusion pump that includes instructions for controlling the infusion pump, the instructions may be synchronized with a secure web portal.

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

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

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

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

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

[0019] These and other features and advantages of the present invention will be better understood by reading the following detailed description taken in conjunction with the drawings. For example, the present specification provides the following: (Item 1) 1. A medical device system comprising: A first medical device; a second medical device; and a remote interface comprising a touch screen, the remote interface wirelessly communicating with the first medical device and the second medical device, the remote interface configured to provide a user interface to the first medical device and the second medical device, the remote interface configured to receive user input through the touch screen; a charging device configured to receive at least the first medical device and the remote interface, the charging device configured to recharge a first medical device battery, the charging device configured to recharge an interface battery in the remote interface, the charging device connected to a personal computer, the personal computer providing information to the remote interface; and A system comprising: (Item 2) 2. The system of claim 1, wherein the first medical device is an infusion pump. (Item 3) 3. The system of claim 2, wherein the first medical device further comprises at least one disposable part and at least two reusable parts, each of the two reusable parts configured to connect to the at least one disposable part. (Item 4) 4. The system of claim 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) 2. The system of claim 1, wherein the second medical device is a continuous glucose monitor system including at least one transmitter, the at least one transmitter wirelessly communicating with the remote interface. (Item 6) 2. The system of claim 1, further comprising a third medical device in wireless communication with the remote interface. (Item 7) 7. The system of claim 6, wherein the remote interface is configured to provide a user interface to the third medical device. (Item 8) 8. The system of claim 7, wherein the third medical device is at least one blood glucose meter. (Item 9) 2. The system of claim 1, further comprising: the wireless communication being radio frequency communication. (Item 10) 2. The system of claim 1, wherein the first medical device and the remote interface are paired using short-range communication. (Item 11) 2. The system of claim 1, wherein the remote interface further comprises at least one camera. (Item 12) 1. A medical device system comprising: A first medical device; a second medical device in wireless communication with the first medical device; a remote interface comprising a touch screen, the remote interface in wireless communication with the first medical device, the remote interface configured to provide a user interface to the first medical device and the second medical device, the remote interface configured to receive user input through the touch screen; a charging device configured to receive the first medical device and the remote interface, the charging device configured to recharge a first medical device battery, the charging device configured to recharge an interface battery in the remote interface, the charging device connected to a personal computer, the personal computer providing information to the remote interface; and A system comprising: (Item 13) Item 13. The system of item 12, wherein the first medical device is an infusion pump. (Item 14) Item 14. The system of 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 configured to connect to the at least one disposable part. (Item 15) Item 14. The system of 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) 13. The system of claim 12, wherein the second medical device comprises a continuous glucose monitor system comprising at least one transmitter, the at least one transmitter communicating wirelessly with the first medical device. (Item 17) 13. The system of claim 12, wherein the second medical device comprises a blood glucose meter that wirelessly communicates with the first medical device. (Item 18) Item 13. The infusion pump system of item 12, wherein the first medical device and the remote interface are paired using short-range communication. (Item 19) Item 13. The infusion pump system of item 12, wherein the first medical device and the second medical device are paired using short-range communication. (Item 20) 1. An infusion pump system comprising: at least one disposable portion of the infusion pump; at least two reusable parts of an infusion pump, each of the two reusable parts of the infusion pump configured to connect to the at least one disposable part; a remote interface comprising a touch screen, the remote interface in wireless communication with at least one of the at least two reusable parts, the remote interface configured to provide user instructions to the at least one of the at least two reusable parts, the remote interface configured to receive user input through the touch screen; a charging device configured to receive the at least two reusable parts and at least one of the remote interface, the charging device configured to recharge a pump battery of the at least one of the at least two reusable parts, the charging device configured to recharge an interface battery in the remote interface, the charging device connected to a personal computer, the personal computer providing information to the remote interface; and An infusion pump system comprising: (Item 21) 21. The infusion pump system of claim 20, further comprising a continuous glucose monitor system comprising at least one transmitter, the at least one transmitter in wireless communication with the remote interface. (Item 22) 21. The infusion pump system of claim 20, further comprising at least one blood glucose meter, said blood glucose meter in wireless communication with said remote interface. (Item 23) 21. The infusion pump system of claim 20, wherein the at least one reusable part and the remote interface are paired using short-range communication. (Item 24) 21. The infusion pump system of claim 20, wherein the remote interface further comprises at least one accelerometer. (Item 25) 21. The infusion pump system of claim 20, wherein the remote interface further comprises at least one camera. [Brief description of the drawings]

[0020] [Figure 1A] FIG. 1A is an exploded view of one embodiment of an infusion pump. [Figure 1B] FIG. 1B is an exploded view of an embodiment of an infusion pump. [Diagram 2] FIG. 2 is an exploded view of an embodiment of the infusion pump and second reusable part. [Diagram 3] FIG. 3 is a perspective view of one embodiment of the infusion pump disposable showing the external infusion set. [Figure 4] 4A and 4B depict one embodiment of an infusion pump. [Figure 5A] 5A-5C depict one embodiment of an infusion pump. [Figure 5B] 5A-5C depict one embodiment of an infusion pump. [Figure 5C] 5A-5C depict one embodiment of an infusion pump. [Figure 5D] FIG. 5D is an exploded view of an embodiment of the reusable portion. [Figure 5E] FIG. 5E is an exploded view of an embodiment of the reusable portion. [Figure 5F] FIG. 5F is an exploded view of an embodiment of the reusable portion. [Figure 5G] 5G-5I show one embodiment of the dust cover. [Figure 5H] 5G-5I show one embodiment of the dust cover. [Figure 5I] 5G-5I show one embodiment of the dust cover. [Figure 6] FIG. 6 is a diagram of one embodiment of a remote interface. [Figure 7A] FIG. 7 is a diagram of one embodiment of a remote interface. [Figure 7B] FIG. 7 is a diagram of one embodiment of a remote interface. [Figure 8]FIG. 8 is a diagram of one embodiment of the system. [Figure 8B] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8C] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8D] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8E] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8F] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8G] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8H] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8I] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8J] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8K] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8L] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8M] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8N] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8O] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8P] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8Q] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 8R] 8B-8R depict various views of a high-level schematic and flow diagram of one embodiment of the system. [Figure 9A] FIG. 9A diagrammatically depicts one embodiment of a multi-processor control configuration that may be included within one embodiment of the present device. [Figure 9B] FIG. 9B diagrammatically depicts an embodiment of a multi-processor control configuration that may be included within an embodiment of the present device in some embodiments. [Figure 10A] 10A and 10B diagrammatically depict one embodiment of multi-processor functionality. [Figure 10B] 10A and 10B diagrammatically depict one embodiment of multi-processor functionality. [Figure 11] FIG. 11 diagrammatically depicts one embodiment of multi-processor functionality. [Figure 12] FIG. 12 diagrammatically depicts one embodiment of multi-processor functionality. [Figure 12A] 12A-12E diagrammatically depict various software layers, according to one embodiment. [Figure 12B] 12A-12E diagrammatically depict various software layers, according to one embodiment. [Figure 12C] 12A-12E diagrammatically depict various software layers, according to one embodiment. [Figure 12D] 12A-12E diagrammatically depict various software layers, according to one embodiment. [Figure 12E] 12A-12E diagrammatically depict various software layers, according to one embodiment. [Figure 13] FIG. 13 is an illustration of one embodiment of the system. [Figure 14] FIG. 14 is an illustration of one embodiment of the system. [Figure 15] 15A-15B are illustrations of an embodiment of a charging station in one embodiment of the system. [Figure 16A] 16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 16B] 16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 16C] 16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 16D] 16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 16E] 16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 16F] 16A-16F depict various views of an embodiment of a battery charger / charging station, according to one embodiment of the system. [Figure 17] FIG. 17 diagrammatically depicts one embodiment of the interconnection of the various elements of the system. [Figure 18] FIG. 18 is an illustration of one embodiment of the system. [Figure 19] FIG. 19 is an illustration of one embodiment of the system. [Figure 20A] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20B] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20C]20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20D] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20E] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20F] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20G] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20H] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20I] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20J] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20K] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20L] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20M] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20N] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20O]20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20P] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20Q] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20R] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20S] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 20T] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 21A] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 21B] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 21C] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 21D] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 22A] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 22B] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 22C]20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 22D] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 23A] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 23B] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 23C] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 23D] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 24A] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 24B] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 25A] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 25B] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 25C] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26A] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26B]20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26C] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26D] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26E] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26F] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26G] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Fig. 26H] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26I] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26J] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26K] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26L] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26M] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 26N]20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 27A] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 27B] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 27C] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 27E] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 27F] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 27G] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Fig. 27H] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 27I] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 28A] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 28B] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 28C] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 28D]20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 28E] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 28F] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 28G] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Fig. 28H] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 28I] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 29A] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 29B] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 29C] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 29D] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 29E] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Figure 29F] 20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Diagram 30]20A-30 are embodiments of various screenshots of a remote interface according to one embodiment of the system. [Diagram 31] FIG. 31 is an embodiment of a 2D barcode. [Diagram 32] FIG. 32 is an embodiment of a system for programming a basal profile using a remote interface and a 2D barcode. [Diagram 33] FIG. 33 is an embodiment information that may be embedded within a 2D barcode. [Diagram 34] FIG. 34 is an example of a basal profile that can be programmed into the remote interface using the camera. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0023] "Device" includes, but is not limited to, medical devices, including, but not limited to, infusion pumps and / or microinfusion pumps, drug delivery pumps and / or apparatus, sensors, measurement devices and / or gauges, blood pressure monitors, ECG monitors, pill dispensers, pulse oximetry monitors, CO 2 "medical device" shall mean any medical device, including capnometers, drip bags, drip flow meters, temperature monitors, peritoneal dialysis machines (including but not limited to home peritoneal dialysis machines), hemodialysis machines (including but not limited to home hemodialysis machines), and any other medical device or devices configured to deliver, handle, and / or determine medical care.

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

[0025] A "button" in the context of inputs such as the so-called "bolus button" discussed below may be any type of user input capable of performing the desired function, including but not limited to a push button, slider, switch, touch screen, and / or jog wheel.

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

[0027] "Fluid" shall mean a substance capable of flowing through a flow line or fluid line, e.g., a liquid.

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

[0029] "Cannula" is intended to mean a disposable device capable of injecting fluid into a user. Cannula, as used herein, may refer to a conventional cannula / flexible tube or a needle.

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

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

[0032] "Acoustic volume measurement" is intended to mean quantitative measurement of associated volumes using acoustic techniques such as those described in U.S. Patent Nos. 5,349,852 and 5,641,892, and U.S. patent application Ser. No. 11 / 704,899 entitled "Fluid Delivery Systems and Methods," filed February 9, 2007, now U.S. Patent Publication No. US-2007-0228071-A1, published October 4, 2007 (Attorney Docket No. E70), and U.S. patent application Ser. No. 12 / 347,985 entitled "Infusion Pump Assembly," filed December 31, 2008, now U.S. Patent Publication No. US-2009-0299277, published December 3, 2009 (Attorney Docket No. G75), each of which is incorporated herein by reference in its entirety, as well as other techniques.

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

[0034] Some embodiments of the device are adapted for use by people with diabetes and / or their caregivers. Thus, in these embodiments, the devices, methods and systems cooperate to deliver insulin that complements or replaces the action of islet beta cells in people with diabetes (referred to as users). The embodiments adapted for insulin delivery seek to replace the action of islet beta cells by providing both a basal level of fluid delivery as well as a bolus level of fluid delivery. The basal, bolus levels and timing may be set by the user by using a remote interface user interface or directly by using a user interface on the device. Additionally, the basal and / or bolus levels may be triggered or adjusted in response to the output of one or more glucose meters and / or glucose monitors (i.e., devices), which in exemplary embodiments may be integral with or in wireless communication with the remote interface. In other embodiments, the remote interface may include one or more analyte monitoring devices, which may include, but are not limited to, a blood glucose meter / device that receives a blood sample and / or a device configured to receive a blood sample, e.g., a blood glucose strip. In some embodiments, the bolus may be triggered by the user using a designated button or other input means located on the device, i.e., on the infusion pump and / or on the remote interface. In still other embodiments, the bolus or basal may be programmed or managed through a user interface located either on the device (e.g., on the infusion pump and / or on the remote interface).

[0035] With regard to the names given to screens and types of screens herein, as well as suitable names given to various features throughout the various embodiments, these terms may vary and are for explanatory purposes; the description is not limited to these names.

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

[0037] Infusion pumps contemplated by this description include pumps that can pump any fluid, including, but not limited to, therapeutic fluids (including, but not limited to, insulin). Thus, when this description describes an embodiment with respect to insulin, this is meant merely for illustrative purposes and is not intended to be limited to insulin. Other fluids are also contemplated. In some embodiments, the methods, systems, and devices described herein may be used in conjunction with other fluid delivery devices, such as pens and / or syringes known in the art.

[0038] The system for controlling the device described herein may be used for any one or more devices, and in some embodiments, the device may include an infusion pump and / or an infusion pump system that may deliver fluid and / or may be configured to deliver fluid to a user through a cannula. For illustrative purposes only, an infusion pump system is described herein that may include at least one insulin pump. 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] 1A and 1B, one embodiment of device 100 is shown. Device 100 is an infusion pump, which in an illustrative embodiment may be any infusion pump, however, in some embodiments may be one of the infusion pump embodiments shown and described in U.S. Publication No. US-2007-0228071 (E70), published October 4, 2007, or U.S. Publication No. US-2009-0299277-A1 (Attorney Docket No. G75), published December 3, 2009. However, as discussed above, in various other embodiments, the device may be any medical device, and in some embodiments, one or more devices are included within a system.

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

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

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

[0043] Next, and referring also to FIG. 2, in some embodiments of the system, the system may include one or more devices, and in some embodiments, the system may include two devices 200, 202. In some embodiments of the system, the system may include two reusable parts 200, 202 and at least one disposable part 204. The reusable parts 200, 202 and the disposable part 204 may in some embodiments be embodiments of the device 100 described above. In some embodiments of the system, the system may include two reusable parts 200, 202, each of which may include a rechargeable power device, e.g., a rechargeable battery. Thus, in some embodiments, one reusable part 200 is connected to the disposable part 204 and is used by a user, while the other reusable part 202 may be recharged. Thus, in some embodiments, the system may include a backup device that may be recharged or serviced while the other device is in use.

[0044] 3, in some embodiments, the disposable part 300 includes tubing 302, which may include a male connector 304 connected to the tubing 302. The male connector 304 is configured to be connected to a female connector 306, in some embodiments. The envisioned connection of the male connector 304 and the female connector 306 provides a fluid path from the tubing 302 to the cannula 308, and thus from the reservoir to the cannula. The cannula 308 may be held in place on the user by a cannula adhesive pad 310. The tubing 302, the male connector 304, the female connector 306, the cannula 308, and the cannula adhesive pad 310 may be collectively referred to as an infusion set 312. In some embodiments, the reusable part 300 may be held on the user by a patch 314, which in some embodiments may be, for example, a disposable adhesive patch (connected to the underside surface of the disposable part 300, where an adhesive may be exposed and then attached to the user) or a hook-and-loop patch. In embodiments in which the disposable patch is a hook-and-loop patch (such as, for example, the hook-and-loop system offered by VELCRO USA Inc., Manchester, NH), the lower surface of the disposable portion 300 may include a complementary hook or loop surface.

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

[0046] 5A-5F, the electrical control assembly 516 may include a printed circuit board 530 and a battery 532, which in some embodiments may be a rechargeable battery. The printed circuit board 530 may include various control electronics for monitoring and controlling the amount of infusible fluid that has been pumped and / or is being pumped. For example, the electrical control assembly 516 may measure the amount of infusible fluid just dispensed and determine whether sufficient infusible fluid has been dispensed based on the dose requested by the user. If sufficient infusible fluid has not been dispensed, the electrical control assembly 516 may determine that more infusible 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 doses may be pumped, or the electrical control assembly 516 may provide an appropriate signal to the mechanical control assembly 512 so that an additional dose may be dispensed with the next dose. Alternatively, if too much infusible fluid is dispensed, the electrical control assembly 516 may provide an appropriate signal to the mechanical control assembly 512 so that less infusible 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 (which may include, for example, but is not limited to, a CC2510 microcontroller / radio frequency ("RF") transceiver available from Chipcon AS, Oslo, Norway) may be dedicated to wireless communication for communicating with a remote interface. Two additional microprocessors (examples of which may include, but are not limited to, the MSP430 micro remote interface available from Texas Instruments Inc., Dallas, Texas) may be dedicated to issuing and executing commands (e.g., to dispense a dose of infusible fluid, to process feedback signals from a volumetric measuring device, and the like).

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

[0048] The locking ring assembly 506 may include grip inserts 540, 542, which may include, for example, an elastomer or textured material, that may facilitate gripping and twisting of the locking ring assembly 506 to engage / disengage the reusable part 500 and the disposable part 504. Additionally, the locking ring assembly 506 may include one or more sensing components, which in some embodiments may be a magnet 544, but in other embodiments may be electrical contacts or other sensing components. In various embodiments, the sensing components may interact with one or more components of the reusable part 500 (e.g., a Hall effect sensor) to provide, for example, an indication of the nature of the mating components (which in some embodiments may include, but are not limited to, one or more of the disposable part 504, the charging station, or the filling station) and / or whether the reusable part 500 is properly engaged with the mating components. In some embodiments, 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. Thus, in some embodiments, the Hall effect sensor in conjunction with the magnet 544 may provide a system for determining whether the locking ring assembly 506 has been rotated to the closed position.

[0049] The sensing component (magnet) 544 may cooperate with the reusable portion components, i.e., in some embodiments, a Hall effect sensor, to provide a determination of whether the reusable portion 500 is properly attached to an intended component or device. In some embodiments, the locking ring assembly 506 may not pivot when not attached to a component, which may include, but is not limited to, the disposable portion 504, a dust cover (not shown), or a battery charger (not shown). Thus, the sensing component 544 may function in conjunction with the reusable portion 500 to provide a number of advantageous safety features to the infusion pump system. These features may include, but are not limited to, one or more of the following: If the system does not detect that the disposable portion 504, dust cover, or charger is attached, the system may inform, warn, or alarm the user that the reusable portion 500, e.g., valves and pumping components, may be contaminated or damaged, compromising the integrity of the reusable assembly. Thus, the system may provide an integrity alarm to alert the user to a potential reusable integrity threat. Also, if the system senses that the reusable assembly is attached to the dust cover, the system may power off or reduce power to conserve power, which may provide more efficient use of power when the reusable parts are not connected to configurables that need to interact.

[0050] The reusable part 500 may be attached to a number of different components, including, but not limited to, a disposable housing assembly, a dust cover, or a battery charger / battery charging station. In either case, the Hall effect sensor may detect that the locking ring assembly 506 is in the closed position and thus the reusable part 500 is removably engaged to the disposable part 504, the dust cover, or the battery charger / battery charging station (or, in various embodiments, another component). The infusion pump system may determine the component attached thereto by using an AVS system, such as those described in the aforementioned referenced patent publications and patents, or by electronic contacts. Now and referring to FIGS. 5G-5I, one embodiment of a dust cover (e.g., dust cover 539) is shown. In an exemplary embodiment, the dust cover 539 may include features 541, 543, 545, 547 such that the locking ring assembly 506 of the reusable part 500 may be removably engaged to the dust cover 539. In addition, the dust cover 539 may further include a recessed area 5849 to accommodate the valving and pumping features of the reusable part 500. For example, with respect to the dust cover, the AVS system may determine that the dust cover is connected to the reusable part, but not the disposable part. The AVS system may use a look-up table or other comparison data to compare the measurement data with the characteristic dust cover or the empty disposable part data to differentiate. With respect to the battery charger, the battery charger may include electrical contacts in some embodiments. When the reusable part is attached to the battery charger, the infusion pump assembly electronic system may sense that contact has been made, and thus will indicate that the reusable part is attached to the battery charger.

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

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

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

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

[0055] Where the system requires interaction between a user and the device, the interaction may be accomplished using an input either on the remote interface or on the device; for example, in some embodiments, where the device is an infusion pump, the input on the device may be a switch assembly on the infusion pump.

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

[0057] 6 and 7A-7B, in some embodiments of the infusion pump system, the infusion pump may be remotely controlled using a remote interface 600, 700. Two embodiments of the remote interface are shown, however, in various other embodiments, the remote interface may be any type of device capable of interacting with the device, including via wireless and / or remote communication. The remote interface 600, 700 may include all or a portion of the functionality of a device, which in some embodiments may include an infusion pump similar to that shown and described herein with respect to FIGS. 1A-5I. As discussed above, for purposes of explanation, the device may be described as an infusion pump, however, the present disclosure is not limited to infusion pumps. Also, the systems, methods, and apparatus described herein may be used in conjunction with any device.

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

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

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

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

[0062] In various embodiments of the user interface, the user interface may request user confirmation and / or user input. In some embodiments, the user interface is focused on ensuring that the effects of various interactions with the device are understood. Many examples will be presented throughout this description of devices that communicate the results of the user's actions to the user. These features ensure that the user understands their actions and therefore provide additional safety to the user. One such example is that if the user presses the back button on a screen after a value has been changed, the user interface may display a confirmation screen that reads "Cancel changes?" If the user selects "Yes", in various embodiments, the user interface discards any pending changes, closes the confirmation screen, and returns to the previous screen (i.e., the screen before the screen where the user pressed the back button). When the action selection is "No" on the "Cancel changes?" confirmation screen, the user presses the return button or other, depending on the embodiment, and the user interface closes the confirmation screen and returns to the screen with the pending changes. This feature prevents the user from assuming that changes have been implemented when in fact they have not. Thus, this feature prevents such a situation and ensures that the user understands that changes have not been implemented. This is just one of many examples of a user interface that requests user confirmation and / or input.

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

[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 limits, e.g., delivery limits, and / or establish user preferences. In some embodiments, the remote interface 802 may allow a user to view the status of the device, which may include power status, delivery status, values ​​read, alarm status, progress of the device, and / or any other data that may be communicated from the device to the remote interface 802. In some embodiments, the remote interface 802 may include a glucose strip reader and / or a temperature display device, and / or other medical functionality that may be desired to perform therapy and / or diagnosis and / or provide medical services to the user.

[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 program / configure the device 800 using the remote interface 802. Some or all of the communications between the remote interface 802 and the device may be encrypted to provide an enhanced level of security.

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

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

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

[0069] PCGP may ensure data integrity by utilizing a cyclic redundancy check (CRC). PCGP may also provide guaranteed delivery status. As a non-limiting example, every new message should have a reply. If such a reply is not returned in time, the message may time out and PCGP may generate a negative acknowledgement reply message (i.e., NACK) to the application. Thus, the message reply protocol may inform the application whether it should retry sending the message.

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

[0071] PCGP may use a shared buffer pool scheme to minimize data copies and avoid mutual exclusion, which may have a minor impact on the APIs used to send / receive messages to applications and a larger impact on drivers. PCGP may use a "bridge" base class that provides routing and buffer ownership. Major PCGP classes may be subclassed from the bridge base class. In some embodiments, drivers may derive from the bridge class or communicate with or own a derived bridge class.

[0072] In some embodiments, PCGP may be designed to run in embedded environments, with or without an operating system, by using semaphores to protect shared data so that some calls are reentrant and can operate on multiple threads. One non-limiting illustrative example of such an implementation is shown in FIG. 8D. PCGP may operate in the same way in both environments, but there may be versions of the calls for 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, the ARM 9 Nucleus OS environment.

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

[0074] In some embodiments, each software object may ask the buffer manager for the next buffer it uses and then give that buffer to another object. Buffers may be passed automatically from one exclusive owner to another, and queues may be generated automatically by ordering buffers by sequence number. In some embodiments, buffers may be recycled when they are no longer in use (e.g., an object may try to give the buffer to itself or release it to the buffer manager for later reallocation). Thus, in some embodiments, data does not generally need to be copied and routing simply overwrites the buffer owner bytes.

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

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

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

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

[0079] The sending of a new message may, in some embodiments, follow one or more of the following rules. Only two messages may be allowed "in-flight" on the network; and / or · Enough data about in-flight messages may be stored to match responses and handle timeouts. Receiving a message may follow the following rules: A matching response may clear the "in-flight" information slot so a new packet can be sent. Non-matching responses may be dropped. · The new message may be for a protocol (e.g. get / clear network statistics for this node). A buffer may be given to the application to receive messages, or a callback may be used; and / or The buffer may be freed or remain owned by the application. Thus, in some embodiments, PCGP may be configured as follows: The callback function may copy the payload data out or may use it entirely before returning. The callback function may copy any payload data it completes or uses before returning. The callback function may own the buffer, reference the buffer and the payload of the buffer by the payload address, and the message may be processed at a later time. The application may poll the PCGP system for received messages, and / or Applications may use callbacks to set events and then poll for incoming messages.

[0080] The communication system may have a limited number of buffers. When the PCGP runs out of buffers, the driver may stop accepting new packets and the application may be told that the application cannot send new packets. To avoid this and maintain optimal performance, the application may attempt to take one or more steps, examples of which may include, but are not limited to, the following: a) The application may keep the PCGP up to date on the radio state. Specifically, in some embodiments, if the link goes down and the PCGP is not aware, the PCGP may accept and queue new messages to send (or may not optimally time out messages), which may clog the transmit queue and delay the application from optimally using the link. b) The application may periodically call "decrement timeout". Optimally, in some embodiments, the application may call "decrement timeout" every 20-100 milliseconds unless the processor is sleeping. In general, messages may move 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. Doing this infrequently can cause delays when new messages are sent or when applications queue new messages. c) Applications may ask PCGP if there is any pending work to do before going to sleep. Thus, in some embodiments, driver activity may wake up the system, and thus PCGP, if PCGP has no work to do, and thus PCGP does not require a call to "packetProcessor" or "decrement timeout" until a new packet enters the system. In some embodiments, failure to do this may cause messages that would have been successfully sent / forwarded / received to be dropped due to a timeout condition. d) Applications should not hold on to received messages indefinitely. Message systems depend on quick replies. If applications share PCGP buffers, then holding on to a message means holding on to the PCGP buffer. In some embodiments, the receiving node is not aware of whether the sending node has timeouts configured for slow or fast wireless communication. This means that the node should measure the fast timeout rate of the network in response to receiving a message. And / or e) An application may call "packetProcessor" frequently. In some embodiments, the call may cause new messages queued by the application to be sent, and may also handle the receipt of new messages. The call may also cause buffers to be reallocated, and infrequent calls may slow message traffic.

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

[0082] The PCGP RX overhead may consist of asking for the next available buffer and calling the route function. A non-limiting example of code that performs such 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 do a TX by asking the buffer manager for a pointer to the next buffer to send. The TX driver may then ask the other side of the interface if it can accept the packet. If the other side rejects the packet, the TX driver may do nothing with the buffer since its state has not changed. Otherwise, the driver may send the packet and recycle / free the buffer. A non-limiting example of code that performs such a function is as follows: uint8 *p = Bridge::nextBufferTX(); if (p != (uint8 *)0) { send the buffer p; Bridge::recycle(p); }

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

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

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

[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 acted upon. If the data is corrupted, a statistic may be incremented and the buffer may be freed. If not, the buffer may be marked as owned by the application. Buffers marked as owned by the application may be recycled for PCGP use or freed for reallocation by the buffer manager.

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

[0090] In some embodiments, PCGP works in conjunction with flow control, which may negotiate the forwarding of messages from one node to another such that buffers are never dropped due to a lack of buffers on the other side of the interface (which may cause backpressure on the sending node).

[0091] The flow control may be part of a shared buffer format. In some embodiments, the first two bytes may be reserved for the driver so that the driver never needs to shift packet bytes. Two bytes may be used such that one byte is the DMA length-1 and the second byte controls the flow of messages. These same two bytes may synchronize the bytes when PCGP messages are 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 the process of being sent by a driver on its way to its destination, being processed by the destination, or being sent back as a response. Typical delays are as follows: [Table 1]

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

[0094] In various embodiments, PCGP may use two different times (set at initialization) for all timeouts, one for when the RF link is in fast heartbeat mode and one for when the RF link is in slow mode. However, in other embodiments, PCGP may use more than two or less than two different times. In some embodiments, when a message is in-flight and the link state changes from fast to slow, the timeouts may be adjusted and the difference between fast and slow may be added to the expiration counter for the packet. Any additional transitions back and forth should not affect the expiration for the message.

[0095] In some embodiments, there is a second timeout, which can be twice as long as the slow timeout, used to monitor buffer allocation in PCGP. Thus, if a message is "stranded" in the driver and not sent, for example due to flow control or hardware corruption, the buffer may be freed by the buffer manager, causing the buffer to be dropped. For "new" messages, this may mean that the packet has already timed out and a reply has already been given to the application that the message was not delivered, causing the buffer to be freed. The next time the driver polls the buffer manager for buffers that need to be sent, the buffer is freed so that messages that can be sent are passed to the driver the next time the obstruction is removed. For reply messages, the reply may simply be dropped or 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, inside 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 ​​of 0xDE, 0xCA or 0x5A, 0xA5. · LD: Driver DMA Length byte, equal to the amount the driver is pushing out in this DMA transfer, which is the total size, not including the size byte or sync byte. · Cmd: Driver command and control byte used for flow control. · LP: PCGP packet length, always total header + payload size in bytes + CRC size. LD = LP + 1. · Dst: Destination address. · Src: Source address. Cmd: Command byte. · Scd: Sub-command byte. AT: Application Tag is defined by the application and has no significance to PCGP. It allows an application to attach more information to a message, such as the thread from which the message originated. · SeqNum: A 32-bit sequence number incremented by PCGP for each new message sent, ensuring that the number is not rounded up, acts as a token, and is endianness-independent. · CRC16: 16-bit CRC of the PCGP header and payload.

[0097] An example of a message with no payload, cmd=1, subcmd=2 is: 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, examples of which may include, but are not limited to, the following: In various embodiments, most hardware DMA engines may use the first byte to define how many additional bytes to move, so in this methodology the driver and PCGP may share a buffer. A byte may be provided immediately after the DMA length to pass flow control information between drivers. · Because the driver length and "Cmd" bytes may be outside the CRC field, they may be modified by the driver and are owned by the driver transport mechanism, and the driver may alert on invalid lengths. There may be a separate PGCP packet length byte, which is CRC protected, so applications may trust that their payload length is correct. The endianness of the sequence number may not be relevant as it is nothing more than a byte pattern that can be matched, which similarly happens to be a 32-bit integer. · The sequence number may be 4 bytes, aligned to the edge of the shared buffer pool length. · There may be an optional RS232 sync byte so that while debugging a message stream the user may move the cable around and have both sides of the interface resynchronize. Applications, drivers, and PCGP may share buffers and free them by pointer.

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

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

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

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

[0102] Below is an event-based pseudocode driver that illustrates how driver events work: The Driver subclassifies the Bridge, disables hasMessagesToSend and flowControlTumedOff, and schedules the TX and RX functions to run if they are not already running. 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 void TX_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 ) ; EnableISRs(); } 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 ) ; EnableISRs(); } }

[0103] Without being limited thereto, one or more statistics may be supported by PCGP. Number of packets sent · Number of packets received ·CRC error ·timeout - Unavailable buffer (buffer is exhausted)

[0104] In various embodiments, PCGP may be designed to operate in multiple processing environments. Most parameters may be run-time configurable to facilitate testing and run-time fine-tuning of performance. Other parameters may be compile-time, e.g., anything that modifies memory allocation that must be done statically at compile time, but still other parameters may be used in various embodiments.

[0105] Below may be definitions of a number of compile-time configurations that may vary where PCGP is implemented. · Driver Bytes: Reserved for a common buffer scheme for the driver, may be 2 bytes, but in some embodiments this may be a compile time option to accommodate other drivers such as RF protocols. · Number of RX driver buffers: May be tuned to the number of buffers desired for that processor / traffic flow etc. · Number of PCGP RX buffers: May be tuned to the number of buffers desired for that processor / traffic flow etc. Total number of buffers: may be tuned to the number of buffers desired for that processor.

[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 be retried by the originator.

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

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

[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 the C++ code. This may simplify the "C" code as the objects being acted upon are implicit. In some embodiments, the following general rules may apply: · PCGP may run on all nodes. Any driver may support the generic driver interface. Race conditions may not be tolerated. · Half-duplex may be supported on the SPI port between the slave and master processors. · It may succeed or return failure / false so no data transfer may be attempted. · May require low overhead (time wasted, processing, bandwidth). · May support CC2510 running at DMA (high speed) SPI clock ratio.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0124] Additionally, in some embodiments, when a user anticipates separating remote interface 802 from device 800, the user may configure device 800 and remote interface 802 into a "separate" mode, thus eliminating the generation of the aforementioned "separate" alarm. However, in some embodiments, remote interface 802 and device 800 may continue to "ping" each other such that upon returning to communication with each other, device 800 and remote interface 802 may automatically be released from "separate" mode.

[0125] Further, in some embodiments, if a user anticipates traveling on an airplane, the user may use remote interface 802 to configure device 800 and remote interface 802 into an "airplane" mode, in which device 800 and remote interface 802 each suspend any data transmission. While in "airplane" mode, device 800 and 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, one or more of checking the battery life of the reusable portion 502, pairing the reusable portion 502 with the remote interface 802, and / or interrupting the administration of a bolus dose of infusible fluid.

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

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

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

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

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

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

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

[0134] A master alarm may be utilized that tracks errors, e.g., volume error, over time, which may indicate that the volume of fluid delivered is less than or more than what is required. Thus, if the sum of errors becomes too large, a master alarm may be initiated, indicating that there may be an anomaly in the system. Thus, the master alarm may indicate the total volume comparisons being made and the discrepancy found. A typical value of discrepancy required to initiate a master alarm may be 1.00 milliliters in an embodiment including the infusion pump described above. The master alarm may monitor the sum in a leak fashion (i.e., the inaccuracy has a time horizon).

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

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

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

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

[0139] In various embodiments, a shape memory actuator may be secured to a first end using electrical contacts. The other end of the shape memory actuator may be connected to a bracket assembly. When the shape memory actuator is activated, the shape memory actuator may pull the bracket assembly forward and release the valve assembly. As such, the measurement valve assembly may be activated via the shape memory actuator. When the measurement valve assembly is activated, the bracket assembly may automatically latch the measurement valve assembly in an activated position. Activating the shape memory actuator may pull the bracket assembly forward and release the valve assembly. When the bracket assembly releases the measurement valve assembly, assuming the shape memory actuator is no longer activated, the measurement valve assembly may be in a deactivated state. Thus, activating the shape memory actuator may cause the measurement valve assembly to be in a deactivated state.

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

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

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

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

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

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

[0146] As discussed above (and with momentary reference to FIGS. 1A-5I), various embodiments and components of the infusion pump system may be configured using a remote interface 802 (see FIGS. 6-8). When configurable via a remote interface 802, the infusion pump 800 may include telemetry circuitry (not shown) that allows for communication (e.g., wired or wireless) between the infusion pump and, for example, the remote interface 802, thus allowing the remote interface 802 to remotely communicate with the infusion pump 800. Various embodiments of the remote interface 802 (which may also include telemetry circuitry (not shown) and may be in communication 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 below for illustrative purposes, but the description is not limited to that embodiment of the remote interface shown in FIG.

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

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

[0150] The OS may be a non-interrupt type scheduling system in that all tasks run to completion before the next task can run, regardless of priority. Additionally, no context switching may occur. When a task completes execution, the highest priority task currently scheduled for execution may run. If no tasks are scheduled for execution, the OS may put the processor (e.g., supervisor processor 900 and / or command processor 902) into a low power sleep mode and may wake 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 key elements of the design, allowing for easy creation, scheduling, and management of tasks.

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

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

[0154] In some embodiments, putting the processor into LPM may always be done by the provided SysClocks. This function may contain all the necessary power down and power up sequences that provide consistency whenever going into or out of LPM. Wake from LPM may be initiated by any interrupt based on the slow clock.

[0155] The OS may track three aspects of time: seconds, milliseconds, and time of day. With regard to seconds, SysClocks may count seconds beginning when the processor comes out of reset. The seconds counter may be based on a slow system clock and therefore may increment whether the processor is in LPM or full power. As a result, this is the boundary at which the processor will wake from hibernation to execute a previously scheduled task. If a task is scheduled to be executed immediately after an interrupt service routine (ISR), the ISR may wake the processor from LPM when it finishes and the task may be executed immediately. With regard to milliseconds, in addition to counting seconds since power on, SysClocks may also count milliseconds while the processor is in full power mode. The millisecond counter may not increment because the fast clock is stopped during LPM. Thus, the processor may not be in LPM whenever a task is scheduled to be executed based on milliseconds. With respect to times, times may be represented within SysClocks as the number of seconds since a particular point in time (e.g., the number of seconds since January 1, 2008, and / or in some embodiments, the number of seconds since January 1, 1971, POSIX standard time).

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

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

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

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

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

[0162] Through inheritance, creation of managed functions may be done by creating a derived class and defining a pure virtual "run" function that contains the code that needs to be subject to scheduling control. The ManagedFunc base class constructor may be based on the unique ID of the function, but may also be used to set default control values ​​at startup.

[0163] For example, to create a function that runs 30 seconds after starting and every 15 seconds thereafter, the desired code is put into the virtual execute function, for example, and a start time of 30 seconds, a function ID scheduled by seconds state, and a repeat setting of 15 seconds are provided to the constructor.

[0164] Below is an illustrative code example for creating a managed function: In this particular example, a "heartbeat" function is created that is scheduled to run for the first time 1 second after device 800 starts up, and then every 10 seconds. #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 implemented by the SleepManager class. SleepManager may contain the actual prioritized list of managed functions. This prioritized list of functions may be automatically populated by the managed function creation process, ensuring that each function is created properly and has a unique ID.

[0166] The primary role of the SleepManager class may be to have its "management" function called repeatedly from the processor's main loop and / or from a forever while loop. On each call to manage, the SleepManager executes all functions scheduled to be executed until the SleepManager exhausts all scheduled functions, at which time the 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 be in LPM again (this process may be repeated, for example, until stopped by the user or by the system).

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

[0168] The SleepManager may also provide an interface to manipulate the scheduling and iterating settings of any managed function through the use of the function's unique ID, which may allow any section of code to perform any necessary scheduling without direct access to, or unnecessary knowledge of, the desired ManagedFunc object.

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

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

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

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

[0173] Referring also to FIG. 12, there is shown one illustrative embodiment 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 the device 800 may forward messaging packets between the SPI port and the 2.4 GHz radio link (or vice versa). In some embodiments, the radio may always be an SPI slave. On the device 800, the radio processor (PRP) 918 (see FIGS. 9A-9B) may, in some embodiments, service two additional nodes (the number of additional nodes may vary in various embodiments) that are upstream (i.e., the command processor 900 and the supervisor processor 902) via the SPI port. In some embodiments, on the remote interface 802, the radio processor 918 (CRP) may enable two additional nodes on the SPI port that 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) described above.

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

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

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

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

[0178] The Quiet_Radio signal may be used by the UI processor of the remote interface 802 to prevent noise interference on the remote interface 802 board by other systems on board. When Quiet_Radio is asserted, the radio application of the remote interface 802 may send a message to the radio of the device 800 to assert Radio Quiet mode for a predetermined period of time. In some embodiments, the Quiet_Radio feature may not be needed 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 Sleep Mode 2 for up to 100 ms. The radio of the remote interface 802 may exit Sleep Mode 2 when the Quiet_Radio signal is deasserted or the maximum period expires. The UI processor of the remote interface 802 may assert Quiet_Radio for at least one radio communication interval before it needs to assert the event. The radio of the remote interface 802 may inform the radio of the device 800 that communications will be shut down during this dormant period. The periodic radio link protocol may have a status bit / byte that accommodates the Quiet_Radio feature unless Quiet_Radio is needed.

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

[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 the 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 may be more or less than the examples stated.

[0181] The maximum time to reacquire communication, including connection request mode and 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 advantageously 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 remote interface 802 going into acquisition mode may be that device 800 needs to go into acquisition mode frequently enough to ensure that communication can be restored within the maximum latency time. However, remote interface 802 may vary the frequency of going into acquisition mode with device 800 when in slow heartbeat mode and heartbeats are lost. In some embodiments, the radio of the remote interface 802 may have knowledge of user GUI interactions, while device 800 may not.

[0182] The remote interface 802 radio 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 remote interface 802 radio to the device 800 radio in each heartbeat. This may not exclusively establish the heartbeat rate of the device 800 due to other conditions that determine which mode to be in. When in fast heartbeat mode, the remote interface 802 radio may set the heartbeat period to 20 ms if it is able to send or receive data packets, thus providing low latency communication when data is being actively exchanged.

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

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

[0185] In some embodiments, the radio may use a system message to get the local radio serial number. On the remote interface 802, the radio may get the serial number from the UI processor of the remote interface 802. The radio may use a system message to store the paired radio serial numbers. The remote interface 802 and the radio of the device 800, in some embodiments, may use a messaging system to issue status messages to the UI processor of the remote interface 802 and command processor 902 whenever one or more of the following conditions change, including but not limited to: -Fast online: Connection successful · Fast Online: Change from Acquisition Mode to Fast Heartbeat Mode · Slow Online: Request to change from fast heartbeat to slow heartbeat successful Offline: Automatic change to search sync mode due to lack of heartbeat exchange · Fast Online: Successful request to change from slow heartbeat to fast heartbeat Offline: Bandwidth below 10% in synchronous mode Online: Bandwidth exceeds 10% in search synchronous mode Offline: Request to change to RF off mode successful

[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 the device 800 to configure these radio settings.

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

[0188] Both the remote interface 802 and the radio application of the device 800 may have an API that allows the messaging system to configure the number of RF retries and radio offline parameters.

[0189] In some embodiments, one or more of the following parameters may be recommended for the radio hardware configuration, without being limited thereto: Basic wireless specifications ·MSK - Wireless communication ratio of 250 kbps or more Up to 84 channels 1000kHz channel spacing 812kHz filter bandwidth No Manchester encoding Data erasure 4-byte preamble 4-byte sync (word) -CRC added to the packet -LQI (Link Quality Indicator) added to the packet -Automatic CRC filtering enabled

[0190] In some embodiments, forward error correction (FEC) may or may not be used. 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 over-the-air bits for the same fixed size message, which may not be desirable 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, it may be a goal for the radio to function within a distance of 7.32 meters under nominal operating conditions. In some embodiments, the transmit power level may be 0 dBm (except in pairing mode) and the transmit power level in pairing mode may be -22 dBm. Because the desired radio node address of the device 800 may not be known by the remote interface 802 in pairing mode, both the device 800 and the remote interface 802 may use a lower transmit power in some embodiments to reduce the possibility of accidentally pairing with another infusion pump assembly. However, in various other embodiments, either the device 800 or the remote interface 802 may use a lower transmit power.

[0192] In some embodiments, AES encryption may be used for all packets, but may not be required, for example in embodiments using a Texas Instruments CC2510 radio transceiver, as the transceiver includes this functionality. In embodiments where AES encryption is used, a fixed key may be utilized, as this may be desirable for a number of reasons, including providing a quick way to allow 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 one separate header source, with no other variables other than the fixed key data, thus allowing easier management of read access to the file. In some embodiments, the radio software may support one or more of the following eight modes, including but not limited to: Pairing mode RF Off Mode Connection Mode Acquisition mode -Fast heartbeat mode Slow Heartbeat Mode ·Search synchronous mode Synchronous Acquisition Mode All of this is depicted diagrammatically in Figures 12B-12C.

[0193] Pairing may be the process of exchanging radio serial numbers between the remote interface 802 and the device 800. The remote interface 802 may be "paired" with the device 800 when the device 800 knows its serial number. The device 800 may be "paired" with the remote interface 802 when the remote interface 802 knows its serial number. In some embodiments, the pairing mode (one embodiment of which is depicted diagrammatically in FIG. 12D ) may require the following four messages to be exchanged over the RF link (however, various embodiments may require more, less, or no messages to be exchanged over the RF link): RF pairing request (broadcast from remote interface 802 to any device 800) RF Pairing Acknowledge (Device to Remote Interface 802) RF pairing confirmation request (from remote interface 802 to device 800) RF pairing confirmation acknowledgment (from device 800 to remote interface 802)

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

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

[0196] In some embodiments, a near field communication ("NFC") protocol may be used to identify that the device 800 and the 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 a pairing protocol, i.e., the device 800 and the remote interface 802 are identified as being paired. In some embodiments, a camera located on the remote interface 802 may be used to capture an image of a 2D barcode on the device 800 and use this image and / or image identification to identify the device 800. In some embodiments, the 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 receiving the first valid RF pairing request message, the radio of device 800 may respond with an RF pairing acknowledgement message using the serial number of the remote interface 802 for the duration of the pairing mode and containing the radio serial number of device 800.

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

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

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

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

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

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

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

[0205] In some embodiments, the radio of the remote interface 802 may transmit a pairing interrupt request message and, in response to receiving the pairing interrupt request message, exit the pairing mode. This may allow the UI processor of the remote interface 802 to interrupt the pairing process at both the remote interface 802 and the acknowledged device 800.

[0206] In the connection request mode, the radio of the remote interface 802 may acquire each device 800 in its paired device list and attempt to restore its "ready to connect" state. The "connect" process, one embodiment of which is depicted diagrammatically in FIG. 12E, may allow the remote interface 802 in some embodiments to quickly identify one of its paired devices that may be ready to be used. The radio of the remote interface 802 may be capable of performing the connection request mode with multiple devices, for example, in some embodiments, up to six paired reusable parts of an infusion pump. The connection request mode may be supported only on the remote interface 802 and may be a special form of acquisition mode. In the connection request mode, the remote interface 802 may connect and respond with the first device. However, each message may be directed to a specific device serial number.

[0207] In some embodiments, the radio of the remote interface 802 may obtain a list of serial numbers of the most recent paired devices when it goes into connection mode. The radio of the remote interface 802 may go into connection mode in response to receiving a connection mode request message. It may be the responsibility of the UI processor of the remote interface 802 to request that the radio go into connection mode when it desires to communicate with a paired device. The radio of the remote interface 802 may issue a connection assessment message to the UI processor of the remote interface 802 containing the radio serial number of the first device that is "ready to connect", if applicable. The radio of the remote interface 802 may generate the connection assessment message within a predetermined amount of time, e.g., 30 seconds, of going into connection request mode. However, the predetermined amount of time may be less than or greater than 30 seconds in various embodiments. In some embodiments, the radio of the remote interface 802 may exit connection request mode upon receipt of a connection assessment acknowledgment and transition to a fast heartbeat mode. The radio of the remote interface 802 may exit connection request mode in response to receiving a connection request abort message from the UI processor of the remote interface 802.

[0208] An acquisition mode may be used on the remote interface 802 to find a particular paired device. In some embodiments, the radio of the remote interface 802 may send an RF RUT (a Remote 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 that the radio of the remote interface 802 will find a paired device.

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

[0210] In some embodiments, particularly those embodiments in which the device is an infusion pump, the radio of the remote interface 802 may communicate (except for pairing and connection modes) with only one paired infusion pump 800. 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, the device 800 may enter acquisition mode under one or more of the following conditions, although in various other embodiments, additional conditions may trigger the acquisition mode. When in radio off mode and acquisition mode may be required When the search synchronization mode times out due to lack of heartbeat

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

[0212] In some embodiments, data packets may be transmitted between pairing device 800 and remote interface 802, for example, when device 800 and 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 a heartbeat exchange. Device 800 may coordinate when to expect to receive packets. In some embodiments, a radio may support one data packet in each direction on each heartbeat. A radio may provide a negative response to a fast heartbeat mode request if the radio is offline. A radio in remote interface 802 may change to fast heartbeat mode if it is in slow heartbeat mode and a system request for fast heartbeat mode is received while the radio is online.

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

[0215] The wireless protocol may be capable of buffering one received wireless data packet and passing the packet to a messaging system. In some embodiments, the wireless protocol may transmit the data packet to the messaging system upon receipt of the data packet. The messaging system may be responsible for sending the wireless data packet to the proper destination node. The wireless protocol may be capable of buffering one packet from the messaging system.

[0216] The radio protocol may involve acknowledging 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, an RF ACK command identification, 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 if no RF ACK is received and the retry count is within the maximum RF retries allowed. If interference prevents transmission on a particular frequency, in some embodiments, RF retries allow the same packet to be retransmitted at the next opportunity on a different frequency. The sequence number provides a means to uniquely identify the packet in a short time window. The number of wireless packet retries may be configurable using a radio configuration command. Allowing more retries may increase the probability of a packet being exchanged, but introduces additional latency for round-trip messages. The default number of wireless retries on a power increase may be 10 (i.e., the maximum transmission attempts before dropping a message). However, this maximum number may be different in various embodiments.

[0218] In some embodiments, a one-byte (modulo 256) over-the-air sequence number may be included in every over-the-air data packet on the RF link. The sequence number may provide a way for the two radios to know if a data packet is a duplicate, since the radios may engage in retrying the data packet transmission if not acknowledged. The transmitted sequence number may be incremented for each new over-the-air data packet and may be allowed to roll over. Upon successful reception of a data packet with the same sequence number (and in the same direction) as a previously successfully received data packet, the data packet may be acknowledged and the received data packet may be discarded. This may remove duplicate packets generated by the RF protocol before being introduced into the network. Note that under extreme circumstances, situations may arise where multiple consecutive data packets with the same sequence number may need to be dropped.

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

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

[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 airplane mode and therefore a walk-away warning. However, this may be completely hidden from the radio of the device 800.

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

[0224] In some embodiments, the device's radio may transition to acquisition mode after a predefined amount of time, e.g., 20 minutes in search sync mode, without a successful exchange of heartbeats. In some embodiments, listening during a pre-agreed time slot is the most efficient use of the device's 800 power to re-establish an RF link. After a loss of communication, crystal tolerances and temperature drift may require extending the device's 800 reception time window over time. Remaining in search sync mode after a loss of communication for an extended period of time (e.g., 5-20 minutes) may cause the instantaneous power consumed to exceed the average power allocated to the device's 800 radio. Remaining in search sync mode may be very power efficient because the remote interface's 802 radio may not be forced to extend its time window. Acquisition mode may consume more power in the remote interface's 802. In some embodiments, 20 minutes may be used as a compromise to balance power consumption in both the remote interface's 802 radio and the device's 800 radio, however, this time may vary with the embodiment.

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

[0226] Radio protocol performance statistics may be desired to facilitate radio troubleshooting and to evaluate radio performance. In some embodiments, the following radio performance statistics may be maintained in a data structure by the radio protocol. However, these are merely one embodiment and these may vary throughout the embodiments. Some embodiments may not use statistics or may use more, less, 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 per channel (16 bit numbers), however, in various other embodiments additional information may also be collected: Number of missing hops Good CCA count Bad CCA count Average RSSI (accumulated for good RX packets only) Drops from frequency hop list count Acquisition mode count (pairs found on this channel)

[0228] In some embodiments, a debug option may be used to gather engineering-only statistics. If processor performance, power, and memory permit, it may be desirable to maintain this information at run-time. Radio statistics may be made available to a messaging system.

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

[0230] In some embodiments, the radio may change frequency with each heartbeat. An adaptive pseudorandom frequency hopping algorithm may be used for the sync mode, and the heartbeats are attempted in the search sync 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 or less than 64 channels may be used. In some embodiments, an algorithm may be developed to adaptively generate a channel list on the remote interface 802 for frequency hopping. The radio of the remote interface 802 may build, maintain, and distribute a master channel list. In some embodiments, previous channel statistics and past performance information may be obtained from the radio of the device 800 by the radio of the remote interface 802 using a messaging system as necessary to meet performance requirements. By creating channel lists from the perspectives of both the device 800 and the remote interface 802, the radio interference environment of both units may be taken into account. The radio may adaptively select a hopping channel to meet round-trip message latency while operating in a desired RF environment.

[0231] 13, in some embodiments, the system may include at least two reusable portions 1300, 1308 of the infusion pump and at least one disposable portion 1310 of the infusion pump. In some embodiments, the reusable portions 1300, 1308 include a rechargeable battery 532. In some embodiments, the two disposable portions may be paired to the same remote interface, which may include the embodiment shown as 1302 in FIG. 13 and / or any one or more of the embodiments shown as 600, 700, 802 in FIGS. 6-8. In some embodiments, the user may connect the reusable portion 1308 to the disposable portion 1310 by rotating the reusable portion 1308 in the direction of the arrow 1316 while mating with the disposable portion 1310 to connect the reusable portion 1308 and the disposable portion 1310, as previously described. The second reusable part 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 of time, e.g., 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 that may be configured to couple with the remote interface 1302 when the remote interface 1302 is placed in the slot 1318. The USB plug may allow data transfer to / from the remote interface 1302 as well as charging of the remote interface 1302. In some embodiments, the user may use one reusable part 1308 while recharging the second reusable part 1300.

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

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

[0234] 16A-16F, as discussed above, the reusable portion 1602 may include a battery 1632, which may include, for example, a rechargeable battery. The battery charger 1600 may be configured to recharge the battery 1632. The battery charger 1600 may include a housing 1602 having a top plate 1604. The top plate 1604 may include one or more electrical contacts 1606 generally configured to be electrically coupled to electrical contacts 1634 of the reusable housing assembly 1602. The electrical contacts 1606 may include, without limitation, electrical contact pads, spring-biased electrical contact members, or the like. Additionally, the top plate 1604 may include alignment tabs 1608, 1610, which may be configured to mate with openings 1636, 1638 in a base plate 1618 of the reusable housing assembly 1602 (e.g., as shown in FIG. 5C). Cooperation of the alignment tabs 1608, 1610 and the openings 1636, 1638 can ensure that the reusable housing assembly 1602 is aligned with the battery charger 1600 such that the electrical contacts 1606 of the battery charger 1600 can electrically couple with the electrical contacts 1634 of the reusable housing assembly 1602.

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

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

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

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

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

[0240] 18 and 19, two embodiments of communication between the device, the remote interface, and a personal computer (which in some embodiments has access to one or more web portals and / or one or more secure web portals) are shown. In FIG. 18, the remote interface 1800 communicates with an infusion pump 1802 and two other devices, which in some embodiments may include a blood glucose meter 1806 and a continuous glucose monitor sensor / transmitter 1804. In some embodiments, the communication is wireless and may use RF communication, e.g., an RF communication protocol as described above, and / or may use 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 FIG. 19, the remote interface 1900 communicates with an infusion pump 1902. The infusion pump 1902 communicates with two other devices, which in some embodiments may include a blood glucose meter 1906 and / or a continuous glucose monitor sensor / transmitter 1904, and in some embodiments may be two continuous glucose monitor sensors. In some embodiments, the communication is wireless communication and may use RF communication, e.g., RF communication protocols as described above, and / or other non-proprietary protocols, including but not limited to BLUETOOTH®, or low energy BLUETOOTH®. In some embodiments, the infusion pump 1902, which wirelessly communicates with the remote interface 1900, may communicate information received from the two devices 1904, 1906 to the remote interface 1900. The remote interface 1900 thus serves as a visual UI, as the remote interface 1900 includes a display, in some embodiments. In some embodiments, the remote interface 1900 communicates wirelessly with a personal computer 1908 (which in some embodiments has access to at least one web portal and / or secure web portal), however, in some embodiments the remote interface 1900 may be connected to the personal computer 1908 via a USB connection and / or other wired connection. In some embodiments, the remote interface 1900 and the personal computer 1908 may communicate via a web / internet connection 1910 and / or via the remote interface 1900 uploading information to the internet and the personal computer 1908 downloading information from the internet.

[0242] With respect to both Figures 18 and 19, three devices are shown communicating, either directly or indirectly, with the remote interface, but the system is not limited to three devices and in some embodiments may include four or more devices. Additionally, in some embodiments, the system may include one device in communication with the remote interface 1900. Also, while one personal computer is illustrated in Figures 18 and 19, in other embodiments, one or more personal computers may be used to receive information from the remote interface. Additionally, as discussed above with respect to the battery charger and charging station, in some embodiments, the infusion pump and / or the remote interface may be connected to a charging station and may upload and / or download and / or communicate with the 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 and the other on the recharger. When the first reusable part is in use, therapeutic agent may be administered by the supervisor processor and command processor as described above. Actions by the reusable part are communicated to the remote interface. To "switch" the reusable part (so that the reusable part on the charger becomes the reusable part in use, or vice versa), the controller that uploaded information from the first reusable part during use downloads various logs onto the second reusable part so that the memory on the second reusable part contains all of the same memory as the first reusable part. This is done during the pairing process. One step of the process is done after pump activation, in some embodiments by the user pressing a switch assembly on the reusable part while the remote interface is in connection mode. During this step, the profile and user therapy configuration are transferred to the second reusable pump and / or synchronized with the reusable part non-volatile memory.

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

[0245] Thus, as previously described with respect to therapy administration, the infusion pump completes all decisions and controls the delivery of the infusible fluid. The remote interface is an interface to the infusion pump and, in some embodiments, provides an enhanced user interface (e.g., a display screen) with multiple opportunities to interact with the device (e.g., the infusion pump) and / or the user.

[0246] Therapy-related information is thus 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 updated information. If the remote interface determines that the reusable part does not contain updated information, the remote interface updates the information and / or synchronizes the reusable part's non-volatile memory with the updated information. Thus, 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 infusion pump) may be configured to deliver the infusible fluid to a user. Additionally, the infusion pump 800 may deliver the infusible fluid via infusion events, which may include continuous and / or multiple and / or discrete infusion events and / or single infusion events. Some of the infusion events may include, but are not limited to, one or more of a bolus, an extended bolus, a basal rate, a temporary basal rate, a combination bolus. As known in the art, a basal infusion event refers to a repeated infusion of small amounts of the infusible fluid at predetermined intervals (e.g., every 3 minutes) that may be repeated until stopped, for example, by the user or by the system. Additionally, the basal infusion rate may be pre-programmed and may include designated rates for pre-programmed time frames, such as a rate of 0.50 units per hour from 6:00 AM to 3:00 PM, a rate of 0.40 units per hour from 3:00 PM to 10:00 PM, and a rate of 1.0 units per hour from 10:00 PM to 6:00 AM, and / or may include pre-programmed time frames, such as 0.50 units per hour, then 1.0 units per hour for 2 hours, then 0.05 units per 30 minutes. In some embodiments, the basal rate may be pre-programmed to remain constant, such as 1.0 units per hour, and may not change throughout the time frame. The basal rate may be repeated periodically / daily and / or on a particular day unless otherwise changed. These pre-programmed basal rates may be referred to as basal profiles.

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

[0249] As known in the art, a bolus, when delivered as a normal bolus, is typically a predetermined volume of fluid delivered at a rate at which the device can deliver the fluid. In some embodiments, the predetermined volume, e.g., a bolus volume of 20 units or more, may be delivered slower than the "normal bolus" rate, which may be desired by the user, e.g., for purposes of absorption into tissue. In either case, however, the bolus event is typically delivered over a short period of time, e.g., in some embodiments, 10 minutes or less.

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

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

[0252] The various embodiments of the infusion pumps shown and described herein, as well as the various embodiments of the infusion pumps, may be implemented in a variety of ways, including, but not limited to, those disclosed in U.S. Patent No. 7,498,563, issued March 3, 2009, entitled "Optical Displacement Sensor for Infusion Devices" (Attorney Docket No. D78); U.S. Patent No. 7,306,578, issued December 11, 2007, entitled "Loading Mechanism for Infusion Pump" (Attorney Docket No. C54); PCT Application No. PCT / US2009 / 060158, filed October 9, 2009, entitled "Infusion Pump Assembly" (now published April 15, 2010, Attorney Docket No. WO2010 / 042814) (Attorney Docket No. F51WO); U.S. Patent Application No. 13 / 076,067, filed March 30, 2011, entitled "Infusion Pump Methods, Systems and No. 13 / 121,822, filed March 30, 2011, entitled "Infusion Pump Assembly," (now U.S. Patent Publication No. US-2011-0208123, published August 25, 2011, Attorney Docket No. I73); U.S. Patent Application No. 11 / 704,899, filed February 9, 2007, entitled "Fluid Delivery Systems and Methods," (now U.S. Patent Publication No. US-2007-0228071-A1, published October 4, 2007, Attorney Docket No. E70); U.S. Patent Application No. 12 / 347,985, filed December 31, 2008, entitled "Infusion Pump Assembly," (now U.S. Patent Publication No. US-2011-0208123, published August 25, 2011, Attorney Docket No. I73); No. 12 / 560,106, entitled "Systems and Methods for Fluid Delivery," filed September 15, 2009 (now U.S. Patent Publication No. US-2010-0185142-A1), published July 22, 2010 (Attorney Docket No. G47);No. 12 / 837,193, filed July 15, 2010, entitled "Apparatus, Systems and Methods for An Infusion Pump Assembly," now U.S. Patent Publication No. US-2011-0144574, published June 16, 2011 (Attorney Docket No. I23); and U.S. Patent Application No. 13 / 011,384, filed January 21, 2011, entitled "Method and System for Shape-Memory Alloy Wire Control," now U.S. Patent Publication No. US-2011-0300001, published December 8, 2011 (Attorney Docket No. I48), all of which are incorporated herein by reference in their entireties, and in various embodiments of the various devices, a remote interface 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 FIGS. 6-8. However, in some embodiments, the remote interface may be a dedicated device such as a cellular phone, tablet, or other device manufactured by, but not limited to, Motorola, Inc. (Schaumburg, NY). The remote interface may be a multi-function web-connected / web-enabled device, such as a GOOGLE ANDROID type device or any other device that may run using an open source operating system, such as the ANDROID operating system, which may include the DROID RAZER by HTC (Illinois, USA); HTC GOOGLE Nexus one by HTC (Taoyuan 330, Taiwan); SAMSUNG Nexus S by SAMSUNG Corporation; and 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 peripherals, including but not limited to GPS, accelerometer, phone, web connection, camera, email, etc.

[0253] 18 and 19, in some embodiments the remote interface 1800, 1900 may be or have web-connected remote interface capabilities, which may include, but are not limited to, the ability to download applications, download software updates, upload information, and / or transmit information to various machines, including but not limited to through a web-based secure portal, and / or through email, and / or via wireless communication protocols. Thus, in various embodiments the remote interface application may run on any capable device and is not limited to so-called dedicated devices. Further, in some embodiments, the remote interface may be BLUETOOTH®-enabled or otherwise compatible to communicate, for example, using radio frequency ("RF") communications with one or more devices, which may include, without limitation, one or more of an infusion pump 1802, 1902 and / or a continuous glucose monitor transmitter / sensor 1804, 1904 ("CGM") and / or a BLUETOOTH® or other communications protocol compatible blood glucose meter 1806, 1906 and / or any other medical device and / or patient care device or any other device.

[0254] Although FIGS. 18-19 illustrate the remote interfaces 1800, 1900 in communication with a personal computer 1808, 1908, an infusion pump 1802, 1902, a blood glucose meter 1806, 1906, and / or a CGM 1804, 1904, in various embodiments, the remote interfaces 1800, 1900 may communicate with one or more of any one of the personal computer 1808, 1908 (which in some embodiments may be a web portal), the infusion pump 1802, 1902, the blood glucose meter 1806, 1906, and / or a CGM 1804, 1904, and / or any other devices, including, but not limited to, medical devices. Further, in some embodiments, one or more of the personal computer 1808, 1908 (which in some embodiments may be a web portal), the infusion pump 1802, 1902, the blood glucose meter 1806, 1906, and / or the CGM 1804, 1904 may also communicate with one or more of the personal computer 1808, 1908 (which in some embodiments may be a web portal), the infusion pump 1802, 1902, the blood glucose meter 1806, 1906, and / or the CGM 1804, 1904 in addition to communicating with the remote interface 1800, 1900. In some embodiments, the remote interface 1800, 1900 may communicate with one or more devices not described herein, however, it should be understood that the remote interface 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, the remote interface device 1800, 1900 may share data with a secure web page / web portal / personal computer 1808, 1909. This shared data may be automatically transferred 1810, 1910 (i.e., synchronized) at predetermined and / or preprogrammed intervals in some embodiments. In some embodiments, data from the remote interface 1800, 1900 is uploaded to the secure web page / web portal / personal computer 1808, 1908 by a password-protected application, which in some embodiments ensures that the information is not shared. In some embodiments, information from the remote interface 1800, 1900 may be stored on a secured web page, so that the information may be downloaded to a substitute remote interface and / or a second remote interface and / or other devices upon request. Thus, in some embodiments, the system allows the remote interface 1808, 1908 to be easily replaced upon failure and / or loss. As discussed above, in some embodiments, secure web pages and / or data transfers are secured by a password or other type of security.

[0256] Additionally, the secure web portal / personal computer 1808, 1908 may be utilized by the user to review infusion pump therapy, CGM data and / or glucose meter data (as well as additional devices connected to either the remote interface 1800, 1900 and / or the secure web page / personal computer 1808, 1908, in some embodiments at the same location). Additionally, the secure web page / personal computer 1808, 1908 may include food libraries and / or user customizable therapies that are customized by the user, for example, on the 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" the 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 at a later time. These events may then be "named" by the user, in some embodiments, and in some embodiments, therapy plans 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 regimen with the food being consumed, including, but not limited to, an indication of the number of slices and the ingredients of the slices, e.g., "Sal's Pizza, Cheese, 2 slices." The user may then input this into the remote interface 1800, 1900, and in some embodiments, later, while reviewing the CGM and / or pump and / or glucose meter data, the user may design a regimen to be used when eating "Sal's Pizza, Cheese, 2 slices." The user may name the event, and a regimen may be associated with the name. The user may then select the "Sal's Pizza, Cheese, 2 slices" event at any time and authorize the remote interface 1800, 1900 to administer the stored regimen associated with the pizza.In some embodiments, events may be linked to a food library, so that as a user includes items from the food library, the remote interface 1800, 1900 may "link" the food items with the therapy and / or CGM and / or blood glucose meter data. 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 interface 1800, 1900. Once these changes are uploaded from the personal computer (and / or secure web page) 1808, 1908 to the remote interface 1800, 1900, they may then be downloaded onto other devices connected to the remote interface 1800, 1900, including, but not limited to, the infusion pump 1802, 1902.

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

[0258] Thus, the user may perform post-event analysis and design and / or make changes to therapy based on the analysis. In some embodiments, the user may use this information to look for trends and modify basal and / or bolus profiles. In some embodiments, the analysis may be completed by a physician and / or caregiver using or through the secure web pages 1808, 1908. In some embodiments, the user may "filter" the database for specific events and / or foods consumed, analyze them with or without the caregiver, determine basal and / or bolus profiles, and link them to the specific events and / or food items. Thus, in some embodiments, the user may use the remote interface 1800, 1900 (or the 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 interface 1800, 1900 may learn user habits from both collected CGM and / or pump and / or glucose meter data and information entered by the user. The application and / or software may recommend therapy changes, which may be accepted or rejected by the user.

[0260] In some embodiments, the 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 set up 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 either 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, the CGM sensors 1804, 1904 may communicate directly with the infusion pumps 1802, 1902 and / or the remote interfaces 1800, 1900 (see FIGS. 18 and 19). In some embodiments, the CGM sensors 1804, 1904 may communicate with one or the other, and in some embodiments, the CGM sensors 1804, 1904 may communicate with both the infusion pumps 1802, 1902 and the remote interfaces 1800, 1900. In some embodiments, safety-critical information, e.g., alarms, may be communicated directly to the infusion pumps 1802, 1902, and the remote interfaces 1800, 1900 may simply be used as a display.

[0262] 7, in some embodiments, the remote interface 1800, 1900 may include at least one screen containing at least one accelerometer and a number of buttons 706, 710, which in some embodiments may be customizable by the user. The buttons 706, 710 may in some embodiments be used to navigate directly to a particular screen, for example, but not limited to, to input information about an event and / or simply to indicate to the remote interface 524 that an event is occurring. In some embodiments, this information may be stored and transmitted to a secure web page and / or otherwise, 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 sent to the remote interface 1800, 1900 for a safety monitoring service. The service may perform monitoring and place a call and / or send a text (e.g., "Are you OK?") to the remote interface 1800, 1900 when data indicates that a problem may exist, e.g., low blood glucose is indicated, and / or an infusion pump warning / alarm and / or a CGM warning / alarm have not been acknowledged, e.g., an alarm / alarm has not been acknowledged / acknowledged by the user, which may include, but is not limited to, a button press and / or a screen touch to acknowledge receipt of the alarm / alarm. For example, in some embodiments, if the user does not respond to the service call and / or text, the service may then place a call to emergency services and / or parents or guardians and / or emergency contacts. In some embodiments, a GPS in the remote interface 1800, 1900 may locate the user so that emergency personnel may be referred and dispatched to the user's location. In some embodiments, if the service contacts parents or emergency personnel or emergency contacts, the service may also send current CGM and / or pump data for review.

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

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

[0266] In some embodiments, the remote interface 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 audio indications, i.e., sounds. The sounds may be personalized and / or unique to each remote interface 1800, 1900, which may increase security in pairing the remote interface 1800, 1900 to a user's device. In some embodiments, pairing may be accomplished using NFC (near field communication), i.e., by holding the device and the remote interface 1800, 1900 in close enough proximity within a short distance that the two may communicate and pair, i.e., be able to communicate.

[0267] In some embodiments, the 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 therefore allow the user to make more informed therapy decisions. Additionally, the actual volume delivered may be useful to the healthcare provider to fine-tune or implement basal levels, insulin to carbohydrate ratios, etc.

[0268] In some embodiments, because the remote interface appears to be a normal device, rather than a medical device, the remote interface may include password protection that is required to change the therapy. For example, to open the "Therapy Screen" (which term may be used to refer to any screen where any changes to the therapy can be made, including, but not limited to, insulin / drug sensitivity, carbohydrate to drug ratio, drug duration, basal profile, bolus requirements, food library information, blood glucose screens, etc.), the user may be required to enter a password in some embodiments. In some embodiments, a fingerprint or other may be used. In some embodiments, a "tap code" may be used, i.e., a force applied to the remote interface at an interval (e.g., in embodiments where the remote interface 1800, 1900 may include at least one accelerometer, a tap of the device at a specific code may convey information. In some embodiments, the infusion pump 1802, 1902 may include at least one accelerometer in addition to or instead of a remote interface 1800, 1900 having 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 send an engineering log directly to the manufacturer regarding that particular device. This may be desirable as it may eliminate the need for the user to mail the device experiencing the problem to the manufacturer. The manufacturer, upon receipt, may recommend to the user a code or other to silence an alarm or other once the manufacturer has determined the cause of the problem. In some embodiments, the remote interface may include a pre-programmed protocol to send only the engineering log to the manufacturer, and not medical information. This may ensure that the user does not unintentionally send its secure medical information to the manufacturer. Thus, the remote interface 1800, 1900, in some embodiments, includes logs and / or information regarding all of the devices connected to the remote interface 1800, 1900. Thus, replacement of a device may be accomplished by downloading logs, user profiles, user preferences, etc. from the remote interfaces 1800, 1900 so that the device can be used by the user with a minimum "setup" time and so that the substitute device can function / be configured as the old device that was replaced.

[0270] In some embodiments, it may be desirable to transmit the screen, e.g., a “screenshot”, from the remote interface 1800, 1900 to a service representative and / or the manufacturer, i.e., the service representative may be able to review the screen while discussing any issues with the device, e.g., either via web chat and / or phone.

[0271] In some embodiments, the manufacturer may send a "video" or a link to a website for instructions on calibrating the device to the remote interface 1800, 1900. In some embodiments, a "video" or other animation may be available on the remote interface 1800, 1900 itself, which may include, without limitation, a video or animation to show / explain and / or "walk through" a user and / or caregiver responding to an alarm and / or other action on the device 1802, 1902, 1804, 1904, 1806, 1906 and / or the device's remote interface 1800, 1900 (see, e.g., FIGS. 29A-29F of some embodiments).

[0272] Additionally, in some embodiments, the remote interface 1800, 1900 may include the ability to compile a list of approved addresses for sending secure information, which may include, but is not limited to, medical information. Thus, if a user unintentionally enters an incorrect email address or web address, etc., the remote interface 1800, 1900 may prevent the user from being able to send secure information without further steps, which may include, for example, entering a new address on the approved address list. In some embodiments, alteration of the list may be password or other (tap, fingerprint, etc.) protected.

[0273] In some embodiments, the status of one or more of the devices (i.e., the CGM sensor / transmitter 1804, 1904 and / or the infusion pump 1802, 1902 and / or the blood glucose meter 1806, 1906), which may include, but are not limited to, a current glucose reading, may be indicated through an audio tone through an earphone connected to the remote interface 1800, 1900 and / or a speaker on the remote interface 1800, 1900.

[0274] In some embodiments, the devices 1802, 1902, 1804, 1904, 1806, 1906 may communicate with the remote interface 1800, 1900 using an acoustic signal coupled with a radio signal, so-called "thunder and flash", to indicate the proximity of one or more of the devices. In some embodiments, a message may be transmitted by a first device to a second device using a radio signal. This radio signal may be simultaneously coupled with an ultrasonic "chirp". This 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 the remote interface 1800, 1900 are at an appropriate distance from the device, which may indicate whether a user of the device's remote interface 1800, 1900 is sending a message, or whether another (i.e., non-user) remote interface and / or device is sending a message. This may be used to ensure the safety of communication and control of one or more of the devices by the remote interface 1800, 1900. For example, if a user is sending a signal / communication from its remote interface 1800, 1900 to its infusion pump 1802, 1902, this may ensure that the user is wearing the infusion pump 1802, 1902 since the remote interface 1800, 1900 cannot be more than a certain distance, e.g., 4 feet, from the infusion pump 1802, 1902. Thus, if the system determines and / or calculates, using the methods described above, that the remote interface 1800, 1900 is more than a threshold distance (which in some embodiments may be pre-determined and / or pre-set by either the manufacturer and / or the user, which in some embodiments may be based, for example, on the user's own measurements and / or length of tubing) from the infusion pump 1802, 1902, the remote interface 1800, 1900 may warn / alarm and / or notify the user.In some embodiments, the alarm / warning may also include a message stating that an unidentified device is attempting to communicate with the infusion pump 1802, 1902. Thus, this may be one way for the remote interface 1800, 1900 to determine if a communication being received and / or transmitted to a device in the system is from an "approved device", i.e., a device that the user has installed in the system, i.e., paired to the remote interface 1800, 1900 and / or paired to another device that may be paired with the remote interface 1800, 1900.

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

[0276] In some embodiments, information uploaded from the remote interface 1800, 1900 to the web portal / personal computer 1808, 1909 may also be synchronized with an electronic calendar, such as, but not limited to, OUTLOOK Calendar or other. 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 provide relevance and breadth to the data for analysis. Also, even if the user has not entered an event into the remote interface 1800, 1900, if the event is on the electronic calendar, the event may be automatically entered with the data for review and analysis. For example, if a user's calendar may indicate "soccer practice," but during soccer practice the user did not indicate the event on the remote interface 1800, 1900, upon upload of data from the remote interface 1800, 1900 to the web portal / personal computer 1808, 1908, the data from the remote interface 1800, 1900 may incorporate the event "soccer practice" into a software program designed to easily view information and data from the device, for example, above an area representing the amount of fluid delivered (which may be a basal rate) and blood glucose data, for example, data from a CGM sensor / transmitter 1804, 1904 and / or data from a blood glucose meter 1806, 1906. Thus, in one exemplary graph, the user may view a representation of what the user was doing at that time, along with, for example, drug delivery data, CGM, and blood glucose data.

[0277] Thus, the user may connect the remote interface 1800, 1900 to a personal computer 1808, 1908 and / or, in some embodiments, upload data from the remote interface 1800, 1900 to a web portal or otherwise. In some embodiments, this may be accomplished while "recharging" the remote interface 1800, 1900, which in some embodiments may be done using a USB connection to the personal computer 1808, 1908, and in addition to charging / recharging, the remote interface 1800, 1900 may sync and / or upload / download data from the personal computer 1808, 1908 and / or the web portal. At this point, the system may determine that software updates are available for one or more of the devices and / or the remote interface 1800, 1900. The user may select "download updates" and these may be downloaded to the remote interface 1800, 1900 again upon charging and / or any time the remote interface 1800, 1900 is connected, either directly or indirectly, to a personal computer 1808, 1908 and / or a web portal designed specifically for the system. As discussed above, the remote interface 1800, 1900 is capable of communicating with a variety of devices. Thus, software updates may be communicated by the remote interface 1800, 1900 to any one or more of the devices. This has many advantages, including but not limited to only needing to connect the remote interface 1800, 1900 to a personal computer / web portal 1808, 1908 to both upload data / information from all of the devices and / or download updates and / or applications from the personal computer and / or the internet / web portal to any of the devices.This may be desirable for a number of reasons, including, but not limited to, the ability to efficiently and easily update all devices from one connection, and / or the ability to view all of the data from all devices in one place, and / or the ability to download information and / or settings from a personal computer / web portal to any of the devices through a remote interface.

[0278] Thus, in some embodiments, a new "remote interface" may be introduced to the system, since from time to time the personal computer / web portal contains all information from all devices, including but not limited to the remote interfaces. This may be accomplished 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 first require that the old remote interface be removed from the "approved devices", 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 capable of communicating with the devices and is capable of connecting 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, a user can turn any device (including some parameters such as the ability to wirelessly communicate and connect to a personal computer and / or web portal) into a variety of devices, e.g., devices that can control an infusion pump and / or receive data from and / or control a CGM sensor / transmitter and / or other analyte sensors and / or other devices. In some embodiments, the remote interface and / or one or more applications on the remote interface may be password or otherwise protected and paired with one or more devices, e.g., paired with an infusion pump and / or a CGM sensor and / or one or more other devices.

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

[0281] In some embodiments of the system, a blood glucose meter 1806, 1906 may be included, which may include only a strip reader and minimal components to function, but not a user interface. In some embodiments, the blood glucose meter 1806, 1906 communicates with a remote interface 1800, 1900, the remote interface 1800, 1900 displays readings, and / or in some embodiments, the remote interface 1800, 1900 includes a broader range of functionality than the blood glucose meter 1806, 1906, which may include, but is not limited to, graphical representations of the blood glucose meter 1806, 1906 readings and / or historical data and user preferences, etc.

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

[0283] As discussed above, in various embodiments, the remote interface 1800, 1900 may include a tablet computer or a multi-function 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 "sleep" while the remote interface is communicating with one or more of the devices in the system, for example, a medical device. In some embodiments, the antenna and / or wireless communication software may be modified, for example, to a proprietary version as described above or in any of the information incorporated by reference. In some embodiments, the wireless communication may be one within the remote interface device itself, for example, a BLUETOOTH® low energy wireless communication protocol. In some embodiments, along with this communication protocol, a conversion device may be included to change to a proprietary protocol on one or more of the devices in the system. In some embodiments, messaging may be accomplished through the protocols discussed herein, or through similar protocols, and / or using protocols from the remote interface device.

[0284] The remote interface thus includes a display assembly, which in various embodiments may include a color touch screen. In some embodiments, the remote interface additionally includes at least one switch assembly. In some embodiments, the remote interface includes animated "setup" instructions for one or more devices. Additionally, in some embodiments, the remote interface includes alarm recovery and / or alarm animations, which may include, but are not limited to, instructions to a user to check and / or confirm and / or recover from an alarm condition. These animations may include, but are not limited to, written / textual instructions and / or audio instructions. In some embodiments, the graphical user interface may present different color backgrounds to represent different states, e.g., "red" for alarm, "blue" for idle, "green" for delivery / action, etc. In some embodiments, one or more of the aforementioned functions may additionally include sounds / audio, which may include, but are not limited to, audio instructions, beeps, etc.

[0285] 20A-30, various "screenshots" are depicted that serve as some embodiments of a graphical user interface for a remote interface for an infusion pump, such as one of the embodiments of the infusion pump described herein. In some embodiments, a screen shot for a remote interface for a blood glucose meter is shown. In some embodiments, the screen may be used as an instruction interface.

[0286] 20A-22H, in some embodiments, the remote interface may include video and / or photographic / graphical instructions to demonstrate to the user how to perform certain actions on the device. In some embodiments, these video and / or photographic / graphical instructions may include narration and / or audio, and / or may include text and written instructions. FIGS. 20A-22H include some embodiments and / or example embodiments of a graphical user interface (GUI) for configuring an infusion pump. These examples 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 vary throughout the embodiments. Additionally, in some embodiments, the various screenshots may include one or more of the following buttons: "back," "cancel," and / or "next" buttons. In these embodiments, on any screen, the user may select to go back, cancel the screen, and / or proceed to the next screen. In some embodiments where a video is included, 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] 20A-20M, graphical instructions for filling the disposable portion (which may also be referred to as a reservoir) and priming the disposable portion are shown. Referring now to FIG. 20A, some embodiments include at least one screen instructing the user to wash their hands. In some embodiments, at least one screen is included showing the user washing their hands and may instruct the user to wash their hands with soap and hot water. In some embodiments, the screen may include an animation showing the user washing their hands with soap and water. Referring now to FIG. 20B, some embodiments include at least one screen instructing the user to remove the cover and lid of the disposable portion. In some embodiments, the screen may show the disposable portion. In this embodiment, the screen shows an embodiment of the disposable portion in packaging and instructs the user to remove the cover and lid from the package. In some embodiments, this embodiment is an animation, and in some embodiments, the graphical animation shows the cover and lid being removed from the package. Referring now to FIG. 20C, some embodiments include at least one screenshot showing the base of the package being attached to the lid. In some embodiments, the embodiment is an animation, and in some embodiments, the graphical animation shows the base of the package being attached to the lid. Now referring to FIG. 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 a vial and an alcohol swab and instructs the user to clean the top of the insulin vial with the alcohol swab. In some embodiments, the embodiment is an animation of the vial being cleaned with the alcohol swab. Now referring to FIG. 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 the package and instructs the user to remove the syringe from the package and connect the needle. In some embodiments, the embodiment is an animation of the syringe being removed from the package and the needle being connected.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 up to a three day supply of insulin. The reservoir can hold up to 3 mL. Remove any air bubbles in the syringe. In some embodiments, this embodiment is an animation of the syringe being filled with insulin from a vial.

[0288] Referring now to FIG. 30, in some embodiments, at least one screen may be included that may show a syringe filled with fluid ("filled" does not necessarily mean volume, as "filled" may be used to refer to any volume of fluid loaded into the syringe and / or reservoir) and an embodiment of a remote interface held by a user and placed in proximity to the syringe that takes a picture of the syringe. In some embodiments, this embodiment is an animation of the remote interface and the syringe, where the remote interface takes a picture of the syringe. In some embodiments, the at least one screen may prompt the user to take a picture of the syringe. In some embodiments, when the user reaches this screen, the remote interface may automatically enter a camera mode so that the user may then look at a viewfinder in the display assembly and take a picture of the filled syringe. In some embodiments, the remote interface may check to see if the picture is acceptable. In some embodiments, when the remote interface enters the camera mode from the "Take a photo of the filled syringe" screen, the camera mode may go into "auto-focus" mode and / or in some embodiments may go into a dedicated camera mode designed to take a photo at a resolution such that pattern recognition software designed specifically for this task 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, such as, for example, to scan 2D barcodes on disposable and / or reusable parts (e.g., in some embodiments, this may be used for devices paired with the remote interface) and / or to scan 2D barcodes on insulin and / or infusible fluid vials and / or other peripherals that may be used in various embodiments of the system, whether the system includes an infusion pump.

[0289] 31-34, in some embodiments, the basal profile may be entered into the remote interface using a camera in the remote interface 3004 and a barcode 3000, including but not limited to a 2D barcode (see item 3000 in FIG. 31 and item 3002 in FIG. 32, examples of which are provided for illustrative purposes only). In various embodiments, the 2D barcode may be generated by a prescription by the user's physician. In some embodiments, the 2D barcode may be communicated to the user, which communication mechanism may include but 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 barcode 3000, 3002. The 2D barcode includes an embedded prescription basal profile embedded within the 2D barcode, which when read by barcode reading software provides the information required by the remote interface and programs the basal profile. An example of information contained within a 2D barcode that may be included is shown in FIG. 33 as 3006. 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 when the expiration date approaches so that the user may prompt their physician to enter an updated basal profile 2D barcode as discussed above. In various embodiments, once the validity of the profile has expired, the remote interface may stop pumping unless an updated profile prescription is entered. In various embodiments, the user may receive multiple 2D barcodes, each containing a different basal profile, which may include, for example, but is not limited to, weekdays, weekends, exercise, sick days, etc. In some embodiments, a single 2D barcode may encode more than one basal profile.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., when a user manually enters a prescription, there may be duplication errors). However, using 2D barcodes, programming errors are eliminated and thus the system may be more secure than manual entry. In addition, the system may be beneficial for prescriptions that may be emailed and / or made available to the user electronically, for example, in 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 prescription barcodes from being read and programmed into the wrong remote interface. In some embodiments, once the remote interface 3004 reads the 2D barcode 3000, 3002, the remote interface 3004 may display the basal profile in graphical form for the user to review.

[0290] 34, in some embodiments, the remote interface 3004 may use a camera to take a picture of the basal profile 3008 in graphical form, whether presented on paper or in electronic form. The remote interface 3004 may, in some embodiments, include recognition software that may recognize the parameters of the basal profile 3008 and program the basal profile 3008 into the remote interface 3004 such that the intended basal 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 (e.g., when a user manually enters a prescription, there may be duplication errors). However, using a basal profile 3008 read by the remote interface 3004, programming errors are eliminated and thus the system may be safer than manual entry. In some embodiments, once the remote interface 3004 reads the basal profile 3004, the remote interface 3004 may display the basal profile 3008 in graphical form for the user to review. In some embodiments, the system may require a passcode / password to be entered before the system can read the basal profile 3008. This may be beneficial to prevent prescription basal profiles from being read and programmed into a remote interface without the user's consent.

[0291] 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 in the reservoir package and instruct the user to insert the syringe into the filling aid and transfer insulin to the base reservoir (the syringe is not removed yet). In some embodiments, this embodiment is an animation of the syringe being inserted into the filling aid and moving the plunger towards the base, transferring insulin to the base reservoir.

[0292] 20H, some embodiments include at least one screen showing a syringe removing bubbles from a filled reservoir. In this embodiment, the screen shows an embodiment of a syringe in a filling aid in the reservoir package and instructs the user to check the reservoir for bubbles and pull any air bubbles back into the syringe. In some embodiments, this embodiment is an animation of the user checking the reservoir for bubbles and pulling any air bubbles back into the syringe.

[0293] 20I, some embodiments include at least one screen showing a syringe and a "sharps" container. In this embodiment, the screen shows an embodiment in which a user holds the syringe adjacent to the sharps container and instructs the user to remove the syringe and discard the needle in the sharps container. In some embodiments, this embodiment is an animation of the user removing the syringe and discarding the needle in the sharps container.

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

[0295] Referring now to FIG. 20K, in some embodiments the user interface may include at least one confirmation screen along with the reservoir volume, and in some embodiments may include a button to "Modify Reservoir Volume," which in some embodiments may direct the user to a screen for inputting a different volume value, such as the screen shown in FIG. 20J.

[0296] 20L, some embodiments include at least one screen instructing the user to prime the disposable part. In this embodiment, the screen shows a thumb / hand pressing down on the filling aid on the disposable part / reservoir and a caption of the infusion set connector, and instructs the user to press and hold the prime button on the filling aid until a drop of insulin is visible from the infusion set connector. In some embodiments, this embodiment is an animation of a thumb / hand pressing and holding the prime button on the filling aid until a drop of insulin is visible from the infusion set connector.

[0297] 20M, some embodiments include at least one screen instructing the user to remove the filling aid. In this embodiment, the screen shows a hand rotating the filling aid on the disposable part / reservoir and instructs the user to remove the filling aid from the base by rotating the filling aid counterclockwise and discard the filling aid. In some embodiments, this embodiment is an animation of a hand rotating the filling aid counterclockwise to remove the filling aid from the base and discard the filling aid.

[0298] 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 illustrations / captions that show the user attaching the pump to the base, which may be close-ups of the "locked" and "unlocked" position icons, and instructs the user to first remove the protective dust cover or charger, then attach the pump to the base and rotate it to the locked position. Once the pump detects that the base is in place, it will play a confirmation tone. In some embodiments, this embodiment is an animation of a hand first removing the protective dust cover or charger, then attaching the pump to the base and rotating it to the locked position.

[0299] 20O, some embodiments include at least one screen instructing the user to press a pump button. In this embodiment, the screen shows the user pressing a pump button on the reusable portion and instructs the user to activate the pump by pressing and holding the pump button. When activated, the pump button will play a sound. In some embodiments, this embodiment is an animation of a hand activating the pump by pressing and holding the pump button.

[0300] 20P, some embodiments include at least one screen that indicates to the user that the pump has been activated. In this embodiment, the screen shows the pump vibrating or playing a sound, and instructs the user that the pump has been activated and to press the next button and proceed to setup.

[0301] 20Q, some embodiments include at least one screen that requests the user to start a pump test. In this embodiment, the screen shows a caution sign instructing the user to make sure the cannula is not connected to a tubing set (the pump test will deliver a small amount of insulin). A button on the screen indicates that the user should follow the caution and then press to start the pump test.

[0302] 20R, some embodiments include at least one screen indicating that the pump is performing a pump self-test. In this embodiment, the screen shows a caution sign instructing the user to make sure 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] Referring now to FIG. 20S, some embodiments include at least one screen noting that the pump test is complete. In this embodiment, the screen shows a "check mark" to indicate that the test 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, which in some embodiments may indicate that the system is suggesting to proceed or abort. Referring now to FIG. 20T, some embodiments include at least one screen instructing the user to insert an infusion set per the manufacturer's instructions.

[0304] 21A, some embodiments include at least one screen that instructs the user to attach the VELCRO to the pump. As previously mentioned, in some embodiments (e.g., as described and illustrated with respect to FIG. 3), the disposable portion may include an adhesive patch, which in some embodiments may include a VELCRO fastening system. In this embodiment, the screen shows the user touching the backing of the patch on the underside of the disposable portion and instructs the user to remove the backing and attach a smaller VELCRO patch to the underside of the base. In some embodiments, this embodiment is an animation of a hand removing the backing and attaching a smaller VELCRO patch to the underside of the base.

[0305] 21A, some embodiments include at least one screen that instructs the user to attach the VELCRO to the pump. As previously mentioned, in some embodiments (e.g., as described and illustrated with respect to FIG. 3), the disposable portion may include an adhesive patch, which in some embodiments may include a VELCRO fastening system. In this embodiment, the screen shows the user touching the backing of the patch on the underside of the disposable portion and instructs the user to remove the backing and attach the smaller VELCRO patch to the underside of the base. In some embodiments, the embodiment includes an animation of a hand removing the backing and attaching the smaller VELCRO patch to the underside of the base.

[0306] 21B, some embodiments include at least one screen that instructs the user to attach the patch to the user's body. As previously mentioned, in some embodiments (e.g., as described and illustrated with respect to FIG. 3), the disposable portion may include an adhesive patch, which in some embodiments may include a VELCRO fastening system, that attaches to the body. In this embodiment, the screen shows the backing of the larger patch and the user touching the larger patch, and instructs 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 an animation of hands removing the backing, attaching the larger VELCRO patch to the body, and attaching the pump to the patch.

[0307] 21C, some embodiments include at least one screen instructing the user to remove the infusion set cap. In this embodiment, the screen shows the user removing the infusion set cap and instructs the user to squeeze two tabs on the infusion set and remove the protective cap. In some embodiments, this embodiment is an animation of a hand squeezing two tabs on the infusion set and removing the protective cap.

[0308] 21D, some embodiments include at least one screen instructing 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 an animation of a hand connecting the infusion set to the cannula.

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

[0310] 22A, some embodiments include at least one screen to show the cannula priming in progress. In this embodiment, the screen shows the delivered priming volume and the total priming volume, and includes a button to stop priming. The screen also includes a status bar that represents the delivered volume of the total priming volume requested.

[0311] 22B, some embodiments include at least one screen to confirm that cannula priming is complete. Referring to FIG. 22D, some embodiments include at least one screen to confirm that setup is complete and includes a button to start a basal rate. In some embodiments, this screen appears automatically after setup is complete, which can be beneficial for a number of reasons, including but not limited to, reminding the user to start an infusion pump based basal rate.

[0312] 23A, some embodiments include at least one screen for programming a basal profile. In the embodiment shown, to program a basal profile, the user enters a rate, which in some embodiments may be a volume (hourly), and a start and end time. In various embodiments, the user may create basal profiles for different days of the week (e.g., a Monday profile, etc.), and / or for weekdays, and / or weekends, and / or create custom profiles for events (e.g., skiing).

[0313] Referring now to FIG. 23B, some embodiments include at least one screen for visually reviewing the daily basal profile, which may include both a graphical representation of the circadian cycle and also an indication of the current ratios at the time of checking.

[0314] 23C and 23D, some embodiments include at least one basal profile screen that includes buttons containing each rate for a range of times in a 24-hour cycle, for example. In some embodiments, the user may select a button that represents one of the time ranges and directs the user to a screen for editing that particular time frame. In some embodiments, the screen may additionally include a graphical representation at the top of both the current basal profile and the current time frame.

[0315] 24A and 24B, in some embodiments, the remote interface may either be wirelessly connected to and / or include a blood glucose meter. When a user takes a blood glucose reading, in some embodiments, the screen shown in FIG. 24A is automatically visible. In some embodiments, the screen may include buttons representing possible "tags" (screen button showing "Lunch") that are automatically based on the time of day, as shown in FIG. 24A, for example. However, the user may edit this tag. For example, the user may select the button "Add / Edit" and the user may be directed to a screen similar to that shown in FIG. 24B. The notes and tags editing screen may include an area for custom editing (i.e., an edit box) into which the user may type comments. The tag list may include custom tags that the user may preprogram into the user settings, 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 may be edited.

[0316] 25A and 25B, some embodiments may include a screen where the user manually inputs a blood glucose reading, as shown in FIG. 25A. In some embodiments, after input and selecting "next," a label screen, for example as shown in FIG. 25B, may allow the user to select a label. The label list may include custom tags that the user may preprogram into the user settings, either by using a personal computer / web portal or by using a remote interface. In some embodiments, the settings for the GUI may include default labels, which may be edited.

[0317] In some embodiments, in response to manually entering a blood glucose value, e.g., using a screen such as that shown in FIG. 25A, the user interface may indicate the amount of carbohydrates the user should consume. For example, if the user enters "40 mg / dL," the system may calculate the amount of carbohydrates to treat hypoglycemia by using the correction information entered for the user profile (i.e., the amount of carbohydrates used to treat hypoglycemia, which may be determined by the user with their healthcare provider). In some embodiments, the remote interface may be pre-programmed to treat hypoglycemia with specific instructions, e.g., 15 skittles (e.g., or any other confectionery, i.e., glucose item) and 4 ounces of apple juice (however, in some embodiments, these may be different) (all of which may be entered by the user into the user profile, either through the remote interface or a personal computer / web portal), and the user interface may show the user a picture of a food item, e.g., 15 skittles and / or 4 ounces of apple juice, in response to entering a hypoglycemic glucose number (which 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 quick and easy treatment of a hypoglycemic event (the user may quickly figure out what food to eat to treat the hypoglycemic event, and / or the user may show a picture to a friend or another person and request that food be provided). In some embodiments, this may be particularly beneficial in countries where the user does not speak the local language.

[0318] 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, e.g., foods eaten and / or activity and / or labels and / or tags, or any other indication the user has tagged or labeled the reading. In some embodiments, a "Graph" tab may be accessible from the glucose screen to view a graph of the blood glucose values. In some embodiments, the graph may be interactive, and the user may touch a point or location on the graph, which will take the user to a screen with further details and / or time periods for input, etc. In some embodiments, the GUI may show continuous glucose monitor (CGM), blood glucose meter (BGM), and infusion pump volumes on the same graph.

[0319] In some embodiments, the graphical user interface may include one or more screens for programming a bolus. Referring now to Figures 26A-26D, in some embodiments, the user may input and select an item from a food library, which may include custom input by the user (either using the remote interface and / or downloading the food library from the web and / or completing custom input on a personal computer and / or web portal and downloading / synchronizing with the remote interface) and / or may include default input, as discussed above. In some embodiments, the user may navigate to a food library screen (e.g., in some embodiments, the screen may resemble the screens shown in Figures 26K and 26L), select a food, and / or select "keypad" and type the food into a search screen, and then another screen, e.g., in some embodiments, the one shown in Figure 26A or similar thereto, may request the user to input the amount 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, but not limited to, one or more of carbohydrates, fat, and / or calories. In some embodiments, if the food item is not selected from the food library, a confirmation screen will be shown to the user that, in some embodiments, may resemble an embodiment of the screen shown in FIG. 26M.

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

[0321] In some embodiments, the user may choose to enter the units of insulin required for the bolus rather than entering a carbohydrate or food item and amount. In some embodiments, this may be accomplished using a keypad screen, which may be similar to the screen shown in FIG. 26N, for example. Once the user has entered the volume required, the user may select "OK" and a screen, which may be similar to that shown in FIG. 26B, may indicate to the user that the remote interface is establishing wireless communication with the infusion pump.

[0322] In some embodiments, during the bolus process, the remote interface may show a screen containing the most recent blood glucose meter result, and in some embodiments, may show the user the time the test was taken and also the time since the test. In some embodiments, the screen may be similar to the screen in FIG. 26H. In some embodiments, the screen may prompt the user to confirm whether they want the bolus calculator to use this most recent glucose test for the correction portion of the bolus. The user may, in some embodiments, select "No, retest," in which case the user interface may open a blood glucose meter screen. In some embodiments, the user may select "No, skip correction bolus," in which case the bolus calculator will not use that value and will not automatically take the user to the blood glucose meter screen. In some embodiments, the user may select "OK," and the bolus process may continue.

[0323] In either case, once the user has entered all of the information they wish to enter regarding the bolus, which may include, but is not limited to, one or more of carbohydrate value, food item, blood glucose value, and / or units of insulin volume required, the user interface presents a summary screen, which in some embodiments may be similar to the embodiment shown in FIG. 26I, showing recommendations for each of the bolus categories, e.g., meal bolus (for food), correction bolus (for glucose), showing the user the remaining bolus amount (which in some embodiments may also be referred to as the remaining insulin amount or IOB), and showing the recommended total bolus. The user may navigate from this window and adjust the total bolus to be delivered, e.g., by touching the "Total Bolus" area of ​​the screen and adjusting the per unit value. In some embodiments, this may be done using a keypad. In some embodiments, this may be done using a slide adjustment GUI, which in some embodiments may be similar to that shown in FIG. 26G. In this embodiment, the recommended total amount, e.g., 3.51 units, is shown in the "Bolus Amount Correction" box 2600. The user may adjust the total volume by moving the slider 2602. For example, as the user slides the slider 2602 toward the left, the total amount in the bolus amount modification box 2600 decreases and the percentage of the decrease is represented in the bolus amount modification box 2600. For example, as the user slides the slider 2602 toward the right, the total amount in the bolus amount modification box 2600 increases and the percentage of the increase is represented in the bolus amount modification box 2600. This may be desirable for a number of reasons, including, but not limited to, if the user wishes to increase or decrease the recommended bolus amount by a given percentage, e.g., decrease by 20% during pre-workout and / or increase by 40% during illness, the bolus amount modification box 2600 makes 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 the volume to be delivered.

[0324] However, if the user wishes to proceed from the review recommendation screen, the user may navigate using the "Next" button in some embodiments. If the user navigates from the bolus amount modification screen, the user may use the "OK" button in some embodiments. In some embodiments, the user will be directed to a screen that allows the user to determine how the bolus is delivered: normal, extended, or combination. Now, referring to FIGS. 26E and 26F, the total volume of insulin to be delivered may be delivered as a normal bolus as a default in some embodiments, unless the user modifies it to add at least a percentage to be delivered as an extended bolus. In some embodiments, depending on the inputs of the screen shown in FIG. 26E, normal 2604 may include the total amount recommended and extended 2608 may include 0.00 units. The total units to be delivered 2606 may be shown below the slider 2610. Normal 2604 and extended 2608 may also, in some embodiments, include a percentage representing the percentage of the total that will be delivered in that mode, ie, either normal or extended.

[0325] A user may adjust the total volume that can be delivered as normal 2604 and extended 2608 by moving slider 2610. For example, as a user slides slider 2610 toward the left, the percentage of the total amount and the sum in normal 2604 increases and the percentage of the total amount and the sum in extended 2608 decreases. However, for example, as a user slides slider 2610 toward the right, the percentage of the total amount and the sum in extended 2608 increases and the percentage of the total amount and the sum in normal 2604 decreases. This may be desirable for a number of reasons, including, but not limited to, if a user desires to deliver a particular percentage as extended, for example, if the user desires to deliver 80% as extended, the user may slide slider 2610 to the right until the percentage in extended 2608 indicates "80%." Also, if the user desires to deliver a particular volume, for example 1.0 unit, as normal (which may be desired in many situations including, but not limited to, when the user desires to deliver the total volume due to a correction bolus as normal), the user may slide slider 2610 toward the right until the volume in normal 2604 is 1.00 unit. In some embodiments, the direction of slider 2610 with respect to normal 2604 and / or the increment / decrement under extension 2608 may be different.

[0326] 26F, if any percentage or volume of the bolus is selected to be delivered as extended, in some embodiments, a screen similar to that shown in FIG. 26F may be presented to the user after selecting "Next" from the Normal and Extended Bolus Volume screen. The user may enter the amount of time for which the extended volume (from FIG. 26E) should be delivered as an extended bolus. In some embodiments, as the user slides slider 2612 to the right, the time for the extended bolus increases, and as the user slides slider 2612 to the left, the time for the extended bolus decreases. In some embodiments, the direction of slider 2612 with respect to increasing and decreasing the time may be different. In some embodiments, a duration screen such as that shown in FIG. 26F may open with a default time, e.g., 1 hour, and allow the user to modify. In some embodiments, the default may be the most recent programmed extended bolus.

[0327] Once the user has programmed the method for delivery of the bolus volume, the user may, in some embodiments, select "OK" and a bolus settings review screen may become visible, for example, similar to that illustrated in FIG. 26C in some embodiments. In some embodiments, the bolus settings review screen provides the total bolus amount to be delivered, the method of delivery, the total volume to be delivered as normal, and the total volume to be delivered as extended, and if there is a volume to be delivered as extended, the duration of the extended bolus may be indicated. The user thus has the opportunity to explicitly review the bolus volume and the method of delivery. 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 potentially reducing the occurrence of accidental or unintentional tapping of the "Confirm" button. Thus, the action to "stop" using the Stop button, i.e., tapping, is a completely different action than "confirm", i.e., sliding. Also, the location of the "Confirm" button and slide, which are in a very different location from the "Stop" button, may prevent unintentional stopping. Thus, the method may reduce unintentional discontinuation and also unintentional delivery when discontinuation is desired. Also, in some embodiments, the location of the "Next" or "OK" button is in a similar location on many screens. Thus, when a therapy change is made, to prevent unintentional confirmation, in some embodiments, the system requires a different action, e.g., a slide rather than a touch / tap, and in addition, in some embodiments, the start of the slide is opposite the "Next" or "OK" button.

[0328] There are many advantages to this method of programming the bolus volume, including but not limited to the following: The user may first determine the volume of the bolus and then subsequently determine the method of delivery. Thus, the user does not need to determine that the bolus is to be "extended" before, for example, entering carbohydrate / food and / or blood glucose values, as previously described, in some situations where the user may wish to deliver the food bolus portion of the total bolus as an extended bolus and the correction portion of the total bolus as a normal bolus. Also, the slider embodiment shown in Figures 26G, 26E, and 26F allows the user to view the percentage change as well as the total volume at any given time. This method may therefore prevent miscalculation and allow for closer fine-tuning and customization of insulin therapy. Also, with regard to programming the duration of the extended bolus after the user has entered the portion of the bolus volume to be delivered as an extended bolus, the user may be less likely to "confirm" the delivery before modifying the duration.

[0329] 27A, 27B, 27C, and 27E, in various embodiments, the user interface includes various opportunities for the user to abort an action. In some embodiments, when the button "Abort" is pressed, another screen appears for the user to confirm that they wish to abort. This may be desirable, for example, so that if the user unintentionally taps the Abort button, the user has the opportunity to continue rather than abort.

[0330] 27F and 27G, in some embodiments, while a bolus is active, e.g., in the previous example, part of the bolus may be delivered as normal and part as extended, the user interface may include a "Delivery in Progress" screen that indicates the status of the active delivery. For example, in some embodiments, as shown in FIG. 27F, the delivered volume and the total volume to be delivered 2716 may be shown, with a status bar 2714 representing the delivered volume as a function of the total volume to be delivered. Additionally, in some embodiments, the Delivery in Progress screen may also include a current basal profile 2718, which may show both the profile name, e.g., "Weekday," and the preprogrammed basal 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 in progress screen, for example, in some embodiments may resemble the delivery in progress screen shown in Figure 27F. In some embodiments, whenever an active bolus is being delivered, the home screen (which in some embodiments may resemble the delivery in progress screen, as described above) freezes and does not time out.

[0332] In some embodiments, while the infusion pump is delivering, the delivering screen and / or various screens of the user interface may include a different splash screen and / or background screen to visually indicate to the user that delivery is occurring. In some embodiments, the background may be "green" to indicate delivery. However, this is just one embodiment and other embodiments for indicating and / or distinguishing the infusion pump status may be used.

[0333] 27F, in some embodiments, while the infusion pump is delivering a bolus, a "Stop Bolus" button 2720 may be included on the delivery screen. In some embodiments, the stop bolus button 2720 may be a different color than the rest of the screen, for example, in some embodiments the stop bolus button 2720 may be red.

[0334] 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 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 they also stop the bolus, which may be desirable because it may indicate that all insulin delivery should be stopped if the user wishes to stop the delivery of basal insulin. The stop basal pop-up screen 2722 reminds the user that a bolus delivery is in progress if they are not aware of it when selecting to begin the process for "stop basal".

[0335] 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, asking the user to confirm that they want to stop the delivery of basal insulin. In some embodiments, the infusion pump may not allow the user to stop the bolus unless they also stop the basal, which may be desirable because if the user wants to stop the delivery of bolus insulin, this may indicate that all insulin delivery should be stopped. Referring to FIG. 27H, in some embodiments, if the user selects to stop the bolus, a confirmation screen for stopping may appear, showing the units 2726 delivered of the programmed total volume.

[0336] 28A, an embodiment of a home screen is shown. In the embodiment shown, the home screen shows several different information, and in some embodiments, the amount of information on the home screen may vary. However, in some embodiments, an infusion pump status indication 2800, such as that the infusion pump is delivering; an indication of the active basal profile 2802; an indication of the remaining bolus amount 2804; an indication of the last glucose result 2806, which in some embodiments includes the time of the last result; the volume of insulin remaining in the reservoir 2808; the percentage of remaining pump battery life 2810; battery value 2814 (which may include a battery level indication); current time 2818; connection status 2816; and the section of the user interface in which the page resides 2812 may include information on the home screen, however, in various other embodiments, one or more of that 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 indication to easily indicate its status; for example, the backsplash of the page may be a different color depending on the status. In some embodiments, the delivering status may be green, the glucose status may be orange, the alarm status may be red, and the idle status may be blue. In these embodiments, the status of the infusion pump may be learned by the user regardless of the screen. An embodiment of an alarm status screen may be found in FIG. 29A-29F, and an embodiment of an idle screen may be found in FIG. 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 for an extended period of time. Thus, in some embodiments, when the infusion pump is idle, the home screen shows an idle status 2828, and the idle status home screen includes a large button for "Start Basal" 2830.

[0338] In some embodiments, one or more of the screens may include icon buttons to navigate to a particular screen, such as, for example, Home 2812, Glucose 2820, Bolus or Basal 2822, Logbook 2824, and / or Settings 2826. Examples of one embodiment of these screens are shown as: Home (FIG. 29A), Glucose (FIG. 28B), Insulin (e.g., Bolus or Basal) (FIGS. 28D-28G), Logbook (FIG. 28H), and / or Settings (FIG. 28I).

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

[0340] 29A-29F, an embodiment of an occlusion detection alarm is shown. In some embodiments, as discussed above, the alarm condition may transform into a different backsplash / background or color, i.e., the backsplash of the screen may be red to indicate the alarm condition. In some embodiments, once an alarm condition is sensed by the system, the system may provide a series of GUI screens to assist the user in restoring and / or confirming the alarm condition. For example, in FIG. 29A, in some embodiments, the screen may indicate that the flow of insulin has been blocked and therefore an occlusion condition exists. In some embodiments, the user may select "Next" and the GUI may walk the user through the recommended actions step by step. For example, in some embodiments, for example, in FIG. 29B, the screen may remind the user to check their blood glucose. With reference to FIGS. 29C and 29D, the screen may instruct the user to initiate a pump test (e.g., to determine if the occlusion is in the disposable portion or the cannula). The pump test may determine if the disposable portion has an occlusion in some embodiments. Before initiating a pump test, in some embodiments, a screen reminds the user to disconnect from the tubing set. Next, referring to FIGS. 29E and 29F, in some embodiments, the system may determine that the occlusion is not in the disposable portion and remind the user to replace the cannula. In some embodiments, the system may automatically initiate a series of screens, including those described above and in some embodiments, including animations, reminding the user to connect a new cannula (and prime the new cannula, etc.). In some embodiments, if the system determines that the occlusion is in the disposable portion, the system may prompt the user to replace the disposable portion.

[0341] Various embodiments of the system therefore include one or more devices and a remote interface. 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 recharging device and / or a remote interface for recharging and / or a device for recharging one or more devices. In some embodiments, during recharging, the device and / or the remote interface may receive software updates / downloads and / or synchronize with a database. In some embodiments, the recharging device and / or the 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 infusion pump and / or other device, both of which in some embodiments 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 of the two reusable parts is being recharged. Swapping the first reusable part for the second reusable part may include the remote interface synchronizing data with the second reusable part as the second reusable part is used, so that it contains updated information. In some embodiments, each reusable part may include non-volatile memory and full control and command capabilities for 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 a user using the remote interface, however those commands are sent to the device, and in some embodiments, after the remote interface verifies that the device has received the information correctly, the device commands all actions, e.g., an infusion pump commands the delivery of an infusible fluid.

[0344] In some embodiments, for a user to change use from a first reusable part to a second reusable part, the user may indicate to the remote interface that they wish to change reusable parts. The first reusable part, while in use, sends current remaining insulin amount and / or remaining bolus amount (which may also be referred to as IOB) information to the remote interface. The remote interface receives this information and starts timing the time on the IOB information. When the second reusable part is connected to the remote interface, the remote interface sends the IOB information to the second reusable part along with a timestamp. The second reusable part checks the time on the IOB information. If the reusable part finds that the timestamps do not match (which in some embodiments may be an indication that the battery of the first reusable part is not functioning properly and / or was 100% depleted when placed on the charger), a message is sent to the remote interface to indicate to 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 portion may rely on the IOB information, and thus the IOB calculation may continue even during the swap from the first reusable portion to the second reusable portion. In cases where the timestamps do not match, in some embodiments, the IOB information may be deleted and the calculation starts over from 0 at the new set time, and the user is notified of this using the remote interface.

[0345] The remote interface may be used to communicate with at least one device. In some embodiments, the remote interface may be used to communicate with a variety of devices. This may be desirable for many reasons, including but not limited to user familiarity. Using a single remote interface, the software platform may be designed, and in many embodiments, designed to be similar in nature, so that a single user may master the various software / applications for the various devices without significant learning time. In addition, the remote interface may download full software updates for all of the devices with which it may communicate, 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 but not limited to maintaining the devices in a streamlined process and updating the devices in an efficient manner.

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

[0347] In some embodiments, the remote interface may be used to capture images that aid in controlling the device. For example, in some embodiments, the user may be instructed to take a picture of the filled syringe using a camera on the remote interface so that the remote interface (and user interface) can either verify the user-entered information regarding the volume of fluid in the filled syringe and / or determine the volume of fluid in the filled syringe. This may be beneficial for many reasons, including but not limited to, approximately the correct volume of fluid loaded into the reservoir, which in some embodiments may lead to additional safety for the user. In some embodiments, the infusion pump determines the volume of fluid remaining in the reservoir and alarms the user when the volume is less than 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 a no-medication event. Thus, if an incorrect volume of fluid is entered by the user as being transferred to the reservoir, the calculation of the volume of fluid in the reservoir may be inaccurate. This may be undesirable for many reasons, including, but not limited to, if the volume of fluid transferred to the reservoir is miscalculated to a higher number, the reservoir may deplete sooner than calculated, and thus the user may run out of medication in an unexpected manner. However, if the volume of fluid transferred to the reservoir is miscalculated to a lower number, the reservoir may deplete more slowly than calculated, and thus the user may replace the reservoir early, and thus discard unused fluid.

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

[0349] While the principles of the invention have been described herein, it should be understood by those skilled in the art that this description is made only by way of example and not as a limitation on the scope of the invention. In addition to the exemplary embodiments shown and described herein, other embodiments are contemplated within the scope of the invention. Modifications and substitutions made by those skilled in the art are also deemed to be within the scope of the invention.

Claims

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

Images