Patent for “Wireless communication to on-body medical devices”

Name: patent PC
Address: 4701 Patrick Henry Dr, Building #16, Santa Clara, CA, 95054, US
Telephone: 800-234-3032

Medical Device – Gary Searle, Deborah Burns, Bruce Burns, David Mason, Charles Hwang, Becton Dickinson and Co

What is a Software Medical Device for “Wireless communication to on-body medical devices”

Is Your Software a Medical Device for “Wireless communication to on-body medical devices”

Abstract for “Wireless communication to on-body medical devices”

“Systems, apparatuses and methods for wireless communication of medical devices within an on-body fluid delivery network are disclosed. On-body fluid delivery systems include a primary patch pumps that attaches a first infusion needle to a user, as well as performing a number of primary pump functions. A secondary patch pump is used to attach another infusion needle to the user. If an error condition is found with the primary patch pumps, the secondary patch pump can perform a number of secondary pump functions that are substantially identical to them.

Background for “Wireless communication to on-body medical devices”

A remotely controlled On-Body Medical device (OBMD), can be used to infuse insulin continuously to patients with diabetes. Each OBMD is no more viable so a user must use a UI that is paired with the OBMD in order to activate and deploy an ensuing OBMD.

“Also, modern OBMDs can be worn under clothes and attached to the patient’s body. As part of their daily routine, users change their OBMDs at regular intervals. A user might change their OBMD every third day if the OBMD reservoir is nearly empty. Most OBMDs can only be filled with one or two sizes of insulin reservoirs. This means that the insulin reservoir will not run out at the beginning of the day, or when the user is leaving their home. The user is faced with a dilemma: can they waste insulin by discarding their patch pump prematurely or risk their privacy and discretion by changing their patch pump publicly?

“Additionally electronic clocks used in remote controlled OBMDs with wireless communications, such as real-time clocks (RTCs), may vary due to inherent limitations in accuracy and ambient conditions like temperature or the such. In the current state-of-the art RTCs, the time delay can be as much as 2 minutes per annum. This is approximately one second more than three days.

“Lastly, the removal of non-viable current OBMDs may result in tissue damage. The adhesive can cause the skin to become more vulnerable to infection and render the area less suitable for infusion.

There are many products that can remove adhesive pads from the skin. However, these products are not available as standalone products. This creates many problems for the user. It is one more device the user must keep track of and can make it difficult to apply if the OBMD isn’t in line of sight. Many adhesive solvents such as siloxane can be flammable. Modern methods of siloxane use expose the solvent to the air and ambient environment, increasing the chance of ignition.

“Accordingly, a fluid delivery system is needed that allows for user discretion, reduces insulin waste, minimizes the number of steps involved in deploying each OBMD and ensures compliance with prescribed therapy.”

“Moreover, a fluid delivery system is required to detect failures and end-of-service conditions. This system must also be active in communication with other OBMDs within the system to provide uninterrupted therapy. This requirement also calls for a communication system that uses less power and thereby lowers both the OBMD’s and UI size.

“A system that reduces or eliminates the peel force and tissue injury associated with removing an OBMD’s adhesive pad is needed.” A method of adhesive removal must be integrated into the infusion device.

“The present invention aims to substantially address these and other concerns and to provide a greater level of discretion when the patients are in the general population, eliminate waste associated with discarding short-term therapeutic requirements, increase ease of use by eliminating all the steps required to deploy and activate ensuing OBMDs. Provide uninterrupted diagnostics and therapy for a patient with or without the assistance of a user interface. Improve therapeutic compliance by addressing unmet needs.

“Another object is the present invention to substantially address timing inaccuracies related to the RTCs for a UI or an OBMD fluid delivery system.”

“Another object is the invention to substantially reduce or eliminate tissue damage and peel force associated with removing an adhesive pad of an OBMD, and to decrease the risk that an adhesive solvent ignites when removing adhesive pads from skin.”

An illustrative embodiment can be used to deliver fluids on the body (subcutaneous, intradermal or otherwise). The primary patch pumps are adapted for attaching a first infusion catheter to a user. A secondary patch patch pump is adapted for attaching a second infusion needle to a user. If an error condition is detected, the secondary patch pumps can perform a plurality secondary patch-pump functions substantially similar to those of the primary patch pumps. A plurality of primary pump functions may include, at minimum, pairing with a user interface, filling with medicament, priming, initiating a dose or basal rate, and then entering a primary pump SLEEP mode.

“An illustrative method for on-body fluid delivery can use a primary user interface communicatively coupled to a secondary patch pump. The primary patch pump may include a first reservoir adapted with a fluid, a catheter, a pump adapted infusing the fluid from the first reservoir through a catheter, and a microcontroller that controls operations of the first pump.

One example of on-body fluid delivery is pairing the primary patch pump with the primary user interface. To determine if user instructions have been received at primary user interface, the primary patch pump can communicate to the primary user. If user instructions are received at the primary interface, machine instructions can then be sent to the primary pump via the primary user’s interface. The user instructions will be followed by a bolus dose and basal rate using the first microcontroller.

An example of on-body fluid delivery could also include the checking by primary patch pumps for error conditions. An alert mechanism can alert a user if an error condition is detected on the primary patch pumps. Relevant data can then be transferred from the primary patch pumps to the primary user interface. If an error is not detected by the primary patches pump, the relevant data can still be transferred from the primary patches pump to the primary users interface. This can be reverted to the initial step of the primary patches pump communicating with primary user interface.

An adhesive pad with adhesive can be used to adhere to skin. An adhesive removal apparatus may contain at least one adhesive solution reservoir within a base of the device. The at least one adhesive solver reservoir can contain adhesive solvent. The device can release the adhesive solvent from at least one reservoir, allowing it to act on the adhesive and remove the adhesive pad from the skin after receiving a signal.

“The adhesive solvent may be encapsulated within at least one adhesive solvent storage. When the adhesive solvent is released, the solvent can flow through at most one hole in its base. Siloxane can make up at least a portion of the adhesive solvent. When the adhesive solvent is released, the adhesive solvent can contact the adhesive and dissolve it. The adhesive solvent can be absorbed into the adhesive pad and dissolve it.

“While communication between devices is preferred to be wireless, an ordinary person skilled in the art would readily recognize other forms of communication such as wired communication and a capacitive interface that allows communication through user tissue such as skin.

“Illustrative embodiments” of the invention are wireless communication between a remote interface, a primary on-body medical device, and a preemptive on-body medical device that can be attached simultaneously to a user’s body with the primary On?Body Med Device or later, before the end of the life of the On?Body.

“A person who is ordinarily skilled and able to understand the art will be able to see that the illustrative embodiments can contain and/or inject insulin or any other medicament subcutaneously. While subcutaneous injection systems are described in the following descriptions, it is important to remember that the invention can deliver fluid intradermally or intramuscularly.

“FIG. “FIG. FIG. Referring to FIG.

“The MCU 105 in the OMBD 100 will retrieve and execute instructions stored within the memory 110 to activate the OMBD 100. It will also control the delivery of controlled amounts insulin to a user at set and variable rates. The present invention can be combined with any number of processors, including an integrated circuit microprocessor (ICMP), a microcontroller (DSP) and/or a central processor unit (CPU), as well as other circuits or equivalents capable of performing logical actions or interpreting instructions.

The memory 110 of the OBMD 100 contains instructions, medical device data (infusion programs and schedules), user log files, as well as any other data or parameters that are necessary to allow the OBMD 100’s operation to work properly. Memory 110 may be used in conjunction with the invention. It can include hard drives, random memory memory (RAM), read-only memory (ROM), flash memory, and any other volatile or nonvolatile memory.

“The RF Chip 115 of the OBMD 100 provides a two-way communication interface that includes a receiver (or transmitter) for communicating with a remote user interface or OBMD via radio frequency or other wireless communication protocols and protocols. ZigBee and any other WPAN protocol that is based on IEEE802.15.4 provide secure, standardized medical device communication using a variety of radio frequency allocations.

The battery 120 provides power to the MCU105. It is possible to integrate the battery into the OBMD 100, or provide a replacement battery. You can use any type of battery.

The OMBD 100 battery monitor 125 determines if the battery 120 has been installed. It also monitors the voltage of the 120. The battery monitor125 can be used to determine the voltage stored in an installed battery, and report its presence or absence. The battery monitor 125 also alerts if 120’s voltage capacity falls below a predetermined threshold. A liquid crystal display (LCD) may provide optical indication, but can also be provided with other optical indicators, such as color light emitting diodes 135, organic light-emitting dimdes (OLED), display text and background colors, backlight colors, or display text. A low-power alarm, buzzer or similar may provide audible indication. A vibratory mechanism 140 such as a piezoactuator can provide tactile indication.

“The reservoir monitoring device 130 is adapted for computing the insulin volume stored in a reservoir of OBMD 100. The reservoir monitor 125 alerts the OBMD 100 if the reservoir volume reaches a threshold.

The synchronization of devices is performed in the illustrative embodiments.

“The pump activation mechanism 150 can deliver and measure insulin doses from the reservoir via a cannula inserted under the skin of a user, when activated with the MCU105.”

“The cannula deployment device 155 can be used to insert a cannula under the skin of a user when activated using instructions from a remote UI. In the absence of a remote UI instructions, instructions from an other OMBD are sufficient.”

The proximity detector 160 can be used to prolong product shelf life and increase patient data security for RF-controlled devices with factory-installed primary-cell batteries that are not easily accessible. The proximity detector 160 uses RF to communicate with other medical devices. Inductive coupling is used with simple modulation. The proximity detector draws its power from the signal and can detect any time it needs to without needing any batteries. This increases the OBMD 100’s responsiveness and extends its shelf life. U.S. provisional Patent Application Ser. No. No. The disclosure thereof is incorporated herein by reference.

“FIGS. FIGS. 2-8 show two examples of the OBMD according to the invention. Particularly, FIGS. FIGS. 2-8 show a disposable patch pump 200 and a durable/disposable pump 250. FIGS. 2-8 show features of a completely disposable patch pump 200. 2-3, and includes integral push-buttons 215 & an upper housing 220. FIGS. show features of the durable/disposable pump 250. FIGS. 4-8 show the features of the durable/disposable patch pump 250. They include an upper housing 320 and integral push-buttons 325. A second upper housing is 340. An electrical connector 345 is also included. O-ring seals 390 are also included. A manual bolus can be activated by using one or more push-buttons. However, it is possible to activate a manual bolus by pressing more than one button. If two push buttons are pressed at once, they can be combined to activate a manual bolt.

“FIG. “FIG. 9” shows an illustration of the completely disposable patch pumps 200. A completely disposable patch pump has a reservoir 201 and a reservoir septum 205, an integral push-buttons 215 and 210, and an upper housing 220. The exemplary embodiments described herein are for the use with a catheter. This is only an example and anyone with ordinary skill in art will be able to see that any suitable substitute can be used in place of a catheter. The term “cannula” can be used to refer to any type of catheter, needle, or similar device. After one use, the completely disposable patch pump 200 can be thrown away. An antenna can be part of a computer-based appliance (PCBA) or an independent component.

“FIG. “FIG. Durable/disposable Patch Pump 250 includes a durable assembly 251 that includes a pump engine 300, connector traces 3310, a PCBA 315 and a first upper Housing 320. It also has integral push-buttons 325 and a dovetail function 330. A disposable assembly 250 is also included in the durable/disposable pump 250. It includes a dovetail function 335, an upper housing 340 and connector traces 310. An antenna can be part of a PCBC or an independent component that is electrically connected to it. The disposable assembly can be paired with the durable assembly using the dovetail feature 330 or any other known coupler.

“The durable and disposable assembly 251, 252 are connected to the channels of dovetail feature 335, 335 and connector 345 before being applied to the skin. After one use, the disposable assembly 252 is removed from the patch pump 250. The durable assembly 251 is still usable if it’s connected to another disposable, non-empty assembly.

“FIG. 11. This illustration shows an illustrative version of the catheter deployment apparatus 230, 360 for embodiments the patch pumps 200, 250, which are adapted to insert a catheter under the skin of a user when activated using instructions from a remote UI. The catheter deployment assembly 360, 230 includes an introducer needle 400 and a catheter 405. A deployment carriage 410, a retraction carriage 415 and a spring (not illustrated), as well as a tubing port.

FIG. 2 shows an illustration of the components of a remote UI. 12. FIG. Referring to FIG. 12, a remote UI 500 typically includes a microprocessor controller unit (MCU), 505, a memory, (e.g. EEPROM) 510 and an antenna 516. A speaker, LED (not illustrated), vibrator 530 and a real-time clock (RTC), 535. A LCD 540. A wired interface (USB), 545. And a proximity transmitter 550.

“The remote UI 500 MCU 505 is programmed to retrieve instructions stored in memory 510 and execute them to operate remote UI 500 500. The present invention can be combined with any number of processors, including an integrated circuit microprocessor (IC), microcontroller (DSP), and/or central processing unit (CPU), as well as other circuits or equivalents capable of performing logical actions or interpreting instructions.

“The remote UI 500’s memory 510 stores instructions, medical device data (infusion programs and schedules), user log files, as well as any other data or parameters that are necessary to allow remote UI 500 500 to function properly. Memory 510 may be used in conjunction with the invention. It can include hard drives, random memory (RAM), read-only memory (ROM), flash memory, and any other volatile or nonvolatile memory.

“The remote UI 500 RF chip 515 is a two-way communication device that includes a receiver and a transmitter for communication with another remote UI as well as at least one OBMD 100. It uses radio frequency or other wireless communication protocols and standards.

“The battery 520 provides power to the MCU505. Any type of battery may be used.

The remote UI 500 battery monitor 525 determines if the battery 520 has been installed and monitors its voltage. The remote UI 500 will be notified if the voltage capacity of the battery 520 is less than a preset threshold. A liquid crystal display (LCD), 540 may provide optical indication. However, other optical indicators, such as color light emitting diodes 530 or organic light-emitting dimmers (OLED), may also be used to indicate the battery’s status. A speaker 530 may provide an audible indication by way of a low-power alarm, buzzer or similar. A vibratory mechanism 530 such as a piezoactuator may provide tactile indication.

The synchronization of devices is performed in the illustrated embodiments of this invention using the RTC 535.

“The wired interface 545 is used to connect, communicate and supply power between electronic devices.

“The proximity transmitter 555” is designed to increase product shelf life and patient data security for RF-controlled devices with factory-installed primary-cell batteries that are not easily accessible as described above.

“FIGS. 13-14 show two examples of remote UI 500. The UIs can generally be powered by primary cells. However, the primary cells would need to replaced by the user every few years. Secondary cells, also known as rechargeable cells, can be used to power the UI. Secondary cells’ life span can be measured by how many charge/discharge cycles they have had. These cells can last for several years.

“FIG. FIG. 13 shows an illustration of a fully functioning GUI 555. Fully-functioning GUI 555 has all the features required to control and administrate the fluid delivery system. It can also communicate wirelessly via a smartphone or PC attached to it using Bluetooth LE, ZigBee or USB. Fully functioning GUI 555 also includes?up? Fully-functional GUI 555 includes?up? buttons 566 and?down to control fluid delivery system, buttons 567 and display 568 to display information.”

“FIG. 14 depicts an illustrative embodiment of a minimally-functioning key fob 560. The key fob 560’s primary function is to allow discrete bolus control, and alarms for public use. The key fob 560 is a replica of an insulin pen that is well-known to anyone with ordinary skill in the art. The user can, for example, turn the end dial 561, see the dose on display 562, then depress the button 563 at the end in the same way as an insulin pen button. Any dose setting device that can be used to adjust a dose can replace the end dial 561. The key fob 560’s design is similar to an insulin pen’s user interface. The key fob 560, for example, has a cross section and a dial to adjust, size graphics on the LCD screen and resistance to turning. The key fob 560’s overall length is approximately the same as a house key. The key fob 560 has a safety feature. This includes a secondary push-button 564, or another button, that allows bolus infusions at predetermined times. There is also a timer function to limit the amount of bolus that can be delivered within a certain time period. A key fob is an example of how to deliver and set a bolus. A key fob, for example, can be used to provide discrete delivery functions of bolus when the user is not in public. While embodiments of the minimally-functioning key fob described herein include bolus functions only, those of ordinary skill in the art will readily appreciate that the minimally functioning key fob could include the ability to adjust a basal rate in addition to setting a bolus dose.”

“For instance, insulin doses are usually administered at a basal rate as well as in a bolus dosage. Basal insulin is continuously administered over a period of time and aims to maintain blood glucose levels within a constant range between meals. Some insulin pumps can program the basal rate to change according to the time of day or night. Bolus doses are usually administered after a meal and provide one additional insulin injection to compensate for the carbohydrate intake. The user can program the volume of the insulin pump to match the type or size of the meal. A conventional insulin pump also allows the user to receive a correctional or additional bolus of insulin in order to correct a low blood sugar level while calculating a meal.

A system for on-body fluid delivery may include a primary pump that attaches a first infusion catheter to a user. The primary patch pumps are further adapted so that they can perform a plurality primary pump functions. A secondary patch patch pump is able to attach a second cannula and the secondary patch pumps are further adapted so that the secondary patch cannula can be attached to the user.

“In an illustration of a system to deliver fluid on-the-body, the plurality primary pump functions can include at minimum one of: pairing with a user interface, filling with medicament, initiating a basal rate or bolus dose, entering a secondary patch pump SLEEP mode, entering primary patch pumps WAKE mode at predetermined time intervals and entering primary patch pumps SNIFF mode for as long as a predetermined primary pump SNIFF time.”

“In an illustration of a system to deliver fluids on the body, a power source associated with a primary patch pump SLEEP mode or secondary patch pumps WAKE mode can be lower than that associated with a primary patch pump WAKE mode.”

An illustrative embodiment of a system to deliver fluids on the body can include a primary interface real-time counter and a primary pump real-time counter. To save energy, at least one cycle from a WAKE, SLEEP, and SNIFF cycles of the primary interface can be synchronized to the primary user’s real-time clock or primary patch pump real time clock. A real-time clock can be used to sync.

“In an illustration of a system to deliver fluids on the body, the primary pump can be communicatively coupled to the secondary pump.”

One example of a system that delivers fluids to the body can include a fully disposable or durable patch pump. A completely disposable patch pump may include a reservoir that can contain medicament, at most one integral push button to activate a dose, a catheter delivery assembly to deploy the catheter, a pump motor to infuse medicament through the deployed catheter. Additionally, the printed circuit board assembly will control the operation of at least one of these components and an adhesive to attach it to the skin. If both push-buttons are simultaneously depressed, the integral push-buttons may include two push buttons to activate a dose.

One embodiment of a system for fluid delivery on the body includes a durable/disposable assembly. The durable assembly can include a pump engine to infuse medicament into the reservoir and at least one integral push button to activate a dose. A coupler feature is used to couple the durable and disposable assemblies to each other. The disposable assembly may also include a connector that connects the disposable and durable assemblies to the durable, a catheter deployment apparatus to deploy the catheter, a reservoir to hold medicament, and an adhesive to attach to the system to the to the to to be controlled by the pump engine and the catheter. If both push-buttons are simultaneously depressed, the integral push-buttons may include two push buttons to activate a dose.

“In an illustrative embodiments of a system for on-body fluid delivery, at least one of a primary user interface and a secondary user interface couplable to one or more patch pumps can include one of a fully-functioning graphical user interface and a minimally-functioning key fob. A timer function can be included in at least one of the primary and secondary user interfaces to allow bolus injections at predetermined intervals. The minimally-functioning key fob can include a dose setting device, such as a turnable dial, adapted to set a bolus dose, and at least one depressible button adapted to initiate a bolus dose.”

“An illustrative embodiment of a system to deliver fluid on-the-body can have a primary user interface that is communicatively coupled to at least one patch pump or the secondary patch pump. A primary user interface may be communicatively coupled to a network link. An interface for communication can be coupled to at least one patch pump or the secondary patch pump.

FIGS. 15-21 show illustrative embodiments of systems and methods for on-body fluid delivery according to the present invention. 15-21.”

“FIG. “FIG. A primary patch pump 605 could include, for instance, a wearable medical device that can measure glucose. Primary UI 600 may include, for instance, a graphical user interface or a personal data assistant. A network link 602 could include, for instance, a personal computer network link, a mobile network link, a cellular network link, an internet link and a gateway into a network, such as a medical network.

“FIG. 16. This illustration shows an illustrative example of a system that delivers on-body fluids between a primary UI 600 or a primary patch pumps 605.

“FIG. “FIG.

“FIG. 20 shows a flow diagram that illustrates an illustration of on-body fluid delivery using a combination of a primary and secondary patch pump. Referring to FIG. 20 refers to FIG. In step S102, the primary patch pump 605 and primary UI 600 are paired. To enable secure, encrypted, wireless communication, and to minimize or eliminate crosstalk with other systems in the broadcast range, the devices are assigned the pairing and unique identifier.

The user will then fill the primary pump’s reservoir of insulin, prime the primary patches pump 605 from the secondary UI 600 and attach the primary patches pump 605 to their skin in step S103. To deliver an incremental amount of basal infusion, the user can now use the catheter from the primary patch pump 605 in step S104. Step S105 is where the user initiates a basal or bolus dose. If the user initiates a basal dose of 2 units/hr using the primary UI600, the primary UI600 instructs the primary patch pumps 605 to infuse a base rate of approximately 0.5 units per 15 minutes.

“In step S106 the primary UI 600 (and primary patch pump 605) go to?SLEEP?” Primary UI 600 and primary patches pump 605 go to?SLEEP? approximately once per minute, as shown in step 107. If upon ?waking?, the primary patch pump 605 detects the primary UI 600 in active mode, then the primary patch pump 605 temporarily enters an ?improved-response-time? Mode with slightly higher power consumption. Step S108 is where the primary patch pump 605 contacts the primary UI 600 in order to determine if the user initiated a mealtime bolus within the last cycle. The primary patch pump 605 will initiate a bolus injection of 1 unit/min if the user has initiated a mealtime bolus during the last cycle, as shown in Step S109.

“The primary patch pump 605 will ‘SNIFF? For up to 1 second, or for a predetermined amount of time in step 110. Then check for an error condition (step S111). An error condition could include one or more conditions, such as catheter occlusions, low reservoir, end-of-reservoir, battery depleted and battery failure, catheter deployment, trapped air, and leakage.

“The ?SLEEP,? ?WAKE,? ?WAKE? The background cycles continue at regular intervals and are visible to the user. The primary UI 600 wakes up when the user uses it to adjust the basal rate or to set a bolus delivery. However, after the adjustment or setting, the UI 600 remains synchronized with the?SLEEP?. ?WAKE,? ?WAKE? Cycles of the primary patch pump 605

“If there is no error condition, the primary patch pumps 605 exchanges relevant information with the primary UI600. This includes receiving infusion commands from primary UI 600 (bolus dose adjustments or bolus dosage requirements), delivering the bolus dose, making adjustments to the basal rates, and transmitting confirmation that delivery has been made. Steps S106 through S112 are repeated until an issue occurs. Relevant data may include data indicative of at most one an infusion profile upgrade, an infusion order, a base rate, a Basal Rate Adjustment, a confirmation that delivery has been made, as well as a confirmation that adjustment has been made.

“If there is an error in step S113, then the primary patch pump 605 will notify the user in step S113. The primary UI in Step S114 will also be notified. Step S115 will now allow you to remove the primary patch pump 605.

“FIG. 21 shows a flowchart illustrating an illustrative wireless delivery method for fluid on-body between a combination a primary UI and a primary patch pumps. Referring to FIG. 21. With the primary patch pumps 605 and 605 already deployed, an user turns ON the secondary pump 610 in step S201.

The secondary patch pump 610 can be paired with both the primary UI 600 or the primary patch pump 605 at step S202. Next, the user fills the reservoir of the secondary pump with insulin, primes the secondary pump 610 from primary UI 600 and then attaches the secondary pump 610 to the user in step S203.

“At this point, both the primary and secondary patch pumps 605 are simultaneously attached to user’s skin. The catheter for secondary patch pump610 has not been deployed yet. The primary UI 600, primary patch pump 605 & secondary patch pump 610?SLEEP? ?WAKE,? ?WAKE? Together in steps S204-S205 and S209.

“During this time, the user can initiate a dose bolus as shown in S207. This will trigger the primary pump 605 to initiate the dose bolus as shown at step S208 during next?WAKE? “Cycle of step S205.”

“The secondary pump 610 will remain awake up to the delivery of the bolus dose. The secondary patch pump 610 will activate if there is not enough insulin in the reservoir. It will then deploy its catheter and complete the delivery. The?SLEEP? ?WAKE,? ?WAKE? The background cycles continue at regular intervals and are visible to the user. The primary UI 600 wakes up when the user uses it to adjust the basal rate or to set a bolus delivery. However, after the adjustment, the UI 600 remains synchronized with the?SLEEP?. ?WAKE,? ?WAKE? Cycles of the primary patch pump 605, 610.”

“If an error condition is not detected in step S210 then the primary UI 600 and the primary patch pump 605 are updated with the most recent relevant data at step S211. Steps S204-S211 are repeated until the error condition is detected and an error flag at step S206. An error condition at step S210 is marked with an error flag at step S212. The primary UI 600 and primary patch pump 605 are then updated with the most recent relevant data at step S211. Steps S204-S211 are repeated up to the error condition.

“Accordingly at the next?”WAKE? Step S207: The error flag at step S206 is present at step, initiating a transfer between the primary patch pump 605 and the secondary patch pump 601. If the primary UI 600 has been detected at step S213, the primary patch pump 605 will communicate relevant data to the primary UI 600 600 and the secondary 610. At step S215, the primary UI 600 deploys the catheter to the secondary patch pump 610. At step S216, the secondary patch pump610 assumes the role of a primary pump. A second preemptive patch pumps can be attached to the user. They can then take over the role as a secondary pump.

“If however, there is no primary UI 600 detected at step 213 then the primary patch pumps 605 transmits the relevant data to the secondary patches pump 610 at S217. The catheter is then deployed on the secondary UI 600 pump 610, and the infusion continues via secondary patch pump610 at step 218.

“A ?SLEEP? “A?SLEEP? mode can have a lower power consumption than a?WAKE?? mode. mode. The?SLEEP?” mode can be changed. The?SLEEP? can last for minutes. The background of the LCD screen 540 can be changed to match the?dose requested? (yellow), to ?dose delivered? (yellow), to indicate that the dose was delivered. These states are not required to be communicated to users. The background of the LCD screens 600,615 or 540 can be turned off as for?sleep? mode. You can also provide tactile and audible signals for the three states mentioned above. Each condition is distinct.

FIG. 19 may activate an additional secondary user interface 615. A secondary UI 615 such as a key fob560 may be activated in this embodiment to enable wirelessly discrete bolus control. It can also provide alarms for public use. The primary UI 600 prevails over the secondary UI 615 when there is a primary UI 600.

“The patch pumps 605,610 might not recognize two different UIs 600 and 615 when they wake up. During travel, if primary UI 600 is found in a user’s bag or trunk, and cannot be recognized as such by the patch pumps 605, 610, the user can only use secondary UI 615 for bolus. Secondary UI 615 is possible in this case in the same manner as a patch pump being removed from the?shelf? Mode and?paired? With the master UI. This is done by placing secondary UI 615 near the patch pumps 605, 610. This process is further described in U.S. provisional Patent Application Ser. No. No. The disclosure is included by reference in this document. Illustrative embodiments show that two UIs can wake up and recognize one another following an event. Relevant data should be transferred from UI2 into UI1, with UI1 taking the dominant role.

“Alternatively, the patch pumps 605,610 can wake up and recognize secondary UI 615. A time limit can be set (e.g. 30 seconds) for them to continue to sniff? Secondary UI 615 can then be used to provide a command for the patch pumps 605, 610. However, the two UIs 600 and 615 should not be enabled simultaneously to give commands to the patch pumps.

“FIGS. 22A-24B show illustrative embodiments for fourteen states 1-14, and operations for activated medical device of the fluid delivery method of the present invention. FIGS. 22A-24B show the system operation for each combination of a primary and secondary patch pump (Patch Pump 1 (PP1), a patch pump 2 (PP2), a primary user interface (UI1), and secondary user interface (UI2) respectively. 22A-24B. FIGS. FIGS. 22A-24B show illustrative embodiments that can cause communications failure (e.g. states in which patch pump 1 is not recognized and all devices wake up) and how the embodiments of this invention provide uninterrupted, safe therapy for a user.

“In state 1, an illustration system includes PP1. Illustrative system Operation can be carried out as follows. Initially, PP1 was paired with UI1, which synchronized?sleep,??wake, and?sniff?. Both devices were initially paired to PP1. This synchronized the?sleep?,?wake??,???sniff? cycles. PP1 will awaken, perform self-diagnostics and sniff for UI1 before returning to sleep. PP1 will continue to deliver basal infusion at a rate previously transmitted by the UI. The push-buttons at PP1 allow users to initiate bolus delivery manually.

“In state 2, an illustration system includes PP1 & UI1. Illustrative system Operation can be carried out as follows. Initially, PP1 was paired with UI1, which synchronized?sleep,??wake, and?sniff?. Both devices will cycle. PP1 will awaken, perform self-diagnostics and recognize UI1. PP1 also can transfer the last update to the infusion profile, receive infusion commands (e.g. Deliver the bolus dose or adjust the basal rates, then send confirmation and/or adjustment. Then, go back to sleep.

“In state 3 an illustrative program includes PP1,UI1 and UI2. Illustrative system Operations may be carried out as follows. PP1 was originally paired with UI1, while UI2 was also paired with UI1, which synchronized?sleep,??wake, and?sniff?. All three devices will go through the same cycle. PP1 will wake up, perform self-diagnostics and sniff, recognize UI1 as well as UI2. PP1 also will transfer to both the previous infusion profile updates. PP1 will not receive infusion commands from UI1 if both UIs are present. bolus dose requirement or basal rate adjustment. After the delivery of the required bolus dose, and any adjustments to the basal rates, PP1 will confirm delivery and/or adjustment and send you back to sleep.

“In state 4, an illustration system includes PP1 (UI2) Illustrative system Operations may be carried out as follows. PP1 was originally paired with UI1, while UI2 was also paired with UI1, which synchronized?sleep,??wake, and?sniff?. All three devices will go through the same cycle. PP1 will wake up, perform self-diagnostics and sniff out UI2. In the absence UI1, PP1 will transmit to UI2 any infusion profile updates that occurred since the last update was transmitted. UI2 is limited to one infusion command. UI2 can only provide one infusion command, i.e. Either UI2 nor PP1 will update UI1, depending on whether UI1 is still being recognized.

“In state 5, an illustration system includes PP1 (or PP2) Illustrative system Operation can be done as follows. PP1 was originally paired with UI1, while PP2 was also paired with UI1, which synchronized?sleep,??wake, and?sniff?. All three devices go through the same cycle. In the absence UI1, PP1 will wake up, perform self-diagnostics and sniff for UI1 as well as any other devices to which PP1 is paired. PP2 will then transfer to PP2 an infusion profile update that occurred since the previous update. Then, PP1 will return to sleep. The user can manually deliver bolus doses. The user can manually bolus PP1 by sending a command to PP1. Both PP1 (and PP2) will be awake upon awakening until the full bolus dose is delivered. If there is not enough insulin in the reservoir of PPP1, PP1 will inform PP2 about the rest and the basal delivery rate. The infusion catheter will be deployed by PP2, and the remaining bolus dose will be delivered. Afterwards, PP2 can return to sleep. After receiving confirmation by PP2, PP1 can disable all infusion capabilities and return to the synchronized wake, sleep, sniff cycle. PP2 will continue to operate in state 1 as PP1 and provide basal infusion and manual-actuated incremental bolus dosing. If PP2 wakes up and recognizes UI1, then the PP2 will update that state. PP2 (and UI1) will then operate as PP1 or UI1 in states 2. The catheter can be pulled out of PP1 and the adhesive can be dispersed automatically by UI1. Alternatively, PP1 can still be removed manually from the user’s skin.

“In state 6, an illustrated system includes PP1,PP2 and the UI1. Illustrative system Operation can be done as follows. PP1 was originally paired with UI1. PP2 was also paired to the UI1 separately, which synchronized?sleep,??wake, and?sniff? All three devices will go through the same cycle. Together, PP1 (and PP2) will wake up, perform self-diagnostics and sniff out UI1. PP1 will transmit to UI1 any infusion profile updates that have occurred since the last update was transmitted. UI1 will transmit to PP2 any infusion profile updates that have occurred since the last update. Infusion commands will be sent to PP1 by UI1. These could include adjustments to the basal or bolus doses. After the delivery or setting of the bolus dose, or adjustment to the basal rate, the PP1 device will send confirmation to UI1. UI1 in turn will transmit the update to the PP2, and all three devices will go to sleep. If there is not enough insulin in the PP1 reservoir to complete the required delivery of the bolus dose or if PP1 has exhausted itself during basal delivery, the PP1 will inform UI1. After receiving confirmation by UI1, PP1 will disengage all infusion capabilities and return to the synchronized wake, wake, sniff cycle. UI1 will then transfer any remaining bolus doses and/or basal rates to PP2. The infusion catheter will be deployed by PP2 and the basal rate and/or remaining doses of the bolus administered to PP2. Afterwards, PP2 will transmit confirmation of the dose and go back to sleep. In state 2, PP2 will operate as PP1.

“In state 7, an illustrated system includes PP1,PP2, UI1 or UI2. Illustrative system Operation can be done as follows. PP1 was originally paired with UI1, while PP2 was paired independently to UI1. UI2 was also paired with UI1, which synchronized?sleep,??wake, and?sniff?. All four devices will go through the same cycle. Together, PP1 & PP2 will wake up, perform self-diagnostics and sniff out both UI1 & UI2. PP1 will transmit to both UIs any infusion profile updates that have occurred since the last update was transmitted. PP2 will receive the infusion profile update that occurred since the last update. Infusion commands will be sent from UI1 to PP1 when both UIs are present. These could include adjustments to the basal rates or bolus-infusion commands. After the delivery or setting of the bolus dose, and any adjustments required to the basal rates, PP1 will send confirmation to both UI1 (or UI2) of delivery. UI1 in turn will transmit the update to all four devices. If there is not enough insulin in the PP1 reservoir to complete the required delivery of the bolus, or if PP1 has exhausted itself during basal delivery then PP1 will inform UI1. After receiving confirmation by UI1, PP1 will disengage all infusion capabilities and return to the synchronized wake, wake, sniff cycle. UI1 will then transfer any remaining bolus requirements or basal rate to PP2. The infusion catheter will be deployed by PP2 and the basal rate will continue to PP2. Afterwards, PP2 will transmit confirmation of the remaining dose and resume basal delivery. In state 3, PP2 will operate as PP1. A new patch pump can be attached by the user, which will assume the role of PP2’s preemptive patch pump.

“In state 8, an illustrated system includes PP1,PP2 and UUI2. Illustrative system Operation can be done as follows. PP1 was originally paired with UI1, but PP2 was later paired with UI1, while PP2 was paired independently and UI1. UI2 was also paired with UI1, which synchronized?sleep,??wake, and?sniff?. All four devices will go through the same cycle. Together, PP1 (and PP2) will wake up, perform self-diagnostics and sniff out UI2. PP1 will transmit to UI2 any infusion profile updates that have occurred since the last update was transmitted. UI2 will transmit to PP2 any infusion profile updates that have occurred since the last update. UI1 is not required to transmit UI2’s infusion profile update. PP1 will be able to receive bolus injection commands from UI2. These could include adjustments to the basal rates or bolus injection commands. After the delivery or setting of the bolus dose PP1 will send confirmation to UI2 and UI2 will then transmit the update to the PP2 and all three devices will go to sleep. If there is not enough insulin in the PP1 reservoir to complete the required delivery or if PP1 has exhausted itself during basal delivery, the PP1 will inform UI2. After receiving confirmation by UI2, PP1 will disengage all infusion capabilities and return to the synchronized wake, sleep, sniff cycle. The remaining basal rate or bolus dose requirement will be transferred to PP2 by UI2. PP2 will then deploy the infusion catheter and/or deliver the remaining bolus dose. It will also transmit confirmation of the bolus dosage and resume basal delivery. In state 4, PP2 will operate as PP1. If PP2 wakes up and recognizes UI1, then both PP2 (and UI1) will be able to operate as PP1 in state 3. Then, either UI2 nor PP2 will update the UI1, and either UI2 oder PP2 will continue to wake, sniff and sleep until UI1 is recognised again.

“In state 9, an illustration system includes UI1. Illustrative system Operation can be as follows. If UI1 fails to recognize a PP upon awakening, an alarm is sent to the user.

“In state 10, an illustration system includes UI2. Illustrative system Operation can be as follows. If UI2 fails to recognize a PP upon awakening, an alarm is sent to the user.

“In state 11, an illustration system includes UI1 or UI2. Illustrative system Operations may be as follows. An alarm is sent to the user if UI1 or UI2 fail to recognize a PP upon awakening.

“In state 12, an illustration system includes PP2 (UI1) Illustrative system Operations may be carried out as follows. PP1 was originally paired with UI1. PP2 was also paired to the UI1 separately, which synchronized?sleep’ and?wake? ?sniff? Cycle of all three devices. PP2 will wake up, perform self-diagnostics and sniff out UI1. In the absence PP1. In the absence of PP1, UI1 will transmit to PP2 any user update for bolus dosage requirement, basal rates, or basalrate adjustment. The infusion catheter will be deployed by PP2, and the bolus dose delivered. Afterwards, PP2 will transmit confirmation of delivery and resume basal delivery. In state 2, PP2 will operate as PP1. PP2 will now function as PP1 in state 2. be removed. After two cycles of sniffing for PP1, UI1 will be awake and continue to sleep. Upon returning to synchronized sleep, wake-sniff cycle, UI1’s UI1 will go back to normal. “(PP1 internal protocols will disable any infusion capability once they detect a communication problem.

“In state 13, an illustration system includes PP2 or UI2. Illustrative system Operation can be done as follows. PP1 was originally paired with UI1. PP2 was then paired with UI1 separately. UI2 was also paired with UI1, which synchronized?sleep,??wake, and?sniff?. All four devices will go through the same cycle. PP2 will awaken, perform self-diagnostics and sniff, and only recognize UI2. In the absence PP1 or UI1, UI2 can transfer to PP2 any user updates regarding bolus dose requirement. The infusion catheter will be deployed by PP2, and the bolus dose delivered. Afterwards, PP2 will transmit confirmation that the bolus dosage was delivered and resume basal delivery. In state 3, PP2 will operate as PP1. PP1 will no longer function properly, and UI2 will notify the user by means of an alarm. UI2 will be awake for two cycles to sniff for PP1. After that, UI will resume its synchronized sleep, wake and snuff cycle. (PP1 internal protocols will disable any infusion capability once they detect a communication problem.

“In state 14, an illustrated system includes PP2,UI1 andUI2. Illustrative system Operation can be done as follows. PP1 was originally paired with UI1, while PP2 was paired independently to UI1. UI2 was also paired with UI1, which synchronized?sleep,??wake, and?sniff?. All four devices will go through the same cycle. PP2 will wake up, perform self-diagnostics and sniff out UI1 or UI2. In the absence PP1, UI1 will wake up and conduct self-diagnostics. It will then recognize only UI1 and UI2. The infusion catheter will be deployed by PP2, and the bolus dose delivered. Afterwards, PP2 will transmit confirmation that the bolus dosage delivery was successful and resume basal delivery. In state 2, PP2 will operate as PP1. PP1 will now function as PP2 in state 2. After two cycles of sniffing for PP1, UI1 will be awake and continue to sleep, wake, and sniff. (If a communication problem is detected, PP1 will disable all infusion capabilities.

“As we have discussed, RTCs used in the medical devices of fluid delivery system of this invention can differ due to inherent limitations in accuracy and ambient conditions like temperature. RTCs are currently subject to a maximum error of approximately 2 minutes per annum, which is roughly one second over three days.

“An embodiment based on the present invention overcomes inherent limitations in electronic clock accuracy used in medical devices with wireless communications, such as RTCs. It controls protocol timing incrementally using very short intervals and uses only short intervals.”

Summary for “Wireless communication to on-body medical devices”